Unknown device, no Z-Wave node XML - Fakro ZWP10 remote

zwave
unknowndevice
fakro
Tags: #<Tag:0x00007f51dd2812d0> #<Tag:0x00007f51dd281190> #<Tag:0x00007f51dd281050>

(Olivier Biot) #1

Is there a way for generating a new Z-Wave device entry if there’s no Z-Wave node XML file being generated? All I have, is the following Z-Wave trace debug (filtered on Z-Wave node 5, which is one of the Fakro ZWP10 remotes):

12-Mar-2019 07:02:49.111 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: MANUFACTURER not set
12-Mar-2019 07:02:51.326 [DEBUG] [col.serialmessage.SerialApiGetInitDataMessageClass] - NODE 5: Node found
12-Mar-2019 07:02:51.435 [DEBUG] [ab.binding.zwave.internal.protocol.ZWaveController] - NODE 5: Init node thread start
12-Mar-2019 07:02:52.245 [DEBUG] [ternal.protocol.initialization.ZWaveNodeSerializer] - NODE 5: Serializing from file /var/lib/openhab2/zwave/network_a1b2c3d4__node_5.xml
12-Mar-2019 07:02:52.247 [DEBUG] [ternal.protocol.initialization.ZWaveNodeSerializer] - NODE 5: Error serializing from file: file does not exist.
12-Mar-2019 07:02:52.323 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 5: Starting initialisation from EMPTYNODE
12-Mar-2019 07:02:52.329 [DEBUG] [ab.binding.zwave.internal.protocol.ZWaveController] - NODE 5: Init node thread finished
12-Mar-2019 07:02:52.395 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 5: Node advancer - advancing to IDENTIFY_NODE
12-Mar-2019 07:02:52.398 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 5: Node advancer: Initialisation starting
12-Mar-2019 07:02:52.786 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: ProtocolInfo
12-Mar-2019 07:02:52.787 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Listening = false
12-Mar-2019 07:02:52.788 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Routing   = false
12-Mar-2019 07:02:52.789 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Beaming   = true
12-Mar-2019 07:02:52.790 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Version   = 4
12-Mar-2019 07:02:52.791 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: FLIRS     = false
12-Mar-2019 07:02:52.792 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Security  = false
12-Mar-2019 07:02:52.803 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Max Baud  = 40000
12-Mar-2019 07:02:52.804 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Basic    = BASIC_TYPE_CONTROLLER
12-Mar-2019 07:02:52.805 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Generic  = GENERIC_TYPE_GENERIC_CONTROLLER
12-Mar-2019 07:02:52.806 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 5: Specific = SPECIFIC_TYPE_PORTABLE_REMOTE_CONTROLLER
12-Mar-2019 07:02:52.807 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 5: Creating new instance of command class COMMAND_CLASS_NO_OPERATION
12-Mar-2019 07:02:52.808 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 5: Command class COMMAND_CLASS_NO_OPERATION, endpoint 0 created
12-Mar-2019 07:02:52.809 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 5: Version = 1, version set. Enabling extra functionality.
12-Mar-2019 07:02:52.815 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: Adding command class COMMAND_CLASS_NO_OPERATION to the list of supported command classes.
12-Mar-2019 07:02:52.817 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 5: Creating new instance of command class COMMAND_CLASS_BASIC
12-Mar-2019 07:02:52.818 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 5: Command class COMMAND_CLASS_BASIC, endpoint 0 created
12-Mar-2019 07:02:52.819 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: Adding command class COMMAND_CLASS_BASIC to the list of supported command classes.
12-Mar-2019 07:02:52.867 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 5: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@1a3a97
12-Mar-2019 07:02:52.868 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 5: Node Init transaction completed with response COMPLETE
12-Mar-2019 07:02:52.869 [DEBUG] [protocol.initialization.ZWaveNodeInitStageAdvancer] - NODE 5: Node advancer - advancing to REQUEST_NIF
12-Mar-2019 07:02:52.872 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@111ef9c
12-Mar-2019 07:02:52.874 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Bump transaction 13 priority from Controller to Immediate
12-Mar-2019 07:02:52.910 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Adding to device queue
12-Mar-2019 07:02:52.911 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Added 13 to queue - size 3
12-Mar-2019 07:02:53.000 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == false
12-Mar-2019 07:02:53.000 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Node not awake!
12-Mar-2019 07:02:58.361 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == false
12-Mar-2019 07:02:58.361 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Node not awake!
12-Mar-2019 07:02:58.396 [DEBUG] [ab.binding.zwave.internal.protocol.ZWaveController] - Waiting for init thread Node_5_init
12-Mar-2019 07:02:58.397 [DEBUG] [ab.binding.zwave.internal.protocol.ZWaveController] - Init thread Node_5_init complete
12-Mar-2019 07:02:58.412 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Controller status changed to ONLINE.
12-Mar-2019 07:02:58.413 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Controller is ONLINE. Starting device initialisation.
12-Mar-2019 07:02:58.421 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating node properties.
12-Mar-2019 07:02:58.422 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating node properties. MAN=2147483647
12-Mar-2019 07:02:58.423 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Properties synchronised
12-Mar-2019 07:02:58.427 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Initialising Thing Node...
12-Mar-2019 07:02:58.458 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Polling intialised at 86400 seconds - start in 49420800 milliseconds.
12-Mar-2019 07:02:58.459 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 5: Device initialisation complete.
12-Mar-2019 07:02:58.583 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == false
12-Mar-2019 07:02:58.583 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Node not awake!
12-Mar-2019 07:02:58.723 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == false
12-Mar-2019 07:02:58.724 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Node not awake!

