I just purchased Hubitat and 8 Enbrighton Z-Wave Plus Smart Switches. I think I am in way over my head but having invested several hundred dollars, there's no going back at this point. All I want to do is turn the lights on in the evening and turn them off in the morning. That's it, nothing else needed.
Of the 8 switches, 5 switches paired with no problems using the Z-Wave inclusion tool.
Of those 5 switches only 3 of them work correctly. For each light, I created a Simple Automation Rule turning on the lights at 7 pm and off at 6 am. All 5 lights are coming on at the directed time but two of them are not turning off.
Regarding the two lights that are not turning off: After the lights have turned on, in the Device Commands section the variable isDigital reads true and the switch is noted as off even though the light is physically on. My conclusion is that Hub won't turn the light off because it thinks the light is already off. Events for these lights do not show that the light was turned on even though it was. I can click the Off comand, refresh, and the Commands section will show the variable isDigital as false, switch off, and the light physically turns off. These lights will again turn on at the next designated time but they will not turn off at the designated off time. However, neither the act of lights coming on or lights going off is noted in the Events.
I just can't understand why after doing the same thing for all 5 switches, that only 3 of them work properly. The two switches that do not work are within 10' of the Hub controller whereas the 3 functioning switches are quite a bit further away.
The 3 remaining switches could not be found using the inclusion tool. However, we were able to pair them using the SmartStart function but the status was stuck in pending. We saw the switches in devices so figured they were included even though status read pending. Deleted the pending status the day after running SmartStart. These lights are functioning the same was as the two problem lights described above. They are a little further from the controller than the 3 lights that do work so possibly this is a distance problem? We will get a repeater.
I have tried to read various help documents and posts but I don't understand most of what I am reading. If anyone can help with some simple "ABC" do this and that, I would be so appreciative!
I don't think Simple Automation Rules has any "optimizations" built in where it will not send a command (e.g., off()) if it thinks the device is already in the desired state (off), but... [EDIT: nevermind, this becomes an option after you choose a switch].
The first thing I'd normally try when an app isn't working as expected is to try the relevant commands on the device yourself. In the admin UI, go to "Devices," find a problematic switch in the list, and click/tap into its device page. Towards the top, you'll see buttons representing all the commands you can run on the device. These are the same commands an app, like Simple Automation Rules, would ultimately use, too. So, try the "On" and "Off" buttons to run those commands to see if that works as expected. If so, there is probably an issue with the app, not the device.
It sounds like you might have tried that already, but I just wanted to check! It's a bit odd that the events aren't recorded in "Events" (assuming you didn't manually set the number of events to keep to 0; the default is 100). Are these all the exact same model of device using the same driver on Hubitat?
If that works as expected, take a look at the app configuration. Do you have any restrictions or other options selected that might prevent the device from turning off?
I was able to turn the light on and turn the light off using the commands in devices. Both commands were recorded in Events this time.
I looked at the app configuration and compared it to the working switch and see no differences. I have not knowingly selected any restrictions or options. The "enable on/off optimization is on and that seems to be by default as I did not turn it on and it is on in all the Simple Automation Rules apps that I set up.
I did try excluding one of the switches that was not functioning properly and then including again. However, i did not do a manufacturer's reset to factory defaults as instructions advised not to do so unless primary controller is missing or nonfunctional. I added a new Simple Automation Rule but that did not change anything.
If your switches aren't reporting correctly, try turning this off. (I forgot about this option above--you have to select a switch first to see it, which I hadn't done in the automation I looked at when I wrote that post.) As you suspected, this will prevent Hubitat from sending an "off" command if it thinks the device is already off.
But then there's another problem of why the device isn't reporting correctly in the first place. Z-Wave Plus devices normally do (lots of older Z-Wave "classic" ones are infamous for not; a Lutron patent expired around the same time that Plus devices became more common). It sounds like most of yours are, and they're all the same device using the same driver (if not, check that and verify that it's the recommended one for your model as shown in this list: https://docs.hubitat.com/index.php?title=List_of_Compatible_Devices).
I clicked on, the light in fact, did turn on, and the event is recored on the event page. I then clicked off, the light turned off and the event is recorded on the events page.
I toggled off the "enable/ on/off" button and the hub turned it on and off once and recorded on the Events page. These two events were recorded on the Events page. The next time I asked to turn on/off, execution failed, I think because Variable isDigital was set to true. Sorry, a little fuzzy about this part. Since then I have executed on/off and the lights are functioning as directed but it is not being recorded in the Events log and the dashboard does not show the lights on, when they are on.
There are a few different pieces here that it may be helpful to troubleshoot separately:
the isDigital thing you see--and pretty much anything in "State Variables" (not "Current State")--is used internally by the driver. I would not consider it of importance here. It is an implementation detail whose behavior is not guaranteed to end users, but in general seems to be a way the driver tracks whether a recent "on" or "off" event (probably) came from the hub or the device (i.e., a physical event: someone touching the switch). Some drivers report this difference in an event (and some users like to automate differently based on that event), though it is not always reliable unless the device itself provides this information. It shouldn't cause problems for sending commandd regardless.
"Events" (the tab/page on the device page) shows you a recent history of, well, events, which are generally things that the device reports back to the hub. Sending a command, like "On" or "Off," will not necessarily generate an event--only if the device actually reports back that something changed. Your Z-Wave Plus switches are likely new enough that they did this, and in general, most devices do (if they are healthy on your network), but, again, some early Z-Wave devices are known not to do this unless refreshed/polled (something I would avoid if you could).
Dashboard is just an app that reads the device state and should reflect the same information you see under "Current States" on the device page. But since the device page would be the authoritative source, you can probably leave Dashboard out of this for the purposes of troubleshooting. (The "Events" page should also show you a history of previously-current states, so it's also an authoritative source.)
The "Logs" page may show you events (if you have "descriptionText logging" turned on for a device, that is generally what that means: event descriptions get logged to this), but a driver could technically do things however it wanted, so it's no guarantee anything actually happened. "Debug logging" will usually show you what's coming into the hub from the device (which the driver may parse into an event), so turning this on and comparing the working vs. apparently non-working devices' messages to the hub, if any (maybe one just isn't sending anything?) may help you--or someone here--see if something looks off.
From what you've said so far, I'd guess that your "Current Sates" aren't updating (because "Events" isn't, either) and the Dashboard is accurately reflecting this--it just happens that both are wrong. So debug logging plus someone familiar with Z-Wave may be the most helpful clues to figure out the difference. In any case, as long as on/off optimization is disabled in Simple Automation Rules, it shouldn't really cause problems in that app: it should send the command regardless of what it thinks the current device state is (so if it works when you do "off" from the device page but not when you think SAR should, there's likely yet another problem; this app has logging you can turn on that may help you figure it out, or you can share the entirety of the app's setup in a screenshot if you want to see if anyone has thoughts on its setup).
I'm wondering if perhaps the issues with inclusion created some ghosts...? These are phantom devices that can sometimes get created when a zwave device fails to include properly. They will show up in your zwave details page kind of like this... no in or out data, sometimes with a "discover" button, sometimes a "remove" button appears above refresh and repair. I suspect that is what @rlithgow1 is thinking as well...
Yeah, a lot of times when things don't want to include it's because of ghosts...It seems to be my go to anymore lol. Invariably we find them, exorcise them, and declare the DB clean...
Last night all of the lights turned on and 7 of 8 turned off this morning. That is progress! Toggling off the "Enable on/off optimization" button seemed to make the non-functional switches work. The one light that did not turn off, I turned off in Device Commands and have since been able to turn the light on and off via a Simple Automation Rule. So at this point, it seems that all lights are at least functional, but only 3 are functioning completely, i.e. they can be toggled via the Dashboard and an event is logged whenever those the lights are turned on/off. The other lights do not appear on or off on the Dashboard and there is no recorded event but at least they work!
We are leaving Tuesday on an extended trip so at this point I think I will leave the lights as they are since they are functioning and continue trying to sort all this out when we return. Thank you all for you help. Wish I had known what I was getting into when we purchased all this!
No ghosts, which is a good thing. A couple of your devices have somewhat weak signals but I doubt if that is it. When you get back we'll no doubt have thought of a few more things to try!
Honestly the enbrighten switches have always been problematic. You could try throwing a couple of beaming repeaters in there like an aeotec 6 or 7 to improve your mesh. Metal boxes are tough on signals. If that doesn't work, I would return them and get either Lutron (because they just farking work like tanks) or Innovelli reds...
