Closed ryan-summers closed 5 months ago
However, the version bump may cause users to lose their flash settings.
There was a breaking change to the on-disk data format in 0.7, so yes this will break things.
Also, I'm very close to releasing v2.0 with some API changes that make dealing with the keys and values easier (and more straightforward). v1.0 is fine and without known bugs, so you can upgrade to that just fine if you don't want to do the refactoring. Going from v1 to v2 won't have changes on-disk.
@jordens I've worked around bus faults by instead writing an empty serialized value into the map, which gives us remove_item
-like behavior without needing to write flash multiple times.
@jordens I've worked around bus faults by instead writing an empty serialized value into the map, which gives us
remove_item
-like behavior without needing to write flash multiple times.
Oh yes. That sounds good.
The fix is pretty small to eliminate the double serialization layer. Will push it shortly after testing.
Fixes #861 by updating
clear <setting>
to actually erase the requested setting from flash memory instead of overwriting it with the current default value.This PR also updates to
sequential-storage
v1.0 by using embassy-futures to complete the async operations in a blocking manner. This shouldn't matter at all because the underlying impl is blocking anyways. However, the version bump may cause users to lose their flash settings.To test this, I cleared flash settings and rebooted the device. I then reprogrammed it with a new default broker of "mqtt2" and verified that the device used the new default of mqtt2 after reprogramming, which indicated that nothing was loaded from flash.