thorrak / brewpi-esp8266

An implementation of the BrewPi device code on the ESP8266, ESP32, and ESP32-S2
GNU General Public License v3.0
82 stars 30 forks source link

Option to manually configure a "true" static IP address, no automatic DHCP network configuration infrastructure required #112

Open robc-km opened 1 month ago

robc-km commented 1 month ago

An option for the "Manual Network Configuration" of network parameters. Not just the SSID and WiFi key, but also the IP Address, Network Mask, Default Gateway, and DNS server(s). This could well be a valuable debugging tool, saving the developer much time. It would take the users automatic network configuration infrastructure out of the equation, allowing the developer to much more easily determine whether networking issues are caused by the controller or the user's network configuration infrastructure.

Automatic Initial Network Configuration: For the user who is not sure what network configuration parameters to manually enter into the controller, and the developer who is not confident the user knows what they are doing, a related/alternative debugging feature would be an "Automatic Initial Network Configuration" switch. This switch would permit the controller to initially obtain it's network configuration, as it currently does, by "Automatic Network Configuration" means, for example using the LAN's DHCP server, but then to remember those initial network parameters and to continue using them without any further contact with the initial automatic network configuration infrastructure, in this example, the LAN's DHCP server.

Ideally, all three modes of network configuration would be available to the user, and thus also to the developer when determining the root cause of a networking issue: 1) "Automatic Network Configuration", as the controller currently, 25th May 2024, gets it's network configuration. 2) "Manual Network Configuration" 3) "Automatic Initial Network Configuration"

Notes: a) If either options (2) or (3) are left in place as a permanent controller configuration then the user should lock the controller's hardware, MAC, address to the controller's IP address in their automatic network configuration infrastructure configuration, i.e. their LAN's DHCP server configuration, so as not to cause future networking issues, like for instance duplicate IP addresses on their LAN.

b) From my limited knowledge of the code base I suspect that mode (3) would be the easiest to implement and this alone could well be a big help to the developer in debugging networking issues.

thorrak commented 1 month ago

Hey there!

The network configuration is set using a third party library which I do not control, and thus unfortunately I’m somewhat limited in the changes I can introduce here. With that in mind, accepting Option 1 already exists, here are my thoughts on Options 2 and 3:

Option 2 is a pretty standard configuration, and is one which is definitely supported by the controller. I had thought this was exposed by default but it might not be. I will take a look at the code later and see if this is exposed - and if it isn’t, see if it can be. I will use this issue to track against this work.

For option 3, unfortunately that’s against best practices for a DHCP-controlled network. If the device with the “static” assignment is ever turned off or otherwise disconnected, the DHCP server could assign the IP to a new device since it would be in the DHCP range, and it wouldn’t know not to. Any users who would want to set this likely are savvy enough to also be able to set a static DHCP assignment on the server which is the better way to go about doing this. While the upstream library could always implement this, I would guess it’s highly unlikely - nor would it be something I would recommend they attempt.

robc-km commented 1 month ago

Hey there John,

Thanks for the quick reply, for brewpi-esp8266, fermentrack and thorrak_hardware they've all been extremely useful to me.

I've had a very brief look at tzapu's WiFiManager, and unfortunately did not notice a way to expose any functionality to solicit static IP address parameters from the user. No handy little toggle to enable suitable user input fields, perhaps alongside the SSID input in the web AP interface, nor in any other obvious place. I hope I've missed something! However, there is this method:

wifiManager.setSTAStaticIPConfig(ipAddress, gateway, networkMask, dnsServer)

which sets up a static network configuration for station mode. A trivial example of it's use is here:

examples/Old_examples/AutoConnectWithStaticIP/AutoConnectWithStaticIP.ino

Note that the dnsServer is an optional field.

If this method is an appropriate way for you to implement option (2) "Manual Network Configuration" then, of course, networking parameters would still need to be solicited from the user. And, as the configuration is set using a third party library outside of your control, then perhaps it would be appropriate - once the controller is up and running using the already implemented option (1) "Automatic Network Configuration" - for the user to enter the static network configuration parameters using your own web interface to the controller?

On your controller's web interface you have already graciously provide us users with the very handy pages "Set Up Sensors/Actuators" and "Controller Settings". Static network parameters could be entered under "Controller Settings" with the current DHCP obtained network parameters being displayed on the "About Controller" page. Or, perhaps more appropriately, another page called something like "Network Configuration" could present the user with the current DHCP obtained parameters and the ability to alter them, submit the changes for storage in non-volatile memory and, perhaps restart the controller.

I agree 100% with your comments about having a statically assigned IP address in the DHCP allocation range is not best practice ... unless they are locked to their device's hardware (MAC) address. Please see Note (a) in my initial post, I think we are in agreement.

BTW, I always enter all my LAN's statically allocated IP address interfaces into my DHCP server configuration even though they "should" never contact the DHCP server, but locked to their hardware addresses. This way if ever a machine happens to unexpectedly boot looking for a DHCP server - initial machine setup, testing a new software builds, wrong BIOS settings (PXE), flat BIOS battery, bootable USB stick or bootable CD left in the machine by mistake - then the machine will be allocated the same "static" IP address by the DHCP server. Appearing on the LAN with that same "static" IP address that it's always had, exactly where I can find it without having to look for it in the server logs.

Thanks again for your software, and PCBs.

Cheers! Rob