About This File
Support topic for this scene:
Script to summarize "Wake up interval" and "Polling time interval" off all physical (master) devices.
-
Version 1.2, 2016-06-23.
* Improved detection: FLiRS & non-Zwave devices.
* Isolate "display" logic into table "printing", so
the detection logic (code) becomes clearer.
* Replace "*" with "-" because, well, I like that
* Handle more exceptional cases (missing data).
* Handle html special characters (ampersand, comparison).
* Implement tests (on my laptop only...). - Version 1.1. 2015-06-27 Fix for: LUA error: /opt/fibaro/scenes/390.lua:70:attempt to perform arithmetic on local 'timeSec' (a nil value).
- Version 1.0. 2015-06-14. Initial version. Tested on HC2 V4.049.
Description of the report
This is a example. The ID is clickable when you run the script. It takes you to the settings of the device in a new tab or window.
ID T(s) T(h:m:s) Type Info 299 - - X 333 7200 02:00:00 W 382 * * G 383 125 00:02:05 P 804 600 00:10:00 W
For battery devices the script will say:
W = Wakeup Interval (device is battery powered).
or
F = FLiRS (frequently listening routing slave).
FLiRS are battery operated that can respond in 1 second to commands (unlike normal battery powered devices). Typically found on door locks. Battery is checked every 24h (non-configurable).
Polling comes in three flavors. The sentences used here are the same as in the HC2 device GUI. They are shown on the "Advanced" page of a device). The possibilities are:
G = Device uses global polling queue. P = Device will be polled at periodic intervals. X = Device excluded from polling.
Global polling uses the settings of polling on the "Configuration, Z-Wave Network" tab.
So in the example: device 299 e'X'cluded from polling, 330 'W'akes every 2h, 382 has 'G'lobal polling, 383 has 'P'eriodic ('P'er device) polling set at 125 s.
* Background *
Wake up interval
This setting applies to battery devices. This is the time between wake up and "wake up" means the device exits "deep sleep" and sends a specific signal to controller. That WAKEUP-NOTIFICATION tells the controller that it is ready to exchange configuration information. The device stays awake for some time (timing is device dependent) to exchange data. Wake up is not to be confused with polling. Also, I'd like to note that a wake up can be forced through some specific button press sequence, but not by "using" a device. For example, breaching a motion sensor, or opening a door with a door sensor does not wake up the device. Such an event merely makes the device send a status change to the controller. After that, it immediately goes to sleep. This is necessary to minimize power consumption. When does this all matter? Suppose you have changed a device parameter. That request will be queued until the device wakes up. Suppose it's a Smoke Sensor, high up there against the wall and you can't push the button. In that case, you'll have to wait until the next "wake up interval" passes. And if you own a radiator thermostat? That kind of device will pick up the set point from the controller at wake up. And for a key fob: you probably wouldn't want it to wake up at all, because there's no interesting data to exchange.
Polling interval
This is the time between "polls" and a poll is the controller asking for the device to send information. Only mains powered devices have their radio switched on at all times, so they can respond to this request whenever the controller asks. But what with a battery device? If the controller ask something while the device sleeps (and that's almost always), it can't receive the poll. I don't know how Fibaro implemented it, but there are 2 possibilities: either the poll is queued or it is discarded. There is a hint how it's done: have you looked at the interface lately? Then you have noticed that a battery device does not have the "polling" settings. In my own opinion, polling indeed doesn't apply to battery powered devices.
What should we do with polling? Is polling necessary? First of all, I remember cases of users that where unhappy without polling, as it was disabled in the earlier 4.X versions. I once owned a device myself, that did not report status to the controller: a simple switch. No polling means: the controller doesn't know the state of the switch when operated locally. But if you have a look at the technical documentation of your device, you're likely to find a "reporting group". And if it's Z-Wave plus, having such a group is part of the standard. That means the device sends data to the controller, when something interesting happens.
What's the issue with polling? Polling causes network traffic. And that may introduce delays from and to your devices. It depends on network size, network design, code and device types. I have 37 mains powered devices (43 battery), and I can tell the difference between polling on and off. The polling traffic is very likely unnecessary traffic. I would disable polling. If HC2 is wrong about the status of a device, verify if "1" is in the reporting group (see device manual). To my knowledge, none of the Fibaro devices need polling.
One more thing. The "polling" and "wake up" interval can be put on the same report, in the same column, because they cannot occur together. If it's a battery powered device, it can't be polled because the device switches off its radio when it's sleeping. And when it's a mains powered device, its radio is always on, so "wake up" doesn't apply.
* FLiRS *
FLiRS are battery operated, but still can receive commands. Because they are "Frequently Listening Routing Slaves" meaning they briefly wake up once per second to check if the controller sends a special command. The Fibaro Heat Controller FGT-001 is such a device. You can also build your own FLiRS based on a Z-Uno. Technically they can be polled, but I think the HC interface does not allow you to do so (not on FW 4.150 anyway). FLiRS "do not wake up as a normal battery device" so there is no such configuration parameter.
* About the code *
Special thanks to forum users krikroff an A. Socha (Fibaro) for pointing me in the right direction for the API. Bits and pieces were gathered on this forum. Some parts were discovered by trial and error (by me). And an invaluable source of information is the book "Z-Wave Basics" by Dr. Christian Paetz.
One small warning: parts of the code uses features that are not (yet) documented. They were discovered by reverse engineering. I may be wrong. Or the code may break if Fibaro changes things in future firmware releases. Maybe the script barks at you. Please let me know if it does so, I'll try to learn from it. I last checked the code on my system, running FW 4.153 jan 2018 and it was still fine.
The code is available as an attachment to this post.
Please let me know what you think of it!
Thanks for reading this long post. And as always: have fun with Home Automation!
