BosseB:
Good suggestion!if (webConfigServer.hasArg("fixedaddress"))
ConfTmp.fixedaddress = 1;
else
ConfTmp.fixedaddress = 0;
or ConfTmp.fixedaddress = webConfigServer.hasArg("fixedaddress")
My struct is defined as such:
typedef struct __attribute__((__packed__))
{
unsigned int checksum;
char sta_ssid[32];
char sta_passwd[32];
byte addr[4];
long baud;
unsigned int tcpport;
byte mode; //WIFI_OFF = 0, WIFI_STA = 1, WIFI_AP = 2, WIFI_AP_STA = 3
byte wichannel; //Channel number to use 1..13, if set to 0 then do not configure (use auto settings)
byte hidden; //AP SSID hidden or not (hidden = 1)
byte fixedaddress; //Use fixed address in STA mode instead of DHCP
char updateuser[20]; //Login for the web firmware update function
char updatepwd[20]; //Password fr the web firmware update function
byte numsensors; //How many DHT sensors are supported (0..4)
unsigned int dhtinterval;
char host[12]; //For setting the network hostname
char ap_ssid[32]; //Separate storage for AP SSID
char ap_passwd[32]; //Separate storage for AP passwd
byte reserved[57]; //For future expansion
} ESPConfiguration; // Size: 256 bytes
So the fixedaddress member is a byte item.
Can the direct assignment you showed work in such a way, since the fixedaddress is not a boolean?
(I might be influenced by Pascal's need for specific type definitions in order to not allow the shooting of ones foot...)
Looked up the C definition of bool and it is an unsigned char in most cases with values 1 or 0.
So I did as you suggested and it works just fine.
Now I added a reset function too with password check and it works fine except for the response page not showing...
Here is the code for my reset handler:
void HandleResetModule()
{
String value;
//First check password!
value = webConfigServer.arg("save_passwd");
if (value != ConfTmp.updatepwd)
{
SerialDebug.println("Wrong password, send error page");
webConfigServer.send(200, "text/html", PWD_ERROR_HTML);
}
else //We have a valid password, so send confirmation and restart!
{
SerialDebug.println("Correct password, module resetting");
webConfigServer.send(200, "text/html", RESETTING_HTML); //<== This is not showing up!
delay(100);
ESP.restart();
}
}
How can I delay the restart so there is time to send the response webpage?
A longer delay or some other solution?
set a flag variable and do the reset in loop
I created a flag and set it in the handler for the reset command page.
But it still just resets without showing the confirmation page.
So now I have this code in loop():
bool Resetflag = false;
// The loop function is called in an endless loop
void loop()
{
//Other stuff
if (Resetflag)
{
delay(100);
ESP.restart();
}
}
And in the reset handler I have this:
SerialDebug.println("Correct password, module resetting");
webConfigServer.send(200, "text/html", RESETTING_HTML);
Resetflag = true;
Same behavior, the reset is performed but the webpage does not show up in the browser.
try longer delay
I used a different approach to ensure that loop() would execute a number of times after the flag was set:
bool Resetflag = false;
unsigned long resetwait = 0;
// The loop function is called in an endless loop
void loop()
{
//Other stuff
if (Resetflag)
{
if (resetwait == 0) //First time here
resetwait = millis(); //Get start time
if((millis() - resetwait) > 1000) //Wait 1000 ms
ESP.restart(); //then reset
}
}
This made the page show up before the module reset.
And this reminds me of another web update related issue I have had:
I added the ESP8266HTTPUpdateServer library about 8 months ago or so in order to have a web update path for the firmware. I did not change much, basically only the texts on the webpage it uses.
It worked but it nagged me that when I used it to update the firmware then the web browser always showed a timeout or not found error (don't remember which now) when it was done and the unit reset.
According to the readme it would send an acknowledge page, but it never showed up for me.
I eventually moved the web update function into my Windows config application so as not have to use a web browser and be irritated by the display problem...
Seems like it is a similar problem as the one I have discussed here....