search

tbowmo / node-red-contrib-mysensors

Mysensor nodes for node-red
23 stars 9 forks source link

[Feature request] Node for converting a mysensors MQTT topic to "human readable" format #20

Open fallberg opened 5 years ago

fallberg commented 5 years ago

As the myscontroller can be populated with information about what nodes exists in the system, the name of the sketch the node executes, the type of sensors the node contain, it is at least theoretically possible to have a node that can convert the MQTT topic into a more human readable form so that it is easier to set up MQTT flows based on mysensors inputs. At least for nodes that are registered in the sqlite database.

tbowmo commented 5 years ago

Just a design idea..

output could be something like the following: root-topic/<sketchname.tolower()>/childId//<ack/nack>/

The parts noted in <> should be human readable decoded text from the IDs. If we keep the above layout, it could be trivial to do the reverse decoding as well..

Only issue is that sketchname might not be unique on the mysensors network. This could be fixed by appending nodeid to the sketchname, and/or make a method for manually labeling nodes (in database).

Depending on traffic through the node, a memory based lookup list should probably be used, instead of doing SQL lookups on each and every message that is received.

It can be argued if ack/nack should be dropped..

fallberg commented 5 years ago

Looks good. Perhaps also encode the type for the sensor value in the payload in case it is a set/get command? So, as a consequence, also include the command in the topic. Example: root-topic/<sketchname.tolower()>/childId/// for == set or req root-topic/<sketchname.tolower()>/childId/// for == presentation root-topic/<sketchname.tolower()>/childId/// for == internal

tbowmo commented 5 years ago

Giving this a bit more thought..

Currently there is a node for decoding from mqtt, and a node encoding to mqtt.. If we do this with the current set of nodes, we have to first convert incomming mqtt messages, and then convert them back into mqtt and then re-emit them on the mqtt broker. And have the same mechanism when we have to send it back to the mysensors network.

Or, we could create a new node that transforms between mysensors numeric ID's to human readable names, and back again.

Also, what happens if the node receive a message that it cannot interpret, because of a spelling mistake in the node name, and we want that message to be emitted on the mysensors network? Should it throw a warning / exception to the node log?

fallberg commented 5 years ago

Hm, valid point. Perhaps a new node would be the cleanest and most backwards compatible friendly option?