MQTT settings dont persist thru power cycle

[Jchuchla]

If the device is power cycled while in a state set by MQTT, the device will return to sACN mode and any set color will be lost. The MQTT values should be persisted in NVRAM so that the set color and on/off state is restored on boot.

[penfold42]

The flash chips have a limit on endurance typically 100,000 write cycles.

Are you happy with a lazy delayed write ?

[Jchuchla]

What exactly is a lazy delayed write? I'm thinking even if I were to change the two values twice a day, that's still almost 7 years worth of writes. I do often see writing the light/set and the rgb/set in succession. So maybe there's a method to wait a few seconds for both parameters to be set and then commit them all to memory. That would cut the writes in half and extend that theoretical write life out to 15 years.

--Jon Chuchla--

Sent from my iPhone

On Sep 6, 2017, at 4:20 AM, penfold42 notifications@github.com<mailto:notifications@github.com> wrote:

The flash chips have a limit on endurance typically 100,000 write cycles.

Are you happy with a lazy delayed write ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/forkineye/ESPixelStick/issues/67#issuecomment-327426485, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFkjQKjHN8InNmo6IAP3JmoU7xCOvJvNks5sfmPlgaJpZM4PN0TD.

[penfold42]

That I think we can do.

You could use Matt to change it every second and if we wrote it to nvram it would last a day.

If we only write a change when it's been constant for an hour it'll last for 10 years

[forkineye]

Let me think about this one for a bit. I could see some non-MQTT uses as well, so maybe a configurable power-on state would work. It would be a 3.1 thing though, just trying to squash the websocket bug so I can release 3.0.

[penfold42]

If we use spiffs I think we hear the benefit of wear levelling which will help with lifetime.

I suggest we use a mqtt.json file to keep state

[Moonbase59]

Hm. Do we need this? The MQTT broker is supposed to retain the values (if "retain" was set) and re-transmit to the device upon reconnect.

You might want to try with something like the Mosquitto client:

mosquitto_pub -h BROKER -u USER -P PASSWORD -t esps/2/set -r -q 1 -m '{"state": "ON", "color":{"r":255,"g":0,"b":0}, "effect":"Chase", "mirror":false, "reverse":false}'

(The -r flag says to retain the message, -q specifies desired QoS.)

---

Well, it should work like this, but doesn’ŧ. Let me investigate tomorrow. I suspect we don’t give the broker a unique device ID, so it will give us a random one each time. This means it can’t give us "our" retained messages next time. Should be relatively easy to fix, I hope.

[forkineye]

States are now retained in the MQTT broker and queried when reconnected.