Spurious Self Protection Shutdown On Smart Plug w/Power Monitoring

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. :slight_smile:

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. :slight_smile:

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? :slight_smile:

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.

The syncStatus if it says Pending Changes means one of the settings set on the device page is out of sync with the device (so it thinks anyway) so the next time you save or configure it will try to set it. This possibly happened when you jammed up the mesh and then tried to change settings, the commands may not have gotten through.

Dont know an exact time frame for braking the mesh. Its all going to be situation dependent. What probably happens is too many messages are flying around and some do not go through. After the devices do not get acks back X numbers of time they go into a re-routing panic mode and start spamming out routing queries. They will settle on a new route but if they keep having issues it will start again. Now you get multiple devices all going into this routing panic and it will just escalate and go downhill pretty quick. Normally if its just one device that has to re-route and the mesh traffic is not heavy it does its thing in a split second and you barley notice.

Was going to try and do that tonight, should be an easy fix.

1 Like

I haven't been documenting all the weirdness in this thread, but something interesting happened this morning.

I had a notification that the Zen04 plug for my wood stove insert turned off early this morning. The light was solid blue and the plug was on when I looked. The log showed that the outlet tripped, ie, physical 'off', on (bogus) high (but still apparently under the driver warning threshold) watts, 2265 watts. The log also showed that the plug turned itself (physical) on two minutes later. This is because I have auto on enabled for two minutes.

I did not have the Zen04 I had the water softener plugged into set to auto on, so it had to be manually power cycled after it tripped out with a blinking orange light. Auto on might have kept it running after a two minute break, but operationally it wasn't desirable, (I wanted it off after an outage).

So, keeping auto on could be an option for those concerned about a spurious trip....maybe. :slight_smile:

I might try putting S2 on several today, maybe without climbing a ladder, lol.

That power reading would be around 18 amps.
I have the limit for power at 2400 W, wasn't sure what it should be exactly since its for all the plugs including the zen15. Probably around 2000 maybe would have been better. Its on line 367 of the code if you want to change it.

Thanks. Strange there wasn't a high amp reading, just watts and the thing tripped. I have a notification set for when outlets turn off, which could be more critical than just extraneous bogus readings that can be safely ignored. It's a strange scene, man.

I put the 13 Zen04's on S2 earlier. Mesh has to settle in some.
Might do the 4 Zen15's tomorrow, although I've had no problem with them.

No overnight errors. So far, so good.

If this pans out I will have to seriously consider changing a lot of my devices over to S2 again. They used to all be S2 and I slowly moved them to None for performance increases. With the latest zwave firmware the performance may not be an issue anymore.

2 Likes

Is S0 still considered bad? I have two Aeotec devices, the home energy monitor and heavy duty switch, that paired only S0. I had to get a Z-stick involved to get it to none.

S0 adds 3x more overhead than no security due to the handshakes it does. It would be OK for something like a lock with little activity but for a chatty device it causes issues. The home energy monitor it would probably bog the mesh down on S0.

S2 adds a small amount of extra data for each transmission and a very long transmission would need to be broken up into smaller pieces (firmware updates take longer). There are some extra acks that can go back and forth as well. So it does have some more overhead but not near as bad as S0.

3 Likes

So is it possible that thanks to the encryption and inherent error checking that S2 packets that actually get delivered are less subject to corruption? :thinking:

If so that is a very useful thing to know especially in certain circumstances like @velvetfoot's . I'm not sure I would commit to putting all my stuff back on S2 though.

Kudos to @velvetfoot for investigating this and as always @jtp10181 for the continued support and work on those terrific drivers!!

1 Like

The drivers are great.

Well, it was too good to be true.

I got a warning about a shutdown this morning of a Zen04 on my water softener due to high amps.
The light was blinking orange.

It probably would've reset and re-energized itself if auto/on was enabled, but it's not. I think there would be multiple regens during an actual power outage because of a generator being on and off, and the stupid water softener not have a long capactive memory. I want to only do one regen, if I have to, at the conclusion of the outage.

Of course, I could control the regen times with the power plug through Hubitat, which is an idea. I don't have a feel for the approximate days between regens though, since it's currently based on gallons through its flow meter. Maybe I could figure it out. Hmmm.

Anyway, I'll be installing the Zooz power switch there today, and disabling overcurrent shutoff.

No other erroneous readings on the 12 other plugs though...so far.