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
When turning on the light, the command is sent from the plate to HA to turn on the light. If you are using the openHASP custom component to set state values for buttons, they can sometimes lag out and cause small loops.
Use plate to turn on light, MQTT message to HA, button state changes.
HA sees that the light is OFF, so sets button state to OFF, triggering another MQTT message.
HA receives the ON command, turns on light, sets button state to ON.
This causes the light to flicker a few times, until it finds a normalised states. Unfortunately it can finally decide to settle in the OFF state, so it is impossible to turn lights on and keep on using the plate in production with this bug. Usually a reset of the plate (remove from wall and reconnect) can resolve this. Will usually occur a few days later.
To Reproduce
I think this could potentially be caused by a delay caused in WiFi messages and MAY be more pronounced the further your plate is away from the WiFi router.
Provide a small, independent code sample that can be used to reproduce the issue.
Format the code like this:
Noting that the use of GROUPID will remove this issue (I will start to update my jsonl pages), unfortunately until the last brightness is passed through (issue:99) the lights turn on at full brightness which is not a great solution for production use cases.
Screenshots or video
20210831_075526_1.mp4
The text was updated successfully, but these errors were encountered:
Perform all steps below and tick them with [x]
Describe the bug
When turning on the light, the command is sent from the plate to HA to turn on the light. If you are using the openHASP custom component to set state values for buttons, they can sometimes lag out and cause small loops.
This causes the light to flicker a few times, until it finds a normalised states. Unfortunately it can finally decide to settle in the OFF state, so it is impossible to turn lights on and keep on using the plate in production with this bug. Usually a reset of the plate (remove from wall and reconnect) can resolve this. Will usually occur a few days later.
To Reproduce
I think this could potentially be caused by a delay caused in WiFi messages and MAY be more pronounced the further your plate is away from the WiFi router.
Provide a small, independent code sample that can be used to reproduce the issue.
Format the code like this:
Telnet Logs:
Logs.txt
Expected behavior
Lights to not flicker and to turn on.
Noting that the use of GROUPID will remove this issue (I will start to update my jsonl pages), unfortunately until the last brightness is passed through (issue:99) the lights turn on at full brightness which is not a great solution for production use cases.
Screenshots or video
20210831_075526_1.mp4
The text was updated successfully, but these errors were encountered: