Depending on how homey stores is configuration you’re obviously right on that (I would expect it would simply be a yaml or json file with all the configuration? But then it would be relatively simple to implement even across updates (dump and apply during boot) so it’s probably in a different way)
But personally I am in the opinion that backup/restore options are infinitely more important than energy measuring/info (just my opinion. Other people probably disagree)
And Athom know that… so they make shire there best effort is in it… it’s ready when it’s ready 
It isn’t just homey itself that stores information though, the zwave and zigbee both have their own internal memory which need to be put back, and everybody knows the zigbee core is currently being rewritten, and creating a backup of something that is still being fully rewritten, not sure I would like that.
And I believe the same goes for the chip talking with the 433 MHz and IR chip.
I doubt that any configuration data is stored in the flash storage at all. I don’t know about the Z-Wave controller, but the flash storage on the Zigbee controller is purely meant for firmware only. Any other persistent configuration data is stored in the host (Homey’s core) and transferred via serial.
If you mean RAM in the chips then that is wiped at every reboot or power cycle. So that shouldn’t be an issue. Without any knowledge of zigbee or zwave chips (but being a Linux Engineer at an international financial organisation) I can’t imagine the chips themselves any other updatable data than firmware and some microcode.
Depending on what level of backup / restore functionality they are looking in to, updating shouldn’t be that big of an issue.
If I would make a design for a homey-like system, I would force a complete reconfigure from scratch based on a single config file at boot time.
But that’s just me of course 
Regardless of how I would do it, and regardless of how much effort it is to make a backup/restore function, I would prioritise that infinitely times to something as trivial (in importance) to Energy measuring/reporting. Energy is a ‘sexy’ topic of course, with the whole climate change thing in the media, but I don’t think that should draw the focus from core managibility of a system like homey.
This of course is just my personal and professional opinion, and I won’t keep nagging on the forum on this.
for z-wave every single device ever added to it (not just Homey) is stored in its memory (you’ve probably seen the messages of the “unknown devices”, but can’t delete them, popping up), not as extending as Homey uses/wants (just the Device’s Handshake and it’s unique ID, and device ID, which is different for ever inclusion you do), this is the same for zigbee, every device is stored in its internal memory, and linked to Homey’s internal (different) device ID, so stating “i doubt it stores any data there” then you should read up onto those subjects more.
and as i stated before, backup is most likely done by employees done different then working on the energy addition, you still can’t work with 5+ people on 1 type of implementation, just because you would do it one way, doesn’t mean that is possible at all.
I didn’t notice any restrictions during the weekend with such Flows till yet.
I am absolutely sure about it that Athom knows the priorities regarding stability of Zigbee and back-up and restore.
And as Brooks law says: adding manpower to a late software project…
Afin others finished a for some of us nice to have, Energy. So it is released, enjoy!
I think most users would like the following problems fixed before “new” Features:
Maybe it is only me but those problems give users major issues that frustrates the current users…
But fixing problems is stupid work it seems and not a sexy selling point like “Energy”
Athom not even inform users when or what is done about those issues, some of the issues are open for years…
I don’t see why you would want to post such a message. This has been mentioned over and over again in this topic. We all understand the frustrations and feel the same way, we all want a product that’s working properly and meets our demands. But repeating these demands does not magically complete the projects Athom has running.
Like @Dijker said, adding manpower won’t help.
Can we all please just get back to the topic at hand here? It’s not helpful for anyone if we keep on returning to the same (off-topic) subject.
What is off topic about updates/fixes in the topic about experimental firmware that adds updates/fixes?
It’s off-topic because the firmware update we’re discussing (v3.0.0) does not (yet) include back-up, a Zigbee rewrite or other requests people may have.
The correct way to get your requests to Athom (which is responsible for those things) has already been mentioned enough in this forum and I believe people have already sent in their requests. So why repeat ourselves here?
Don’t get me wrong. B&R is on the top of my priority list as well, but mentioning that in this topic won’t get me anywhere. Sharing information about the elements that are in v3.0.0 are usefull for both myself and other users. That’s why I would like to only discuss these topics.
Mentioning anything in this topic about any update will never get us anywhere since athom employees are not active on this forum.
It is a community forum to discuss about homey, and that is what we are doing here, nothing more nothing less.
Don’t get me wrong, i am a reasonable happy homey user since the first hour(kickstarter user) but it could be all much more enjoyable if things just work…
Like not having to reboot daily because of memory leak/bluetooth crashing or reading zigbee devices because they are suddenly lost by homey…
It seems we’re on the same page.
True, but does your comment really add to the discussion after all of the previous comments? Or is it more accurate to classify this as venting emotions (note how I avoided the word ‘nagging’ here)?
I would just prefer to solely discuss the actual update in the stores, rather than a future update that hasn’t been released.
You’re right to feel a bit dissappointed by Athom, but since we all (yes, me as well!) agree on that subject, can we please just give that a rest, or perhaps create a separate ‘There is no Zigbee rewrite yet’-topic?
That problem has been solved a few updates ago, if I’m not mistaken?
Sorry, don’t use Bluetooth, you’re probably right here
Never had that problem, like I stated earlier. Still genuinely wondering why I don’t see these problems and other people do, because I do have Zigbee devices.
And does it?
Never had issues with that before but last night the same (full) battery woke me up 2 times, showing 1%, then after removing and putting back in again 100%, then 1% again…
To Athom the Green factor is imminent as some Leads need to be attracted by that feature. It’s a bit astonishing as this small update is clearly only focused on prospects and not on the existing customer base (that did all the dirty work); serving their essential needs would’ve been a nice sign of appreciation to them. Well, I am not saying that this is a way to show something as well, but … 
Haven’t installed the beta yet, so I don’t know. I just like it 
What you’re describing with the percentage is ‘normal’.
Fibaro always resets the battery level after removing/inserting a battery.
So you remove and put back an old battery and it will say it’s at 100%. After it checks the voltage it will notice that it’s actually (almost) empty and report back the correct level.
Don’t wanna stay to much OT, but the battery is full though the energy level keeps reporting its empty.
Bummer.
However; I am waiting for the official release which was planned to be end of October, perhaps there might be some more fixes in the background (a complete update log might be somewhere available, listing ALL changes of 3.0 … is it?)
Have you reported this to Athom? If not, perhaps you could do so in order to help Athom find and fix these problems for yourself and future users 
Since this is part of the v3.0.0 update which is experimental, i’m guessing Athom would like to know about the problems that alpha testers like yourself are experiencing. So I don’t feel this is off-topic at all.
let me repeat something i’ve said before in this very topic about Fibaro devices and their battery reports.
To elaborate more, there have been many tests done, by Athom and some community members, and all came to the same conclusion (not just Homey’s received data, also 3th party sniffers), fibaro’s battery reports just sux, even if we ask the device every time it wakes up to send its battery status (Homey still does this!), it will ignore this +80% of the time just completely.
And Fibaro also has no interval or threshold setting for their battery level.
So conclusion is, it can’t be fixed by Athom.
Thanks for telling.
Nevertheless: the error never occurred to me and started to appear with 2.5.2, all out of the sudden.
