MSR UI on a mobile browser

[toggledbits]

Perhaps, but there's no command setting to closed in that reaction, either.

Another way to look at this is to open a second tab for Reactor, and stay on the Status page with the Running Reactions widget displayed. If the blind closes after the Reaction has stopped running, that suggests the command to close it is coming from elsewhere.

And of course, any time things don't look as expected, you should always be looking in the logs.

Edit: based on your edit, I'd make sure all rules doing anything with blinds are disabled during this testing.

[toggledbits]

@toggledbits said in Fail safe condition for battery devices:

Perhaps, but there's no command setting to closed in that reaction, either.

WAIT -- WHAT'S THIS???

[tamorgen]

@toggledbits,

That would be me dying of embarrassment. I'm not sure how that got there.

Removed and surprise surprise, works fine.

[toggledbits]

Whew! All good!

[gwp1]

Best thread ever given I have 13 iblinds and they get... cranky/fussy.

I'm going to pile onto the "wait, I never knew about Repeat While - when was this added @toggledbits ?

[tamorgen]

@gwp1 said in Fail safe condition for battery devices:

Best thread ever given I have 13 iblinds and they get... cranky/fussy.

I'm going to pile onto the "wait, I never knew about Repeat While - when was this added @toggledbits ?

I'm going to say they been a lot less cranky since I added the dead node routine. It's not strictly for iBlinds, but the battery powered devices are the ones that tend to not report in quite as regularly.

I also have a notification routine that sends me push notifications when battery level is below 35%. This used to be a huge problem when I ran Vera and the original iBlinds. Battery readings would go from 80% to dead overnight. Not so much a problem anymore with HA and the 3.1 version of iBlinds.

This whole thread came up, because I got tired of walking into a room, and wondering if my wife closed a blind on purpose, or if the routine that opens them failed in some manner. I'm hoping this will reduce my questioning.

[toggledbits]

@tamorgen said in Fail safe condition for battery devices:

I'm going to pile onto the "wait, I never knew about Repeat While - when was this added @toggledbits ?

Build 22023... two and a half years ago.

In fairness, though, it was advertised as "experimental" in the release notes, and I never did make another note to clear that status, so by the power vested in me by the Universal Life Church of Stockton, California USA, I hearby bless it.

[gwp1]

@toggledbits Praise be to He!

[gwp1]

@tamorgen @toggledbits is it better to use cover.open and cover.close or postion.set=.5 and 0/.99?

I'm noticing this morning after moving my open/close Reactions to Repeat While that the iblinds will "settle"... ie, land on .52 and then retry for the next few minutes until settling on .51 as "open".

[tamorgen]

@gwp1 said in Fail safe condition for battery devices:

is it better to use cover.open and cover.close or postion.set=.5 and 0/.99?

I'm not sure about better, but I'm now using the position.set for consistency. For each blind or set of blinds in a room, I have basically 3 possible positions I want them: Open, (50%/.51), Closed (0%/0, up inside), and a Sun glare position (80%/.81). it's just easier for me to have the same reaction set up, but change the position.set value.

[toggledbits]

@tamorgen said in Fail safe condition for battery devices:

Open, (50%/.51), Closed (0%/0, up inside),

Just a thought: using the between operator (e.g. between 0.495 and 0.515) to allow for floating-point round-off error is probably a good idea. Equality comparisons with floating point values has long been an avoided practice in good programming. In some cases, you may want the range even wider, because sometimes open just means not closed, and that's a big range of values. In fact, cover.state actually does this for slat devices, understanding that (ZWave/native values) 0 and 99 mean closed, so anything other than these two values is considered open (i.e. cover.state reports true).

And yes, using a range/between test applies even if the results are rounded explicitly (as position.value is). In programming classes, students are taught that a better test is abs( samplevalue - testvalue ) < smalldelta. If smalldelta is chosen appropriately, this is pretty much bulletproof across all systems/floating point implementations we normally encounter. You could do this kind of test in an expression in Reactor, but using between gives the same semantic result without the extra complexity.

@tamorgen said in Fail safe condition for battery devices:

I'm not sure about better, but I'm now using the position.set for consistency.

For slat devices, this is probably the best choice. I had to make an implementation decision for cover.close, whether that was going to mean slats fully up inside (0) or slats fully down inside (99). So I chose up (0). So you could use cover.close if my choice works for you, but using position.set can do either one, and always will.

[tamorgen]

@toggledbits said in Fail safe condition for battery devices:

Just a thought: using the between operator (e.g. between 0.495 and 0.515) to allow for floating-point round-off error is probably a good idea.

That's a good idea. The .51 value did work for me, but having that wiggle room could definitely save some headaches.

I would assume however, in this case, it would need to be not between in order for it to work, otherwise it'll keep running the repeat while when the condition has already been met.

[toggledbits]

Yes, between or not between as your logic requires, but the idea is the same.