Variables are a very low-level abstraction: it would be nice to have collections of them in 'objects'.
For example, say a weather station has these variables:
Node number: 3
Sensors/variables:
S_BARO: V_PRESSURE, V_FORECAST
S_WIND: V_WIND, V_GUST
S_RAIN: V_RAIN, V_RAINRATE
How about a combined object like this:
{ UID: node-3
is: pressure wind rain sensor
pressure: 1020
forecast: thunderstorm
wind: 8
gust: 13
rain: 3
rainrate: 9
}
It has a UID made here from the Node ID number, although it can be any string uniquely identifying the object. This is an opportunity to use a more globally-unique UID, perhaps including IPv6 address strings.
This would require payload fragmentation to transfer the whole string in something like the above format (JSON-like, but without all the punctuation noise). Or alternatively, some way of constructing and deconstructing objects from the current protocol messages.
A parallel, alternative protocol could be designed - if fragmentation and re-send of missed frags is built in efficiently and reliably, and if the objects are usually pretty small, like the above example, you could take a little hit on efficiency to get the benefit of raising the level of abstraction throughout the system, in terms of both coherent object formats and types and the use of more global UIDs or addresses.
Of course, it's less efficient to transfer the whole object: if only 'wind' changes, you only really need to transfer that variable, not the whole object. Plus string text is bigger than numbers. Plus backwards-compatibility is pretty important.
So, using the present protocol, this object approach would just be 'syntactic sugar' - via a helper API. You'd only see the above format with a special print_object() function, and the API would handle aggregation and the new UID. The downside would be having to deal with two levels of abstraction everywhere.
Cheers!
Duncan
