meteohub.de

More an more features were added over time, so RAM might go a bit low on certain conditions. SMB takes a lot of RAM, so disabling it might help. If not, we know at least that this is not the reason

End of May the frequency of the hang-up trouble went up and getting sick of weather services reporting my station was offline and instead of doing a full erase and a clean build of the MB-Red, I took a bold step and ordered a new MB-Black. Yes that did hurt, but was on my long-term wish list anyway since the MB-Red display has developed serious burn spots and I always disliked its inside temperature going 50 - 63 degree C in summer.
I now have the two running in parallel at same location in my attack and this setup allows to have a close look at the issue without risk of any further data loss and misfiring in the weather services updates.
The MB-Black was simply loaded with the MB-Red configuration file and a copy of the database from the MB Red. And it ran without any issue and no spikes in CPU-% at the hour !
I did the transition in small steps, switching off things in the MB-Red and simultaneously switching same service on in the MB-Black. And checking CPU-% for multiple hours.
1 Stopped all events
2 Erased all events
3 Stopped uploads to weather services
So far, the CPU-% spiking remained for the MB-Red while no spiking in the MB-Black.
Then I erased the database in the MB-Red and to my surprise the spiking had stopped !
Loading the database again resulted in return of the CPU spiking at the hour.
Reconstruction of that database did not change the problem.

In order to produce some Prohealth graphs to show the effect on this forum I tried to reproduce above sequence, but when loading the database the MB-Red returned a stubborn error: “cannot prepare create table (after 0 tries in 1ms): database disk image is malformed (11) dbase (06.06.2026 21:29:45): RAM database purged.”
I tried older versions of its back-up database and configuration file, did multiple restarts, factory resets, nothing helped to accept a database back-up file. Suspecting the internal memory stick was the problem, I had the MB-Red running with an external USB stick as database store. And tried to get the database loaded in again via the second USB port. Still no success, same error: “database disk image is malformed (11)”. As a last option I tried to load a fresh database back-up file from the MB-Black and using the internal USB memory again to store it. And that step made the MB-Red run without issues, no errors and no CPU spikes over 100% at the hour! Weird that the MB-Red did not accept it’s own back-up file, but did accept the MB-Black database.

Maybe Boris can get some clues out my excursions.

For the moment the MB-Black is running fine for a month. While the MB-Red has developed a new issue: it loses connection to all my Davis stations while sitting next to the MB-Black. RF-signal strength was a typical -69 dB at time of disconnection, so cannot be an issue, I would say. Simply restarting the MB-Red make it go again, but unfortunately not for long. RAM usage is usually around 80%, sometimes 91% max. He're some typical lines from the logfile:
logger (30.06.2026 18:54:08): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (30.06.2026 18:54:08): disconnect station 0 (RF Vantage): timeout
logger (30.06.2026 18:54:38): connect station 0 (RF Vantage via USB serial).
logger (30.06.2026 19:39:09): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (30.06.2026 19:39:09): disconnect station 0 (RF Vantage): timeout
logger (30.06.2026 19:39:39): connect station 0 (RF Vantage via USB serial).

For those having a similar CPU spike issue, if you are in a position to try running with an empty database, pls check about spikes disappearing like in my case.

admin wrote: Fri Jul 03, 2026 4:48 pm More an more features were added over time, so RAM might go a bit low on certain conditions. SMB takes a lot of RAM, so disabling it might help. If not, we know at least that this is not the reason

Mine is still crashing despite disabling SMB

I updated the firmware this morning, and then it crashed in the afternoon

Mine does seem to be more stable after disabling SMB.

yamahabest wrote: Wed Jul 15, 2026 11:29 am Mine does seem to be more stable after disabling SMB.

Mine as well… only had one crash so far

EDIT:

just died again

PING 192.168.10.10 (192.168.10.10): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
ping: sendto: No route to host
Request timeout for icmp_seq 3
ping: sendto: Host is down
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
^C
--- 192.168.10.10 ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss

These messages are a bit strange:
The "connect" message should initiate a reset of the RF module which should as far as I can remember punch out a couple of messages.

Can you please send me a remote login to your Meteobridge?

I'll send remote login details per mail.
Remarkably those messages also appear in the logfile for the MB-Black I've running in parallel. But for different times.

Logfile copies of most recent occurrences during June 16 - 17:
MB-Red:
dbase (16.07.2026 15:29:22): database sync done (125 tables, 44/7215 writes).
logger (17.07.2026 01:41:14): station 0 (RF Vantage), no signal for 2700 seconds, station to be restarted.
logger (17.07.2026 01:41:14): disconnect station 0 (RF Vantage): timeout
logger (17.07.2026 01:41:44): connect station 0 (RF Vantage via USB serial).
logger (17.07.2026 01:41:52): station 0 (RF Vantage), transmitter 1 registered as ISS
logger (17.07.2026 01:41:52): station 0 (RF Vantage), transmitter 2 registered as Temperature/Humidity
logger (17.07.2026 01:41:52): station 0 (RF Vantage), transmitter 3 registered as Leaf/Soil
logger (17.07.2026 01:41:52): station 0 (RF Vantage), transmitter 4 registered as Leaf/Soil
logger (17.07.2026 01:41:52): station 0 (RF Vantage), transmitter 8 registered as ISS

