Status update sends command

[Giannie]

Unless I'm mistaken, it seems that when the status of a device is updated using the status url a command is then sent off. This can cause an issue when the status url has slightly outdated data. Is it possible to prevent the status url from activating a command?

[rudders]

The status url is called to determine the status of the device - it assumes that call returns a value that can be interrogated. I'm not sure i understand what you are asking sorry? Typically the url you provide for status should not activate or deactivate the device - just request it's status.

[Giannie]

The issue is that when the status is found to be different to the current homekit status, it then changes the state and sends the related command. For example, if a device is on at startup the following is logged by homebridge: [Lounge Light] Switch received power http://localhost:5550/switch.lounge_lamp state is currently 1 [Lounge Light] Setting power state to on [Lounge Light] HTTP set power function succeeded!

This has the adverse affect of stale data from the status_url sending an on command. I would expect that a status update would change the registered state of a device without then sending the command related to the new state. In the best case scenario this is a pointless command sent and in the worst case it actually changes the state back when the reason it is different is because the api has not yet updated the state.

I'm not actually sure if this is technically feasible as it would require a way in which the state can be updated without sending the command to homebridge.

[NovaGL]

I don't believe its feasible as it needs to tell homebridge what the command is.

Does it actually run the on command for you?

As far as I have seen all it does is just set the value on Homebridge UI to reflect what is shown on the status.

Homebridge status can be wrong for two reasons

• You updated the value outside the Homebridge app (eg Eve) meaning if you turn a switch to off Homebridge will still show on (if that was the previous state)
• You have realtime polling on, but you keep your finger on the slider, this means the value is constantly in flux and will change to the value in the status.

EDIT: I just tested this myself and it does not send a command,

Set Light to on in Eve on another iPad set light to Off (confirm status url shows off), open and close Eve on first iPad, status is now changed to Off but Off command is not triggered.

[Giannie]

For me the off command is definitely triggered in that scenario. As I posted in the logs above, homebridge actually runs the command. Currently I use X10 automation which does not have a talk back feature to the server. This means that if the button on the plug is activated the actual state and the state stored by the controller can be different. I assume that in your situation this does not happen as Eve knows the current state of the device.

In my opinion, a status confirmation should only cause the state to update to the correct value, not send the corresponding command when there is a change. I would be happy to do this myself but I'm not all that familiar with js and don't fully understand yet how the status is updated for homebridge.

[NovaGL]

Are you using realtime polling? The only thing I can think of is there is a bug in the implementation of it.

[Giannie]

I am using realtime polling, yes

[oldschool777]

I think I am seeing a similar issue. I had a bug in my status URL that was returning the opposite value from the actual state, so when I used realtime polling, the commands were constantly sent turning the switch off, then on, in a continuous loop. It seems as though every time it polled the status, it then sent a command with the new found state. Once I fixed the status URL, the continuous loop of on then off was fixed, but occasionally, if the status URL took too long, I would get a response back of "NaN", instead of the expected 1 or 0, and that would cause the command to be sent, because it was not the same as the known value.

Ultimately, I would expect that a request for status would not initiate a command, even if the status is different from the last known status.

I am using this configuration:

        {
            "accessory": "Http",
            "name": "Office Automation",
            "switchHandling": "realtime",
            "http_method": "GET",
            "on_url":      "<my on url>",
            "off_url":     "<my off url>",
            "status_url":  "<my status url>",
            "service": "Switch",
            "brightnessHandling": "no",
            "brightness_url":     "",
            "brightnesslvl_url":  "",
            "sendimmediately": "",
            "username" : "",
            "password" : ""
        }

[d0n13]

I'm having this issue as well. I have a gate that is triggered by as a switch. The status url returns the state of the switch which is always 0 when the gate is open and only goes to 1 when the gate is closed.

I want the status to flick over to ON when the gate closes so show it's closed. I don't want it to issue a command which it currently does. So if it sees the gate closed it tries to set the state to ON which triggers the gate to open.

Is there a way to set the switch handling to avoid setting the state to match the status?

[aferrato]

someone has found a way to fix this? @Giannie? thanks

[NovaGL]

There was a PR recently. Has that changed anything?

[webpablo]

I am still seeing similar behavior on the most recent implementations of this plugin.

[antonioag95]

I think it is a bug because it only occurs when "switchHandling" is in "realtime" mode. I have this problem too!