[App][Pro] Zone Memory - Save and Restore Device Configurations

I have nearly 60 Hue bulbs and accessories and the thought of moving them away from Hue Hub is not something I want to contemplate. Being able to use Hue Scenes is essential and seems to not upset Homey, being able to update firmware strikes me as important too. And the Hue zigbee mesh is borderline bomb proof.
Athom support tell me they are working on improvements with their Hue integration, I suspect that Hue bulbs are the most widely used so it would be crazy to not improve this. Fact is now the Athom Homey app can see the Hue scenes, they are listed, it just gets confused as to where to apply the scene.
I have sent them a big email this morning, and they have been quick to reply in the past.

Hue scenes and updates to the Hue devices were also reasons for me to use the Hue bridge.
As I said before, I am currently moving all my Zigbee devices to the ConBee II USB stick.
The Hue Essentials app (this app supports both the Hue bridge and the ConBee II USB stick) generally lets you create scenes and update device software. But since I haven’t transferred the Hue devices yet, I can’t say at the moment if you can update the Hue devices and use scenes in Homey Flows.
I will let you know when I know more though.

The Zigbee mesh (stability, range) seems to be comparable with the Hue bridge. This is also reported by other users.

But this is all OT, sorry @Shakesbeard.


Did you solve this?
I have a similar problem for restoring a single device.
It works fine if the light starts off as on. My first flow saves the state of the light. My second (triggered by the completion of the save) changes the light to white 100%.
Another flow simply restores that light.
As I said this works fine if the light was on at time of save. If it is off then it correctly turn the light off but does not restore the colour so the next time the light is turned on it is white 100%.
Advice would be much appreciated.

1 Like

Hi @Bellringer2 and @Johan_van_Dijk ,
actually, it should not matter if the light was on or not when saving. Did you check your onOff behaviour in the restore cards?
Also, if the problem persists, I would like to have a look at the data.
For this, reproduce the problem and right after that generate a diagnostics report for the app.
To do so, go into the Homey app menu “More…” -> “Apps” -> “Zone Memory” -> hit the little gear icon and from there the button create diagnostic report. Please include your forum names in the message field there so I can see which one comes from which user.
I will have a look at the log data and see if I can make out any issues or get clues from there.


Diagnostic report as requested. 3789cf86-6ec2-400a-a2dc-27895ba994b1

Thanks for your help with this.


Peter Bayly

1 Like

Thanks for the report. This might need a bit more detailed investigation.
Could you try changing the command rate setting on the restore card. Basically the fastest rate would be okay, just not instant/all at once. Let me know if this changes the unexpected behavior.
It is just a suspicion as the app’s output seems good. Except for the order of commands. Something seems a bit off, maybe.

1 Like

I already tried this and it made no difference.

I also tried one card which ignoring the on/off behaviour and then followed by a separate card using as stored on off behaviour. Still left the light as white when it was turned back on.

Hi there,
something here does not make sense. You said, when saving the light was turned off.
This matches the data seen. But according to the data from the light, it is in color mode.
However, according to the restore log the state is restored exactly like that without issue.
The setting is being confirmed by the Homey setCapabilityValue api. No errors.
Maybe this is a limitation of the light app you are targetting. Do those light support change of the parameters whilst being turned off?
In generel the restore of the onOff status is updated as very last setting for every device.
If you ignore the onOff on restore, then there is simply no update command send for it.

In other words, this here is accepted by the target app without errors:
{ name: ‘dim’, value: 1 },
{ name: ‘light_hue’, value: 0.69 },
{ name: ‘light_saturation’, value: 1 },
{ name: ‘light_temperature’, value: 0.52 },
{ name: ‘light_mode’, value: ‘color’ }
{ name: ‘onoff’, value: false },

According to that data, the light should come up in a bright color. Whatever hue 0.69 is.
Does the light change to this color if you ignore the onOff command?
If not then there must be a bug in the target app.

On a different note: I have seen api errors for the day before the day you created the report. Looks like there is a communication error. Either caused by overstressed Homey, bad network/internet connection or unresponsive target app.

evening. I disabled my flows with Zone Memory because something isn’t working. if light was off before it was not being turned off on restore and if light was on first the restore does not restore hue. I have just reenabled with the commands send rate set to 40/s

Morning, and further update. Homey updated to firmware RC53 last night and my flow with Zone Memory works again…
Also wondering whether it’s worth while updating the Athom Hue app to the bleeding edge test version

