I think there might be a bug in the Sinope Dimmer driver or maybe I am doing something wrong?
Here what's happening. I have a rule to turn on the light if the mode is not "Away". Between 4:00 PM and 8:00 PM the level is set to 100% after 8 PM, the level is set to 19%.
The problem is that if the action runs for the between 4PM-8PM part, the level is set to 100% and almost right away, the level is put back to it's last level before it was turned off last.
I also created a simple rule to just set the level to 100% at 4:00 PM and I had the same issue, so that's why I thing the problem might in the driver itself.
Also, in the driver's preference section, the log debug switch doesn't stay ON. Every time I turn it ON, it's back to OFF the next day.
Is it possible you have another app or rule interacting with this dimmer? Check the "In use by" section on the device page. You can disable an app if you want to test something without totally removing it. You can also see what happens if you send commands directly from the dimmer's device page without going through a rule in case you're worried about something in your app/rule, though I don't see anything in this particular rule that would cause this. (The rule itself does seem to be a bit odd, triggering every hour instead of in response to events that might make your desired conditions true or not, but there's nothing inherently wrong with that.)
As for the debug logs, that's normal. With all stock drivers (and, IMHO well-written community drivers), debug logging on devices stays enabled for the first 30 minutes after enabling (including after device installation), then gets automatically disabled. Most will log that information too. This is because debug logs are often only useful if you're troubleshooting a particular problem, and even then often only if you either are the developer or are working with the developer. In this case, it might not hurt to have it on when this problem happens, but I'm not sure it will show anything revealing.
Not ruling out the possibility of a driver oddity here, but I don't think I've read about this anywhere else, so my hunch is that something else is happening. The guess above is the best I have for what that might be at the moment.
Could Google home mess with this device like this? I guess I will remove this device from the Google home app and find out!
Also, I have the same issue when I use the "set level" button command directly on the driver's page. It does it only the first time after its turned off. Still possible that it's related to Google home though....
I took Google home out of the equation and I have the same issue. This morning, I set the level to 100% directly from the driver's page and it went 100% then 18% right after.
Are you using those rules to turn the lights on also or just preload a dimmer state? Out of curiosity could you set it to 99 instead of 100? Some zwave dimmers don't play nice with 100.
It's to turn the lights ON as well. I read somewhere that setting the level turned the light ON too which seem to be true. Should I turn the lights ON than set the level? I will try the 99% trick and see!
Some devices can handle setting the dimmer and not turning on the device. I was just trying to understand the logic you have in your rule as to what you were trying to achieve. You have it running around the clock on the hour but only using 8 hours. There's probably a better way to structure the logic.
Any standard-behaving light on Hubitat will turn on with a "Set Level" (or "Set Color" or "Set Color Temperature") command unless a matching pre-staging option is offered and enabled as it is for a few devices, but it's still off by default. The "99" thing is usually a Z-Wave issue, where the level per Z-Wave spec maxes out at 99, while Hubitat's model assumes 100. Most drivers handle this gracefully, sending a 99 to the device when the user puts in 100, though exact behavior may vary here. Since the Sinope is Zigbee, it shouldn't have this problem, though it couldn't hurt to play around with other values just in case.
One thing you could try that I don't see mentioned yet: completely remove and re-add the device. If you don't have it in use by many apps/rules, this shouldn't be too time-consuming; if you do, unfortunately, it may be, since you should remove the device from any apps/rules it's in use by before un-pairing it. But if you do this, you could try seeing what happens right after pairing before you add it to any apps/automations: does the behavior persist? If so, there might be something odd with the device or possibly driver. If not, it must have been something on the hub/automation side, but exactly what would be hard to say.]
Oh, and if you switched to the Sinope Dimmer driver manually, be sure to hit "Configure" after you change to that driver. You could try that now too just in case it makes a difference, though I doubt it. But at least it's easy to try.
I changed the rule to set the level to 99% instead of 100%. If that doesn't work I will do what you suggested and remove / re-add the device. There's only one app/rule using it now....
