[SOLVED] Triggering rule only when blinds go UP and should not stop when going UP

Setup, Configuration and Use Scripts & Rules
1

I have Simon blinds controller, which works with Zwave.

In the morning I have Alexa raising the blinds to 3% but then I always have to manually click quickly on the down button to close a little the blinds, so that they are not fully oppened (on the horizontal pads or whatever the name of that thing).

Well, anyway, this is what I want to do: Each time blinds go UP, whether clicking on the button manually or via OH or whatever, I want it to go DOWN for only 0.3 seconds.

I have setup this rule but problem is, if I remove the STOP trigger, this won’t start and if I setup with STOP rule, then this will always be triggered in an infinite loop. :frowning:

var Timer offTimer = null

rule "Fechar ligeiramente estores escritorio"
when
   Item brisa_escritorio received command UP or
   Item brisa_escritorio received command STOP
then
   offTimer = createTimer(now.plusSeconds(5), [|
      sendCommand(brisa_escritorio, DOWN)
   ])
   offTimer = createTimer(now.plusMillis(300), [|
      sendCommand(brisa_escritorio, STOP)
   ])
end

Any ideas?

2

First of all .3 seconds is just not going to happen. OH cannot respond that fast and more importantly, it will take longer than that for the Zwave device to report the button was pressed and for your stop command to be sent in response. If this can be done is less than a second I’ll be surprised.

Beyond that, check to see if the receivedCommand is STOP and only schedule the timer if it isn’t. That will break the loop.

3

WELP! I love when this happens. :rofl:

I basically solved the problem, but now I have another one.

My other problem is: what if I want blinds to go all the way up? I’ve just tested and it stops after those 5 seconds and starts going ALL THE WAY DOWN (WOT?!?).

I’ve now changed my cod to this:

var Timer offTimer = null

rule "Fechar ligeiramente estores escritorio"
when
   Item brisa_escritorio received command UP   
then
   offTimer = createTimer(now.plusSeconds(5), [|
      sendCommand(brisa_escritorio, DOWN) 
      offTimer = createTimer(now.plusMillis(400), [|
         sendCommand(brisa_escritorio, STOP)
      ])
   ])
end
4

That’s probably related to sending the command too fast. What if you use 1000 or 2000 just to test it. Does it stop then?

5

This is working. The STOP function always work now, I even had to change from 300 to 400 because it was just not closing enough. 1 second it’s too much time and it closes more than I want, so that’s why I want it specifically to close a certain way.

Problem here now is only that this will stop going UP when it’s active and going UP.

6

Is it possible to make it move 0.5% instead of 1%? Because if that’s possible, then that may be the solution for this problem because I wouldn’t need to have this milliseconds and I could put it waiting on the first part 1 minute to guarantee that it has time to fully reach the top if that’s the case.

My item is set like so btw:

Rollershutter brisa_escritorio "Brisa EscritĂłrio [%.0f %%]" <blind> (estores) ["Rollershutter"] {alexa="RangeController.rangeValue"
        [category="EXTERIOR_BLIND",
         friendlyNames="@Setting.Opening",
         supportedRange="0:100:1",
         unitOfMeasure="Percent",
         actionMappings="Close=0,Open=100,Lower=(-10),Raise=(+10)",
         stateMappings="Closed=0,Open=1:100"]}

Can I set this as 0.1 instead of 1?

I mean, is this even possible?

Rollershutter brisa_escritorio "Brisa EscritĂłrio [%.0f %%]" <blind> (estores) ["Rollershutter"] {alexa="RangeController.rangeValue"
        [category="EXTERIOR_BLIND",
         friendlyNames="@Setting.Opening",
         supportedRange="0:100:0.1",
         unitOfMeasure="Percent",
         actionMappings="Close=0,Open=100,Lower=(-1),Raise=(+1)",
         stateMappings="Closed=0,Open=0.1:100"]}
7

Rollershutter only supports PercentType so no, it only supports integers between 0 and 100.

8

That’s a shame. :frowning:

Well, anyway, my other problem still persists.

Is there a way to check if this is still going UP and therefore not activating the rule?

9

Only if you have an Item linked to a Channel that tells you that it’s in motion. Then you can have an if statement to ignore the event if it’s already in motion.

10

Hum, interesting! You mean have it linked like so:
Screenshot_2020-03-12_17-43-17

11

I can’t say. I don’t have this device. I don’t know how it works. But assuming that the device reports it’s current position, I would expect that Channel to provide that information.

12

@rlkoshak thank you for your kind help. :slight_smile:

I chosed to increase the time waiting on the first part to 1 minute so that it gives time for blinds to go all the way up. So this is solved and here’s the final code:

var Timer offTimer = null

rule "Fechar ligeiramente estores escritorio"
when
   Item brisa_escritorio received command UP   
then
   offTimer = createTimer(now.plusMinutes(1), [|
      sendCommand(brisa_escritorio, DOWN) 
      offTimer = createTimer(now.plusMillis(400), [|
         sendCommand(brisa_escritorio, STOP)
      ])
   ])
end

Although I will mark this topic as solved, because this solves the problem, I still have a different question here.

What if I really want to leave it all the way open without it slides this little bit (meaning, not running this rule)? Can you think of a way to do this?

Thanks. :slight_smile:

13 
    if(some condition) return;

You have to come up with what some condition is. Usually it’s the state of an Item.

14

Thank you for your help, but I just leave it with a timer of 1 minute and that’s enough for my case.

Also, when I arrived to the office this morning I noticed the blinds were not as I wanted. So I went to investigate and had to change my code for this, which now allows me to set it how I want, order it to stop and it will just not run the rule and leave the blinds as I wanted. :smiley:

var Timer offTimer = null

rule "Fechar ligeiramente estores escritorio"
when
   Item brisa_escritorio received command
then
   if(receivedCommand !== DOWN
      && receivedCommand !== STOP
      && receivedCommand !== 0
      && receivedCommand !== 100) {
      offTimer = createTimer(now.plusMinutes(1), [|
         sendCommand(brisa_escritorio, DOWN)
         offTimer = createTimer(now.plusMillis(400), [|
            sendCommand(brisa_escritorio, STOP)
         ])
      ])
   }
end

So that’s it, this topic is now fully solved and with the solution for future reference. :smiley:

15

that looks a little bit odd. Normally !== is used to compare against null. I think it should be != but if it works for you, then it must be okay.

1 Like
16

That’s actually not totally correct. These are called identity operators and are used when you want not only to compare the value but also the type.

So this means that comparing “ON” == ON result in being TRUE, but comparing “ON” === ON result in being FALSE.

17

That’s true in JavaScript but not Rules DSL. Your overall description on the difference about what === and !== means is generally correct, but in Rules DSL "ON" == ON will not return true. In Rules DSL, === only returns true if the operand on the left is pointing at the exact same Object (i.e. same place in memory) as the operand on the right. Thus, it can make sense to use === with enumerated types like ON/OFF but you should never use it in any other case. In general though, there is a whole bunch of stuff going on behind the scenes that might make the ON carried by an Item come from some other instance of OnOffType than the instance of OnOffType imported into the Rules context. If that were to occur, MySwitch.state === ON could return false even when MySwitch.state is ON.

Therefore the recommendation is to only use === and !== when null is one of the operands. In all other cases, even for enum types, use == and != in Rules DSL.

When using Scripted Automation, use what ever is correct and makes sense for the language you are using, only be aware that many of the Objects you will be working with are Java Objects so they may or may not behave as expected.

1 Like
18

Thanks a lot for the clarification @rlkoshak, always learning. :slight_smile: