@jtp10181 , no other high power readings around 3:39 PM. That 0 was in all liklihood after it turned itself off. There was a 3.2w reading at 3:15.
We'll check if there's a way to write in some kind of code into the firmware to ignore these high readings but we suspect they're generated by the power supplies used in these applications. When choosing a power supply for one of our other products last year, we did a lot of detailed testing and found that most of the power supplies sold today produced very unstable current values and many were unsafe to use. That means that even if we tell the plug not to report these values, the electronics will still be affected by the current spikes and the device may fail over time if used with similar power supplies. We do recommend the ZEN15 Power Switch for most inductive loads since it's designed to handle motor loads specifically. @velvetfoot please send me a message if you would like to try the ZEN15 in that location to see if it works better for you.
I also need to say here that wireless control of any heat producing appliances or devices is not recommended for any of our products and any operation of such devices should be conducted under supervision at all times.
4 Likes
Hi @agnes.zooz , I'll send you a message. Another advantage of the ZEN15 is that the protection can be shut off, so that mission critical stuff, like a sump pump, won't get erroneously shut down. What are the specs, anyway, for overcurrent shutdown for the ZEN04? It's not noted in the product literature.
I didn't know small power supplies could create large current flows like this. I'll have to read up on it. I was thinking maybe some kind of stray signals from a nearby device creating a problem.
Just to clarify, this issue, where the plug shuts down on overcurrent protection, is different than the other issue where crazy numbers somehow are reported.
Thanks.
@agnes.zooz according to the post I linked up above, his water softener drew 142.41 Amps and then the device shut itself off presumably for over current protection. If this was happening for real I would suspect this device would also pop the circuit breaker when plugged directly into the wall since those will trigger for anything over 15-20amps depending on the breaker. The power pack is only rated for 0.59A, so this seems like a totally bogus report from the device.
I have similar "wall warts" plugged into some Zigbee power plugs that only report power, and I have never seen any excessively large power values (which would indicate a large amp draw if I did). I have one Zigbee plug on a Sump Pump as well which is rock solid and tells me when them sump runs. I would be scared to use a ZEN04 on the sump knowing this data that @velvetfoot has acquired showing it could just lock itself out at any time.
I already wrote code in the driver to ignore the unreasonable values, but the main problem is that the devices goes into a lock out mode for no reason and the user cannot disable that or restore the device remotely.
We did also find some of the bad reports appear to be corrupted messages but this one in particular is definitely legit since the device sent it 3 times over 3 hours and also the device went into its lock out mode tells us that it thinks there was an over-current problem. This is not the first time he has had the over-current lock outs from seemingly small loads.
3 Likes
Thank you for the additional notes, we'll definitely look into this and will try recreating the issue in the lab to see how best to address this.
3 Likes
So it is just two of the ZEN04 you seems to be having problems with mainly? Even after moving it to another location, still getting bad readings?
This last one is a toss up, it looks legit because the deltaTime is exactly one hour. But the Precision is usually 2 for voltage. It is possible the device adjusts the precision based on how high the reading is, so possibly it thought it got 3718V and decided in order to send that in the size 2 packet the precision needed to drop to 0.
I have some similar wall warts. In fact I have a ZEN17 sitting here I can plug into my ZEN04 and see what happens.
That's funny. I too have a Zen17, and also a Zen16 on the coffee table next to me. The black wall wart is hardwired. Perhaps I'll wire the Zen16 into it and plug it into the Zen04.
Two problems in the same place. I returned one with a solid orange light and trip, as I recall. The last one is the blinking light and trip.
Here is a shot of my outlet warnings dashboard. Test04 is the old water softener.
Apparently that water softener power supply does not play nice with the ZEN04 internals.
@agnes.zooz that voltage report he just posted looks like a legit message from the device. There is no way it actually picked up 3595V on the input.
@velvetfoot I don't suppose there is another circuit you could plug into with the water softner temporarily just to rule that out? I am really thinking the ZEN15 will take care of this though.
Let me be clear: the Zen04 did not trip; it just had a warning.
There's only one circuit down there for outlets. Perhaps I could tie into the boiler convenience outlet. But to drag an extension cord down there, and wait for it to happen...I don't know.
As I said earlier, there's another Zen04 down there with a power strip hanging off it that goes to 300 watts sometimes, including a large 24v landscape lighting transformer, that has no problems, knock on wood.
@jtp10181 , is it possible you can make the warning text visible? It just reads null now:
Something like this would be useful, in case it's no longer visible in the logs:
In your second example is that pulling the description of the event? I should be able to add a message to the warning event similar to what goes into the logs, I never thought of doing that.
1 Like
Sitting here, just got a notification.
This DID NOT turn off the plug.
A new personal best of 15449233293326 amps. 
1 Like
We're checking with the engineers how the device would create the value on its own without any physical events and hope to get to the bottom of this soon.
1 Like
That last one with the high amps look bogus because the deltaTime and previous meter are blank.
I wonder if it would be worth pairing one of your problematic ones with S2 to see if the corrupted messages continue? Supposedly S2 has better error checking and would be more likely to ignore corrupted messages.
Zwave at 100kbps or any speed S2 will use full CRCed packets instead of just simple checksums. I use S2 for any device that supports it for this reason.
I started off fully using S2 on everything and slowly changed all my switches to None. I noticed everything seemed to be snappier without security. I had one motion sensor and one door sensor that were still on S2 and they were acting up, switched those to None a few weeks ago and they seem to be working better. I suspect it might be a firmware issue on the device itself but for me the None works better most of the time. Anything critical or entry point I do keep on S2 for security and message integrity.
Thanks, I knew it was different just was not sure what the difference was exactly.
@velvetfoot This makes a good point, you should post the info from the Zwave Status table for some of the ones that seem to be getting corrupted readings. If they are not at 100kbps they are much more susceptible for corrupted messages since I believe you are not using S2.
All my devices have no security. Doesn't S2 require the pin written in tiny characters on the device? That'd be fun.
Last night I was experimenting with the parameter settings on the ZEN04's. First, I adjusted all 14 of them to be at the max for all reporting, thinking I would use a rule to refresh them all every minute, or whatever. The rule is easily made and modified. You pointed out that excessive polling could choke the mesh, but what's 'excessive'? Things choked up.
I also stopped that rule and adjusted the frequencies on all the ZEN 04's to 1 minute, figuring to let the devices spit out the info without polling. This also choked things up.
I couldn't turn many devices on and off, there were many (I saw a '16", I believe) pending sync changes, and I was getting warnings galore.
What does 'pending syncchanges', exactly?
I used a rule and the fine parameter attribute you so thoughtfully created to quickly, and temporarily change the frequency parameter to 60 minutes on all 14 devices. Things are pretty calm this morning. No overnight warnings. Did I say I like the parameter attribute?
I might try S2, maybe on a couple. I could live with slower reporting, but not mesh choking.
The usually outlandish readings as a possible result of bad comms seems to be a totally different issue than the spurious self protection shutdown. Your filter gets rid of most of them, but I'm sure some 'believable' readings sneak through.
And @jtp10181 , do you have a time frame for putting some text about the warning? It would be nice to see what the readings are from the notifications I've been sending myself. This way, I'll have them in case they disappear from the logs...for whatever it's worth.
Thanks again for your efforts.
