Global Moderators group | Smart Home

toggledbits

Yes, I found this as well. I have a fix that I've been running/testing, not yet into a build. I will get it done before the end of the weekend.

therealdb

Number 2 seems more logical. Right now all we have are empty values.

Maybe some way to do easy things like

avg/min/max of values
if any matches a value (ie cool), the value is cool
and/or/xor for binary values

Similar to other options, to avoid code for simpler scenarios. Thanks.

toggledbits

Yes!

Question on your feature request... generally, a capability has to be defined on an entity to assign an attribute within that capability. A Group is a subclass of Entity that normally has a limited set of capabilities and attributes that don't vary from group to group (i.e. the sys_group capability is pretty much it).

I can see adding attributes to a Group two ways:

Like with actions, the capabilities the Group allows follows the superset of capabilities of the Group's members, so the group would inherit those capabilities and you would be allowed to set attributes (via expressions in config) for them, or...
In config, you set what capability you want to assign and set attributes for, and then supply the logic (expression) to drive the attribute. In this scenario, the only additional capabilities that are assigned to the Group are those you explicitly name in config.

Thoughts?

therealdb

Oh, wow. Is ; universally accepted in code blocks too?

Thanks for considering the request!

toggledbits

@therealdb said in DynamicGroupController and attributes:

I think the correct code snippet is d = false,

The grammar allows semicolon (;) to end a subexpression, so in that context, the two should be interchangeable.

@therealdb said in DynamicGroupController and attributes:

But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic

I understand. Nice. I will look at this in greater depth over the weekend.

therealdb

Hey @toggledbits I'm back to trying to optimize a couple of things based on dynamic group.

First of all, I think I found a typo in the doc:

          primary_attribute: "binary_sensor.state"
          primary_attribute_value: |
            d = false;
            each id in members: d = getEntity(id)?.attributes?.power_switch?.state or d,
            d

I think the correct code snippet is d = false,

All that said, my use case for dynamic groups is to group 3 different climate devices, so I could easily command them at the same time. Commands are good, but sometimes I want to check if any of the devices are on, and that's easily done with a similar snippet as the one you have in the docs. But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic (while all are null in the group). ie, access hvac_control.mode and see if any of the unit is set to cool, or heat. Is that possible, without re-defining an expression in each of my rules? Thanks!

toggledbits

OK. EnvisalinkController won't be of much help there, since Honeywell is all I have to test with (and therefore all it currently supports). If at some point you think you may want to try it, let me know.

toggledbits

Gotta love AI... this thread sent me digging on the unsolved problem, and I just decided to ask Grok why I'm getting arming CIDs but not disarms... on my panel, opening reports are off by default. Thirty seconds in programming mode to enable opening reports and there they are! So now, I have parity... correct user IDs when arming and disarming (using EnvisalinkController).

Maybe check your panel configuration and ensure both arming (closing) and disarming (opening) reports are enabled?

toggledbits

I've written an EnvisalinkController for Reactor that I use, rather than HA's integration, but result is somewhat consistent in that it's unexpected/inconsistent (I'm on an Ademco/Honeywell panel). For me, arming produces the right user ID in a partition CID event and email from EyezOn. But alas, state isn't consistent with EVL3/4, and there does not seem to be a corresponding disarm CID event, and the overall keypad message/status event (which must be used to detect disarming) doesn't seem to report the user slot that disarmed the alarm (nor do I get an email from EyezOn that the alarm was disarmed, which given no CID event, makes sense). A bit different from your results, but frustrating nonetheless.

toggledbits

It's all good! Many, many, many has been the time where an extra pair of eyes helped me. That's why I'm thrilled to have my son working on this project with me now. I'm glad it was something easy (no patch and build needed). Onward!!!

Global Moderators

Posts

Member List