The complete Z-Wave 1-minute trace log spans 5.444 lines.

For the record, all ZWP remotes have similar looks, and have the following lay-out:

  • Channel selector button (switch between 1 → 2 → 3 → 4 → 1+2+3+4 →1→…)
  • For each of these 5 channels: 2 channels of 3 function buttons (up, stop, down)
  • The remote supports “multilevel switch” mode (smooth dimming) by keeping the up or down button pressed (instead of a short button click to e.g. fully open/close blinds or roller shutters)

So, the ZWP10 remote has 5 x 2 channels. From the ZWP10 manual: Each channel can either 10 appliances separately on 5 channels (2 per channel - one left and one right), or it can support up to 10 independent groups, each containing appliances that have to be operated simultaneously. The remote can store up to 231 appliances.


(Mark) #2

Yes, but I’d suggest trying to find out why the node.xml won’t generate. If this is a battery-powered device, you may need to wake it up multiple times before the node.xml is created.


(Olivier Biot) #3

It is indeed a battery-powered remote. Here’s what paper UI tells me for node 5:

Parameter name Parameter value
zwave_beaming true
zwave_class_basic BASIC_TYPE_CONTROLLER
zwave_class_generic GENERIC_TYPE_GENERIC_CONTROLLER
zwave_class_specific SPECIFIC_TYPE_PORTABLE_REMOTE_CONTROLLER
zwave_frequent false
zwave_listening false
zwave_neighbours
zwave_nodeid 5
zwave_routing false
zwave_secure false
zwave_version 0.0

But I can’t get the remotes to have their node_x.xml files generated. I even tried lowering the polling interval for battery-powered devices to 60 seconds.

I however managed to identify which remote is which Z-Wave node by triggering the ASSOCIATE mode on the ZWP10 remote, and by holding the remote close to the Z-Wave controller. I then see the following trace log entries appear in the Z-Wave log:

14-Mar-2019 00:54:39.801 [TRACE] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Received SOF
14-Mar-2019 00:54:39.807 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 49 84 05 06 01 01 01 86 85 72 4D 
14-Mar-2019 00:54:39.811 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 0C 00 49 84 05 06 01 01 01 86 85 72 4D 
14-Mar-2019 00:54:39.813 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - Calculated checksum = 77
14-Mar-2019 00:54:39.815 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
14-Mar-2019 00:54:39.818 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 5: Message payload = 84 05 06 01 01 01 86 85 72 
14-Mar-2019 00:54:39.820 [TRACE] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
14-Mar-2019 00:54:39.832 [TRACE] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
14-Mar-2019 00:54:39.836 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationUpdate[73], type=Request[0], dest=5, callback=132, payload=84 05 06 01 01 01 86 85 72 
14-Mar-2019 00:54:39.841 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationUpdate[73], type=Request[0], dest=5, callback=132, payload=84 05 06 01 01 01 86 85 72 
14-Mar-2019 00:54:39.843 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - lastTransaction null
14-Mar-2019 00:54:39.845 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
14-Mar-2019 00:54:39.847 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Last transaction: null
14-Mar-2019 00:54:39.850 [DEBUG] [ab.binding.zwave.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=5, callback=132, payload=84 05 06 01 01 01 86 85 72 
14-Mar-2019 00:54:39.851 [TRACE] [ab.binding.zwave.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
14-Mar-2019 00:54:39.853 [DEBUG] [otocol.serialmessage.ApplicationUpdateMessageClass] - NODE 5: Application update request. Node information received. Transaction null
14-Mar-2019 00:54:39.855 [DEBUG] [otocol.serialmessage.ApplicationUpdateMessageClass] - NODE 5: Application update - no transaction.
14-Mar-2019 00:54:39.857 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
14-Mar-2019 00:54:39.859 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
14-Mar-2019 00:54:39.861 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == false
14-Mar-2019 00:54:39.862 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 5: Node not awake!
14-Mar-2019 00:54:39.864 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 6: listening == false, frequentlyListening == false, awake == false
14-Mar-2019 00:54:39.865 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 6: Node not awake!
14-Mar-2019 00:54:39.867 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 7: listening == false, frequentlyListening == false, awake == false
14-Mar-2019 00:54:39.868 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 7: Node not awake!
14-Mar-2019 00:54:39.869 [TRACE] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
14-Mar-2019 00:54:40.108 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: Is awake with 1 messages in the queue
14-Mar-2019 00:54:40.110 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: Creating WakeupTimerTask
14-Mar-2019 00:54:40.112 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: COMMAND_CLASS_WAKE_UP not found - setting AWAKE
14-Mar-2019 00:54:40.114 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: Start sleep timer at 2500ms
14-Mar-2019 00:54:40.115 [TRACE] [ab.binding.zwave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveNodeStatusEvent
14-Mar-2019 00:54:40.117 [DEBUG] [ab.binding.zwave.internal.protocol.ZWaveController] - NODE 5: Node Status event - Node is AWAKE
14-Mar-2019 00:54:41.365 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == true
14-Mar-2019 00:54:41.367 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF
14-Mar-2019 00:54:41.369 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: WakeupTimerTask First iteration
14-Mar-2019 00:54:42.616 [TRACE] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: listening == false, frequentlyListening == false, awake == true
14-Mar-2019 00:54:42.617 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: WakeupTimerTask 1 Messages waiting, state REQUEST_NIF
14-Mar-2019 00:54:42.619 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: No more messages, go back to sleep

So basically the remote never bothers to answer the controller’s REQUEST_NIF packet.

I also tried enabling other modes on the remote, but only two trigger messages on the Z-Wave log.


(Olivier Biot) #4

I see that the remotes are now online in Paper UI (although they are not identified yet, which is normal as there’s no DB entry for them yet). And I see the first trace of their wake-up (here node 5):

Parameter name Parameter value
zwave_lastwakeup 2019-03-14T00:51:33Z

In the Z-Wave log I just came across the following log line:

[DEBUG] [openhab.binding.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:controller

Not sure what this message means.

Maybe related to the identification problem:

09-Mar-2019 02:55:33.357 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 5: Can not start heal as initialisation is not complete (REQUEST_NIF).

Which confirms that the ZWP10 refuses to reply to the REQUEST_NIF message from the controller.


(Chris Jackson) #5

This is a debug message - not an error, so I would suggest not to worry about debug messages unless you are debugging and trying to correlate the source code.

In any case I can confirm that this is not a problem.


(Chris Jackson) #6

The binding isn’t sending a NIF as the device has not woken up. There is normally a button to wake up the device - then the controller will try to communicate with it.


(Olivier Biot) #7

The remote has the following buttons:

  • At the back:
    • IN/EX microswitch
  • At the front
    • Channel switch button
    • Left ‘sub’ channel: Up / Stop / Down buttons
    • Right ‘sub’ channel: Up / Stop / Down buttons

Bingo! I managed to get it working. The trick, is to keep the channel switch button pressed for about 5 seconds until the 4 channel LEDs start blinking together (undocumented behaviour). When the LEDs stop blinking, repeat this step again. I now have a node_5.xml file:

<node>
  <homeId>0xa1b2c3d4</homeId>
  <nodeId>5</nodeId>
  <version>4</version>
  <manufacturer>0x85</manufacturer>
  <deviceId>0x1</deviceId>
  <deviceType>0x1</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>false</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map">
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>3</int>
      <associationGroup>
        <index>3</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>4</int>
      <associationGroup>
        <index>4</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>5</int>
      <associationGroup>
        <index>5</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>6</int>
      <associationGroup>
        <index>6</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>7</int>
      <associationGroup>
        <index>7</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>8</int>
      <associationGroup>
        <index>8</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>9</int>
      <associationGroup>
        <index>9</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>10</int>
      <associationGroup>
        <index>10</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
  </associationGroups>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_CONTROLLER</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_GENERIC_CONTROLLER</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_PORTABLE_REMOTE_CONTROLLER</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
            <COMMAND__CLASS__ASSOCIATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <maxGroups>10</maxGroups>
            </COMMAND__CLASS__ASSOCIATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>133</deviceManufacturer>
              <deviceType>1</deviceType>
              <deviceId>1</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_VERSION</commandClass>
            <COMMAND__CLASS__VERSION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <libraryType>LIB_CONTROLLER</libraryType>
              <protocolVersion>3.67</protocolVersion>
              <applicationVersion>1.1</applicationVersion>
            </COMMAND__CLASS__VERSION>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors/>
  <lastReceived>2019-03-14 09:37:16.877 UTC</lastReceived>
</node>

However Paper UI still reports the nodes as being uninitialised after this step: The device initialisation is not complete


(Chris Jackson) #8

Press the same button sequence again - it might, depending on the device, take a few wakeups in order to get all the data required as part of the interrogation.


(Olivier Biot) #9

I get the following log entry:

14-Mar-2019 11:56:38.340 [DEBUG] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 5: Device discovery completed

But still no change in Paper UI.


(Chris Jackson) #10

I’m not really able to comment on a 1 line logfile :wink: . This line is not in any way related to the initialisation, so I can’t tell you what the initialisation state is.


(Olivier Biot) #11

Here’s a link to a compressed Z-Wave trace log. Unpacked it takes about 14MB (~96k lines). Node 1 is the controller, node 2 is the small Fakro ARZ roller shutter, nodes 3 and 4 are identical Fakro ARZ roller shutters, nodes 5 to 7 are the Fakro ZWP10 remotes. It starts to get interesting around 10:35.


(Chris Jackson) #12

There are probably a few issues in there…

Firstly, I suspect that on some nodes the initialisation may have just given up (it only tries to contact the device a certain number of times).

However, node 5 does complete initialisation - but it doesn’t do anything since the device reports that it doesn’t support any useful command classes.

image

We can see the device type/id and I don’t think this is in the database -:

image

However, since this device apparently doesn’t support any functions (??!!??) it seems a bit pointless. My guess is that the NIF is reporting incorrectly, but without more information it’s going to be difficult to do much with the device.


(Olivier Biot) #13

There’s no documentation on how to awaken the remote when it’s asleep. It’s by accident that I discovered that it was exchanging data with the primary controller when setting it in ASSOCIATE mode, and that even more data was exchanged when I pressed the channel switching button for 3-5 seconds (a totally undocumented function of the remote).

I’m not surprised that the remote only reports COMMAND_CLASS_ASSOCIATION as it can act as a primary controller or a slave controller, and that it can assign devices (e.g., dimmable lights, blinds or roller shutters) to buttons for a given channel. I would have expected a battery status function as well.

Maybe there’s another way to make the ZWP10 remote talk to the controller?

Indeed, There’s no Fakro entry in the Z-Wave DB for anything but actuators (blinds, roller shutters, window winders). The entry 0085:0001:0001 is indeed nonexistent.

So the information in the XML file is not enough / meaningful for adding it to the database?

That’s something I can’t assess. Which functions would you usually/normally expect from such remote?


(Chris Jackson) #14

Ok, I don’t know what this device is, but I assumed it had buttons or something so that it could actually control another device? Is that not the case?

We can add a database entry, but as the device does nothing, it is a little pointless other than to give it a name.

Normally remotes send commands to control devices - eg turn them on and off, set the level, make something go up and down… I don’t know this device at all, but it sounds like from what you’ve said it doesn’t do that sort of thing.


(Olivier Biot) #15

Your assumption is correct: it is a Z-Wave remote that can be configured to control blinds, roller shutters, window openers… but also light dimmers etc. But you see more in the log than I do (although I believe you hoped to see much more than there currently is).

That’s something I couldn’t make out from the logs. I don’t consider myself a Z-Wave expert (although I think I will need to spend more time researching the Z-Wave protocol).

I suppose that this means that the remote was supposed to send more data about supported command classes than what it did so far?

Maybe it’s an incompatibility between the ZME EU UZB1 stick and the Z-Wave chipsets used in these remotes? Should I try to exclude the nodes 5, 6 & 7, re-include them and re-discover them by OpenHAB? Last time I configured the ZME EU UZB1 stick as primary controller, I had to resort to a Z-Wave setup tool to include the roller shutters and remotes to the primary controller so it’s a bit of a hassle…


(Olivier Biot) #16

Guess what… node 7 finally reported BASIC:

<node>
  <homeId>0xa1b2c3d4</homeId>
  <nodeId>7</nodeId>
  <version>4</version>
  <manufacturer>0x85</manufacturer>
  <deviceId>0x1</deviceId>
  <deviceType>0x1</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>false</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map">
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>3</int>
      <associationGroup>
        <index>3</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>4</int>
      <associationGroup>
        <index>4</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>5</int>
      <associationGroup>
        <index>5</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>6</int>
      <associationGroup>
        <index>6</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>7</int>
      <associationGroup>
        <index>7</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>8</int>
      <associationGroup>
        <index>8</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>9</int>
      <associationGroup>
        <index>9</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>10</int>
      <associationGroup>
        <index>10</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
  </associationGroups>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_CONTROLLER</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_GENERIC_CONTROLLER</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_PORTABLE_REMOTE_CONTROLLER</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
            <COMMAND__CLASS__ASSOCIATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <maxGroups>10</maxGroups>
            </COMMAND__CLASS__ASSOCIATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>0</version>
              <instances>0</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>133</deviceManufacturer>
              <deviceType>1</deviceType>
              <deviceId>1</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_VERSION</commandClass>
            <COMMAND__CLASS__VERSION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <libraryType>LIB_CONTROLLER</libraryType>
              <protocolVersion>3.67</protocolVersion>
              <applicationVersion>1.1</applicationVersion>
            </COMMAND__CLASS__VERSION>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors/>
  <lastReceived>2019-03-15 09:46:25.496 UTC</lastReceived>

(Olivier Biot) #17

I redid the entire Z-Wave network configuration by using OZWCP:

  • Removed the roller ARZ shutter nodes from the network
    • From OZWCP, in category Controller, choose *Remove Device and click “Go” (green button)
    • ARZ roller shutter: press the ‘P’ button on the roller shutter until the green LED turns on
  • Removed the ARZ remotes from the network:
    • From OZWCP, in category Controller, choose Remove Device and click “Go” (green button)
    • ZWP10 remote: press 3 times the “IN/EX” microswitch in 1 second. LEDs 1, 2 & 3 will turn on. Upon device removal, LEDs 2, 3 and 4 will briefly turn on to confirm the operation.
  • Performed a (factory) reset of the USB Z-Wave controller (ZME E UZB1)

Then I restarted the OZWCP page and started re-including the nodes: first the ARZ roller shutters, then the ZWP10 remotes. Exactly the same steps as above need to be followed, but obviously one should use choose Add Device now.

OZWCP also incorrectly detects my ARZ roller shutters as being ZWS12 Chain Actuator, but is able to detect and identify the ZWP10 remotes, seemingly all by itself. I however used the undocumented long-press-channel-button trick to wake up the remotes for subsequent communication with the controller.

Then I deleted all Z-Wave things in OpenHAB and restarted.Since the network ID changed, I had to force remove the things. Now thing discovery is able to find the roller shutters (showing up as ZWS12 Chain Actuator) but also the ZWP10 remotes (showing up as Z-Wave Node 005 (0085:0001:0001:1.1)).

The properties of Node 005 are now reported as:

Parameter name Parameter value
zwave_beaming true
zwave_class_basic BASIC_TYPE_CONTROLLER
zwave_class_generic GENERIC_TYPE_GENERIC_CONTROLLER
zwave_class_specific SPECIFIC_TYPE_PORTABLE_REMOTE_CONTROLLER
zwave_deviceid 1
zwave_devicetype 1
zwave_frequent false
zwave_listening false
zwave_manufacturer 133
zwave_neighbours
zwave_nodeid 5
zwave_routing false
zwave_secure false
zwave_version 1.1

I uploaded a new Z-Wave trace log for today here. You’ll see that the home ID changed over the course of the day. In addition, now keypresses on the ZWP10 remote are recognized. However, some of the messages are apparently not recognized by the Z-Wave binding (maybe the Z-Wave protocol is not fully obeyed):

15-Mar-2019 21:23:23.209 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 6: Received COMMAND_CLASS_SWITCH_MULTILEVEL V0 unknown command 5

It happens when pressing the STOP button on the remote.

I also kept the OZW log files and the XML backup generated by OZWCP, just in case it can help.


(Olivier Biot) #18

I see an ever growing node_N.xml file. Here’s the current status of node 7 (identical to nodes 5 & 6):

<node>
  <homeId>0xf6e419c7</homeId>
  <nodeId>7</nodeId>
  <version>4</version>
  <manufacturer>0x85</manufacturer>
  <deviceId>0x1</deviceId>
  <deviceType>0x1</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>false</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map">
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>3</int>
      <associationGroup>
        <index>3</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>4</int>
      <associationGroup>
        <index>4</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>5</int>
      <associationGroup>
        <index>5</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>6</int>
      <associationGroup>
        <index>6</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>7</int>
      <associationGroup>
        <index>7</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>8</int>
      <associationGroup>
        <index>8</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>9</int>
      <associationGroup>
        <index>9</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>10</int>
      <associationGroup>
        <index>10</index>
        <maxNodes>0</maxNodes>
        <associations/>
      </associationGroup>
    </entry>
  </associationGroups>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_CONTROLLER</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_GENERIC_CONTROLLER</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_PORTABLE_REMOTE_CONTROLLER</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_VERSION</commandClass>
            <COMMAND__CLASS__VERSION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <libraryType>LIB_CONTROLLER</libraryType>
              <protocolVersion>3.67</protocolVersion>
              <applicationVersion>1.1</applicationVersion>
            </COMMAND__CLASS__VERSION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>133</deviceManufacturer>
              <deviceType>1</deviceType>
              <deviceId>1</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
            <multiLevelSwitchCommandClass>
              <version>0</version>
              <instances>0</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </multiLevelSwitchCommandClass>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>0</version>
              <instances>0</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
            <COMMAND__CLASS__ASSOCIATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <maxGroups>10</maxGroups>
            </COMMAND__CLASS__ASSOCIATION>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors/>
  <lastReceived>2019-03-15 17:04:50.574 UTC</lastReceived>
</node>

In case it can help.

Update: this is the longest the file ever gets. In the current scenario, the ZWP10 remote acts as a secondary controller. It can also act as a primary controller, but the problem is that I can transfer the primary controller role to the ZWP10 remote but not back (at least, I couldn’t get it to work as this function is not documented). So in case I have to set it up with the ZWP10 remote as primary for a test, then I subsequently need to reset my entire Z-Wave setup as I now rely on a ZME E UZB1 stick as primary controller.


(Olivier Biot) #19

In case it is of use, here’s the OZW dump (before assigning the roller shutters to buttons on the remote):

<Node id="5" name="ZWP10 Controller 1" location="Attic" basic="1" generic="1" specific="1" type="Portable Remote Controller" listening="false" frequentListening="false" beaming="true" routing="false" max_baud_rate="40000" version="4" query_stage="Complete">
	<Manufacturer id="85" name="Fakro">
		<Product type="1" id="1" name="ZWP10 Remote Controller" />
	</Manufacturer>
	<CommandClasses>
		<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1" request_flags="4" after_mark="true">
			<Instance index="1" />
			<Value type="byte" genre="basic" instance="1" index="0" label="Basic" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
		</CommandClass>
		<CommandClass id="114" name="COMMAND_CLASS_MANUFACTURER_SPECIFIC" version="1" request_flags="4" innif="true">
			<Instance index="1" />
		</CommandClass>
		<CommandClass id="132" name="COMMAND_CLASS_WAKE_UP" version="1" request_flags="2">
			<Instance index="1" />
		</CommandClass>
		<CommandClass id="133" name="COMMAND_CLASS_ASSOCIATION" version="1" request_flags="4" innif="true">
			<Instance index="1" />
			<Associations num_groups="10">
				<Group index="1" max_associations="232" label="Channel 1 Basic" auto="true">
					<Node id="1" />
				</Group>
				<Group index="2" max_associations="232" label="Channel 1 Multilevel" auto="false" />
				<Group index="3" max_associations="232" label="Channel 2 Basic" auto="false" />
				<Group index="4" max_associations="232" label="Channel 2 Multilevel" auto="false" />
				<Group index="5" max_associations="232" label="Channel 3 Basic" auto="false" />
				<Group index="6" max_associations="232" label="Channel 3 Multilevel" auto="false" />
				<Group index="7" max_associations="232" label="Channel 4 Basic" auto="false" />
				<Group index="8" max_associations="232" label="Channel 4 Multilevel" auto="false" />
				<Group index="9" max_associations="232" label="Channel 5 Basic" auto="false" />
				<Group index="10" max_associations="232" label="Channel 5 Multilevel" auto="false" />
			</Associations>
		</CommandClass>
		<CommandClass id="134" name="COMMAND_CLASS_VERSION" version="1" request_flags="4" innif="true">
			<Instance index="1" />
			<Value type="string" genre="system" instance="1" index="0" label="Library Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="2" />
			<Value type="string" genre="system" instance="1" index="1" label="Protocol Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="3.67" />
			<Value type="string" genre="system" instance="1" index="2" label="Application Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="1.01" />
		</CommandClass>
	</CommandClasses>
</Node>

OZW is able to identify the ZWP10 remote. I was expecting a battery-level command class but apparently it is not reported / supported / provided by the Z-Wave chipset used.


(Michał Chudy) #20

Hey @shutterfreak,

I’m working on adding the very same remote to my own network. Thanks for the trick with the pilot. :slight_smile:

If you don’t mind, I’ll try to add this device to database.