Zwave device has no channels - not scanned properly? Tips to solve?

Setup, Configuration and Use Items & Sitemaps
1
  • Platform information:
    • Hardware: RaspberryPi 4 (with powered USB hub)
    • OS: Debian GNU/Linux 11 (bullseye) - was installed as Openhabian a few months back
    • Java Runtime Environment: openjdk 17.0.12 2024-07-16 (output of java --version)
    • openHAB version: 4.2.1-1

Issue of the topic
When adding a zwave device (an Aeotec Heavy Duty Switch), no channels are detected (in fact, very little seems to be detected)

The switch I’m using is an Aeotec Heavy Duty Switch, model number ZW078-C. It’s in the zwave database (here: OpenSmartHouse Z-Wave Device Database). It’s only ever detected as Z-Wave Node 006. If I add it, the device itself carries on flashing its LED like it’s not been paired, and I don’t see an XML file for it in the zwave directory on the openhab box (I do see XMLs for other detected devices, even those I haven’t paired with).

I’ve currently got the zwave stick (an Aeotec Z-Stick Gen5) connected via a USB extension cable so that it can be located about 3 inches away from the switch. It’s connected into a powered USB3 hub, which is plugged into a USB3 port on the Raspberry Pi. The same hub is being used (successfully) for a zigbee stick. I have one other zwave device successfully working via my stick. I have 3 other devices shown in the inbox, but these devices no longer exist (removed from the stick, now switched off, and in fact disposed of).

When the wonky device is added to Openhab, it continues to flash as if not paired. However, Openhab has a device, and it no longer appears in the ‘inbox’, nor is it found during a scan. If I look at the device, it says “Thing Type: unknown device” (and goes on to explain the details weren’t found yet). In ‘Thing Properties’, it has a couple of the fields incorrectly (or at least, they differ from the details on the Database page). I can’t see any of the information on the database page to verify it really is (or is not) the same device.

The only thing I see in the log (at all) during a scan is this:

2024-08-11 20:06:06.249 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery could not resolve to a thingType! Manufacturer data not known.

Is there any way to make this work? Can I manually edit the ‘code’ for the device to give it the configuration it’s missing? What other information do you need from me?

Any help much appreciated.

Previous research suggests this can work somehow:

2

Check out this Guidance for “unknown” Zwave Device - Tutorials & Examples / Solutions - openHAB Community My guess is the TYPE:ID is different

Edit: A couple of other thoughts. 1) Try to exclude the device first.

  1. Get Simplicity studio (it is free, but you have to register) and get rid of everything that is missing.
  1. Or simplest at this point, Exclude the device you have and factory reset the stick (hold button for 20 seconds), and factory reset the Hvy duty switch then reinclude the old one plus the new device.
3

Thanks for all of that - much appreciated.

I’ve tried a variety of reset and exclusions you suggest, all the way up to a full reset of the stick. So far the outcome is much the same - I still get this ‘partially scanned’ device in the list. I think your idea of a different Type:ID looks reasonable - I just can’t see a way to get the ID from the device. I don’t get an XML, nor does the log file show anything useful. How else can I get the ID?

(I have been looking at turning up logging - the advice is to run the console, log at log:list and turn it up for the binding - but I don’t see any zwave items in the list, and so am not sure what to ‘turn up’)

I’m currently looking at SimplicityStudio - not immediately seeing what I need, but I’ll keep at it.

4

There is a hardware issue with the Aeotec Z-Stick Gen5 (most models) on the rpi4 (the first with USB3). (Sorry for HA link, but it was what popped up on google.) One workaround is to put the stick into a USB2 hub (powered optional). If you don’t have one, at least try to switch your hub to the USB2 port on the Rpi. This could be the problem.

Another test would be to include the device using Simplicity Studio as that will be on a different computer (I assume).

5

Thanks for that - I had got it in a powered USB3 hub, which was plugged into a USB3 socket on the pi. I’ve now moved it to a USB2 hub plugged into a USB2 socket.

I feel like this isn’t a hardware problem with the stick - it’s been working very nicely with two other devices for months/years. Never say never, but…

I also found that you can put the zwave binding into debug, even though it’s not listed in log:list. A simple log:set Debug org.openhab.binding.zwave into the console makes it happen. With that, I’ve got a bit more over the course of the last couple of hours (grepping for NODE 6 in the openhab.log file):

