Bootstrap device state from the cloud?

One question I had was, when the device turns on and bootstraps, does it bootstrap the current values from the cloud? Wondering if an idea like that has merit? You could argue that on startup the device should get its current state from the cloud, right?

I have a beta device and it is not bootstrapping from the web, so I would like to have the discussion on if this should happen or not?

I answered one version of this here:

But I actually wasn’t perfectly clear on what “bootstrapping from the web” might mean to you? Could you elaborate on what info you imagine being transmitted?

I think we have the same idea on what bootstrapping from the web means, at its simplest form to sync state of the pins for what the api knows to be the most recent state. I guess that means that the api would have to store that state too, is that something you are already doing?

I am on the fence on if it should sync or not. For devices that use the api to set those values then it is something that is necessary. If the device use local input to set those values, then you could argue that the state should be stored locally to the device and should not be overwritten by the values in the cloud (this assumes there is some memory available to maintain the state locally). It almost seems like cloud sync is something that would need to be set optionally?

Cool. Yeah, I think it should be optional, and I look forward to hearing more discussion about this possibility.

We are not currently storing the state in the cloud. We do log the messages that come through the server, but we don’t know what code is running locally on the Core that might have changed the state.

I think it would help to describe some use cases here… then we can wrap our heads around why anyone might want to store the state of all the I/O.

Personally I’m having a hard time with it, because if you are stashing the I/O state in the cloud, the presumption is you are going to be disconnecting from the cloud and powering down. Possibly a sleep mode. If that happens you don’t have power so you can’t hold the state of the I/O locally. If when you power back up you retrieve the last known state of all I/O and set it… that sounds ok so far, but then your app is going to be running and making decisions again about how to set the I/O anyway. So I’m thinking all you really need to do is save your state variables that help you decide what to set the pins too, i.e. EEPROM memory. I would think the Spark Core has local EEPROM though, so … that leads me back to… what other use cases I’m not thinking of?