EV Charger won't connect to Cloud after switching to Ubiquiti Router.

I have recently upgraded my home networking setup from a ISP provider router to a Ubiquiti UDR7 + 2 APs. Overall, I have been extremely happy with the new system, with the exception of the EV Charger.

The Charger has been nothing but trouble with this new network, and I'm at my wits end trying to get it to play ball. I have it set on a 2.4GHz WPA-2 IoT network with the rest of those devices, including my Givenergy AIO. The AIO plays ball with this setup with zero issue, however the EV Charger simply does not.

When it's connected to the network, I can ping it from my PC and start charging from the Modbus protocol through GivTCP EVC, however it can't talk to the internet for some reason. I have spent hours verifying that the firewall is not preventing it from talking to the Internet, and I'm fairly convinced it can see the WAN as the AIO can with no issue.

Now, I'd be fine with only local control IF it actually held, but seemingly randomly (I truly mean random, no correlation with time of day, activity, commands etc) it completely disconnects from the network and needs a hard reboot (off at the breaker) to actually reconnect to the network.

I'm potentially leaving the country for a number of months soon, and I cannot leave my partner to deal with this issue. As the charger refuses to connect to the cloud, it means that I cannot set a schedule for EV charging, which means that there's a real possibility here that the car becomes unchargable at home, which would cost a fortune.

If anybody has any experience with Unifi or issue relating to the connectivity of the EV Charger, it would be greatly appreciated.

Is this new Wi-fi network using the same subnet addressing as before? how about DNS servers, are they the same? could they have been statically assigned on the charger to that of the previous router? I've seen some routers act as dns relays/forwarders.

How long ago was the network changed? Are you pinging the charger from the same subnet or using a different one? If using a different subnet and you can still reach it then it's most likely either DNS or access lists IMHO as it would have correct gateway details set in order to route between subnets and therefore the internet. If you are pinging from the same IP subnet, then i'd try a different subnet and check the default gateway on the charger. Is there anyway of resetting the network configuration or statically assigning an address/settings on the device?

With my Uni-fi I stick with DHCP for my IOT devices, including my AIO but then use reservations to ensure they get the same one each time, but I had a Zappi charger installed as that was supplied by Octopus so can only speculate in general troubleshooting steps.

So since that post I've factory reset the device, and like with my AIO assigned it a static IP. This is on a seperate IoT network that uses 10.10.x.x rather than the standard 192.168.0.x.

I thought I made some progress today as by deleting the charger from the account and then readding it, it briefly showed up as online and I got a notification from Givenergy that the charger had indeed been readded. Short lived though, as it quickly dropped off again.

I can ping the charger from my main PC which is on a different VLAN, and when I connect my phone to the same VLAN I can connect to the internet with no issues.

I set a static IP for the charger, as GivEVC doesn't like it swapping, however I've cancelled that provision until I get the modbus re-enabled (as factory resetting it shut it off). I'll see what it wants to connect as.
If this doesn't work, I'll set up a new Wifi with the old 192.168.0.x subnet to see what that does.

Stever I cannot thank you enough. After creating a new subnet of 192.168.0.x, the charger is completely happy. Don't want to jump the gun here, but I've been able to set a scheduled charge which is more progress than I've been able to make in weeks.

Now just to get the Modbus back.

well, I don't think I did anything, but happy to have provided inspiration!

It does seem weird that changing to a class c style 192.168.0.x subnet worked, I can't imagine why it would prefer a /24 subnet over /16 (or any other valid subnet) apart from poor/lazy design as any valid subnet you'd thought would have worked, unless you had the mask wrong on the 10.10.x.x subnet. This is why DHCP reservation can be good as it'll get the right settings to the device (as seen by your testing of a phone) and then ensures it doesn't change so you always know the address, setting a reservation is quite easy on the Uni-fi (presuming you're using the Uni-fi for DHCP and not relaying requests elsewhere).

Before I had my AIO/IoT deployment I used to be a baller (aka idiot) and have a /8 internal network 😃 now I have everything split out into multiple /24 class C subnets

[unknown] It does seem weird that changing to a class c style 192.168.0.x subnet worked, I can't imagine why it would prefer a /24 subnet over /16 (or any other valid subnet) apart from poor/lazy design as any valid subnet you'd thought would have worked,

Don't know about AIO, but (the dongle in) my hybrid is acting as an access point for its own network, on 10.something network, in addition to acting as a client on your home wifi. So maybe it can't work on another 10 network at the same time ? (The AP is how you connect to it to configure the home wifi connection.)