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

Device has been woken up on battery and USB power 4x over a 4 minute period (two different power sources). The devices are ONLINE but it’s UNKNOWN. I have 4 of the same devices like this after the upgrade to latest JAR. Only 1 is working properly . . .

Best, Jay

Then you need to find out what is happening - check the debug logs as even if the device is not in the database, it will still be detected as it has nothing to do with the database.

Is the device waking up and being heard by the controller? What is shown in the log?

I get site not found with this link.

Node 2 looks fine - it has been detected as a thing ok, and node 5 is not communicating with the device at all. There are no wakeups in the log, so I’d suggest to try and wake it up with the device reasonably close to the controller.

Are you using batteries, or USB? I note that both devices show they are LISTENING which means they are are mains devices. Node 5 is however not responding to requests, which indicates that it is not currently listening (despite the fact that the controller thinks it is). This might explain the issue.

I’d suggest to exclude it, and ensure it is included in the power state that you intend to run it with (ie battery or USB).

I haven’t seen it mentioned in a while in this thread - if I currently have 2.3.0 do I still need to wipe all of my thing definitions before I upgrade to 2.4?

If yes, does anyone know of a way to script (maybe via the console) the re-creation of the items? I have dozens of devices that expand to well over 100 items, and I just went through creating all of them by hand as I upgraded from 1.8 to 2.3.0. Now that I realize that the door locks won’t work I’m faced with having to do it again…

Thanks!

Yes.

Yes:

Ok, tried that now and I can confirm that something is broken, I also get the little “ERROR: 404 - Not Found” popup and nothing more happens (the inbox discovery result is still there and no Thing is created). Also nothing useful in the log with debug on for the binding. I guess maybe there would be stuff in the log if debug would be turned on for some other component, just no idea which…

Did anyone report this as a bug anywhere?

Note that you should not need to delete all your items - only the things need to be regenerated. Of course, if the thing removes/changes channels, then you will have to do something, but if that’s the case it can’t be automated anyway :wink:

Please can someone get a dump of the inbox using the REST interface and I’ll see if I can work out how to reproduce it.

Something like this?

[
  {
    "bridgeUID": "zwave:serial_zstick:15f24d360d4",
    "flag": "NEW",
    "label": "Z-Wave Node 018: FGSD002 Smoke Detector",
    "properties": {
      "zwave_class_basic": "BASIC_TYPE_ROUTING_SLAVE",
      "zwave_class_generic": "GENERIC_TYPE_SENSOR_NOTIFICATION",
      "zwave_frequent": "false",
      "zwave_version": "3.3",
      "zwave_listening": "false",
      "zwave_deviceid": "4098",
      "zwave_routing": "true",
      "zwave_beaming": "true",
      "zwave_class_specific": "SPECIFIC_TYPE_NOTIFICATION_SENSOR",
      "node_id": 18,
      "zwave_manufacturer": "271",
      "zwave_devicetype": "3074"
    },
    "thingUID": "zwave:device:15f24d360d4:node18",
    "thingTypeUID": "zwave:fibaro_fgsd002_03_002"
  }
]

Yes - thanks, that’s exactly what I asked for… However, can I ask for something different (sorry)? Can you post the file DiscoveryResults.json from your {userdata}/jsondb folder? This would ensure I can replicate this reasonably easily (I think :wink: ).

Thanks
Chris

This is org.eclipse.smarthome.config.discovery.DiscoveryResult.json:

{
  "zwave:device:15f24d360d4:node18": {
    "class": "org.eclipse.smarthome.config.discovery.internal.DiscoveryResultImpl",
    "value": {
      "bridgeUID": {
        "segments": [
          "zwave",
          "serial_zstick",
          "15f24d360d4"
        ]
      },
      "thingUID": {
        "segments": [
          "zwave",
          "device",
          "15f24d360d4",
          "node18"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "zwave",
          "fibaro_fgsd002_03_002"
        ]
      },
      "properties": {
        "zwave_class_basic": "BASIC_TYPE_ROUTING_SLAVE",
        "zwave_class_generic": "GENERIC_TYPE_SENSOR_NOTIFICATION",
        "zwave_frequent": "false",
        "zwave_version": "3.3",
        "zwave_listening": "false",
        "zwave_deviceid": "4098",
        "zwave_routing": "true",
        "zwave_beaming": "true",
        "zwave_class_specific": "SPECIFIC_TYPE_NOTIFICATION_SENSOR",
        "node_id": 18,
        "zwave_manufacturer": "271",
        "zwave_devicetype": "3074"
      },
      "flag": "NEW",
      "label": "Z-Wave Node 018: FGSD002 Smoke Detector",
      "timestamp": 1535357263602,
      "timeToLive": -1
    }
  }
}

Thanks.

There were duplicate channels. I’ve fixed this and I’ve created a PR so that there is something logged, and also reported back to the user so it’s actually possible to find such issues in future.

There will be an updated binding in 5 minutes. [edit: done]

Yes, I kinda wondered about that (you saw my comment on the device?), seemed a bit weird with all those channels. Works like a charm now, thanks! :sunny:

edit: Btw, I guess this means it’s a good idea removing all FGSD002’s and readding them, right?

No, I didn’t. The comments aren’t something I normally look very often.

It’s the standard “problem” with ZWave - it provides many different ways of doing things and the database needs to be trimmed down to try and provide one way that works…

I’ve added more error checking into the database now so duplicate channels will raise an error.

Thanks for confirming and also providing the info earlier :slight_smile:

If they are working, then you probably don’t need to, but to keep everything consistent, I would recommend it.

1 Like

I can also confirm, that this is the same issue that I reported on Jul 26 and that it is now working.

https://community.openhab.org/t/oh2-z-wave-refactoring-and-testing-and-security/21653/3633?u=aradoorolesen

Remember to update the date of build at the top of this thread. It is still dated 23rd Aug. It would be great with at buiild number or date on the jar file.

Thanks,
Anders

1 Like

Thanks

Good point - thanks.

I just use the standard for OH2, so they are always the same name for snapshots. You can find the dates in Karaf though.

Just for the record: I think it’s very good that it always has the same file name, makes it easy to just fetch the file straight into the addons folder, overwriting the old version. Different file names would increase the risk of users screwing up by running multiple versions. Guess that won’t be a problem much longer though :slight_smile:

1 Like

Glad it got solved. Why it could be added as thing with those channels once but not readded once deleted is unclear for me… But hey… It works :slight_smile:

Thanks