Indigo Domotics

Umtauscher wrote:

and shouldn't be doing that why exactly?

If the underlying architecture for backing-up and restoring the Z-Stick is Aeon Labs' (protected) intellectual property, then others must be granted authority to use it. If Aeon hasn't granted authority, then its use is by definition unauthorized. It's my understanding that Indigo Domotics has asked for access and been denied and I think it would be a very bad business decision for Indigo to just go ahead and include it anyway. It would be taking another company's product and selling it as their own.

If other companies haven't been authorized to use Aeon's intellectual property, then they're stealing it.

Jay

https://community.openhab.org/t/backup- ... tion/33703

The last comment on there suggests OpenHAB have recently (he started talking about it in Sept 17) signed an NDA with Sigma about backing up.

May be worth a fresh approach?

Peter


Sent from my iPhone using Tapatalk Pro

much of the z-wave documentation is now public.
I haven't found the backup/restore yet.

http://zwavepublic.com/specifications

http://zwavepublic.com/downloads

I have a few more infos about the so called backup software.

The backup is a simple memory dump which is initiated via the serial api.
The backups seems so read the memory block 0x0000 - 0xFFFF and writes it into a single file via the api function NVM_EXT_READ_LONG_BUFFER.
The memory is read in a loop in blocks of 40 byte. The dump is 512K in size but in fact onyl contains the same block of memory 8 times.

The restore is made via the serial api function SUPPORT_NVM_EXT_WRITE_LONG_BUFFER
The restore wites the 512K of the dump file, but the stick only stores the first 64K.

This means the backup will only work as long as the memory map of the chip doesn't change.

I suppose the backup software that is implemented in the Vera 1 does the same, only for the Gen2. Since it's a simple memory dump, the 2 are not compatible, because they use different chips and firmware. I havent had the time to compare the Gen2 dumps with the Gen5 but since the Gen2 dumps only 16KB there should be a significant difference.

Nevertheless this backup is very helpful, when the hardware fails.

I have tested restoring a backup of the Gen5 to the UZB and it worked. As far as I can tell the resulting stick had all the properties of the doner stick .

Cheers
Wilhelm

We have not made any progress on that. It is still definitely on the request/ToDo list, but higher priority items get bubbling to the top.

lanbrown wrote:

matt (support) wrote:

We have made any progress on that. It is still definitely on the request/ToDo list, but higher priority items get bubbling to the top.

So you have received the authorization to accomplish this? That is encouraging.

Argh, sorry. I inadvertently omitted "not" from my statement. Corrected now.

Umtauscher wrote:

I think what he means is, that all device after the exclusion and inclusion process "forget" the previously configured parameters.

In my experience that's true. That is why I didn't want to rebuild my network. I am heavily using associations and would have to redefine them all.

I have updated my howto:
http://www.indigodomo.com/library/411/

@Jay
I think there are many HA software products which are able to initiate a backup of the stick themselves. I cannot see why your firm might not be able to accomplish this.
( Razberry, OpenHAB, Domoticz and others can do it)
BTW the UZB backup is compatible to the Gen5 so I think the command is built into the firmware...

Cheers
Wilhelm

Thanks Wilhelm for the great how to guide for migrating from aeon labs gen2 z-stick S2 to aeon labs gen5 z-stick.
I'm have now solved one of my greatest worries from the past years. Now I'm running the latest Gen5 stick and I can now backup my network.
I also have tried the procedure to restore from backup and I have a extra stick just in case.

Umtauscher wrote:

I think what he means is, that all device after the exclusion and inclusion process "forget" the previously configured parameters.

In my experience that's true. That is why I didn't want to rebuild my network. I am heavily using associations and would have to redefine them all.

I have updated my howto:
http://www.indigodomo.com/library/411/

Just a question on this. Did you ever find out why the 'shift' button is greyed out? No matter what I do, it is always greyed out. I even read the manual.

Sam.

I too need to migrate from an S2 stick to a new Gen5.
I have borrowed a windows PC (ugg) for this project and downloaded the instructions (thank you).

My first problem is that I cannot find the ZenSys Tool ZWaveController software anywhere. Can someone point me to it? Is it compatible with the latest and very paranoid version of Windows 10?

The closest I found was here but it may not be the current incarnation of the tool...
https://www.silabs.com/products/develop ... are/z-wave

I just found it here.
https://www.symcon.de/forum/attachment.php?attachmentid=21753&d=1373548171.

Cheers
Wilhelm

Umtauscher wrote:

I just found it here.
https://www.symcon.de/forum/attachment.php?attachmentid=21753&d=1373548171.

Cheers
Wilhelm

Thank You!

Very interesting thread, many thanks for sharing! I am also going to move to the Gen5 stick so I can backup my stick.

jay (support) wrote:

dduff617 wrote:

This is actually a large amount of work. We'll have to weigh the tradeoffs since implementing this functionality would require that we put off other things. We know that moving sticks is painful, but given the relative infrequency of having to do it, does it actually take precedence over added device support, new features, etc.

This makes sense Jay. Is there any way to programatically dump all the devices parameters and their values to the server log? This should allow a user to dump them before migrating to a new stick, then dump them again after the stick migration and do a file compare. Sure this doesn't removes the need for reconfiguring all the device parameters but it will make it a lot easier. Perhaps some devices might not even loose the configuration so they might remain unchanged.

lanbrown wrote:

The device parameters are on the device, not the Z-Wave USB controller; hence the name, device parameters. Indigo does set some of the parameters to what is required for the device to work with Indigo though. This is not on every Z-Wave module though.

I know that. But as others have mentioned on this post some devices reset their parameters when they get excluded and included into a new controller. So regardless of where they are stored you will need to set them again if you change controllers and they got reset. As Jay has said it’s not easy to do backup/restore them programmatically so I was looking for a way to do ease the pain. If the values of all parameters can be outputted to the server log before and after the controller migration via a script then one can simply do a file compare and identify the device parameters that need to be updated. Still you will need to update them manually but at least you have the list of changes.

A plugin/script could fairly easily dump the current settings for params that Indigo exposes in the device.

Any you’ve set manually would need reading from the zwave device manually/when it’s awake - though literally as I wrote this sentence I’m trying to recall if a plugin could waitTillWake if you let it run for 24-48 hours and just retrieve the params at that point - in which case this step is also simple to do.

And the follow-up would thus be the same on the new device, waitTillWake then set params.


Sent from my iPhone using Tapatalk Pro