-
Notifications
You must be signed in to change notification settings - Fork 294
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
[enhancement] Allow MQTT topic rewriting #981
Comments
Ok, will check that first. |
Ok yes this is working fine.
|
btw, it seems you are doing something very interesting. Please consider writing a tutorial/;article about it for our forum, we can send you a set of Elektroda gadgets for that |
Well before that ( I am using the https://www.openhasp.com/0.7.0/hardware/sunton/esp32-2432s028/#esp32-3248s035 ) module I would like to elaborate a bit the back route from LCD module to OpenBEKEN. Having OpenHASP to monitor/control OpenBEKEN is not a bad option. Just a dumb broker is needed to do all, no Node-RED or other dependencies. These modules have an ESP32 so they could even run a micro MQTT server next to it. ( looking at https://github.com/tuanpmt/esp_mqtt ) To be honest I would like be able to communicate touch events to openBeken directly, but since I have limited control on what topic openHASP is publishing, you could think of a flexible way to have OpenBEKEN actually subscribe to a user defined topic. Maybe keep the (non-existing) command So instead of getting the commands from
Of course that is not an easy thing to do, and it would need to honour the Monitoring multiple OBK on a single OpenHASP already works fine. Sample buttonA sample of an OpenHASP toggle button ( page Channel : So getting that would involve parsing the JSON as well... |
So it would send that JSON to obk? No problem, I can make a custom driver for that |
A bit like this and with the
meaning:
I think the "keep original" flag is not needed anymore and the currentTopic should always be available. Remarks I think mqttTopicClone is a better name, and it would mean that we may also use it for cloning mqtt publish behaviour, eg
meaning:
In this way it would work transparently in both directions: Parse when receiving, Wrap when publishing |
You run usually MQTT server on home automation server. I don't know what home automation you are using, but it is always possible when receive a mqtt message in one topic just to change what you want (if necessary) and publish the message into another topic. |
Ok, then maybe we could consider this : (in analogy of
In this way we would use existing functions where possible and only Things to consider:
Thinking about that, you might also choose to expand the |
I want to use OpenHASP https://www.openhasp.com/0.7.0/ to display sensor values published by OpenBEKEN to MQTT.
OpenHASP allows the values of screen objects to be set via MQTT.
For example : by publishing
25
tohasp/plate/command/p0b5.val
you update the displayed value of that object.Issue :
OpenBEKEN publishes to a fixed topic, eg
/device/power/get
I cannot instruct OpenBEKEN to publish the sensor value to
hasp/plate/command/p0b5.val
Suggested :
Add command to rewrite the MQTT topic just before publishing, e.g.
mqttTopicRewrite currentTopic newTopic [keep]
mqttTopicRewrite /device/power/get hasp/plate/command/p0b5.val
The optional
keep
flag is to publish also to thecurrentTopic
Alternative :
use
addEventHandler OnChannelChange 1
Related issue : HASwitchPlate/openHASP#577
Restrictions :
newTopic
as acurrentTopic
The text was updated successfully, but these errors were encountered: