Fail safe condition for battery devices
-
@tamorgen said in Fail safe condition for battery devices:
Appreciate any ideas to make this more reliable.
Have you considered using a "while" group? Here's a simple example in a Reaction. You can embellish on this for more reliability:
The first action forces a refresh on the device, and the delay gives it a little time to settle. From there, the Repeat...While runs while the lock remains unlocked... it tries to lock the lock, and then waits a minute and will try again if the lock remains unlocked. You could add a refresh inside the loop as well.
@toggledbits
Thanks Patrick. That's exactly what I was looking for. I didn't even know about that Repeat While condition....2 blinds down, 12 to go..... Oh, multiply by 3.... open, close, sun.
This may take a while.
-
Okay, I may have spoke to soon.... the first blind in the series keeps opening and closing when I run it.
The idea here.... the repeat while checks for the position.... If it does not equal 0 (range is 0-100), then it is open. The action is cover.close, and then delay for 10 seconds before going on to the next one.
What could it be causing it to be stuck in the loop? I'm monitoring what it's doing, and the Current value: (number) changes between 0 and 50, whereas 50 being the open position.
-
The iBlinds 3.x implementation in ZWaveJSController commands 99 for close, not 0. Try using
position.set
with 0 instead. -
The iBlinds 3.x implementation in ZWaveJSController commands 99 for close, not 0. Try using
position.set
with 0 instead.@toggledbits said in Fail safe condition for battery devices:
The iBlinds 3.x implementation in ZWaveJSController commands 99 for close, not 0. Try using
position.set
with 0 instead.Not quite working either. Position 99 is Closed, down inside. Position 0 is Closed, up inside. The cover.open and cover.close commands work in my previous iteration. When I try and use the position.set command, I get unexpected results.
Below is the corresponding Open version. When I set the position.set to 50, which is 50% (halfway between 0 & 99, so the blinds are flat and fully open, it set's the position to 99, not 50.
If I use position.set to 1, the current value changes to 99, so for opening the blinds to that 50 value, position.set does not appear to be appropriate.
iBlinds now uses the Window Covering command class and not the previously used multilevel switch window class, which works fine for roller blinds, but not horizontal blinds.
-
Sorry, I erred... try using values in the range of 0 to 1 (so 50 = 0.5) for
position.set
.I would also be consistent and not use the extended attributes (
x_zwave_values...
), but ratherposition.value
and/orcover.state
. -
Sorry, I erred... try using values in the range of 0 to 1 (so 50 = 0.5) for
position.set
.I would also be consistent and not use the extended attributes (
x_zwave_values...
), but ratherposition.value
and/orcover.state
.@toggledbits said in Fail safe condition for battery devices:
Sorry, I erred... try using values in the range of 0 to 1 (so 50 = 0.5) for
position.set
.I would also be consistent and not use the extended attributes (
x_zwave_values...
), but ratherposition.value
and/orcover.state
.That makes sense. The cover.state is a True/False value, so I'm not quite sure what that does.
I've revised it, and I've extended the delay times out a bit. The first blind opens correctly, but the second one opens, and then closes itself again. I'm really perpelexed as to why.
-
@toggledbits said in Fail safe condition for battery devices:
Sorry, I erred... try using values in the range of 0 to 1 (so 50 = 0.5) for
position.set
.I would also be consistent and not use the extended attributes (
x_zwave_values...
), but ratherposition.value
and/orcover.state
.That makes sense. The cover.state is a True/False value, so I'm not quite sure what that does.
I've revised it, and I've extended the delay times out a bit. The first blind opens correctly, but the second one opens, and then closes itself again. I'm really perpelexed as to why.
@tamorgen said in Fail safe condition for battery devices:
That makes sense. The cover.state is a True/False value, so I'm not quite sure what that does.
Can you also post the full attributes for this device (using the Copy Attributes button)?
-
@tamorgen said in Fail safe condition for battery devices:
That makes sense. The cover.state is a True/False value, so I'm not quite sure what that does.
Can you also post the full attributes for this device (using the Copy Attributes button)?
@toggledbits said in Fail safe condition for battery devices:
Can you also post the full attributes for this device (using the Copy Attributes button)?
Here you go:
battery_power.level=0.9 battery_power.since=1721846488511 cover.state=false position.value=0 x_debug.dt={"entity_class":"Cover","match":"deviceClass.generic.key=17;deviceClass.specific.key=7","capabilities":["cover","toggle","position"],"primary_attribute":"cover.state","description":"Window Blind Controller","model":"iblinds V3","default_name":"Window Blind Controller","values":[{"valueId":"38:currentValue:","capabilities":{"cover":{"attributes":{"state":{"expr":"!(value == 0 || value >= 99)"}},"actions":{"open":{"valueId":"38:targetValue:","value":50},"close":{"valueId":"38:targetValue:","value":99},"stop":false}},"position":{"attributes":{"value":{"expr":"round( value / 99, 2 )"}},"actions":{"set":{"valueId":"38:targetValue","value":{"expr":"max( 0, min( 99, round( 100 * ( parameters.value ?# 0 ), 0 ) ) )"}},"increase":{"valueId":"38:targetValue","value":{"expr":"max( 0, min( 99, round( 100 * ( ( entity.attributes.position?.value ?# 0 ) + ( parameters.amount ?# 0.10 ) ), 0 ) ) )"}},"decrease":{"valueId":"38:targetValue","value":{"expr":"max( 0, min( 99, round( 100 * ( ( entity.attributes.position?.value ?# 0 ) - ( parameters.amount ?# 0.10 ) ), 0 ) ) )"}},"relative":{"valueId":"38:targetValue","value":{"expr":"max( 0, min( 99, round( 100 * ( ( entity.attributes.position?.value ?# 0 ) + ( parameters.amount ?# 0.10 ) ), 0 ) ) )"}}}},"toggle":{"actions":{"toggle":{"valueId":"38:targetValue:","value":{"expr":"entity.attributes.cover.state ? 99 : 50"}}}}}}],"manufacturerId":647,"productType":4,"productId":113} x_zwave_values.Battery_isLow=false x_zwave_values.Battery_level=90 x_zwave_values.Configuration_Close_Interval=15 x_zwave_values.Configuration_Default_ON_Value=50 x_zwave_values.Configuration_MC=1 x_zwave_values.Configuration_Maximum_Tilt_Level=null x_zwave_values.Configuration_Minimum_Tilt_Level=null x_zwave_values.Configuration_Movement_Duration=0 x_zwave_values.Configuration_Override_Response_to_ON_Command=null x_zwave_values.Configuration_Remote_Calibration=1 x_zwave_values.Configuration_Reset_Button=0 x_zwave_values.Configuration_Reverse_Direction=0 x_zwave_values.Configuration_Send_Reports=0 x_zwave_values.Indicator_Node_Identify_3=0 x_zwave_values.Indicator_Node_Identify_4=0 x_zwave_values.Indicator_Node_Identify_5=0 x_zwave_values.Indicator_identify=null x_zwave_values.Indicator_timeout=null x_zwave_values.Indicator_value=null x_zwave_values.Manufacturer_Specific_manufacturerId=647 x_zwave_values.Manufacturer_Specific_productId=114 x_zwave_values.Manufacturer_Specific_productType=4 x_zwave_values.Version_applicationBuildNumber=43707 x_zwave_values.Version_applicationFrameworkAPIVersion="3.12.1" x_zwave_values.Version_applicationFrameworkBuildNumber=35 x_zwave_values.Version_applicationVersion="3.12.1" x_zwave_values.Version_firmwareVersions=["3.12"] x_zwave_values.Version_hardwareVersion=2 x_zwave_values.Version_hostInterfaceBuildNumber=0 x_zwave_values.Version_hostInterfaceVersion="unused" x_zwave_values.Version_libraryType=3 x_zwave_values.Version_protocolVersion="7.12" x_zwave_values.Version_sdkVersion="7.12.2" x_zwave_values.Version_zWaveProtocolBuildNumber=35 x_zwave_values.Version_zWaveProtocolVersion="7.12.2" x_zwave_values.Window_Covering_currentValue_23=0 x_zwave_values.Window_Covering_duration_23={"value":0,"unit":"seconds"} x_zwave_values.Window_Covering_levelChangeDown_23=null x_zwave_values.Window_Covering_levelChangeUp_23=null x_zwave_values.Window_Covering_targetValue_23=0 zwave_device.capabilities=[106,112,114,128,134,135] zwave_device.endpoint=0 zwave_device.failed=false zwave_device.generic_class="Multilevel Switch" zwave_device.impl_sig="23326:1:23260:1" zwave_device.is_beaming=false zwave_device.is_listening=false zwave_device.is_routing=true zwave_device.is_secure=true zwave_device.manufacturer_info=[647,4,114] zwave_device.max_data_rate=null zwave_device.node_id=80 zwave_device.specific_class="Motor Control Class C" zwave_device.status=4 zwave_device.status_text="alive" zwave_device.version_info=[null,"3.12.1"]
-
So is it 80 or 81 that's not staying in the expected state?
-
Can you command 80 from the Entities list using the same actions and values?
-
Can you command 80 from the Entities list using the same actions and values?
@toggledbits said in Fail safe condition for battery devices:
Can you command 80 from the Entities list using the same actions and values?
Yes, it opens to 50% using position.set .50
When I use the reaction, it does change to .5, but then changes back after 20 or 30 seconds.
-
Is there a rule that could be triggered by the shade moving that's still active?
-
Is there a rule that could be triggered by the shade moving that's still active?
@toggledbits said in Fail safe condition for battery devices:
Is there a rule that could be triggered by the shade moving that's still active?
I don't believe so. I believe I would see other rules flashing active/green, were that to happen. If that was the case, manually doing it either through HA or through the entities tab, like you just had me do, would cause that reaction as well.
BTW, that was one of the first things I thought of. I had two separate reactor windows open, so I could monitor the Reactions tab, as well as the Blinds Rule Set rules simultaneously.
-
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.
-
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 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???
-
@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???
That would be me dying of embarrassment. I'm not sure how that got there.
Removed and surprise surprise, works fine.
-
Whew! All good!
-
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 ? -
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 ?@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.