Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fallberg opened this issue May 2, 2019 · 4 comments

Comments

@fallberg
Copy link
Contributor

fallberg commented May 2, 2019

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
Copy link
Owner

tbowmo commented May 3, 2019

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
Copy link
Contributor Author

fallberg commented May 7, 2019

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/<command_t>/<v_type>/ for <command_t> == set or req
root-topic/<sketchname.tolower()>/childId/<command_t>/<s_type>/ for <command_t> == presentation
root-topic/<sketchname.tolower()>/childId/<command_t>/<i_type>/ for <command_t> == internal

@tbowmo
Copy link
Owner

tbowmo commented May 16, 2019

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants