Seeking Advice:

[rafale77]

The combodevice is normal. It is what the z-way bridge uses for... combo devices. The SRT from what I can see seems to be declared as a switch with a temperature sensor, so you should see child devices spawn from that combo device. For us to be helpful, we would need to know what command classes are showing in z-way which are not ported by the bridge but the first problem is to get them interviewed and show in the z-way home automation UI.

The dimmer 2, if it has more than one functionality, likely also shows up as a combo device with child devices. Apparently it already has ported the power meter but not the dimmer command class? This is not like the vera... you don't need to go modify the xml and json and neither will it work. Each of these corresponds to an actual zwave command class and doesn't go through some vera guess work, often failing and spawning some random stuff which is why it doesn't have the vera's device specific support problems.

[CatmanV2]

Ahhhh OK. That gives me some interesting avenues to explore. I shall report back (undoubtedly with more questions!)

C

[CatmanV2]

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?

Cheers

C

[CatmanV2]

SRT321 now accepts setpoint so that's great. Just curious how I would control it via AltUI?

Cheers

C

[rafale77]

@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.

[akbooer]

@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.

[ArcherS]

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

[CatmanV2]

@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

[rafale77]

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.

[CatmanV2]

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

[akbooer]

@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/

[CatmanV2]

Thanks? Did I miss something in the install then?

Is this a suitable screenshot? All it shows it the Power meter..

C

[rafale77]

@CatmanV2

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.

[CatmanV2]

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

[rafale77]

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.

[akbooer]

@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.

[CatmanV2]

@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

[rafale77]

@CatmanV2

@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?

[CatmanV2]

Positive. What would you recommend replacing it with?

C

[rafale77]

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.