Homie convention and Javascript Object

[Urs-Eppenberger]

Hello

This is a question about the Homie convention and how to put all the data into a Javascript object which follows the Homie convention structure.
The question is further down, for those not interested in the background, just jump one page down.

Background:
With continually adding new devices to my node-red based home monitoring system, I found that my initially defined MQTT topic tree still works. So far so good. Nevertheless I had a close look at the Homie convention, and after some initial struggle started to like it.

Another problem of my initial setup is, that I split up the incoming messages from the sensors into single messages for each measurement type. For the DHT11 devices this means, that two messages are sent into influxdb for the temperature and for the humidity, and Colin on this board strongly advices against that in several threads. So I plan to take this into account too.

My current idea is to take the incoming messages via MQTT from the sensors, and create a Javascript object based on the Homie convention. I receive input messages from various devices in my home monitoring network. Mostly this is measurement or status data, changing over time. These measurement values are properties of a node of a device in Homie terminology. This is done in a function node per device as a first step, later on I might put all fixed data of the device like naming of the nodes and properties in a file or context and load it from there. Clever me wanted to put everything into a msg.homie.{} object, but I failed. This leads to the question below:

End of Background.

Start of Question:
I receive several measurement values from a sensor via MQTT like this:

msg.payload = {"Name":"sonoffth4","Temp":21.7,"Hum":47.1}`

I want to convert this into a Javascript object according the Homie convention like this

msg.homie.sonoffth4.{}

I use the MQTT topic hierarchy as structure of the Javascript object. Up to the node level everything went fine. But on the property level I got a problem. I paste the example of the convention, chapter 7.3.1, this will make it clear (hopefully):

homie/super-car/engine/temperature/$name → "Engine temperature"
homie/super-car/engine/temperature/$unit → "°C"
homie/super-car/engine/temperature/$datatype → "float"
homie/super-car/engine/temperature → "21.5"

Everything is a key-value pair, I know how to handle this. But on the very last line of the convention, the key does not exist, there is just a value posted. With MQTT that is no problem at all. But I was not able to wrap my head around how to code this.

msg.homie.super-car.engine.temperature = {};
msg.homie.super-car.engine.temperature.$name = "Engine temperature";
msg.homie.super-car.engine.temperature.$unit = "°C";
msg.homie.super-car.engine.temperature.$datatype = "float";
msg.homie.super-car.engine.temperature = "21.5";

The last line kills the entries before, as I found out the hard way.
I can fix it like this:

msg.homie.super-car.engine.temperature.$payload = "21.5";

But this breaks the Homie convention with a new attribute which I would like to avoid.

Is there a better way?

[TotallyInformation]

These issues and some others were why I ditched homie in the end, it was simply adding complexity for the sake of it without adding value.

The problem here is that you cannot exactly reproduce the homie data using a JavaScript object, it isn't possible because, as you've shown, you have a left-over value with no property name to attach it to. I'm afraid there is no better way to do it.

[Urs-Eppenberger]

Thanks for your reply. I'm not a programmer so I thought I might have missed something obvious.

I like the Homie convention, since it allows me to keep all the device information in one place, which reduced the overhead of documentation. And since it happens quite often, that the whole thing just runs fine for half a year and then I have a look at it and extend it a bit. This is where node-red excels for me, the documentation is in the code.

If there is no conformant way to use the Homie convention in a Javascript object, then I might as well extend on what I already invented on my own with what I learned in the Homie convention and on this board.

thanks a lot,
Urs.

[TotallyInformation]

That is pretty much what I did too. Ditching the unnecessary complexity though still keeping plenty of detail. For example, I always know and standardise my sensor values (deg C, % relative humidity, LUX, ...) so none of that is needed in MQTT. On the other hand I may keep update timestamps and what updated something. Here is a pretty complex example of a standardised sensor platform data:

Though more recently, I've switched to using ESPhome for all of my sensor platforms and use something like this:

Because all my my newer platforms all use a set of composable includes and so outputs are consistent.

But I also keep convenience topics such as this:

Since these can be much easier if you simply want to get the values of a specific type for a specific location. I also keep another set by location then type.

Also some general info is kept separately:

Not everything gets used but when building out, it can be easier to create the standard topic structures and populate them than going back and working them out later. Your milage may vary