Joined the Hubitat USB Stick to my ST HomeID

🎬 Get Started
1

I was frustrated by the ordeal of migrating my 70+ devices, one at a time from my current ZWaveNetworkHomeID to a completely new one. I was well aware that the ZWave stick itself wasn’t limiting this, it was software. I decided to invest in moving the stock USB Stick to my existing ZWaveNetworkHomeID.

My existing ZWaveNetwork has at least 4 controllers, now 5: StaplesConnect, Aeon Z-Stick (paired to OpenRemote), SmartThings, and Wink… now Hubitat.

That’s a lot of extra work to remove each ZWave device from each hub. Probably it would be simpler to just turn them off for the migration then factory reset them and try to rejoin the Hubitat factory ZWaveNetworkHomeID that came on the USB Stick.

It took days! But, once I got it, it was done in 30 mins. (Minus the time for the Hubitate to discover all the devices… that’s an ongoing process and I cannot YET say it’s workable.)

Using VirtualBox, I created a Debian 9 virtual Linux box. I’ve never used/seen Debian before so I used a lot of bad words as my fingers typed Linux commands that aren’t the Debian flavor!

I had to download and install 6 packages:
libmicrohttpd12_0.9.51-1_amd64.deb
libopenzwave1.5_1.5+ds-4_amd64.deb
openzwave_1.5+ds-4_amd64.deb
libjs-jquery_3.1.1-2_all.deb
libjs-bootstrap_3.3.7+dfsg-2_all.deb
openzwave-controlpanel_0.2a+git20161006.a390f35-1_amd64.deb
Used the search box at:
https://packages.debian.org/search
to find them and wget to download each. Then dpkg -i to install them, one at a time (in that order.)

At the end, I was able to start the OpenZwave Control Panel via:
ozwcp -p 8888

Then browsed to that server’s IP and :8888 and got the Control Panel.
I entered the device name as: /dev/ttyUSB0 pressed enter and the original Hubitat USB Stick’s values populated.

I did an Initialize. I doubt this was needed, but it does clear out any pairings already done AND generates an all new ZWaveNetworkHomeID.

Finally, the important step:
I put SmartThings into Add a Thing (Include) mode and selected Receive Configuration (under Controller on the OZ Control Panel). The panel said it was receiving the config and crashed!!

restarted ozwcp -p 8888 and refreshed the browser and again adding the Device Name: /dev/ttyUSB0 it populated with MY ZWaveNetworkHomeID !!!

It rather quickly started populating the DB (discovering devices) which get added to the Memory ON the USB Stick. I gave it 10 mins or so to flesh out the DB, I could see it polling each device and getting the manufacturer names, etc.

I then killed the Control Panel and unplugged the USB Stick and put it back in the Hubitat.

When the Hubitat eventually rebooted and I could browse to it, a Discover Devices briskly populated Devices with generic devices.

I think all my Battery devices are not (yet) responding to the Polling that Hubitat is doing because I see (under Settings: ZWave) that there are a lot of DEAD devices with a red Reinitialize button.

I may still have a lot of work to do BUT it’s way less than half what I would have needed.

2 Likes
2

More details:

As root (because why not, it’s a temp server!)

wget http://http.us.debian.org/debian/pool/main/j/jquery/libjs-jquery_3.1.1-2_all.deb
wget http://ftp.debian.org/debian/pool/main/libm/libmicrohttpd/libmicrohttpd12_0.9.51-1_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/o/openzwave/openzwave_1.5+ds-4_amd64.deb
wget http://http.us.debian.org/debian/pool/main/o/openzwave/libopenzwave1.5_1.5+ds-4_amd64.deb
wget http://http.us.debian.org/debian/pool/main/t/twitter-bootstrap3/libjs-bootstrap_3.3.7+dfsg-2_all.deb
wget http://http.us.debian.org/debian/pool/non-free/o/openzwave-controlpanel/openzwave-controlpanel_0.2a+git20161006.a390f35-1_amd64.deb
dpkg -i libmicrohttpd12_0.9.51-1_amd64.deb
dpkg -i libopenzwave1.5_1.5+ds-4_amd64.deb
dpkg -i openzwave_1.5+ds-4_amd64.deb
dpkg -i libjs-jquery_3.1.1-2_all.deb
dpkg -i libjs-bootstrap_3.3.7+dfsg-2_all.deb
dpkg -i openzwave-controlpanel_0.2a+git20161006.a390f35-1_amd64.deb

ozwcp -p 8888

The VirtualBox setup works best if you install the USB stick and let the host OS find it. Then under USB, create a filter (to tell VBox to NOT let the host OS grab the device, let the VirtualMachine get it first.) There’s a button that shows the list of USB devices, you click the USB Stick, done. Remove the USB Stick and start the VirtualMachine. Anytime after it’s booted, plug in the USB Stick and doing a:
ls /dev
should show you a couple dozen devices, look alphabetically for "tty"
That’s what you’ll want to type in when the OZControl Panel runs.

I just tried it all over again from scratch, new virtual disk, new OS install, pasted in all the “wget” lines, Pasted in all the “dpkg” lines… fired up ozcp -p 8888 and after entering in the device I found via “ls /dev” - it worked!

Right now, today, this works… the more time there is between today and when YOU are reading this, the more likely the packages I pulled will be replaced and a pure copy paste of my lines won’t work. One or more patches will occur, I’m certain. But using the search box of Debian -- Package Search Results -- search will probably yield the same results.

naturally I’d love to have this marked OBSOLETE because the command got added to Hubitat.

2 Likes
3

We’ve looked at doing this, and know that’s it’s doable. It’s basically making the stick act like a secondary controller to ST, which gets all of the z-wave devices downloaded to it. There is one significant problem however, and that is the who’s-on-first problem. It appears that the way you’ve done this leaves the stick as a secondary controller to ST. Have you determined that it all works in Hubitat if you turn off the ST hub? If both hubs are on, then either can control those devices, and when doing so, the other hub will not know that has happened, leading to out-of-synch problems for automations.

2 Likes
4

In MY head, I’ve divided the problems you raise into two “piles.” On the Left is a pile of Migration issues that do get mostly remediated by this. On the Right is the problem of being a true secondary controller and that was not done in my case.

To my knowledge, no one offers a secondary. It’s entirely possible this is due to a problem with the underlying Sigma code. Maybe it’s: “been tried and it’s too hard, give up.” But my observation of what occurred via OpenZwave Control Panel (OZWCP) messages, the USB Stick is/was a primary. The delta between a so called primary and a so called secondary is largely historical I believe. Today’s pairing (secure, mesh) was not envisioned when the primary/secondary constructs were written. The USB Stick in my Hubitat is currently able to initiate a pairing. I have what appears to be, 4 (now 5) parallel primary controllers on my network. They completely ignore one another. There’s a Static Update Controller (SUC) definition too, and I suspect SUC and “secondary” are starting to merge conceptually.

Because OZWCP exposes a lot of the commands, yea, I probably could pop the USB Stick out of Hubitat, back into OZWCP, and get the latest batch of updates/pairings from one of the other controllers, then back into Hubitat. But then again, I’m the only one adding devices, and it’s significantly easier to just click New Device on each Controller these days. PLUS I can simply hold off adding new devices until my migration to Hubitat is complete. I’ve got the control to make the issues I’ve ignored to be non-issues… for ME.

Receive Config is a “demand” by any controller to get an up to the minute snapshot. Obviously that can be done primary to primary. Whichever primary I put into pairing mode before I click the go button in OZWCP for the USB Stick is the one that responds, of course. Again, making a SUC a bit ephemeral. I did not try the RequestNetworkUpdate command, so I don’t know if any of my Controllers envision themselves as the SUC. Thousands of commands I didn’t try include TransferPrimaryRole and CreateNewPrimary.

Going back to my two piles metaphor, migration tends to assume that eventually something gets shut. Many people here are hoping they can shut their SmartThings because of local processing. That eliminates “sync problems” from the list. My direct answer to your question: "all works in Hubitat if you turn off the ST hub? " is yes, Hubitat is still a primary. I’ve spent zero time exploring the purpose/need of a secondary. Like you, I’d just like the Sensors to tell ALL of my primaries their state. I can’t see that happening with battery devices, so I look to the controllers (more specifically the Apps) to do what the commands imply… go GET the state, not just look it up in a self-DB.

1 Like
5

While I’m discussing Migration, perhaps I will point out some GUI updates that might help.

As everyone knows, when you import the device list from “the network” what you get is a pure generic list of devices. Everything is a “switch” or even better, just a “device.” Because I’ve had to do this before, (4 times,) I keep an ordered list of every device ID and what I paired.

I have a file full of these:
81 51 Aeon MultiSensor6F (Guest Bath)

I want to, as quickly as possible, get through the generic renaming process. Unfortunately, using my example, a battery device, it did not show up as a Device after Discovery. Settings:Zwave Information shows a list of devices but most of the battery ones showed as DEAD with a re-initialize button. What’s missing is an opportunity to do the rename. What I need is the list of DEAD devices and walk through the house and click them while also doing the reinitialize.

Said another way, there’s two places to do a rename, under Devices, the live ones, and under Discover, occasionally there’s a name and it can be changed. I find a DEAD device, look it up in my list, walk to that device, click it’s button and click Discover Devices. Only then can I rename it. It would be great to allow rename more universally.

