Update status regardless of "known" device state

[robertklep]

I don't exclusively use Homekit to change the state for some devices. For instance, I have some KlikAanKlikUit switches for which I also use a hardware remote control.

This causes an issue with the Homekit app, because (I think) of this line:

 if (device.state[status] != variable && variable != null)

This assumes that device.state always reflects the actual state of the hardware, which isn't always the case. Because of this, the Homekit app may decide not to send a signal (because it thinks the device is already in a particular state) where in fact it should (because the actual hardware state was changed externally).

I would suggest always sending the signal, even though it may look like it's not necessary.

[sprut666666]

Is there a specific example of a problem? All test cases work fine for me) I did not notice any problems with statuses =)

[robertklep]

I can reproduce the problem using the method below. I forgot to mention that this probably only happens with "unidirectional" devices, devices that Homey can send a signal to, but cannot query for the current state of the hardware (in my case, 433Mhz outlets). In other words, there's not feedback from the hardware to Homey that its state changed:

• I turn on an outlet using HomeKit. This sets device.state.onoff to true in your HomeKit app. Homey sends the 433Mhz signal and the outlet is turned on.
• I use an external remote to turn off the outlet. Because the outlet is unidirectional, Homey isn't informed about this (i.e. the $state event never triggers).
• Homey, and your HomeKit app, still thinks that the device is turned on.
• I try to turn on the outlet again, using HomeKit. Because device.state.onoff is still true, and the new state is also true, your HomeKit app doesn't send the signal because it still thinks the outlet is turned on and it won't send a signal if the new state appears to match the current state (that's because of this code in updateStatus: device.state[status] != variable).

When I remove that not-equal check, everything works as expected, because your HomeKit app will now always send the signal.

[robertklep]

Reopening the issue because it still exists, and it prevents me from being able to use Homekit at all.

Homekit should never assume that the internal state that it keeps for a device it the actual, current state for that device. The code is trying to implement a shortcut to prevent an "unnecessary" update if it thinks that the device's state is already set to the value to update to, but that it based on the (false) assumption that the internal state is up-to-date, which might not be the case.

Here's another situation that I'm running into:

• I have three devices: A, B and C
• These devices are part of a device group. Device groups are virtual devices that can be used to switch multiple devices on/off as if they were one device. Let's call this virtual device "All Lights"
• I turn on device A, so the new state becomes:
  • Device "A" ON
  • Device "B" OFF
  • Device "C" OFF
  • Device "All Lights" OFF (device groups are only set to ON when they were explicitly told to turn on themselves; in this case, only one of the lights inside the group was turned on, not the device group itself)

Now I want to add a scene to Homekit, "Turn off all lights". This scene turns off the "All Lights" device, which in turn will turn off A, B and C.

I can't create such a scene with your Homekit app, because when the scene triggers, it looks at the state for the "All Lights" device, which is "OFF", and because of the aforementioned shortcut, it will not send the "OFF" command to the "All Lights" device. Because of this, device "A" stays turned on.

The shortcut is unnecessary and actually causes problems. When I remove the shortcut (remove device.state[status] != variable), it works as expected.

The Homeykit app doesn't have this problem because it doesn't have the shortcut.