API buy problem about iqoptionapi HOT 11 OPEN

Same problem!

It apears that the epiration time is wrong in timesync.... because the response from server contains:
{"name":"buyComplete","msg":{"isSuccessful":false,"message":["Time for purchasing options is over, please try again later."],"result":{"request_id":null},"code":4}}

Just don't know how to fix this......

from iqoptionapi.

@j1and1 how did you print that response?

from iqoptionapi.

@inmarelibero I used logger to see what actualy happens when I buy an option......

It seems that api.buy method does not return anything.....

Conveniently I got some help with this issue here

from iqoptionapi.

@j1and1 ok, but how did you use the the logger? sorry it's a python related question, I'm not yet experienced with it

from iqoptionapi.

fix
expirationtimestamp -= expirationtimestamp % 60;

from iqoptionapi.

@crypto-maniac This is incorrect and inconsistent. Rounding the timestamp already occurs on the Java API and it still doesn't ensure that trades are executed on time. This has been covered at least 10 times.

from iqoptionapi.

Login to iqoption via the app (preferred) or the website (slower).
Now notice how the new candle commences at your local time of 00 seconds
You need to place your stake before the candle opens, so I suggest doing so at 59 secs local time
that is - within the 1 second before the candle opens, this is normal
this allows time for the trade request to be received before the candle opens

The websocket (wss connection) will respond if the stake is placed correctly
You will get (if you are viewing the wss response);
profile
listInfoData
and buyComplete messages

When the candle closes you are updated with listInfoData and profile messages.

Note, this api does round the time for you = timestamp / 1000 - where timestamp is the time since epoch in milliseconds divided by 1000 to convert to seconds (there are 1000 milliseconds in a second).

What is epoch time? The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z).

The code below is taken from this api - timesync.py

@Property
def server_timestamp(self):
"""Property to get server timestamp.

    :returns: The server timestamp.
    """
    return self.__server_timestamp / 1000

For info;
iqoption allows 2 logins from the same ip address, so

• Don't run this from home and login to iqoption whilst out and about as it won't let you.
• If you changebalance - the balance will be seen to change on the app / webpage - from practice to real or vice versa - as you requested. Ignore the popup, it does not stop trading from the api.
• if you place a trade using your program / this api, and run the app or webpage on the same computer, you will see the trade on the app.

So
Place your buy command at a local time of 59 secs, just before the candle you wish to trade opens.

from iqoptionapi.

Thank you, all works!

from iqoptionapi.

@playsten4096 : Share your working script

from iqoptionapi.

This code gives at least 1 minute of distance from now to the expiration time. You don't need to make the order exactly at 00 seconds. On my experiments, I had to make the order 2 seconds before the clock turns.

Notice I have changed the timedelta from minutes to seconds (do not use expiration_timestamp as it is a derivate method).

    @property
    def expiration_datetime(self):
        """Property to get expiration datetime.
        :returns: The expiration datetime.
        """
        exp = (2 * self.expiration_time * 60) - (self.server_datetime.second % 60)
        return self.server_datetime + datetime.timedelta(seconds=exp)

But the actives have different expiration time. Some have 1 minute, others start from 15 minutes. How can we get the correct choices? Almost sure there is a message for this.

from iqoptionapi.

@vinydl and @playsten4096 - do you have, guys, working script? I have the same issue today

from iqoptionapi.