SmartHomeUI and ExpertUI suggestions

[rafale77]

@PoltoS

I have been trying to work with both the ZWaveAPI and the vDevAPIs to bridge over to another automation layer and am encountering some issues and would like to make a couple of suggestions:
On the ExpertUI:
1. Could non supported/manufacturer specific and proprietary CC be displayed on the device interview screen instead of being just ignored? I am clearly seeing for example NIF returning 10 command classes but the expert UI only displays 8 for one of my devices. Even if it is not supported, it could just display the command class number.
2. I noticed that if we click on the "Select Device Description" It takes out the entire command class list no matter what we pick and in reality it does nothing good. What is the purpose of the device description selection?

On SmartHomeUI:
This is the area which is the most painful. There are a number of command classes from the devices which are not being represented in spite of completing interview, and are not forwarded to this vDevAPI. My suggestion would be to allow for users to select command classes for devices to be forwarded manually and select the device type and the variable to connect it to beyond what you are already automatically doing. This essentially makes this API unusable at the moment as I have many devices either forwarding state of the wrong command class, wrong state variable in the command class or not forwarding anything at all in spite of being 100% interviewed.

[PoltoS]

Your description is to generic to become a ticket need more specific description

[rafale77]

Thanks.

Maybe you can help me be more specific? I don't know how much more specific I can go.

1. You go interview a device And NIF Sends back 10 CC but expert UI only shows 8. Why?
2. Please try selecting a device description on any device on expert UI and see what happens.

For SmarthomeUI, I have motion or water sensors reporting CC perfectly on the expert UI but smart homeUI only shows their tamper CC (the everspring ST812 but some others are also doing this). I have entire devices completing interview with 8 or 10 CC and showing nothing on smart home UI. They did not create any vDev. The leviton VRCZ4 is an example but I have many others.

The point is to get a generic solution, not a device specific one.

[PoltoS]

1. You go interview a device And NIF Sends back 10 CC but expert UI only shows 8. Why?
Which are missing in Z-Way ? Those are certainly not supported in Z-Way and means you certainly don't need them

2. Those are mostly for text description of device. What is wrong? Which description you select?

SH UI:
This explains why it happens the ST812 problem: https://github.com/Z-Wave-Me/home-autom ... x.js#L5904

[rafale77]

1. You go interview a device And NIF Sends back 10 CC but expert UI only shows 8. Why?
Which are missing in Z-Way ? Those are certainly not supported in Z-Way and means you certainly don't need them

This is the part that I disagree. I actually have at least one of these particular case where I have a manufacturer specific CC which I need (Leviton). I found the workaround by using a sendData command to this CC class though.

2. Those are mostly for text description of device. What is wrong? Which description you select?

SH UI:
This explains why it happens the ST812 problem: https://github.com/Z-Wave-Me/home-autom ... x.js#L5904

Does this hold true also for CC156? 0x9C-COMMAND_CLASS_SENSOR_ALARM.

I also have issues with this device not showing any vDev at all and is the one having 10CC reported and only showing 8:

Command Class
Basic • SceneControllerConf • ManufacturerSpecific • PowerLevel • NodeNaming • Hail • Association • Version •
Interview 100%

[PoltoS]

where I have a manufacturer specific CC which I need (Leviton)

What are those "Manufacturer Specific CC" ? Please list them.

Does this hold true also for CC156? 0x9C-COMMAND_CLASS_SENSOR_ALARM.

Alarm Sensor should be supported: https://github.com/Z-Wave-Me/home-autom ... x.js#L5795 But there are so few devices nowdays that we can not test this anymore. This CC was deprecated about 7 year ago

Basic • SceneControllerConf • ManufacturerSpecific • PowerLevel • NodeNaming • Hail • Association • Version •

Well, there is nothing to control here It is a remote that sends commands to devices (including Z-Way if association is set). Make sure to enable Trap events from Remotes and Sensors to see autogenerated widgets for each received event from this "remote control".

[rafale77]

1. I have one at the moment: Leviton 0x91 it controls the LED colors of the buttons.

2. I did finally managed to add that command class to SmarthomeUI. Not quite sure how, I have been editing the config XML manually and I think I updated the version of the CC. It seems to not be an issue anymore.

3. This is the problem. I cannot event set a trap event because the plugin sees no vDev at all. When I go to select a device to trap on. I get nothing.

I have now fully migrated my setup to zway and am working out some kinks

[rafale77]

Another example as to why you should allow users to configure what gets binded to smarthome UI:

My thermostat reports CC 67(Thermostat Setpoints), 64 (thermostat Mode), 68 (Fan Mode), 69 (Fan State), 66 (Thermostat Operating State), 49-1 (temperature sensor) out of which you are only binding 67, 64 and 49-1.
I read the manual for CC66 and it is very strange. This CC does not have anything to do with logging in my case but reports the Thermostat Operating State which can be 0-Idle, 1-Heating, 2-Cooling.
Same can be said of the Fan Mode and Fan State CC. The Thermostat mode is, on the smarthomeUI a binary switch unable to control the 5 mode reported by expertUI. I can go on and on... They all work perfectly from ExpertUI. Not and issue for things we want to send commands to as we can switch to that API but for readback, it is a real problem.

[PoltoS]

1. I have one at the moment: Leviton 0x91 it controls the LED colors of the buttons.

As I remember, it is Manufacturer Proprietary. It can not be supported by Z-Way as it is proprietary You can still use zway.SendData(x, [0x91, x, x, x]) to handle it.

BTW, now Z-Way has SwitchColor for this.

2. I did finally managed to add that command class to SmarthomeUI. Not quite sure how, I have been editing the config XML manually and I think I updated the version of the CC. It seems to not be an issue anymore.

Logs and debugging can help with this. Put a lot of console.logJS() around the line mentioned above.

3. This is the problem. I cannot event set a trap event because the plugin sees no vDev at all. When I go to select a device to trap on. I get nothing.

You should check what the device is sending to Z-Way. Does it ever send something ?

[rafale77]

3. This is the problem. I cannot event set a trap event because the plugin sees no vDev at all. When I go to select a device to trap on. I get nothing.

You should check what the device is sending to Z-Way. Does it ever send something ?

My first two issues were addressed so I will focus on the last one and thermostat discussion.

Short answer is Yes it does. I am actually sending commands to it with the send function into its proprietary CC. Everything on it works on the expert UI. I can assign associations to buttons and can see button clicks. Again the issue is flexibility. All these command classes for a large variety of devices all work and can be controlled/readback on expertUI. They all could be ported over to smarthome UI but I just don't know why you won't allow users to do it manually. It may not be easy to do but such a huge improvement for the system.