Request: MH-S220 Micro Switch not fully included (OH4)

Add-ons Bindings
, ,
1

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.

Thing Code

UID: zwave:device:f01d24200c:node9
label: Z-Wave Node 009 (015F:2201:7202:4.2)
thingTypeUID: zwave:device
configuration:
  group_1:
    - controller
  group_3: []
  node_id: 9
  group_2: []
bridgeUID: zwave:serial_zstick:f01d24200c

addThing
addThing751×439 24.8 KB

thingInfo
thingInfo1920×1080 85.4 KB

thingChannelsInfo
thingChannelsInfo753×191 8.55 KB

tail-f.txt (6.5 KB)

I really appreciate your help here. :man_bowing:t2:

2

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.

Hope this helps.

3

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?

4

No. At this point you would be the only one affected. Do the parameters and association groups look the same?
Edit:

Do you mean OH4.0.x or 4.1 something (Snapshot or M1 or M2)?
OH4.0.x will not work with a newer ZWave binding.

edit2: You could try the “manual” process linked above with this file to see if you are happy with the results
mh-s220-v3-2_3_2.xml (11.6 KB)

5

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?

20231026_122812
20231026_1228121920×1070 158 KB

Sorry, the correct version is OH 4.0.3 Release Build.

I didn’t understand this. I see the current binding as follows:

openhab> bundle:list |grep ZWave
267 x Active x  80 x 4.0.3                  x openHAB Add-ons :: Bundles :: ZWave Binding

I followed the steps but even after a reboot I see the same event logs saying that Device discovery could not resolve to a thingType!.

I don’t know how to get this working, could it require a device update in the DB or creating a new one?

Below is the XML data from the “node 9” in question, which I see quite different in content from the one you uploaded…I’m so lost at this point. :confused:
network_ea4df0a1__node_9.xml (10.2 KB)

Thanks again for your help!

6

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.

7

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.

8

Hello @apella12 @chris , it turns out that the Z-Way service approach does not meet my needs, so I’ll need to update/create a zwave device in the DB.

I registered my user there but it seems that I don’t have the necessary permissions to update/create devices.

Could you guys help me with that?

Thank you!!!

PS: my user is jaravena.

9

Did you open a ticket so Chris can give you write access?

10

Thanks, I didn’t know the procedure for that. I’ll start it right away!

11

Hello @apella12, sorry to bother you again but I’m not having luck with the DB user permissions, I understand Chris might be busy.

Is there any way I can manually convert the node XML file from the /userdata directory into a device XML to include it in the binding JAR file?

I looked everywhere but I can’t find those instructions or a recipe to make this transformation properly.

Thanks in advance and Happy Holidays!

12

No it is different.

I’m not at home, so the best I can do is suggest you go back through my comments in this thread on the manual jar update and the xml file I attached above.

13

Thanks for your reply Bob!

I already did the manual JAR update with the XML you provided, and it didn’t work.

I don’t have much experience with the node XML contents but I could spot some differences between what I see in the /userdata/zwave node XML and the product XML you exported from the DB, so I’m very inclined to say that the MH-S220 device I have is a new version that doesn’t match any of the existing ones in the DB, and requires a new DB object creation, but without the proper write access I’m stuck, this is why I’m aiming to manually produce the XML to then perform the manual JAR update once more, but again I don’t know how to make this XML conversion on my own.

If you have any spare time, could you please try creating the new device in the DB with the node XML I was able to get from my OH server?

Thanks in advance!

14

My suggestion is to try again, more carefully, see my suggestion in post 5.

Else, I can take a look at this on the weekend.

15

I did the manual device addition into the ZWave binding JAR file once again, this time it was SUCCESSFUL :partying_face:

The only thing I had to modify from the product XML you provided, is adding the following line after line 101:

<option value="1">with specified on/off position</option>

Thank you for your help here Bob, really appreciated.

@chris: I’m still awaiting the write access for my DB user :sweat_smile: