-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interview of 'Secure' included devices doesn't complete #136
Comments
Secure interview is a very subtle thing. I suggest to do inclusion of secure devices right from Z-Way |
Sadly… That’s not practical in a zWave network AFAIK…
To include a device it has to be
1. Right next to the controller
2. Where it will actually live.
The controller isn’t exactly portable when using RaZBerry. And I have yet to get a device to include that was more than about 100mm from the controller. So that necessitates taking a portable (Aeotec USB stick) controller TO the device to include it… Fight with it for 30 minutes or so… Eventually get an inclusion (Some manufacturers seem better at this than others)… As z-way is licensed and I don’t have a license for the Aeotec it only runs on my RaZBerry…
Vera get round this by packing their devices with built-in batteries so you can unplug and carry around do the inclusion… Nice idea. My R-Pi2/RaZBerry isn’t like that… Maybe it should be, but the only portable pack I have doesn’t do piggybacking so thats not practical at this time either…
sigh…
… On 13 Dec 2017, at 10:15, Poltorak Serguei ***@***.***> wrote:
Secure interview is a very subtle thing.
I suggest to do inclusion of secure devices right from Z-Way
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#136 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARG0q0n1osoP4Kppj2OfBgsENC0EUpP3ks5s_6PMgaJpZM4Q_mt5>.
|
I am having the same problem. I have been trying to get the secure key from the vera into Zway and have not seen it completed. I initially thought it was a problem with the vera but it does not appear to be... |
Send us the log |
Would love to. Could you tell me exactly which logs you need? And what folder I could get them from as well as where to send them to? |
/var/log/z-way-server.log |
Looking into the logs when only doing the security interview, this is what I am getting. [2018-07-25 20:10:38.873] [W] [zway] Node 1:0 CC Security: secure channel not established by primary controller - skipping security |
This means your RaZberry do not have Security established by the primary controller. Is RaZberry slave? |
No actually it’s not. The vera is secondary and the UZB is primary in this case. I am running on vs 3.0.0 RC15. The vera was the original primary and I have shifter primary from the vera to zway. |
Please help us to solve this. Just need some explanation. So Vera was primary and you included Z-Way in it as secondary and shifted the primary role to Z-Way? |
Vera was primary. Included Z-way as secondary and then did a shift that is correct. At no time Z-way is able to join the network securely. I did exactly the same thing with openZwave with the same result. The only difference is that I can input the secure class key on openzwave. I cannot with Z-way. |
Just to check, Vera is using S0 or S2 security?
|
I believe it is S2 security but can't be sure. it runs on the latest SDK version. |
I'm having the exact same problem as described, and I have done something very similar: I used to have Aeon Labs Z-stick gen5 as primary (and only) controller on a Raspberry pi3 running OpenHAB. Then I wanted a second controller and included a Raspberry pi2 with a RaZBerry2 controller running Z-way. After that I switched the RaZBerry2 to be primary controller because I liked the "expert"-interface in Z-way better than the Z-wave-configuration possibilities in OpenHAB. I then included all devices again, but all devices with a "Security"-attribute has interview results somewhere around 97% because the "Security"-part of the interview never succeeds. |
This is because if you include RaZberry as secondary controller, it expects security interview from the primary to get the network key. But if the primary has not done that (I believe OpenHAB missed this), your RaZberry do not know the key. If you want to re-include all, please reset to factory default your RaZberry and then start over. Otherwise you can not use security. |
@PoltoS, While I agree with you on your assessment, I would like to insist on the fact that OpenHab (which uses openZwave as the backbone) gives the ability to set the S0 security key. I looked further into the zwave security and it seems vera uses S0 as well. It would be a great addition to Zway as for now we cannot get secure devices to migrate to Zway. |
Please send me the log of Z-Way during inclusion. This will enlighten the issue. We have tested and Z-Way can include another Z-Way securely. To be sure, you tried to just add Z-Way as secondary, not as primary (controller shift)? |
This shows up in the log when I try to force interview for the "Security"-attribute: I added Z-Way (RaZBerry2) as second controller, and afterward I shifted controllers, so Z-Way became primary (and running SUC and SIS). |
because my RaZBerry is fairly fixed in place, I have a second controller in my network. An Aeotec USB Gen5 stick. Very useful because it's portable.
Usually devices include (eventually - that's a whole other story). However after going back to z-way on the RaZBerry (I was running openzwave for a while) I've noticed that any device that is shown as 'secure' in the way interface never completes the interview. It's always outstanding for the 'Security' interrogation...
Both controllers have the same 'secure' key (Which is currently the default 0x00, 0x01, 0x02 etc) and both controllers appear to be able to talk to the devices (Mostly). And I get updates form the devices back to the RaZBerry and they get fed to openHab OK. But it's a little disconcerting that I can't get the interview to complete 100% for all those 'secure' devices.
The text was updated successfully, but these errors were encountered: