I personally think that every device, needs to have a default. That said, sometimes the most sane default is, in fact, it’s prior state.
If I leave the air conditioner running so the house will be cool when I get back from the shop, I’d rather like it to not be turned off because we had a brown-out two minutes after leaving the house (has happened to me more than once). Now, the controller and it’s current scene settings should take care of that, so the edge node just needs to come up “safe”, and then emit it’s assumed state.
There is also an argument, for instance, to having hallway or stairway lights default to on — also, as well as post-blackout recovery, if the network just fails and they can’t be controlled, then having them turn on just in case is better than falling down the stairs.
The flipside as you point out, though, is not being able to control things during a blackout. But then, I’ve lost count of the number of times I’ve forgotten to switch regular lights off when going to bed during a blackout, and wished I could have certain things with soft-ons’ come back on by themselves (like the afore-mentioned air conditioner on a hot summers night). There’s also a moderately simple solution to that, which I’ll get to in a bit…
This default is a function already on my TODO list (and in fact, semi-planned out) for adding to my gear, and something that it would subsequently shove into its EEPROM so it remembers on power-up (as opposed to current state, while I leave in the MQTT server).
You bring up a complication for the default, though (the reason it’s still only “semi-planned”); I do use retained states as a matter of course — which was actually the original reason for the single-topic method I am using — which then need a little smarts to not simply override the default. When an edge node comes online, it automatically gets a replay of the last command(s) it was sent directly from the MQTT server — for my ledstrip, that’s on/off, brightness, pattern, and auto-cycle delays (of which there’s two; the main one is actually off and a cron script ticks it over manually because I didn’t yet have a controller of any kind when I started the project, the second kicks in when the network is down — but isn’t presently preserved over restart so defaults, it just defaults to 10 minutes). On and off, I would agree have cause for default behaviour. But brightness and the autocycle settings, I would very much like to be retained from last time. So even there, if the device is non-trivial, the answer isn’t nearly as straight forwards as “just have it always start off”.
Likewise, which state should a garage door default to? If there’s a load of stuff in your garage and a door into your house, it should default to closed, but if it’s detatched and empty (or we’re talking about the driveway gate instead), maybe it would be more convenient to have it default open, and then the controller can close it when it comes up — sure, the garage/gate will open and close any time you have a brown out, but it might be better than getting home and not being able to open the door because the controller failed to restart.
So in my plan is two extra flags; whether to accept or ignore that retained state over the default, and whether to assume the default in cases like simple network failure. (And I’m trying to avoid my OCD telling me to do a timeout — as per the ledstrip — too…)
Since I haven’t set up external access to my automation yet, I implemented something else that just happens to work for blackouts, also; Email, SMS, and I’m also playing with having my online web server — sitting as it is nice and safe in a Google data center — host the front-end instead of my own systems. This means so long as someone in the house has a functional mobile phone, I can issue commands to be run automatically when the system comes back up (such as switching to the “goodnight” scene I use now).
Right now for default behaviour, I presently just use the MQTT server’s retain flag (I think I mentioned that in my other thread?); the restart default will be the last retained value, so if I just don’t retain commands during regular use, the default will be the one persisted. Though, that seems a little fragile, not the least because I also only retain values for two weeks… On the controller end, it’s fine, because devices don’t control devices directly anyhow — the controller gets in the middle so it can be configured to retain, or not (and in fact, it always retains the default setting, but not the non-default). The device however, some of them have local or alternative controls, and so their own reflection of such out-of-band inputs needs to be retained, or not, as appropriate — and this is where strictly using the MQTT server as default storage completely falls down (as well as the network-down default, of course). But there’s still five bits left in that planned byte, so it’s all good.