Codes sometimes reproducibly don't work with Siri until I toggle the state twice in the Home app - debug help request

[hepcat72]

I don't know if this is a problem with this plugin or my Broadlink RM Mini 3, but I have finally ruled out the TV and I think I've ruled out Siri. This had been happening quite some time with my previous dumb TV (a Magnavox) and now has happened with our new (hand-me-down) dumb LG TV, and it's more of a problem because CEC on the LG doesn't work (correctly).

PROBLEM: It appears that sometimes the code sent by the Mini doesn't work, and repeated sends of the same code reliably and reproducibly don't work either. The light on the mini flashes and the code in the homebridge log checks out (it is the correct code), so it thinks it is sending a code.

Notable details:

• I am using discrete on/off codes, not a toggle (obtained from irdb.globalcache.com)
• I am using Siri to issue the command (e.g. "Hey Siri, turn off the LG TV")
• whenever this has happened, I have noted that the state of the button in the Home app is out of synch with the actual TV power state (e.g. the home app shows it is off, but it is on and I'm trying to turn it off).

WORKAROUND: When the problem happens, I can open up the home app and manually toggle the button twice. The first tap synchs the actual power state with the home button state so that it is accurate. The second tap actually changes the power state of the TV (e.g. if I am trying to turn off the TV, I turn it "on" in the home app [and the TV remains on] and then I turn it off in the home app [and the TV actually turns off]). Every subsequent Siri on/off command then works as expected and I am unable to reproduce the problem even if I intentionally put the TV power state and the home app button power state out of synch.

Since this has now happened with 2 different TV's, I no longer think that it is a failure of the TV to correctly respond to the code. I feel like it must be that either the Mini is screwing up the code or the plugin is somehow showing the right code in the log, but it differs from the actual code sent.

Here is the accessory in the config:

                {
                    "name": "LG TV",
                    "host": "192.168.1.61",
                    "type": "outlet",
                    "allowResend": true,
                    "data": {
                        "on": "260050000001289412121212123712121212121212121212123712371212123712371237123712371212121212371212121212121237123712371237121212371237123712121212120005a50001284a12000c980d05000000000000",
                        "off": "260050000001289412121212123712121212121212121212123712371212123712371237123712371237121212371212121212121237123712121237121212371237123712121212120005a50001284a12000c980d05000000000000"
                    }
                },

Note, I have 2 mini's, that's why the host is set.

I am creating this issue to see if anyone has any debug suggestions. How can I confirm that the mini is actually sending the correct code, aside from what's in the homebridge log?

Additional Information

To be transparent, I am technically equating 2 different situations with the 2 TVs, because I didn't want to complicate things, but I think that there is additional information that may provide a clue to the root of the problem. I never actually had discrete on/off codes for the Magnavox TV. Instead, I simply had the toggle code for both the on and the off codes:

                {
                    "name": "TV",
                    "host": "192.168.1.61",
                    "type": "outlet",
                    "allowResend": true,
                    "data": {
                        "on": "26004e002119211a3e1a211a201a2119211a201a2136211a3e1a21000b96201a211a3e1a201a211a201a211a201a213621193f1a20000b96201a211a3e1a201a211a201a211a201a2136201a3f1a20000d0500000000000000000000",
                        "off": "26004e002119211a3e1a211a201a2119211a201a2136211a3e1a21000b96201a211a3e1a201a211a201a211a201a213621193f1a20000b96201a211a3e1a201a211a201a211a201a2136201a3f1a20000d0500000000000000000000"
                    }
                },

And I created a shortcut in node-red for the workaround:

SHORTCUT FOR THE WORKAROUND: This is essentially the same workaround as above, but since both on and off are set to toggle, it only needs to issue the opposite command once. I implemented the shortcut in node-red. Using node-red's homekitd node, I created a separate "TV toggler" button which retrieves the state of the homebridge TV button and issues the opposite command. E.g. if I'm trying to turn off the TV and the home button says it's off, it issues the on command (which turns the TV off because they're both the toggle code).

Insight

Since the config for the old Magnavox TV had the same toggle code for both on and off, this rules out the possibility that the plugin is sending the opposite code (but reporting in the log that it is sending the intended code). So I have no reason to believe that it is sending the opposite code.

Since the light on the mini flashes, it seems that the mini at least things it is sending a code. I just have no way to confirm it is sending the code.

The physical TV remote always works and there is nothing obstructing the line of sight between the mini and the TV, so either the mini is sending the wrong code or it thinks it is sending a code but it is not.

My intuition tells me that since this only seems to happen when the state is out of synch between the home app and the mini knows nothing about that, the problem must be with the plugin. I should actually test this using the broadlink app. If I can get a discrete code in the broadlink app to work when the siri-initiated command doesn't, that should rule out an issue with the mini itself.

Since I cannot intentionally reproduce the problem, my guess is that it has something to do with the initial state of the plugin after a homebridge restart. Though I don't know if the way that I create the synch issue is important (e.g. I could stand in front of the emitter, push the physical button, use the physical remote). I will have to see if I can determine a way to reproduce the issue...

[hepcat72]

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.

[mikellas1983]

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.

[hepcat72]

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...

[mikellas1983]

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....

[hepcat72]

Doesn't bother me.