openweather plugin ?

[rafale77]

Well.. this plugin only serves to subscribe vera variables and post them into an mqtt broker. It does not get the messages from it and report them into openLuup. It is the opposite of what I am trying to do...

[akbooer]

Ah well, it’s good, at least, to know what is out there, and whether or not it fits your needs. (Not, in this case.)

[rafale77]

Indeed it could have been good base for a new plugin though but I am leaning towards starting from scratch. The code is quite aged...

[rafale77]

making progress

[therealdb]

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.

[rafale77]

@therealdb

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.

[therealdb]

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.

[rafale77]

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?

[kfxo]

@rafale77 Have you seen this mqtt plugin? i have been using it to subscribe to topics for some time. Maybe it has some hints as to your issue.

[sender]

Maybe you know, maybe you don't. I use this explore to view real time events and topic updates on my broker:

MQTT Explorer

Very handy to discover topics, see updates etc.

[rafale77]

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.

[kfxo]

@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.

[rafale77]

I will look into it. Thanks... I am so close with my own plugin though...

[kfxo]

I thought it might help with writing your plugin. Looking forward to see what you come up with.

[rafale77]

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.

[therealdb]

Slightly OT. Overall I like lua, but I miss the simple approach to non-blocking code offered by c# and even JavaScript. That’s particularly bad when doing network/http call, because it’s very difficult to write async code.

[akbooer]

There’s no fundamental difficulty in writing non-blocking I/O. The openLuup server module and scheduler allow callbacks on incoming. The HTTP async code has a separate module simply because of its entanglement within the LuaSocket HTTP module.

[therealdb]

@akbooer said in MQTT Plugin:

There’s no fundamental difficulty in writing non-blocking I/O.

well, I was speaking about an async/await first approach, with lambdas/promises. co-routines are just OK.
maybe I'm too biased because I'm used to the other approach and I still spend most of my time writing C#/Javascript instead of LUA. I wish it was simpler - let's say - to execute 3 HTTP calls under Vera in parallel, each having its own response handler inline.

[akbooer]

@therealdb said in MQTT Plugin:

I wish it was simpler - let's say - to execute 3 HTTP calls under Vera in parallel, each having its own response handler inline.

So this isn't good enough...?

local async = require "http_async"

async.request ("http://request1",
  function  (response, code, headers, statusline)
    -- response code 1 here
  end)

async.request ("http://request2",
  function  (response, code, headers, statusline)
    -- response code 2 here
  end)

async.request ("http://request3",
  function  (response, code, headers, statusline)
    -- response code 3 here
  end)

[therealdb]

Oh, I missed this.
It could greatly benefit to my own HTTP plug-in. Any plan to release as a plug-in on Vera itself?