Like others here, I was experiencing a lot of the issues mentioned in various threads, such as DHCP reservations being ignored, and the "The configurations of device ER7212PC are different from the configurations from the controller.” error, despite making changes slowly, and on a local level, not through the Cloud, as well as an issue where Ethernet-connected clients randomly lost their IP addresses, and could not be assigned new ones, even after reboots of all Devices, and the clients in question.

I thought that I’d detail what issues I experienced, and how I set everything up again, in case it might help someone, and if anyone sees anything I could improve on, I’d be delighted to hear.

I’ve also listed the "interface annoyances” (not bugs, honestly) that I found with the Omada software, and issues that I’ve seen with particular clients’ interactions with the LAN.

 

LAN hardware:
1 x ER7212PC V1.0 PoE router with integrated Controller - (PPoE WAN connected to ISP’s FTTH termination unit)
1 x SG2008P V3.20 PoE switch - (serving 4 x PoE CCTV cameras and a Synology NAS/NVR, to keep excessive CCTV traffic off the uplink to the switch)
3 x EAP-615 Wall(EU) V1.0 - (connected to the router, to keep excessive wireless client traffic off the uplink to the switch)
Various other wired and wireless clients, about 30+ in total.

 

I had upgraded the switch from (I think) V3.0.4 Build 20221130 to V3.20.1 Build 20240115 and it was then that the DHCP reservations began to be ignored (may or may not be connected), and a few weeks later on, the "The configurations of device ER7212PC are different from the configurations from the controller.” began to appear (again, may or may not be connected).
I then upgraded the router from (I think) ER7212PC(UN)_V1_1.0.2 Build 20230202 to ER7212PC(UN)_V1.6_1.1.2 Build 20240102 (note that the newer version was from the hardware version 1.6 page, because it says that Vx.0 can take VX.6 & Vx.8).
The issues became much more frequent, with the addition of another issue where some, both Ethernet and Wireless, clients randomly lost their IP addresses, and could not be given another one - They still appeared in the client list, but with a dash in the IP address field. Removing the DHCP reservation and IP-MAC Binding didn’t help.
The local connection that I had to the router then failed (possibly my client desktop lost its IP address?) The only way I could access my router was to use my phone on 5G to see it through the cloud connection on the Omada app.
I connected my desktop to my phone’s access point and downloaded the latest version of V1.0 firmware, reset the router (and the switch) back to factory settings, connected my desktop to the router with an Ethernet cable and was going to load the V1.0 firmware when I took a look at the build dates and realised that they were probably the same. I found the previously-downloaded V1.6 firmware in my downloads folder and confirmed that they are identical (they occupy exactly the same number of bytes on the hard drive). So I didn’t bother reloading the firmware, but began to set up the LAN again.

 

I set up the Management LAN on 192.168.0.1/24 with all devices’ IP addresses assigned by DHCP.
I connected the switch and adopted it.
I then added a number of LANs with different VLANs - Main Client LAN on 10.0.2.1/24, with VLAN 2 - CCTV on 10.0.3.1/24 with VLAN 3, & a Guest LAN/VLAN, an IoT one and a VPN one in the same format.
Each LAN has a DHCP pool of 10.0.x.150-254, so the 10.0.x.2-149 section is available for static assignments.
Only some of the LANs have a WLAN/SSID, and they were given the same VLAN, eg: Main LAN has an SSID also on VLAN 2, but the CCTV cameras are PoE, so no WLAN is required.
I set all relevant router and switch ports to the correct VLANs and then reset the three EAPs to factory settings and adopted them again.
The SSIDs were the same as before, with the same passwords, so many clients came back online by themselves, but others needed to joined again.

When I had all clients connected, I exported a client list as a CSV file, and re-sorted it by Network and MAC address, to give a basic order to the list.
I then changed the final octet of each client IP address at the top of each network to 10.0.x.2 and used the Excel autofill function to give the ones below the next sequential address (10.0.x.3, 10.0.x.4, etc.)
With the proposed DHCP reservation list made this way, I went between the Omada Client List and the Excel spreadsheet and set each client to use its assigned static/reserved address in the correct Network/VLAN. I also changed or added a recognisable Client ID string where needed.

