Gradually turn on lights.

[cw-kid]

I seem to have a problem with my trigger however

Its triggering the reaction when I don't want it to do so.

I need to make the value of the expression "battery_low_names" null when no devices are below the battery level of 10% etc.

I've tried adding in a ? in to the expression but it doesn't seem to be working

join( each id in battery_low_list: getEntity(id)?.name, ', ')

EDIT:

This seems to work instead adding "? id: null" to the end of the expression.

join( each id in battery_low_list: getEntity(id).name, ', ') ? id: null

EDIT 2:

Maybe it doesn't work because now its not putting in the devices name in the expression value

EDIT 3:

I then tried changing the trigger altogether to this, but it doesn't work and becomes true anyway.

Likewise with this one:

Maybe there is a bug? All of these are going true and running the reaction when I expect them not to do that

[Ian]

@cw-kid

I'm using this.

This goes true when battery_low_names is populated with the names of the devices with low battery levels.

[cw-kid]

@ian

That works !

Easy when you know how..

The trigger is now going false when no devices are in the battery_low_names expression results.

[toggledbits]

@toggledbits said in Rule for devices battery level ?:

(a string now) expression is not empty,

Details.

Also these can be rule expressions, they do not need to be global.

[cw-kid]

Thanks I've changed the expressions to local rule ones instead and its all still working.

[cw-kid]

How can I make this rule re-trigger ?

Say I don't immediate go replace the battery on the device mentioned, can I have the rule run the alerts / notifications each day or week until I have done it and changed the batteries ?

Also can the alerts also state what the battery level percentage actually is ?

Thanks

[toggledbits]

@cw-kid said in Rule for devices battery level ?:

How can I make this rule re-trigger ?

Wrap the condition in a group and put the group in "pulse" output mode with the timing you want.

@cw-kid said in Rule for devices battery level ?:

Also can the alerts also state what the battery level percentage actually is ?

Yes, but I'm going to leave it as an exercise for the reader. Level of difficulty: moderate.

[Ian]

@cw-kid

Try this.

[cw-kid]

@ian

Thanks Ian that works, my Telegram text message now has the number% at the end of the message now.

However this messes up the Google Home TTS announcement sent via node-red, if I have a "%" in the expression. So I had to change it to the word "percent" instead and now the TTS sounds correct when spoken.

join( each id in battery_low_list: getEntity(id).name + " " + "at" + " " + int(getEntity(id).attributes.battery_power.level * 100) + " percent", ', ')

[cw-kid]

@toggledbits said in Rule for devices battery level ?:

Wrap the condition in a group and put the group in "pulse" output mode with the timing you want.

Like this?

Seems to be working and the alerts are repeating every 60 seconds now. I will just set this to 24hrs I think.

[Crille]

@toggledbits said in Rule for devices battery level ?:

One of my to-do list tasks for expressions is to be able to create a list of devices that match a test.

This is very useful, is it released yet or still on the to-do list?

[toggledbits]

Still on the to-do list, but I think I'm close to figuring out what I want it to do. These things get harder with time: the more people use them, the more etched in stone they become, so making a "first guess" and completely changing things later isn't really something I want to do a lot of. If I can get something good on the first try, that's the way...

Here's what I'm thinking...

First, the matchEntities() function would quickly narrow down the set, in a manner similar to the filters on the Entities page and the Entity Picker:

    living_room_sensors = matchEntities( { controller: 'vera', capability: [ 'binary_sensor', 'value_sensor'' ], group: 'Living Room' } )

This would return an array of entities. From here, you could use an each statement to further filter any deep refinements. This expression would take the above array of sensors in the Living Room and pick out those that are battery powered and have battery level under 50%:

    low_battery_living_room = each e in living_room_sensors: e.attributes.battery_power?.level <= 0.5 ? e : null

I'm liking this approach because the function could do the bulk reduction of potential hundreds of entities down to a manageable list, and then the final filtering of the list can be done with expressions for maximum flexibility.

Any thoughts about that?

[Crille]

@toggledbits That would do it for me, is the matchEntities() function already available in Expressions? I get no error but no matter what I do the Expression always returns an empty array.
I'd expect this to contain at least something:

matchEntities( { controller: 'vera', capability: 'humidity_sensor' } )

[toggledbits]

No, it's not yet available.

[Crille]

Ah, that explains a lot I like the idea, it seems very flexible.

[Crille]

@toggledbits Thanks, the new matchEntities() is brilliant. Now we can have dynamic arrays of devices.

[toggledbits]

@crille said in Rule for devices battery level ?:

Now we can have dynamic arrays of devices.

Tell me about that...

[Crille]

@toggledbits Inspired by this topic I created a rule with similar expressions to monitor/notify x_ezlo_device.reachable for all my Ezlo devices. Instead of managing a static array, like the battery_device_list in this topic, the expression matchEntities( {capability: 'x_ezlo_device'} ) generates a list of devices that is dynamically updated if devices are added or removed from the controller.

[tunnus]

@toggledbits I'm testing this new function, but somehow it does not show all the devices I'm expecting it to show. See examples below

Array is empty, although it should contain one device:

Strange, as device 216 definitely has capability "x_vera_device"

[toggledbits]

One of the issues I see in matchEntities() as it currently works is that it returns an array of entity objects with attribute values, but it does not update that array when any of the returned entities' attributes or other values changes. So it's certain, then, that the attributes will go stale in the result array.

For the next build, I will change the definition of this function to return canonical entity IDs only, rather than entity objects, so you will have to use getEntity() in your each over the results, as you did with your test_array example, and this will ensure that you are always looking at the latest attributes. You can test this theory now by modifying your each for d_failure_list to use getEntity( id.canonical_id ).