You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update openHASP to the latest version - v0.7.0-rc4
Reproduce the issue and describe all steps
Describe the bug
I am using Lanbon L8 devices running v0.6.3 and v0.7.0-rc4 - both versions exhibit this behavior.
When I enable an output (whether from an object on the display or via MQTT), and then at some point the device is restarted via the MQTT "restart" command, the output relay remains on. This is essentially as I would expect, however when the device completes restarting the output is shown as off in both the UI and when querying the output status via MQTT.
Where it gets interesting is that in this state if I attempt to disable the output via MQTT, the request is ignored - presumably because the device believes the output is off even though the output relay is on.
From this state, setting the output on via either the UI or MQTT produces no change with the output relay, however the UI is now back in sync with the state of the relay. From here an attempt to turn the output off works as expected.
To Reproduce
1 - Use the default button code for an Lanbon L8 ... the pages.jsonl that I am using:
2 - Enable one of the outputs from the UI or via MQTT
3 - Issue a restart command via MQTT
Expected behavior
I am not familiar with the hardware design of these devices, so unsure if it is possible to query the output state on startup.
If it is, then expected behavior would be to query that and set the internal state to match that - this would provide a fairly seamless restart for the device user (in that all outputs/lights/etc remain in the state they were before the restart). (This is how my devices running Tasmota appear to function.)
If it is not possible to query the current output state, then expected behavior would be to set all of the output relays to the state that the device believes they are in (eg: all off).
Screenshots or video
I can attempt to provide this if the above description is not clear enough.
Thank you!
The text was updated successfully, but these errors were encountered:
Perform all steps below and tick them with [x]
Describe the bug
I am using Lanbon L8 devices running v0.6.3 and v0.7.0-rc4 - both versions exhibit this behavior.
When I enable an output (whether from an object on the display or via MQTT), and then at some point the device is restarted via the MQTT "restart" command, the output relay remains on. This is essentially as I would expect, however when the device completes restarting the output is shown as off in both the UI and when querying the output status via MQTT.
Where it gets interesting is that in this state if I attempt to disable the output via MQTT, the request is ignored - presumably because the device believes the output is off even though the output relay is on.
From this state, setting the output on via either the UI or MQTT produces no change with the output relay, however the UI is now back in sync with the state of the relay. From here an attempt to turn the output off works as expected.
To Reproduce
1 - Use the default button code for an Lanbon L8 ... the pages.jsonl that I am using:
2 - Enable one of the outputs from the UI or via MQTT
3 - Issue a restart command via MQTT
Expected behavior
I am not familiar with the hardware design of these devices, so unsure if it is possible to query the output state on startup.
If it is, then expected behavior would be to query that and set the internal state to match that - this would provide a fairly seamless restart for the device user (in that all outputs/lights/etc remain in the state they were before the restart). (This is how my devices running Tasmota appear to function.)
If it is not possible to query the current output state, then expected behavior would be to set all of the output relays to the state that the device believes they are in (eg: all off).
Screenshots or video
I can attempt to provide this if the above description is not clear enough.
Thank you!
The text was updated successfully, but these errors were encountered: