Advice on Storing and Backing Up Bind Mounts - Docker

[Snowman]

I finally decided to make use of the DynamicGroupController.

I needed to find an easy/effective way to identify devices with low battery levels and this caught my attention.

I created an expression, actually two. One to get the entity names and another one to strip off "_battery_level" at the end of an entity name. That way it looks clean when a notification is sent.

So far, I like what it can do and will try to see where else I can leverage it despite being experimental.

I did search this forum for comments/feedback. I couldn't find any. So I apologize up front if there were.

Question for Patrick, am I safe to use this controller? Should I only use it for testing purposes?

Thanks

[toggledbits]

@Snowman I use it extensively. Since you didn't show your config for low battery devices, I'll show mine:

  - id: groups
    enabled: true
    implementation: DynamicGroupController
    name: Dynamic Group Controller
    config:
      groups:
        battery_operated:
          select:
            - include_capability: battery_power
        low_battery:
          select:
            - include_group:
              - battery_operated
          filter_expression: entity.attributes.battery_power.level < 0.5

I use two groups. The first just collects all of the devices that are battery-operated. The second filters that group for those with <50% battery level. I find it useful to have two groups, but you can certainly do this with one.

Here's the rule that triggers (sets) when the low battery group is not empty. It creates a local variable called low_names with the names of the devices to use in outbound email. The "sustained for" delay prevents spurious messages from a couple of devices that have occasional low reports as they get close to the limit (i.e. hystersis, because their response is not linear).

[Snowman]

Here's my config. I do like the way you did it though. Thanks for sharing.

• id: groups
  name: Dynamic Group Controller
  enable: true
  implementation: DynamicGroupController
  config:
  groups:
  "low_battery_entities":
  name: Low Battery Entities
  select:
  - include_capability:
  - battery_power
  - exclude_entity:
  - "hass>sensor_ip8_battery_level"
  - "hass>sensor_ipad_air_5_battery_level"
  - "hass>sensor_ip7_battery_level"
  - "hass>sensor_ipad_air_2_battery_level"
  filter_expression: "entity.attributes.battery_power.level <= 0.85"

[Snowman]

I have successfully implemented the battery_group as explained by Patrick.

I am now trying to create a group for two water leak sensors (at moment) so that I can tell which sensor has detected a leak.

Unfortunately, my local expression does not work. I am doing something wrong but don't know what.

  - id: groups
    enabled: true
    implementation: DynamicGroupController
    name: Dynamic Group Controller
    config:
     groups:
       # Water leak group
       water_leak_device:
         select:
           - include_capability: binary_sensor
           - include_entity:
             - "hass>binary_sensor_water_heater_leak_water_alarm_water_leak_detected"
             - "hass>binary_sensor_water_main_leak_water_alarm_water_leak_detected"
       water_leak_detected:
         select:
           - include_group:
             - water_leak_device
         filter_expression: entity.attributes.x_hass.state = on

The local expression
LeakNames: each id in matchEntities ( {group:'groups>water_leak_detected'} ) : getEntity( id ).name

[toggledbits]

Sorry, "does not work" is not an adequate description of the (any) problem. You don't say what you are getting, show any error messages, log snippets (you looked at the logs, right?), describe expectation vs observation, etc. Please add some detail.

[Snowman]

I have not looked at the log. Looking at it now.

[Snowman]

I did have a look at the log and nothing jumped at me. Hopefully I am giving you the right info.

