Well a debug log, documented with what you are doing could help. Also a comparison to the fibaro that is working. I’m not an expert on these devices, but I would look at the logs.
I created some logs using Down / Up command (node 49). In Z-Wave Log Viewer I noticed that after some seconds a “alarm_power1” entry is created. I don’t know if this is expected. I will reconnect my Fibaro Roller Shutter 3 at another time to have a comparison regarding the logs.
Up_Command.log (82.6 KB)
Down_Command.log (117.7 KB)
Not having shutters, how are these connected? It looks like the commands are issues on the root endpoint and send to both endpoints 1 & 2. Are these separate devices with separate motors? Or does one endpoint raise and the other lower? I might need to study further after understanding what the configuration is
The alarm power is a little concerning. That message normally means the endpoint 1 has the Mains Disconnected. Is the wiring correct? Have you tried to just operate the blind on Endpoint 2?
EDIT: POWER_MANAGEMENT__MAINS_DISCONNECTED("POWER_MANAGEMENT", 2),
The wiring should be correct as the switches are working.
It is only one motor connected. On the fibaro device I also have two channels blind1+2 but the “root” endpoint is deprecated. I also tried to use endpoint 1 directly with no luck.
I wonder why a dimmer Item works some kind of. The motor reacts at least. It seems the device does not Interpret the Up/Down command correctly.
Calibration seems also to work.
There should not be a dimmer channel or item. Try to unlink and remove the item. Then go into the console and check openhab:links orphan list, then openhab:links orphan purge (if any). Then delete the thing (do not exclude) and rescan. Hopefully no dimmer channel. Try tests again.
other stuff
- As background normally root (0) and EP(1) are mirrors, so root is usually dropped. Trying just EP1 was a good idea (I think)
- The power error is from the Zwave protocol, but sometimes mfgs don’t follow it. Could call Shelly support to see what that means.
- With both up and down logs the polls always return zero. Were the tests done from the closed position.
- not having a device, I don’t quite get why the need for two endpoints with only one motor. Maybe the fibaro logs will help me understand.
- assumed you have checked the parameters 3 & 5 and tried the calibration via zwave. I wonder if somehow ep1 and Ep2 are fighting each other, so nothing is happening and the power alarm goes off because of a internal breaker.
No there is no dimmer channel, I just tried a dimmer item like another one mentioned in this thread. For some reason it reacts some kind of using a dimmer item on the blinds channel
- Yes the motor is at position 0. So it is ok to report this value.
- I do wonder too but the fibaro also have this two.
I will get some Fibaro Logs as soon as possible. Have to re-wire it first.
I managed to re-wire the fibaro device and collected the logs.
openhab-fibaro.log (106.1 KB)
I performed an up command, stopped after some seconds and did a down command.
The commands itself seem to be very similar.
Can someone else find a relevant difference?
I’m not sure what is relevant (compared UP files), but the fibaro command and responses are all on EP1. The other device uses the root
to send out commands to both EP1 and EP2, springs the power management alarm and then nothing works. I’m guessing the fibaro EP2 is meant to turn the slats as it is labels Lamella Control.
Although the Fibaro works, the first 2 GET commands time out and then the device sends three responses all at once. Odd, but not really the problem at hand.
Does anyone has any idea how to proceed further? Who can help isolate the issue? It seem that the device on other systems like Home Assistant is working, so it is not a device issue in general.
If you want to check out the HA version, but stay on OH (like I do). Could review this posting. I’d assess as an intermediate level of difficulty but if you have used docker, generic mqtt and have spare capacity (or extra SBC), it should not be a problem to at least test to see if it works.
On the OH side, did you try to just use the blinds control on EP1 like the Fibaro does?
I think I also tried to use EP1 without luck…
Thank you for pointing me to Zwave-JS-UI. It sounds really good.
In the past I tried to avoid additional service like MQTT, but maybe I can not get around it.
Hi, I recently got a Shelly device as well to replace an old Qubino Flush Shutter. Thanks for sorting out the Shelly DB issue. I noticed as well that the switch_binary is missing for the Shelly Shutter, while it is there for the Qubino. For venetian blinds the switch_binary control for the lamella position actually is beneficial, as one can open/close the blinds with ON/OFF commands and does not give on the interface the option for stopping half way (which is hard since it all takes only 1 sec anyway). In my view this is much more consistent. For the blinds up/down a switch_binary as in the caes of the Qubino is not strictly needed. Would it be possible to add the switch_binary in for endpoint 2 by adding it to the DB entry for testing and extract an XML to overwrite the config ?
If I understand this correctly the answer is no. The command classes are “advertised” by the device itself and are loaded into the ZW DB automatically when the XML is uploaded. They can’t added as the device doesn’t have them programed. What might be possible (and I’m guessing as I have no blinds) it to link a switch (on-off) item to the blinds control dimmer channel. I think that dimmers can be controlled with that type of item.
H all
I have good news.
Yesterday I checked the firmware release notes of the wave shutter, which showed me a possible fix to our problem. After I update my device from inital firmware (12.13) to latest (12.23), my Shelly is working correctly using roller shutter items 
How to update on a Raspberry with Razberry?
As Openhab still does not support OTA (Over The Air) Firmware Updates, I used “Z-Way Server”, which I had already installed on my RPi for some other tasks like delete dead Z-Wave battery devices.
- Download Firmware files from Shelly
- Note the devices node ID in OH
- Stop OH Service
- Install and Start Z-Way Server and login to the admin Website
- Open Expert UI
- Locate your device and perform “force interview”
- use the Firmware tab to upload and update you device
- In my case, the update took about 30 minutes for one node
- Stop Z-Way Server and Start OH Service again
- Reinitialize your device (maybe not needed, but otherwise firmware version is not updated in thing properties)
- Have fun
Edit
One thing I noticed is, that values are “reversed”. Fully open = 100 and fully closed = 0. Anyone else see this behaviour?
