Set Reaction > Script Action

[wmarcolin]

@toggledbits

I would like to consult, and maybe even suggest, the possibility that all devices have the common attribute binary_sensor.state.

I am in the process of switching from Vera to Hubitat, and I see huge benefits in Hubitat having very few attributes available to the devices, which makes the device lighter, and faster in my opinion.

But one point that bothers me is for example plug and switch has binary_sensor.state which basically replicates the state of the Tripped Vera.

In Hubitat motion devices don't have it (similar Tripped), the status is motion_sensor.state, in this case my suggestion is if it would be possible that MSR creates in these devices the attribute binary_sensor.state and equals automatically the motion_sensor.state.

Expandindo a solicitacao (asking is not prohibited ) to thermostats for example, I imagine that the hvac_control.mode attribute, other than "off" which means the device is "on (heat, cool)", also has the binary_sensor.state set to "true" (heat, cool) for "on" and "false" for "off".

In summary, regardless of the hub, or type of device a standard attribute to indicate and command the "on" or "off" status, similar to Tripped that has Vera that creates a standard of the devices.

Thanks.

[toggledbits]

I realize that would probably simplify some things for you, but unfortunately, on Hubitat in particular, I don't think it's a good idea.

The problem is that Hubitat device drivers can, much like MSR, pick and choose capabilities that apply to the device, and if we start thinking about "superclassing" MSR capabilities (i.e. the binary_sensor capability is an ever-present abstraction of the more specific door_sensor or motion_sensor), then entities that implement overlapping capabilities will suddenly have a clash.

I have such an example in my network. I have an Aqara Leak Detector, and it implements the Hubitat WaterSensor and PresenceSensor capabilities (I'm not sure why it does the latter, but it does, and we deal with it the way it is). Each of these has a binary equivalent capability in MSR: leak_detector and presence_sensor, respectively). If we abstract those to an additional binary_sensor, we collide, because there can be only one instance of a capability on the device — we can't use binary_sensor twice. So it is not clear, and likely also not deterministic, which of leak_detector and presence_sensor gets to own and set binary_sensor. As it happens, presence_sensor most often wins.

Basically, what you are asking for is the primary attribute, in my view. Unfortunately, another challenge with Hubitat is that we cannot automatically determine what attribute to use as primary, because devices don't really have a type, and they just have a number of capabilities associated with them but none is identified as more important than any other. You can, however, set them manually. It's tedious, though, and I don't recommend it.

This also sounds a bit like an X-Y problem, too: you are asking for a feature to support a solution (Y) you think works for a problem that you haven't stated (X). Maybe take a step back and tell me what you are really trying to accomplish (X).

[wmarcolin]

@toggledbits thanks for the explanation, I confess that I had to read it three times to understand, but I think that in the end, distorting the original attributes is not a good measure.

Well, I will think of ways to use more global variables, the array can help a lot and with the last functions, you added I will certainly get this hub standardization. Thanks!

[toggledbits]

By the way, I think I've mentioned this before, but I have a model for dynamic groups that I haven't yet implemented. The recent work on MQTT and Hass events has moved that forward somewhat, at least in concept. This may address a big part of your ultimate need (still not really stated?). It will be a good bit more efficient than matchEntities(), and a lot more flexible.

[wmarcolin]

@toggledbits WWW

waiting waiting waiting

Lord, inspiration and patience to Patrick, you are in my prayers