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

[sihui]

@darkbeer

if this is broken

This is an excerpt from my former - working - things config, maybe it helps:

Bridge zwave:serial_zstick:controller "Z-Wave Serial Controller" [ port="/dev/ttyACM0", controller_softreset="false", controller_master="true", controller_inclusiontimeout=60, heal_enable="true", heal_time=2, security_networkkey="whatever" ]
Thing zwave:popp_004001_00_000:controller:node10 "Z-Wave Node 10: 004001 Smoke Detector and Siren" (zwave:serial_zstick:controller) [ node_id=10 ]
Thing zwave:fibaro_fgrm222_24_024:controller:node11 "Z-Wave Node 11: FGRM222 Roller Shutter" (zwave:serial_zstick:controller) [ node_id=11 ] {
Channels:
Type blinds_control : blinds_control [ config_invert_percent="true" ]
}

[darkbeer (Amar Takhar)]

Thanks it does not my configs are the same. I’ve started building the zwave binding from scratch rewinding using Git. I went back a week with no luck I’ll go back a month if it works I’ll bisect.

[chris (Chris Jackson)]

My guess is that the problem isn’t in the binding (but I could be wrong). I’m pretty sure that people are using this at the moment, and if I check the code, the reading of the node_id is the first real line of code in the initialise method. If you have the compiler running, it should be pretty obvious if it’s working by setting a breakpoint on that line and checking the config.

Good luck .

[darkbeer (Amar Takhar)]

OK I’ll try running it under a compiler. Can you give me a tip on what line to break at? I’m not suggesting it’s your binding that’s the issue but at the end of the day the ID isn’t being read which is what I’m trying to debug. I’ll hack away at it tomorrow I’ve got no issues going deeper into this just looking for tips…

Also, the comments I’ve seen for people running it in this way was before the addition of being able to modify config items via the paper UI when configuring via text. From what I have found anyway. This is why I asked on here as I found no examples of anyone making this work since the major changes have happened. I’ll look into it deeper tomorrow thanks for the feedback!

[sihui]

@darkbeer

my configs are the same.

Nope. You have an additional node_id=1 in your bridge config.

[chris (Chris Jackson)]

@darkbeer

Can you give me a tip on what line to break at?

Look in the ZWaveThingHandler - right at the top is the initialize() method, and almost the first line is the line that reads the node ID from the configuration.

Remember as well that the binding doesn’t read the config files - it gets the configuration from the system so the binding doesn’t know if the configuration comes from the config file, or PaperUI/HABmin configuration.

@darkbeer

Also, the comments I’ve seen for people running it in this way was before the addition of being able to modify config items via the paper UI when configuring via text

No - there are people using the new system. OH2 was never able to configure things with text files until this version. See also this thread -:

ZWave Manual Thing Configuration

This write-up provides a “how-to” to actually get this configuration completed for Z-Wave for those that don’t want to use the automatic configuration that the binding provides. Z-Wave things can be configured in the same way as other OH2 bindings - for general information refer to the OH2 documentation. Note that at the time of writing, text configuration of things is only available in the development version of the binding - not the master or snapshot versions. At the time of writing, there …

[darkbeer (Amar Takhar)]

OK, So I installed Eclipse and used remote debugging. I set a breakpoint where it requests the NodeID. After that I went and observed the thing that was returned. In the properties array I found the node_id value and it’s correct at ‘2’. Yet, the NodeID value in the zwave plug-in is null.

I will look into this more but it seems your initial thought about the bug being in OpenHAB was correct. I will probably try to get an older snapshot of OH to see if it works I’ll first play around with this a bit since I have it open.

Update: It was an OH bug, I went to jfrog and got the oldest snapshot dated 2017-10-05 (openhab-2.2.0-20171005.012724-78.zip). If I have time I’ll hop back into the debugger and see if I can figure out what’s different.

[sihui]

@chris

The hassle here is that (I think) the REST server is probably eating the exception, and just passing the 404 (or 500, or whatever) error to the REST response, so we don’t actually have any log of what is causing the underlying problem .

I’ll see if I can find a way to improve the ESH logging here so we can see what’s happening.

