MQTT Plugin
-
Only if you knew!! ha! Back then it was to integrate other zwave platforms I think... Guess what distracted me...
Now I am looking at getting events from watsor for object detections from my IP cameras. My memory is getting more and more challenged... I have to learn a bit about how mqtt works. I actually had setup a broker way back then. -
I write one by myself (in c#) to use Tasmota, Shelly and similar devices.
I think MQTT is very useful in order to integrate external things.
I like the idea of a full bridge, to send updates from openluup to a broker, and act as a broker. It’s fantastic for near time updates.--
On a mission to automate everything. -
I write one by myself (in c#) to use Tasmota, Shelly and similar devices.
I think MQTT is very useful in order to integrate external things.
I like the idea of a full bridge, to send updates from openluup to a broker, and act as a broker. It’s fantastic for near time updates.I will have a simple sensor plugin ready to share in the next few days I think. It will subscribe to an MQTT topic of your choice and respond to the payload change by tripping/untripping the sensor.
Sending updates from openLuup has existed for quite some time now as the plugin above subscribes and publishes topics generated from openLuup variables. A full bridge should probably do both...
I will be using the pure lua mqtt library on luarocks as it appears to be maintained unlike all the other approaches I looked at. -
I use them a lot for temperature, humidity, luminosity and binary inputs, but I also have one near the pool that’s turning on the lights and provide pool temperature. It was too far for Zwave, but it’s ok for WiFi (I have an outdoor access point anyway). That’s why I started developing my virtual devices, after all.
-
So I am running into a lua problem with creating this plugin:
Threading or the lack thereof. I can probably try to use a co routine but I am seeing that opening an MQTT listener client hangs up openluup as it would just occupy the main thread I guess. How should I spawn a listening thread without blocking openLuup?
-
So I am running into a lua problem with creating this plugin:
Threading or the lack thereof. I can probably try to use a co routine but I am seeing that opening an MQTT listener client hangs up openluup as it would just occupy the main thread I guess. How should I spawn a listening thread without blocking openLuup?
-
Maybe you know, maybe you don't. I use this explore to view real time events and topic updates on my broker:
Very handy to discover topics, see updates etc.
-
Thank you,
It is actually a forked version of the plugin @akbooer shared as well and...
"This plugin provides the ability to publish out any user defined variable to an MQTT Broker."
Which again is not what I am trying to do. I am trying to get a client to subscribe and read messages. Not to publish which involves for the plugin to be constantly connected to the broker and listen.
-
Thank you,
It is actually a forked version of the plugin @akbooer shared as well and...
"This plugin provides the ability to publish out any user defined variable to an MQTT Broker."
Which again is not what I am trying to do. I am trying to get a client to subscribe and read messages. Not to publish which involves for the plugin to be constantly connected to the broker and listen.
@rafale77 It does allow you to subscribe.
You can subscribe to a topic by creating a child device :
Add a new device and choose a type (e.g. "D_BinaryLight1.xml" or "D_TemperatureSensor1.xml").
Reload LUUP engine.
Change the attribut "id_parent" with the id of the MQTT plugin device.
Reload LUUP engine and refresh your browser.
You should see variables "mqttTarget" and "mqttTopic" in your newly created device.
Set the topic you want to subcribe to and the target (format: service,variable=(formula in LUA)).
Reload LUUP engine.
If the payload of the received message is in JSON, the plugin will try to decode it and put it in the variable "payload" in the context of the LUA formula. -
Well I learned something from it. My problem with opening the listening client was not due to cpu threading but because it was blocking the socket. Unless I want to proceed with a polling strategy, this particular library is not going to work... Ohh well, back to square one with a different library.
