ZWave binding updates

image

That can likely be controlled by the flexible openHAB, but not using the Z-Wave binding.

HTTP binding may work but you would need to figure out the configuration. There is a reason the cheap Chinese stuff is cheap.

It appears to be designed for their cloud server service. It is up to you if you want to send your information to China…

Have a look over here: Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide

I have my OpenHab installation running on a BHyve VM and it works like a charm with a remote USB stick on a Raspi attached to the ceiling.

1 Like

Typically boxes like this do not expose the ZWave devices or protocol - they expose their own UI and may have an external API that can be used. It will not however work with the ZWave binding.

1 Like

Is it possible to access zwave thing attribues ‘last_wakeup’ and ‘last_heal’ from openhab rules ?

Also, how can I enumerate attributes of specific thing?

The short answer is it’s no possible to access thing properties from rules.

The much longer answer is you could do it if you accessed the REST interface, but that’s not super simple.

1 Like

You can use REST, but this is entirely possible using scripted automation. Let me know if you’d like an example. I’ve also included a module for manipulating Things in the Jython helper libraries.

Just to point out that this is maybe a little “back door” and possibly might not work in future? I’m not sure how that works with the authentication that is now added to make this more secure? Have you tried it with the latest protected REST interfaces @5iver.

Scripted automation can access Things directly. I have not used the REST API in OH 3.0.

1 Like

Ah - cool - I didn’t know that :+1:

I’d be grateful if you can share one.

If not, I’ll go calling REST api from rules, as @chris suggested (thanks!)

I started a new topic for this…

2 Likes

@chris, after using scripted automation and having full access to zwave things configuration and properties I noticed two things which may be/are related to binding:

  1. zwave_lastwakeup property is present only on battery powered things. There is no such property on constantly powereed things with date of last communication. There is no any other property with ‘last communication’. Can you add something like that? This would be very helpful one. Either thing property or thing status?

  2. I found one battery operated thing, (which works correctly), but binding is showing zwave_lastwakeup property at all on this thing:

    2020-08-23 23:31:08.593 [WARN ] [jsr223.jython.TEST                      ] - 
    thing.label: zSensor Hackerspace
    thing.UID: zwave:device:zwave:node9
    thing.configuration: Configuration[{key=binding_cmdrepollperiod; type=BigDecimal; value=1500}, {key=config_41_3_00FFFF00; type=BigDecimal; value=0}, {key=config_100_1_wo; type=BigDecimal; value=0}, {key=config_201_2; type=BigDecimal; value=1}, {key=config_202_1; type=BigDe
    cimal; value=0}, {key=config_203_2; type=BigDecimal; value=0}, {key=config_204_1; type=BigDecimal; value=0}, {key=group_1; type=ArrayList; value=[controller]}, {key=action_reinit; type=Boolean; value=false}, {key=config_201_2_0000FF00; type=BigDecimal; value=0}, {key=confi
    g_112_4; type=BigDecimal; value=3600}, {key=wakeup_node; type=BigDecimal; value=1}, {key=config_39_1; type=BigDecimal; value=20}, {key=config_113_4; type=BigDecimal; value=3600}, {key=config_111_4; type=BigDecimal; value=3600}, {key=config_41_3_0000000F; type=BigDecimal; v
    alue=4}, {key=config_42_1; type=BigDecimal; value=10}, {key=config_201_2_000000FF; type=BigDecimal; value=1}, {key=config_43_2; type=BigDecimal; value=100}, {key=config_44_1; type=BigDecimal; value=10}, {key=config_41_3; type=BigDecimal; value=20}, {key=config_40_1; type=B
    igDecimal; value=0}, {key=config_252_1; type=BigDecimal; value=0}, {key=action_failed; type=Boolean; value=false}, {key=wakeup_interval; type=BigDecimal; value=3600}, {key=config_110_1_wo; type=BigDecimal; value=0}, {key=config_255_4_wo; type=BigDecimal; value=0}, {key=act
    ion_remove; type=Boolean; value=false}, {key=binding_pollperiod; type=BigDecimal; value=43200}, {key=action_heal; type=Boolean; value=false}, {key=config_2_1; type=BigDecimal; value=0}, {key=config_101_4; type=BigDecimal; value=241}, {key=config_102_4; type=BigDecimal; val
    ue=0}, {key=config_9_2; type=BigDecimal; value=0}, {key=config_46_1; type=BigDecimal; value=0}, {key=config_3_2; type=BigDecimal; value=240}, {key=config_4_1; type=BigDecimal; value=5}, {key=config_45_1; type=BigDecimal; value=2}, {key=config_5_1; type=BigDecimal; value=1}
    , {key=config_103_4; type=BigDecimal; value=0}, {key=node_id; type=BigDecimal; value=9}]
    thing.properties: {zwave_class_basic: BASIC_TYPE_ROUTING_SLAVE, zwave_class_generic: GENERIC_TYPE_SENSOR_MULTILEVEL, zwave_neighbours: 1,24, modelId: ZW100, zwave_version: 1.7, zwave_plus_devicetype: NODE_TYPE_ZWAVEPLUS_NODE, versionMin: 1.7, vendor: AEON Labs, defaultAsso
    ciations: 1, zwave_routing: true, zwave_beaming: true, commandClass:COMMAND_CLASS_SENSOR_MULTILEVEL: supportedGetSupported=false, zwave_secure: false, zwave_class_specific: SPECIFIC_TYPE_ROUTING_SENSOR_MULTILEVEL, zwave_devicetype: 2, zwave_frequent: false, versionMax: 1.7
    , zwave_listening: true, manufacturerId: 0086, manufacturerRef: 0002:0064,0102:0064,0202:0064,1A02:0064, dbReference: 355, zwave_deviceid: 100, zwave_nodeid: 9, zwave_lastheal: 2020-01-17T04:03:26Z, zwave_plus_roletype: ROLE_TYPE_SLAVE_SLEEPING_REPORTING, zwave_manufacture
    r: 134}