I’m getting the same error on all of my 20 devices, unfortunately no errors in debug log:

2017-10-11 16:31:22.817 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:15ca6a108b9:node10/config' for thing 'zwave:device:15ca6a108b9:node10': null

zwave development binding version 2.2.0.201710012213

This is how it looks in PaperUI: the association group is bound to node 1 (which in fact is the controller). Trying to set it to “openHAB Controller” via PaperUI gives again the same error in openhab.log.

[vossivossi]

@sihui

I’m getting the same error on all of my 20 devices, unfortunately no errors in debug log:

2017-10-11 16:31:22.817 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at ‘things/zwave:device:15ca6a108b9:node10/config’ for thing ‘zwave:device:15ca6a108b9:node10’: null

zwave development binding version 2.2.0.201710012213

I can confirm this behaviour. I noticed that one of my dimmers did not update its state in the UI when I switched it manually by physical switch. So I decided to have a look at the associations if association group 1 for controller updates was set to the controller. In Habmin it shows that it apparently is set correctly:

However, looking at the same node 160 in PaperUI tells a different story:

So obviously one of the two is not telling the truth. The reporting from PaperUI would explain the dimmer’s behaviour (assocaition group 1 is initial, not set to controller).
However it is indeed not possble to set the association neither with Habmin nor with PaperUI.

The exception in OHLOG is:

2017-10-11 20:30:55.845 [ERROR] [ome.io.rest.core.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:ZWOG:node160/config' for thing 'zwave:device:ZWOG:node160': java.math.BigDecimal cannot be cast to java.lang.Integer

@chris : Do you have any idea?

I am using OH Snapshot 1036 with Zwave Dev Binding version 2.2.0.201710012213.

[chris (Chris Jackson)]

@vossivossi

However, loogin at the same node 160 in PaperUI tells a different story:

I suspect that PaperUI doesn’t handle this interface correctly. If you check the configuration file, what does it show?

[vossivossi]

The xml file in the Zwave folder?

<associationGroups>
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <associations>
          <associationMember>
            <node>1</node>
            <endpoint>0</endpoint>
          </associationMember>
        </associations>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <associations/>
      </associationGroup>
    </entry>

If I pasted the correct detail from the XML it seems to say indeed that node 1 is member of associations group 1.

[chris (Chris Jackson)]

@vossivossi

The xml file in the Zwave folder?

No - the configuration - either from the configuration file (ie the json) or the REST interface. That said, the XML shows that the association is set.

[vossivossi]

Ok, in the JSON file it has the same info:

 "group_1": [
            "node_1_0"
          ],

[vossivossi]

@chris

or the REST interface

How can I acces this?

[chris (Chris Jackson)]

Just go to the dashboard and select the REST interface. It might be easier to look in the json file though if you’re not familiar.

[chris (Chris Jackson)]

@vossivossi

Ok, in the JSON file it has the same info:

Same info as what? It looks ok right?

[vossivossi]

@chris

Same info as what? It looks ok right?

Yes it looks correct. Same info as in the xml file and as in Habmin.

[5iver (Scott Rushworth)]

The items that I have that through errors when saving associations (newly added or had the associations removed and readded) are missing <endpoint>0</endpoint> in the associationGroups section of the xml. In spot checking some of my other devices, I am finding some others that I do not recall touching that are also missing <endpoint>0</endpoint>. The jsondb file shows the same as the xmls.

  <associationGroups>
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <associations>
          <associationMember>
            <node>1</node>
          </associationMember>
        </associations>
      </associationGroup>
    </entry>
  </associationGroups>

  "group_1": [
    "node_1"
  ],

[chris (Chris Jackson)]

The missing endpoint is perfectly ok in itself. There are just different ways to set associations (multichannel, or the normal association class, and the multichannel has 2 options in itself).

Really it’s hard to say what’s happening without the log showing the error, which appears to be an issue. I’ll see if I can find this tonight.

Edit:

Thing REST config exception logging

[5iver (Scott Rushworth)]

I get the same error but with a 500 error response when I send this in the body through the REST UI or from command line:

{"group_1":["node_1_0"]}

But this goes through without error:

{"test_1":["node_1_0"]}