This changes:
No, did no discovery. Is this necessary?
Not meaning to hijack folks, in a similar situation here. Happy to provide .items and .rules (if that would help). Running OpenHab 2.5 on a Raspberry Pi with 2 Somfy roller blinds controlled via RFXTRX.
Yes. The skill only works currently on a poll basis. So the Alexa side won’t know any configuration changes you made in OH until you trigger a discovery.
That’s actually a minimum requirement 
Please provide that information and any details that would help narrow down the issue. Thanks.
Came here for the same issue.
Glad to know my wife isn’t the only one which is angry about this change. 
1 Like
I feared the duplicates, but now I’ve triggered the discovery. No duplicates, no new devices, but it seems that the devices were updated.
Now it is running again. Thanks a lot.
1 Like
You’re too kind Jeremy! Thank you
.item definition
Rollershutter Down_Stairs_Blind "Down Stairs Blind" {alexa="RangeController.rangeValue" [category="INTERIOR_BLIND", friendlyNames="@Setting.Opening", supportedRange="0:100", unitOfMeasure="Percent", actionMappings="Close=0,Open=100", stateMappings="Closed=0,Open=1:100"]}
.rule defintion
rule "Down Stairs Voice Control"
when
Item Down_Stairs_Blind received command
then
logInfo("Down_Stairs_Blind", "Downstairs Blind Voice Control")
if (receivedCommand > 50)
{
sendCommand(rfxcom_rfy_b6a20466_shutter, UP)
logInfo("Down_Stairs_Blind", "Downstairs Blind going up")
}
else
{
sendCommand(rfxcom_rfy_b6a20466_shutter, DOWN)
logInfo("Down_Stairs_Blind", "Downstairs Blind going down")
}
end
Hope that makes some sense. WAF is diminishing here. Probably should have said, the way it “used” to work was by saying, “Alexa, close downstairs blind” (and it would go down) and conversely “Alexa, open downstairs blind” (and it would go up).
So what is your experience currently? inverted or not working?
If inverted, you would need to invert receivedCommand < 50 in your rule or update the semantic mappings metadata parameters as I mentioned above.
Anyway, you certainly would benefit using the new syntax I mentioned above which will remove the need for your rule.
Rollershutter Down_Stairs_Blind "Down Stairs Blind" {alexa="Blind"}
Alexa, open the down stairs blind => UP command sent
Alexa, close the down stairs blind => DOWN command sent
Alexa, stop the down stairs blind => STOP command sent
(Make sure to trigger a discovery after making the configuration change)
1 Like
I can confirm that the solution is working.
Old Syntax
{alexa="RangeController.rangeValue" [category="INTERIOR_BLIND", friendlyNames="@Setting.Opening", supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)", stateMappings="Closed=100,Open=0:99"]}
New syntax
{alexa="Shutter"}
Thanks for the help.
Discovery after updating the items required.
Wife = Happy.
2 Likes
Sorry, was not clear, it’s no longer working via Alexa. Works just fine via PaperUI “Control” node. Trying your suggestion now (getting rid of the rule and adding the new syntax)
Nice! So the new syntax is not so daunting after all
Keep in mind that you can use one of the window covering device type that matches your setup. I used Shutter above based on @Celaeno1 item definition.
Basically, Blind/Curtain/Shade are modeled as what was previously known as INTERIOR_BLIND category while Shutter/Awning as EXTERIOR_BLIND.
Thanks for the hint.
But as far as I understand, this is more about cosmetics than about functionality?
In some cases, it is just less complex to setup without any additional functionality. In the case of the window covering attributes, it now interacts with Rollershutter items the same way you would do in OH and how the majority of the binding integrations intended to be, using UP/DOWN/STOP commands opposed to specific percentage value. Also, less fiddling with inverted configuration. So it might seem there is no differences on the surface, but there are some subtle changes in the background that advanced users were looking for.
Argh! Still not working. Tried it with;
Rollershutter Down_Stairs_Blind "Down Stairs Blind" {alexa="Shutter"}
and with
Rollershutter Down_Stairs_Blind "Down Stairs Blind" {alexa="Blind"}
In both cases, the blind is already down so the first command i said was, “Alexa, open downstairs blind”. She replies, “OK” and the following appears in the log
2021-12-14 21:08:16.705 [ome.event.ItemCommandEvent] - Item 'Down_Stairs_Blind' received command UP
But nothing actually happens, the blind stays down. I then tried “Alexa, close downstairs blind”. She responds with, “Downstairs blind doesn’t support that”. At least she’s talking to me, unlike wife 
So I missed the part that this is a proxy item. You should set this configuration directly onto your rfxcom_rfy_b6a20466_shutter item and get rid of that proxy item
The skill is working as expected.
As far as the close utterance failure, you should give a try again and check your voice history to confirm it was understood as expected. I suspect an issue with your device name between “down stairs” and “downstairs” where I believe the latter is the proper term.
No no, I meant the configuration with INTERIOR_BLIND vs. EXTERIOR_BLIND and ‘Shutter’ vs. ‘Blind’. From what I see in the documentation, the attributes are the same.
No question about the simplicity which is now part of the new feature set. This is wonderful.
1 Like
Related to that configuration, you are correct that there is no differences in functionality between the different window covering device types I listed above.
Hi, I have a similar issue. I’m trying to set up my rolershtters using new syntax but alexa doesn’t discover them anymore.
I removed the item from alexa app, changed configuration on the item in openHAB MainUI, then run a discovery but no item is found.
Edit: item configuration
Thx
I assume you clicked save in the MainUI after making the configuration change? I am asking because it happened to me while testing
Do other configuration changes get discovered? Also, is that item part of a group? If so, does this group have a metadata configuration for Alexa?
Also, in term of configuration, why don’t you just use Shutter or Shutter.PositionState Alexa device type/attribute? There is no need to use a generic attribute anymore in that use case since there is a specific attribute for controlling the position of a window covering device.
ahahah it happend many times to me as well: yes I saved 
yes
no, never done that and so far it worked. Should I do it?
because I tried those first and the item wasn’t discovered. Then I tried the other ones and last the most complex and flexible one.
yes. I tried with a new switch.
thx