How to interpret Developer Z-Wave Node columns?

Devices
1

My goal is to make the Z-Wave mesh as responsive and stable as possible. To be able to do so, I need to see what is going on and how all nodes are connected. That is done through the page:
https://developer.athom.com/tools/zwave

However, can someone explain the column Tx Error and Rx and why my NodOn wall plugs have received (Rx) something 2.352.719 times and still counting upwards 2-3 times each second? What are they doing? It is both NodOn plugs that is behaving like that. Also sometimes they don’t respond when using the wall switch or the app so I guess something is wrong with Homey that is spamming these nodes?

DevZNodes
DevZNodes.PNG1228Ă—608 44.6 KB

What does it actually mean if I spot a node that for instance have 12% Tx Errors? What can I do to make the node run perfectly? All 4 nodes in the screenshot with Tx Errors are between 3 to 5 meters away from Homey in the same room.

Also, what can I actually do with the popup menu with the 4 choices as in the screenshot above? What does Heal do and when should I use it? If anyone can take the time to explain these for a new user, it would be great. Thanks!

2

Rx = receive signals.
So homey received that amount of signals from your device, looking at your other devices there is definitely something wrong with your plugs and this happend in a short amount of time, try enabling the log below to see what they send.
If it is COMMAND_CLASS_METER then it is a known issue of the (micro) plugs themselves and you should contact nodon about this, as it is a manufacturing error.
I’ve seen the same with 1 of my micro plugs I have (I have 7 in total).

Tx = transmit signals (send toward the device),
60 times something was send, with 7 (12%) where it was not received by the device (homey knows this by not receiving the “ok I received your command” back, also known as noAck (no acknowledgement))

Heal:
every mains powered device has a table inside with which devices are nearby (routing purposes).
With heal you let that device know to renew that table.

Send basic on/off, send the most basic on/off signal there is in zwave, every device that can turn off or on should react to this (unless secure, then it depends on what the manufacturer implemented)

Send test frame, sends homey’s NIF (node information frame) to the device, 99% of the time it does nothing, so not useful unless you dive deep into zwave to know what it does.

6 Likes
3

Thank you very much for your help, Caseda! Your information was most helpful. The log shows the same error as you mentioned so I’ve contacted NodOn to fix it.

I guess it shouldn’t be any Tx Errors at all in a healthy Z-Wave mesh network or is the errors like in my screenshot to be expected?

4

The TX errors probably are there because of the amount of traffic the 2 plugs generate.

5

A factory reset of the NodOn Plugs helped. So far.

7

Hi,

Looks like my Zwave neocoolcam plug is having the same issue,
no errors but tons of Rx sent
This is 24H since the last reboot

image
image.png1288Ă—730 40.4 KB

and indeed tons of COMMAND_CLASS_METER
I’ll try a reset of the plug, otherwise just throw it.I don’t need zwave plugs as i have tons of zigbee plugs, i only buy them for the mesh…

