Get read too quickly after set

arachnetech / homebridge-mqttthing

A plugin for Homebridge allowing the integration of many different accessory types using MQTT.

Apache License 2.0

465 stars 104 forks source link

Get read too quickly after set #322

Closed gavc1 closed 3 years ago

gavc1 commented 4 years ago

Where a device has a set topic different from the get topic, eg "getOn": "home/3/37/1/0" "setOn": "home/3/37/1/0/set" It can take half a second for the getOn topic to reflect the setOn topic. This results in the accessory in HomeKit flashing state for a moment. Eg a Light is off and turned on, it flashes on, off then on again in the Home app.

Is there a way to delay the refreshing of the getOn after the setOn topic is called?

arachnetech commented 4 years ago

I may be misunderstanding, but generally mqttthing doesn't read a get topic: it responds to an MQTT message published on the get topic. Could this delay be caused by your accessory?

It would be useful to see what MQTT messages are being published at what times and from where when this happens.

gavc1 commented 4 years ago

Oh interesting, I am using this in combination with z-wave to mqtt https://github.com/OpenZWave/Zwave2Mqtt It seems to be a timing issue, where I will turn a light off using home app, it flashes off, then back on, then a second later updates to on. The history shows the value changing from false to true, when its turned on, then back to false when its turned off.

But the home app flashes on/off, in the video below I tap the light on, then it indicates the light is on, then off, then on. all while the light is on. Then I tap it off near the end and it works properly. It seems to be intermittent.

RPReplay_Final1602039195.mov.zip

dhritzkiv commented 3 years ago

I experience a similar behaviour with dimmer lights (Inovelli dimmers managed through OpenZWave/Zwave2mqtt). Possibly related to #122

If I have the lights on at 100%, then:

[in Home] turn them off to 0. The UI briefly (optimistically) reflects that they will be off
[In logs] the device sends updates to the mqtt topic about its dimming state. it'll log out several points: 86%, 50%, 34%, 0%, etc.
[in Home] the UI moves from the 0 value to try to reflect reflect each of these states (86%, 50%, 34%, 0%) in that order

This is particularly noticeable/bad when dragging the dimmer slider slowly, as it'll interpolate between each of the points.

I'm currently looking into debounce options in mqtt per topic (so that the last message will be sent, but messages received within a x ms frame will be ignored). Not sure how far I'll get. Perhaps this is something that could be implemented in this plugin, especially since debouncing on the server side may impact how confirmationPeriodms works?

arachnetech commented 3 years ago

I'll try adding the long-ago suggested feature (in #122) to wait a few milliseconds for incoming MQTT messages to stop before processing them. Hopefully this will help.

arachnetech commented 3 years ago

Debounce option implemented in v1.1.25.