Mine has firmware 05.05, SDK Version 6.51.06 (=bootloader 13481) and it is running with “Z-Wave PC-Controller 5.30” and 5.38
Which SDK Version is shown in Z-Way? which UUID ??
Mine has firmware 05.05, SDK Version 6.51.06 (=bootloader 13481) and it is running with “Z-Wave PC-Controller 5.30” and 5.38
Which SDK Version is shown in Z-Way? which UUID ??
For folks who want to use the UZB Z-Wave stick with Z-Wave PC Controller 5.38.
Please note if your stick firmware has firmware 5.25 or 5.26 you’ll see PC Controller crash/exit as soon as it detects the z-wave stick. I was able to get it to work finally after updating the firmware to version 5.33 and also 5.34 with SDK version 6.81.01
Unfortunately the ONLY way to update the Z-Wave stick firmware is to download latest v3.0.0 of Z-Way-Server. While there is an older windows version 2.3.3, DO NOT use this as it’s outdated and cannot update your firmware.
Couple of things to note during this process
Unable to update data. /ZWave.zway/ZMEBootloaderUpgrade
when you try to upgrade from the UI.Cannot open device, permission denied
. Open a new console and type in sudo chmod 666 /dev/ttyACM0
EVERY time you see this error on the console running the z-way-server. This will be multiple times during the upgrades process (after each upgrade)Extract here
. It’ll extract all the file into a folder called z-way-server
sudo chmod 666 /dev/ttyACM0
, keep this terminal openLD_LIBRARY_PATH=./libs ./z-way-server
. The server should start and it should detect the UZB stick controllerlocalhost:8083
, it’ll ask you to create a password and login, skip the instructions/introlocalhost:8083/expert
, this should open the expert pages from where you can update your firmwaresudo chmod 666 /dev/ttyACM0
, it should allow the z-way-server to now read/write to your stick again. If the server times out (after 5 retries), no worries, just shutdown the z-way-server (Ctrl + C) and then restart it again with the command LD_LIBRARY_PATH=./libs ./z-way-server
and it should detect your stick again (don’t close the browser window!)I hope this helps folks and they won’t have to struggle the way I did
Very interesting that there are two different latest firmware versions. While @leif has version 5.36, the version of @hunnypuppy is 5.34.
Only out of interest: which bootloaderCRC do you have now?
Mine is 48059.
You will get this, when you are in above mentioned window (post #35) and then click on “Show controller data”
Hi,
there is a chance to brick the UZB-Stick when updating the firmware. I got this answer in the zwave.me forum bricked device zwave.me forum
Sorry to inform you, but there is a known issue in some UZB manufactured by our partners on license base that after upgrade they become bricked.
I will try another one
Update: 2nd device also bricked when updating from 5.27 (preinstalled) to 5.36 using
zway 3.0 on raspberry.
best, ypoosn
bootloader 40196 and the firmware doesn’t show me any options to upgrade beyond 5.34
/: None (09:46 AM)
nodeId: 1 (09:46 AM)
homeId: -771274748 (09:46 AM)
SUCNodeId: 1 (09:46 AM)
isPrimary: true (09:46 AM)
isInOthersNetwork: false (09:46 AM)
isRealPrimary: true (09:46 AM)
isSUC: true (09:46 AM)
SISPresent: true (09:46 AM)
libType: Static Controller (09:46 AM)
SDK: (09:46 AM)
ZWlibMajor: 6 (09:46 AM)
ZWlibMinor: 2 (09:46 AM)
ZWLib: 1 (09:46 AM)
ZWVersion: 6 (09:46 AM)
ZWaveChip: ZW0500 (09:46 AM)
APIVersion: 05.34 (09:46 AM)
manufacturerId: 277 (09:46 AM)
vendor: Z-Wave.Me (09:46 AM)
manufacturerProductType: 1024 (09:46 AM)
manufacturerProductId: 1 (09:46 AM)
bootloaderCRC: 40196 (09:46 AM)
firmwareCRC: 18024 (09:46 AM)
capabilities: 2,3,4,5,6,7,8,9,10,11,16,17,18,19,20,21,22,23,28,32,33,34,35,36,39,40,41,42,43,44,45,46,55,56,57,58,59,63,65,66,68,69,70,71,72,73,74,75,76,77,79,80,81,83,84,85,86,87,88,94,95,96,97,98,99,102,103,120,128,144,146,147,152,180,182,183,184,185,186,189,190,191,208,209,210,211,212,238,239,242,244,245,247 (09:46 AM)
controllerState: 0 (09:46 AM)
nonManagmentJobs: 0 (09:46 AM)
lastIncludedDevice: 0 (09:46 AM)
lastExcludedDevice: 0 (09:46 AM)
secureInclusion: true (09:46 AM)
oldSerialAPIAckTimeout10ms: 150 (09:46 AM)
oldSerialAPIByteTimeout10ms: 15 (09:46 AM)
curSerialAPIAckTimeout10ms: 10 (09:46 AM)
curSerialAPIByteTimeout10ms: 10 (09:46 AM)
countJobs: false (09:46 AM)
memoryGetAddress: 25856 (09:46 AM)
memoryGetData: 157,4,70,104 (09:46 AM)
memoryManufacturerId: None (09:46 AM)
memoryType: None (09:46 AM)
memoryCapacity: None (09:46 AM)
functionClasses: 2,3,4,5,6,7,8,11,18,19,21,22,23,32,33,34,35,36,39,41,42,43,44,45,57,58,59,63,65,66,68,70,71,72,73,74,75,76,77,80,81,82,83,84,85,86,87,94,96,97,98,99,128,146,147,186,190,208,209,210,211,242,243,244,245 (09:46 AM)
functionClassesNames: SerialAPIGetInitData,SerialAPIApplicationNodeInformation,ApplicationCommandHandler,GetControllerCapabilities,SerialAPISetTimeouts,GetSerialAPICapabilities,SerialAPISoftReset,SerialAPISetup,SendNodeInformation,SendData,GetVersion,SendDataAbort,RFPowerLevelSet,GetHomeId,MemoryGetByte,MemoryPutByte,MemoryGetBuffer,MemoryPutBuffer,FlashAutoProgSet,NVMGetId,NVMExtReadLongBuffer,NVMExtWriteLongBuffer,NVMExtReadLongByte,NVMExtWriteLongByte,ClearNetworkStats,GetNetworkStats,GetBackgroundRSSI,RemoveNodeIdFromNetwork,GetNodeProtocolInformation,SetDefault,ReplicationReceiveComplete,AssignReturnRoute,DeleteReturnRoute,RequestNodeNeighbourUpdate,ApplicationNodeUpdate,AddNodeToNetwork,RemoveNodeFromNetwork,CreateNewPrimary,ControllerChange,SetLearnMode,AssignSUCReturnRoute,EnableSUC,RequestNetworkUpdate,SetSUCNodeId,DeleteSUCReturnRoute,GetSUCNodeId,SendSUCNodeId,ExploreRequestInclusion,RequestNodeInformation,RemoveFailedNode,IsFailedNode,ReplaceFailedNode,GetRoutingTableLine,GetPriorityRoute,SetPriorityRoute,RFPowerLevelGet,SendTestFrame,SetPromiscuousMode,PromiscuousCommandHandler,WatchDogStart,WatchDogStop,ZMEFreqChange,ZMERestore,ZMEBootloaderFlash,ZMECapabilities (09:46 AM)
softwareRevisionVersion: v2.3.3 (09:46 AM)
softwareRevisionId: 25bdd65bc580b075ba69b766a4113866403c0036 (09:46 AM)
softwareRevisionDate: 2017-04-13 21:53:20 +0300 (09:46 AM)
uuid: f0a57bf559c4a1aa19a89c1f7a9cf3ef (09:46 AM)
caps: 0,0,255,5 (09:46 AM)
frequency: EU (09:46 AM)
deviceRelaxDelay: 15 (09:46 AM)
statistics: None (09:46 AM)
backgroundRSSI: None (09:46 AM)
channel1: 173 (09:47 AM)
channel2: 179 (09:47 AM)
channel3: 127 (09:47 AM)
RFTxFrames: 0 (09:46 AM)
RFTxLBTBackOffs: 0 (09:46 AM)
RFRxFrames: 0 (09:46 AM)
RFRxLRCErrors: 0 (09:46 AM)
RFRxCRC16Errors: 0 (09:46 AM)
RFRxForeignHomeID: 0 (09:46 AM)
priorityRoute: None (09:46 AM)
dstNodeId: None (09:46 AM)
routeType: None (09:46 AM)
speed: None (09:46 AM)
hops: None (09:46 AM)
homeName: (2019-07-30)
homeNotes: (2019-07-30)
5.34 seems to be OK (based on your steps). But now it isn’t active anymore.
Probably you went: 5.27/40196 --> 5.33/40196 --> 5.34/40196
And @leif went: 5.27/40196 --> 5.36/40196
See here:
You can also view them (active or incative) here.
I don’t want to confuse anyone here, why the 5.27, 5.33, 5.34, 5.36 are now shown as “inactive or hidden”, probably only zwave.me knows it. (6-7 weeks ago, they were “active”).
But (above picture) is the only plausible explanation why some have 5.34 and others 5.36.
Hi Leif
Id like to do the backup of an Aeotec Z Stick, but it says the command isnt supported on the stick?
Is this possible?
Regards
Kris
Were you using the Aeotec app? If it says that the stick doesn’t support it, I’m going to guess that it’s not possible. The Aeotec sticks use ancient firmware if I remember correctly.
Sorry I was using the Silicon Labs to backup, but the Aeotec App does the job! Works Thanks!
Anyone found a way to do a backup with the Aeon backup tool via command line? I’m already running OH on Windows so I was hoping to automatically do a backup occasionally in the middle of the night. Just recovered from a corrupted stick without a backup and want to avoid that going forward. And a backup isn’t a good backup if it requires manual intervention to do it
If you were able to do that you would need to shutdown OH, backup, and then restart OH which would need to rediscover all the zwave devices. I find many of my battery powered devices need to be woken up manually to get fully discovered.
Who said a backup isn’t a good backup if it requires manual intervention to do it? I don’t agree with this statement at all. A backup isn’t a backup if it never gets done, but that’s not the same thing.
Realistically, how often do you really make changes to your smart home controller once it’s set up and running? Certainly the rate slows way down. If you haven’t made more changes, another backup is superfluous or even undesirable. As long as you make a backup once you’ve got things up and running, and some time after you’ve made some additions, I’d think you should be fine.
That reminds me – it’s time I make another clonezilla image of my openhab system.
For god know what reason, I never reach the stage where I can say, “I finally got things up and running”. I simply change to much all the time
But I agree with you about the backup anyway.
It seems to work just by stopping the Z-Wave binding and then starting it up again, which can be done via the console. I’ve seen some latency between starting the z-wave binding and battery devices being detected, but I haven’t had an issue with data being reported or the battery-based buttons not working, etc… when they should be.
Maybe I should rephrase to “backup strategy”. It could be that I’m just not disciplined enough, but a manual backup schedule for me usually looks good for the first month or so then there starts to be large gaps. I just can’t keep up with it. And this results in not meeting my recovery point objectives when a failure actually happens. The sentiment is directed more towards things like file systems, etc… but I still try and apply it wherever I can when I know something needs to be backed up… especially after recently having a z-stick have corruption issues and not having a good backup.
I probably add/remove a device at least once a month. I’m in a place in life where I don’t get that much time to work on home automation due to kids and other family commitments, etc… So often times I just get things working and don’t necessarily want to/have the time to take things down again to do a proper backup in the waking hours. I’d much rather have a script that stops the Z-Wave binding once a month at 2:00am, does the backup, and gets everything going again. That costs me some time to write the script, but no time going forward.
Wouldn’t it be nice if that image backup was automatic?
Things are up and running, but I’m always wanted to add more devices/functionality!
Does this statement imply there’s a better USB zwave stick to use than the Aeotec one? I’m based in the UK and as far as I know the Aeotec one is the only USB one available. Though I do admit I haven’t really looked for any others since I got an Aeotec one. Is there an alternative with newer and “better” firmware?
@chris is our Z-Wave expert and lives in the UK. Since he develops our binding I would consider his opinion quite definitive.
I personally prefer the UZB stick:
I’ve been able to successfully clone one stick to another and successfully run my system from the clone with no other modifications.
I have one of the Aeotec stick (initially bought one Aeotec and one UZB) and then bought three more UZB sticks as backups and in anticipation of the needing them in the much larger house I’m currently building.
What is it about the UZB stick that you prefer? Have you noticed it performs better in any way?
I have two Aeotec Gen 5 sticks and have also been able to gone one to the other. A very useful feature.
The UZB is physically much smaller than the Aeotec, less expensive, there’s no flashing colour LED light, and the firmware seems to still be developed. There might be more differences but those were enough for me to buy more UZBs as opposed to more Aeotec’s. YMMV, to each his own.