Along those lines, in Devices, the Device Network ID column is sortable. Click on it and the entire list is sorted. Perfect, but it’s not “sticky”. When I’m renaming, I want to go through them in order, but when I click one to rename it, and then try to go back, the display reverts to sorting on the name column.

The construct in the Device Discover list (when device names show) is great. I can rename it there and a small “save” button hangs below the field. Battery devices just don’t wake often/long enough to coincidentally be found in my experience.

I have 12 devices in my Device Discovery list. All look like this:
Found Z-Wave 3A
Initializing
I know what 3A is, it’s my Fibaro RGBW Controller. It’s sitting on the shelf in front of me. Hasn’t been plugged in in a year. But I can’t rename it. I have to bump into it every pass through and look it up.

Yea, I understand I’m the ONLY guy in the Hubitat universe with a 60+ device renaming task… but maybe soon I won’t be alone. :smiley:

1 Like
6

I understand. We will take a look at this.

7

Could this similar technique be used to view the Z-Wave mesh?

8

This technique is “Get the software that does what you need running, then use it.” :rofl: In my case, I didn’t know what software would do as I needed.

The Aeon Z-Stick has a button on it and a battery inside. You click it to go into Inclusion mode and I could then punch the button on another product’s GUI to do the join. So what I needed was software that “clicked the button” on the Nortek USB Stick. Zensys Tools would do it… but I never got it to see the USB ports on a virtualized Windows system.

OZWCP was my next choice and Docker seemed a good mechanism. Never worked for me. And so on… one brick wall after another. Finally I got something to work, and it was WAY easier than everything else I tried, and easier still than ANY of the recipes I found.

You’ll have to do the same… find the software that will display the mesh and display it in a comprehensible way. Then find a way to get that software running with access to a USB port with drivers to speak to the USB Stick.

I believe OZWCP has commands to query each node for it’s routing table. I think the map creation would then be manual, because you’d just get a giant list of node numbers from each node’s viewpoint.

My lifelong experience with OZWCP is about 10 minutes. :frowning:

9

I don't understand this statement. Per the specification, any certified Z wave controller that can act as a primary can also act as a secondary. (You can't go by what open Z wave does for this because that's all reverse engineering, it's not using the actual Z wave specification. It's missing a lot of parts.)

Under the specification, it's up to the secondary to continue asking the primary for status information after the original join. There are lots of certified controllers that do this. For example, vera does, and so does Homeseer. With the Aeon zstick, it depends on what software you are using to run it. SmartThings does not, but they also tell you not to use their device as a secondary. :scream:

1 Like
10

As far as I can tell, I have zero secondaries. I do use SmartThings as a SUC. I can’t really go by OpenZwave because I’ve only ever used it for approximately 10 minutes to run the action I described. When I did the ReceiveConfig in OZWCP I fully expected to demote something… I was, after all, adding a primary. Didn’t happen.

I agree that the spec, and probably the reality is, any certified ZWave Controller CAN be a secondary. In my experience, it has yet to be implemented in any convincing way. I think my larger point is “for what?” what’s a secondary bring to the picnic? The spec from 15 years ago might define them, but does the build out of a ZWave network today need one? The reality perhaps trumps the spec?

Multiple primary controllers that completely ignore one another functions OK. The problems occur when dealing with status. Independent primary controllers don’t exchange status. I consider my Home Automation to be done wrong if I MUST whip out my phone to do something. When my Home Automation is working, without the need for my phone, the incorrect status shown on my phone is a don’t care.

There’s a minor caveat in that the automation portion of the processes must work within that shoddy status environment. When I create a Rule that says “IF x is ON…” then the automation must go find out if X is on, NOT rely on an internal state value reflecting what it itself did, ever. If the Rule says “…THEN tun off Y” it needs to send the OFF command to the device and NOT use the local state value to optimize.

Given that a Secondary Controller is distinguished by it’s status accuracy, the real world test is to turn on a device and verify the status updates somewhere else. If any of my other Controllers saw the status change, it’s a secondary to the Primary I’m testing. Rinse, repeat. Using the next controller, I turn something on (or off) and determine if that state shows up on anything else.

I’ve had good luck with OpenRemote’s ZWave implementation to function in the shoddy status I have built. Core/Webcore can disable optimization and thus do well here in the Land of Shoddy. :slight_smile:

What is overwhelmingly true is there’s room for improvement and early adopting Hubitat might mean ideas are exchanged and implementations improve.

11

