MySensors EEPROM save/load Position

[sghazagh]

Hi guys,
I have created a sensor which working fine with my Controller.
I also have implemented webserver on my board (Wemos D1 mini Pro) to have control on sensor over the web as well.
So it gives me option to access to the webserver on the board directly to control the sensor if for some reason controller was offline.

For my webserver, I made it dynamic and saving SSID, Password and static IP, Gateway , Subnet Mask addresses into the eeprom start from position 0 and uses up to address 205.

I also need to save and load MySensor relay state on eeprom. So, i have set the position to save on location 206 (one bit after my webserver settings).
But it always writes on position 0 so it mess up my settings on that location.

Can you please guide me why the "saveState(206, message.getBool());" does not save the status on address that I have specified?

Note: I also use "loadState(206);" to retrieve the status. It also reads it from same position that saveSate eas used. (So it's working but my webserver settings does get mess and will not have proper values if I use load/saveState function)

Hope I could explained well!
Many thanks,

[Yveaux]

@sghazagh the address parameter to saveState() is only a byte. Internally this address is increased as the library also uses some eeprom space.
My first guess is your address of 205 plus the library offset become too large to store in a byte and therefore the address wraps, starting at 0 again.
IMHO the library should at least check for overflow.
Could you enter an issue on github, so we can track this?

[sghazagh]

@Yveaux : Many thanks for your reply.

I don't think if it overflow. from 206 to 256 all are spaces which the MySensor can use unless it's hard coded to start from 0 or something like that.

I don't know if MySensors writes something on eeprom without our request (unless we ask for 'saveState' or other commands uses eeprom), otherwise, that's not good, as we need to maintain the eeprom space by our applications and it makes conflict.

I will post it on GIT as issue and hope the proper answer comes up.

Thanks again,

[Yveaux]

@sghazagh said:

I don't think if it overflow. from 206 to 256 all are spaces which the MySensor can use unless it's hard coded to start from 0 or something like that .

I wouldn't be so sure if you do the math:
https://github.com/mysensors/MySensors/blob/master/core/MySensorsCore.cpp#L409

And

https://github.com/mysensors/MySensors/blob/development/core/MyEepromAddresses.h#L85

[sghazagh]

@Yveaux : It gave me a clue!
In file EepromAddress.h I found this:

#ifndef MyEepromAddresses_h
#define MyEepromAddresses_h
// EEPROM start address for mysensors library data
#define EEPROM_START 0
// EEPROM location of node id
#define EEPROM_NODE_ID_ADDRESS EEPROM_START
// EEPROM location of parent id
#define EEPROM_PARENT_NODE_ID_ADDRESS (EEPROM_START+1)
// EEPROM location of distance to gateway
#define EEPROM_DISTANCE_ADDRESS (EEPROM_PARENT_NODE_ID_ADDRESS+1)
#define EEPROM_ROUTES_ADDRESS (EEPROM_DISTANCE_ADDRESS+1) // Where to start storing routing information in EEPROM. Will allocate 256 bytes.
#define EEPROM_CONTROLLER_CONFIG_ADDRESS (EEPROM_ROUTES_ADDRESS+256) // Location of controller sent configuration (we allow one payload of config data from controller)
#define EEPROM_FIRMWARE_TYPE_ADDRESS (EEPROM_CONTROLLER_CONFIG_ADDRESS+24)
#define EEPROM_FIRMWARE_VERSION_ADDRESS (EEPROM_FIRMWARE_TYPE_ADDRESS+2)
#define EEPROM_FIRMWARE_BLOCKS_ADDRESS (EEPROM_FIRMWARE_VERSION_ADDRESS+2)
#define EEPROM_FIRMWARE_CRC_ADDRESS (EEPROM_FIRMWARE_BLOCKS_ADDRESS+2)
#define EEPROM_SIGNING_REQUIREMENT_TABLE_ADDRESS (EEPROM_FIRMWARE_CRC_ADDRESS+2)
#define EEPROM_WHITELIST_REQUIREMENT_TABLE_ADDRESS (EEPROM_SIGNING_REQUIREMENT_TABLE_ADDRESS+32)
#define EEPROM_SIGNING_SOFT_HMAC_KEY_ADDRESS (EEPROM_WHITELIST_REQUIREMENT_TABLE_ADDRESS+32) // This is set with SecurityPersonalizer.ino
#define EEPROM_SIGNING_SOFT_SERIAL_ADDRESS (EEPROM_SIGNING_SOFT_HMAC_KEY_ADDRESS+32) // This is set with SecurityPersonalizer.ino
#define EEPROM_RF_ENCRYPTION_AES_KEY_ADDRESS (EEPROM_SIGNING_SOFT_SERIAL_ADDRESS+9) // This is set with SecurityPersonalizer.ino
#define EEPROM_NODE_LOCK_COUNTER (EEPROM_RF_ENCRYPTION_AES_KEY_ADDRESS+16)
#define EEPROM_LOCAL_CONFIG_ADDRESS (EEPROM_NODE_LOCK_COUNTER+1) // First free address for sketch static configuration

With quick calculation I think the first free address would be 157? correct? (can you please check and see if you come up with same result)

If thats the case, then I have to rewrite my code and fit them from address 157 to 256. What do you think?

[Yveaux]

@sghazagh I can't do the math right now (on phone) but you are probably right.
Are you able to fit it all in these remaining bytes?
It's a pity the address is passed as a byte, as it restricts the total amount of eeprom addressable. On Esp8266 eeprom is emulated in flash, which is way bigger than the eeprom on Atmega328, for which this interface was designed.

[sghazagh]

@Yveaux
I have shifted the saving address from 0 to 10 and it seems that it is working now.
I have updated the GIT so a guy is looking at it.
It definitely has some conflict with address between 0~10 as all other data saving somewhere else can be restored properly!
Still don't understand why mysensors writes something on these addresses!!!

[tbowmo]

@Yveaux

And on the Sensebender Gateway (and on Sensebender Micro Mk2) the eeprom is 4Kbytes.. Perhaps we should change parameters for SaveState()