Hello Community and DevTeam, I’m having a very similar issue to this other one I believe, but anyway I’m providing all the data I can gather so far to try troubleshoot this, since this switch device can help me reducing the power utility bill, and I think many others will benefit from this too.
Other than a faulty device option, I’d like to explore a more optimistic one and just being a misconfiguration issue, or something that needs to be added/modified to the device database maybe?
I’m attaching the screenshots from Basic UI showing the Thing details along with its code, also the tail-f logs, where the two lines highlighted below caught my eye but don’t know what it means to require:
2023-10-25 03:03:36.934 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 8: Device discovery could not resolve to a thingType! 015F:2201:7202::4.2
2023-10-25 03:08:01.768 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 8: Device discovery could not resolve to a thingType! Manufacturer data not known.
The device needs to be added to the ZW DB. There is a blog with directions (the DB is maintained by the OH community and changes are approved by the binding developer at periodic intervals).
Once approved you will generally need to upgrade the binding (devices are contained within the binding). There is no retroactive updating of older bindings (except manually) and in some cases the newer binding will not work with an older version of OH, so you may have to upgrade your system. So with that as background, what version of OH4 are you on?
One thing may make this easier and faster. Look at the MH-s220 in the DB with the firmware version >3.2 (not the one you found) and compare the parameters to your device manual. I suspect they are the same. If so, all that needs to be done is add 2201:7202 to the type line. If that is the case, I can add that for you. If a new device needs to be created, you will need to do that yourself, following the blog instructions. There should be a node9.xml in your userdata/zwave folder.
Thanks so much for your input Bob! I had some issues yesterday with my OH3 running on RPi3 and I ended up reinstalling the whole thing with OH4.4.0, nonetheless the same situation popped up on both versions.
Now, if we go with the second option to just add the type line to the device with version >3.2, would this cause any issues to users that currently have this device included in their infrastructure?
Hello Bob, please find my updates below on this matter:
I’m not 100% sure on this, since I see some differences in the parameters table from the official annex and the one I have from the device package (image below), specifically on numbers 20 and 21 which are not present in the DB device, but maybe that’s fine?
A reboot is not require after the bundle is updated with the XML, but you do have to delete node9 from the UI page (do not exclude it), then go to the inbox, zwave binding, scan to pick it up again. If that does not work something was not done right. You did adjust the directory to mcohome in this step, right? mkdir /home/openhabian/jarmodify/OH-INF/thing/mcohome
Sorry, for the confusion. What I meant was if the device is added to a new binding (it will be OH4.1 Snapshot) and a OH4.1 snapshot in October or November will not work with a OH4.0.3 installation.
Hey Bob, thanks for your help here! I ended up reinstalling OH4 in my RPi3 and managing the ZWave bridge via Z-Way, which simplified the devices operation much smoother since the Razberry pi-hat since it is made by them.