openweather plugin ?

[akbooer]

...if you excuse a link to the other place:

May 11, 2019

openLuup: Asynchronous I/O

The latest openLuup development release has a new file in the openLuup/ folder: http_async.lua. This now implements asynchronous HTTP and HTTPS requests (depending on which scheme is provided in the requested URL.) If you want to use it, you simply require it in your code like this: local async...

[rafale77]

Well my frustration is not so much with http, though I did have my run ins with it and ended up using libcurl due to... digest not working somehow on luajit with luasocket but at this moment, I am finding that:

1. the luarocks version of the MQTT library uses the luasocket in a blocking fashion. It does connect fine to the MQTT broker though.
2. the vera-mqtt plugin is full of little bugs causing it to not work as a subscription client. For example the library fails to declare the socket variable, It crashes with an empty socket call to SSL when SSL is not needed etc... I have not been able to make it connect to the mosquitto broker even after fixing all the problems I found...

Sadly, I may have to move back to python and have home-assistant being the MQTT bridge.

[therealdb]

As I already said, I wrote my own bridge in c#. I might make it more general purpose and release it. It’s a process running inside .net core and as ha-bridge could be installed separately, but pointing to openluup.
Let’s see if I find some motivation. It’s very lightweight, since it’s just one library running in a console app, and .NET Core 3.1 is very performant.

[kfxo]

@rafale77 said in MQTT Plugin:

2. the vera-mqtt plugin is full of little bugs causing it to not work as a subscription client. For example the library fails to declare the socket variable, It crashes with an empty socket call to SSL when SSL is not needed etc... I have not been able to make it connect to the mosquitto broker even after fixing all the problems I found...

Sadly, I may have to move back to python and have home-assistant being the MQTT bridge.

I have had good success with the plugin I linked to above. Currently I have 9 different child devices subscribing to at least 15 different topics. I did modify the plugin slightly, not to get it to work, but to allow for child devices to have any designated number of subscriptions, include availability, state, and command topic subscriptions, and I added actions/functions for reconnecting to the mqtt server and reconnecting subscriptions.

[rafale77]

Well I made some progress and got it to connect to the broker but it is extremely fragile. Digging into it deeper, it actually relies on a periodic call of a "handler" function in the library to check for messages from the broker. The call fails regularly and is not very well written in the sense that it defeats the purpose of MQTT by doing a poll.
There are a number of forks of this library which attempted various fixes and they have had various degree of success.
Not judging the plugin itself but rather the MQTT library. I actually took quite a bit from the plugin for these tests. Still work in progress but I am pretty pessimistic.

[rafale77]

Update: I now have a kind of a working solution and it is interesting...
The fundamental problem is that setting up an MQTT client to listen to the broker blocks the luasocket and therefore openLuup.
The two libraries use different approaches to the problem.
The older library used by the vera MQTT plugin uses a handler function which polls the broker and gets and closes immediately regardless of getting a message or not. It therefore won't block the luasocket but it comes back empty 99% of the time and really relies on luck to catch a message as it can miss them. Basically unusable.
The newer lua library does the same but waits for a message back and blocks the luasocket while waiting. If one sets a high polling frequency without getting a message back, openLuup hangs. My solution to this has been to significantly increase the frequency of messages from the publishing client to unblock the socket. It really is no longer event based and this generates a lot of traffic.

If anyone has better suggestions (@therealdb I look forward to your bridge). I am also thinking that openLuup could use moving all its http traffic from luasocket to libcurl...

Edit:

I ended up giving up on trying to make it work with luasocket and spent 2min setting up 4 MQTT subscriptions on Home Assistant and another 10 to build the bridges back into openLuup. I really hoped to be able to do have a direct pipe into openLuup...

[therealdb]

@rafale77 right now I'm using it to process incoming messages and update variables on Vera/Openluup. Do you want to call service endpoints as well? I can make it really generic and call HTTP endpoints, if needed. So you can
I don't use it so much to send messages, but I think we could add this later, if needed.
I can also try to put a relay feature, to receive incoming messages and then publish them back to another broker.

