Thanks, will try during the weekend!
No change unfortunately. I first tried uninstalling the standard binding and put your jar into the addons-folder, but for some reason OH didn’t pick it up, so I ran bundle:install pointing it to the url. Then the binding started, but wasn’t visible anywhere in the UI, so I couldn’t run discovery. Had to reinstall the original binding and then do a bundle:update, pointing to the jar on github. (Shouldn’t matter how I installed it I believe, but noting it down here just in case, perhaps some caching issue?).
Anyway, I got it up and running:
322 │ Active │ 80 │ 4.3.0.202411281737 │ openHAB Add-ons :: Bundles :: ZWave Binding
But still the same result when including the device. Adding two log files, the first is when doing discovery after the bundle:update, when that didn’t work I restarted OH and tried again, but no change. The device is node 21 in the first log, and node 22 in the second.
zwave-attempt-1.log (282.9 KB)
zwave-attempt-2.log (286.8 KB)
There i a bug at the moment that can make it difficult to drop JARs in the addons folder - I suspect this might be the cause of your problems trying to change to the debug version -:
@apella12 I looked at your modifications, and the getNode().getEndpointCount() == 1 check is still present, any is always true (since endpoint 0 is included in the count), so the other else if never gets evaluated.
Let me fix that. That was my original idea, but I shied away from that. EDIT: Sorry New jar available. Also added a log statement (should have done that before too). @pacive Will wait until I hear from you before committing the new version in the PR. Edit 2: I did a quick test with the new version (without the ==1) on my test multichannel device and it still works, so that is positive.
1 Like
Hi,
I also try 4.3.0-snapshot version of zwave binding.
openhab> bundle:list|grep -i zwave
314 │ Active │ 80 │ 4.3.0.202411281737 │ openHAB Add-ons :: Bundles :: ZWave Binding
openhab> feature:list|grep -i zwave
openhab-binding-zwave │ 4.2.3 │ │ Uninstalled │ openhab-addons-4.2.3 │ Z-Wave Binding
I’m on OH 4.2.3.
But nothing has changed, XML file for Wave 1 Mini was not created.
I made a change this morning
268 │ Active │ 80 │ 4.3.0.202411301300 │ org.openhab.binding.zwave
EDIT: Also not exactly sure if this will work on 4.2.3 (There have been some changes in karaf among others), I had originally suggested to @pacive because I saw he was on 4.3M4 like me. But if it works great!
This is covered in the blog, but with the time zone differences and a certain degree of optimism;
If you do get an OH node XML for the mini with the PR .jar, you will need to alter the Type:ID of this partial but incomplete device, before trying to paste the XML from OH into the “Create Device” window. Bottom line, the ZW DB will error if trying to add with an XML the same Type:ID as an existing (even incomplete) device. Also if the device is mostly the same as the wave 1PM you can use the gearbox on the new entry to copy most of the information over. The dropdown is not sorted but the 1PM is device 1577. Lastly add REMOVE to the Multichannel CC config on the endpoints tab.
1 Like
Good news! The latest changes enabled the binding to successfully include the device and create an XML for it, I’m in the process for adding it to the database. Since this is the Wave 1 Mini (no PM) I didn’t have to change any existing entries.
I have one question on how to define the parameters, especially the bitmask field. I have e.g. this description from the manual:
Parameter No. 91 - Water Alarm
This parameter determines which alarm frames the Device should respond to and how. The parameters consist of 4 bytes, the three most significant bytes are set according to the official Z-Wave protocol specification.
Values size: 4 Byte
Default value: 0
Values & descriptions:
0 no action
1 open relay
2 close relay
It’s a 4 byte value, but only the least significant byte is used, should I then add the bitmask as 0x000000ff? Or even 0x00000003, since only two bits are effectively used? Or is the bitmask only used in cases where one byte is split e.g. the 4 highest bits are used for one setting and the lowest for another?
Edit: and how do I tell the binding to use “the official Z-Wave protocol specification” for the three most significant bytes?
Added the device to the DB and requested a review. I tried deleting the COMMAND_CLASS_MULTI_CHANNEL, but nothing happened. A bug in the web page?
Edit: This seems to be the reason:
I wouldn’t worry about the alarm. I think that is a confusing. Does the device have internal sensors or do you think it refers to if it gets a message from another device? I did not see the parameter section in the attached manual, so really don’t understand.
As to the REMOVE. I did it for you. This will happen when the device is discovered
1 Like
I think the settings are for how it should react to alarms from other devices, not sure if these are generally broadcasted over the entire mesh?
Should I remove the alarm-related parameters all together then?
For reference the manual here has all parameter descriptions: Shelly Wave 1 Mini – Shelly Europe
I’d just leave them.
It is not obvious to me, but the mini would probably need to be included in an association group of another device for the water, co and smoke alarms. It does seem to have a built-in heat alarm.
Thanks for raising this I have just tried to include this same device received in the post today.
Z-Wave Node 032 (0460:0002:008E:10.4)
The results I get with the release binding are (obviously) the same as yours
Is there any assistance I can give?
At this point the Zwave snapshot binding has been modified with a fix to allow an XML creation. Using that snapshot @pacive created a ZW DB XML that is pending approval to be included in the binding.
What you (or anyone) could do (besides wait) is modify your existing Zwave binding with this file
EDIT: 1 mini has been added to the OH4.3 snapshot binding, should be in .jar tonight or tomorrow. Cleaner and corrected file if still want to do procedure
wave1mini_0_0.xml (36.5 KB)
following this procedure. (folder shelly, not zooz) If that seems too much, just wait until ZW DB is merged into the binding. It should not be too much longer. Note that it will be merged into a OH4.3 snapshot binding, so might not work with a OH4.2.x release. However, the 4.3 Release is only a week or two away and that should contain the device info.
One last note. There is a Shelly Wave 1PM mini (0460:0002:008F:11.3) that is not fully in the ZW DB with the same issue, so might not be in the 4.3 release.
2 Likes
Excellent 
It’s working! Thanks.
majherek@atom:~$ mkdir jarmodify
majherek@atom:~$ cd jarmodify/
majherek@atom:~/jarmodify$ cp ../org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar .
majherek@atom:~/jarmodify$ ls
org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar
majherek@atom:~/jarmodify$ mkdir -p OH-INF/thing/shelly
majherek@atom:~/jarmodify$ unzip -t org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar | grep shelly
testing: OH-INF/thing/shelly/ OK
testing: OH-INF/thing/shelly/alrezwew1pm_0_0.xml OK
testing: OH-INF/thing/shelly/wave1_0_0.xml OK
testing: OH-INF/thing/shelly/wave2pm_0_0.xml OK
testing: OH-INF/thing/shelly/wavei4dc_0_0.xml OK
testing: OH-INF/thing/shelly/waveplugus_0_0.xml OK
testing: OH-INF/thing/shelly/wavepmmini_0_0.xml OK
testing: OH-INF/thing/shelly/wavepro2pm_0_0.xml OK
testing: OH-INF/thing/shelly/wavepro2_0_0.xml OK
testing: OH-INF/thing/shelly/waveshutter_0_0.xml OK
majherek@atom:~/jarmodify$ cp ~/wave1mini_0_0.xml OH-INF/thing/shelly/
majherek@atom:~/jarmodify$ jar uf org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar ./OH-INF/thing/shelly/wave1mini_0_0.xml
majherek@atom:~/jarmodify$ unzip -t org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar | grep shelly
testing: OH-INF/thing/shelly/ OK
testing: OH-INF/thing/shelly/alrezwew1pm_0_0.xml OK
testing: OH-INF/thing/shelly/wave1_0_0.xml OK
testing: OH-INF/thing/shelly/wave2pm_0_0.xml OK
testing: OH-INF/thing/shelly/wavei4dc_0_0.xml OK
testing: OH-INF/thing/shelly/waveplugus_0_0.xml OK
testing: OH-INF/thing/shelly/wavepmmini_0_0.xml OK
testing: OH-INF/thing/shelly/wavepro2pm_0_0.xml OK
testing: OH-INF/thing/shelly/wavepro2_0_0.xml OK
testing: OH-INF/thing/shelly/waveshutter_0_0.xml OK
testing: OH-INF/thing/shelly/wave1mini_0_0.xml OK
Also in Karaf:
majherek@atom:~$ ssh oh4
_ _ _ ____
___ ___ ___ ___ | | | | / \ | __ )
/ _ \ / _ \ / _ \ / _ \ | |_| | / _ \ | _ \
| (_) | (_) | __/| | | || _ | / ___ \ | |_) )
\___/| __/ \___/|_| |_||_| |_|/_/ \_\|____/
|_| 4.2.3 - Release Build
Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.
openhab> feature:list|grep -i zwave
openhab-binding-zwave │ 4.2.3 │ │ Uninstalled │ openhab-addons-4.2.3 │ Z-Wave Binding
openhab> bundle:list |grep -i zwave
314 │ Active │ 80 │ 4.3.0.202411281737 │ openHAB Add-ons :: Bundles :: ZWave Binding
openhab> bundle:stop 314
openhab> bundle:uninstall 314
openhab> bundle:list |grep -i zwave
Then I update the org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar
in folder: /opt/openhab4/addons (I use opehab in docker).
And again in Karaf:
openhab> bundle:install file:////openhab/addons/org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar
Bundle ID: 315
openhab> bundle:list |grep -i zwave
315 │ Installed │ 80 │ 4.3.0.202411301300 │ openHAB Add-ons :: Bundles :: ZWave Binding
openhab> bundle:start 315
openhab> bundle:list |grep -i zwave
315 │ Active │ 80 │ 4.3.0.202411301300 │ openHAB Add-ons :: Bundles :: ZWave Binding
And it’s works (already checked):
Good 
A couple of notes for others.
- I took down the test jar linked above because the PR was merged, so the official 4.3 snapshot has the fix for finishing initialization of this device.
- From your test it appears the ZW 4.3 snapshot will work with OH 4.2.3. That is good news too.
- The latest official ZW 4.3 binding now (as of last night) also has the Shelly Wave 1 Mini config included, so a simpler karaf bundle:update from the official repository should work on OH4.2.3 and the OH4.3 milestones if you have this device.
Lastly, Can you post the OH XML for node20? I want to see how/if the REMOVE worked.
1 Like
Great! Then I can go ahead with installing all the other minis I purchased 
They’re quite cheap for being a z-wave device, if all you need is to switch a single (< 8A) load and don’t care about power monitoring for it.
1 Like
I attach the node20 config.
network_cc14718f__node_20.xml (11.2 KB)
Unfortunately the timers are not working according to me. I set OFF to 300 sec (5 minutes), and the state of the switch does not change.
After 5 minutes nothing change:
openhab> openhab:items list Oswietlenie_na_schodach_Switch
Oswietlenie_na_schodach_Switch (Type=SwitchItem, State=ON, Label=Switch, Category=Switch, Tags=[Switch, Light], Groups=[Oswietlenie_na_schodach])
But I assume it’s not a problem with the bindings themselves, but with the device.
Not unlikely. All we have to go on here is the manufacturer’s documentation 
But if you can get debug logs from when you change the parameter, that might give an indication.