Does the log viewer have show any hints?
https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer
You can post the zniffer file. It is easier to understand. Do you have the poll after set for the nodes? Do you need it?
Yes, thank you. It gave some information. Looks like the controller receives the last reports from the relay device but doesnât send them up to the binding? Because the controller ACK:s them but nothing shows up in the binding log?
Yes I have. I need it for some nodes because I do not want to get regular reports as soon as the watt value changes. I just want to poll it once after the device has been set. But I donât need it to poll the whole device, only the relay I changed. Now it polls everything.
Damn it, I donât have the zniffer file for this event saved. But I can probably make a new one.
Most devices send a report immediately after switched anyway
Node 6 doesâ you can see it in the zniffer 5th line of the snippet you sent so why ask again?
006 001 F9 E0 F2 20 Singlecast Meter Report
donât like this
23 001 006 F9 E0 F2 20 Singlecast Multi Channel Cmd Encap
22 001 006 F9 E0 F2 20 Singlecast Multi Channel Cmd Encap
Hi @brydling
I was intrigued by the two commands from the controller with no ACK .
Looking at the RSSI node 6 is closer (radio reception wise) than the controller to zniffer but there is a missing ACK and the two requests are identical. There is no evidence of an issue with radio reception in the rest of the snippet of the trace.
I can not reproduce this however hard I try so I donât think it can be an issue in the binding and it makes no sense it is a retry in the base coms layer with 23ms between messages.
You might have evidence here that the Aeon z stick does odd things under certain conditions.
It is because I do not trust that the power report that the device sends is the stabilized value. I have it set to report changes of 20% or more, so if it changes first to 100W then to 110W during power on then the value will stick at 100W. I think it gives a more consistent value when polling the device after 1,5 seconds.
Edit: Now I understand what you mean. I have seen lots of these âretriesâ followed by two ACK:s when troubleshooting and have thought that the issue is poor RF environment or a bad device responding with an ACK too late. Since I donât have knowledge about the protocol I just thought it was normal for the controller or devices to perform a retry after 20-30 ms. But you are saying the device is performing OK this time and it is the controller that is performing a retry too quickly?
I have suspected this. Thatâs why I performed a factory reset of it. Seems it did not solve the issue. I really like the battery feature of the Z-stick, but it looks like I have to ditch it for something else. I guess it is possible to use a laptop and the Z-Wave PC Controller to include devices with any Z-wave stick? Iâve never had anything other than the Z-stick, so I donât know how people with other controllers do it. It is not feasible to take every device to the controller because the majority of them are a part of the electrical installation in the house.
@robmac Forgot to make the last post a reply to your post, so maybe you didnât receive any notification 
Do you need it accurate? People generally agree very regular reporting and polling is not a great idea on z wave. What do you use it for that needs accurate?
One link but I can add many including my own:
Many many advise the same.
If you want to go against the flow, slow performance may be what you have to accept. I turn off ALL polling.
I also donât bother too much with accurate W at each device as the only place I find it interesting is for total at the main supply. I have recently replaced my supply meter with a Shelly EM3 which is nice and accurate and less of a nuisance than my old aeon labs meter. As I have overall W accurate there so I donât worry about W on individual devices so possibly that is the difference. I still grab kWh from the individual devices but everyone is different. If it is to monitor how much solar/battery you are using, total W at supply would be more accurate.
You should not need to take things close. NWI (network wide inclusion) is supported by controllers.
I can add devices 100+ m away from my controller. Just watch with your zniffer so you are sure the exchange has happened as you have zniffer. It makes life a lot easier to know the exchange is happening.
1 Like
I donât need it but I thought it was nice to be able to check power consumption of LED bulbs etc. I think I can manage without it though. I will turn it off.
I have bought a zwave.me uzb stick now. I excluded all the devices from the Aeon Z-stick and started including devices on the zwave.me but got into trouble immediately. I have turned off polling on all the included devices. With only a few nodes included response times are even worse than with the Aeon Z-stick. Here I have included a debug log and a zniffer log of the whole startup when rebooting the computer running OH startup.txt (843.7 KB) startup_zlf.txt (58.6 KB). The file startup_zlf.txt shall be renamed .zlf. This forum doesnât allow .zlf files apparently.
In the end of the logs I try turning on one of the relays in node 4.
It seems that this stick also does nothing for long periods of time. The binding seems to abort lots of transmissions after waiting 5 s. That is also what is happening when trying to turn on node 4 at 00:31:11.143. The stick sends out the command on the z-wave network 99 seconds later, then the binding receives the ACK.
The stick doesnât even respond with an ACK when node 4 tries sending meter reports lots of times. If the Aeon Z-stick sucked then I donât even have words for the zwave.me uzb.
Are there any controllers that work as intended? What are you using?
It would take some development effort with rules etc., but there might be an intelligent way to provide this info for this kind of load. The load doesnât vary much outside of commanded changes, so a very occasional or even one-off sample can be extrapolated over longer periods.
In some cases a REFRESH command by rule can produce a poll on demand.
Likely to take some effort for little return, that could instead be simply approximated, though.
1 Like
Hold on a minute, zwave is a mesh network with learned pathways. Youâre busy changing the mesh. itâs going to take a while to settle down, do not throw it in the bin just yet.
Thatâs about as far as my knowledge goes, interesting reading here
What about the tried & true path of asking the system what is happening by collecting debug logs as stated in the official binding documentation??
1 Like
What documentation are you referring to? I have included a debug log by setting the loglevel to DEBUG for the zwave binding. That is what I found in the documentation. What have I missed?
Certainly do not worry unduly about issues during startup. Because of the way openHab works the binding goes through a whole rigmarole with a set of traffic that stress tests the best of mesh networks.
It is not great but hard to solve but possibly it will be long term.
BUT
you need to turn down the reporting on your devices. Node 4 is flooding your network with traffic at regular periods. It spends long periods sending a report every 20 to 40 odd ms. When would a controller get an opportunity to send anything during these periods?
When that one is not bleating we may find others but start by turning reports off or down to as few as possible on node 4. What sort of device and firmware is it?
Very basic UZB-3. Reference design from Silicon labs. Not sure you can beat it. No frills but I get 40m direct @100 with no issues to my shed so it does what it says on the tin. No buttons no leds just a simple controller.
I put it on a short usb extension cable so it can be placed in a good place that gives good results. I have experimented with changing the antenna but it makes little difference and often what you improve in one way you lose in another so I use a vanilla stick.