|2019-09-23T06:53:26.884Z|Node[18]: Received application command for COMMAND_CLASS_METER, data: 0x02214400000031012d00000031|
|2019-09-23T06:53:26.886Z|Node[18]: [COMMAND_CLASS_METER] {“Properties1 (Raw)”:{“type”:“Buffer”,“data”:[33]},“Properties1”:{“Scale bit 2”:false,“Meter Type”:“Electric meter”,“Rate Type”:“Import”,“Meter Type (Parsed)”:{“value”:“Electric meter”},“Rate Type (Parsed)”:{“value”:“Import”}},“Properties2 (Raw)”:{“type”:“Buffer”,“data”:[68]},“Properties2”:{“Size”:4,“Scale bits 10”:0,“Precision”:2},“Meter Value”:{“type”:“Buffer”,“data”:[0,0,0,49]},“Delta Time (Raw)”:{“type”:“Buffer”,“data”:[1,45]},“Delta Time”:301,“Previous Meter Value”:{“type”:“Buffer”,“data”:[0,0,0]},“Scale 2 (Raw)”:{“type”:“Buffer”,“data”:[49]},“Scale 2”:49,“Meter Value (Parsed)”:0.49}|
|2019-09-23T06:53:27.872Z|Node[18]: Received application command for COMMAND_CLASS_METER, data: 0x02215400000000012d00000000|
|2019-09-23T06:53:27.873Z|Node[18]: [COMMAND_CLASS_METER] {“Properties1 (Raw)”:{“type”:“Buffer”,“data”:[33]},“Properties1”:{“Scale bit 2”:false,“Meter Type”:“Electric meter”,“Rate Type”:“Import”,“Meter Type (Parsed)”:{“value”:“Electric meter”},“Rate Type (Parsed)”:{“value”:“Import”}},“Properties2 (Raw)”:{“type”:“Buffer”,“data”:[84]},“Properties2”:{“Size”:4,“Scale bits 10”:2,“Precision”:2},“Meter Value”:{“type”:“Buffer”,“data”:[0,0,0,0]},“Delta Time (Raw)”:{“type”:“Buffer”,“data”:[1,45]},“Delta Time”:301,“Previous Meter Value”:{“type”:“Buffer”,“data”:[0,0,0]},“Scale 2 (Raw)”:{“type”:“Buffer”,“data”:[0]},“Scale 2”:0,“Meter Value (Parsed)”:0}|
|2019-09-23T06:53:28.870Z|Node[18]: Received application command for COMMAND_CLASS_METER, data: 0x02a1425ac3012d5b08|
|2019-09-23T06:53:28.871Z|Node[18]: [COMMAND_CLASS_METER] {“Properties1 (Raw)”:{“type”:“Buffer”,“data”:[161]},“Properties1”:{“Scale bit 2”:true,“Meter Type”:“Electric meter”,“Rate Type”:“Import”,“Meter Type (Parsed)”:{“value”:“Electric meter”},“Rate Type (Parsed)”:{“value”:“Import”}},“Properties2 (Raw)”:{“type”:“Buffer”,“data”:[66]},“Properties2”:{“Size”:2,“Scale bits 10”:0,“Precision”:2},“Meter Value”:{“type”:“Buffer”,“data”:[90,195]},“Delta Time (Raw)”:{“type”:“Buffer”,“data”:[1,45]},“Delta Time”:301,“Previous Meter Value”:{“type”:“Buffer”,“data”:[91]},“Scale 2 (Raw)”:{“type”:“Buffer”,“data”:[8]},“Scale 2”:8,“Meter Value (Parsed)”:232.35}|
|2019-09-23T06:53:29.870Z|Node[18]: Received application command for COMMAND_CLASS_METER, data: 0x02a14a0000012d0000|
|2019-09-23T06:53:29.872Z|Node[18]: [COMMAND_CLASS_METER] {“Properties1 (Raw)”:{“type”:“Buffer”,“data”:[161]},“Properties1”:{“Scale bit 2”:true,“Meter Type”:“Electric meter”,“Rate Type”:“Import”,“Meter Type (Parsed)”:{“value”:“Electric meter”},“Rate Type (Parsed)”:{“value”:“Import”}},“Properties2 (Raw)”:{“type”:“Buffer”,“data”:[74]},“Properties2”:{“Size”:2,“Scale bits 10”:1,“Precision”:2},“Meter Value”:{“type”:“Buffer”,“data”:[0,0]},“Delta Time (Raw)”:{“type”:“Buffer”,“data”:[1,45]},“Delta Time”:301,“Previous Meter Value”:{“type”:“Buffer”,“data”:[0]},“Scale 2 (Raw)”:{“type”:“Buffer”,“data”:[0]},“Scale 2”:0,“Meter Value (Parsed)”:0}|

8

Well, it always sends reports about usage on every change that exceeds the threshold. But what appears strange to me is this looks like reports of the voltage metering and that it goes from 0 to 232 and back to 0. That’s shouldn’t happen when it’s just plugged in imo. Is there something plugged in in the power plug?

1 Like
9

  1. to answer the question, Only a basic lamp that i only turned on once in the last 24H and is off the rest of the time

  2. i’m especially surprised by my PIR which shows “offfline” and unreachable but does tons of RX!

    image
    image.png1306Ă—761 52.8 KB

    and has a 50% error in TX, this PIR used to mesh over the plug that does too much RX, may be linked !

  3. Weirder even, node 3 and 19 are meshing over a battery powered small neocoolcam siren/alarm (node 2) sounds impossible

here is the full report :slight_smile:
http://www.mediafire.com/file/y9ilm9kqfnpq2or/New_Text_Document.txt/file

10

  1. Strange. Maybe i misinterpret the logging, not sure about that. When i find the time i will look at my Coolcam plugs logging’s.

  2. Unreachable is a farce. Don’t know when or why it is shown.If you switch the unreachable device off or on it does do that instantly. When you press test it says “reachable” and the status disappears…

  3. The nodes you refer to are “unknown” so their path is indeterminable. Very often that results in showing a path that is impossible (either through a device that isn’t there anymore or via a device that doesn’t even route).
    Unknown usually means that the device is REALLY unreachable (either because it isn’t powered or because it is out of reach).

11

thanks!!

Most of the “unknown” are a few meters away from my homey,
i am clearly not out of troubles with my z-wave

12

I have the same problem interpreting the Z-Wave statusses.

image
image1519Ă—447 26.9 KB

