Is there a way (say from a Cron rule) to have the Z-wave controller send a Get request to a node (thing) for a certain item (say operating status)?
For example, I have thermostats with configuration parameters to get certain items on a certain frequency (say sensor temperature), but I’m missing an item or two and resorted to polling everything on a more frequent basis. That is working, but generates extra traffic that I do not need (like the summer cooling setpoint (it’s winter here) and the battery level (they are on the furnace power normally). I have a working zniffer, so could pick up the binary, if that is a factor.
I was thinking there might be something similar to the getActions (mqtt, broker), etc. But could not find anything.
Depending on the device, you can send the REFRESH command to cause the binding to send a GET request. However, you mention battery level, so if this is a battery device, then it is simply not possible to poll since the device will be sleeping - or more accurately you can poll, but they will only be sent when the device wakes up.
So I almost hate to mention the thermostat since there has been controversy about the humidity, but this question is unrelated. It is the RTC CT101. It is powered (C-wire) but only has Association group 1 for the controller. What I am doing now is polling every 3 minutes to get all the data I need, and, as noted above it works. I have two zones (edit: Node 14 & 21- shown below) and am aligning the operation to reduce frequent restarts.
What led me to this question was this zniffer output of the poll.
I was looking to see if I could just GET the ones I’m after (Operating State Get & Thermostat Setpoint GET) and reduce the traffic. It sounds like that is not likely? A REFRESH would just send another poll. right?
By exclude/include do you mean delete from Openhab (Zstick) and re-add?; Not just delete thing and rediscover in the UI? Will this mean a new node number?
The device itself has a reset button. Do you think I should I do anything with that?
Are you saying the device should send a report when the furnace goes on or off, even though there is no configuration parameter for a report related to that? The only obvious reporting configuration item is the change in ambient temperature.
I’m a little apprehensive, since it works, but is just not optimal.
Thanks for replying
Bob
edit: random thought: Is there something in the RTC101 Device database to look at to see that the operating state should be reported when it changes?
Unless the device has a very odd design the lifeline would normally get all reports that the device would ever send. That is the point of the lifeline. If the report comes through when you poll it should also come through on the lifeline.
Exclude the thermostat from the network.
This would normally reset the device but if factory reset is there it might be worth hitting that after you have excluded the device to make sure.
As you say it is working and if all of that traffic is not causing issues to other things then you might decide to live with it. I suspect though that if all that polling coincides with other busy times you might get delays.
I had a network with 180 nodes and only ever polled any of them every 10 days. I would have disabled all polling if it did not require changing the code each time I took a release. Polling should only really be needed if you have very old z-wave devices. A well setup network with no buggy nodes does not require polling or poll after a command if all nodes support association and the lifeline or necessary association groups are set to the controller.
The reason to poll devices is to check if they are still there - it’s a monitoring system. You could argue you don’t care - if a device fails, you’ll find out when you go and press the button, but at least IMHO it’s best to know before you need it that it has failed.
If you don’t poll a device, and you don’t use a device, then you just don’t know if it’s working. I know some sensors can be configured to report regularly, but not normally simple devices like switches.
First thanks to @chris and @robmac for your time and replies. I would like to wrap this topic up with a summary of what I gathered.
I’m going to mark Chris’ post as the solution as that was the answer to my question, although robmac explained that it was due to the zwave being on the serial port, so issuing a specific GET command in a rule won’t work. (I hope I’m saying this precisely enough)
Also the point is taken that, at least in this case, if my device was working as typical, I should not need the functionality I was asking about in the first place.
As to Chris’ suggestion on the REFRESH that is promising since the device does report ambient temperature changes and I can use this to prompt a poll from a rule to get the other parameters. This could greatly achieve a reduction in polling activity (versus the arbitrary 3 minutes that I’m using now).
I’m reluctant to delete and rediscover the device as that always leads to other problems for me. Also the devices do have the humidity quirk, so I’m not certain that after all the delete/etc it is going to report the Operating state when it changes (as is typical for newer Zwave devices). The devices are not new and not Zwave plus. These devices do have a good radio and are shown as a neighbor for nearly all of my 42 other devices, so I’m also concerned about that. I’ll keep this suggestion in my hip pocket, but will work on the REFRESH concept first.
This Zniffer I set up last week does result in compulsive behavior by me regarding network traffic and routing. However, stepping back, my Rpi3b uses about 1% of the CPU, 50% of the memory, and the Ack’s are in the low msec range, so realistically, at least for home automation I’m good, even with the extra traffic from these two devices
I have not had a failed device since moving to openHAB. Which says a lot about how well the binding works if the network does not have issues or poor configuration and my selection of devices.
It is a good point for those that have poor configuration or poor devices though.
Hats off to you for how well the z-wave works from the binding.
Sometimes you have to do this, to pick up changes in the bindings device configuration.
Done with care, it should be relatively painless … famous last words?
Leave the device and controller alone, it’s just an exercise in deleting the openHAB Thing and allowing OH to rediscover it from the controller’s list.
If you make a note of the old Thing name and re-use that when allowing a re-discovered device to create a new Thing, all the old gubbins should relink.
The exception would be if something major happened, like channel type or name changing. Then you’d have to rework the affected channel(s).
Thanks for the support.
I frequently delete the thing and scan to reacquire. I believe the instructions above were to exclude, then reinclude from the network. That changes a lot-That is what I’m reluctant to do. I did do the simpler delete and scan on the device already.
A simple delete of the Thing & re-discovery gets the latest binding settings and the rediscovered Thing has the same thingid as the deleted one so Item linkage does not break.
The thing is that you have one of those lovely devices that only updates certain settings when it is included.
There are a few devices from other manufacturers that pick up settings when first included and to change to proper behaviour you have to exclude and reinclude. This includes a few that have power/battery power and if included when on batteries or the include fails to complete fully in some way then all you can do is try again or the device works in some odd not fully awake not fully sleeping mode.
You can choose to live with it but if your network is in good order exclude and reinclude should work easily and quickly. If exclude and include do not then there are issues with your network and as you have a zniffer you could track them down and fix them.
One recommendation I will give is, if you do try exclude and reinclude, is when excluding/including always have your zniffer on. That way you see the protocol exchange and configuration take place including setting the associations. You can then analyse what commands were sent and see any failures.
If your network is small and well configured it should remove and add very fast for current node 21 as it is direct to the controller. Hopefully current 14 is similar. If it does not post the zniffer log of the remove and add.
Recap
I originally wrote the rules to align the operation of my two heating/cooling zones in January prior to my zniffer purchase. Several things can cause Z-wave controller cancelled frames, but pre-zniffer, that is what I used to judge if Z-wave frame traffic was excessive. A three minute poll of each Node thing did not seem to cause any problems. With the zniffer I saw all the traffic (most extraneous) and asked the posting title question to see I could just get the one item I needed. Again I appreciate all the replies.
For now, not wanting “perfection to be the enemy of the good”, I have implemented the “Refresh” idea that I marked as the solution, triggering on temperature changes and set polling back to 86400. This has reduced traffic at least 60% from my earlier, and non-problematic working set-up. A step forward in my book.
As to the RTC101 devices, while working on the “Refresh”, with the polling off and using the Zniffer, I noticed that the device does send reports on the operating state (i.e. Heating On). The frequent polling of the original solution apparently suppressed these reports. I ran this way for several hours and captured the frames. The problem was that the device report for operating state (key item in my logic) was not reliable. Sometimes the report was when heating started (good), but sometimes it was several minutes later. Likewise the report for heating “stopped” did not match with the furnace, so I moved the “Refresh” rule back into the model and called it a day.
As this now becomes a question of the timing of the reports rather than if the device was not configured to produce the reports, I’m going to hold off on the exclude/include idea. As noted above, I had already done the delete/rescan some time ago. The last device database update was Sept 2019, so I don’t think that did much. Anyway I’m on to other zniffing.
Thanks for the update. It is interesting that the report is delayed. It will be interesting when you have gone through your zniffer logs if you can mange to reduced traffic to a low base level if that delay is still an issue.
I suspected the frequent polling would caused issues on your network. You will find too frequent reporting also causes issues and I also do not like the poll after for this very reason. This is particularly true for devices that immediately report position change or power after receiving a command. If your network is too busy you get all sorts of odd things including hard to add and remove devices and wrongly displayed states.
I had in the past reduced the level of reporting in some cases to below what I needed. this made the network great but some automation was compromised.
If you need all of the traffic and it is too much at times, you might find that splitting your network to two controllers (or more) will help. There is plenty of wireless bandwidth and many not overly busy networks can coexist.
I had a big network before OH3 and some very noisy temperature sensors that I want to reports on 0.1C change. Moving these to their own controller on a remote OpenHAB instance so they were direct connection has allowed me to move back to 0.1C reports from 0.5C reporting.
You might even find you can just put a second USB stick in and put the noisy reporters on the second stick if the zwave is already direct. What you lose is direct association between all devices but if the network is too busy direct association is not going to behave well anyway.
These thermostats and a couple energy monitors are my only use of polling in my 44 node (29 powered, 15 battery) network. I have curtained reports and do not use the command poll. I have 21 nodes directly communicating with the controller, 13 one-hop, 7 with two and only one that goes through three intermediate nodes. I’ve noted the ack time and it is generally less than 10 ms per hop. I’m not running much else on the pi3 except the Z-wave and MQTT. I also have a pi4 on OH with the camera binding, MQTT server and use the new (and slick) remote OH server binding to get item states from the Pi3 for some rules and mysql DB persistence.
My nemeses are zwave plugs and energy monitors. Some tie reporting to a watt threshold (good) with a max 100% percent trigger (bad). When idle, stray readings range from zero to 1 watt triggering almost constant reporting. As noted above, that is my other use for polling. It was also another reason why I asked about Zwave direct commands.
Yes. Based the Zniffer it appears the device waits until a temperature report is required by the configuration. If the Heat message is not included with the temperature change (the 20 year old furnace warm-up could be a factor) it waits until the next temperature change to send the Heat On, after the heat on is well underway (or heat OFF after it has been off for several minutes). The Heat message ON or OFF was typically delayed 7 minutes+ until the temperature changed again.
One of those annoying devices. We should get all of these poor features on the comments in the database to save others the pain of finding the same issue.
