Codes sometimes reproducibly don't work with Siri until I toggle the state twice in the Home app - debug help request about homebridge-broadlink-rm HOT 5 OPEN

Incidentally, here is the old node-red work-around I implemented with the Magnavox TV (when both the on/off codes were the same toggle code):

This seemed to always reliably work.

from homebridge-broadlink-rm.

Hi,
I have a similar issue but with my airconditioners.Indeed homebridge restart breaks the connection momentarily.
I have 4 Broadlink RM mini 3 at home and 2 of them have this issue. What I have also noticed is that the ones that have the issue are RM mini 3 Red Bean (5f36). The other two that work flawlessly, are RM mini 3 Black Bean (2737). Although the 2 devices are physically the same, they seem to have differences in their firmware which is somehow causing this in my opinion.

from homebridge-broadlink-rm.

I created a new node-red flow for the new TV (with separate discrete on and off codes), similar to the one pasted above for the old TV (which had the toggle code configured for both on and off):

This flow works flawlessly, only sometimes, it takes a second before the TV turns on/off. Basically, it determines whether I'm trying to turn the TV on or off and then queries the homebridge plugin to see what state it thinks it's in. If the states are the same, it just sends the one intended command. If they differ, it sends the opposite command, pauses a second, then sends the intended command.

I see why you suspect it is firmware due to the coincidental correspondence of the models/firmware linked to behavior. The red ones have different firmware. Even though they are packaged as an RM mini 3, mine would not work at all until I configured it in homebridge as an rm mini 4, so it definitely has different firmware. But I have the inverse behavior. The one with the issue is my black/old one (the firmware for rm 3) and the one without the issue is the red/new one (with the rm 4 firmware). I cannot say for certain yet, but my programmer's intuition is that this is not a firmware issue. I suspect that it is something to do with the plugin, and that the issue can be device-independent. I have a plan to rule out the firmware/device as the cause, but only once I encounter it organically.

Out of curiosity, since you've clearly poked around on this issue, have you tried setting persistState to false or setting resendHexAfterReload to true? I'm wondering if either of those settings would effectively work around this issue...

from homebridge-broadlink-rm.

Hi again,
No i havent tried those to be honest .I will give it a try tonight although i dont want to be hijacking your post in any way....

from homebridge-broadlink-rm.

Doesn't bother me.

from homebridge-broadlink-rm.