I didn’t reboot all of the clients, but left everything overnight to confirm that they ended up with a 10.0.x.2-149 (static) address, and had dropped the DHCP 10.0.x.150-254 version.
I then went to Settings > Services > DHCP Reservation to confirm that all (30+) clients were listed there, and had the static IP address they were reserved.
I also set up some Gateway ACL entries to prevent the IoT & Cameras networks from accessing the others, but allowing the others to access them.

 

Interface Annoyance (bug): While the Client List remembers the setting for how many clients are shown per page, the DHCP Reservation page always falls back to 10/page, meaning the user with 11+ clients has to pick from the drop-down. every. single. time. 
After a few days, I was happy that all (actually most, see below) clients were retaining their chosen static IP addresses. When I was happy that all entries looked correct, I exported them to the IP-MAC Binding table - I clicked slowly, and waited for the “Succeeded” banner at the top of the screen each time, and never got the "The configurations of device ER7212PC are different from the configurations from the controller.” error, like I had before the rebuild, even though I had waited for the banner then too.

 

Interface Annoyance (bug): The same problem with the page-table falling back to 10/page exists on the IP-MAC Binding page too.

 

Interface Annoyance (bug): Despite copying and pasting the Client Name string into the Description field in each DHCP Reservation entry, the Description string is no longer copied across to each IP-MAC Binding entry, meaning you get a whole table of meaningless MAC & IP Binding entries with no way of knowing which client is which. I had to refer to my Excel sheet to enter each one manually to avoid constant cross-referencing in the future. The previous firmware version used to copy the Descriptions perfectly.

 

Client Issue: IKEA Dirigera hub gets two identical IP addresses.
The IKEA Dirigera smart home hub is only officially mentioned as having an Ethernet connection, but a recent firmware update has turned on the built-in wi-fi radio, which has an (almost) identical MAC address to the Ethernet one (only the last character is different), but there is no reference to Wi-Fi in the IKEA Home smart app, or any IKEA documentation, and so it is impossible to turn off. This wouldn’t be an issue, except that if the hub is also connected by Ethernet, it receives the same IP address on both connections.
It doesn’t matter whether you set static or DHCP addresses for either the hub’s Ethernet or the Wi-Fi MAC address, they both get the same IP address.
If you set different static IP addresses for each MAC address, the Wi-Fi one is ignored, and both still receive the Ethernet’s IP address.
I presume that this is breaking the router’s ARP rules and causing trouble, so I disconnected the Ethernet cable, but then the hub receives a DHCP IP address, despite the DHCP Reservation being set for a static address.
Apart from that, everything seems to work fine, despite the Wi-Fi connection not officially existing.

 

Client Issue: Apple HomePod Mini’s fall off the WLAN every day or two.
If an iPhone has the “Private Wi-Fi Address” function set ('Wi-Fi address' is Apple’s term for MAC address), it uses a different MAC address for each WLAN it connects to (to help prevent device-tracking by online advertisers). This doesn’t seem to impact the iPhone’s connection on TP-Link LANs, and the DHCP reservation works fine for it. However, the HomePod Mini’s on the LAN that are administered (through the Home app) by an iPhone with this privacy setting turned on seem to also change their MAC address randomly (according to numerous threads online), which causes them to be unable to access the WLAN.
Turning the Private Wi-Fi address function off on the iPhone (when connected to the SSID that the HomePods are on) seems to make the HomePods much more stable on the network, presumably because they no longer change their MAC addresses. However, the iPhone’s DHCP reservation is then ignored, and the phone receives a DHCP-pool IP address (despite the reservations & IP-MAC Binding entries being deleted & re-entered with the new MAC address that the iPhone adopts when the Private Wi-Fi address setting is deactivated. However, this is no issue for the phone’s use, and makes the HomePods much more reliable, so is a good solution.