2024-08-12 15:56:09.499 [DEBUG] [age.SerialApiGetInitDataMessageClass] - NODE 6: Node found
2024-08-12 15:56:09.568 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 6: Init node thread start
2024-08-12 15:56:09.895 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 6: Serializing from file /var/lib/openhab/zwave/network_efe24710__node_6.xml
2024-08-12 15:56:09.899 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 6: Error serializing from file: file does not exist.
2024-08-12 15:56:09.999 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 6: Starting initialisation from EMPTYNODE
2024-08-12 15:56:10.049 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 6: Init node thread finished
2024-08-12 15:56:10.049 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 6: Node advancer - advancing to IDENTIFY_NODE
2024-08-12 15:56:10.053 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 6: Node advancer: Initialisation starting
2024-08-12 15:56:10.161 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: ProtocolInfo
2024-08-12 15:56:10.176 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Listening = false
2024-08-12 15:56:10.178 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Routing   = true
2024-08-12 15:56:10.180 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Beaming   = true
2024-08-12 15:56:10.185 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Version   = 4
2024-08-12 15:56:10.193 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: FLIRS     = false
2024-08-12 15:56:10.194 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Security  = false
2024-08-12 15:56:10.196 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Max Baud  = 40000
2024-08-12 15:56:10.221 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Basic    = BASIC_TYPE_ROUTING_SLAVE
2024-08-12 15:56:10.222 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Generic  = GENERIC_TYPE_WALL_CONTROLLER
2024-08-12 15:56:10.223 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 6: Specific = SPECIFIC_TYPE_BASIC_WALL_CONTROLLER
2024-08-12 15:56:10.224 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 6: Creating new instance of command class COMMAND_CLASS_NO_OPERATION
2024-08-12 15:56:10.225 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 6: Command class COMMAND_CLASS_NO_OPERATION, endpoint 0 created
2024-08-12 15:56:10.227 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 6: Version = 1, version set. Enabling extra functionality.
2024-08-12 15:56:10.229 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: Adding command class COMMAND_CLASS_NO_OPERATION to the list of supported command classes.
2024-08-12 15:56:10.230 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 6: Creating new instance of command class COMMAND_CLASS_BASIC
2024-08-12 15:56:10.244 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 6: Command class COMMAND_CLASS_BASIC, endpoint 0 created
2024-08-12 15:56:10.254 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: Adding command class COMMAND_CLASS_BASIC to the list of supported command classes.
2024-08-12 15:56:10.275 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 6: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@4a06ecf2
2024-08-12 15:56:10.277 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 6: Node Init transaction completed with response COMPLETE
2024-08-12 15:56:10.278 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 6: Node advancer - advancing to REQUEST_NIF
2024-08-12 15:56:10.279 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@6da3bfdb
2024-08-12 15:56:10.280 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Bump transaction 9 priority from Controller to Immediate
2024-08-12 15:56:10.285 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Adding to device queue
2024-08-12 15:56:10.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Added 9 to queue - size 1
2024-08-12 15:57:39.086 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery completed
2024-08-12 15:57:39.095 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery could not resolve to a thingType! Manufacturer data not known.
2024-08-12 15:58:48.787 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery completed
2024-08-12 15:58:48.791 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery could not resolve to a thingType! Manufacturer data not known.
2024-08-12 16:06:08.046 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery completed
2024-08-12 16:06:08.054 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery could not resolve to a thingType! Manufacturer data not known.

This all adds some weight to the idea that my device has a different typeID - but I can’t see which ID it does have to compare it against the database. I’ve looked around a fair bit, I can’t see another way to get that ID without some other software.

As for Simplicity Studio, it seems the zwave stuff is Windows only, so for now at least, that’s out. I’ll see if I can get some Windows somewhere, but that whole process will take some time.

6

Well, that’s weird… I’ve been hacking away at this for a while now, always with the same nothingness output.

However, just now, it’s started working. It seems to have come up with a new zwave nodeID, but it is recognised and works correctly. I’m getting readings off it, and can turn the switch on/off.

It’s always a bit disconcerting when something “just starts working”, but it has. I can’t tell you what made it work though.

Thanks everyone for your help - you all nudged me towards a solution :slight_smile:

7

Congrats. The type:ID must match the DB or you wouldn’t have control.

One note for the future on 4.2.1 you can set the binding in debug from the settings page. In the Addons Settings find the binding, click and set the log level

1 Like
8

I always feel the same way but… with zwave it kind of happens now and then
I had a sensor, gave me fits, switched to a snapshot, did everything for days, then all the sudden all on it’s own it started working

1 Like