You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the integration looks for last_seen or last_timestamp. But there may be entities that provide the same information in an attribute with a different name. Rather than having to update the integration to support those entities, add an option that allows the user to specify the name of the attribute.
Another option might be (in addition to, or instead of, the above option) to allow the user to specify a template for extracting the information. This would serve the same purpose as the above, but would also allow the data to be converted in case it is in an unsupported format, or is wrong in some way but can be "fixed".
The template option does have potential downsides...
First, the core team seems to want any data added to an existing integration to go into a separate sensor entity (no matter how much it should be an attribute. See comment from core PR for GPSLogger that wasn't accepted.) Since such an entity would update independently of the composite's input entity, there would be no way to guarantee it would have the correct value when the input entity updates and the composite integration processes that update.
Along the same lines, using any other entities would have the same problem; i.e., every entity updates independently, each creating their own state_changed event, and there's no way to know when all relevant entities are "done" updating. If the user is not careful, the resulting composite entity could have short-lived incorrect states as all the entities referenced in the template update.
The text was updated successfully, but these errors were encountered:
For UI configuration, first check if input entity already has a last_seen or last_timestamp attribute, and if it is in one of the supported formats. If so, either just skip step for specifying the attribute, or display which attribute would be used and give option to go with that, or to override with a different attribute.
If last_seen & last_timestamp don't exist, check other attributes for ones with datetime info in a supported format. If there's only one, maybe offer to use that, but still provide option to ignore or override. If there's more than one, then provide a list of potential attributes, with an option to pick one, specify another, or go without.
Currently the integration looks for last_seen or last_timestamp. But there may be entities that provide the same information in an attribute with a different name. Rather than having to update the integration to support those entities, add an option that allows the user to specify the name of the attribute.
Another option might be (in addition to, or instead of, the above option) to allow the user to specify a template for extracting the information. This would serve the same purpose as the above, but would also allow the data to be converted in case it is in an unsupported format, or is wrong in some way but can be "fixed".
The template option does have potential downsides...
First, the core team seems to want any data added to an existing integration to go into a separate sensor entity (no matter how much it should be an attribute. See comment from core PR for GPSLogger that wasn't accepted.) Since such an entity would update independently of the composite's input entity, there would be no way to guarantee it would have the correct value when the input entity updates and the composite integration processes that update.
Along the same lines, using any other entities would have the same problem; i.e., every entity updates independently, each creating their own state_changed event, and there's no way to know when all relevant entities are "done" updating. If the user is not careful, the resulting composite entity could have short-lived incorrect states as all the entities referenced in the template update.
The text was updated successfully, but these errors were encountered: