I had window shade programmed with conditions on custom attributes, which worked fine. Now with direct support in 2.2.9, I rewrote that rule to use these new features. There is condition "IF windowShade opening THEN", but it doesn't work. It never evaluates as true. On device page, I can see the state is opening, but when I open the rule detail, it shows "IF windowShade opening (F) [FALSE] THEN". The same issue with "closing" condition.
The rule looks like this:
"Obývák závěs" is window shade, and the highlighted conditions never turns true, even when the device itself (on device details page) has windowShade: opening.
Is it only the display on the page displaying the rule that has you concerned? Or are you seeing this impact the way the rule functions when it is triggered?
The reason I ask is that I expect the display on the rule page is only evaluated when you open the page, not updated in real-time as the Window Shade is opening.
I know it's not updated real time. Opening/closing curtain takes quite a while, so I have time to open RM when it's actually happening, and it still shows "false". It's not just about the display, it's about the condition, it's not evaluated as true -> commands in that if branch are not executed. Here, when I press the button while curtian is opening/closing, it should stop, but it doesn't. I updated the rule like this to make it clear:
Those new conditions added in 2.2.9 doesn't work - shade opening/closing is false no matter what. When I add new condition on custom attribute (1st else-if), you can see it recognizes it, set to true, and execute those commands.
Another thing is that the Stop Shades command doesn't work either. I have to use dimmer capability and stop dimmer change to stop the curtain.
To me it looks like there is some issue with newly added shade/blind functionality in RM.
There is also issue with the Open/Close commands (last else-if in screenshot above: if level <= 50 then close else open)
Both of these commands do "close". Open does close too.
Depending on the triggers for the shade opening, the best I can offer would be to set a virtual switch or variable while it is in that state and then use this in your rule.... If the open / close can occur outside of HE, then that is more problematic....
On its surface this is not correct based on your screenshot, that shows opening(T) right after the ELSE-IF. But, I will investigate further. Please post a screenshot of the Settings portion of the App Status page for this rule, found from the cog icon upper right corner of the rule.
It would also be most helpful if you could post logs from this rule. Turn on all logging, put the rule through running, and then post a screenshot of the Logs. This will show the events that the rule is responding to, and we can compare those to the actions it takes or not.
First IF uses the new shade conditions added in 2.2.9 - and it shows false. ELSE-IF that follows has the exact same condition, only this time done as condition on custom attributes, to show that this way it works and it's nothing with device, but it's really the new conditions.
OK, understood. But I need more information as described in my post just above.
Sure, sorry, I was not on home network so couldn't get those screenshots. Settings for this rule is so long, so for debug purposes, I created much simpler app in RM which has the same issue:
When curtain is opening and I press button, it should turn off light. It doesn't, because it doesn't recognize curtain opening.
Settings:
Logs:
I pressed the button when window shade was opening (and device page indeed displayed windowShade: opening.
OK, thanks. I will put some more effort into investigating.
On the shade device in question, would you go to its device page, and open the Events with button at top of page. Past a screenshot of that here, hopefully covering same time period.
I wonder if this is a race condition, where the rule is running before the shade reports 'opening'. You could test that theory by putting in a Wait for Event prior to the IF-THEN, Wait for shade changed.
I triggered curtain opening, and then waited about 5 secs until I pressed button to trigger RM, so it doesn't look like race condition. I thought it is some easy fix, missing subscription or something, but it starts looking much more complicated.
I will go experiment with this, see what I can find.
I think I already see the problem with this.
OK, this has been tracked down and fixed. There were two bugs, both fixed and will be in the next release.
2 Likes
This now fixed in new release:
It works, thank you 