It's based on a JSON config file and you have to map it manually, but then it's transparent. Give me a couple of days to polish and I'll publish it on GitHub, with instructions on how to build, and install it.

[akbooer]

@rafale77 said in MQTT Plugin:

The fundamental problem is that setting up an MQTT client to listen to the broker blocks the luasocket and therefore openLuup.
The two libraries use different approaches to the problem.

This just sounds like a lack of understanding on behalf of the module authors, ...or possibly me. I can’t believe that it could possibly be so difficult.

These are the two libraries you referenced st the start?

[rafale77]

@akbooer
Or it could very well be that I missed something but looking at reports from github, I am not the only one observing it. These library work very well for publishing to the broker. They don't work unless you want to dedicate an instance of lua to be the listener...
@therealdb
This could potentially be the base for a bridge to so many things for openLuup!!

[therealdb]

@rafale77 I have a simple version almost ready. I'll debug later today or tomorrow, and put on GitHub. Here's an excerpt of the config:

{
	"MQTT": {
		"Username": "vera",
		"Password": "openluup",
		"Port": 1883
	},

	"Devices": [
		{
			"Name": "Pool",
			"ClientID": "sonoff-pool",

			"TopicName": "tele/tasmota/SENSOR",
			"TopicPath": "AM2301.Temperature",

			"DeviceID": 12,
			"Service": "urn:upnp-org:serviceId:TemperatureSensor1",
			"Variable": "CurrentTemperature"
		},

		{
			"Name": "DeHumidifier",
			"ClientID": "tasmota-dehum",

			"TopicName": "stat/sonoff/POWER",
			"TopicValue": "ON",

			"DeviceID": 12,
			"Service": "urn:upnp-org:serviceId:HVAC_UserOperatingMode1",
			"Variable": "ModeTarget",
			"Value": "HeatOn"
		},

		{
			"Name": "DeHumidifier",
			"ClientID": "tasmota-dehum",

			"TopicName": "stat/sonoff/POWER",
			"TopicValue": "OFF",

			"DeviceID": 12,
			"Service": "urn:upnp-org:serviceId:HVAC_UserOperatingMode1",
			"Variable": "ModeTarget",
			"Value": "Off"
		}
	]
}

I think it's more than enough to understand how the things will gonna work

[Buxton]

@rafale77 hey Rafale,

I went down the very same road a while back and threw in towel because the polling by the MQTT plugin created CPU drags that stopped openLuup from functioning "reliably". The instability was also in part because I use two other must-have plugins that rely on polling, and I imagine that the combination of the three was creating a scenario that caused intermittent failures. And I too ended up implementing MQTT in Home Assistant and then using RealDB's virtual HTTP plugin to send commands to my WiFi devices--albeit not knowing the status of the devices in openLuup after the send.

I'm looking at RigPapa's socket proxy and WebSocket plugins to see if I can transform my polling plugins to Async. The MQTT plugin is too complex for me to convert though, so if you take a crack at it, and are successful, I would very much appreciate you publishing your results, as MQTT is becoming a must for me.

GitHub - toggledbits/sockproxyd: A socket proxy for Vera/openLuup systems

A socket proxy for Vera/openLuup systems. Contribute to toggledbits/sockproxyd development by creating an account on GitHub.

GitHub - toggledbits/LuWS: A WebSocket client implementation for Luup (Vera and openLuup) systems, with optional async receive (responsive)

A WebSocket client implementation for Luup (Vera and openLuup) systems, with optional async receive (responsive) - toggledbits/LuWS

[rafale77]

I was also thinking about using a proxy for this but it is really adding a layer of complication. For MQTT it might be work it though, I think @therealdb 's solution is likely a better approach... basically also kind of a proxy written in C to act as the client and seems to be very lightweight.

[therealdb]

I had a brief health problem in the latest days that put me completely KO, but I'm recovering. Code is almost done, I just need some time to test it under load and write some doc. I hope to finish it later today.

