You can add @ in front of their username to tag them. Like this. @brydling 
1 Like
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.
Ok, thank you!
I have some nodes that don’t really care about my setting of not reporting a change of less than 20% in watts. This is one of these nodes. They also report very small changes even though the text in OH for the device setting says it never reports a change <1W. I didn’t think this could cause the behavior we see though because I believed it was normal with a retry that soon when the other end is not responding. The times I have seen in the log when an ACK actually happens it happens after around 20 ms. But I will try setting it to disable these reports altogether.
This is a Qubino Flush 2 Relay (ZMNHBD) with firmvare version 1.2. I have been in contact with Qubino support regarding this earlier, because another problem with this specific node is it reports -214748364,8 kWh in its energy reports (max negative 32 bit integer). They told me it was a known issue in this firmware and that I should try excluding it, resetting it and including it again. I have tried excluding and including but haven’t managed to reset it to factory defaults. Maybe I shall try that some more. They told me to send an RMA if problems persist, but I really do not want to send back the ~10 of these devices with old firmware that I have installed in different locations in the house.
Thank you for your patience guys!
The binding simply polls all devices during startup to establish their current state - so that the UI reflects the current state of the device, and not the state when OH was last running.
If people want to have a system that correctly reflects the state of the device, then I’m not sure of other options, but I’m open to suggestions. OpenHAB expects the device to be
@robmac @chris
I have now turned off reporting on node 4 and verified in zniffer that no more meter reports get sent. Then I rebooted the whole computer running OH. Nothing changed to the better unfortunately, so I will put my Aeon Z-stick back into service and try how that works with polling disabled. I will also order one more UZB3 to replace the Z-stick later. The one I currently own is zniffer.
I don’t know if I am just unlucky or if there are loads and loads of z-wave controllers and devices with buggy firmware out there. Knowing what I know now I would never have invested in Z-wave devices for my electrical installation. Plejd is taking over Scandinavia and it just works. But it is a locked system. If these kind of devices is what the open world has to offer then the future belongs to locked systems unfortunately 
Will send a report with more troubleshooting info when I have tried the Z-stick again.
I doubt that the firmware is buggy. However, currently all ZWave controllers use fundamentally the same firmware from Sigma/Silabs - that’s likely to change in future, but for now it’s still the way it is.
Unfortunately ZWave isn’t (IMHO of course 
) quite a stable as it once was - there’s a lot of evolution in the standards these days and that leads to confused implementations. The way ZWave introduces new features is often quite muddled compared to other protocols as well. It is however still a very widely supported system and in general there is good compatibility across devices.
2 Likes
No criticism it was a statement of fact. Zwave does not like lots of traffic so it is a stress test.
Not many options but as you asked. For a small network it is not a big issue and as long as you do not restart it is never an issue. For large networks with lots of sleeping nodes it is a bit of a pig.
Some other systems…
Openzwave does the same as the binding so anything based on that does the same.
One option I used to like was homeseer which allows you to mark which ones you are bothered about and it collects only those. I have not used since 2011 but I would be surprised if they removed it.
For Fibaro they don’t bother but it is easy to do something like homeseer. Very easy to write a quick script to get the ones you care about quickly and the rest at a slow pace in waves. This could be done in openHab so not a bad option just lave it to a script.
Both of those options allow you to not bother with many sleeping nodes that tend to be the type that report and if they are regular reporters probably report before they wake anyway and cause the worst of the startup in OpenHab.
lots of bugs in Quibino which is why they offered to let you return.
Lots of people run large zwave networks with no issues but if you get even one bad device it can cause lots of issues.
Do not forget @chris is “handcuffed” to some extent my restrictions & requirements of openHAB.
From my experience, this binding is worlds better than openzwave. I used them with Home Assistant.
The sleeping nodes should not be an issue, and will not participate in the startup medley since they are sleeping 
. The binding will not send anything to them until they wake up, which will all be at random times spread over the next hour or two, so they are not in any way participating in the “stress test”.
There’s no doubt that polling all devices on startup can create a considerable amount of traffic and I fully agree with your original point that people shouldn’t get too worried about this. I don’t really think it’s a problem in any way - it just takes a bit of time, but is necessary to ensure that the system is synchronised with reality. In fact this is not even part of the binding since at the moment openHAB forces this by sending a REFRESH command to all channels on startup.