Rollershutters stops operating with Alexa today, direction inverted

Has anyone else noticed that there are no controls in the Alexa app (ios) after this change? However, voice commands still working, but no longer control via smart devices in the app.
Addendum: Of course, only applies to blinds. Light still ok.

You have to trigger a discovery each time you are making changes to your Alexa configuration on your OH server. You don’t need to delete them beforehand though. However, it doesn’t hurt to do so to confirm a given device was properly rediscovered.

This is a known issue as mentioned above.

2 Likes

Not yet… I will make each blind with a diferent combination to test witch one works correctly.

Still work reversed with both options. I have rediscovered devices, deleted and rediscovered again to be sure that there are really rediscovered. All time works at oposite with inverted and without it :frowning:

Any other things that I can test?

Rollershutter persiana8 "Persiana Ocho" <persiana> { alexa="Blind", channel="mqtt:topic:mosquitto:persianes:P8" }
Rollershutter persiana9 "Persiana Nueve" <persiana> { alexa="Blind" [inverted=false], channel="mqtt:topic:mosquitto:persianes:P9" }

Can you provide your event logs associated to the Alexa commands you requested?

This is the code of this all 4 blinds:

ollershutter persiana5 "Persiana Cinco" <persiana> { alexa="RangeController.rangeValue" [category="EXTERIOR_BLIND", friendlyNames="@Setting.Opening", supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=0,Open=100,Lower=(-100),Raise=(+100)", stateMappings="Closed=0:49,Open=50:100" ], channel="mqtt:topic:mosquitto:persianes:P5" }
Rollershutter persiana6 "Persiana Seis" <persiana> { alexa="RangeController.rangeValue" [category="EXTERIOR_BLIND", friendlyNames="@Setting.Opening", supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+100),Raise=(-100)", stateMappings="Closed=50:100,Open=0:49" ], channel="mqtt:topic:mosquitto:persianes:P6" }
Rollershutter persiana8 "Persiana Ocho" <persiana> { alexa="Blind", channel="mqtt:topic:mosquitto:persianes:P8" }
Rollershutter persiana9 "Persiana Nueve" <persiana> { alexa="Blind" [inverted=false], channel="mqtt:topic:mosquitto:persianes:P9" }

With all of them, if I say “Alexa Baja Persiana X” (Alexa Down Persiana X), in MQTT I receive a 100 command, no matter what combination I have, all four of them receive a 100 command.

image

Ruben

I would have expected that your persiana8 and persiana9 items to receive an UP command opposed to 100 as it was previously. This sounds like these items haven’t been rediscovered. Can you provide the actual content of your event logs?

Thanks Jeremy. I will check the log, because I have to enable a lower level of verbossing on log. Actually doesn’t see any information about Alexa. Can I enable a lower level only for Alexa?

Ruben

I am referring to events logs (events.log) opposed to server logs (openhab.log). There are generated with the standard log level.

Sorry for before post. I have checked again. This is what I received on Persianas 6, 5, 8 and 9 for telling to do Down:

2021-12-16 19:45:43.227 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'persiana6' received command 10
2021-12-16 19:45:43.274 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'persiana6' predicted to become 10
2021-12-16 19:45:43.274 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'persiana6' changed from 0 to 10

2021-12-16 19:45:50.507 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'persiana5' received command 10
2021-12-16 19:45:50.529 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'persiana5' predicted to become 10
2021-12-16 19:45:50.538 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'persiana5' changed from 0 to 10

021-12-16 19:45:57.349 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'persiana8' received command DOWN
2021-12-16 19:45:57.364 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'persiana8' predicted to become DOWN
2021-12-16 19:45:57.364 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'persiana8' changed from 0 to 100

2021-12-16 19:46:03.956 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'persiana9' received command DOWN
2021-12-16 19:46:03.988 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'persiana9' predicted to become DOWN
2021-12-16 19:46:04.003 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'persiana9' changed from 0 to 100

All four defined as before post.

So I just realized that your items are linked to the MQTT binding. I will assume that your integration doesn’t support UP/DOWN/STOP commands? If this is the case, why not use Dimmer items over Rollershutter?

Anyway, if you insist using Rollershutter items, you will have to specify the action mappings since this is not the standard use case for these items.

Rollershutter persiana5 "Persiana Cinco" <persiana> { alexa="Blind" [inverted=false, actionMappings="Close=0,Open=100,Lower=0,Raise=100"], channel="mqtt:topic:mosquitto:persianes:P5" }
Rollershutter persiana6 "Persiana Seis" <persiana> { alexa="Blind" [actionMappings="Close=100,Open=0,Lower=100,Raise=0"], channel="mqtt:topic:mosquitto:persianes:P6" }

Otherwise, if you transition to Dimmer items (not inverted by default)

Dimmer persiana5 "Persiana Cinco" <persiana> { alexa="Blind", channel="mqtt:topic:mosquitto:persianes:P5" }
Dimmer persiana6 "Persiana Seis" <persiana> { alexa="Blind" [inverted=true], channel="mqtt:topic:mosquitto:persianes:P6" }

I will test both and tell you.
Really it is linked to MQTT because the home automation of blinds are not standard and I use a custom software to send commands to it (I could also recompile it for using reversed, but I prefer to know what is happening with OH before).

I could also change my automation part to UP/STOP/DOWN (maybe it could be better), because my blinds really have two buttons to up and down, and really I can’t control position, only all open or closed. But, to MQTT broker never arrives UP/DOWN commands, only number percent values, no matter I use “Blind”. Probably could be the better option, but… what can I do to receive de UP/DOWN command on MQTT instead of 0/100?

Thanks in advance.
Ruben
EDITED: Works!!!.. all four suggestions work in the correct direction!
And also I suppose that need to change the “things” type of this MQTT commands to allow UP/DOWN reach the broker instead of number.

Thanks very much, and sorry for all messages.

If there are only two states and you can’t stop your blinds while transitioning from one state to the other, you should probably use a Switch item and map the on/off commands with the blind integration connected to your MQTT server, assuming you can make that change.

Doing so would basically switch the Blind device type default attribute, at the skill level, from PositionState to OpenState. Also, if the current state of your blinds aren’t retrievable, you should add metadata parameter retrievable=false on each item (command only support).

Switch persiana5 "Persiana Cinco" <persiana> { alexa="Blind", channel="mqtt:topic:mosquitto:persianes:P5" }
Switch persiana6 "Persiana Seis" <persiana> { alexa="Blind" [inverted=true], channel="mqtt:topic:mosquitto:persianes:P6" }

But in this case I need two switch for every blind, because I have two push-buttons for every blind (one push button to go up, and other to go down). I can stop the blind pushing the button again (or the reverse one). For me is working correcly with Rollershutter until now, with both Alexa, and OH (and also manual pushbuttons). Maybe I can test the “retrievable” metadata parameter to see which difference I have.

BUT!, I have realized a problem: I have used your suggestion “alexa=“Blind” [inverted=false, actionMappings=“Close=0,Open=100,Lower=0,Raise=100”]” with Rollershutter item type. Until now, I have several groups on Alexa App, for example “Salon”, with some lights, some blinds, and a “Blinds” group with all blinds. Until now, I can say “Down Salon”, or “Down Blinds”, and Alexa down salon blinds, or all blinds… but now if I say that, Alexa tell me that is incompatible. :thinking::confused:. Maybe defining as Dimmer could work?

Ruben
Edited: on the stop thing, I would refer that I can’t do for example 50% closed, only can do a timing on each one supposing on a know up or down state.

You don’t: ON = OPEN/UP; OFF = CLOSE/DOWN

If this is the case, using a Rollershutter item makes sense. However, as you mentioned your blind integration consuming the MQTT messages will need to be updated to support UP, DOWN and STOP commands instead of position level.

For the STOP support, assuming you have to push the same button direction that your blind is transitioning to, you will need to cache the previous command triggered so you can send it again.

How did you define your blind groups?

Thanks for all, probably in a future I try to migrate to UP/DOWN/STOP. By now is working correctly with percent values, as I have adapted to it.

The groups are defined with Alexa phone App, on device section, as Groups. Something has changed on Skill, because it was working until lasts versions of Skill.

Ruben

If you deleted your previous items, you need to add the newly discovered one to your Alexa groups.

I only have deleted two items, and added again… but I am not sure if in all groups. Tomorrow I check it again (now is impossible or my wife could kill me :smiley: )

1 Like

I had the same problem, and simply changing to “{alexa=“Shutter”}” fixed it for me.

However, I still have the same problem I always had, namely that shutters are not properly assigned to the room they’re in. E.g. if I’m in the bedroom and say “close shutter” then it actually closes the shutter in the bathroom. I have to say “close shutter in bedroom” to make Alexa close the correct shutter.

This room assignment works great for lamps and switches, but for shutters it doesn’t seem to work properly. Any hope to have that fixed at some point?

1 Like

Your assessment is spot on. Unfortunately, the room awareness feature is handled on the Alexa side and we have no control at the skill level. So there is not much that can be done other than implement the workaround below using the Amazon Echo Control binding.