As the title says, I just upgraded my USB z-wave dongle to the latest version provided by silabs and have booted it on the vera without having to do anything to my network. I was already running 6.81.03 before and so far, it seems to be working without any problem. Will report here if I find anything.
3 Likes
The major change appears to be the implementation of smartstart which would make device inclusion much easier.
https://www.silabs.com/documents/login/white-papers/introduction_to_z-wave_smartstart_091317.pdf
This feature would need to be implemented by the controller software layer though. Hopefully eZLO is looking into this.
1 Like
^^^ Yes, your very correct on this, I’d just like to point out that 6.81.05 SDK is the latest SDK however the latest Sigma UZB driver is v6.06. (which is included in the SDK).
Some will ask what is the difference?
The SDK is more than one driver, it includes other device drivers (each with there own version) other device files such as tech specs etc.
If any of these change then the SDK is updated to a new version, so it’s important to actually check the file you need has been updated.
For those who are not running V6.06, it’s worth while updating especially if you are using a version below 6.0.
Word of warning:
It i s possible to brick the UZB so be careful, also the update only applies to the Sigma based UZB other manufacturers such as Z_Wave-Me, Aeon and Fibario use custom FW, you need to obtain the correct driver from them.
Any Black Cat UZB users are offered a free upgrade, simply return the UZB to us, we will upgrade it for you and return it, shipping changes apply.
Something weird happened that I just noticed on my upgraded dongle: According to vera, it has lost it’s primary role. It switched from Master: NO, PRI: YES to now showing Master: Yes, PRI: NO.
It is a little annoying because it now prevents the vera from including devices. What is even more odd is that if I take the dongle and plug it into a PC. The Silabs PC controller shows that it is primary. I even managed to assign the dongle to be the SUC/SIS and included devices from it so it just means that I will be including devices with another tool moving forward…
Now the question is why does the vera not see the dongle as a primary and every other controller does. (I tested OpenZWave as well)
Oh boy. Your description… the first thing that jumps to mind is that this just smacks of testing a bitmasked response against a fixed value rather than masking off the right bits (e.g. if ( deviceflags == 8 ) {...} rather than if ( (deviceflags & 8) != 0 ) {...}).
Yeah not to mention that a SUC/SIS can only be assigned to a primary controller and now the vera shows Suc/SIS: YES PRI: NO… which makes no sense.
On the positive side, I will be including devices using my surface tablet from now on so the inclusion will be mobile. 
. I will just have to configure the devices on the vera afterwards.
I can also confirm the above failure with Vera Inclusion.
Works well with Homeseer, HASS, looks like you need 2 UZB’s one on older FW to include and the other on the latest.
Far from ideal, we will pull the latest SDK FW for Vera until a solution is found.
Edit: I’ve opened a Support ticket for this.
Update:
Support isn’t interested.
Vera doesn’t support the SDK
Looking very much like a change over to Homeseer
It doesn’t really bother me since it is a USB stick and I can unplug it, go do my inclusion on my laptop and then plug it back on the vera… But still, it is a bug. If I was to choose, I would go eliminate the luup reloads with the serial command queue first.
1 Like
I downgraded back to 6.81.03 and I am still observing the same PRI: NO problem though other controllers are seeing the stick as primary. It appears that the firmware upgrade somehow changed the NVM network database on a variable or a bit the vera reads and uses to determine primary but no other controller does.
Was just looking at Homeseer and found interesting that they call their SmartStick+ G2 the stick they loaded 6.81.03 on while zooz’s ZST010 ships with 6.81.02. The Zooz is not upgradable through the SILABS SDK though as it is not an OEM reference design on the firmware side.
There used to be an issue many years ago under UI5 where Vera could lose its Primary role - some setting somewhere gets corrupted.
You could “fix” it at the time by downgrading to 2.78 Z-Wave firmware from the UI5 UI and then running the “hack to convert 2.78 to 3.20”.
http://wiki.micasaverde.com/index.php/Migrate_To_Z-wave_version_452
IIRC the final part of that “hack” was to force Vera back to Primary, flipping whatever setting had gotten corrupted.
If you have a UI5 firmware image knocking around you can probably find the script that does it and see what it did …
Thanks… I looked into and unfortunately it isn’t very relevant. It is based on older firmware for older incompatible hardware. As I noted, the zwave network information and controller status is all recorded in the zwave dongle NVM. I (and apparently @zedrally tested the USB dongle on other controllers which see the dongle as primary without any issue. The “fix” you speak of is to modify the data on that dongle. I am more suspecting that this is a vera firmware issue.
I have now upgraded back and am running a full network heal. I am also watching my network performance by tailing my log:
tail -f /tmp/log/cmh/LuaUPnP.log | grep “tardy”
looking for network response lag.
Sure, point is that this “problem” has existed for years, Vera internally forgets that it’s the Primary which prevents it from Including / Excluding.
MCV support could rectify this by “flipping the setting” (I’ve seen this mentioned in many different emails from them throughout UI5 lifetime), or you could do that “hack” I mentioned to sort it yourself (back in the days where it would take weeks to get a reply from support).
Sadly a lot of this info has been lost in the mists of time 
What do you get if you query:
<state id="141" service="urn:micasaverde-com:serviceId:ZWaveNetwork1" variable="Role" value="Master SIS:NO PRI:YES"/>
<state id="85" service="urn:micasaverde-com:serviceId:ZWaveNetwork1" variable="Role" value="Suc SIS:YES PRI:YES"/>
I don’t know if you can directly write to that variable, but it wouldn’t surprise me to see them using that verbatim to allow or disallow Inclusion / Exclusion. After all, it wouldn’t make much sense to query the Z-Wave chip every time for its current Role status, you’d likely do that once at boot up or LUUP reload and store it as a setting in memory.
I can actually change that variable in the zwave device but it resets at every luup reload so I think the vera is querying the dongle at every reload. I have not tested an inclusion with that variable changed yet though. It just appears to treat the response from the dongle somewhat oddly.
I found a really old script on one of my UI5 devices /www/cgi-bin/cmh/trouble_report.sh
There’s a test in there to check for Primary role … all it does is awk /etc/cmh/zwave_version
RealPri=$(awk -F'_' '{print $9}' /etc/cmh/zwave_version | tr -dc [0-9])
[[ “$RealPri” -eq 0 ]] && WARNINGS=“$WARNINGS
ZWave Controler is NOT PRIMARY → Warning: Cannot add/remove any ZWave devices”
That also seems to still exist on UI7 (although I’m running several version back from latest).
UI5:
3.20-l1_r0_hdeXXXXXXXX_n1_s0_is0_o0_si0_rp1_su0_pr0
UI7:
4.5-l1_r2_hdYYYYYY_n1_s1_is0_o0_si1_rp1_su1_pr0
What’s your “rp” field show? Zero?
1 Like
Yup, My rp is showing 0.
Let me see when this file gets updated. If it does not update at every luup reload then maybe we have something.
Edit:
Unfortunately… the file gets overwritten at each luup reload… so the luup engine reads and overwrites it…
Would be interesting to know if that (or the service variable) allows Include / Exclude though.
Agreed. I will have to test this but have no new device to add at the moment… I may have some in the next week.
Can definitely confirm now that 6.81.05 causes problems on the vera. It intermittently drops serial communications apparently which leads to luup reloads. This is on top of somehow driving the vera to lose its zwave primary controller role which really, as I confirmed is a vera bug since a controller cannot be a SIS master without being primary.
Edit: Frequency of the problem goes from having the error once every 10-14 days on 6.81.03 to 1-2x a day on 6.81.05 on my setup.
As I read through the historical threads which predated me joining the vera bandwagon, I am now starting to understand what is going on.
Z-wave controllers can be in one of the following states:
- Secondary with no primary role. ( Master: No ; PRI: No)
- Secondary with a primary role. (Master: No ; PRI: Yes)
- True Primary being the SUC (static controller). (Master: Yes ; PRI: Yes)
- True Primary controller and ID server aka. SUC/SIS. (SUC/SIS: Yes ; PRI:Yes)
The problem with what was occuring before is that the vera firmware seems to not support SUC as its design predates the implementation of the Static controller and of the Static ID server. It only supports being in the case 1 and 2 and does not understand being in status 3 and 4. The problem is that the zwave dongle firmware by default will set itself in state 3 (this is not a bug, it is only the logical design) and it is what happened when I upgraded my firmware. The vera does not comprehend being the SUC Master and defaults to PRI: No. This is why one work around was to do a controller shift on the vera… basically forcing the vera to become a secondary controller by abandoning its true master role (SUC) in order for the vera to see the dongle as having a Primary role. Any state which has the controller as SUC or SUC/SIS can only be primary. The status Vera report (Master or SUC/SIS: Yes, PRI: No) does not exist in zwave definition and could cause disabling the ability of the vera to include/exclude zwave devices. This is another massive bug in the vera program…