Ruida controllers simply don’t employ a proper subnet for many networks. If you have a Class C network they will work fine. But for a Class A (Like 10.0.0.0), or Class B, or if you truly have a subnetted network, only a select few machines on the network will be able to communicate with the Ruida controller.
Basically, a Class C network (like 192.?.?.x) uses the first three octets to determine the network ID and the last octet to identify the host. Ruida is fine with this as it ALWAYS assumes a 255.255.255.0 subnet mask (which is STUPID BAD).
If you are running your Ruida controller on a Class A network with an address of 10.10.10.254 (for example), then the Ruida controller will always assume that the network ID is 10.10.10.0 (first three octets). This means that only hosts on your Class A network which share the same first three octets as 10.10.10 will be able to talk with the Ruida controller.
This is a Ruida problem which I was told (years ago) they know about. It is simply lazy programming on their part. I’m sure they are using some library-based TCP stack (they didn’t write their own from the ground up) and all they would need to do is allow the user to specify the appropriate subnet mask (instead of always assuming/applying 255.255.255.0 (/24).
I simply bought a little palm-sized, 2-port, $50 router, set up a single port-forward and NAT rule, and attached it to my laser so that all the clients on my Class-B network could talk to my laser. Now I just specify the IP address of my little router and everything works as it SHOULD. In effect I had to create a dummy Class-C network underneath my Class-B network just to work around the subnet FAIL with my Ruida controller. …and there is only a single host on that dummy Class-C network (My laser): https://forum.lightburnsoftware.com/t/anyone-know-has-the-ruida-firmware-ever-been-updated-to-fix-their-network-limitation/151129/9?u=evanevery