Log files

[Pabla]

Hello all, on Reactor Vera I had a few expressions built (with the help of some of you guys) that basically listed all security sensors and then from that list, another expression listed the sensors that were tripped. Attached is a screenshot of that.

I want to recreate those same expressions and have really only gotten as far as being able to list all the sensors as an array and since MSR expressions are not like Vera Reactors expressions I am a bit stuck. I basically need help creating an expression that will check the binary_sensor.state and if its true create spit out its entity name, and if false null. After that I think I should be able to create a message expression in similar fashion to the Vera expression.

[toggledbits]

This thread.is a pretty good starting point. It covers a straight line approach to what you want to do. There are some enhancements available since that thread (like DynamicGroupController), but those are more advanced topics, so for this first step, stick to the basic way described in the post, which is pretty much the same as R4V, just with the updated syntax.

Also, be sure to check out the Expression documentation for some additional clarity on the updated expression syntax. I think the bulk of the changes are not in the language itself (but there are adjustments, for sure), but mostly in the function library.

[Pabla]

Perfect was basically able to copy paste your solution and tweak it a bit to work. Attached is the screenshot for anyone's future reference!

[Pabla]

Final question, can I use an expression variable in the a HA service call? I have tried this in the past but can't get it to work. The TTS is saying 'tripped_zone_names' and not the actual names of the tripped zones.

Here is the data in the service call if the screenshot isn't clear enough

{
    "entity_id": "media_player.living_room",
    "message": "ALERT the ${{ tripped_zone_names }} have been opened",
    "cache": true
}

[toggledbits]

You can't do it in x_hass_system.call_service (specifically and uniquely) because the data is an object field in that action, and the substitution doesn't work in object types, only in strings. You need to use the actions available in x_hass_tts. If your media_player.living_room does not natively have x_hass_tts actions listed, you'll need to add them by copy-pasting this to a file called local_hass_devices.yaml in your config directory (and restart Reactor):

entities:
  # This media player supports TTS
  "hass>media_player_living_room":
    services:
      - tts

Unfortunately the Hass API doesn't expose enough info for Reactor to know that device supports the service, so it has to be done manually.

[Pabla]

@toggledbits said in Create Expression to call out Entity ID of Tripped Binary Sensor:

You can't do it in x_hass_system.call_service (specifically and uniquely) because the data is an object field in that action, and the substitution doesn't work in object types, only in strings.

Crap this throws a wrench in a lot of my automation plans. I tried to add the TTS functionality way back and never got it working will try again.

[Pabla]

Having some issues with the expression that determines what zones are true. It was working when I originally created the expression but I made a few tweaks to expression names and now it doesn't work. Here is a snippet of the logs. Also a screenshot of the expression

