I have a solar system that publishes updates every ten seconds. Internally, it uses DataUpdateCoordinator and updates the state of a bunch of sensors in a ‘batch’.
I’d like to publish this state to MQTT for another device to read.
Is there a way to trigger an automation after the platform update, rather than individually on each sensor change? I don’t want to send a bunch of updates to MQTT, one for each sensor, I just want to update it once but be sure to have all the latest sensor values.
I’m not aware of any way to plug into that HASS-internal construct to get that information.
Do you typically see the sensors all update very quickly so that there’s kind of a burst of updates approximately every 10 seconds? If so, an imperfect but probably workable solution, is to trigger on state changes for ONE of them with a for of, say, 4 seconds, and assume that with the passage of 4 seconds all of the sensors have now received the update. And then send your MQTT message with the state of all the sensors.
It’s not perfect because if your system hits some kind of laggy moment, maybe all the sensor values don’t propagate through in time. Might more more of a theoretical than an actual concern. But unless something will catch fire if an MQTT update gets sent with data that doesn’t all come from the same update, it’ll probably do the trick.
EDIT: A few more ideas. The idea above, I think, has the problem that if the sensor you pick as your trigger receives the same value it had before, the state trigger won’t fire. Perhaps there is a sensor that always changes.
Another possibility: just use a time_pattern trigger to fire the automation every 10 seconds and build the MQTT message. Might be slightly more likely to fire “in the middle” of an update, though, again, this might be more theoretical than actual as far as concerns go.
Still another one: use a mode: restart automation that fires on a state change to any of the sensors, and at the start of the automation, use a delay of 4 seconds or so. Assuming the behavior I asked about above, once the last sensor in a given update has been updated, the 4-second wait will succeed and then you’re in theory seeing the latest states of all the sensors to build the MQTT message.
Hello Jamie Montgomerie,
Gathering on
So trigger on that one that almost always changes and add a delay giving the whole stack enough time to update within the 10 second window, then they all should be updated.
Personally I would make sure you actually need the 10 second frequency reporting here, that the data is useful that fast. It’s a lot of data and if you are not going to use all that don’t clog your database up with all that. limit the data retrieval to a useful frequency.
Another idea…
You could also add triggers for all the values, and trigger the automation on a significant change to a value that does require action is another way. Adding a timed trigger along with that to collect state for history every couple of minutes when there are not significant change rounds that out.