gmag11/EnigmaIOT

Storing temporary node data into flash instead RTC

gmag11 opened this issue · 7 comments

gmag11 commented

@quangvankts asked in #11

How do I save complete nodes and gateway current data into flash (including shared key, valid status etc) so they can load it up, skip registration and exchange data straightaway after a cold boot (I know it only takes 200ms to register but I want to experiment how fast nodes can work)

gmag11 commented

Actually registration will be longer as several random delays are placed to avoid registration collisions.

You idea makes sense but I did no implemented like this for a couple reasons:

  1. This data is written on every packet to update message counters. If you use SPIFFS to write so often it may happen that it wears out too soon. Remember that each flash position may be written about 10000 times.
  2. Having session key on flash may reduce security in case an attacker have physical access to your device. Then key may be easily read. Then it may be used to decode commands and messages.

If you have all this in mind, it may be some situations that this may be a good idea, either.

Nodes that send a message not too often may be completely off to improve battery duration significatively.

Let me think if I can implement this with a parameter in begin call of as a configuration in EnigmaIOTconfig.h

gmag11 commented

I've added a new branch to implement this (https://github.com/gmag11/EnigmaIOT/tree/flash_storage)

@quangvankts Test it if you like. This feature is controlled by a parameter on EnigmaIoTconfigAdvanced.h

#define USE_FLASH_INSTEAD_RTC 1

If it is 1 context data will be stored on flash, if it is 0 it will be stored on RTC mem.

Storing data on flash adds around 10 ms to processing time

Notice that you should increase MAX_KEY_VALIDITY and MAX_NODE_INACTIVITY on EnigmaIoTconfig.h according message frequency.

Remember that flash may be stressed if messages are sent too often. Actually, I do not know how fast the flash would degrade. If you can sacrify one esp8266 flash module you may do a burn test :))))))

quangvankts commented

Thanks !
Yes I just want to try EnigmaIOT in a very specific case where timing and battery life is more important than security. So using flash instead of RTC is very helpful. I have some further questions:

  1. Does gateway need the same save RTC to flash implementation for this to work as well (in case gateway is not always power on) ? If yes can you add this to gateway ?
  2. Is there a way to save RTC to flash only after node registration is done, and not every time a message is sent if I don't use message counter ? (same for gateway)
  3. Will defining MAX_KEY_VALIDITY and MAX_NODE_INACTIVITY as -1 make shared key last forever ? If not how do I do so ?
gmag11 commented

Here my answers

  1. Gateway does not store node related data persistently, it is only on RAM. So, it it is restarted all nodes will have to reconnect again, what may take something between 1 and 10 seconds, depending the number of nodes that try to register at the same time.
  2. Not easily, Context is updated at least on every message because each one is tagged with a counter. I have included the possibility to disable counter but context is still updated. I may study if adding a condition can reduce the number of writes.
  3. No, but it is a nice idea. I'll check if there is any type conflict doing that. Having infinite MAX_NODE_INACTIVITY may force to reboot gateway if you remove a node from network. Adding a management panel on Gateway my be a solution but I'm really far from implementing that feature yet.

If you test last development successfully let me know to include it in next release. I've tested on ESP8266 and works fine. I have to do same test on ESP32 yet.

gmag11 commented
  1. I've noticed that this was already implemented. This requires that Gateway is compiled with counter checking disabled. You may use EnigmaIOTGateway.begin (&Espnow_hal,NULL,false); to start gateway in setup (). You need to do the same on every node with EnigmaIOTNode.begin (&Espnow_hal,NULL,NULL,false);.
  2. Commit 0a0d909 adds this feature. Setting MAX_NODE_INACTIVITY or MAX_KEY_VALIDITY to 0 makes them infinite.
quangvankts commented
  • 👍2
gmag11 commented

Integrated in main branch on release 0.9.5. @quangvankts Let me know if you find any bug.