I'm having a problem lately with some of my zooz plugs and this driver where they take a real long time to respond to a switch on/off command. Any ideas?
Its most likely a z-wave mesh issue and not the driver. As soon as the on command is called the driver sends the command out to the device. As soon as the driver receives a status update from the device it posts the event. There is only around a dozen lines of code for these actions, so not much to cause any sort of delay. You should make a separate post about the issue (and you can tag me if you want).
1 Like
Can you post a screen shot of the Z-wave detail page that shows the connections and speed?
If you have a C-8 hub that is located in a central location, most of your Z-wave devices should be connected directly to the hub at 100 kbps or through no more than one repeater. If your device is routed through multiple repeaters or you are have connections that drop below 100 kbps, then you need to figure out why. You might need to move your hub, move a repeater or add a new repeater/range extender.
I think I've got it mostly sorted out, after diving into "ghost" devices and plugging my Z-wave stick into my pc.
There are a number of devices with a few hops, even though I'm in an apt and my c7 hub is fairly central.
I do still run into the issue with zen25 devices reporting crazy unrealistic power (watt) spikes sometimes. At least they no longer report negative numbers via this driver. (I guess they do, but the reports are ignored?)
Since I do have a usb PC z-wave controller inaddition to my c7, is it possible to listen to the updates on the PC directly as well?
It looks like a good number of your devices are connected directly with the hub at 100 kbps. That is great.
You have some devices that are going through multiple hops, that could be a problem.
You have some devices that connect only at 9.6 kbps which is a problem, especially if you are in an apartment. Start with those devices and try to figure out why the connection is so poor.
Some things to look for in poor connections:
Does moving the hub slightly change the signal strength?
Does moving a device a few inches or a few feet change the signal? Of course, some devices like wall switches cannot be moved.
Do you have any devices located directly above or below the hub? While the hub antennas radiate uniformly in all directions around the hub, there are nulls directly above and below the antennas.
Check the locations of things that can block the signal. They can include such things as HVAC ductwork, water pipes, mirrors, steel doors, heavy furniture, water heaters, aquariums, etc. If switches are mounted in steel electrical boxes, these will block signals from certain directions. If you have a switch mounted on a wall outlet located behind a desk or computer monitor or near large speakers, the signal might be poor. In some instances, I have mounted repeaters/range extenders or smart plugs on extension cords to move them to a better location.
One thing you might consider is changing problematic Z-wave smartplugs to Zigbee smartplugs. I use Zooz Zen15 Z-wave outlets on appliances such as my washer, gas dryer and sump pump and they have worked well. However, most of my smartplugs are Zigbee. While Zigbee signals do not penetrate walls as well, the transmission speed is much faster so connections through multiple repeaters is not a problem like it can be with Z-wave. I never want more than one Z-wave repeater/range extender between the hub and final device unless it is unavoidable. I have a Z-wave motion detector on my back deck with a brick chimney directly between the hub and the sensor. The signals do not penetrate the brick, so sometimes two repeaters are needed.
While having a USB Z-wave stick is helpful in troubleshooting and removing ghost devices, I would suggest that you remove it during normal operation.
Because most of your devices are working well, you do not want to rebuild the entire Z-wave mesh. However, you might want to try a repair operation on devices that are not working well.
I moved this conversation over to a new topic since this is not directly related to the driver.
I see a few potential concerns with the Z-wave details. How long had it been since the last hub reboot when you took that screenshot?
Also, it looks like you have a few sensor and metering devices. These are the most chatty and if configured wrong can bog down the mesh. Can you give a brief overview of those device and how often they are reporting in (either timed intervals or X change in value).
This is with about a day of uptime:
What's considered too many reports for a z-wave network? I went mostly with z-wave as to avoid conflicts on the 2.4ghz band, esp as I have ~30 bluetooth thermometers reporting there already.
My main concern right now is how certain zen25 switches report anomalously high or low readings - spikes over 2000w or negative values. This ruins any wattage based automation I might want to run (like consider a device idle if its power has been under 40w for 20m)
I also have unable to configure them to stop sending me voltage/amp readings, or reports for the master device and not just the child devices.
Z25.7 and Z25.8 have a lot of route changes. This might indicate they are generating too much traffic.
There is no hard line, its too much when it is causing problems. Multiple reports from a device all at once or quickly and repeatedly can quickly bog down the mesh for a short while as it re-routes and recovers. Looks like your Z25.8 might be set to a very low threshold. Do you need to know every time the watts changes by 0.2 watts?
The spikes I think usually happen when you have a load connected that is converting voltages, like any sort of charging device, a wall wart, or any sort of transformer. I have noticed this on my ZEN25 where I have a 4-port USB charger plugged in. I know this excludes a LOT of devices, but that just seems to be the way it is. The ZEN04 seems to have similar issues but not as bad.
The Voltage and Amp readings you cannot turn off but you can just the interval to a few hours or longer so its not excessive. I also try to set the energy/voltage/amps interval differently so they do not all come in at the same time.
Z25 7 is one of my farthest devices.
Spikes: Do computers count? Thats most of my devices.
I do have the voltage/amp levels set as high as I can get, but they report more frequently anyways.
I don't generally need it reporting that frequently - was trying to debug the spike issue.
Is there a way to write the driver code to ignore a reading thats 5x the previous one (or another way to better filter out the spikes?) It makes it hard to trigger automations properly right now.
A PC is using a power supply to convert to 12VDC, so that is maybe what is causing the issues. Whatever hardware they are using to detect the power info must be extra sensitive to noise on the line or something.
If the spikes are always much higher than you would ever expect for your device(s), you could go to approx line 150 of the code and change the upper limit for power. This would impact all devices using the driver. That setting could also be turned into a per-device setting with more code work. One could also, as you asked, add code to ignore changes by a certain factor.
*line numbers might be slightly off from published version, this is my working copy
How can I manually debug/parse the z-wave packet being sent? It doesn't make sense to me that the meter would send a negative value.
2024-01-27 06:01:47.448 PMtraceZ25 8: parse: zw device: 21, command: 3202, payload: A1 22 04 C9 00 01 04 C9 , isMulticast: false --PARSED-- MeterReport(meterType: 1, precision: 1, scale: 4, size: 2, meterValue: [4, 201], rateType: 1, deltaTime: 1, previousMeterValue: [4, 201])
dev:3432024-01-27 06:01:47.043 PMinfoZ25 8: IGNORED METER REPORT of -1097.4W for power (below limit of 0W)
dev:3432024-01-27 06:01:47.039 PMwarnZ25 8: IGNORED MeterReport power (precision: 1, size: 2, meterValue: -1097.4 [213, 34], deltaTime: 4, previousMeter: 38.6 [1, 130]) payLoad: [33, 50, 213, 34, 0, 4, 1, 130]
dev:3432024-01-27 06:01:47.035 PMdebugZ25 8: MeterReport: scale:2, scaledMeterValue:-1097.4 (-1097.4), precision:1 (ep 0)
dev:3432024-01-27 06:01:47.031 PMtraceZ25 8: MeterReport(meterType: 1, precision: 1, scale: 2, size: 2, meterValue: [213, 34], rateType: 1, deltaTime: 4, previousMeterValue: [1, 130]) (meterValue: -1097.4, previousMeter: 38.6) (ep 0)
dev:3432024-01-27 06:01:47.027 PMtraceZ25 8: parse: zw device: 21, command: 3202, payload: 21 32 D5 22 00 04 01 82 , isMulticast: false --PARSED-- MeterReport(meterType: 1, precision: 1, scale: 2, size: 2, meterValue: [213, 34], rateType: 1, deltaTime: 4, previousMeterValue: [1, 130])
dev:3432024-01-27 06:01:46.955 PMtraceZ25 8: Found Child for endPoint 1 using data.endPoint: Z25 8 USB Hub (343-LEFT)
dev:3432024-01-27 06:01:46.946 PMwarnZ25 8: IGNORED MeterReport power (precision: 1, size: 2, meterValue: -1131.1 [211, 209], deltaTime: 4, previousMeter: 5.2 [0, 52]) payLoad: [33, 50, 211, 209, 0, 4, 0, 52]
dev:3432024-01-27 06:01:46.942 PMdebugZ25 8: MeterReport: scale:2, scaledMeterValue:-1131.1 (-1131.1), precision:1 (ep 1)
dev:3432024-01-27 06:01:46.938 PMtraceZ25 8: MeterReport(meterType: 1, precision: 1, scale: 2, size: 2, meterValue: [211, 209], rateType: 1, deltaTime: 4, previousMeterValue: [0, 52]) (meterValue: -1131.1, previousMeter: 5.2) (ep 1)
Zooz support claims
"The device itself is unable to report negative values since they don't have a physical representation (I think we can all agree on that) so there must be something happening during the data processing where the information reported by the device is represented by the software as negative values. We have seen that occasionally with groovy based platforms but haven't been able to replicate it on other systems.
Does the device report power consumption accurately for you now with the updated driver?"
(and they suggested I use your driver)
Guess you are going to make me dig out the Z-Wave docs.... please hold.
1 Like
@jolly
meterType 1 just tells us it electrical.
Scale tells you what type of meter it is, so not relevant.
Precision tells you how many decimals (where to put the decimal)
Size is the length in bytes of the meter value (so you know how to parse it, the HE functions do this for me)
The meterValue, the spec says it must be encoded using signed representation
So your example meter value is [213, 34] (this is 0xD5, 0x22, or 0xD522)
0xD522 = 54562
Based on the table in the specs, a 16-bit maxes out at 32767 then it rolls over to negative numbers.
To convert from the raw unsigned value to signed we first need 256^2 (the size) = 65536
54562 - 65536 = -10974 (negative)
Precision is 1, so we back in 1 decimal giving us.... -1097.4 W
Even if we said it is reporting an unsigned value, then it would be reporting 5456.2W which is obviously outside of the range it can handle.
You can give a link to this right to Zooz, they will trust my info.
Also, just to confirm the HE function is not parsing the values incorrectly I found the D5 22 in the raw payload in yours logs as well.
2 Likes
Zigbee supports up to 64 devices connected directly to the hub. If you have repeaters (smart switches generally function as repeaters as well as switches), you can have many times more. Your temperature sensors do not come close to maxing out the capability of Zigbee. I have 67 Zigbee devices in my mesh and it works well. I have 15 smart plugs that function as repeaters.
Thanks so much!
Any idea why no one else seems to be reporting these sorts of issues with the zen25's?
A lot of people just have the power reporting turned off, or they stopped using them. Sometimes it can spam the mesh and cause delays, which is sort of what you are possibly seeing.
There is a reason I added the negative and very high value filtering... its a known issue.
1 Like
Is there a way to retell the z25 to use the hubitat as the primary controller? I made the mistake of updating the firmware via my usb stick, and now it seems to not automatically send reports back to the hubitat unless I manually tell it to refresh.
I'll have to think about the best way to write the logic to filter out spikes, but not filter out when a device actually gets turned on.
Running configure on my driver should set the LifeLine association back to normal if the device is still paired to the hub. You will see some messages about it if you enable debug logging before running configure. Using PC Controller as a secondary should not have changed that though. Or did you reset and pair the device to the USB stick directly?
I correctly excluded the usb stick, and the switches were always paired directly with the hubitat.
Whats the difference between configure/refresh?
Tried configure a few times without much luck.
Having some weirdness between the main device and the child:
I hit configure on the main, and also ensured reporting was enabled.
Noticed one of the child switches still claimed there was power usage, even though the switch was off, so I turned the switch on.
The main device logs show the child being turned on, and power usage.
But as far as the child can tell, its still off, and no change in power usage.
It should be reporting every minute, so even if one was missed somehow, I'd still expect to see new info.
Everything looks like the LEFT is still turned off to me. I don't see anywhere in the logs where it reports that it is on. Did you verify in person if it is on or off?
Have you tried power cycling the ZEN25?
