Hi Michael,
I've been very happy with the mcsMQTT plugin, not to mention fairly impressed with the amount of time you're putting into its development.
One of the things that I would like to see is greater control over the auto-generated topic names, as well as even the payloads, themselves. While I understand that I can manually define things such as the topic names, I've got close to 240 devices in HS, so tweaking everything becomes tedious.
Here are my ideas:
Option to prefer the usage of forward-slashes for device topic separators, rather than vertical pipes.
The usage of vertical pipes for device name separators hinder MQTT subscribers from leveraging my broker's ability to filter messages for them.
I'd really like to have the general option within mcsMQTT to specify that auto-generated topic names use forward-slashes (/) for device name separators, rather than vertical pipes.
For example, I have a nightstand light, and the mcsMQTT generated topic name is "homeseer/mcsMQTT/Master_Bedroom|Lighting|Nightstand_Light".
However, if the topic name were "homeseer/mcsMQTT/Master_Bedroom/Lighting/Nightstand_Light", a subscriber could filter for all Master Bedroom lights with "homeseer/mcsMQTT/Master_Bedroom/Lighting/+", or even all lights in my home with "homeseer/mcsMQTT/+/Lighting/+". I cannot do the same thing when vertical pipes are used in the topics.
Here's an area to the section of the MQTT specification regarding topic separators: http://docs.oasis-open.org/mqtt/mqtt...#_Toc398718106
Template-string control over generated topic names
While I've got your ear, I'll throw another idea at you: it'd be neat if we had the ability to define a template string (or something similar) that would provide control over the structure of the topic name.
Imagine, if you will, I were to define a hypothetical template string like "status/${location1}/${location2}/${type}/${name}", the generated topic name for my nightstand light would be "status/Master_Bedroom/Lighting/Insteon/Nightstand_Light".
You could have a whole slew of replacement tokens for a template, if you wanted:
Template-string control over payloads
Basically an extension of my previous idea, but control over the payload string, which would mean easier interoperation with other systems in my MQTT ecosystem.
It'd be pretty neat if I could define a payload template like:
I've been very happy with the mcsMQTT plugin, not to mention fairly impressed with the amount of time you're putting into its development.
One of the things that I would like to see is greater control over the auto-generated topic names, as well as even the payloads, themselves. While I understand that I can manually define things such as the topic names, I've got close to 240 devices in HS, so tweaking everything becomes tedious.
Here are my ideas:
Option to prefer the usage of forward-slashes for device topic separators, rather than vertical pipes.
The usage of vertical pipes for device name separators hinder MQTT subscribers from leveraging my broker's ability to filter messages for them.
I'd really like to have the general option within mcsMQTT to specify that auto-generated topic names use forward-slashes (/) for device name separators, rather than vertical pipes.
For example, I have a nightstand light, and the mcsMQTT generated topic name is "homeseer/mcsMQTT/Master_Bedroom|Lighting|Nightstand_Light".
However, if the topic name were "homeseer/mcsMQTT/Master_Bedroom/Lighting/Nightstand_Light", a subscriber could filter for all Master Bedroom lights with "homeseer/mcsMQTT/Master_Bedroom/Lighting/+", or even all lights in my home with "homeseer/mcsMQTT/+/Lighting/+". I cannot do the same thing when vertical pipes are used in the topics.
Here's an area to the section of the MQTT specification regarding topic separators: http://docs.oasis-open.org/mqtt/mqtt...#_Toc398718106
Template-string control over generated topic names
While I've got your ear, I'll throw another idea at you: it'd be neat if we had the ability to define a template string (or something similar) that would provide control over the structure of the topic name.
Imagine, if you will, I were to define a hypothetical template string like "status/${location1}/${location2}/${type}/${name}", the generated topic name for my nightstand light would be "status/Master_Bedroom/Lighting/Insteon/Nightstand_Light".
You could have a whole slew of replacement tokens for a template, if you wanted:
- location1
- location2
- type - device type
- name
- value - the current (or just set) value of the device
- value_string - the string-mapped value. ex: "ON", "OFF", etc
- previous_value - the previous value
- previous_value_string - the previous string-mapped value
- address - Device address
Template-string control over payloads
Basically an extension of my previous idea, but control over the payload string, which would mean easier interoperation with other systems in my MQTT ecosystem.
It'd be pretty neat if I could define a payload template like:
Code:
{ "room":"${location1}", "device":"${name}", "new_value":"${value}", "old_value":"${previous_value}" }
Comment