I wrote a home dashboard that displays some home-related information (a consolidated calendar from the family Google calendars, the time children go and come back from school, weather, …). The general architecture is
a backend service that fetches the data from the providers
the data is then sent to a MQTT bus
the dashboard (JavaScript) is subscribed to the MQTT topics and displays information as they come
Since I have a HA installation that already manages states for devices, I was considering switching the source from MQTT to HA and having the frontend connect via websockets to react to state changes.
The state would be set via my backend service (instead of sending to MQTT).
Do you think this is a good/reasonable/brilliant idea? Any possible drawbacks you anticipate?
tbh I cannot see in your description the state machine you mentioned in the subject
HA has to materialize those states somewhere, otherwise you loose them when restarting HA.It will lose also results of automations (suppose this is the “state machine”) unless it’s materialized somehow.
The best you can do imo is to connect HA to your mqtt, this way allow it to make use of data stored by your service.
But if it would be enough for your needs (I’m still in doubt about them) then maybe NodeRed alone would be even better.
Sorry for being unclear @maxym . An example would be best I guess.
From within a backend service (a standalone one, that runs in its own docker container - so nothing to do with HA or MQTT so far), I get the temperature outside by gathering readings from surrounding weather stations. After some calculations, I get a temperature, say 13°C.
I then push this value to a MQTT topic (say outside/temp).
I also have a dashboard written in JS/Vue/Quasar that displays (among others) this temperature. It does so by subscribing to outside/temp, and displaying whatever is sent there.
All of this works great but I would now to use HA as the place these 13°C are stored.
I would create an entity in HA holding the temperature (say dash.temp), sending it from my backend service the current readings, and having the frontend retrieve changes to dash.temp through a websockets connection.
I am interested in the pros and cons (especially the cons) of such a solution.
So at first you have already the value stored. There is no need to store it somewhere else just for sake of using another storage
Second: HA alone doesn’t provide storage feature (there are some exceptions but not applicable here). It works in memory. Once restarted you lose all values until you send another data. Yes, it has history. But after restart, all values are considered unknown since the system cannot assume that sensed values didn’t change during an outage).
MQTT provides materialized storage. I wouldn’t change it in favour of HA alone for that matter.
Third: to get data to HA you need so called integration. You can write your own. You can talk with HA API. But still you need some interfacing. You can also use existing MQTT and create sensors in HA based on data in your MQTT - it makes the question: is it the thing you need? do you need to get values to HA, or you are looking for another way of storing data instead of using MQTT?
If the second: HA alone is not a tool dedicated for that.
If the first, for example to create some automations based on that, HA might be the way, especially if you have plans to extend your system with devices HA can integrate easily.
I thought that HA itself would store values but if it relies on something else to initialize them (MQTT and the topics it is subscribed to for instance) then the idea of “sending data to HA” does not make sense in the first place (in the context of my understanding, with HA being the data store).