Does Losant have a recommended strategy for State vs Topic updates? I’m trying to decide how or if I should break my program up into State vs Generic MQTT transmits and don’t find a lot of guidance on how large a State update should be versus how much should be implemented in generic MQTT topics. I have a large device reading several pressures, gps data, cell phone statuses, battery states, etc. There are a lot of moving variables. Should I just put them all into one big flat State json wad or would it be better to break some out into MQTT topics with workflows to update the variables?
Your examples all have just a small number of State variables - I have probably 25 or so.
Jason
Hi
We update 25-30 properties every 3 seconds on 40+ devices on one project. This works well and is simple.
Originally I was only updating the state of those properties when it changed or every 30 seconds.
However it made the time series graphs look odd, so went back to updating all properties regardess every 3 seconds.
You only have a single state topic per device. Really the other question is are the multiple logical devices. For instance 3 pumps each with a pressure sensor. If so then that would be 3 seperate devices.
Just my 2c worth
Cheers
T
Generally we’d recommend just putting them all on a single state payload. That’s likely the easiest to architect and develop with from your perspective. There are customers with hundreds of attributes all being reported at once, so your use case is right in line with what we’d expect.
There is a big difference between the state topic and arbitrary topics when it comes to Losant handling your data. Anything published to a state topic will automatically be stored in our time series database. Anything published to custom topics will be lost unless you trigger a workflow to handle it.
If your data requires conversions or you’d like to filter it before recording it, publishing to custom topics is an excellent way to do that. The workflow can perform the conversion or filter and then use a Device State node to record the result.