Switch sometimes fails to switch with multiple concurrent actions

[mattsaxon]

Debug error show in log when switching

2019-04-16 11:19:45 DEBUG (Thread-3) [custom_components.sonoff] websocket msg: {"error":504,"reason":"Request Timeout","deviceid":"100065897f","apikey":"cb0ff096-2a9d-4250-93ec-362fc1fe6f40","sequence":"15554099808773541"}

This occurs more frequently when switching multiple devices at same time.

The result is the physical switch does not change, but the switch icon in HA switches making it out of sync.

[peterbuga]

unfortunately, as the error says "reason":"Request Timeout" this is an expected behaviour. due to how HA currently works, it tries to switch individually all of them in the same time, therefore i think i need create some scheduler system to execute them 1-by-1 (for example toggling a group you will see them go on/off successively) or maybe i could try to open a new websocket connection for each device... but i don't have to many to test this theory so i don't know how it'll behave in the end

right now i don't see any other workaround this problem and pretty sure itead doesn't consider it a problem either, you can't toggle 2+ devices in eWeLink app in the same time ... or can you 😮 ?

[mattsaxon]

The issue for me is occurring quiet regularly for just 2 devices. I also get the

2019-04-16 11:26:44 ERROR (Thread-3) [custom_components.sonoff] websocket error: Connection is already closed.

error around the same time..... sometimes!

The 1 by 1 approach might yield dividends in terms of reliability, but I really like the immediate effect of the new approach (I'm testing the https://github.com/beveradb/sonoff-lan-mode-homeassistant/ repo in parallel btw on a different instance of HA which also has this benefit.

A separate websocket sounds like it could be appropriate means of dealing with this.

I'll continue to feedback what I find to help and maybe when I get a little more knowledgeable on HA, I can assist with resolution.

[peterbuga]

I'm highly familiar with the sonoff-lan-mode repo and it's a major difference between how that works and this component. That one opens a websocket command for each device (just like i mentioned above) but because it's done directly over the local network it's more reliable/fast.

To achieve your all-off requirement, further testing and some hefty rewrite of the logic involved needs to be redone. Right now though I'm re-writing the script to be HASS compatible and hopefully some day it'll be added to the main project. Bottom line unless someone is willing to step in and at least give me some help code-wise regarding this, do not expect to be fixed anytime soon.

You could give a try the old v0.2+ poll-ing version which is slower in pretty much every way but opens briefly a new websocket for each switch action and you might avoid the connection is already closed errors

[mattsaxon]

@peterbuga, yes many thanks for all the work, I'll keep plugging away with both repos and will gladly lend a hand in due course (i.e. when my skills allow)

[GertSchepens]

I'm getting this error in the logs, recently more than before. For a scene change that involves several switches..

2019-05-01 22:43:11 ERROR (Thread-2) [custom_components.sonoff] websocket error: Connection is already closed. 2019-05-01 22:43:11 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/config/custom_components/sonoff/init.py", line 270, in state_listener self.get_ws().send(json.dumps(payload)) File "/usr/local/lib/python3.7/site-packages/websocket/_app.py", line 153, in send if not self.sock or self.sock.send(data, opcode) == 0: File "/usr/local/lib/python3.7/site-packages/websocket/_core.py", line 250, in send return self.send_frame(frame) File "/usr/local/lib/python3.7/site-packages/websocket/_core.py", line 275, in send_frame l = self._send(data) File "/usr/local/lib/python3.7/site-packages/websocket/_core.py", line 445, in _send return send(self.sock, data) File "/usr/local/lib/python3.7/site-packages/websocket/_socket.py", line 114, in send raise WebSocketConnectionClosedException("socket is already closed.") websocket._exceptions.WebSocketConnectionClosedException: socket is already closed. 2019-05-01 22:43:11 ERROR (MainThread) [custom_components.sonoff] websocket is not connected

I'm guessing this is the same problem. (but figured I'd drop a note anyway to make sure)

[peterbuga]

@GertSchepens yes it seems kinda the same problem. as I mentioned above looks like I have to get find some kind of workaround for this, meanwhile just add a delay between the switching of devices if possible

[2016for]

@peterbuga In my opinion won't it be better if we can combine the "Params" on group actions in one websocket message rather than having a delay b/w commands?

At least for multiple outlet devices. (Ewelink Google Home integration turns of all outlets at same time when told to turn off all lights)

Thanks.

[peterbuga]

@2016for unfortunately the problem is different in the case of multiple outlets (and clearly do not compare anything with google, they're so big that companies go head over heals just to look good for them) as i'm exposing them as single switches in HA (because that's how stuff need to work). as far as HA knows they are completely separated and will try to triggered them individually, creating individual channels of execution that i'm not sure if they can be captured back into only one (definitely I don't know how to do it).

moreover this still doesn't fix the main problem if you try, for example, to toggle 5x sonoff basic in the same time

[skelgaard]

any news on this ?

[peterbuga]

i might've found 2-ish ways to overcome this problem, but i've seen people stuck with the 1+ seconds delay between entities option soo i'm not sure if this still deserves a real fix anymore

[skelgaard]

• delay: '00:00:01' works... i will use that for now at least... newer thought about using that

[primalnow]

@peterbuga inserting a delay works in automations and scripts. But groups and scenes, remain totally useless. If your API could queue the requests, and then clear them with a 1s delay, it would make groups/scenes useful, and also make automations/scripts easier.

Hoping, you'd have some free time this weekend :)

[dwl99]

I'm having this too for several S20 & Basic 2 devices all on 3.3 FW. Has anyone tried duplicating or triplicating the list of devices for each automation in automations.yaml?

[peterbuga]

Has anyone tried duplicating or triplicating the list of devices for each automation in automations.yaml?

what do you mean by this?

[dwl99]

Has anyone tried duplicating or triplicating the list of devices for each automation in automations.yaml?

what do you mean by this?

listing the same devices several times for each automation, e.g.

device1 device2 device3 device1 device2 device3 device1 device2 device3

Anyway, I tried it & it doesn't work.

[peterbuga]

@dwl99 such a bad idea, it has been explained above why multiple switches don't work in the same time. i've been having some ideas on how to overcome this problem but for now it doesn't represent a total priority IMO therefore it'll take a while till i might actually fix this issue 😅 (i also think it's a bit annoying for the people using this plugin with HomeKit ... but it is what it is)

[victorlapshev]

Any news?

[Rapidlaser]

I have also discovered another couple of bugs, 1) if using google routines, switching one item then another the first sometimes cancels the first and sometimes even stranger it double switches the first command which has the effect of tuning it off and on quickly.