openweather plugin ?

[therealdb]

Yep, I noticed on my own version as well. It's because the HTTP endpoint crashed (are you using openLuup, right?) or timedout after 10 secs. I'll probably make it configurable in next version and be more aggressive towards crashes.
It's still very beta, even if I'm running a modified version in production for my own.

New release coming up on GitHub in minutes

[ArcherS]

@therealdb yep, I am on OpenLuup.
I tested and the old version also crashes in the same way after 30-60 minutes.

//ArcherS

[therealdb]

@archers are you able to compile it yourself, for an easy fix? I have a new version ready, but I'll need more debug in a real world scenario. But I'm ready to push it, if you can try. I also added support for alternate topic (useful if you want to intercept two mqtt messages with different topics and payload, but execute the same action) and wildcard support for clienid (useful if you have messages coming from other brokers and the original clientid is lost).

[ArcherS]

@therealdb I was able to build the previous versions, so I can try the new version if you push it.

[therealdb]

@archers ok, it's on GitHub. Lemme know if it's working for you and I'll produce a compiled build (and I'll also automate it in the next days to automagically do it for me).

[ArcherS]

@therealdb new version built and started, I will report back how it goes.

[ArcherS]

@therealdb I have now had the updated Mqtt Bridge running continuously for little more than 25 hours. So far it is still alive and kicking.

The log file is now working I get entries in the log, which I did not get before. This makes it easier to see what is happening of course.
So when the bridge starts I get:

2021-01-30 11:24:16.055 +01:00 [INF] [MQTTServer] Broker is starting v 0.31.210130 on port 1883...
2021-01-30 11:28:40.877 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 24.5
2021-01-30 11:33:40.770 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 24.9
etc...

At times I get the following error, I assume it is related to the http issue:

2021-01-31 11:38:40.852 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 25.5
2021-01-31 11:38:50.854 +01:00 [ERR] [LuupWrapper] RunCommandAsync: http://127.0.0.1:3480/data_request?id=variableset&output_format=json&DeviceNum=216&serviceId=urn:upnp-org:serviceId:TemperatureSensor1&Variable=CurrentTemperature&Value=25.5&RunAsync=1
System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 10 seconds elapsing.
 ---> System.TimeoutException: The operation was canceled.
 ---> System.Threading.Tasks.TaskCanceledException: The operation was canceled.
 ---> System.IO.IOException: Unable to read data from the transport connection: Operation canceled.
 ---> System.Net.Sockets.SocketException (125): Operation canceled
   --- End of inner exception stack trace ---
   at void System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at int System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs.GetResult(short token)
   at async ValueTask System.Net.Http.HttpConnection.FillAsync(bool async)
   at async ValueTask<ArraySegment<byte>> System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(bool async, bool foldedHeadersAllowed)
   at async Task<HttpResponseMessage> System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, bool async, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at async Task<HttpResponseMessage> System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, bool async, CancellationToken cancellationToken)
   at async ValueTask<HttpResponseMessage> System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, bool async, bool doRequestAuth, CancellationToken cancellationToken)
   at async ValueTask<HttpResponseMessage> System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, bool async, CancellationToken cancellationToken)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.Logging.LoggingHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task<TResult> Polly.Retry.AsyncRetryEngine.ImplementationAsync<TResult>(Func<Context, CancellationToken, Task<TResult>> action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates<TResult> shouldRetryResultPredicates, Func<DelegateResult<TResult>, TimeSpan, int, Context, Task> onRetryAsync, int permittedRetryCount, IEnumerable<TimeSpan> sleepDurationsEnumerable, Func<int, DelegateResult<TResult>, Context, TimeSpan> sleepDurationProvider, bool continueOnCapturedContext)
   at async Task<TResult> Polly.AsyncPolicy<TResult>.ExecuteAsync(Func<Context, CancellationToken, Task<TResult>> action, Context context, CancellationToken cancellationToken, bool continueOnCapturedContext)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.PolicyHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task<TResult> Polly.Bulkhead.AsyncBulkheadEngine.ImplementationAsync<TResult>(Func<Context, CancellationToken, Task<TResult>> action, Context context, Func<Context, Task> onBulkheadRejectedAsync, SemaphoreSlim maxParallelizationSemaphore, SemaphoreSlim maxQueuedActionsSemaphore, CancellationToken cancellationToken, bool continueOnCapturedContext)
   at async Task<TResult> Polly.AsyncPolicy<TResult>.ExecuteAsync(Func<Context, CancellationToken, Task<TResult>> action, Context context, CancellationToken cancellationToken, bool continueOnCapturedContext)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.PolicyHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.Logging.LoggingScopeHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async ValueTask<HttpResponseMessage> System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, bool async, bool emitTelemetryStartStop, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   --- End of inner exception stack trace ---
   at async ValueTask<HttpResponseMessage> System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, bool async, bool emitTelemetryStartStop, CancellationToken cancellationToken)
   at async Task<string> System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task Luup.MqttBridge.Services.LuupWrapper.RunCommandAsync(int deviceID, string action, string actionCommand, string commandParameter, string command, string serviceID, string value)
2021-01-31 11:43:40.851 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 25.5
2021-01-31 11:48:40.836 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 25.6
etc...

After the above error it goes back to reporting updates.
The error comes quite random, at times once every approx 20-30 minutes, and at times it can be a few hours between them.

So far I have only one test device in OpenLuup getting values from the bridge, I do not know how adding some 50+ topics would affect the overall load and stability.

Edit: It could be worth mentioning that I today have some 50 devices in OpenLuup that are getting their values over http; some SiteSensors a bunch of virtual sensors getting data from Tasmota/Shelly devices etc. In other words there is a bit of activity already going on through the http interface today. Moving most of them to Mqtt would perhaps not increase the load at all, who knows.

Looking promising, thanks for the effort so far with the bridge!

[therealdb]

I have mine running with almost 20 virtual devices and it's rock solid. It's pushing to vera as well.

My forked version has the ability to update the value only if a difference threshold is met (useful to avoid too many requests to the http interface). I'll try to backport it here in the coming days.

As I said, I'm using it to push things from a lot of different things (tasmota, shelly, my windows app, miflora).

I'll add an http endpoint soon to publish messages as well.

[ArcherS]

@therealdb that sounds reassuring, thanks!

As a side note to anyone venturing into the world of mqtt I found Mqtt Explorer which seems to be a pretty nice tool for looking at messages, topics etc.
It can even create graphs for values to track them over time.

[therealdb]

@archers said in MQTT Plugin:

@therealdb that sounds reassuring, thanks!

is this still working for you?

[ArcherS]

@therealdb yep, it is still working, still only one test device receiving data.
I get the same error related to the http issue from time to time as shown in the log above, but it recovers and continue updating the device.

[therealdb]

@archers the error is related to openLuup HTTP server. the system can recover from faulty calls and re-try them again. Maybe I'll make the logs less verbose in the next iteration.