Need help reducing false positive notifications

[tamorgen]

Good morning,
I'm trying to figure out if there is a way to evaluate if a command was completed and retry if it did not complete.

I have 14 iBlinds 3.1 z-wave controllers in my home. 95% of the time, they work just fine. Occasionally, I'll get a blind that does not open on the first attempt. When I go into Home Assistant, and manually open or close the blind, it works.

I have 3 reactions set up for each room. One to open, one to close, and one partial open for sun glare. Each of them is set up as below.

The reactions are set up to wait for 5 seconds before going onto the next blind, so the z-wave network doesn't get overwhelmed.

In addition, the set command to run the reactions has "Wait for completion" checked.

I also have a routine set up whenever a z-wave device reports as non-functional (dead), it'll get pinged to wake it up. This usually works to wake them up.

Appreciate any ideas to make this more reliable.

I'm running:

• Reactor latest-24190-bd310acc, Bare-metal on Fedora
• WaveJSController [0.1.23326]
• Home Assistant: 2024.7.0

[toggledbits]

@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.

[tamorgen]

@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.

[tamorgen]

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.

[toggledbits]

The iBlinds 3.x implementation in ZWaveJSController commands 99 for close, not 0. Try using position.set with 0 instead.

[tamorgen]

@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.

[toggledbits]

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 rather position.value and/or cover.state.

[tamorgen]

@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 rather position.value and/or cover.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]

@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]

@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"]

[toggledbits]

So is it 80 or 81 that's not staying in the expected state?

[tamorgen]

80, which is the second one

[toggledbits]

Can you command 80 from the Entities list using the same actions and values?

[tamorgen]

@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.

[toggledbits]

Is there a rule that could be triggered by the shade moving that's still active?

[tamorgen]

@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.

[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!