Just posting my opinion having been coding my driver… but it would be REALLY useful (going forward I guess) if the observation array did not change much.
Examples:
Air Temperature on an Air is in array value 2, but on a Tempest it is in 7.
Solar Radiation on a Sky is in 10, but on a Tempest it is in 11.
This means that you need to test for what the device type is and then build your own data off the array for each. If it was a bit more standardized (ex: 2 was ALWAYS Air Temperature and if a device does not support it, it returns null) it would have made it much easier going forward.
Maybe for the next device after Tempest, or any add-on devices, it could at least be based from the array for Tempest, with new fields always added to the end of the array going forward?
The issues I see with that… If Air data is at indexes 1-4 and Sky data is at 5-10… the Sky data message will have 4 null fields… and the Air will have 6 null fields…
Now add 5 more unique-data devices… and append their items to the data stream… the 5th new device will have potentially a lot of null, extraneous fields out there… creating overhead on the data stream…
Yes, but a null does not take up much. Even if it was spelled out as “null” versus just having no value before the next comma, it is only 4 characters. By the time they have increased to 100 null locations they are up to… 400 characters of “waste”.
Considering most other APIs actually spell out what each field is (as does even the WeatherFlow Station Observations) then provide the value… This seems like an odd design decision.
And add in that the Hub needs to do this and that eats up precious memory. This could be done on the Server side in the REST API but I would not want the UDP data changed. It’s simple enough to add an additional process or each new device.
For me the solution going forward is to make more use of the federated Station Observation API end point rather than the Device Observation API endpoint. It makes sense that each device only returns fields that are applicable to itself, but a station observation could return a standard response with nulls in fields that aren’t applicable based on the hardware of each station.
WF mentioned a while back that they were working on this endpoint, but I haven’t heard anything for a while.
Of course the UDP packets would remain specific to each device.