[latest-22248]2022-09-06T23:41:57.638Z <Rule:INFO> Zone Open ALERT (Rule#rule-grpot1ehov) evaluation complete
[latest-22248]2022-09-06T23:41:57.639Z <Rule:INFO> Babay/Papa Windows (Rule#rule-l7jasakd) starting evaluation; because entity-changed Entity#hass>binary_sensor_babay_papa_windows
[latest-22248]2022-09-06T23:41:57.639Z <Rule:INFO> Zone Open ALERT (Rule#rule-grpot1ehov) starting evaluation; because entity-changed Entity#hass>binary_sensor_babay_papa_windows
[latest-22248]2022-09-06T23:41:57.640Z <Rule:INFO> Babay/Papa Windows (Rule#rule-l7jasakd) evaluated; trigger state unchanged (false); rule state remains RESET
[latest-22248]2022-09-06T23:41:57.640Z <Rule:INFO> Zone Open ALERT (Rule#rule-grpot1ehov) evaluated; trigger state unchanged (false); rule state remains RESET
[latest-22248]2022-09-06T23:41:57.640Z <Rule:INFO> Babay/Papa Windows (Rule#rule-l7jasakd) evaluation complete
[latest-22248]2022-09-06T23:41:57.641Z <Rule:INFO> Zone Open ALERT (Rule#rule-grpot1ehov) evaluation complete
[latest-22248]2022-09-06T23:41:57.641Z <Engine:ERR> [Engine]Engine#1: error evaluating expression tripped_zones: [ReferenceError]ReferenceError: Invalid scope in reference to member binary_sensor of (object)null
[latest-22248]2022-09-06T23:41:57.642Z <Engine:ERR> [Engine]Engine#1: expression: each id in zones_list: getEntity(id).attribute.binary_sensor.state == "true" ? id : null
[latest-22248]2022-09-06T23:41:57.642Z <Engine:CRIT> ReferenceError: Invalid scope in reference to member binary_sensor of (object)null
ReferenceError: Invalid scope in reference to member binary_sensor of (object)null
    at _run (/home/armans2/reactor/common/lexp.js:1490:31)
    at _run (/home/armans2/reactor/common/lexp.js:1484:33)
    at _run (/home/armans2/reactor/common/lexp.js:1334:34)
    at _run (/home/armans2/reactor/common/lexp.js:1502:32)
    at _run (/home/armans2/reactor/common/lexp.js:1594:41)
    at /home/armans2/reactor/common/lexp.js:1324:29
    at Array.forEach (<anonymous>)
    at _run (/home/armans2/reactor/common/lexp.js:1323:28)
    at run (/home/armans2/reactor/common/lexp.js:1704:22)
    at Object.evaluate (/home/armans2/reactor/common/lexp.js:1740:20)

[Pabla]

Interestingly enough I am using almost the exact same expression elsewhere just fine

[toggledbits]

You're right... it is almost the exact same expression... almost. (I'm teaching here... look closely at the one the works, and the one that doesn't).

[wmarcolin]

Hi @Pabla

I'm sorry if I'm saying something wrong and out of the context of this discussion, but I'll put what I have that seems to be what you are looking for, using DynamicGroupController, which was an excellent feature that @toggledbits implemented.

config > reactor.yaml

  - id: groups
    enable: true
    implementation: DynamicGroupController
    name: Dynamic Group Controller
    config:
      groups:
        "dgc_low_battery":
          name: DGC Low Battery
          select:
            - include_capability:
              - battery_power
          filter_expression: >
            entity.attributes.battery_power.level < 0.3
        "dgc_tripped":
          name: DGC Tripped
          select:
            - include_capability:
              - door_sensor
              - motion_sensor
              - co_detector
              - smoke_detector
              - leak_detector
          filter_expression: >
            entity.attributes?.door_sensor?.state == true or
            entity.attributes?.motion_sensor?.state == true or
            entity.attributes?.co_detector?.state == true or
            entity.attributes?.smoke_detector?.state == true or
            entity.attributes?.leak_detector?.state == true
        "dgc_internal_motion":
          name: DGC Internal Motion
          select:
            - include_entity:
              - "hubitat>40"
              - "hubitat>41"
              - "hubitat>43"
              - "hubitat>73"
          filter_expression: >
            entity.attributes?.motion_sensor?.state == true

When I then have the information loaded, it is easy to handle in many situations.

In the example below, I put in the array HouseSECURITY which devices I want to monitor, according to the way the house is, and then I crosscheck with what comes from DynamicGroup, and display messages, take actions, etc..

At the moment, the house is in Day mode, so there is nothing, at night I load in this variable the list of doors and windows; when it is travel, I add movement.

I don't know if I helped or hindered.

Thanks.

[toggledbits]

It would be my preference that Pabla find his error, since the way he's doing it will work... worked before, and he said that, he just changed something that made it not work, and some troubleshooting is necessary. In this case, a "code review" is sufficient (a review of the failing expression, perhaps in conjunction with a careful comparison to the working similar expression).

[Pabla]

@toggledbits said in Create Expression to call out Entity ID of Tripped Binary Sensor:

You're right... it is almost the exact same expression... almost. (I'm teaching here... look closely at the one the works, and the one that doesn't).

Had a feeling it was a typo mistake, gonna take a look with some fresh eyes later today.

[Pabla]

@wmarcolin that’s my next plan! I want to get comfortable with some basic expressions first then dive into the dynamicgroupcontroller

[wmarcolin]

@pabla said in Create Expression to call out Entity ID of Tripped Binary Sensor:

dynamicgroupcontroller

I highly recommend taking the time to use DynamicGroupController, before I had huge global variables, complexity to monitor and create array, when this feature was implemented it made these group management actions by characteristics much easier. Good luck!

[Pabla]

@toggledbits said in Create Expression to call out Entity ID of Tripped Binary Sensor:

You're right... it is almost the exact same expression... almost. (I'm teaching here... look closely at the one the works, and the one that doesn't).

okay so I checked and noticed that I wrote attribute singular and in the working one made it attributes plural. Still no success.. I even got someone else to check the syntax and they weren't able to find a difference between the working and non-working expression.

I fear I am overlooking something super basic which I thought I fixed but I have yet to find the error

Edit: I had a typo in my array of entities all is well

[toggledbits]

Did the behavior change? If so, what does the new behavior look like? If not, what is in the logs?

[Pabla]

@toggledbits it works as expected now, I had a typo in one of my entities in the array.

[toggledbits]

@toggledbits said in Create Expression to call out Entity ID of Tripped Binary Sensor:

You can't do it in x_hass_system.call_service (specifically and uniquely) because the data is an object field in that action, and the substitution doesn't work in object types, only in strings.

This restriction has been lifted in build 22251. The data will now be stored as a string rather than an object, so that substitution can occur. This requires that any use of call_service be edited, so that the stored data is updated to the new form. You'll get alerts for actions that need to be edited. See the announcement for build 22251 for more info.