Again, I’m not quite sure I understand what you’re saying. Many zwave installations use secondary controllers. It’s a practical way to offload some of the computing requirements as well as to extend range. It’s the recommended best practices way for getting around the four hop limitation. For example, if you want to automate an outbuilding and you are using a platform other than SmartThings, you’d almost always use a secondary controller for that. Lots of vera and homeseer customers have run multiple hubs in a primary/secondary configuration for years.

It’s not done with SmartThings because SmartThings doesn’t do it well, but it’s definitely done. :sunglasses:

1 Like
12

When I decided to focus on joining my shiny new Hubitat to my existing ZWave network, it was due to my experience of joining my (then) shiny new Z-Stick to my StaplesConnect. Followed by my experience of joining my (then) shiny new SmartThings to both. Years apart, but still, I had the experience to know it Could be Done. Given the off the shelf nature of the Nortek USB Stick, I thought I had a pretty good chance of succeeding and after all, what was the down side? Just that I had wiped out my home’s ZWave network. That’s pretty much what all the other early adopters face anyway… exclude every device from “there” and include them in Hubitat and then via Virtual devices, mirror them back onto SmartThings.

In other words, I can only build what I can buy and cobble together. I invented my Land Of Shoddy the first day I added the Z-Stick to StaplesConnect. I’ve been working around the limitations every day since. There may well be a path I SHOULD have taken… a path with secondaries and no shoddy status. I didn’t do that. I have no experience there. I have good experience in what I’d suggest is 90+% of Hubitat early adopters face. A home with two primary controllers. :slight_smile:

2 Likes
13

I’ve tried to do the same thing. But something went differently for me.
I was able to join “stick” to my z-wave network. Device name and ID’s were populate in opzw. But after I moved “stick” back to Hubitat and ran discover device in Hubitat, no device were discovered…
If I go into settings , Z-wave information I see 67 z-wave devices. But I can’t do anything with them…

14

The stick knows about the devices now, but the devices don’t know the Node ID for the Stick. Put the Hub into Discover (Include mode) and go “click” each device so that they will converse.

On my Aeon MultiSensors, I have to “squeeze them” because the Action button is mechanically tied to the back cover… for wall switches and sockets/receptacles I run around and just turn them on or off. Door sensors, just open or close the door, all while the Hubitat is in Discover.

15

Can’t make Hubitat to find any device.
I installed Domoticz for Windows. Hard reset the stick, then did all over again. Stick received configuration from ST. Device populated into Domoticz, I was able to control them. Moved stick to Hubitat. In settings, I can see all devices, but can’t discover any. Process would be much easier if Z-wave utility would be incorporated into Hubitat…

16

Unrelated to your question, (since you hadn’t asked yet :slight_smile: ) I shut Hubitat and moved the USB Stick back onto OZWCP and was experimenting with trying to convince it to be a Secondary. I was unsuccessful, but during all of that time the logs were scrolling showing me conversations it was having with all of the devices. (Populating OZWCP with state and device info.) That’s 100% unrelated to what the Hubitat would do with the same DB living out on the USB Stick, but it does say the info was out there, ready to be used.

It’s getting to be more than a few weeks since I did the “join”… 17 days per the counter on this Thread… and some of the steps I took are getting fuzzy. Overlayed by yesterday’s stuff. :frowning:

But I don’t remember anything “outstanding” - meaning unexpected or different from what I was expecting, having done it 3 times previously. [StaplesConnect <-- ZStick <-- Wink <-- SmartThings <–Hubitat] I have since, shut down Wink and StaplesConnect.

I was expecting to have to “click” the devices to get them to start a conversation and that the Hub needed to be in Include.

17

Yes. I agree that DB is living on the USB Stick. But hubitat apparently can’t make any use of that. The way I see it, when I run discovery in hubitat, Stick go into discovery process, but there is nothing new to discover, stick knows all devises already. I’ve tried to create a virtual device and give it real network ID . Very similar to what would I do in ST to create new device manually. But unfortunately in Hubitat, device would appear on the device list, linked to a real device on Z-wave device list. But Hubitat can’t control device anyway…
I hope ability to add new device manually will be added in future updates…

18

There was a change made in the latest build that has the unintended consequence of making the device discovery for the z-wave devices populated by OZWCP not work. Please note the word unintended.

We know exactly what we did to cause this, and will have a fix in the next release that allows you to get those devices joined to the database. You won’t use Discover Devices to get them, but instead will be able to join them directly from the Z-Wave info page.

We are planning this for the next release.

5 Likes
19

Wonderful !:+1:

20

I would like to thank Bruce and all Hubitat team! I was able to join ST z-wave network with the Stick after 704. update.
@csteele But I can’t get any battery device to reliably report events to Hubitat. Unless I remove it from ST and join Hubitat…