question

Hi @Seb71

I may be experiencing the same thing.

Might be wifi. I switched to ethernet and got this from the wifi screen..

The 'Failure' thing I've never noticed before, usually says 'Connected'. Pulled the ethernet and lost it, the wifi didn't take over as it should.

I managed to revive it to 'Connected' status, then pulled the ethernet. Worked ok for a few minutes, then while scratching my head looking at it, a couple of flickers and gone again. Back to ethernet.

2.62, auto updated (whenever). Works ok on ethernet.

Morning Guys

I have just installed my cerbo and had problems similar to what is described, almost as though the processor is lagging and very slow. I noticed it on the LAN network connected and slow loading times. I even lost all bluetooth connectivity, to the point where the blue LED would not even work on the cerbo and light up, even though it was enabled on the unit and the wifi side working.

I finally resolved the speed issues by resetting the unit and for some weird reason all started to work, including the bluetooth and the blue tooth LED on the cerbo. This is on version 2.62. After the reset, I had to use a PC screen and keyboard to enable bluetooth and the wifi again, but it is working well for the last 12 hours and the slow loading seems to have gone away as well. I can only currently, and within reason presume that the new 2.62 firmware is not either flashing correctly or has bugs. When I did flash to the new firmware, I had no issues and it did flash. Hope this helps a little.

Regards

Johan

I have found that if I change to a different WiFi channel on the Access point than it solves it.
For me, CH6 has issues, if I change to CH13 (Europe), it works well.

After reverting back to 2.60 (with which I never had this problem), yesterday I upgraded to the newly released 2.63.

Today I had the same issue again (as described in my original post).

Remote Console was not accessible on my LAN via WiFi for a few minutes.

I checked in VRM right away and I saw:

"Last updated: 7 minutes ago".

Then it started working again, without me doing anything to fix it (same as with 2.62).

I managed to catch it again a few minutes ago.

I sent a ping request to Cerbo GX from a PC in the same LAN (while Remote Console was not accessible via WiFi).

192.168.0.171 is my Cerbo GX (via WiFi)

192.168.0.101 is the PC from where I was sending the ping request to Cerbo GX.

=======================================

Pinging 192.168.0.171 with 32 bytes of data:
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Reply from 192.168.0.101: Destination host unreachable.
Request timed out.
Request timed out.
Reply from 192.168.0.171: bytes=32 time=7ms TTL=64
Reply from 192.168.0.171: bytes=32 time=18ms TTL=64
Reply from 192.168.0.171: bytes=32 time=19ms TTL=64
Reply from 192.168.0.171: bytes=32 time=9ms TTL=64
Reply from 192.168.0.171: bytes=32 time=5ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=4ms TTL=64
Reply from 192.168.0.171: bytes=32 time=7ms TTL=64
Reply from 192.168.0.171: bytes=32 time=3ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=17ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=4ms TTL=64
Reply from 192.168.0.171: bytes=32 time=12ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=3ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=4ms TTL=64
Reply from 192.168.0.171: bytes=32 time=3ms TTL=64
Reply from 192.168.0.171: bytes=32 time=6ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=22ms TTL=64
Reply from 192.168.0.171: bytes=32 time=9ms TTL=64
Reply from 192.168.0.171: bytes=32 time=6ms TTL=64
Reply from 192.168.0.171: bytes=32 time=34ms TTL=64
Reply from 192.168.0.171: bytes=32 time=6ms TTL=64
Reply from 192.168.0.171: bytes=32 time=3ms TTL=64
Reply from 192.168.0.171: bytes=32 time=5ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=3ms TTL=64
Reply from 192.168.0.171: bytes=32 time=3ms TTL=64
Reply from 192.168.0.171: bytes=32 time=6ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=3ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=6ms TTL=64
Reply from 192.168.0.171: bytes=32 time=8ms TTL=64
Reply from 192.168.0.171: bytes=32 time=13ms TTL=64
Reply from 192.168.0.171: bytes=32 time=5ms TTL=64
Reply from 192.168.0.171: bytes=32 time=1ms TTL=64
Reply from 192.168.0.171: bytes=32 time=1ms TTL=64
Reply from 192.168.0.171: bytes=32 time=110ms TTL=64
Reply from 192.168.0.171: bytes=32 time=1ms TTL=64
Reply from 192.168.0.171: bytes=32 time=7ms TTL=64
Reply from 192.168.0.171: bytes=32 time=9ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=2ms TTL=64
Reply from 192.168.0.171: bytes=32 time=9ms TTL=64
Reply from 192.168.0.171: bytes=32 time=5ms TTL=64
Reply from 192.168.0.171: bytes=32 time=6ms TTL=64
Reply from 192.168.0.171: bytes=32 time=6ms TTL=64

