I have an ornamental tree with lights that I "upgraded" with a Magic Home WiFi dimmer. This is a simple single channel controller. I would like this light to come on every morning at 7 am and then shut off at 10:30 pm. I created a Simple Automation Rule to set the light to 3% brightness at 7 am and shut off at 10:30. What I am seeing, the rule runs ONCE, then never runs again. If I look under status of the rule, it does say there is a PENDING job for 7 am today, but that time has past, and there is nothing in the logs.
If I disable that rule, and setup a Rule Machine rule that only turns the light on every day at 7 am at 3% that works fine.
Any ideas as to where the problem is? I have other Simple Automation rules that I have had for months that work without issue.
Is it possible Alexa is messing with you? Check to see if youâve got a routine in Alexa that you originally might have set up to do the same thing as your Simple Automation, but got on/off backwards. Reason I ask is because, just before your 8:45 pm turn off, thereâs a turn on, and just after your morning turn on, youâve got that turn off.
Either that sort of a mix-up, or perhaps you have some auto off virtual switch in there, etc.
Look at the light in question, see what is listed for âin use byâ on the device page.
I checked Alexa and I don't have any "timer" automations set by her. I have 3 voice routines that turn a subset of devices on/off and good night routine that turns everything off before bed.
This device is only tied to 4 "in use by"
First is Alexa
Second is a routine that shuts everything off if I am not at home.
Third is the rule that is not working right.
Fourth is a rule that sets a subset of lights to come on 2 hours before sunset.
I saw that in your message, but it didnât say that you had later edited that rule to turn it off later.
Not quite sure what you are saying here.
Are you saying that you did one manual âoff then onâ, and then a second manual âoff then onâ, from the driver page, and it generated these 10 events?
I need to rework those MH drivers. I've been focused on some real-world projects over the last year, and haven't made much time to work on those. The nature of these (and a lot of TCP/UDP/TELNET) devices is that you need to poll them, and check if a hub is still connected to them. It's unfortunately CPU intensive, but can be toned down. My development versions have all of the sendEvent commands removed from everything but parse, among other changes.
I have a few ideas of how to make the TCP interface faster, but unfortunately the implemenation in Hubitat doesn't tell us if a device has disconnected or not (unlike my Python, and NodeJS version), so it needs to be polled for. That is, unless @gopher.ny can message me and let me know if that interface has changed in the last couple months to have some way of being notified of a non-hub-side disconnect. Chuck had said it wasn't on the block for implementation back in that era.
