In general, polling should be limited, and if associations are available (which is the case with all modern devices), then polling should not be used. This is a common mistake people make, and is a major cause of network performance issues.
I would strong discourage the use of polling at any rate higher than 30 or 60 minutes. This short of low rate polling is (IMHO) ok, and used by the binding to ensure that devices are still available.
FGD212 Dimmer 2
Still lags in power reporting. Turn the light off, and it shows 30watts being sent for example.
What exactly is polling for, when having a wakeup time periode?
Polling is used to read the state of a device.
If the device is a battery device, polling works the same, but polling, and any other communications, will only occur when the device wakes up.
I have a Neo CoolCam motion sensor. It has been running quite stable since I got it for… hmm almost a year ago. Lately it has started to give falsh triggers though. Battery was down to 40%. I changed the battery, and for some reason, the falsh triggering seems to have stopped. Makes no sense really…
Like, if it´s alive ??
Thats what I thought…
So a polling time of 12 hour and a wakeup time at 12 hour will result in the device could be dead for at least 12 hours before reported dead, right? (for battery devices that is).
But your device will normally report something if it is in use through association. Say new light level or temperature or door open. This report does not wait for wakeup it is sent by the device as required.
Chris has also put a rather nice bit of code in the binding that even if a device is thought to be dead, as soon as the controller sees a message from it, the device is marked good again. I can not compliment Chris and other contributors highly enough for what they have achieved,
If it is not configured to report anything even battery level then it will still wake on wake up time and ask the controller that is associated for any messages waiting. If you manually wake it will also ask out of schedule and should pick up any messages waiting from the controller.
This is the same advice I have been giving on the Fibaro forum for seven years. Fibaro used to have pollingon by default. They eventually got the hint and turned it off by default.
The only reason I use polling is for devices I rarely control. I do this one time a week when all settles down and it is just so they get marked dead and I notice before they are actually needed.
In the early days after a device is added or reconfigured I have it set so that the device gets some messages and a good latest working route is defined. when all settles it gets progressively made longer and then turned off.
and that takes us back to not wasting bandwidth or trying to control 12 devices in an instance. It is just asking for trouble, When it is automation you could happily put 1s between each and not notice any difference but your network will be a lot more robust.
Also limit what you report and how often, Do you really need to know 0.01 kWh more has been used?
Thats what I meant… There really isnt any need for polling I Guess. Perhaps in the first few hours testing a new device. If it turns out good, no need for polling then.
I think we are in the same place and that is my attitude.
Unless you:
Do not poll.
One device I have that I use it for is the switch on the amp in my spare room. It is switched on by automation when the player starts and off after a delay when playback stops. I have no time driven energy reports from it as it is just not needed. It just sits there so if it was switched off by my cleaner I would not notice unless it made my network wobble. I probably would not notice as the mesh is good in that area. I put polling on it very occasionally so that I notice it has gone dead rather than a guest trying to listen to the radio and the amp not working.
Other than that type of thing I use it at setup only as a sort of test and route optimization thing then would remove altogether.
Well, there’s not really any such thing as “in an instance” 
The binding will queue all frames - so if you send 12 frames “instantly”, the binding will queue them and send them one after another - waiting for the previous response before sending the next message. This has the effect of spreading everything out over a relatively long duration.
I should note that the recommendation for polling is documented - if you feel like updating the documentation, then it would be appreciated -:
This is what I was trying to get over to answer the original question.
The disadvantage of queuing in a batch is that as soon as one command is sent the reports will come back for the energy change in the opposite direction not long after the ACK. Also they have the poll after command set so it queues a lot more admittedly at a lower priority.
As @kovacsi2899 had reporting set for W , kWh and position coming back there was a lovely storm on his network and it all got a bit odd.
@kovacsi2899 is this all making sense now and are things working again?
I will go and have a read and see if it needs any further comment. Often I am finding it is the pure volume of items that prevents me finding the information I need and it may be that as much as anything that causes people to not take note.
Edit just read it and I think the only edit would to be explicitly say polling set to a long period on this line
“Where possible associations should be used to update the device state and polling set to days or weeks -”
cheers,
Robert
All I have made an edit. Update README.md by robmachab · Pull Request #1204 · openhab/org.openhab.binding.zwave · GitHub
All please have a read and send comments. I may have made things more confusing rather than improving.
Hello, Yes it makes sense and performance is mutch better. I’m sure in that. But as this communication jam was not continious I need some time to judge that my final conclusion. Regarding polling what I have mentioned before I have issue with Fibaro Roller Shutter 2. They are not reporting precisely actual state as they send information during shutter is moving and final state is not reported quite often. So it happen that it is closed to 0% but last report was 11%. That’s why I will set it back to 120 min as it was before probably. I don’t know that is there any new firmware and as I do not have Fibaro HC I can’t flesh it anyway. I would need precise information for control as I use the actual state to decide move it up or down when button press event is triggered.
This should be fine (and it is fine) - the network has a lot more capacity than one command every 50 milliseconds. The network also uses CSMA to avoid conflicts in any case.
shh you will keep people reporting every 0.1s change every 0.1s and producing thousands of reports and commands a second and lots of collisions. Then they will get pauses and waste their time all to get reports that gave them no value.
Yes that is a nuisance. Not sure why they do not make them available so anyone could flash. They are so paranoid about their IP. I sometimes question if they are not harming their sales more than the risk they would take. They do not even let most people have root to the HC2. Not hard to get round but very annoying.
We’re not talking about that - we were talking about sending a number of commands in a row - this is fine - we are NOT talking about “thousands of reports”.
I’m still playing with these settings. My network is more stable now. I was able to remove all failed nodes with Zwavecontroller software except one:
Hello, Finally I could set up a stable Zwave network using these advices. Thanks for that! I have bought Fibaro Home Center Lite for updating firmware of my Fibaro devices. I have added as a secondory controller to my network. This way all devices are visible in Fibaro HC as well and I could update Fibaro’s firmware. One interesting thing is that Openhab recognizes Fibaro HC as unknown device:
I think that the binding does work.
Please note the error you show in your post -:
The issue is clearly related to serial port issues. Are you using the latest version of openHAB (not just the binding)? This is required to fix a startup issue that was fixed in the framework quite recently. Otherwise it is likely the other standard serial port issues - permissions or options.
