1. Home
  2. Hardware
  3. Z-Wave.me
  4. Add Indicator commandClass to zNode metric
(Last Updated: April 27, 2020)


Add Indicator commandClass to zNode metric

  • R

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

    1 P 1 Reply
  • 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.

    1
  • R

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

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

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

    0
  • P

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

    1
Log in to reply