Shutter: Open and Close in a single feature

[stefxx]

Hi, I need some help here. I have a Shelly 2.5 configured as a shutter module. This means I have Power1 and Power2 (as separate switches), to switch up and down in an on (open/close) and off (stop) state. I have them configured as separate features in HS4 like this:



So far, so good. But wouldn’t it be better if we would have a single feature with two buttons, Open and Close? Pressing Open once opens the shutter, pressing it again stops the shutter. Same for Close. Tasmota has ShutterStopOpen and ShutterStopClose so it should be possible.

I tried to follow 4.1.28 but I cannot figure it out. I assigned both stat/xxx/Power1 and stat/xxx/Power2 to the same device. Then I try to edit the first topic, but it seems to update the second topic at the same time, so I cannot update the correct Replace fields. Also, I have no clue how to assign the Open and Close buttons to cmnd/xxx/ShutterStopOpen and cmnd/xxx/ShutterStopClose, without sending the feature value.

Thanks!

[stefxx]

After upgrading to 5.7.0.0 I am able to make changes to individual topics, so that is resolved. This is what I did:

Payload RegEx Match Pattern: .+
Payload RegEx Replace Pattern: Power1 or Power2 (depending on topic)
Payload RegEx Operation: Replace Match Pattern With Replace Pattern
HS Device Publish Topic: stat/xxx/ShutterStopOpen or stat/xxx/ShutterStopClose (depending on topic)
HS Device Control/Status UI: Button
HS Device VSP List:
- Payload Closed=0;Closed VSP
- Payload Open=1;Open VSP

This is the resulting feature:


What am I missing?

[Michael McSharry]

You now have two relay status reported by Tasmota which I assume come in JSON payload something like {..."Power1":ON,"Power2":OFF...}
This will be shown on Association tab as rows
xyz:Power1 ON
xyz:Power2 OFF
They could be two separate topics as well. xyz is just a made up topic to simplify illustration.

You want these to show up in HS as single device that combines the status of the two rows.
I would Associate the second row (the one that comes later in the JSON payload) with HS device.
In the Expression field combine the two payloads as two catenated strings

"$$PAYLOAD:(xyz:Power1):"&"$$PAYLOAD:"

This will result in status values of OFFOFF, OFFON, ONOFF and ONON when all combinations are received.
Use the VSP edit to change the HS status to be appropriate. e.g. OFFOFF=0;CLOSED
Use the VSP edit to create two additional values that will be used for the control (e.g. CLOSE=4;ShutterStopClose)
In the Publish Topic use cmnd/xyz/$$LABEL:

I would expect Tasmota to update the relay status when it receives the ShutterStopClose command and this would then be reflected in the created HS device as one of the four states of the two relays.

[Michael McSharry]

I gave it a try to see if my guidance worked and I was pretty close. I had done expressions only for the text and number types. The button and list were not included so I added them in http://mcsSprinklers.com/HSPI_mcsMQTT_5_7_0_4.zip

When setting up the two control VSP reverse the order such as ShutterStopClose=4;CLOSE. This will put the HS Button label as CLOSE and the $$LABEL: substitution as ShutterStopClose. The Payload also includes ShutterStopClose so change the payload template if you want something different.

I left the button for the four relay states during my test, but they could be deleted from the HS Devices page since they serve no purpose

[stefxx]

Thanks! I will give it another try tonight.

One question, after the shutter is opened or closed, the result will always be that both switches are OFF. So I guess it will not show the last status, correct? Not a big issue, but would be nice.

[Michael McSharry]

I think you can define a virtual device with just two VSP having the same button labels and publish topic for control as my example. The virtual device should retain the last HS command. You can also associate the two relays to get relay status in addition to the commanded-position status. The status feature(s) would not have any publish topic assigned.

Another approach, may be via events (with script) that trigger on the relays state sequence. This would position based upon feedback rather than position based upon command.

[stefxx]

Thanks! I've got the basics working now.

[stefxx]

Many of my features of type "Button" now have a value of -1 (instead of the normal 0 or 1). I had to go back to 5.7.0.0 to fix this.

[Michael McSharry]

I made the Button/List Expression evaluation dependent on a non-empty Expression text box in 5.7.0.5 so it should work the same as before for the default case. http://mcsSprinklers.com/HSPI_mcsMQTT_5_7_0_5.zip. I'm heading for airport and don't have time to test, but .4 and .5 are very minor updates.

[Michael McSharry]

Updates that property handle text, VSP, and numbers with and without expressions is at http://mcsSprinklers.com/HSPI_mcsMQTT_5_7_0_7.zip (HS4) and http://mcsSprinklers.com/mcsMQTT_5_7_0_7.zip (HS3).

[stefxx]

Thanks. Enjoy your trip!

[stefxx]

Michael, there still seems to be an issue with the Expression calculation. For a sensor that returns 0 or 1, I always used "$$PAYLOAD: * 100" as I needed 0 and 100. Since the last versions, when I receive 0 the result of the calculation is -1. When I receive 1, the result is 0.

Could any of your recent changes has caused this? Thanks!

[Michael McSharry]

You are correct. Cut/Paste error when trying to keep the two plugin versions in sync. I will post an update later today.
nValue = nvalue = System.Convert.ToDecimal(sNewValue, New System.Globalization.CultureInfo("en-US"))

[Michael McSharry]

What I have decided as the most flexible approach is to build upon the ability to associate multiple topics to the same HS feature. This allows the slider and the buttons to be specified at the MQTT topic/payload level where the plugin is oriented. Behind-the-scenes logic is used to build the combined button/slider controls for HS when the same Ref has a slider and a button topic.

The problem with this is that the one-to-may relationship for devices and topic was handled as a special case. To make this work it needs to be handled as a general case situation. Good for the long term, but a significant number of changes are needed to support it. The logic is similar in each case, but with multiple 100's of lines affected the potential for error is not 0%.

It is mostly done so I will be posting soon for other eyes as 5.9.0.0.

[stefxx]

Thanks Michael. Looking forward to this version. Happy to test!