Z-Wave radiator valves not included in OH3


I am in the process to move from OH2 to OH3 (and from RPi 3 to RPi 4) and for several reasons I am starting the setup from scratch. Everything but Z-Wave radiator controllers seems to work fine. I cannot simply get them included - more details below.

  • System: Openhabian 1.6.2 on RPi 4 2 GB
  • Z-Wave Controller: Aeotec Z-Stick Gen5, full online and configured (through the great WebUI). Below the output of both lsusb and the relevant part of dmesg - (does the initial error matter?)
[21:54:35] openhabian@openhabHost:~$ lsusb -s 001:009
Bus 001 Device 009: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

[17554.288707] usb 1-1.2: new full-speed USB device number 7 using xhci_hcd
[17554.388928] usb 1-1.2: device descriptor read/64, error -32
[17554.608918] usb 1-1.2: device descriptor read/64, error -32
[17554.828719] usb 1-1.2: new full-speed USB device number 8 using xhci_hcd
[17554.928940] usb 1-1.2: device descriptor read/64, error -32
[17555.148927] usb 1-1.2: device descriptor read/64, error -32
[17555.269184] usb 1-1-port2: attempt power cycle
[17555.928779] usb 1-1.2: new full-speed USB device number 9 using xhci_hcd
[17555.966111] usb 1-1.2: New USB device found, idVendor=0658, idProduct=0200, bcdDevice= 0.00
[17555.966131] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[17555.969129] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

  • Radiator Controllers: Eurotronic Spirit Z-Wave Plus (link to doc)

  • Problem description: the radiator controllers are detected by the binding, even w/o active scanning or putting the controllers in the inclusion mode. However, the are not recognized (see log below) and they keep staying with an error condition (Node is not communicating with controller)

2020-12-30 21:30:10.623 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 7: Restore from config: Error. Data invalid, ignoring config.

2020-12-30 21:31:14.457 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 7: Device discovery could not resolve to a thingType! Manufacturer data not known.

  • What has been already tried:

    1. Z-Wave controller hard reset (via WebUI)
    2. Factory reset on the radiator controller - but why then the message “Restore from config”? What kind of data is invalid if I am starting from scratch??!?!?
    3. Exclude Devices option in Zwave controller
    4. Looked to other posts, I cound not find related posts (more on bridge offline though)

Could you please help me with this? The only option I have is to revert to OH2 (the Rpi3 is still in place) and exclude one-by-one the devices before including them in OH3. Would this make sense?


P.S.: apologize for the long post, but I want to provide as much information as possible to solve this quickly, it is winter here in Germany :cold_face:

What version of OH3? The Stable Release?
I do remember some issues with Spirit that were corrected but I need to research the timeline.

EDIT: I believe the Stable Release of OH 3.0.0 should work OK.

1 Like

Hi @Bruce_Osborne

yes, stable OH3 as installed by default through Openhabian 1.6.2 (3.0.0 - Release Build). It would be great if you could find any reference to issues in the recent past, I can dig into them.


A clean install or an upgrade?
You might try deleting the Thing from OH ( do NOT exclude) and re-adding it.

The entry for that device was last updated on Dec 15 & exported on Dec 17 as far as I can tell.

The cleanest as possible - new device (Rpi 4), new SD card, OH3 installed from scratch. No files imported at all.

Is there anything cached in the dongle?


The device database is part of the binding…

On a Pi 4 with USB3 some sticks do not behave. Try a USB2 hub in between. I think the Pi thinks the stick supports USB3 when it does not.

I guess that could hamper discovery of some battery operated devices.


Just had a look to this file - does it matter for the config of my device? It looks it has been modified several times in the last weeks…

That was modified before OH3 was built for stable release.

Damn, I though I had something to hope for :wink:

I will go back to my RPi3/OH2.5.1 config tomorrow and log a little bit more data on the working system, before reverting to OH3 and further debugging the issue.

Or install OH3 on RPi3 (sob, 1GB only avail :frowning_face:)


@chris, @Bruce_Osborne

I have discovered a similar issue posted in this thread - is there anything related I can learn from there?

I want to give OH3 a chance to run, since I like it, but w/o heating I won’t get the needed support at home :laughing:


If the manufacturer data is not known the device has not yet communicated with the controller.
You need to wake that device, again and again, several times until an xml file is generated in your /userdata/zwave folder.

There seems to be an invalid xml already in your userdata folder for node 7. Just delete that file before waking the device as described above.

1 Like

I can’t see anywhere where you say the device ID / type? Please provide this so we can check.

1 Like

Eurotronic Spirit. I that lengthy first post.

Sorry - I can’t spot it. I can see the USB IDs for the controller, but not the device IDs from the ZWave device, but I could be blind :slight_smile:

Below the log listing.

Just a short update - I have now tested the very same process (OH3 installed on a new SD card) on a RPi3 and I clicked on “Hard Reset the Controller” when I added the bridge for the first time. All thermostatic valves have been recognized properly - both the name and the channels matched the HW (Z-Wave device XXX: Spirit Z-Plus blah, blah + all expected channels).

I am now repeating the same for Rpi4, I will let you know the results shortly.


P.S.: I have at least a working OH3 setup :slightly_smiling_face:

1 Like

Final update: it seems the issue is related to the stick directly supplied by the RPi4.

It seems that the limited power supply to the stick was responsible for a messy communication between stick and RPi4. I can SOLVE the issue by putting a powered USB hub in between. The error in the dmesg (device descriptor, power cycle, etc) are gone, and all Z-Wave thermostatic valves are correctly detected. Interesting enough, the faulty configuration detected such devices (w/o recognizing them) even w/o putting them in discovery mode, while the correct setup could not detect any, unless the device was put into the discovery mode (factory reset + boost power button pressed).

A good lessons learnt - should I put/mark somewhere/somehow for future reference?


1 Like

If the device can be battery powered or USB powered, it needs to be USB powered when included in the Z-Wave network. Otherwise it functions like a battery powered device even if USB powered.

At least that has been the advice & experience for my dual powered devices.


Apologize if I was not clear - I meant the controller (Aeotec Z-Stick Gen5) - as you previously pointed out, it needs to be on a USB powered hub and not drawing power directly from the RPi4. I was only a little bit confused by the other posts claiming that the bridge was constantly offline, while mine seemed to be healthy and online.


1 Like