4.2M4 Shelly Wave 1pm mini and i4 not recognized

[Juno]

Added both Shelly Wave 1pm mini and i4.
But their devicetype is ‘Unknown Device’

Next link and because the devices are not in the opensmarthouse zwavedatabase

Guidance for "unknown" Zwave Device

Zwave wave devices are generally identified by the TYPE:ID pair (also infrequently the firmware version). Some manufacturers change the TYPE:ID numbers as the device is changed (FW or other change) or simply to identify the year it is made. The TYPE:ID can be found for an unidentified device in the userdata/zwave folder (or var/lib/openhab/zwave with most OH installations) in an XML file (like network_d2818a75__node_3.xml). The other thing to notice is the last approval date at the bottom of th…

the devices are missing in Openhab4.2M4.
How/who can update the opensmarthouse zwavedatabase, or did I took wrong conclusion, missed … ?

Their (auto generated) labels are:
Wave 1PM Mini
Z-Wave Node 020 (0460:0002:008F:11.3)
Wave I4
Z-Wave Node 018 (0460:0009:0081:11.4)

And Zwave database entries:
Z-Wave JS Config DB Browser
Z-Wave JS Config DB Browser

But these are missing in:
OpenSmartHouse Z-Wave Device Database

Though looks present in the openhab documentation
Shelly - Bindings | openHAB
as
shellymini1pm
shellyplusi4

According to next support should already have been merged:
[shelly] Add support for various Gen3 devices (Plus 1/1PM, Mini 1/PM/1PM, Dimmer 0110, i4) by markus7017 · Pull Request #17166 · openhab/openhab-addons · GitHub
[Shelly] New Device Mini 1 Gen 3 · Issue #16773 · openhab/openhab-addons · GitHub

Next link indicates the two devices are not in openhab because they are missing in the database
Guidance for "unknown" Zwave Device
Blog Posts

[apella12 (Bob Eckhoff)]

In OH there is both a Shelly binding and a zwave binding. I don’t know if the devices you have support both protocols. As to the OH Zwave I checked in the OpenSmartHouse - this is what the OH Zwave binding uses) and your devices are missing, although it might mean just adding the type:ID as there are devices that look close. here and here.

Lastly OH can be used with Z-wave-js (the other references, but it [requires a few more steps])(Zwave-JS-UI in place of OH Zwave binding). Since Zwave-js is used by the bigger HA community the DB of devices tends to be bigger.

[Juno]

Thanx for the suggestion.
Already have ZUI (zwave-js-ui) running as a docker. This can run instead of my OH docker to test/verify zwave setup.
In ZUI both devices are present, so this db has more devices.
And looks like the Shelly binding is for wifi devices.

Can the OH zwave binding not (re)use the ZUI db? Or have the OH zwave db generated from the same (source) devices as ZUI, so new devices are faster in the db?