The smoke detectors (brand: Heiman) in the kitchen (“keuken”) and the hallway (“hal”) do trigger the right flow when tested with the button on the device. Same for the CO detector (Heiman as well, named “cv-kast”).
Only the smoke detector (Heiman) in the bedroom (“slaapkamer”) does not seem to trigger the right flow when tested. When it it brought closer to Homey, it does.
The submenus are unclear to me too.
image
When pressing “test” ALL the devices give “node is unreachable”.
Send testframe give " TRANSMIT_COMPLETE_NO_ACK" for ALL devices.

I suppose the right solution would be to buy an mainspowered device like a smart plug and place it in the middle.
but where can I find this information on the developers overview for Z-Wave?
And what’s the purpose of the items in the submenu?

I have no problems interpreting Zigbee here, but Z-Wave is a whole different story… :thinking:

13

With “Send Basic On/Off” you can switch e.g. switches, SmartPlugs etc. on and off for test purposes.
With “Heal” the neighbouring nodes are requested and the device tries to find a better route.
With “Test” you can only check if the device is reachable or not.

If you want to execute the “Heal” or “Test” on battery powered devices, e.g. your smoke detectors, then these devices have to be woken up first. This is not necessary for power operated devices.

For a stable Z-Wave Mesh, if possible, several power operated devices should be installed. These devices transmit the Z-Wave signal (Repeater), battery powered devices do not.
In the end, you can only try out if a SmartPlug or a Repeater is sufficient, but this is definitely not a guarantee for a good working Z-Wave Mesh!

1 Like
14

Thanks @DirkG!
How to wake up the devices then? Push the testbutton on the detector itself? Is it then “active” for a given amount of time?
It’s not clear to me to be honest how this “sleep mode” works on smoke/CO detectors. They are not in contact with Homey like other sensors are? Like my door/window sensors , temperature sensors, etc.?

15

How to wake up a device is different per brand, but usually it is pressing the same button you paired it with for one or three times. Should be mentioned in the manual though…

Every battery powered device goes into offline mode. That is to save the battery. It doesn’t have to be in contact until it triggers. Most devices do have a setting for waking up and report presence every x time, mostly adjustable. That should be in the manual also…

16

How to wake up battery-powered devices and how long they stay in awake mode is different.
For the smoke detector I have unfortunately only found the Zigbee user manual.
In the manual for the CO detector it is also not clearly described, but I would press the button 3 times within 1.5 seconds (see screenshot).

image
image727Ă—729 110 KB

As Peter has already written.

17

Thanks for the replies, guys!
Strange that some detectors stay in alarm state after I have pressed the test-button (so not the button @DirkG mentions). The green one in the pic above.
Shouldn’t they return to a normal state after some while when there is no new alarm?
Looks like the sensor goes into sleep mode before it can report…?

See:

SmartSelect_20200321-172726_Homey
SmartSelect_20200321-172726_Homey463Ă—722 83 KB

Perhaps something can be done with the settings below in “advanced settings”?

SmartSelect_20200321-173055_Homey
SmartSelect_20200321-173055_Homey1080Ă—735 75.3 KB

And why/how is this different from the door/window sensors? The return to a normal state as well after a door had been opened for a long time and then closed…

18

Guess you pushed the wrong button. To me it looks like you have to press a button inside the case (small blue dot), with a needle or something similar.

I do not use Heiman devices, so I cannot tell you how they behave.

Yes, with the parameter “Interval” the wake-up interval can be set. However, this does not have to be changed.

I’m not sure if I understand you.
Basically there is no difference between a door/window sensor and a smoke detector. Both are triggered by a specific event.
However, since the smoke detector is a security related device, I think that you have to reset the alarm status manually, as a kind of control. As I already wrote, I don’t have any Heimdal devices and I don’t have any smart smoke detectors either. So please have a look at the manual how to disable the alarm state.

19

I pushed this button to test the smoke (and CO) detectors, like ypu would do with normal detectors.
That gives an acoustic alarm on the detector itself, and triggers the alarm-flow on Homey (only not on the one in the sleeping room which probably is too far away).

The triggering sets the detector to an alarm state in Homey which does not reset.
Unfortunately there is no card to reset an alarm from these sensors in Homey.
That means you would have to press the button within with a needle after each testing?
EDIT: pressing the button behind the small hole does not result in resetting the alarm-state…

Wouldn’t adjusting the wake-up interval not help here?
Or might this significally increase battery usage, you think?

20

Sorry, I don’t know because I don’t have Heimdal Smoke and CO detectors.

Still, I guess we misunderstood each other.
You asked how to wake up the sensor.
The button in the case (small blue dot according to the manual) is probably used to wake up the device (press 3 times within 1.5 seconds).

No

Yes

21

Thx…
Yes, I understood you right I think.
Waking up the sensor would hopefully reset the alarm state because it reports that everything is ok again.