The speedtest integration creates 3 entities.
does the linked automation need to be run on every one of the included entities to get them to update or does running the “update_entity” service call on one of them trigger the integration to update all of them?
Do you happen to know the answer or do I need to ask CentralCommand in the linked thread?
Right now I have the integration running every 4 hours and would like to keep it that way.
Same for me. Supervised install on raspi 4. The logs show tons of warnings about integrations taking a long time to start. Tons of lag. It took forever to bring up the backups page but I was able to restore to 2022.12.7. Everything is fine again…
I assume that is a custom integration. Ask the author on their github.
It should update all 3 in this case.
That being said, that is not a one size fits all answer, each integration handles how it updates entities differently. For example of calling update entity on a template sensor does not cause the template integration update every template entity, just that one is recalculated.
I noticed that too and agree. AQI should be included. There are multiple standards as to how that is defined which will need to be dealt with.
Device integrations aren’t allowed to generate entities from data that doesn’t come directly from the device. In PurpleAir’s case, the API only returns raw particulate values.
That said, there’s a way to get what you want; check out my post here: PurpleAir Air Quality Sensor - #189 by bachya
Thanks for the info.
That definitely seems to make this more complicated. It seems that we need to now dig into each integration source code and figure out how it handles updates?
Or do you know of a better way to know what is needed to be done?
I mean tbh the easiest way is to simply try it. Use dev tools and call update entity on one of them and see if the others update or not.
You can also generally see how integrations work in this regard from history. If a clump of entities from a single integration all change state at the exact same time or not at all in history then their update mechanism is linked. The service is almost certainly making one API call and setting the state of those entities from the response.
But if it is critical that you know exactly what updates when for a particular integration then yes, looking at the source code is most likely the only option right now. The docs are open source with an edit button at the bottom though so feel free to add this info if you think people will find it useful.
I would say as a user you should not be concerned about which entities get updated alongside others. Just use the service call provided and create your own scan interval using the time_pattern trigger. That will literally do the same thing as scan interval, whats nice about this is that you as a user get more control over how often things can update which can indeed vary from user to user. Me for example. I disabled speed test hourly updates and I only update 4 times a day and only when nobody is streaming via plex and downloader is idle, otherwise I dont need it hogging up the bandwidth every hour. To me thats the beauty of this update feature, better control of when updates happen to my own preferences.
@zapp7 @Frederic_ESH @WoolCardigan @NateMathisen
I made a github issue. If you have additional logs or comments. Please share making a comment.
Right but you could already do that the way that it was before.
now instead of just changing a simple entry in an integration configuration option for how often you want it to update you have to completely disable polling on the integration and create an automation to do it even if you literally only want to change how often (based on time only) and there is no other specialized requirements. Along with investigating how the current polling is done (by entity or by integration) so you know what the automation to update things entails.
and if you do have those special requirements then you already had the ability to do that even before the latest update.
The change just seemed to make things harder with no clear benefit.
as far as not being concerned which entities need updated alongside others…
then how will you know which entities to update?
Should we just assume that all of them need forced updates and enter all of the entities into the automation?
That sounds like a horrible misuse of resources.
Me too. I tried a few different things to try and get it to work, but I don’t understand it too well.
Is there a way of clearing the oauth config if we made a mistake?
Not that I’m using any of impacted integrations. But I read similar comments the second time. I can accept yhe new strategy.
I’m just curious why there is default period left built-in. Imo it should be removed too.
IMO this inconsistency adds to confusion and anger.
You can just turn off the built in polling. It’s an option in every integration (that polls)
Because then it wouldn’t run at all.
It would work the same way as current ver of integration with built-in polling disabled
You can’t disable polling with scan_interval. So what you’re saying isn’t correct. Unless you’re referring to something else?
Thanks for creating issue.
I confirm that I have unifi integration, and logs was crazy about it, especially uptime they had an entry every second to indicate a change to the same value as before…