(Last Updated: October 10, 2020)

Add Indicator commandClass to zNode metric



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



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



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



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



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



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



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



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



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



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



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

    4e1309cf-17df-449c-9626-6765334489c1-image.png

    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.
    
    


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


Log in to reply