MySensors MQTT 'dialect' optionally Homie

[Peter Loeffler]

are there any plans/thoughts of implementing an optionall mqtt-transport that follows Homie-conventions?

activateable by (eg) #MY_GATEWAY_MQTT_HOMIE

[tbowmo]

In my opinion it's not feasible to do this on memory constrained devices, we should keep the topic structure as simple as possible. If we implement the homie-conventions we need to keep all the sensor names etc as string values in the code, in order to create a proper topic.

As an alternative, you could use nodered to transform topics to another format. I'm doing that in my setup, so I have the following topic structure:

house/<room>/<device>/<sensor>

to set a value to a device I have the same topic as above, with /set appended.

[Peter Loeffler]

@tbowmo that would consume memory on the gateway, thats right, but that does not hurt, does it?
waiting for a working binding (eg. for OH3) or even writing something like a "binding" is - in my opinion- too much energy and, after several changes on the controller, not so extra sufficiant threads here I am almost as far as to recode all my (abt 120 sensors) to get rid of the need of a "binding".

my main point is NOT a "beautiful" mqtt-topic-space. its all about userfriendlyness.

[tbowmo]

@Peter-Loeffler

The mqtt / serial protocol adhere very closely to the OTA protocol, where we are using byte sized nodeIds. This keeps the overall transmission payload down, and limits the time needed for transmitting a sensor value, and also keeps the likelyhood of errors down (Larger payloads = larger chance of failure). And currently chosen radios have a limited payload length

If we should implement the homie-convention (see below for an example) we need to be able to tell the gateway that nodeId 10 is device123, and childSensorId 1 is myThermostat. Then the gateway needs to store that info somewhere in a lookup table, to be able to do the conversion on the fly, as it's not feasible to send that info over the air for each transmission.

Also, we support the use of the same sketch on multiple devices with the current nodeId assignment. IE when you have 10 temperature sensors that all use the same sketch. The nodes get a nodeId from the controller, that it stored in eeprom, and re-used. Even if you re-program the device.

Homie-convention examples:

  homie / device123 / $homie → 3.0
  homie / device123 / $name → My device
  homie / device123 / $state → ready
  homie / device123 / $nodes → mythermostat

  homie / device123 / mythermostat / $name → My thermostat
  homie / device123 / mythermostat / $properties → temperature

  homie / device123 / mythermostat / temperature → 22 
  homie / device123 / mythermostat / temperature / $name → Temperature
  homie / device123 / mythermostat / temperature / $unit → °C
  homie / device123 / mythermostat / temperature / $datatype → integer
  homie / device123 / mythermostat / temperature / $settable → true

[Peter Loeffler]

@tbowmo payload-length does not have anything to do with the node and the transport node-gateway, right?! we talk about gateway-mqtt and no other transport. and mqtt would even accept data of (at leaste) one jpg-image in ONE payload...

the same sketch on multiple devices (include the same mqtt-topics) sounds good, but will def. not work with eg. OpenHAB or MyController or whatever, because of the topic, and the fact, that nothing BEHIND the topic would make that node/sensor unique - i mean: there are enough ways to make a node unique...

the main "problem" is the need of a "binding" , the need of coding such a binding, the need of updateing that binding.....thats a lot of work to be done. and implementing a standard (and I call homie-convention a standard) will def. less work to do

[monte]

@Peter-Loeffler just use HA

[tbowmo]

@Peter-Loeffler

You still need to tell the gateway "This node is 'living-room' and it transmit 'some-odd-property'" This needs to be configured somewhere, that be the node itself (and transmitted over the air/wire), or the gateway (or a computer running some software).

The current iteration of mysensors let the gateway run on an UNO. So that is the lowest common part that the gateway firmware needs to be compatible with (at the moment), and that mcu is too small in supporting the above schemes. Let alone, have all in the different sensor types programmed as text strings.

It might be doable in some future version, that is only in the talks (We've had some brainstorming on v3 of the protocol a couple of times).

[Peter Loeffler]

@tbowmo
uno runs maybe as serial ateway, but uno+ethshield+mqtt is not stable enough for a "productional"-environment. so the limitation is not UNO. some derivates with esp32/8266 will present enough horsepower to do that

finally: thank you for some openness ... we see where this leads to
there are some other project playing the converter/translator -role in the middle, but thats not so really cool, hence there needs to be node running...

[tbowmo]

@Peter-Loeffler
I still see this as a "controller" part, as it's mqtt you are totally free to subscribe to the messages from the gateway, transform it to something else, and then publish that onto mqtt as well.

That's the way I would do it, as it's much easier to edit config files etc on a computer (rpi etc).

[Peter Loeffler]

@tbowmo
what? it's a controller-part to decide which MQTT-dialect the gateway talks?

thanks for the words, now I know I am again treated as a fool

[tbowmo]

Perhaps my definition about "controller", is a bit broad here.

What could be done, is to have a thin "controller", that receives MQTT from the existing gateway, hands out IDs if they are requested from a new node, and translate the message into homie compliant topics. That is all it has to do, should not care about the rest of the automation at all. Should also be able to translate back from homie compliant to mysensors.

This could be written in python, c#, javascript, rust etc. The benefit is that you have (relatively) easy editing of configurations at hands, without re-uploading sketches to your gateways / nodes, if you decide that node X should be named Y instead.

And I am in no way trying to treat anyone as a fool!