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

This device is definitely in the database, but to know if your have a special variant, we need to know what it is.

Please provide the device IDs for your device (device type, device ID and firmware version).

Hereā€™s some info from the OLD working zWave XML files specā€™s for the one of the devices that is set to UNKNOWN now with your newer binding.

<manufacturerSpecificCommandClass>

<version>1</version>

<instances>1</instances>

<versionSupported>2</versionSupported>

<initSerialNumber>false</initSerialNumber>

<deviceManufacturer>134</deviceManufacturer>

<deviceType>258</deviceType>

<deviceId>100</deviceId>

</manufacturerSpecificCommandClass>

<firmwareUpdateCommandClass>

<version>1</version>

<instances>1</instances>

<versionSupported>2</versionSupported>

</firmwareUpdateCommandClass>

<manufacturer>0x86</manufacturer>

<deviceId>0x64</deviceId>

<deviceType>0x102</deviceType>

<commandClass>ZWAVE_PLUS_INFO</commandClass>

<zwavePlusCommandClass>

<version>1</version>

<instances>1</instances>

<versionSupported>2</versionSupported>

<zwPlusVersion>1</zwPlusVersion>

<zwPlusRole>5</zwPlusRole>

<zwPlusNodeType>0</zwPlusNodeType>

<zwPlusDeviceType>0xc07</zwPlusDeviceType>

<zwPlusInstallerIcon>0xc07</zwPlusInstallerIcon>

<isGetSupported>true</isGetSupported>

</zwavePlusCommandClass>

<versionCommandClass>

<version>2</version>

<instances>1</instances>

<versionSupported>2</versionSupported>

<libraryType>LIB_SLAVE_ENHANCED</libraryType>

<protocolVersion>4.54</protocolVersion>

<applicationVersion>1.10</applicationVersion>

<hardwareVersion>100</hardwareVersion>

</versionCommandClass>

Hope this is what you need.

Best, Jay

This means that it hasnā€™t completed initialisation - please wake up the device so it can complete and hopefully it should be ok.

I have a ZW-100 device as well (AeoTec Multisensor 6).
You probably have to wake it up a few times manually. When you include it, try keep it close to the controller. Og better yet, put it on USB power. It will probably include much faster.

This is standard for battery devices - they sleep almost permanently. This is why I put this in the docs :wink:

Note that it may take some time to discover the device type - especially in battery devices where you may need to manually wake up the device a few times to allow the interrogation to complete. Refer to the device manual for information on waking up the device.

Only include it on USB power if you intend to always run it on USB power - otherwise it will not work properly as it will always think it is mains powered.

Are you sure about that? The ZW-100 multisensor 6 have an automatic (wakeup) setting when beeing USB power or battery powered. It changes automaticly if you go from USB power to Battery.
When I included it first time I used batteries. But due to some problems I powered it with USB. I have not tried going back to batteries yet, but that was indeed my intention.

Yes - a device reports its listening state when it is first included and it canā€™t change this unless it is re-included. Even if the device can save power, the binding (and controller!) have no way to know this and will treat the device as if it is a battery device.

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.