MB-Black:
logger (16.07.2026 09:04:55): station 0 (RF Vantage), no signal for 2700 seconds, station to be restarted.
logger (16.07.2026 09:04:55): disconnect station 0 (RF Vantage): timeout
logger (16.07.2026 09:05:25): connect station 0 (RF Vantage via serial).
logger (16.07.2026 09:05:34): station 0 (RF Vantage), transmitter 1 registered as ISS
logger (16.07.2026 09:05:34): station 0 (RF Vantage), transmitter 2 registered as Temperature/Humidity
logger (16.07.2026 09:05:34): station 0 (RF Vantage), transmitter 3 registered as Leaf/Soil
logger (16.07.2026 09:05:34): station 0 (RF Vantage), transmitter 4 registered as Leaf/Soil
logger (16.07.2026 09:05:34): station 0 (RF Vantage), transmitter 8 registered as ISS
logger (16.07.2026 16:41:50): station 0 (RF Vantage), no signal for 2700 seconds, station to be restarted.
logger (16.07.2026 16:41:50): disconnect station 0 (RF Vantage): timeout
logger (16.07.2026 16:42:20): connect station 0 (RF Vantage via serial).
logger (16.07.2026 16:42:29): station 0 (RF Vantage), transmitter 1 registered as ISS
logger (16.07.2026 16:42:29): station 0 (RF Vantage), transmitter 2 registered as Temperature/Humidity
logger (16.07.2026 16:42:29): station 0 (RF Vantage), transmitter 3 registered as Leaf/Soil
logger (16.07.2026 16:42:29): station 0 (RF Vantage), transmitter 4 registered as Leaf/Soil
logger (16.07.2026 16:42:29): station 0 (RF Vantage), transmitter 8 registered as ISS

The odd thing is both MB's report "station 0 (RF Vantage), no signal for 2700 seconds, station to be restarted." but at different times. And station 0 is a set of 4 Davis Vantage transmitters at different frequencies, so hard to believe they fail to transmit at same time.

This puzzles me completely. The RED shows in the log of your first example no initialisation messages after a fresh "connect". Your latest post one the same machine does show it. Looks like something in the receiver module has hung up. That is th only plausible explanation that comes into my mind for this inconsistent reaction on a "connect" attempt.

Is the core issue that no RF data coming in or does the unit get stalled in total?

I could still access the MB Red and check all tabs, but there was no data coming in. So it looks like no RF reception. But the brandnew MB Black is showing same problem at different time.

Does anybody know what this error means:
logger (09.09.2026 08:08:58): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (09.09.2026 08:08:58): disconnect station 0 (RF Vantage): timeout
logger (09.09.2026 08:09:28): connect station 0 (RF Vantage via USB serial).
logger (09.09.2026 08:53:59): station 0 (RF Vantage), no synchronization for 2700 seconds, data logger will be restarted.
logger (09.09.2026 08:53:59): disconnect station 0 (RF Vantage): timeout
logger (09.09.2026 08:54:29): connect station 0 (RF Vantage via USB serial).

And what could be the cause?
I's a bit hard to believe it's a reception error, since the Vantage system has 4 different transmitters (ISS, Temp/hum & 2x Soil/leave) and ISS signal strenghth is around -70 dB. CPU% and RAM% are not high. The Envoy datalogger is in same location as the Meteobridge and is running well.

I have since couple of weeks same problem,
dbase (18.09.2026 00:00:39): deletion of per minute data between 1970-01-01 and 2025-09-17 initiated (56 sensors).
dbase (18.09.2026 00:00:49): deletion of per minute data done for 56 sensors.
backup (18.09.2026 20:58:12): backup media size is 29.3G (205.4M free).
backup (18.09.2026 20:58:22): old backup file removed: dbase-202608100920
backup (18.09.2026 21:02:15): backup completed: dbase-202609182058 (763.8M)
dbase (19.09.2026 00:00:28): deletion of per minute data between 1970-01-01 and 2025-09-18 initiated (56 sensors).
dbase (19.09.2026 00:00:35): deletion of per minute data done for 56 sensors.
logger (19.09.2026 08:23:39): station 0 (RF Vantage), no signal for 1350 seconds, station to be restarted.
logger (19.09.2026 08:23:39): disconnect station 0 (RF Vantage): timeout
logger (19.09.2026 08:24:09): connect station 0 (RF Vantage via serial).
logger (19.09.2026 08:24:09): station 0 (RF Vantage), transmitter 1 registered as ISS
logger (19.09.2026 08:24:09): station 0 (RF Vantage), transmitter 2 registered as Soil
logger (19.09.2026 08:24:09): station 0 (RF Vantage), transmitter 3 registered as Wind
logger (19.09.2026 08:24:09): station 0 (RF Vantage), initialization string sent to device /dev/ttyS0
logger (19.09.2026 08:46:10): station 0 (RF Vantage), no signal for 1350 seconds, station to be restarted.
logger (19.09.2026 08:46:10): disconnect station 0 (RF Vantage): timeout
logger (19.09.2026 08:46:40): connect station 0 (RF Vantage via serial).
logger (19.09.2026 08:46:40): station 0 (RF Vantage), transmitter 1 registered as ISS
logger (19.09.2026 08:46:40): station 0 (RF Vantage), transmitter 2 registered as Soil
logger (19.09.2026 08:46:40): station 0 (RF Vantage), transmitter 3 registered as Wind
logger (19.09.2026 08:46:40): station 0 (RF Vantage), initialization string sent to device /dev/ttyS0
logger (19.09.2026 09:08:41): station 0 (RF Vantage), no signal for 1350 seconds, station to be restarted.

only a reboot fixes it.