That’s quite interresting. Maybe the actual problem was caused by something on the route over zigbee or the hue app then. Let me know if you see any strange behaviour again.

Maybe this is also relevant for @fantross to know.


Thank you so much for looking into this so thoroughly.

So I think you are saying that the colour is being restored prior to the on/off state.

In that case when the light is turned on again then it should be the restored colour (in my test Magenta) but it is not. Instead it comes up white which was the interim colour I set it to after the save and before the restore.

Perhaps the make of bulb has something to do with it. For the record this is an Innr GUI 10 bulb linked directly to Homey Zigbee.

Let me test this more thoroughly and on different makes of bulb. I’ll also choose a different interim colour to see whether white is a default setting.

This may take me a few days but I will get back to you with what I’ve found.

Yes, your assumption is correct. Technically the light state is restored before sending the onoff command. But how the target app or device reacts to those messages highly depends on that app or device. (In any case, some lights like LIFX support changing the settings without turning the light on some not, very brand and app dependend really)
Hence why I added the command send rate setting as some devices/apps cannot handle too many commands at once.
You could also try using the slowest command send rate and see how the device behaves. The commands are executed in the order you see when doing inspect in the app settings for the dataset with the exception of onoff. That is explicitly always send as last update command.

Let me know what you observe. Am quite curious about this.

Ok. I got a chance to test this.

It seems to be very definitely brand related.

I set up the exact same scenario on an Ajax zigbee bulb and it worked as expected with no requirement for a delay.

I did change the speed to the slowest on the Inrr bulb but that didn’t solve it. I think I observed that it did dim to the previous level before turning off but never changed colour.

I also tested my Lidl bulb and that worked ok once I used the smallest delay in command rate.

Very peculiar that a very cheap bulb from Lidl performs better than one from Innr.

Anyway got to the bottom of it now and once again thanks for all your help.


Peter Bayly

1 Like

Todays report.

TLDR: I don’t think that Zone Memory is able to see the current values of all devices when it needs to

I set a scene in the hue app, wait 10 minutes just to make sure that settings have filtered through to Homey, then run a flow which does nothing more than Save State of Devices In Zone, and just the lights, everything else set to “no”. If I then inspect the dataset the lights usually, but not always, have the same values for Dim/Hue/Saturation/Temperature. This flow was created because…

I had a flow which switched on the lights and then set Dim/Hue/Saturation/Temperature and which then a Then card which Save State of Devices In Zone. The purpose of this was to use the saved dataset to restore the state of those lights in that zone after one of a couple other flows had run, flows which changed the state of one or more bulbs in that zone. The dataset created might have saved the correect values 50% of the time.

However Homey is communicating to Hue and vice versa is likely what is creating the problems. I use Hue bulbs etc via Hue Hub and not using Homey Zigbee.

Sometimes a few minutes can go by before a bulb’s state is presented correctly in Homey app so presumably Zone Memory is not able to see the correct state either. Or at least as part of a flow unless a large delay is input.

Is there any way to edit the dataset in Zone Memory?

I am looking forward to when Homey can use Hue scenes properly, apparently it is coming but no idea on timetable.

Yes. That is correct. Zone Memory basically uses the same data source as the Homey app. It would see the data the Homey app sees only. I don’t have any Hue or Zigbee devices at all, so cannot test it myself. Thanks for sharing this observation.

1 Like

At the moment this is not possible. I have been asked this a few times now but I am uncertain how to implement that. The easiest way to implement that would be offering a text editor with the raw data been saved. That would not be the most user friendly approach but at least give the possibility.


@Philip_Montgomery and possibly anyone interrested in editing datasets.
I been thinking back and forth but there is no really good solution without implementing a complex user interface.
However, soon v2.1.0 will go live. I replaced the quite limited popup message inspector with an inline inspector.

So, the actual question would be, whether people would be fine if that inspector would allow editing of the raw data it shows. If so, I could enable it to write the data back, but only with limited logic checks.


would be interested in having a go as it would still be very useful for having lights put back to their previous state after a temporary change.

I have had issues with saving state of a parent zone that has multiple children.

The main zone is called ”Home” and has multiple rooms/zones in it. And the flow only has lights enabled as stored values.

The error message i get is:
Cannot read property Homey of undefined

But when i chose a children as source object it works ok? every children has been tested ok, main parent zone does not contain any devices.

1 Like