meteohub.de

It was time to streamline the code across the various platforms a bit. This also had an impact on the crowdy start configuration scripts. My tests indicate that I have not broken anything, but experience tells that I for sure did

Please report freshly implemented bugs here. I will try to fix those short term.

Nano Aug 11 release loads as v5.4 Build 4261 (Aug 11, 2022) Matches release date

MBPro Aug 11 release loads as v5,4 Build 14798 (Aug 4, 2022) Confirm this date?

I just released fresh images.

Hello,
I've noticed that since I installed the latest release, some weather networks, especially Meteotemplate which is the most important to me, they often go offline (ever had any problems before).
I reboot MB and everyone works again.
Coincidence? bug? php8.1?
tnx in advance for any comments
Norbert

Meteobridge did not change in how it feeds weather networks. I see from the messages that you are sending too often and the other error is a message from the target server about an internal problem.I Don't hink it is related to the changes in Meteobridge.

At random occurence: meteobridge doesn't send rain total and solar through to websites.
Also ftp upload gets regurarly stuck.

Staying with 5.3 solves the problem.

Or rebooting the device.

Since 5.4 I need to reboot almost every day because it 'freezes', sends out no data anymore (rain total and solar from Davis WLL).

Grtz

Can you please send remote login credentials and how to reproduce the error regarding not showing up data.

I have never noticed these problems before until CWOP began experiencing server network issues.

1.) Meteobridge seems to struggle to figure out which of the rolling CWOP servers to upload to and the connections fail many times, I've seen upwards to an hour last weekend.

2.) When this happens, then the logger appears to logger stops sending to Wunderground until the next CWOP attempt.

I've already reflashed my Meteobridge and tried multiple upload settings.

CWOP does not provide rolling servers anymore, at least externally.

Ok but is the logger supposed to stall and stop reporting to other networks each time when a different network suffers a failed connection?

kejaco wrote: ↑Sat Sep 24, 2022 5:24 pm Ok but is the logger supposed to stall and stop reporting to other networks each time when a different network suffers a failed connection?

Requests to weather networks are not done in parallel as this will blow the RAM and performance limited SOCs of the Meteobridge. Therefore, requests are serialized and provided with a timeout, when no reply coming back in time. When CWOP internal IP resolution does point to nothing on their side, no error is returned, but Meteobridge waits until deciding to give up by its internal timeout definition. Now assume that some services are triggered every 10 seconds and the CWOP services again and again run into the 30 seconds timeout stall. Now requests will queue up and even when Meteobridge does try some smart priorization in the sending queue this will result into a mess after some time.

Doing things in parallel will be even worse as over time more and more processes will queue up in parallel until the whole system gets unresponsive or crashes because of lack of resources.