OH2 Z-Wave refactoring and testing... and SECURITY

I believe that you can help here by providing the device xml
The listing exists here: http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/702

but I think that it is not working since it is missing info (and as a result, it is not approved).

In addition to the information provided by @Dim, I can also say that adding the device to the database won’t change how it is included. If it’s included unsecurely for some reason, then this will not change by making any changes to the database so you’ll need to work out why it’s not securely included.

Or, is this a controller? (It’s a bit hard to tell really). If it is, then adding it to the database is not relevant as the database is not used for controllers.

I have a Devolo MT02792, a switchable meter plug, running openHAB 2.3.0~RC2-1 (Milestone Build)
I linked 2 channels DevoloMT02792ZWaveNode2_ElectricMeterKWh and DevoloMT02792ZWaveNode2_ElectricMeterWatts
In HABmin/PaperUI i can see the value of both channels, so far so good
In Basic UI i can’t see the value of ElectricMeterWatts, so i looked up the differences in REST and noticed that the watts channel is missing the stateDescription

How or better where can I add the stateDescription to the watts channel?

  "link": "http://openhab:8080/rest/items/DevoloMT02792ZWaveNode2_ElectricMeterKWh",
  "state": "16.88",
  "stateDescription": {
    "pattern": "%.1f",
    "readOnly": true,
    "options": []
  "editable": true,
  "type": "Number:Dimensionless",
  "name": "DevoloMT02792ZWaveNode2_ElectricMeterKWh",
  "label": "Beamer - Electric meter (kWh)",
  "category": "Energy",
  "tags": [],
  "groupNames": [
  "link": "http://openhab:8080/rest/items/DevoloMT02792ZWaveNode2_ElectricMeterWatts",
  "state": "225.7",
  "editable": true,
  "type": "Number:Dimensionless",
  "name": "DevoloMT02792ZWaveNode2_ElectricMeterWatts",
  "label": "Beamer - Electric meter (watts)",
  "category": "Energy",
  "tags": [],
  "groupNames": [

Thank You!

Just to note that RC2 will not contain the security features discussed in this thread.

The binding provides this normally, so I’m not sure why it’s not here in this case.

does this mean that in the coming 2.3 stable release this zwave security build is not included and still needs to be installed manually?

Yes, that’s correct. I will look to merge this soon.

1 Like

today I upgraded to 2.3 stable release. now I want to troubleshoot my errors which I thought that it was because I was running oh2.2 with the zwave 2.3 security snapshot binding. but it seems not.

first (new) error after upgading to 2.3 (not sure if its regarding zwave): to all my nodes I get an info loggin

2018-05-28 20:13:08.830 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 2: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 3: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 4: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 5: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 6: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 7: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 8: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 9: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 10: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 11: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 12: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 13: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 14: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 16: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 17: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 19: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 20: Node found
2018-05-28 20:13:08.835 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 21: Node found
2018-05-28 20:13:08.835 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 22: Node found
2018-05-28 20:13:08.835 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 23: Node found
2018-05-28 20:13:08.836 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 24: Node found
2018-05-28 20:13:08.836 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 25: Node found
2018-05-28 20:13:08.837 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 29: Node found

but all nodes are working, also showing as online.

coming now to the error logging:

2018-05-28 20:13:19.381 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 8: AssignSucReturnRoute command failed.
2018-05-28 20:13:19.385 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 6: AssignSucReturnRoute command failed.

on some nodes this message appear. on oh2.2 the error message looked like this

2018-05-28 19:57:12.182 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 19: Assign SUC return routes failed.

I think that could be a reason why I’m running into some problems with my fibaro switchs (and association groups), that the current state of the switch sometimes doesnt get reported back correct. sometimes I need to reconfigure on my switch the association group (although it was already defined correct). Also in habmin the lifeline group was on 90% of switch empty after saving the openhab controller into it and refreshing habmin (never understood this).

any idea?

This is not an error. It’s just saying that the node is found.

Yes - that’s what the log says - they are found ok.

I will reduce these messages to debug so that they are removed from normal logging.

Why do you think it’s related? Personally, I doubt it, but maybe I’m wrong. This “error” is the failure to set the SUC return route, but it is VERY unlikely to cause any problem unless you have multiple controllers in your network?

Do you mean Fibaro Single/Double Switch 2 (ie FGS-213/FGS-223) or Fibaro Relay Switch (ie FGS-212/FGS-222)? And were they first included using the development binding?


oh man… thats embarrassing :S I dont know why… I read “Node not found” in the log file… maybe it was regarding my evening beer :joy: I’m sorry …

regarding suc return route log:
I dont have any rational explaination why I thought that. I dont even now what suc and sis is. It’s just, because I had a problem with zwave states and there are error messages with terms like suc (which seems to be sth controller relevant) and return route. But after your statement I dont believe anymore.

I’m using and talking about Fibaro Doubleswitch. That is a good question with what zwave binding I included them! I dont really remember :confused:


1 Like

I’ve created a new TEST binding here. This has some changes that might cause problems as I’ve made some mods to change the way dead nodes are handled and messing with the low level transaction code is always a little dangerous.

If you’re feeling adventurous, then please feel free to give it a go and report back :slight_smile: . This is one of the last major changes I want to make before I can merge the dev binding into master so it would be good to iron out any issues…

1 Like

testing now

quick question: Is the Bridge name editable?
I see zwave:serial_zstick:512 but I can’t change the 512 part.
If I remember well, I was able to specify the bridge name (I have all my items linked to channel names)
Maybe I am doing something wrong :stuck_out_tongue:
OH 2.4 S1292

You can set it on startup, but I’m not sure you can go around changing it (I think it’s meant to be immutable). This isn’t anything to do with the binding though - it’s up to the core…

Correct. Maybe something changed in OH 2.4 core… If I remember well, I was able to modify that part. Anyway… no worries…

Continuing the tests now

I did a quick test and half of my devices, even mains powered, were reported as dead. Had to roll back due to house guests, but will test more (and get some logs) over the weekend.

Quick question: does the latest 2.3 version (from the top of this thread) work with 2.4 snapshot?
In other words is it safe to upgrade to OH 2.4?
I mean are there any breaking changes in 2.4 core? I did upgrade to 2.4, but zwave did not resolve due to missing guava dependencies. I know there was a plan to remove guava from OH, so maybe this happened in 2.4?


Remember - all that is changed is the number… Last week it was numbered 2.3, now it’s numbered 2.4. It’s still basically the same thing…

Really - I’ve not seen that issue. ZWave doesn’t use guava so I don’t know why this would have been the case :confused: . There were some other missing dependencies relating to UoM and USB, but that was due to new features and these are in 2.4 anyway.

That’s what I thought.

It has been mentioned in this thread too. But it wasn’t an issue with the binding itself, it was enough to just reinstall it. I will do that today, yesterday it was really late, so I just gave up. Now that you confirmed it should work, I will try to reinstall the binding, hopefully all the issues will gone. :slight_smile:

I think that was a change of ESH - they changed a definition of a protected field from static (from memory) and that made it binary incompatible, so needed to be reinstalled. At least that wasn’t guava related, but maybe there was something else that I didn’t know about… If I search this thread for guava, there is basically nothing other than our mails this morning (and one message from 12 months ago which is I think unrelated).

I think it’s ok in any case :wink: .