Make command MQTT topic independent from controller or add generic MQTT 'controller'

[giddyhup]

NOTE: This is not a support forum! For questions and support go here: https://www.letscontrolit.com/forum/viewforum.php?f=1

Steps to reproduce

How can we trigger this problem?

Even though the documentation is generic the way commands are accepted via MQTT seems to be specific to the respectively selected first controller protocol. (Discussed and discovered here.)

Does the problem persist after powering off and on? (just resetting isnt enough sometimes)

Yes.

Expected behavior

Tell us what should happen?

The documentation states regarding submission of commands via MQTT: "send the <command> to topic <MQTT subscribe template>/cmd".

Actual behavior

Tell us what happens instead?

I have PiDome MQTT selected, the Controller Subscribe topic is modified to be "home/%sysname%/#" . When I send a command payload to "home/foobar/cmd" nothing happens (system name is set to foobar).

Suggested solution approach

Change the way commands are accepted via MQTT so that it is always the same, independently from the activated controller, or, if the first suggestion breaks things, add a generic MQTT controller setting that complies with the documentation. Should you decide to do the latter I suggest adding also user name and password fields like in OpenHAB MQTT.

[JK-de]

My suggestion for imlementation:

• Implement in controller.ino - don't send to controller if it is a valid and handled command
• If the topic ends with "/<systemname>/cmd" it is a command message and the payload is handled as command with all commas, spaces...
• add a checkbox in advanced page to enable commands via MQTT (security)
• a controller plugin can additionally handle own command syntax like PiDome-MQTT

[Grovkillen]

Would be great if this also could make MQTT Import somewhat obsolete in future releases. I mean that if we could send .../cmd and trigger events in rules we wouldn't need MQTT Import for other than true float values (as it was first intended). I use MQTT Import to trigger some rules but need to have float values (I use integers) to trigger. But as we all know numbers are not words and /cmd with payload OpenGarageDoor is alot easier to remember than payload 1.

But one thing that is really great with MQTT Import is that I can mass trigger all my nodes since I can tell them all to listen to generic topic (for example) cmdMQTT and that would be cool if future enhancement would also allow the cmd to be sent to ALL or a GROUP of units. Just my thoughts on the subject.

[JK-de]

As addition:

• If the topic ends with "/all/cmd" it is a command message and the payload is handled as command with all commas, spaces...

It can als implemented:

• If the topic ends with "/<systemname>/event" it is a event message and the payload is handled as... ???
• If the topic ends with "/all/event" ...

Before implementing we need a concept!

[Grovkillen]

I agree with your suggestion but maybe we need to handle it like this:

Unique Unit

• If the topic ends with "/<systemname>/cmd" it is a command message and the payload is handled as command with all commas, spaces...
  A variant of this would be the use of: "/<systemname>/cmd" with payload "event,<eventname>" is an event message...

All Units

• If the topic ends with "/all/cmd" it is a command message and the payload is handled as command with all commas, spaces...
  A variant of this would be the use of: "/all/cmd" with payload "event,<eventname>" is an event message to ALL...

Group of Units

• If the topic ends with "/all/<integer>/cmd" it is a command message and the payload is handled as command with all commas, spaces...
  A variant of this would be the use of: "/all/<integer>/cmd" with payload "event,<eventname>" is an event message to ALL within the group ...
  The "<integer>" would be an group number. And units part of that group would act on the cmd simultaneously.
  Group settings, if it is possible multiple groups should be allowed.

[JK-de]

May repalace "/all/<integer>/cmd" "/group/<integer>/cmd"

and replace "<integer>" with a single character or a string. Setting would be "Unit is in Groups [ABXY]" or "Unit is in Groups [Lorem,Ipsum,Dolor,Sit,Amet]"

[Grovkillen]

Great suggestion @jkDesignDE

[Grovkillen]

I like this one;

"Unit is in Groups [Lorem,Ipsum,Dolor,Sit,Amet]"

[giddyhup]

I like the ongoing discussion. We must remember though, that we are operating in the topic name space and this should be documented so that if somebody decides to use reserved words for other reasons they know that they may run into conflicts. I think the checkbox suggested by @jkDesignDE is a good idea (if it is not overkill).

[JK-de]

I was to fast! To reduce MQTT-subscriptions and MQTT-traffic we should switch topic order and define (settings) a MQTT-command-prefix like "/aaa/bbb/cmd/" followed by:

• /<systemname> -> the payload is handled...
• /<group-name> -> the payload...
• /all -> the...

@giddyhup Some checkboxes and some if's in code is very easy - it's more work to define the checkboxes and what they should do

[Grovkillen]

Yes that is more to the point.

[papperone]

maybe a stupid idea (and slightly OT!) but on MQTT controller I'd like to be able to enable module to publish automatically specific topics:

/<systemname>/IP
/<systemname>/ModuleName
/<systemname>/Version
/<systemname>/MacAddress
/<systemname>/Uptime
/<systemname>/SysTime
/<systemname>/WiFiSignal
/<systemname>/WiFiSSID

as well could be nice to be able to activate a "pulse" topic (/%systemname%/Pulse) which is toggling between 1 and 0 every "n" seconds (useful to monitor remote nodes if still alive or not and/or as input for an hardware watchdog for example, or simply to have a screen on the GUI with Nodes list/statuses/etc)

[psy0rz]

also we should do this post 2.0.0 i think?

[Grovkillen]

Yes this is a 2.1.0 milestone I think.

[papperone]

Yes agree, it is not a simple update which requires enough time to analyze and make it the best with widest usage possible; thinking more on it I'd like as well the possibility to have "global" topic that can handle a bulk change on all modules at one time:

1. DST flag (with 20 modules you can't imagine how annoying task is!!!)
2. OTA (I know that will be not an easy one but I'd love to be able to send a message to all my "stable nodes" and update them to the newer firmware)
3. Reboot (could be useful that a reboot is performed an all units, kind of "master reset")
   etc...

PS: is there a place where all the post 2.0.0 milestone new/updated features are keep recorded? I think it woudl be great to have better visibility on them...