Or can maybe create a Zwave-JS-UI binding replacing the (current) OH zwave binding, like HomeAssistant is using (Z-Wave JS WebSockets (used by the Home Assistant Z-Wave JS integration)?

[apella12 (Bob Eckhoff)]

@Juno

Can the OH zwave binding not (re)use the ZUI db? Or have the OH zwave db generated from the same (source) devices as ZUI, so new devices are faster in the db?

HA has paid developers, OH does not. The OH Zwave developer has a full time job with lots of travel, so the main activity (See OH Zwave github) at this point is to merge user created devices (updates to OH Zwave DB are by the “community”) in the DB into the binding. I use both OH zwave and Zwave-js and have contributed devices to both. Neither is automatic (check out the Zwave-js issue tab on github for configs). Zwave-js can pull a draft from the OH Zwave DB, but not the other way around.

@Juno

Or can maybe create a Zwave-JS-UI binding replacing the (current) OH zwave binding, like HomeAssistant is using (Z-Wave JS WebSockets

Note this issue in OH addons. Feel free to write a PR to address. Z-Wave JS official integration · Issue #16374 · openhab/openhab-addons

[Juno]

I fully agree.
Now getting all info for the how to.

Modify a zwave binding jar to add/change a zwave device while waiting for a build

I think Chris kicked off a manual build of that binding so somebody could see if their issue was resolved. Like you said, since it was after the snapshot you got an older one. I usually just update the database and wait for the next export. Chris usually exports once a week or so.

So have to update the DB, export the xml and merge this into the jar, and update the jar of the docker image. The DB linked in the above manual do not exists anymore.

Z-Wave Device Database Guide

And getting a login for the db results in File not found.
https://www.opensmarthouse.org/user/register.php
Also buttons to create a xml for a device is not present, or should one first login?

Latest build artifacts are now at
https://ci.openhab.org/job/openHAB-ZWave/
https://ci.openhab.org/job/openHAB-ZWave/ws/src/main/resources/OH-INF/thing/shelly/
build from

org.openhab.binding.zwave/src/main/resources/OH-INF/thing/shelly at main ·...

And when running a docker, how to update a file in the docker image
https://www.quora.com/What-is-the-best-way-to-replace-files-from-within-a-running-docker-container-without-re-building-the-image
https://www.quora.com/How-do-I-add-changes-to-a-docker-image-without-rebuilding-it-just-for-testing-purpose

Creating a local build system to replace a file in an image is possible, but setting up a build system can be quite challenging.

How to get a login for the DB, or did I make an incorrect assumption? And has someone already performed above steps?

[apella12 (Bob Eckhoff)]

A couple of things

1. I updated the binding update to reflect OH3/4 here.
2. the ZW DB has been hit with DoS, so the developer created another way here.
3. Also I think you can just add the modified Zwave jar to the addons folder (assuming you created a volume for it) EDIT: Note Uninstall the Zwave binding from the UI first.

services:
  openhab:
    image: "openhab/openhab:milestone"
    restart: always
    network_mode: host
    volumes:
      - "/etc/localtime:/etc/localtime:ro"
      - "/etc/timezone:/etc/timezone:ro"
      - "/etc/cont-init.d:/etc/cont-init.d"
      - "./openhab_addons:/openhab/addons"  // use this
      - "./openhab_conf:/openhab/conf"
      - "./openhab_userdata:/openhab/userdata"
    environment:
      CRYPTO_POLICY: "unlimited"
      EXTRA_JAVA_OPTS: "-Duser.timezone=America/New_York"
      OPENHAB_HTTP_PORT: "8080"
      OPENHAB_HTTPS_PORT: "8443"
      USER_ID: "1000"
      GROUP_ID: "1000"

[Juno]

After some experimenting and using existing xml files as templates and combining them with generated xml file, I have my two (new) devices as known devices in my things list.

Used docker cp to update/replace the jar in my local docker container, and after a container restart, they showed up.

Copy the jar to your local file system
docker cp openhab:/openhab/userdata/tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.zwave/4.3.0.M4/. .
and update/add your xml files in the jar file (effectively a zip file) to the existing (archive/zip) folder(s)
OH-INF\thing\[manufacturer]\ for my Shelly devices OH-INF\thing\shelly\.

docker cp ./org.openhab.binding.zwave-4.3.0.M4.jar openhab:/openhab/userdata/tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.zwave/4.3.0.M4/

Note: a (docker) container image update/re-pull will of course ‘revert’ this manual change.

[apella12 (Bob Eckhoff)]

Don’t forget to “request review” on the overview tab, if you are finished.

[Juno]

Can ask for a review, though I still wants to test it a little more…
Also in progress of adding the Wave 1PM mini [OpenSmartHouse Z-Wave Device Database], though the endpoints as manually created using an xml file did not go correctly. So these do not match the Wave 1PM (non-mini) [OpenSmartHouse Z-Wave Device Database].
Because the endpoints command classes cannot be added manually, some needs to alter the DB tables manually, or update the endpoints page…

[apella12 (Bob Eckhoff)]

No worries. Sometimes people forget that step and the device is delayed (updates have been running 2-3 weeks apart).

As to the other device, I’m not sure I understand. What exactly is missing?

Also was wondering if, after you marked up an XML for the binding to discover the device, did OH generate an XML in the zwave folder? The OH generated XML has the “NIF info” that the ZW DB needs to set the Command classes and endpoints.

[Juno]

@apella12

Also was wondering if, after you marked up an XML for the binding to discover the device, did OH generate an XML in the zwave folder? The OH generated XML has the “NIF info” that the ZW DB needs to set the Command classes and endpoints.

Openhab did not generate an XML for the second (new) 1PM mini device. So tried to assemble one manually using the 1PM (non-mini), but this resulted in an error while creating the device, but still a device was created. This endpoints did not match the 1PM (non-mini)…
But you can compare the endpoints of both 1PM s. You see for the 1PM mini:

ToRemove:
COMMAND_CLASS_MULTI_CHANNEL_V3

Missing:
COMMAND_CLASS_TRANSPORT_SERVICE_V0
COMMAND_CLASS_SUPERVISION_V0
COMMAND_CLASS_MANUFACTURER_SPECIFIC_V1
COMMAND_CLASS_POWERLEVEL_V1
COMMAND_CLASS_FIRMWARE_UPDATE_MD_V1
COMMAND_CLASS_ASSOCIATION_V2
COMMAND_CLASS_VERSION_V2
COMMAND_CLASS_INDICATOR_V3
COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION_V3
COMMAND_CLASS_SECURITY_V1
COMMAND_CLASS_SECURITY_2_V0

If one renames the
COMMAND_CLASS_MULTI_CHANNEL_V3
to
COMMAND_CLASS_SUPERVISION_V0
It nicely matches the order of the 1PM (non-mini)

[apella12 (Bob Eckhoff)]

@Juno

Openhab did not generate an XML for the second (new) 1PM mini device.

I wondered with your doctored binding XML whether the binding would still get hung-up on the Multi_Channel CC and not be able to create the OH zwave node XML (This is used as a storage record for restarts, etc.).

At a high level how, it works; At any startup the binding requests a NIF and the device sends back all the CC’s supported. The binding then proceeds to interview each CC. The device is always going to send the Multi_Channel CC and the binding will always try to interview it.

If you have a 1PM (non-mini) you could create a device from that OH zwave node XML to create a mini XML with the desired CCs for the ZW DB, but my guess is that once the mini sends its “Real” NIF the binding will get hung-up (the reason for my question). It might mostly work (it sounds like you have it working) with your doctored binding XML, but will not produce the OH zwave node XML. Without that I don’t think OH will consider the device fully configured and I’d anticipate other problems (Not able to Heal, etc.).

I’m thinking that a programming hack is needed to temporary allow the bypass of the Multi_Channel CC if versions higher that V2.