My migration from Vera, or what I did on my holidays
-
SRT321 now accepts setpoint so that's great. Just curious how I would control it via AltUI?
Cheers
C
-
@CatmanV2 said in My migration from Vera, or what I did on my holidays:
OK looking at the lights Fibaro dimmer it hasn't appeared to create any devices in Z-way that are visible other than in the advanced view.
Nothing in elements. The advanced view gives me access to all the parameters but nothing I can control it with, if that makes sense?
yep, that's where the problem lies and is why we have been talking about switching the API the bridge is talking to. The automation UI is really more of a demonstrator for what the lower API and library can do. It has some gaps unlike the lower level zwave API and even the JS API. I also have devices like these which we had to workaround by sending commands directly to the lower level API. Please provide the details: what command class that device has on the expert UI and which ones are missing. It is possible that a forced interview or a simple version edit can fix it too.
@CatmanV2 said in My migration from Vera, or what I did on my holidays:
SRT321 now accepts setpoint so that's great. Just curious how I would control it via AltUI?
Cheers
C
This is a bridge problem then, because none of us had this device before. A screenshot of the cgi screen showing the details of this device (go to the zway bridge and click on configure child) could reveal what this device is publishing and we can make the bridge support it.
-
@CatmanV2 said in My migration from Vera, or what I did on my holidays:
OK looking at the lights Fibaro dimmer it hasn't appeared to create any devices in Z-way that are visible other than in the advanced view.
I haven't tried a simple Fibaro dimmer on ZWay, but I certainly have have tested one of their RGBW LED controllers, which presents as no less than SIX dimming devices (one each for RGBW, one group, and one master.) These all work as expected, so I have high hopes for the basic Fibaro dimmer.
I think the interview problem is the one to fix first??
I do have Fibaro dimmers on my Vera system, and I think I have a spare device somewhere, so I'll try and find it and add it to ZWay.
-
I have a number of older Fibaro devices on my ZWay and most of them work as they should. As noted by Rafale77 above Fibaro are a bit of a pain, and I will try avoiding buying more.
I do not have any Dimmer 2 devices but a three older Dimmer 1 devices and they work as they should. I also have a single and a double switch (also the older models) that also work. I tried to include another double switch but I did not get it to report status properly. When checking the FW was older on that one that the one that works. I re-included it to my Vera Plus for the time being.
Unfortunately Fibaro does only allow FW update on their own controller, so I will need to replace it with something else.I also have two RGBW devices and an old Fibaro door sensor of the old type that all work the way they should. The last one is a Universal Sensor that works despite not having finished the interview.
In all they work better that on the Vera (baring one) and inclusion of e.g. the door sensor that was a proper pain on Vera was much easier on Zway.
There are some threads on the zwave-me forum on Fibaro devices, perhaps there could some clues on the Dimmer2 there.//ArcherS
-
CatmanV2replied to rafale77 on Jun 30, 2020, 5:31 PM last edited by CatmanV2 Jun 30, 2020, 1:33 PM
@rafale77 said in My migration from Vera, or what I did on my holidays:
. Please provide the details: what command class that device has on the expert UI and which ones are missing. It is possible that a forced interview or a simple version edit can fix it too.Like this?
Association group and security are the ones that are failing interview.
This is a bridge problem then, because none of us had this device before. A screenshot of the cgi screen showing the details of this device (go to the zway bridge and click on configure child) could reveal what this device is publishing and we can make the bridge support it.
Hmmm I get a 404 on the zway_cgi.lua...
file not found: cgi/zway_cgi.lua
C
-
ok we are getting somewhere. failing security is bad. You probably skept the whole security part? (extracting security key from the vera and insert it in zwave). Then yeah because your device was added to the vera with security, no other controller without the key will be able to control it... It is by design.
As for the cgi, you just need to install the file in the cgi folder.PS: @akbooer is right. I was in no way suggesting that the fibaro won't work with zway. Just that it is normal if interview may not complete.
-
Ahhhh right. I wasn't aware that I had used security
Do I need to talk to Vera or are you in a position to assist with the methodology?
From where do find zway_cgi.lua and to where do I copy it?
Cheers
C
-
@CatmanV2 said in My migration from Vera, or what I did on my holidays:
From where do find zway_cgi.lua and to where do I copy it?
Z-Way/cgi at master · akbooer/Z-Way
Zway plugin for openLuup . Contribute to akbooer/Z-Way development by creating an account on GitHub.
Copy to
cmh-ludl/cgi/ -
The whole process is described here:
GitHub - rafale77/Z-Way: Zway plugin for openLuup
Zway plugin for openLuup . Contribute to rafale77/Z-Way development by creating an account on GitHub.
I thought that's what you were following.
-
It is...
But
<quote>
B. Security key. (S0)If you previously succesfully included or shifted the z-way into the vera's network with the security key
<quote>
I didn't
<quote>
then the key will be in your /z-way-server/config/zddx/config*** file at the entry line 57. If not you can always ask vera's support for the way to extract the key as they deleted my post which provided the instructions to do so.
</quote>Hence my asking so I don't have to ask Vera
C
-
Ohh.... Somewhat weird but the vera team wanted to keep that secretive which no other platform really does and found at the end to be quite absurd because to get to the key, they need access to the vera which means that they would have access to controlling all of the devices anyway.
I posted it on this very forum I believe.
Here it is:
https://smarthome.community/topic/28/network-key-location/3?_=1593537609454
It is also possible that your device was not set with security but that the fibaro does support it. Therefore those command classes which require security just won't work and therefore will not respond to an interview. This would be another reason why you would not get to 100% interview. My aeotec dimmer for example shows all kinds of command classes, one set for security, and another for non secure inclusions. So if included securely I can get to 47% interview as the equivalent non secure class would be disabled. If I include insecurely, I get to 75% because the secure class commands are disabled.
-
@CatmanV2 said in My migration from Vera, or what I did on my holidays:
Did I miss something in the install then?
No. You are using a prototype which has not been engineered internally, or externally, for the general public...
...but you’re special, so you can go ahead.
-
@akbooer said in My migration from Vera, or what I did on my holidays:
...but you’re special, so you can go ahead.
Oh I know
OK so secure key copied into the file
Nothing changes. Force interview does nothing
Interview result and manually doing individual interviews gets me up to the 85%
Everything else:
[2020-06-30 20:43:45.377] [I] [zway] Waiting for job reply: Basic Get [2020-06-30 20:43:47.523] [W] [zway] Reply not received before timeout for job (Basic Get)Cheers
C
-
@CatmanV2 said in My migration from Vera, or what I did on my holidays:
[2020-06-30 20:43:45.377] [I] [zway] Waiting for job reply: Basic Get
[2020-06-30 20:43:47.523] [W] [zway] Reply not received before timeout for job (Basic Get)That's why I don't like fibaro... very weird/poor zwave implementation. The basic CC should not matter though so don't worry about it. You are sure you restarted z-way?
-
Positive. What would you recommend replacing it with?
C
-
What I meant that it isn't a problem. Then it means that I was wrong and that the vera did not include it securely.
I would recommend to exclude it and do a secure inclusion to (finally) benefit from the secure class commands on your fibaro device which vera could not support. -
Thanks
C
-
Hah! All sorted
A few more dodgy devices tomorrow ;). Thanks gents
C
-
OK so time for an update. This has kind of drifted off the 'Here's how you do it'
Most of getting Openluup, HA Bridge, AltUI, and getting Z-way up and runningwas pretty trivial (all things considered)
The migration from Vera to Z-way, was not as simple as I'd have hoped. Pretty much 2 days of fettling.
Couple of gotchas:
- My restore to the UZB dongle took a couple of shots. It took quite a long time as well.
- Migration to Z-way per se was pretty simple
- However, Z-way requires a totally different way of thinking. Pretty much every service creates an individual device. If you're not ready for this you can get in a hell of a mess trying to name stuff. I still have a few odd devices that I'm not quite sure what they are. I suspect tamper switches!
- Some devices are not what you think. Sirens. In fact these are shown as switches. Makes total sense when you think about it, but doesn't look great on the interface.
- The rooms were not migrated. So although all my rooms already existed in AltUI / Opeluup (from Vera) new devices all appeared in a ZWay room. In retrospect this could be because I already had rooms named, and they had different UIDs
- Reactor is still fantastic
- There are a couple of devices that aren't supported in Openluup / AltUI. Meh might be worth checking in advance.
Finally a huge thankyou to @akbooer @rafale77 @therealdb Partrick (is he here? If not can someone ping him the other place) and the rest of you that have made this work.
This is so much faster, more sensible, reactive, responsive and everything else. Now I just want to do more
Respect
Chris
82/105
