Problems including battery devices with OH3

I know that inclusion of battery devices in OH was always a gamble but with OH3 (3.1.0) for me it doesn’t work at all same devices working in OH2 for years. I wonder if this is something I’m doing or problem with the binding. Here’s my scenario: brand new z-wave network with only controller as device 1, two z-wave devices Aeotek TriSensor and Aeotek NanoMote. I’ve attempted both secure and non-secure inclusion, both devices included with controller and show up as things but never finished “interview” and never created XML serialized file. Attempts to wake up the devices somehow moving interview to a certain point. Both devices can be kept awake but that just does nothing, controller doesn’t see them as available for interview. It seems like both devices stuck on “Group Association” stage and not advancing further no matter how many times they woke up.

Deleting “thing” and recreating without exclusion immediately brings device forward in the interview, number of properties jumps to +10 on thing properties, channels created but still no XML and no polling on the device.

Going to try another clean inclusion tonight.

Debug logs attached, node 7 is TriSensor and node 8 is NanoMote:
node7_inclusion_p1.log (539.0 KB)
node7_inclusion_p2.log (631.0 KB)
node8_inclusion_p1.log (798.1 KB)
node8_inclusion_p2.log (238.9 KB)

Any advises welcome!! Thank you community!

Battery operated devices are a challenge with the zwave binding. It is a little more complex but you could use zwavejs2mqtt and he OH mqtt addon with Mosquitto broker. In my testing zwavejs2mqtt fully interviews (discovers) battery devices even it it takes the device hours to wake up sufficiently.

After consulting with Chris, I’ve fixed issues myself. So here’re a few recommendations for including battery devices:

  1. Do not use security for devices other then locks / gate controllers or so. (Locks are usually battery powered but they are not regular devices and have to be included with security)
  2. Pay attention to the wake-up node in the thing configuration, it should be set to controller node (usually 1 with simple setup). If it is not set controller won’t respond to wake up events and won’t finish initialization. No need to re-include just simply set it to 1 or whatever is your controller node, wake up device and check log that it is reporting.
  3. Check wake-up time. Usually wake-up time could be set to a very high number. I set it to 28800 (8 hours) but could be even higher, the only downside is the time to save configuration to the device but I doubt that is a regular thing. For initialization you can set this time for a shorter period, usually there’re some limitations and minimum is 1800, if you wish just set it to that and leave the device it will initialize after a few wakeups, after that you can set configuration and change wake-up time to something bigger. If you don’t want to wait just wake your device manually (refer to the manual) but don’t wake up for longer period. Just do a simple “NIF send”, that would be enough. Also you can do “NIF send” if you want to update config and don’t want to wait for wake up. Some times you need to do that multiple times. Note: that wake-up time has nothing to do with device operation, it is only to read and send config to device.

Hope this will help somebody and Thank you, Chris!!

2 Likes

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.