fermuch
commented
6 years ago I really like the idea of setting the intervals from the controller to the device, so the controller can ask for more data if it's necessary.
Example:
Normally, you only want to read the temperature of a room every minute or so. But if some sensor detects smoke, you'd like to switch the temperature sensors to a higher frequency, so you can detect where the fire is propagating. You could do this filtering on the server side, but if it's running over GPRS it's way better to ask more only when needed.
I do something similar to this with broadcasts. If there's a "critical" broadcast, all sensors switch to critical mode, sending as much data as they can, and when things go back to normal I fire a "normal" broadcast.
ingoogni
bertmelis
timpur
nicola-lunghi
davidgraeff
In the past days, working with the Homie Convention, I on occasions thought, this [...] is missing, on deeper though it was not. But, there is always a but, I now ran into an "omission" that I think would be a useful addition to the convention:
homie / device ID / node ID / property / property attribute
EDIT: as intervals do not have to be seconds but can also be other units as meters or °C another property attribute may be needed: $intervalunit (see in discussion below)
Property attribute: $interval is an attribute of a property, not a property of a node (although a node could have). It tells us something about the data being published. My CO2 sensor measures every 5 seconds, I have the data published ever 10 seconds and a min, avg, max every 5 minutes.
Some use cases:
Monitoring; A client can be written that monitors the timely arrival of data packets and responds to the situation.
Time series; Even if it would be easy to add time stamps to data it is a bit clumsy to write time series to a database row by row by time stamp. Easier is it to write only a start and or end time and write the data to an array in the DB, that though needs a regular and known interval for the data. A published $interval is this and makes it possible to for a client to note missed packets and write null data in such an array. A round robin database can use $interval for setting the 'heartbeat'. A series Timestamps itself will not tell us whether they come in at the set or required interval.
State changes; During a process the state of a sensor can change and with it its publishing frequency. With a (re-)published interval clients can adapt.
Stale Data; As all messages are published retained a newly active client can determine by use of the $interval whether the first dataset received by the broker is stale and discard it in that case.