I have another observation on the Zen15.
I'm reporting only power.
I disabled threshold reporting, and only enabled percentage.
It worked fine, until the power gets to zero, which happened on my washer.
Any percentage of zero is zero.
So now, if I still want to do percentage, I bump up the watts threshold until just below the usual max.
That way, threshold isn't a factor while I tweak the percentage.
My apologies if this isn't the correct forum for this question.
I recently added a ZEN14 and your driver to control some string lights. Everything seems to be working okay except the power meter functions. I'm not sure how to use that. Currently it seems the feature is disabled.
How am I supposed to enable that and also how do I display the values in my Dashboard?
Sorry the ZEN14 is not power metering. Only the ZEN04 and ZEN15 have power reporting.
1 Like
Ahh. Okay. No worries. I was just wanting to geek out. Not really something I HAD to have. Thanks for the quick response.
Preference Manager doesn't seem to work with the ZEN04, except for common things like logging. The screens on PM seem to be geared towards the ZEN15, that is, the parameter numbers are ZEN15 specific.
I assume this has something to do with the driver's quality to be a 'swiss army knife'. But I thought I'd bring it up.
What's nice about the Preference Manager, base on my observation about turning logging on and off, is that the driver page actually gets changed, and it's not a temporary thing that you have to remember what you did.
@jtp10181 , would you know anything about the preference manager comment above? I've taken to globally changing some parameters, and PM is nice because the changes are permanent, rather than getting wiped out with a Configure, or whatnot? No big deal though.
@jtp10181 ... I have a ZEN14 controlling two lamps, that are bound to a wall switch using switch bindings. I seem to have an issue where the status reflected in Hubitat (on/off) gets out of sync with reality on one or both outlets ... and then rules or dashboard tiles can no longer control the confused output .. they just seem to get stuck. If I go into the child devices and refresh them to poll the device and re-sync the state of the confused output, everything starts working again. Sometimes its both, sometimes it's just one or the other and if it's only one, the other continues to work just fine until it eventually gets stuck too. I updated to 1.1.2 when you released it hoping that might have fixed the issue, but it had no impact.
This is a very frequently repeating issue so if you have any suggestions or thoughts, I'd appreciate the ideas.
Post a screenshot of that device from the Zwave Status page.
You could also turn on debug logging and try to get some SCREENSHOTS of logs when the issue is happening.
The On/off commands should not be blocked (by the driver) if the device is already in that state, so if the device if OFF, but the hub thinks it is ON, and you press the ON button on the device page, it will send an on command to the device regardless of its current state.
However, the switch bindings app might be blocking that from happening. I would put the actual outlet child devices on your dashboard, not the switches, which should allow you to directly control the outlets without having to go refresh them.
Do you need two-way sync from the outlets back to the switch? Do you control the outlets directly via other methods? Voice commands, etc..? Does anything happen on the switch depending on the state (led maybe?). Reason I am asking, is the built in Mirror app might work better than switch bindings in this case.
When the outlets are stuck, sending a command of the same state from the device page does change them back to the expected state, I will need to test to see if that also restores the functionality elsewhere.
The wall switch is not in the dashboard, only the child devices. When they get stuck, the dashboard tiles just switch to a permanent hourglass when commanded and nothing ever happens.
In this case, the wall switch is more of a remote … and if it’s turned on or off, both lamps respond. If the “lights” are commanded through Alexa, both respond. However, in the dashboard, they are controlled independently and if either is controlled on, the wall switch also changes it’s state to on.
I will attempt to get some logs over the weekend.
So do you have the wall switch attached to the parent device then or both child devices?
Also get screenshots of the zwave details page. I am suspecting the devices change states but the response never gets back to the hub, and thats where the problems start.
Nothing is bound to or references the parent device, the child devices are referenced as individual objects.
Sending an "off/on" from the device page does re-sync things like refresh does and everything works again ... but in either case, it only works for three-five cycles before it breaks again.
Here are logs when it works turning off ...
The following attempt, only one turned on ...
And after the only the one was working ...
In the events, one child shows the events, while the one in the stuck state doesn't even reflect them ...
And for the details, I have a C5, so they don't have as much useful info ...
Right now, both children are physically off, but the child devices reflect them as being on. The parent correctly reflects its overall state as off.
Lastly, the children are using "Generic component switch" as their type ... just to be sure that is correct.
It may be worth noting that prior to the ZEN14, I had two separate dimmer modules in this room as part of the exact same logic and it never failed ... but when we replaced the lamps with ones that use plug in transformers, I moved the dimmers elsewhere and replaced them with this single on/off module to avoid damaging the transformers.
Looks like you turned on debug for the switch, probably dont need that. Did you have debug logging on for the parent ZEN14 device? Looks like it was only enabled for the child(s). I think the parent debugging would show more useful info. You could also edit the driver code and go all the way to the bottom to enable the trace logging which will log pretty much everything.
I am also suspecting when it does miss a report from the device, the switch bindings app is what is causing the problem as it does not "force" the command, it only sends it if there is a state change (based on the device state). Toggling the wall switch on/off should get it sync back up through switch bindings I think, as then it would send the commands out to both devices. Not a solution but maybe a temporary workaround.
Debug logging is/was on for the parent and both children.
Once the sync is broken, the only resolution is the device page … the wall switch, and Alexa are both connected through the bindings, so there is a possibility that there is a relationship… however, triggering the dashboard tiles is closer to direct on/off commands from the device page than it is to the behavior of the bindings app and those don’t work either.
I’ll look into enabling the trace tomorrow and let you know what I find.
Your first log you posted before only contains one entry from the device in question 1144. If you are using my driver and the parent device had debug on there should be a "componentOff" log from the parent device right away any time "off" is commanded on the child device. Then the parent sends the zwave command to the device, and the device should respond, resulting in more logs.
As far as nothing else working besides the device page when it gets stuck, the driver is doing its job, the dashboard and the switch bindings app are what is causing the problem in that case, not the driver.
It is version 1.1.2 of your driver and debug is confirmed on for the parent ...
I will investigate the other apps, but, as I mentioned, this exact setup worked fine with two separate dimmer modules ... I didn't start to have issues until I swapped them out for this device. I think your logic partially sound on the "only sending on state change" statement ... but if that were the sole case, repeated activity would eventually reset things because the applications would think there was a state change on the next cycle.
While it may not be the driver, it could be the firmware, or as you mentioned messages simply not getting back to the hub for some reason, but the fact that somehow they are getting out of sync is the root of the issue here, and I don't think its the apps, but perhaps the timing around the way the app is triggering both children of the module simultaneously?
What is the firmware on your ZEN14?
The parent debug logging will time out after 30 minutes, not sure if that's why you are missing that logging? Or was it filtered out? I don't see any logging from the parent device in your posts.
Here is logging of an on then off from the child device with all logging enabled on child and parent.
Also made a quick group to test turning both on/off at the same time. Also works fine and you can see much more logging than you are showing.
I do see one possible issue, if a child is off (or on) and I send the same command to it again, the plug only reports back the parent state and not the endpoint/child state. I am also noticing the parent state is just mirroring whatever that last endpoint change was, if I turn one ON the parent reports On, if they are both on and I turn one off, the parent reports off. Makes no sense really. I think Zooz changed something with a firmware update because I don't remember it doing that when I made the driver.
I don't really think any of this would be causing your issue though. At this point without more logging all I can suggest it is a z-wave mesh or device issue and the reports are not making it from the device back to the hub.
Hi.
The filtering of weird values on the Zen04 is working great.
I usually get them from plugs out in the garage. At least they show some signs of life with the weir readings, lol.
However, I just got a really high energy (kwh) reading.
I wonder if you could also apply a filter to kwh?
What was interesting is the next reading was right on track with the correct kwh. So, you actually can see it getting 'lost in translation'.
One more question: Have you screened out negative voltage readings? I got one, and the only way I noticed was the low reading on the device driver. It could be I don't have the latest driver since I bifurcated 04 and 15 because of the preference app.
Thanks.
version 1.1.2 should be catching and ignoring negative readings.
I did not put a limit for kWh because it technically has no limit if you never reset the stats it will just keep going up forever.
1 Like
The firmware version on the device is 1.20 according to the stamp on the bottom.
I don't think there is a mesh strength issue ... the mesh in my house is pretty dense - there are 95 z-wave devices in my network, and at least 85 are actually repeaters. No other devices exhibit any issues remotely like this.
What is the logging that you need? the trace logs that you mentioned turning on in the driver?
