meteohub.de

my Nano SD updated this morning

I can no longer access the web GUI , it is coming up with the local AP and i can attach to that via 192.168.169.1 , it shows the network page

Status is

Connect to WLAN at 192.168.6.91 which is where it should be , but i cannot connect to this via a PC using chrome or edge , it just times out
Interesting status also says NO internet and NO DNS ....
I tried changing it to DHCP and it no longer gets a DHCP address ...
I tried the network DNS and also google 8.8.8.8 same result

I upgraded the power supply to 5v / 1A in case , but no change , it is in a davis vue console , led is flashing on the nano

It does not answer a ping and the local AP appears to be coming up and down so maybe a boot loop ?

A problem in 4.4 ??

Thanks

Status pic attached

I just restarted my NANO SD and it comes up fine with the current version. As the changes done the last days are about the station connectivity only, I am rather sure your problems are not related to any 4.4 issue.

BTW, your gateway IP looks not good to me. Normally the router is located at ".1" and not ".254".

Thanks for the reply

The gateway is fine it is a firewall/router at .254

Seems odd but i think it is related to multiple Ap's , the nano can see multiple Ap's which have the same SSID which is correct and normal on this site, however it seems maybe the nano is jumping between the AP's then gives up and restablishises its own control AP , also there are 2.4ghz and 5ghz networks with the same SSID but the nano shouldn't see the 5's

I seem to have resolved it by creating a separate specific SSID just for the Nano on the closest access point , it now seems stable

ok, thanks for letting us know.

That kind of concerns me, because I've also a setup with multiple APs and using the same SSID for 2.4 and 5GHz. Creating an extra SSID just for meteobridge would annoying and I hope that metrobridge will really cope with environments with multiple APs (which is BTW not an unusual setup)

what Meteobridge can do in terms of networking depends on the underlying openwrt stack. We have full controll of the application level, but not on supported networking modes. When you do "unusal" wifi things like meshing or SSID sharing it might work or might not.

I completely understand that metrobridge depends on openwrt and you don't have control over that part.

But have there been any changes to the openwrt stack that were released with the new meteobridge version ?

If no, it would still interesting why the problem occurred and whether other experiencing the same issues with the version and a similar setup.
If there have been changes, it's still a regression from our (the users) perspective and might prevent users to update to a newer meteobridge version.

Thanks,
Bernd

thunderstorm wrote: ↑Wed Sep 16, 2020 3:23 pm But have there been any changes to the openwrt stack that were released with the new meteobridge version ?

When we port Meteobridge to a new platform we use the most recent openwrt stack. From this point on, updates will only happen on the application level, we don't touch the openwrt stack as this will make reflashing of devices neccessary, which is not acceptable when you have a few thousand users. When you look at the list of supported devices you might get an idea what it means to have all those up and running with all the new things we do on the application side. To add multiple openwrt stacks for each of the devices is simply not manageable.