[latest-23028]2023-02-07T21:50:01.584Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_water_main_leak_water_alarm_water_leak_detected
[latest-23028]2023-02-07T21:50:01.604Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) trigger evaluation result is true (previously false)
[latest-23028]2023-02-07T21:50:01.604Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluated; rule state transition from RESET to SET!
[latest-23028]2023-02-07T21:50:01.642Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluation complete
[latest-23028]2023-02-07T21:50:01.644Z Engine:INFO Enqueueing "Notification: Home Security - Open/close water main shut-off valve<SET>" (rule-kvo8us5v:S)
[latest-23028]2023-02-07T21:50:01.660Z Engine:NOTICE Starting reaction Notification: Home Security - Open/close water main shut-off valve<SET> (rule-kvo8us5v:S)
[latest-23028]2023-02-07T21:50:01.720Z HassController:INFO HassController#hass action power_switch.off([Object]{ "newTargetValue": "0" }) on Switch#hass>switch_water_shut_off succeeded
[latest-23028]2023-02-07T21:50:01.721Z Engine:INFO Resuming reaction Notification: Home Security - Open/close water main shut-off valve<SET> (rule-kvo8us5v:S) from step 1
[latest-23028]2023-02-07T21:50:01.746Z HassController:INFO HassController#hass action x_hass_system.call_service([Object]{ "service": "notify.all_devices", "data": "{\n "title": "Home Security",\n "message": "Water leak has been detected at 2023-02-07, 16:50. Closing main valve. "\n}" }) on System#hass>system succeeded
[latest-23028]2023-02-07T21:50:01.748Z Engine:INFO Resuming reaction Notification: Home Security - Open/close water main shut-off valve<SET> (rule-kvo8us5v:S) from step 2
[latest-23028]2023-02-07T21:50:02.903Z HassController:INFO HassController#hass action x_hass_system.call_service([Object]{ "service": "notify.gmail", "data": "{\n "title": "Home Security",\n "message": "Water leak has been detected. Closing main valve. "\n}" }) on System#hass>system succeeded
[latest-23028]2023-02-07T21:50:02.905Z Engine:INFO Resuming reaction Notification: Home Security - Open/close water main shut-off valve<SET> (rule-kvo8us5v:S) from step 3
[latest-23028]2023-02-07T21:50:02.906Z Engine:INFO Notification: Home Security - Open/close water main shut-off valve<SET> all actions completed.
[latest-23028]2023-02-07T21:50:05.741Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_water_main_leak_water_alarm_water_leak_detected
[latest-23028]2023-02-07T21:50:05.758Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) trigger evaluation result is false (previously true)
[latest-23028]2023-02-07T21:50:05.758Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluated; rule state transition from SET to RESET!
[latest-23028]2023-02-07T21:50:05.770Z Rule:INFO Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluation complete
[latest-23028]2023-02-07T21:50:05.772Z Engine:INFO Enqueueing "Notification: Home Security - Open/close water main shut-off valve<RESET>" (rule-kvo8us5v:R)
[latest-23028]2023-02-07T21:50:05.786Z Engine:NOTICE Starting reaction Notification: Home Security - Open/close water main shut-off valve<RESET> (rule-kvo8us5v:R)
[latest-23028]2023-02-07T21:50:05.901Z HassController:INFO HassController#hass action power_switch.on([Object]{ "newTargetValue": "1" }) on Switch#hass>switch_water_shut_off succeeded
[latest-23028]2023-02-07T21:50:05.903Z Engine:INFO Resuming reaction Notification: Home Security - Open/close water main shut-off valve<RESET> (rule-kvo8us5v:R) from step 1
[latest-23028]2023-02-07T21:50:05.923Z HassController:INFO HassController#hass action x_hass_system.call_service([Object]{ "service": "notify.all_devices", "data": "{\n "title": "Home Security",\n "message": "Water leak has been remedied at 2023-02-07, 16:50. Opening main valve."\n}" }) on System#hass>system succeeded
[latest-23028]2023-02-07T21:50:05.924Z Engine:INFO Resuming reaction Notification: Home Security - Open/close water main shut-off valve<RESET> (rule-kvo8us5v:R) from step 2
[latest-23028]2023-02-07T21:50:06.864Z HassController:INFO HassController#hass action x_hass_system.call_service([Object]{ "service": "notify.gmail", "data": "{\n "title": "Home Security",\n "message": "Water leak has been remedied at 2023-02-07, 16:50. Opening main valve."\n}" }) on System#hass>system succeeded
[latest-23028]2023-02-07T21:50:06.866Z Engine:INFO Resuming reaction Notification: Home Security - Open/close water main shut-off valve<RESET> (rule-kvo8us5v:R) from step 3
[latest-23028]2023-02-07T21:50:06.867Z Engine:INFO Notification: Home Security - Open/close water main shut-off valve<RESET> all actions completed.

