this does logically not make sense. In order to connect to the Particle cloud you need the WiFi on before that.
And WiFi.on() alone does not cause WiFi.ready() ever to become true. For that you'd need to call WiFi.connect() - or let Particle.connect() do that, but as said after you switched the WiFi module on.
Also this is an impossible condition
You can under no circumstance ever be still in the "trying to connect" to the WiFi network state but already connected to Particle cloud.
There is no need to convert event to String(). Particle.publish() will happily accept a C-string as is. And I'd use %.1f instead of full width floats via %f.
And your code is quite convoluted with all these Serial.println() lines. You can have the same thing happen with adding a set of \r\n at the end of any actual Serial.print() statement. And there is also a Serial.printf()/Serial.printlnf() that allows you to format your string like with sprintf() which helps reducing these mulit-line blocks of Serial.print() statements into a single line of code.
You may also want to add some sanity checks in your Particle.function() callbacks to guard against invalid command parameters.
You are also EEPROM.write()ing a float but that will give you wrong values in many cases as the second parameter is a uint8_t.
In your place I'd rather create a struct that holds your values and use EEPROM.put() and EEPROM.get() instead. That also reduces write cycles and hence flash wear.
I'm also not quite getting the use of this statement
The result of that is not 2000 but rather write_time so what is all that extra effort for?
When you put the values for Photon in, you get
I have learnt from you about my mistakes I made.And you are guiding me lot to get better day by day.I am very much thankful to you.
Yes the last statement āclearā should be changed.When I was calculating to erase the memory based on how much time I write to memory.Later I realized that so lenghthy statement was not required.I have changed it already.
One thing I didnāt get that you have told to perform some 'Sanity checks on Particle.function().This point I didnāt get Sir.
I would like to inform you that here in my Particle.function() I am providing upperlimit,lower limit and duration from CLI so the moment the values are sent the Device will reset automatically ,like I have used system.reset() function.Earlier to this whenever the new limit values were updated from CLI I was pressing the RESET butto manually.So to avoid this intervention I have used system.reset().I even tried by calling these Particle Function in void loop if so then no need to call 'system.reset() ā or press RESET button manually.But to avoid the read cycles I placed the code in SETUP section.
Since the command parameter for these functions is a string, you could send any "insane" string into your function resulting in a wrong value being stored in EEPROM. To avoid that and the possibly bad side-effects of that you should check the sanity of that parameter and only apply the value when suitable.
I gathered the intent of the System.reset() already, but I'd not see need for that.
You can apply the new setting without a reset too.
Just change the functions to something like this
const int minRefresh = 10.0;
const int maxRefresh = 3600.0;
int updatetime(String command)
{
int val = command.toInt();
if (minRefresh <= val && val <= maxRefresh)
{
refresh = val;
EEPROM.write(2005, val);
return val; // return the new value and carry on with that
}
return -1; // there was an error
}
Sir I have checked that whenever we use Particle.function() and send Commands since we are storing in EEPROM we need to RESET the device then only the new values will be updated.
If suppose I keep my Particle.function() prototype inside VOID LOOP then no need to RESET.This was the thing I found when I was trying to code the other day.I will try your method and check again Sir.
This s the difficulty I faced that passing command value into VOID LOOP so I used EEPROM.write() to save those commands and then read back them.This was my own logic.
But your logic is awesome Sir saving EEPROM write and read cycles.I learnt the way to think in this way too
Thank you sir.
When your variables are declared globally (=outside of any function declaration) you donāt need to pass the values around (let alone go via EEPROM) but when manipulated in one function all other functions will see the new value as soon they access the variable next time.
Nope it does not - that's another unsolicited change that could just cause other troubles. Why do you not just go with the answers you get?
That's all it needs for variables to be visible to all functions in the module.
Declaring a global variable static in C++ means that each module gets its own instance of the variable which might cause problems when you expect this variable to share the same value between modules.