mqtt mapping

[analystcmyk]

I know I currently need an external handler, but I have the following scenario:

I have three devices.

• a device that publishes a value to an MQTT broker to "mydevice/sensor/val"
• an MQTT broker "https://mybroker.com"
• a openHASP device with an object p1b1

Suppose we would have the following file : mqttsubscriptions.json

{ 
[
 "targetobject": "hasp/plate/command/p1b1.val", 
 "sourcetopic": "/mydevice/sensor/val",
 "sourcebroker":"https://mybroker.com"
],
[etc],[etc]
}

This would imply that the openHASP would be subscribed to the sourcetopic on the sourcebroker, and that any change in the sensor value of mydevice would lead to an updated value in p1b1

I would like to run the mapping on openHASP itself instead of adding another dependency that does no more than republishing a subsribed topic to another topic.

Since we already have the full web/mqtt/json stack available, is there a technical impediment to perform such function ?

It would be very nice to have the openHAB act as an independent subscriber to an MQTT topic.

What are your thoughts?

[smcgann99]

Could make a lot of sense, would allow different plates to update from the same published value, rather than republishing the value X times on different topics.

[htvekov]

From a Home Assistant users point of view, I definitely think that a solution should be made to ease configuration of multiple devices with shared pages/object mapping.
Partly to avoid repeated yaml code blocks for numerous devices, but mainly to keep HA load and MQTT chatter to a minimum.

But I'm not sure if this would be the way to proceed. I foresee that maintenance of such subscribe lists easily could become a nightmare in case you have some 200+ shared objects. Currently I'm at 180 objects or so in total, most shared on multiple devices, and I'm not nearly finished yet with the pages I want in production.

Personally I do all(most) shared pages/objects as HA automations utilizing mqtt group topics instead of repeated Custom Component configuration. This method has a few drawbacks, but solves the general issue with repeated code, HA load and unneeded mqtt chatter.

Whether or not local mqtt mapping is within the scope for openHASP is a different matter. I guess only @fvanroie can give an answer on that one with confidence 😉

[smcgann99]

I understand the danger of scope creep, especially as haspmota exists. Although I haven't been able to use it yet as I cannot get my screen working with it. And as I'm new here I don't want to step on anyone's toes ;-)

But a more flexible way of handling MQTT would be a bonus to many. I use Node-Red myself so I can handle the required logic, but a couple of things came to mind today.

There are specific topics for some things like /state/backlight and /state/page but to get button feedback I have to subscribe to /state/#
then filter based on having the key event. I realise it would be a breaking change, but wouldn't it be better to have a dedicated topic for this ?

Related to the OG post, a none breaking change that might be useful would be to add publish to the available commands. So the action could publish something to a specified topic eg Directly switch on a MQTT device without need to go via any external logic.

Just my random thoughts ;-)

[chbarg]

Hello,

I am looking for the same feature or an alternative to make this functionality work.
I would like to have an OpenHASP panel work with a mqtt broker directly, without the need for HA to bounce the information from the broker to the panel.

Regards,