there isn't unfortunately
Thank you for confirming why I switched drivers.
Any chance of adding a Flash command to the Sengled driver?
Also if it's not too much trouble, please check the Advanced RGB Zigbee driver's "initialize" function to see if it could possibly turn on the bulb.
As noted by @brad5 above, it’s simple to have a rule triggered on systemStart and having an action to set the bulbs appropriately.
any driver having an initialize function will have Initialize as a displayed command in the driver details.
I don’t have the candelabra bulbs, but using the Advanced RGBW driver with Sengled E11-N1EA doesn’t turn the bulb on when the hub is rebooted.
This is expected behavior after hitting configure with this driver btw as Mike alluded to.
Yeah you right! The driver does not have an Initialize command.
Thank you for checking and posting this information
I prefer finding out why, but If I can't find it, an RM workaround is my choice.
2 Likes
Falling deeper into Alice's rabbit hole, I may have found the Wonderland of unintended consequences. However, I did find the cause of the lights going on, but not the why.
Also it was not only my Sengled Color bulbs turning on, but some plain white only Sengled bulbs on switches and other drivers.
In the following RM disabling the second statement stops the lights from turning on at reboot. The first disabled statement is a workaround for a device occasionally reporting 531F at reboot, triggering an HSM high temperature alarm, including my siren. The remainder of the rule refreshes my always on dashboard displays at reboot.
@mike.maxwell @bravenel
Any idea why RM "HSM Arm All HSM Rules" turns on the lights?
Depends on what HSM Rules you have, doesn't it?
I rely upon your expertise, but this may be an HSM bug.
After extensive additional testing I found it is the first disabled rule "HSM Disarm HSM Rule: High Temperature / Fire" above that is turning on the lights. Also when I click on the HSM "Disarm this Rule" below, the bulbs turn on.
The HSM rule in question
1 Like
You need to capture the logs of that HSM Rule when it turns on the light. Is it possibly being fired due to a transient high temperature report that happens at startup, as you described above?
I can recreate it at any time by clicking on "Disarm this Rule"
All devices report ~70F
Logs please. HSM Rule captures the state of lights at the time of an alert, and disarming cancels the alert and restores the captured state of the lights.
Look at the Application State on the App Status page for prevLights. Those are set by the rule alerting, and those are what is restored.
Sorry where are the logs and do I need to set on any trace switches?
Please show me the Application State from App Status for prevLights. Gear icon.
Rule Armed, most lights off
After rule disarmed. Looks same but all lights are now on
Next release will clear those out when the rule is armed, and that should solve your problem. However, if the rule alerts, it will restore the lights when it is disarmed to the state they had when alerted.
You could clear it up now by turning off all of those lights, and causing the rule to alert. One way you could cause it to alert would be to create a virtual temperature sensor (or omni sensor), add it to the rule, and set the temp to force the alert. Then it would capture the lights as being off. Subsequent to that, disarming would not turn them on.
2 Likes
Fix for this is now released:
2 Likes
Thank you. Installed 2.3.1.132, problem solved.
3 Likes
@bravenel
Just noticed when clicking on "Disarm this Rule" the lights now shut off.
This would be correct when the rule alerts, but unexpected when there is no alert.
An unintended side effect. I'll put in a fix for that.
4 Likes