That is correct - only battery powered devices support wakeup. Mains powered devices are permanently awake.

Maybe it has not woken up? Is wakeup actually set.

Please note that wakeup is a specific function of battery devices - they can work perfectly normally (ie send data) without ever waking up. Wakeup is only required to configure the device.

1 Like

I got it, yet we don’t have information about last time thing was communicating with us, while we have multiple not so useful information (dbreference, zwave_version, etc). There is no way to get this information currently to detect missing/broken nodes, other than parsing zwave debug log AFAIK.

Would it be possible to add it? For example additional field on status, would be perfect (curl -X GET --header "Accept: application/json" "http://ohpi/rest/things/zwave%3Adevice%3Azwave%3Anode6/status"
).

Wakeup is set to 3600. Device is working ok (sending messages, it’s a multi sensor, so quite a lot of traffic in day). As far as I can see, thing.properties do NOT containt zwave_lastwakeup parameter for this thing. it has plenty possibilities to send wakeup, however I can not exclude possibility that it does not as this is the only thing of this type in my network.

the only message in debug log grepped for ‘wake’ for this node:
d23 20:44:56.100 [.ZWaveCommandClass] - NODE 9: Command class COMMAND_CLASS_WAKE_UP, endpoint 0 created

This has been discussed in the past, and I think there are ways to record the time that a channel was updated already?

Anything is possible, but it’s not something that I’m likely to add myself - there’s simply too many other things to do - sorry.

I guess the device is not waking up then? It’s difficult for me to say a lot more, but if the last wakeup time is not set, and there are no wakeups in the log, that points to the device not waking for some reason. Maybe it didn’t get set during initialisation - you could try reinitialising this parameter and manually waking the device.

It would be possible, but needs much more spaghetti code to catch all channels on all device to detect this.

I would probably go for using zwave_lastheal if daily heal works correctly in last binding version, does it?

The other option, IIRC, I can use sendCommand(“REFRESH”) and try to check lastUpdate sometime later, on carefully selected items (one per thing).

I understand. Would you like to accept PR or simple wanted tester for this anytime in the future, just let me know.

Thanks, I will try it.

1 Like

Can’t you just use persistence for example? Won’t that give you the last time a channel was updated? If you configure persistence for record the update you should be able to get the time the channel was last updated?

I’m a little loath to add this sort of function to the binding as (IMHO) it’s a more generic thing that if OH wanted this sort of feature, then it should be in the core rather than being implemented in every binding.

2 Likes

@rdsiw, what are you trying to accomplish? I sounds like you might be trying to automate a notification when Z-Wave devices are not communicating. You could trigger a rule when the Thing status changes or a Channel triggers. You wouldn’t need to use rules for this though, if you used a timestamp-update or timestamp-change profile.

1 Like

@5iver has pointed to the documentation already, and I found this forum post very useful for implementing something very similar:

Design Pattern: Time of Last Update

Thanks Guys, your links helped me to verify all possible solutions and choose the best one.

My need was, in a relative modest installation of around hundred z-wave things, each having on average 6 channels, to be able to monitor all of things if they’re simply working (not channels, things).

I wanted to avoid doing it per every thing, as this would be too much hardcoded rules, plus (more importantly) much more to remember maintain in the future. This requirement excluded solutions:

  • timestamp-update/change -> requires additional item per channel
  • time of last status update -> reauires one additional item per thing
  • DSL rule “when Thing ‘NAME’ received update” -> requires one rule per every thing (there is no ‘memberof’ for things).

The only solution at the moment is to use NGRE and generic ThingStatusInfoChangedEvent as desribed here: Monitoring Thing Status which can be used with Jython rules.

If someone has small installation and is not afraid of having additional item per thing for communication monitoring here is a good start: Monitoring Things (Status).