consecutive commands issue about broadlink-http-rest HOT 14 CLOSED

The timeouts have been shortened. If you need multiple commands in a row, a macro is best. If you need longer timeouts you can change them in both the device and global section. The device section waits for the IR device while the global section is the http timeout

from broadlink-http-rest.

Thanks :)
The macro is not an option for me because I get the commands from external source (Google Home), so I will change the timeout in the settings.
What are the units used? if the timeout is set to 4 - is that 4ms?

BTW, I've noticed that RF commands are more sensitive for the short timeout, is there a way to have one timeout for RF and a second one for IR?

from broadlink-http-rest.

All my commands come from Google Home as well, and I've never had them come that fast. I don't have anything RF to test with (except what I rigged up using GPIO off my Beaglebone wired into a remote).

The increments are tenths of a second if I remember correctly. And you can set timeouts per gateway device, but there is no way to know if the command will trigger RF or IR.

I would start by setting the Timeout in the global section to something large, like 20. I think it's just dropping the connection on you. The timeout was lowered because it would hold connections open and not respond. A real fix would be to have larger timeouts and thread the server. It's on my to-do list.

from broadlink-http-rest.

Curious. How do you integrate Google Home? I'm using IFTTT with the Webhooks module. Which method are you using?

from broadlink-http-rest.

I use Action on Google, I built Dialogflow bot that control my home theater system, and SmartHome app to control devices like RF light switches etc.

So my problem is that I have rooms with two lamps, and when I'm asking the Google Home to turn off both of them it sends out JSON with the two devices, and my webservice sends two http requests to the broadlink server. also, I have some scenes configured that can send even 7 commands together...

The advantage of Action on Google over IFTTT is first bigger scale, and the Natural Language Processing - you can say what you want how you want and google's NLP will figure it out...

The short timeout seems to bother only the RF for some reason... I'll try playing with the timeouts and see how it goes. Thanks :)

from broadlink-http-rest.

I don't see any information about Action. Can you post a link? The lack of NLP is killing me with IFTTT and there are tons of bugs in their interface. Edit: Found it

Sending lots of commands in sequence shouldn't hurt it. In fact, my html based remote will send a new command as soon the previous reply is received as long as you hold down the button.

from broadlink-http-rest.

@Harel-M Do you have to use the "talk to my app" style phrasing, or just "hey Google, turn off the livingroom light". Most of the documentation seems to indicate this extra step, but I heard Google.did away with that.

I'd like to see what it would take to allow this project to be used as a the dialogflow webhook directly, basically cutting out a piece of middleware. I think the integration would make for more maintainable configurations. I'm still reading docs, but also doing crazy overtime at work.

from broadlink-http-rest.

It depends.. for dialogflow bot yes, as far as I know there is no way to do it without telling google "ok google, ask BOT-NAME bla bla...".
With Smart Home apps (https://developers.google.com/actions/smarthome/) the commands are given directly to the Google Assistant, but it is much more limited than dialogflow.. there are several devices types and commands you can give them, and it is not as flexible as dialogflow...

from broadlink-http-rest.

BTW for our original topic, I tried playing with the device and http server timeouts, but couldn't get the same performance as in the original script...
In the old setting file there was no timeout for the device... do you know if there were such a value embedded in the script, and what was it?

BTW I see in the server print outs that all the commands are sent, but the RF devices are not responding to the second ones if they are sent to quickly.

from broadlink-http-rest.

The old code had a timeout of 4 seconds or something, but I don't think it worked. It would just wait forever.

In general, the new code allows things to be sent FASTER. And there is a device authorization that used to be done every command, which is now only done at start-up. I'm thinking it's just sending too fast for your device and cramming the RF commands too close together.

One way to test this would be to change your commands into macros. For example ...

commandA = ...... << whatever it was >>

rename it to "rawCommandA" or whatever, then add a line like this ...

commandA = MACRO rawCommandA sleep

That adds a 1second pause at the end of the command. If that works, we can see about doing this programmatically in the code for that device type.

Also, does it only do it when sending multiple commands to one end device, or multiple commands to the broadlink with different destinations?

from broadlink-http-rest.

Hi sorry for the long time... just now had a chance to test it.
adding the one second delay with the MACRO indeed solved the problem.
I think the code should allow to add a delay in milliseconds (as one second is a bit annoying long delay) for every command in the settings.

For me the problem is when sending commands to several devices - e.g. sending "turn on" command to two RF light switches - only the first one is turning on.

As a work around I added 800ms setTimout in my script that sends the HTTP request, but having this done in the setting.ini file of this script is much better solution.

Thanks.

from broadlink-http-rest.

I agree that the code should solve it rather than the Macro system, but now we know where the issue is. I'm wondering just how fast we can send commands. I'm thinking the delay should only be when sending consecutive commands to the same broadlink device, and maybe only for RF, some sort of Max throughput we can look at per device type. I'll think on this, but it won't be terribly soon. This weekend is booked

from broadlink-http-rest.

Having it only for consecutive will be great, but I also can't think of a way to do it :)

As for when to do it, take your time, as I said I have a work around for this ;)

I can just suggest maybe to add a small note about this in the Readme file (maybe even mentioning the MACRO work around).

Thanks a lot.

from broadlink-http-rest.

Only problem is that my tree has diverged quite a bit from this one and there are a lot of changes I want to make. As for the sleep not being granular enough, I agree. I needed a smaller sleep today in fact, and made a quick hack to allow for float numbers. So, "sleep,0.25" is now a quarter second (not uploaded anywhere since I just tried it just now), but I think that's an easy/compatible fix.

EDIT: My tree allows floating point sleep times as well as a per-device "Delay" parameter that will automatically place the given delay between commands. I think this is the best way to tackle this.
However, it's quite a bit diverged with a lot more dependencies and functions more as a programmable hub rather than just an IR gateway.

from broadlink-http-rest.