In control I see the controls for the rollershutter
Now for the issue I don’t understand…
When I push a control-button it publishes:
0 instead of stop
0 instead of up
100 instead of down
on the mqtt-broker and the ShellySwitch2 does not react.
I filled in the correct pay-load and toppic…I think.
A rollershutter is a percentage value for openHAB internally. Put aside that stop was wrongly implemented by me and a fix is on the way (after everybody returned from holidays), UP and DOWN will send the target percentage. This might not be clear from the docu (create an Issue if so).
If your shelly wants “stop”, “up” and “down” you should define a switch with those three commands instead. (Can only be done textual on item level unfortunately)
No, the concept describes a RollerShutter to accept UpDown, StopMove and Percentage commands, so if a device expects “Up” as a command, the binding just should send “Up”.
I would understand his comment in a different way, as it is about the state handling, which indeed is a percentage value. Movement control should be possible by sending Up/Down/Stop to a device, without the need of workarounds like virtual items and rules.
I need to “cache” the mqtt topic value, because I get it only once, while subscribing. Now imagine the following scenarios:
The user publishes “37” → I’m storing a percentage value of 37% and hand it over to the framework as state update. All good.
The user publishes “UP”,“DOWN”,“STOP”. I have no idea how to “change” my cached value. In my earlier version of the PR I just left it as it is and posted UP/DOWN/STOP as a command to the framework. Kai wants me to post a command of 0% and 100% for UP/DOWN respectively though.
User changes state
The user changes the rollershutter item state to “37” → I’m publishing a value of “37”.
The user issues an “UP”,“DOWN”,“STOP” command. In my earlier version of the PR I was just sending those commands. But Kai presumably disagrees, because he wants me to publish “0” and “100” for “UP” and “DOWN” respectively.
So I don’t really know how to handle this at the moment. That’s why the PR is a bit stale right now.
If a DOWN command is issued without interruption, this would result to a percentage value of 100%, UP to 0%.
So far so good. What about a STOP command? how would you translate this to percentage, what value to cache?
I see the main issue and concerns in caching any values.
I was able to successfully integrate the MQTT binding with the new version 2.5.0 into my system with RbP3.
The Sonoff switches work, now I still have RGB LED bands and IR transmitters on Sonoff.
Has anyone done that on the new MQTT?
I would be grateful for any tips!
Is there any update on this? I updated to the 2.5.0 snapshot version of OH because I had both MQTT1 and MQTT2 bindings running to allow me to use my MQTT rollershutter (a Shelly2) with openHAB 2.4.0. After a reboot a few days ago somehow the old binding wouldn’t really work anymore, so the device (and others which I haven’t converted to MQTT2 yet) stopped working…
and I am not sure what to do about the problem that only 0 and 100 are published to the command topic. The Shelly2 needs “open” (100) and “close”. I do have those mappings in the shellies.map file, but it looks like that isn’t used.
So I cannot use the binding for the rollershutters yet? You said in another post:
If I understand correctly, that hasn’t been integrated yet? I guess I will have to find out why the MQTT1 does not work anymore until you get to implementing the outgoing transformation?