meteohub.de

ac2ev wrote: Fri Dec 04, 2020 7:12 pm Actually I do. It’s a Pi-Hole DNS filter. I can bypass it by setting the DNS manually. I don’t have issues with the Nano SD unit getting out. The internal pages slow down along with SSH. I have not experienced this with any other devices on my network. There’s a half dozen Raspberry PIs, 4 laptops, 3 chrome books, half dozen cameras, etc,

Network is all Ubiquiti equipment.

I set the meteobridge to manually with Google’s DNS.

Sounds more like an experimental setup to me that asks for trouble by design. When you put the NANO on a dedicated SSID with a fixed channel and just on one (the nearest) AP and giving all credentials via DHCP (no special DNS thingies) you should be fine. As it works for hundreds of users you should start eliminating what makes your setup special. Just my $0.02.

Ubiquiti networks work fine with NanoSD (and MBPro for that matter) and standard DNS, sounds like something in your network is just not right?

The Pi-Hole handles forwarding outside of my network to Quad9 DNS. There is conditional forwarding but only for internal addresses on my LAN this is to allow local name resolution. There is not DNS recursion. This setup has been in place for years and has caused zero issues with any of the devices on my network. There are dozens of devices on my network and none have an issue.

None of this explains why after about 3 days of runtime why the Nano's internal webpage, Weather 34 dashboard, and SSH would become slow to unresponsive.

I have made the following changes:
static IP/GW/SN/DNS
I verified the DNS using the tools in in the OpenWRT setup (using 8.8.8.
Set up my IP camera to provide an image of 1280x720 ( was 2688x1520). I thought perhaps the image retrieval may not be releasing RAM after grabbing images from my camera.

The Nano has no issues sending data out to the Wunderground, Wunderground camera, Meteobridge Camear, PWS, APRS, CWOP

I upgraded the power supply to a 3A unit.

Looking at the system log (this may not mean anything)

This is repeated several dozen times Kernel log I'm wondering if it would help to have system log write to /dev/mmcblk0p1 ?
I'll keep monitoring process load and memory usage on the OpenWRT side, it hasn't changed much since I built custom devices with it years ago.
Is Meteobridge logging to anywhere?

Please allow me to be a bit sceptic that it worked fine and then out of nothing it stops operation.

When you played with openwrt on the device you have a good chance to break it, as the default openwrt stack did not feed the vocore2 wireless needs and I had to install some hooks to get it running from within Meteobridge. Clicking around in the openwrt interface might have this broken... I stop here...

Please start over with factory defaults.

Are you saying that viewing the OpenWRT pages could break the Nano, even if no settings are changed? Why give the user a button to it if simply bring up the other webpage will break it?

Is this system really that fragile?

To be clear: I have not made any changes in the OpenWRT/Luci interface only viewed the system logs and memory usage. I did not modify or change any settings in the OpenWRT pages.

All changes I made were done in the Meteobridge interface only.

I can perform a factory reset if you want but I don’t think we’ve made any progress in determining what is going on.

My issue is:
The unit is working fine but slows down after 3 days of runtime.

Edit:
I have performed a factory reset and set up my network (static IP/GW/SN/DNS 8.8.8.8 ), weather, and camera. I will report back in a couple days if the slowdown happens again.

Since it runs fine for three days before slowing down could it possibly be a buffer or memory issue that fills up after three days and then isn’t purged ?. I don’t know if there is any way to test either the on board ram or the microSD card to see if either is the culprit ?.

BigAlT wrote: Sat Dec 05, 2020 11:03 pm Since it runs fine for three days before slowing down could it possibly be a buffer or memory issue that fills up after three days and then isn’t purged ?. I don’t know if there is any way to test either the on board ram or the microSD card to see if either is the culprit ?.

It seems to have the hallmarks of a memory leak. Since other people have similar setups the only variable I could think of would be the IP camera image. I set the resolution on my camera much lower, thinking maybe the routine in the Nano wasn’t purging out the old image(s).

It’s my understanding the image processing is done on the meteobridge website vs locally. So that shouldn’t be the issue.

There’s not enough serial data to cause this issue, at least I wouldn’t think so.

We’ll see how things are in a few days.

So far so good. Don’t know if it’s the reduced IP camera image size or not enabling the dashboard. It seems to be stable and working, success.