homieiot / convention

🏡 The Homie Convention: a lightweight MQTT convention for the IoT
https://homieiot.github.io/
Other
715 stars 60 forks source link

Array properties or not to array properties #180

Closed David-E-Thomas closed 4 years ago

David-E-Thomas commented 5 years ago

I'm creating a Water Monitoring station using an ESP32 and I'd like to use the Homie convention.

The station has four sensors - temp, humidity, water tank level, and a flow meter - that I'm linking into OpenHab.

The first four are straight forward to set up in homie, but I'm having trouble thinking through how to set up the flow meter.

The flow meter reads instantaneous water flow and produces L/min. This would create a flood (pun intended) of messages on MQTT which need to be dealt with in OpenHab. Rather than have Openhab collate the data over time (creating hourly, weekly, monthly usage), I'm thinking that I'll get the ESP32 to store the data in non-volatile storage and return it on request as a set of measurements - Liters used in last hour, day, week, month.

Homie doesn't support arrays, so I'm assuming I'll use a String Datatype. I'll need to have dates/time durations associated with each measurement value, which is a lot of stuff to parse together.

Any ideas on how to simplify this?

bertmelis commented 5 years ago

Create an array in json and send the json string?

davidgraeff commented 5 years ago

I'd second this. Homie tries to harmonize mqtt topics, and specifies some basic datatypes. But you are basically asking for a complex type (an association of int->int with timestamp->measurement). That's best done with a custom format, json, yaml, toml, bson, messagepack etc.

In OH you'd need a script to parse that structured data. Btw an OH channel can have binary data (bson, messagepack etc) json is probably easier to parse though, because the GSon Java library is already part of OH.

kollokollo commented 4 years ago

Why not simply send out a string with many numbers, separated by a blank? This forms an array a[n] of n integers or floats, all would have the same unit, same type. In case of a history of e.g. temperatures the most recent value should be on the left side. So any client not capable of processing arrays will at least see the most recent value and ignore any other part after the first blank.

Of course, this way more complicated data structures cannot be realized (e.g. (x,y) corrdinates or (x,time) values. If you need this, I would agree to use JSON.

But thinking in terms of the ancient programming languages (BASIC, FORTRAN) one can make separate simple arrays for the X[n] and Y[n] and TIME[n] data. One needs to make sure, that "n" is the same in all cases and maybe one wants to add a Timestamp (T1580396855.826) as the last value (see another proposal), to make sure the data corresponds to each other. This is not very elegant, but avoids a complex parser. (not all Microcontrolles have space for this).

mjcumming commented 4 years ago

I am closing this. If the OP still has questions, we can reopen.