BatteryLevel cache file changes

[gizmocuz]

In the new OZW 1.6 library the cache file has been renamed. Also Domoticz is not storing/writing the cache file anymore to the disk, the driver does this, and only when needed. This means the battery levels won't be up to date anymore

In Domoticz 11023 i added a new JSON function to retreive the actual battery levels for each node:

json.htm?type=command&param=zwavegetbatterylevels&idx=3

where idx is the zwave hardware index

This returns a list of all nodes with the current battery levels.

Where level = 255, means no battery level received, or a node that does not support it (powered node) Else the range is whats being receive (0-100%)

[999LV]

@gizmocuz ,

Many thanks. I’ll update the plugin to take advantage of this new feature !

[Bewo]

Hi guys, thanks for working on all the great projects... :-)

For me, the plugin doesn't work anymore.... Actually i'm on Domoticz 11069 and battery plugin 0.5.1 but the battery devices shows no actual levels... And domoticz shows only level 255...

This is the json request:

This are the devices in Domoticz: (old but they turned NOT red)

And here the same devices in the Zwave-Configuration:

[999LV]

Yes, I need to look into this when back from vacations... on top of it, all my zwave devices are on production systems and I am not yet happy enough with OZW 1.6 implementation to upgrade these production systems and work on upgrading the plugin (getting many errors similar to https://www.domoticz.com/forum/viewtopic.php?f=24&t=28821&p=220204&hilit=This+size#p220204). But I will follow up in due course when ready to move to OZW 1.6. Please bear with me.

[Bewo]

No hurry -> Have a nice vacation! :-)

[gizmocuz]

@Bewo, do you know if you 'received' the battery status from the nodes before calling the json function ? Does the battery levels in the devices tab show the correct level ?

[Bewo]

@gizmocuz, you're right, the json call works. Sorry, i restarted Domoticz before the first screenshot. Now it shows the right values...:

The battery-devices (from the plugin) shows old levels but curiously the don't turn red. (It's live the same as in the screenshots above.)

[gizmocuz]

That is because it's a event/switch. And because switches do not periodically send status updates, it should not turn red. For temperature sensors, they should turn red when they are not received for a period of time. But this is not related to the battery It seems all works correctly and we can close this issue ?

[Bewo]

No, we can't. :-) The new Domoticz-JSON-call works, but the devices are NOT updated. So the plugin doesn't work actually. It's looking for the cache file -> and this is missing in 1.6 as you mentioned.

Wouldn't it be better to define the battery devices as an sensor? This aren't switches. And they shown in the utility page. Named as type: "General, Custom Sensor". So in my opinion it would be more consistent if they turn RED after the set time period. So everybody see's at a glance that something is not working.

[999LV]

@Bewo ,

The plugin uses custom devices, not switches, and time out is not yet implemented (because I wrote the plugin when the plugin framework did not yet handle this) but this is easy to do.

Version 0.5.1 is meant to read the new ozwcache_0x????????.xml file introduced in OZW 1.6 if it exists... what I do not know, but please confirm, is that ozwcache_0x????????.xml indeed contains up to date battery levels... again I do not want to upgrade my production systems with zwave yet, so feedback is welcome (Gizmocuz implied that the new OZW cache file is no longer updated, but other users have told me the plugin was working fine, so I welcome a definite response).

Based on this feed-back, I will modify the plugin as needed when a) I am back from vacations and b) I feel comfortable upgrading to OZW 1.6 so that I can test.

[gizmocuz]

@999LV , about battery levels, no the cache file does not contain up2date levels as it is not written to disk anymore (only when needed). (as mentioned/specified in the OZW 1.6 API) Therefor i created the new JSON call which returns the latest values Also the JSON returns the correct level, even if the cache file was written to disk every hour, the return data from the JSON is always correct

Ohhh and go enjoy your holiday !!! ;)

[FearNaBoinne]

A quick fix for OZW 1.6+ seems to be to change "node[1]" to "node[2]" in plugin.py... The commandclasses seem to have moved down 1 index!

But as ozwcache only gets written on system start, it's useless otherwise...

[FearNaBoinne]

And going to json.htm?type=command&param=zwavegetbatterylevels&idx=3 makes my OpenZWave crash... (But that is probably something to go in to a different GIT issue! )

[Bewo]

Did you change the idx to your's? I can confirm that domoticz crashes, if you use a false idx. With the correct idx the json call works like a charme.

[FearNaBoinne]

Thanks! I'm daft for trying to do this stuff late in the evening, and misread... I thought the hardware idx was the index of the zwave device in the zwave config, not the idx of the actual OpenZWave device itself!

json.htm?type=command&param=zwavegetbatterylevels&idx=8 (8 = idx of the Aeotec Z-Wave USB stick) works... However I only see 2 devices with a battery level:

But there are 3 devices (idx 1, 6 & 7, nodeID's 3, 11 & 18) that provide battery level information according to the ozw cache file: root@raspi-domoticz:/opt/domoticz# grep 'label="Battery Level"' Config/ozwcache_0xd163c951.xml <Value type="byte" genre="user" instance="1" index="0" label="Battery Level" units="%" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="100"> <Value type="byte" genre="user" instance="1" index="0" label="Battery Level" units="%" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="100"> <Value type="byte" genre="user" instance="1" index="0" label="Battery Level" units="%" read_only="true" write_only="false" verify_changes="false" poll_intensity="2" min="0" max="255" value="51">

(PS @Bewo : Can you please add a hardware type check before executing the command and return a "not an openzwave device" error instead of crahing Domoticz? Or tell me where approx I can find the code, so I can modify it myself and - assuming it works - send that back in to the repo?)

[gizmocuz]

@FearNaBoinne , you might have to wait until an actual battery value is received for those 'other' sensors

[FearNaBoinne]

As you can see, the battery for the missing one is down to 51%, so I would expect at least one value to have been sent/received... But I'll keep an eye on it...

[gizmocuz]

@FearNaBoinne , you could enable the debug logging for the controller (not to long! Generates a long log file), and check the log (in the config folder) if COMMAND_CLASS_BATTERY is received for this node I expect not...

[FearNaBoinne]

I have 12 hours of debug log (800k), but not a single COMMAND_CLASS_BATTERY in there, not even for the two devices that ARE showing a battery state... (Unless, for whatever reason, the debug enable didn't take.)

The ozwcache*.xml file OTOH DOES have COMMAND_CLASS_BATTERY entries for the three devices mentioned above, as mentioned above...

[gizmocuz]

@FearNaBoinne , well that explains a lot... there is no battery level/value received. Fine that your config file indicated a battery value , an old value, useless Not sure what type of node you are using, but there is probably a configuration setting that you can enable to let it send battery status ? Ps. Better search for 'battery' instead of COMMAND_CLASS_BATTERY

[FearNaBoinne]

Neocam 3-in-1 sensors, Aeotec keyfob and A siren of which I forgot the brand and cannot check right now! None of them have a parameter like that, and at least the Neocam and siren have successfully sent battery data in the past... And i wonder where the 51% of the keyfob in the ozwcache has come from then?!...(It must have received battery info at least once for ozwcache to have the class info and historic data record) Anyway, not here to have a discussion on semantics... Point is: Domoticz shows battery status for all three of them in the devices screen, and the above command doesn't show battery data for one of them...

I will reboot the RasPi later today and retry debug mode... looking at the logfile I only see startup info and errors about one dead node (which I still need to figure out why it is dead) and that's it, so I really think the debug mode didn't work...

[999LV]

@FearNaBoinne , please open an issue in domoticz forum or github to continue discussing the issues you are having and avoid "polluting" the plugin's github space with an unrelated issue.

@gizmocuz ,

Finally got some time to look into upgrading the plugin. I noted the new API call "zwavegetbatterylevels" only returns nodeID and batValue, but not node Name, which the plugin needs to have a user friendly name to display. To get the name, the plugin would not only need to call "zwavegetbatterylevels" to get nodeID and batValue but also call "openzwavenodes" to get node name.

I looked into OpenZWave.cpp and I cannot think of an easy way to return the node name with that "zwavegetbatterylevels" API call... could not think of anything simple. However it seems easy to add the batValue to the json returned by "openzwavenodes" if I am not mistaken. What do you think ?

[gizmocuz]

@999LV , the names are stored in the internal database In the next beta (current development code), the name is also provided:

{
   "result" : [
      {
         "battery" : 255,
         "nodeID" : 1,
         "nodeName" : "Controller"
      },
      {
         "battery" : 255,
         "nodeID" : 3,
         "nodeName" : "Unknown"
      },
      {
         "battery" : 255,
         "nodeID" : 2,
         "nodeName" : "Unknown"
      },
      {
         "battery" : 255,
         "nodeID" : 4,
         "nodeName" : "Unknown"
      },
      {
         "battery" : 255,
         "nodeID" : 10,
         "nodeName" : "MyPhilio PST02-A"
      },
      {
         "battery" : 255,
         "nodeID" : 11,
         "nodeName" : "SomeName"
      }
   ],
   "status" : "OK",
   "title" : "GetBatteryLevels"
}

[999LV]

Many thanks @gizmocuz ! Will now update the plugin and test !

[999LV]

@gizmocuz ,

Turns out we are not yet done... I updated domoticz and the plugin successully, but unfortunately I realized that the zwavegetbatterylevels API call keeps returning battery values of 255 for all zwave nodes, even those that are really battery powered where battery value should be between 0 and 100... and the openzawe control panel shows the correct battery values...

[gizmocuz]

@999LV , and are there already real battery values received in the system from the nodes ?

[999LV]

@gizmocuz , not sure about that. But does it matter ? OZWCP and also the cache file show the proper battery levels, so I would expect domoticz to pick these values ?

Note that my only zwave systems are production ones and I just upgraded briefly to OZW 1.6 for testing your new API (I revert to stable afterwards since I still cannot figure to have my Fibaro Buttons switches working with recent betas of domoticz, but that is a separate issue)

[gizmocuz]

@999LV , yes this does matter a lot ! The values are 'updated' internally, when there have been a 'update' received from OZW, before that, the value could by quite wrong as well I could force it to take the 'add value' value, but currently it is only available after the node has send it, until then, do not update anything internally

[999LV]

I updated the plugin to work with the new API call. Version 0.6.0. Thanks again @gizmocuz !

[Bewo]

Works fine! Thanks guys!!! @999LV @gizmocuz