The local expression always shows the two included leak sensors. Since there is no leak. I would expect the array to be "0".

A screenshot of one of the leak sensor attributes.

[toggledbits]

In the logfile, look for messages with DynamicGroupController on the line, particularly at Reactor startup (so, do a restart, then look). I'm guessing you're going to find a logged error for the expression:

         filter_expression: entity.attributes.x_hass.state = on

[Pabla]

try this

filter_expression: >
  entity.attributes.x_hass.state == 'on'

[toggledbits]

@Snowman, @Pabla is likely right, at least, that's one problem. But I was trying to lead you to the right place in the logs where you'd see more information... without making @Pabla's change, restart Reactor, and look at the startup messages, specifically those related to DynamicGroupController. I believe you'll find that the expression doesn't compile, and it complains about it. If you care, post the message(s) you find, and we'll keep going from there. Messages for anything other than DynamicGroupController are not likely relevant at this point.

Also, please use code block formatting for log snippets (as you did for your config in the original post).

[Snowman]

At Patrick suggestion, I got the following from the log file. I have replaced = on to = 'on'. Even tried = 1 and = true. Same warning: returned non-boolean (string).

[latest-23028]2023-02-08T22:36:49.294Z <DynamicGroupController:INFO> All controllers ready, setting up dynamic groups
[latest-23028]2023-02-08T22:36:49.313Z <DynamicGroupController:WARN> DynamicGroupController#groups filter expression entity.attributes.x_hass.state = 'on' returned non-boolean (string) on
[latest-23028]2023-02-08T22:36:49.313Z <DynamicGroupController:WARN> DynamicGroupController#groups filter expression entity.attributes.x_hass.state = 'on' returned non-boolean (string) on

[toggledbits]

Right, that's because = is the assignment operator... == and === are for comparisons. To keep it simple, use == here.

The === comparison operator requires that both operands are the same data type as well as the same value to be true (so "123" === 123 would be false), where the two-equal == does not check type, and will try to coerce the values to a common comparable type, so, for example, the string "123" would be taken as equal to the number 123 (i.e. "123" == 123 would be true), even though they are different data types.

[Snowman]

"==" did the trick. Stupid mistake on my part as if I was not aware of the differences. Thanks for your help.

Forgot to mention it requires double quotes.

filter_expression: entity.attributes.x_hass.state == "on"

[toggledbits]

It is one of the oddities of many computer languages, including C, C++, Java, and JavaScript, from which the expression syntax is derived. You are not the first to be bitten by it, and won't be the last!

[toggledbits]

@Snowman said in DynamicGroupController Feedback:

Forgot to mention it requires double quotes.

Actually, it's a good idea to surround the entire expression in quotes, since expressions often contain special characters that YAML doesn't want to digest.

In this case, that means you'd have quotes in quotes, which is fine, as long as they are different. In the expression itself, the expression language doesn't care if you use single quotes or double.

    filter_expression: "entity.attributes.x_hass.state == 'on'"

But I really think @Pabla 's form is the best... that's a special feature of YAML that works really well for expressions, so if you want to avoid headaches, write all your expressions the way he showed.

    filter_expression: > 
      entity.attributes.x_hass.state == 'on'    

In this case, everything idented under filter_expression is taken as part of the expression, so you can write multi-line expressions easily, too...

    filter_expression: >
      entity.attributes.leak_detector.state &&
      entity.attributes.temperature_sensor.value < 35