Razberry firmware upgrade from 5.04 to 5.27

[ronluna]

I'm trying to monitor the indicator command class of a 5 button scene controller in Z-Way so openluup can properly create and track it.

seems like Z-Way COMMAND_CLASS_INDICATOR (0x87 or 135) are not being monitored by the ZWave module as I couldn't find anything for this command class in (/z-way-server-path/automation/modules/ZWave/index.js)

When a Get or Set Indicator command class request is sent to the controller. ZSniffer picks up the request and response just fine although this packets are not being monitored by the zwave module
Example:

ZWayIP:8083/ZWaveAPI/Run/SendData(NodeID,[ Command_Class, Instance, Value ])
ZWayIP:8083/ZWaveAPI/Run/SendData(2,[ 0x87, 0x01, 0x01 ]) (Hexa)
ZWayIP:8083/ZWaveAPI/Run/SendData(2,[ 135, 1, 1 ]) (Decimal)

the answer looks like:

[2020-04-24 19:59:36.261] [I] [zway] Waiting for job reply: Indicator Get
[2020-04-24 19:59:36.281] [D] [zway] RECEIVED: ( 01 0B 00 04 00 02 03 87 03 01 B6 00 C2 )
[2020-04-24 19:59:36.281] [D] [zway] SENT ACK

I’d like to store the Indicator response “RECEIVED” correctly. I believe by modifying the index.js of the zwave module could do the trick and once the module start tracking the indicator command class values as a metric then openluup's z-way plugin would properly track any changes as well.

I'm wondering if anyone around here could share any thoughts or comments that could make it easier...

[rafale77]

This is the problem with not having the bridge polling the zwave API or even the JS API. The readback is only from the Automation API which is more limited. You can obviously get the signal readback from the zwave API...
Only three ways to get around this:
Ask PoltoS to bridge this command class to the Automation API,
Write a plugin in JS for Z-way. (I may be able to do this but will be learning in the process)
Or... rely on @akbooer’s future change to move the bridge to one of the other APIs if this is still the plan.

[ronluna]

not sure @akbooer would be in the mood migrate form the automation API and as you mentioned it seems is very limited as well.

[rafale77]

We have been discussing it and it was clear that eventually it would be the direction we would have to take. A lot of the refactoring he has been doing to the bridge is to prepare for such a move.

[akbooer]

Yes, this is the (a) plan. Each of the APIs has their own merit. I will, no doubt, end up with using aspects of all of them.

But I’m a bit busy at the moment, and this, I think, is mainly a cosmetic issue?

[PoltoS]

@ronluna said in Add Indicator commandClass to zNode metric:

I'm wondering if anyone around here could share any thoughts or comments that could make it easier...

You are right, Indicator CC is handled by lib zway, but is implemented on the high level yet. You can copy everything about Switch Multilevel and rename this part to Indicator. It will add support of this CC. You can them make a pull request to include it in the dev branch on our github. Or wait for us to implement it.

[ronluna]

@PoltoS I've started your suggestion for adding Scene Controller indicator class and scene activation following your comment above by simply replicating "Switch Multilevel" in the index.js . Although wondering if this approach would be acceptable to submitted to the dev branch.

After modifying the z-way-server-path/automation/modules/ZWave/index.js and adding the command classes 135 and 45 as:

	this.CC = {
		"Basic": 0x20,
		"SwitchBinary": 0x25,
		"SwitchMultilevel": 0x26,
		"SwitchColor": 0x33,
		"SoundSwitch": 0x79,
		"SceneActivation": 0x2b,
		"Alarm": 0x71,
		"AlarmSensor": 0x9c,
		"SensorBinary": 0x30,
		"SensorMultilevel": 0x31,
		"Meter": 0x32,
		"MeterPulse": 0x35,
		"ThermostatMode": 0x40,
		"ThermostatSetPoint": 0x43,
		"ThermostatFanMode": 0x44,
		"DoorLock": 0x62,
		"CentralScene": 0x5b,
		"Battery": 0x80,
		"DeviceResetLocally": 0x5a,
		"BarrierOperator": 0x66,
		"Wakeup": 0x84,
		"Indicator": 0x87,
		"sceneControllerConf": 0x2D
	};

And:

				} else if (this.CC["sceneControllerConf"] === commandClassId) {

			var devId = vDevId + separ + 'DS';

			defaults = {
				deviceType: 'sensorDiscrete',
				location: smartStartEntryPreset && _.isNumber(smartStartEntryPreset.location)? smartStartEntryPreset.location : 0,
				probeType: 'control',
				metrics: {
					probeTitle: 'Control',
					icon: 'gesture',
					level: '',
					stat: '',
					title: compileTitle('Sensor', 'Control', vDevIdNI),
					state: '',
					currentScene: '',
					discreteStates: {},
					isFailed: false
				}
			};

			// apply postfix if available
			if (changeVDev[changeDevId]) {
				defaults = applyPostfix(defaults, changeVDev[changeDevId], devId, vDevIdNI);
			}

			var vDev = self.controller.devices.create({
				deviceId: devId,
				defaults: defaults,
				overlay: {},
				handler: function(command) {
					if (command === "update") {
						cc.Get();
					}
				},
				moduleId: self.id
			});


			// disable value set on z-way startup
			var startup = true;

			setTimeout(function() {
				startup = false;
			}, 1000);


			if (vDev) {
				vDev.set('metrics:isFailed', self.zway.devices[nodeId].data.isFailed.value);
				self.dataBind(self.gateDataBinding, self.zway, nodeId, instanceId, "SceneActivation", "currentScene", function(type) {
					try {
						if (!(type & self.ZWAY_DATA_CHANGE_TYPE["Invalidated"])) {
							vDev.set("metrics:currentScene", this.value);
						}
					} catch (e) {}
				}, "value");

				self.dataBind(self.gateDataBinding, self.zway, nodeId, instanceId, "Indicator", "stat", function(type) {
					try {
						if (!(type & self.ZWAY_DATA_CHANGE_TYPE["Invalidated"])) {
							vDev.set("metrics:stat", this.value);
						}
					} catch (e) {}
				}, "value");

			}

The changes above start monitoring those two classes for my static scene controller

http://z-way-server-ip:8083/ZAutomation/api/v1/devices shows the values as

{
creationTime: 1601994291,
creatorId: 1,
customIcons: { },
deviceType: "sensorDiscrete",
h: -849256330,
hasHistory: false,
id: "ZWayVDev_zway_17-0-45-DS",
location: 0,
locationName: "globalRoom",
metrics: {
probeTitle: "Control",
icon: "gesture",
level: "",
title: "Cooper Control (#17)",
state: "",
currentScene: 5,
discreteStates: { },
isFailed: false,
stat: 20,
},
nodeId: 17,
order: {
rooms: 0,
elements: 0,
dashboard: 0,
},
permanently_hidden: false,
probeType: "control",
tags: [ ],
visibility: true,
updateTime: 1602006617,
},

Now I'm wondering what would the best way to add support to this command classes (45 and 135) . "currentScene" would be for the last triggered scene and "stat" would be the Indicator value.

@akbooer I've noticed that command class 45 is already there for Leviton Scene controller as:

  -- Scene Controller Configuration
  ["45"] = {
    updater = function (d, inst)
      d, inst = d, inst
    end,

     -- Leviton Zone/scene controller
    files = { "D_SceneControllerLED1.xml", SID.SceneControllerLED, "D_SceneControllerLED1.json"},
  },

But is not grabbing the currentScene metric.

Mind sharing a good approach for ZWay plugin to properly trace those two classes ?

[akbooer]

@ronluna said in Add Indicator commandClass to zNode metric:

But is not grabbing the currentScene metric.
Mind sharing a good approach for ZWay plugin to properly trace those two classes ?

This is just a stub, it doesn’t do anything.
I’ll take a look.

[ronluna]

@akbooer I've tried adding

    files = { nil, SID.EnergyMetering },
  },

  -- IndicatorStatus
  ["135"] = function (d, inst)
    local indicatorStatus = tonumber (inst.metrics.stat)
    setVar ("IndicatorStatus", indicatorStatus, SID[S_HaDevice], d)
  end,

  -- Manufacturer proprietary
  -- Leviton Zone/scene controller
  ["145"] = {

no joy

[akbooer]

@ronluna said in Add Indicator commandClass to zNode metric:

I've tried adding

At first sight, that looks right. You're sure that your ZWay JS mods are doing the right thing?

Have you tried the same for the currentScene state?

[ronluna]

@akbooer I've tried with currentScene as well. the metric is being collected by ZAutomation/api just fine as shown here.

{
creationTime: 1601994291,
creatorId: 1,
customIcons: { },
deviceType: "sensorDiscrete",
h: -849256330,
hasHistory: false,
id: "ZWayVDev_zway_17-0-45-DS",
location: 0,
locationName: "globalRoom",
metrics: {
probeTitle: "Control",
icon: "gesture",
level: "",
title: "Cooper Control (#17)",
state: "",
currentScene: 5,
discreteStates: { },
isFailed: false,
stat: 20,
},
nodeId: 17,
order: {
rooms: 0,
elements: 0,
dashboard: 0,
},
permanently_hidden: false,
probeType: "control",
tags: [ ],
visibility: true,
updateTime: 1602028670,
},

Even the Zway plugin see the classes on the device (In the example is device 17) but no their values.

I've tried modifying L_ZWay2.lua as:

     -- Leviton Zone/scene controller
 --   files = { "D_SceneControllerLED1.xml", SID.SceneControllerLED, "D_SceneControllerLED1.json"},
 -- },

  -- currentScene
  ["45"] = function (d, inst)
    local currentScene = tonumber (inst.metrics.currentScene)
    setVar ("currentScene", currentScene, SID[S_HaDevice], d)

end,

  -- binary sensor
  ["48"] = {

I'm not entirely sure that the ZWay js mods I've added is perfectly doing the right thing, I'm a little doubtful of how devId is being handled.

var devId = vDevId + separ + 'DS'; 

not sure if it requires the "DS" suffix.

[akbooer]

Unless you changed something really drastic, the fact that the values are not appearing in the raw zway_xxx variables indicates that they are not being sent correctly from the actual ZWay system.

[DesT]

@ronluna I'm having also a bunch of Leviton scene controller everywhere and can't use them with zwave+openLuup!

Did you make some progress since October ?

[ronluna]

I did, I will explain in detail in a little bit once I get to the computer.

[ronluna]

Most scene controllers behave differently. I don't have a Leviton scene controller in my network. Although I've read they are a little easier to properly manage them as they report the indicator status of each button individually (Cooper RFWC5 does not whichi is what I have) . So I'm assuming Z-way has created 5 toggle switches in your Z-Way Automation API (1 for each LED button of your Leviton scene controller ). If that's the case there then the missing piece for your environment would be for the openluup Z-Way plugin to track the status of those variable (The toggle switches for each indicator button on your leviton scene controller) .

Can you share an screenshot of all the variable the openluup z-way plugin is reading for your Leviton scene controller?

Currently L_Zway2.lua is only updating metrics.level (updateChildren function #1649) and is not tracking all the z-way classes. so you will need to add support for the missing classes for your scene controller and update the "updateChildren function" accordingly inside L_Zway2.lua

[akbooer]

When you find out what’s missing, I’ll happily put it into the baseline. As you say, scene controllers vary wildly.

[ronluna]

@akbooer I have not share what to modify on L_Zway2.lua because I'm not sure about the changes I've made on the Z-way automation module. I'll continue playing with it and report back in a couple of days.

[DesT]

@ronluna that's the model I have
https://store.leviton.com/collections/z-wave/products/vizia-rf-4-button-remote-scene-controller-vrcs4-m0z?variant=33666558595

I'm trying to make it work properly on zway first, 'cause right now it not appearing under openLuup

[DesT]

@ronluna @akbooer

Done re-adding the device to zway correctly... not if I'm playing with one of them in the hallway, I got this in the openLuup log...

2020-12-28 13:39:26.931 luup.variable_set:: 31940.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 4 now: 3 #hooks:0
2020-12-28 13:39:26.932 luup.variable_set:: 31940.urn:micasaverde-com:serviceId:SceneController1.LastSceneTime was: 1609180558 now: 1609180766 #hooks:0

2020-12-28 13:39:38.712 luup.variable_set:: 31940.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 3 now: 1 #hooks:0
2020-12-28 13:39:38.713 luup.variable_set:: 31940.urn:micasaverde-com:serviceId:SceneController1.LastSceneTime was: 1609180766 now: 1609180778 #hooks:0

2020-12-28 13:39:53.350 luup.variable_set:: 31940.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 1 now: #hooks:0
2020-12-28 13:39:53.351 luup.variable_set:: 31940.urn:micasaverde-com:serviceId:SceneController1.LastSceneTime was: 1609180778 now: 1609180793 #hooks:0

What I did, I click on number 3 (ON), then number 1 (ON), then number 1 again (OFF)

The other thing, openLuup is not getting the "right" device name, sometime it use one "child" instead of the main device.

So I think the best way to handle that under openLuup will be to have a scene that run when sl_SceneActivated "changed" and do some "IF = 1 then, IF = 2 then..... "