I have a feeling your mesh is being overloaded from all the ZEN25 reporting so a lot of stuff is getting lost. Your Z25.7 device in the details screenshot up above has a lot of route changes which means it is having issues pushing all of its reports back to the hub in a timely fashion.
Would it be useful if you could set a max power per each device and then it would filter out anything higher? Instead of trying to do some sort of a factor.
I set the max to 1000w, and will monitor. Will try and figure out if its reporting other spikes that are less than 1000w. I think I've only got one machine that could actually pull 1000w anyways.
I also modified the driver to stop reporting voltage/amps, as I can't think of any practical use for that info.
Just so you know, the device is still reporting it, so all you are doing is suppressing the info. Does not really gain much performance wise. But if it makes you happy go for it!
Agreed, unless I want to go reverse engineer at their firmware.
Is there guidance or best practices for update frequency or expected packet transmission rate on zwave networks?
What would be useful: I noticed there's an option to track high low states but the only tracks it for the master not the child devices which is way more useful for dual plugs.
Minor FYI: the variable name is slightly different between the MCP and the normal advanced driver.
That would require a custom child driver that had those attributes, I did not make the effort since I was not sure what anyone would do with that info.
What variable? The attributes looks to all be the same to me, unless you are talking about something internal in the code.
Ah, did not realize that was a seperate driver needed, yeah prob not worth it.
Huh, I swear I saw them named two different things.
Mostly was trying to use the Preference Manager to bulk set the settings, the Z15 devices showed up with the HighLow option, not the Z25's -
Due to my drivers having dynamic parameters it messes with the way the Preference Manager app works, it is not designed to handle dynamic settings. In order to fix you would have to install the driver a separate time for each type of device you wanted to use it for (and change the title of it), switch the devices to those separated drivers, then re-scan with the prefs manager.
switch (meter?.name) {
case "power":
// New check for val over 75 and within 400% of the previous value
if (val > 75){
if (cmd.scaledPreviousMeterValue != null && (val >= safeToDec(cmd.scaledPreviousMeterValue * 4))) {
logWarn "IGNORED MeterReport meterValue: ${cmd.scaledMeterValue} is >75 and > 4x prev: ${cmd.scaledPreviousMeterValue}, deltaTime: ${cmd.deltaTime}"
sendEventLog(name:"warnings", value:(device.currentValue("warnings")?:0)+1, isStateChange:true, desc:"IGNORED REPORT of ${val}${meter.unit} for ${meter.name} " + "${meter.unit})" + "Not within 4x of ${cmd.scaledPreviousMeterValue}", ep)
return
}
}
break
default:
break
}
I added this function, which mostly works, except it also triggers when the scaledPreviousMeterValue itself was invalid.
Not sure what you mean? It is value in the cmd object that gets parsed by the hub and passed to the zwave functions. I would need to see what function you are adding that code block to.