[therealdb]

here we are: https://github.com/dbochicchio/luup-mqtt

Try it and let me know. It should be easy to acquire .NET Core SDK and build the app. It's very minimal, fast and should be easy to understand. Right now it's only updating variables (with virtual device I think it's more tha enough), but I could add other actions if needed.

[rafale77]

@therealdb

Thank you! I will be testing it shortly now that I am done with my object recognition component and fixed a couple of network issues.

[RogerO]

Hi Guys,
Was on the Lobo beta using Owntracks that Rigpapa was running but he killed it to focus on other projects. I have MQTT broker (Mosquitto) running on my rpi but can't figure out how to get MQTT data into a virtual switch on Vera. Did you ever get this working? Are there compiled files anywhere I can load on my Vera or openluup device?

Roger

[therealdb]

I'm using it exactly for OwnTracks (well, a forked version based on this). I could publish compiled binaries for sure if you are interested.

Since OwnTracks is publishing raw data, you'll need something (ie: some code in a scene) in order to really parse the lat/lon/accuracy and update a virtual sensor.

[RogerO]

Thanks, that would be great.

[ArcherS]

@therealdb I finally decided to try and setup MQTT for my Tasmota and Shelly devices.
After having built the bridge i.a.w. the instructions I have copied it to my Ubuntu PC that also is running OpenLuup. I put all the files in a folder in "Home" and given permissions sudo chmod -R a+rwx /path/to/folder.
(I built the files on my Win 10 PC in an Ubuntu WSL including -r linux-x64.)

The Tasmota test device I use says "MQT: Connected" in the console so it seems that it connects to the bridge when it starts. I also set up MQTT Explorer and it also connects to the bridge and shows the topics from the Tasmota device.

Despite this no temp value is set for the virtual sensor in OpenLuup I use for the test.
I have double checked the topic name, the topic path and the OpenLuup information and it seems correct.

appsettings.json:

{
	"MQTT": {
		"Username": "luup",
		"Password": "openluup",
		"Port": 1883
	},

	"Luup": {
		"ipAddress": "127.0.0.1",
		"port": 3480
	},

	"Devices": [
		{
			"ClientID": "tasmota_test",

			"TopicName": "tele/tasmota_test/SENSOR",
			"TopicPath": "AM2301.Temperature",

			"DeviceID": 216,
			"Service": "urn:upnp-org:serviceId:TemperatureSensor1",
			"Variable": "CurrentTemperature"
		}
	],

	/* remove comment when you're OK with less logs
	"Serilog": {
		"MinimumLevel": {
			"Default": "Information",
			"Override": {
				"Microsoft": "Fatal",
				"System": "Fatal"
			}
		}
	}
	*/
}

Sensor topic on Tasmota console is posted when Tasmota posts the data:

13:58:05 MQT: tele/tasmota_test/SENSOR = {"Time":"2021-01-28T13:58:05","AM2301":{"Temperature":23.5,"Humidity":37.3,"DewPoint":8.1},"TempUnit":"C"}

Device in OpenLuup:

The log file says:

2021-01-28 12:51:57.992 +01:00 [INF] [MQTTServer] Broker is starting on port 1883...
2021-01-28 12:59:21.709 +01:00 [INF] [MQTTServer] Broker is starting on port 1883...
2021-01-28 13:55:27.236 +01:00 [INF] [MQTTServer] Broker is starting on port 1883...
2021-01-28 13:57:48.402 +01:00 [INF] [MQTTServer] Broker is starting on port 1883...

Any ideas on what could be wrong? I have most likely missed something obvious.

//ArcherS

[akbooer]

Sorry, nothing to suggest. I took a look at the MQTT code and while ago and it's rather poorly written.

FYI, though, I am in the process of writing a Shelly bridge for openLuup, which will have its own MQTT server and be able to automatically create configured devices for any Shellys that use it.

Turns out that it's rather easier to write a minimal MQTT server than it is an MQTT client.