Ping statistics for 192.168.0.171:
Packets: Sent = 109, Received = 98, Lost = 11 (10% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 110ms, Average = 7ms

=======================================

At the same time I quickly connected a LAN cable between Cerbo GX and my Internet router.

I could access the Remote Console through the LAN (UTP) cable, but just at that time I saw that the Cerbo GX WiFi recovered and I started to get replies to that ping (see above).

Nevertheless, I managed to capture this screenshot:

As you can see, same status ("Failure") for WiFi as @JohnC had.

And now it did it again.

It is definitively a WiFi issue.

It's not a Cerbo GX freezing issue as I wondered in my original post.

I now know this for sure because this time I already had the LAN cable plugged between Cerbo GX and my Internet router and I could access Cerbo GX via LAN cable, while could not via WiFi.

WiFi had the same "Failure" status.

Then I saw "Connection lost" status and right after that "Connected" status and Remote Console started to work again via WiFi, too.

Hi Seb71 ! Stupid question, are you using a 2.4Ghz phone or a Device for Baby monitoring ? They can create interferences on the 2.4Ghz bandwith... You could check that using a laptop and see how many WiFi networks are in your area, and which canal is the less occupied, then change the router to use it, and wait a few days to see if the issue happens again or not.

Michel

And now it did it the 4th time today.

WiFi not working ("Failure" state) for about 7 minutes.

I went back to 2.60 again.

@Seb71

I haven't seen it again, so consider the experience a one-off.

But I did note in the VenusOS changelog an entry for 2.62, "Fix connecting to another WiFi network after a failure". I take that to mean it won't now connect to another unintended one.

I'm quite remote, so never see a stray unprotected network, and my own phone is banned from such. But maybe applies to you?

@JohnC

But do you have the LAN (UTP) cable always connected between your Cerbo GX and your Internet router (or switch)?

If your UTP cable is always connected to your Cerbo GX, it would be difficult to notice random WiFi failures.

-------

I do have other WiFi networks visible here (from neighbors). All are password protected.

-------

I bought my Cerbo GX last summer (2020), but I completed my system only at the end of November 2020.

My Cerbo GX came with 2.56 firmware (if I remember correctly) and I updated it right away to the latest available firmware at that time (which was 2.60).

Since the end of November 2020 it ran fine with 2.60, until I updated it to 2.62 (and later to 2.63).

Switching back to 2.60 always fixes this issue.

-------

As you know, Victron, for some reason, does not keep old versions available for download.

I only have 2.60 in my Cerbo GX (so I can still boot it).

For comparison, this is the result after about 14 hours of ping requests (made today), when using 2.60 firmware on my Cerbo GX:

=======================================

Ping statistics for 192.168.0.171:

Packets: Sent = 49286, Received = 49231, Lost = 55 (0% loss),

Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3761ms, Average = 19ms

=======================================

Those 55 lost packets were not grouped together, but like this:

I also accessed Remote Console at random intervals. It always loaded right away.

Unfortunately it still happens in 2.65. This time WiFi did not even recovered after waiting about 15-20 minutes. I had to reboot the Cerbo GX (I connected an UTP cable to have access to Remote Console).

Is it worth moving the antenna's to see if this makes a difference?

https://community.victronenergy.com/questions/82877/cerbo-gx-wi-fi-issue-when-having-the-gx-touch-conn.html

I have the same issue as described in the original post except my Cerbo unit is only approx 3 weeks old and is running on ver 2.66. I use a permanent ethernet cable connection to a router. The connection breaks down very irregularly and has been doing it for a week now (before then it was stable). The only way to get it to reconnect is to reboot the unit via the local wifi hotspot connection - some days up to 5 times and today already twice. I have tried setting up a fixed IP address instead of auto but it makes no difference iro reliability. If it loses connection in the evening for example it would not self recover even after 12 hours.

I am also experiencing issues with Remote Control connection to Cerbo GX via WiFi

At best it only works sometimes.

Bought new system in May 2022. Often remote control access via LAN is " lost" - the IP address becomes "unreachable". Interestingly all other devices on LAN remain reachable via PING.

Temporary solution: Reboot the router OR Cerbo GX. The IP address for Cerbo GX then becomes reachable again. Why this is happening is strange.

Cerbo GX version 2.91

Router is a Tandy Wireless Router connected to Fibre (10/5mbps), 2.4GHz and 5GHz

Often (but not always) remote control via VRM works even though LAN access does not!?

Victron Connect will not show Cerbo GX as a local device if LAN access is unavailable.

All the above happens using either iOS Chrome or Windows Chrome (or the Victron Connect app on both systems)

Wifi signal strength is ~80%

LAN Ping times to other devices around 64ms

Settings on Remote Console are all OK

No wiring access to router at this stage until I get fed up.

I suspect the problem lies with Cerbo GX WiFi chip with reference to Local IP addressing or Port numbering. It could also be due to crowded WiFi channels increasing error rates (and thus reducing netwokr speed), whoever, then I would expect all devices to have network speed problems. Perhaps Cerbo GX is oversensitive to networking speed?

Maybe its time that the Cerbo GX gets a proper chip for WiFi that will work at 2.4 and 5 GHz? Or a software tweak to make it more robust.