[Qubino Flush Dimmer] Switch command class and dimmer command class don't update each other

When I turn on the light using the switch command class I expect it to update the level of the dimmer command class accordingly and viceversa. Unfortunately that doesn't happen.

Turning the light on with the switch command class (2-37-0-targetValue)
Before:

After:

As you can see the switch on 2-37-0 has been updated to true but the level (2-38-0) hasn't been updated to 99 accordingly.

Turning the light on with the dimmer command class (setting the 2-38-0-targetValue level to 99)
Before:

After:

As you can see the level on 2-38-0 has been updated to 99 but the switch (2-37-0) hasn't been updated to true accordingly.

zwave-284642.log
$ npm start

><EMAIL_ADDRESS>start /home/niko/devel/zwavejs2mqtt
> node bin/www

  z2m:Store scenes.json not found +0ms
  z2m:Store nodes.json not found +2ms
  z2m:App zwavejs2mqtt version: 0.0.0 +0ms
  z2m:App Application path:/home/niko/devel/zwavejs2mqtt +1ms
  z2m:Mqtt MQTT is disabled +0ms
  z2m:Zwave Connecting to /dev/ttyACM0 +0ms
Logging to file:
/home/niko/devel/zwavejs2mqtt/bin/zwave-284642.log
  z2m:App Listening on port 8091 +0ms
  z2m:App New connection ohv-AeAq0ZkOcAPRAAAA +1s
  z2m:Zwave Zwave driver is ready +2s
  z2m:Zwave Driver ready +1ms
  z2m:Zwave Node added 1 +1ms
  z2m:Zwave Scanning network with homeid: 0xc54055a2 +0ms
  z2m:Zwave Node 1 is alive +59ms
  z2m:Zwave Node 1 doesn't support groups associations +3ms
  z2m:Zwave Node 1: value added 1-32-0-currentValue => undefined +3ms
  z2m:Zwave Node 1: value added 1-32-0-targetValue => undefined +1ms
  z2m:Zwave Node 1 ready: AEON Labs - ZW090 (Z‐Stick Gen5 USB Controller) +1ms
  z2m:Zwave Scan completed +0ms
  z2m:Zwave Network scan complete. Found: 1 nodes +1ms
  z2m:Zwave Node 1: interview completed, all values are updated +1ms
  z2m:App User disconnected ohv-AeAq0ZkOcAPRAAAA +8s
GET / 304 8.727 ms - -
GET /static/css/app.ac70a60bcc407fe11707.css 304 4.830 ms - -
GET /static/js/app.a4eeee65f64587f9e920.js 304 0.763 ms - -
  z2m:App New connection -xi4jW9V5OFHT317AAAB +396ms
GET /static/logo.png 304 0.690 ms - -
  z2m:App Zwave api call: startInclusion [ true ] +22s
  z2m:Zwave Secure inclusion started +29s
  z2m:Zwave Success zwave api call startInclusion true +1ms
  z2m:Zwave Node 2: added +13s
  z2m:Zwave Node added 2 +1ms
  z2m:Zwave Inclusion stopped +5ms
  z2m:Zwave Node 2 is alive +104ms
  z2m:Zwave Node 2: value added: 114-0-manufacturerId => 345 +52ms
  z2m:Zwave Node 2: value added: 114-0-productType => 1 +1ms
  z2m:Zwave Node 2: value added: 114-0-productId => 81 +0ms
  z2m:Zwave Node 2: value added: 134-0-libraryType => 3 +57ms
  z2m:Zwave Node 2: value added: 134-0-protocolVersion => 4.5 +0ms
  z2m:Zwave Node 2: value added: 134-0-firmwareVersions => 3.7 +0ms
  z2m:Zwave Node 2: value added: 94-0-zwavePlusVersion => 1 +490ms
  z2m:Zwave Node 2: value added: 94-0-nodeType => 0 +0ms
  z2m:Zwave Node 2: value added: 94-0-roleType => 5 +1ms
  z2m:Zwave Node 2: value added: 94-0-installerIcon => 7168 +0ms
  z2m:Zwave Node 2: value added: 94-0-userIcon => 7168 +1ms
  z2m:Zwave Node 2: metadata updated: 38-0-Up +45ms
  z2m:Zwave Node 2: metadata updated: 38-0-Down +1ms
  z2m:Zwave Node 2: value added: 38-0-currentValue => 0 +61ms
  z2m:Zwave Node 2: value added: 37-0-currentValue => false +65ms
  z2m:Zwave Node 2: metadata updated: 50-0-reset +50ms
  z2m:Zwave Node 2: metadata updated: 50-0-value-65537 +92ms
  z2m:Zwave Node 2: metadata updated: 50-0-previousValue-65537 +0ms
  z2m:Zwave Node 2: metadata updated: 50-0-deltaTime-65537 +1ms
  z2m:Zwave Node 2: value added: 50-0-value-65537 => 64 +0ms
  z2m:Zwave Node 2: value added: 50-0-deltaTime-65537 => 0 +0ms
  z2m:Zwave Node 2: metadata updated: 50-0-value-66049 +91ms
  z2m:Zwave Node 2: metadata updated: 50-0-previousValue-66049 +1ms
  z2m:Zwave Node 2: metadata updated: 50-0-deltaTime-66049 +1ms
  z2m:Zwave Node 2: value added: 50-0-value-66049 => 0 +1ms
  z2m:Zwave Node 2: value added: 50-0-deltaTime-66049 => 0 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-1 +7ms
  z2m:Zwave Node 2: metadata updated: 112-0-2 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-3 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-4 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-10 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-11 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-12 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-20 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-21 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-30 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-40 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-42 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-60 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-61 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-65 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-66 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-67 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-68 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-100 +1ms
  z2m:Zwave Node 2: metadata updated: 112-0-101 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-110 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-120 +0ms
  z2m:Zwave Node 2: metadata updated: 112-0-250 +1ms
  z2m:Zwave Node 2: value added: 112-0-1 => 0 +80ms
  z2m:Zwave Node 2: value added: 112-0-2 => 0 +72ms
  z2m:Zwave Node 2: value added: 112-0-3 => 0 +73ms
  z2m:Zwave Node 2: value added: 112-0-4 => 0 +124ms
  z2m:Zwave Node 2: value added: 112-0-10 => 255 +77ms
  z2m:Zwave Node 2: value added: 112-0-11 => 0 +72ms
  z2m:Zwave Node 2: value added: 112-0-12 => 0 +70ms
  z2m:Zwave Node 2: value added: 112-0-20 => 0 +69ms
  z2m:Zwave Node 2: value added: 112-0-21 => 0 +71ms
  z2m:Zwave Node 2: value added: 112-0-30 => 0 +77ms
  z2m:Zwave Node 2: value added: 112-0-40 => 10 +70ms
  z2m:Zwave Node 2: value added: 112-0-42 => 0 +72ms
  z2m:Zwave Node 2: value added: 112-0-60 => 10 +71ms
  z2m:Zwave Node 2: value added: 112-0-61 => 99 +71ms
  z2m:Zwave Node 2: value added: 112-0-65 => 100 +77ms
  z2m:Zwave Node 2: value added: 112-0-66 => 3 +73ms
  z2m:Zwave Node 2: value added: 112-0-67 => 0 +69ms
  z2m:Zwave Node 2: value added: 112-0-68 => 0 +76ms
  z2m:Zwave Node 2: value added: 112-0-100 => 0 +77ms
  z2m:Zwave Node 2: value added: 112-0-101 => 0 +69ms
  z2m:Zwave Node 2: value added: 112-0-110 => 32536 +71ms
  z2m:Zwave Node 2: value added: 112-0-120 => 5 +68ms
  z2m:Zwave Node 2: value added: 112-0-250 => 0 +39ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-1 => 1 +325ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-1 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-1 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-2 => 16 +238ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-2 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-2 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-3 => 16 +237ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-3 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-3 =>  +0ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-4 => 16 +235ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-4 =>  +0ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-4 =>  +0ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-5 => 16 +233ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-5 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-5 =>  +0ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-6 => 16 +235ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-6 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-6 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-7 => 16 +235ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-7 =>  +0ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-7 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-8 => 16 +233ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-8 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-8 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-9 => 16 +239ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-9 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-9 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-10 => 16 +238ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-10 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-10 =>  +1ms
  z2m:Zwave Node 2: value added: 142-0-maxNodes-11 => 16 +237ms
  z2m:Zwave Node 2: value added: 142-0-nodeIds-11 =>  +2ms
  z2m:Zwave Node 2: value added: 142-0-endpoints-11 =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +321ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1  => 1 +2ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-11 16 => 16 +390ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-11  => 1 +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-11  =>  +2ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-11 16 => 16 +31ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-11 1 =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-11  =>  +1ms
  z2m:Zwave Node 2: metadata updated: 113-0-Power Management-Over-load status +1s
  z2m:Zwave Node 2: value added 2-38-0-targetValue => undefined +27ms
  z2m:Zwave Node 2: value added 2-38-0-duration => undefined +4ms
  z2m:Zwave Node 2: value added 2-38-0-currentValue => 0 +0ms
  z2m:Zwave Node 2: value added 2-38-0-Up => undefined +0ms
  z2m:Zwave Node 2: value added 2-38-0-Down => undefined +1ms
  z2m:Zwave Node 2: value added 2-94-0-zwavePlusVersion => 1 +0ms
  z2m:Zwave Node 2: value added 2-94-0-nodeType => 0 +0ms
  z2m:Zwave Node 2: value added 2-94-0-roleType => 5 +0ms
  z2m:Zwave Node 2: value added 2-94-0-installerIcon => 7168 +0ms
  z2m:Zwave Node 2: value added 2-94-0-userIcon => 7168 +1ms
  z2m:Zwave Node 2: value added 2-134-0-libraryType => 3 +0ms
  z2m:Zwave Node 2: value added 2-134-0-protocolVersion => 4.5 +0ms
  z2m:Zwave Node 2: value added 2-134-0-firmwareVersions => 3.7 +2ms
  z2m:Zwave Node 2: value added 2-134-0-hardwareVersion => undefined +0ms
  z2m:Zwave Node 2: value added 2-114-0-manufacturerId => 345 +0ms
  z2m:Zwave Node 2: value added 2-114-0-productType => 1 +0ms
  z2m:Zwave Node 2: value added 2-114-0-productId => 81 +0ms
  z2m:Zwave Node 2: value added 2-37-0-currentValue => false +1ms
  z2m:Zwave Node 2: value added 2-37-0-targetValue => undefined +0ms
  z2m:Zwave Node 2: value added 2-50-0-value-65537 => 64 +0ms
  z2m:Zwave Node 2: value added 2-50-0-deltaTime-65537 => 0 +0ms
  z2m:Zwave Node 2: value added 2-50-0-value-66049 => 0 +0ms
  z2m:Zwave Node 2: value added 2-50-0-deltaTime-66049 => 0 +0ms
  z2m:Zwave Node 2: value added 2-50-0-reset => undefined +1ms
  z2m:Zwave Node 2: value added 2-50-0-previousValue-65537 => undefined +0ms
  z2m:Zwave Node 2: value added 2-50-0-previousValue-66049 => undefined +0ms
  z2m:Zwave Node 2: value added 2-113-0-Power Management-Over-load status => undefined +0ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-1 => 1 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-1 => 1 +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-1 =>  +1ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-2 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-2 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-2 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-3 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-3 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-3 =>  +1ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-4 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-4 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-4 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-5 => 16 +1ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-5 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-5 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-6 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-6 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-6 =>  +1ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-7 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-7 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-7 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-8 => 16 +1ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-8 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-8 =>  +1ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-9 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-9 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-9 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-10 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-10 =>  +1ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-10 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-maxNodes-11 => 16 +0ms
  z2m:Zwave Node 2: value added 2-142-0-nodeIds-11 =>  +0ms
  z2m:Zwave Node 2: value added 2-142-0-endpoints-11 =>  +0ms
  z2m:Zwave Node 2: value added 2-112-0-1 => 0 +1ms
  z2m:Zwave Node 2: value added 2-112-0-2 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-3 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-4 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-10 => 255 +1ms
  z2m:Zwave Node 2: value added 2-112-0-11 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-12 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-20 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-21 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-30 => 0 +1ms
  z2m:Zwave Node 2: value added 2-112-0-40 => 10 +0ms
  z2m:Zwave Node 2: value added 2-112-0-42 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-60 => 10 +0ms
  z2m:Zwave Node 2: value added 2-112-0-61 => 99 +0ms
  z2m:Zwave Node 2: value added 2-112-0-65 => 100 +1ms
  z2m:Zwave Node 2: value added 2-112-0-66 => 3 +0ms
  z2m:Zwave Node 2: value added 2-112-0-67 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-68 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-100 => 0 +0ms
  z2m:Zwave Node 2: value added 2-112-0-101 => 0 +1ms
  z2m:Zwave Node 2: value added 2-112-0-110 => 32536 +0ms
  z2m:Zwave Node 2: value added 2-112-0-120 => 5 +0ms
  z2m:Zwave Node 2: value added 2-112-0-250 => 0 +0ms
  z2m:Zwave Node 2 ready: Qubino - ZMNHDD (Flush Dimmer Plus) +2ms
  z2m:Zwave Node 2: interview completed, all values are updated +2ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  true
] +3m
  z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +3m
  z2m:Zwave Success zwave api call writeValue  +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 80.1 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 80.1 => 80.7 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  false
] +54s
  z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +52s
  z2m:Zwave Success zwave api call writeValue  +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 80.7 => 0 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +983ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 38, endpoint: 0, property: 'targetValue' },
  50
] +15s
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 0 +12s
  z2m:Zwave Success zwave api call writeValue  +1ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 50 +914ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 11.4 +1s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 11.4 => 27.4 +996ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 27.4 => 45.4 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 45.4 => 47.1 +996ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 38, endpoint: 0, property: 'targetValue' },
  0
] +22s
  z2m:Zwave Node 2: value updated: 38-0-currentValue 50 => 54 +17s
  z2m:Zwave Success zwave api call writeValue  +1ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 54 => 50 +258ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 50 => 34 +989ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 34 => 16 +995ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 16 => 0 +995ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 47.1 => 0 +1s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  true
] +15s
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +11s
  z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +17ms
  z2m:Zwave Success zwave api call writeValue  +5ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 80.9 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 80.9 => 81.1 +996ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  false
] +14s
  z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +11s
  z2m:Zwave Success zwave api call writeValue  +3ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 81.1 => 3 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 3 => 0 +997ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +996ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  true
] +15s
  z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +12s
  z2m:Zwave Success zwave api call writeValue  +5ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 80.5 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 80.5 => 80.8 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  false
] +8s
  z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +4s
  z2m:Zwave Success zwave api call writeValue  +3ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 80.8 => 0 +3s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 38, endpoint: 0, property: 'targetValue' },
  0
] +6s
  z2m:Zwave Node 2: value updated: 38-0-currentValue 99 => 0 +2s
  z2m:Zwave Success zwave api call writeValue  +1ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 0 +895ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  true
] +6s
  z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +6s
  z2m:Zwave Success zwave api call writeValue  +2ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 66.4 +1s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 66.4 => 80.9 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 80.9 => 81.2 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  false
] +43s
  z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +40s
  z2m:Zwave Success zwave api call writeValue  +2ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 81.2 => 0 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +994ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 38, endpoint: 0, property: 'targetValue' },
  99
] +10s
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 0 +7s
  z2m:Zwave Success zwave api call writeValue  +1ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +877ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 28.4 +1s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 28.4 => 74.8 +996ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 74.8 => 81.5 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:Zwave Node 2: value updated: 50-0-value-65537 64 => 64.1 +2m
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-65537 0 => 0 +0ms

The request does sound plausible, but I'm not sure if it is feasibly to do this automagically. At least I couldn't find anything in the specs I've read that these two CCs should be mapped to each other.
Did this work with the OZW backend? A quick search didn't show any code where that could be happening.
I'm a bit hesitant to do this, because I can already anticipate that there's at least one device out there where Binary Switch and Multilevel Switch do different things.

Could be something configurable using the device config file? Maybe a special option

I think this should be a matter of setting the right association groups or something similar.
Regarding OZW if I recall correctly it used to work with OZW 1.4 but it doesn't work anymore with 1.6. If I include the device with OZW 1.6 it doesn't even update the power (W) value when I turn on/off the light, while if I include it with zwave-js it does update the power (W) at least. So I guess it's something which gets set during inclusion.
Something similar happened to me with the Qubino Flush Shutter in venetian mode, which didn't report the tilt value whenever you changed it using the physical push button with OZW 1.4. The following procedure fixed it: https://community.home-assistant.io/t/integration-of-qubino-zmnhdd1-flush-dimmer/129487/13
With OZW 1.6 it works out of the box, so I guess it's setting those associations automatically.
Could it be something similar for the Flush Dimmer?
This is the manual: https://qubino.com/manuals/Flush_Dimmer.pdf

The following procedure fixed it: https://community.home-assistant.io/t/integration-of-qubino-zmnhdd1-flush-dimmer/129487/13

Both OZW and this driver automatically configure lifeline associations during the device interview. Missing reports are almost always related to misconfigured associations.
zwave-js automatically uses Multi Channel Assocations (with a target endpoint) if possible, otherwise "normal" node assocations.
For some devices I had to force node associations, because I was getting reports that the reports wouldn't work otherwise. This includes ZMNHDD!
I'm not sure if the dashboard already allows you to configure associations - if it does, you could try to change group 1 (should include the controller) from a node association (node 1, NO endpoint) to a multi channel association (node 1, endpoint 0)
I see you opened a similar issue in the OZW repo, I'll watch this to see if the maintainers have any more information about the correct behavior.

I'm not sure if the dashboard already allows you to configure associations

@robertsLando  does it?

Yes, you can

Control Panel > Groups Tab > Select a Node Then the goups and the target node / endpoint and press add association

While you're at it, try if adding the controller to group 4 changes anything. This might at least give you multilevel switch updates when turning it on with binary switch.

try to change group 1 (should include the controller) from a node association (node 1, NO endpoint) to a multi channel association (node 1, endpoint 0)

Those are my associations for node 2, group 1. Unfortunately I cannot manage to remove the existing one, neither with "Remove" nor "Remove all".
  z2m:App Zwave api call: removeAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +3m
  z2m:Zwave Assocaitions: Removing associations from Node 2 Group 1: [object Object] +8m
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +350ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 1 => 1 +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1  =>  +0ms
  z2m:Zwave Success zwave api call removeAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +650ms

  z2m:App Zwave api call: removeAllAssociations [ 2 ] +1m
  z2m:Zwave Assocaitions: Removing all associations from Node 2 +1m
  z2m:Zwave Success zwave api call removeAllAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +1s

Any clue?

This should be a node association:

Success zwave api call getAssociations [ { nodeId: 1 } ]

but the remove call tries to remove an endpoint association { nodeId: 1, endpoint: 0 } (which does not exist)
@robertsLando

I know but shouldn't the removeAllAssociations remove it?

Probably, yeah. I'd need to see the logfile 😅

Here it is:
zwave-359840.log
In the log first I tried to remove it with "Remove", then "RemoveAll".

Strange, there's only the first remove visible in the log. @robertsLando I'm inclined to believe this is a bug in zwavejs2mqtt. The interview and the log from above
  z2m:App Zwave api call: removeAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +3m
  z2m:Zwave Assocaitions: Removing associations from Node 2 Group 1: [object Object] +8m
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +350ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 1 => 1 +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1  =>  +0ms
  z2m:Zwave Success zwave api call removeAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +650ms

shows that there is only a node association (last line), but zwavejs2mqtt tries to remove an endpoint association (first line).

shows that there is only a node association (last line), but zwavejs2mqtt tries to remove an endpoint association (first line).

Yes, you right. Actually when I call removeAssociations I let the user specify the association to remove 'manually' (he doesn't select it from the associations list). I will try to improve this in the ui, anyway like I said, shouldn't the removeAllAssociations remove it?

@darkbasic Try to pull last commit https://github.com/zwave-js/zwavejs2mqtt/commit/3def708f8c86c638333ddcd0069a77d93951cb56

removeAllAssociations

That is not part of zwave-js
https://zwave-js.github.io/node-zwave-js/#/api/controller?id=managing-associations

That is not part of zwave-js

:rofl: :rofl: Let me go take my :coffee:
Is removeNodeFromAllAssocations the same?

Or maybe it means to remove the node from the other associations, not to remove associations of that node. Tricky :confounded:

Yep, that has an entirely different meaning :)
When a node is removed from a network, it should be removed from all associations. This is what this method is for.
You could just call removeAssociations with getAssociations(nodeId).get(groupId).

@AlCalzone Fixed:
https://github.com/zwave-js/zwavejs2mqtt/blob/master/lib/ZwaveClient.js#L1158
https://github.com/zwave-js/zwavejs2mqtt/blob/master/lib/ZwaveClient.js#L1184

@AlCalzone   z2m:Zwave Error while adding associations to 2: Node 2, group 1 does not support multi channel associations! +1ms
zwave-3679.log
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +12s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +37s
  z2m:App Zwave api call: removeAssociations [ 2, 1, [ { nodeId: 1 } ] ] +11s
  z2m:Zwave Assocaitions: Removing associations from Node 2 Group 1: [object Object] +11s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +389ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 1 =>  +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1  =>  +1ms
  z2m:Zwave Success zwave api call removeAssociations  +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +75ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1  =>  +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1  =>  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [] +535ms
  z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +1m
  z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of  Node 2 +1m
  z2m:Zwave Error while adding associations to 2: Node 2, group 1 does not support multi channel associations! +1ms
  z2m:Zwave Success zwave api call addAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [] +1s

@robertsLando z2m:Zwave Assocaitions: Removing associations from Node 2 Group 1: [object Object] +11s
typo is Associations plus json needs to be serialized

@robertsLando I also don't like the fact that once you've changed the placeholder channel ID you can't select the empty one anymore

@AlCalzone I also can't add the controller to group 4
zwave-3679.log
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +2m
  z2m:Zwave Success zwave api call getAssociations [] +2m
  z2m:App Zwave api call: addAssociations [ 2, 4, [ { nodeId: 1 } ] ] +5s
  z2m:Zwave Assocaitions: Adding Node 1 to Group 4 of  Node 2 +5s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +387ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4  => 1 +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4  =>  +1ms
  z2m:Zwave Success zwave api call addAssociations  +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +61ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4 1 =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4  =>  +0ms
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +1s
  z2m:Zwave Success zwave api call getAssociations [] +550ms

I also don't like the fact that once you've changed the placeholder channel ID you can't select the empty one anymore

What?

z2m:Zwave Error while adding associations to 2: Node 2, group 1 does not support multi channel associations! +1ms

That's really strange as it is has multiChannel flag to true

What?

Nevermind, I saw the slider and I didn't notice you can actually delete the content of the channel ID field.
Anyway, wouldn't it be better to have a "Delete" button near each "Current associations" item instead of the current way?

Anyway, wouldn't it be better to have a "Delete" button near each "Current associations" item instead of the current way?
Yes it would be more user friendly, I'm just lazy :rofl:

Anyway I've just tried to add a multichannel node association to group 4 and now both the node association and the multichannel one appeared:
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +11s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +3m
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +8m
  z2m:Zwave Success zwave api call getAssociations [] +8m
  z2m:App Zwave api call: addAssociations [ 2, 4, [ { nodeId: 1, endpoint: 0 } ] ] +16s
  z2m:Zwave Assocaitions: Adding Node 1 to Group 4 of  Node 2 +16s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +319ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4  => 1 +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4  => [object Object] +0ms
  z2m:Zwave Success zwave api call addAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 }, { nodeId: 1, endpoint: 0 } ] +684ms

zwave-3679.log
Something strange is going on here...

@darkbasic I have submitted an ui improvment for associations that you will like :) pull

Something strange is going on here...

Zwave is good, zwave devices are strange :rofl:

z2m:App Zwave api call: addAssociations [ 2, 4, [ { nodeId: 1 } ] ] +5s
z2m:Zwave Assocaitions: Adding Node 1 to Group 4 of  Node 2 +5s
z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +387ms
z2m:Zwave Node 2: value updated: 142-0-nodeIds-4  => 1 +0ms
z2m:Zwave Node 2: value updated: 142-0-endpoints-4  =>  +1ms
z2m:Zwave Success zwave api call addAssociations  +1ms
z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +61ms
z2m:Zwave Node 2: value updated: 142-0-nodeIds-4 1 =>  +1ms
z2m:Zwave Node 2: value updated: 142-0-endpoints-4  =>  +0ms
z2m:App Zwave api call: getAssociations [ 2, 4 ] +1s

Looks like the device did not accept this change. addAssociations performs an add command and then requests the updated list. Wonder why the node association showed up on the next attempt though, maybe the device needed time to update?

Zwave is good, zwave devices are strange 🤣

yeah and Z-Wave associations are a f*cking mess.

That's really strange as it is has multiChannel flag to true
If the config file forbids multi channel associations then the driver respects that. You could try and change your config file locally:
In<EMAIL_ADDRESS>comment out the lines with noEndpoint: true. Just be warned that this could cause the unsolicited updates to stop working.

I have submitted an ui improvment for associations that you will like :) pull

Unfortunately the backend is doing something fishy, because I had both a node association and a group association and after deleting one of them it deleted both...
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +10s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 }, { nodeId: 1, endpoint: 0 } ] +13s
  z2m:App Zwave api call: removeAssociations [ 2, 4, [ { nodeId: 1 } ] ] +1h
  z2m:Zwave Assocaitions: Removing associations from Node 2 Group 4: [{"nodeId":1}] +1h
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +388ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4 1 =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4 [object Object] => [object Object] +1ms
  z2m:Zwave Success zwave api call removeAssociations  +0ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +16ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4  =>  +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4 [object Object] =>  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +1s
  z2m:Zwave Success zwave api call getAssociations [] +594ms

Wonder why the node association showed up on the next attempt though, maybe the device needed time to update?

I don't think so:
  z2m:App Zwave api call: addAssociations [ 2, 4, [ { nodeId: 1 } ] ] +2m
  z2m:Zwave Assocaitions: Adding Node 1 to Group 4 of  Node 2 +2m
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +389ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4  => 1 +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4  => [object Object] +1ms
  z2m:Zwave Success zwave api call addAssociations  +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +45ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4 1 =>  +2ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4 [object Object] =>  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +1s
  z2m:Zwave Success zwave api call getAssociations [] +561ms
  z2m:App User disconnected ndt4_zcnbK4pPDA0AAAC +10s

(waited some time)

  z2m:App Zwave api call: getAssociations [ 2, 4 ] +12s
  z2m:Zwave Success zwave api call getAssociations [] +23s

In<EMAIL_ADDRESS>comment out the lines with noEndpoint: true

It looks like despite the error it already created the group association, because after commeting them out it shows both:
  z2m:App Zwave api call: getAssociations [ 2, 4 ] +7s
  z2m:Zwave Success zwave api call getAssociations [] +12s
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +2s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 }, { nodeId: 1, endpoint: 0 } ] +2s

@robertsLando I tried the new "Remove all", but it doesn't remove all the associations:
  z2m:App Zwave api call: removeAllAssociations [ 2 ] +25s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +26s
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [object Object] =>  +2ms
  z2m:Zwave Assocaitions: Removed 2 associations from Node 2 group 1 +4ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-2 16 => 16 +337ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-2  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-2  =>  +0ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 2 +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +252ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-3 16 => 16 +93ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-3  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-3  =>  +1ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 3 +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-4 16 => 16 +337ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-4  =>  +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-4  =>  +1ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 4 +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-5 16 => 16 +326ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-5  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-5  =>  +0ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 5 +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-6 16 => 16 +344ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-6  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-6  =>  +1ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 6 +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-7 16 => 16 +336ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-7  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-7  =>  +1ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 7 +0ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-8 16 => 16 +352ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-8  =>  +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-8  =>  +1ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 8 +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-9 16 => 16 +364ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-9  =>  +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-9  =>  +1ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 9 +2ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-10 16 => 16 +344ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-10  =>  +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-10  =>  +1ms
  z2m:Zwave Assocaitions: Removed 0 associations from Node 2 group 10 +1ms
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-11 16 => 16 +321ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-11  =>  +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-11 [object Object] =>  +0ms
  z2m:Zwave Assocaitions: Removed 1 associations from Node 2 group 11 +1ms
  z2m:Zwave Success zwave api call removeAllAssociations  +0ms

Hmm that does indeed look very fishy.

z2m:App Zwave api call: removeAllAssociations [ 2 ] +25s
z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +26s
z2m:Zwave Node 2: value updated: 142-0-nodeIds-1  =>  +1ms
z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [object Object] =>  +2ms
z2m:Zwave Assocaitions: Removed 2 associations from Node 2 group 1 +4ms

This looks like an endpoint association was removed (2nd to last line)

z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +252ms

And this is really weird. @robertsLando does z2m cache these results somehow? If not, this does seem like we have a node association created by the Association CC and nothing for Multi Channel Association CC. Removing that only uses Multi Channel Association CC, so the Association CC association is probably unaffected. 🤔

does z2m cache these results somehow?

I only cache groups, associations are fetched on every request when the user selects a group

@darkbasic Please use dev branch, I will add edits there

Ok, then I'll have to investigate

@AlCalzone Add investigating flag :rofl:

@darkbasic could you share your cache file (something.values.jsonl) please? If @robertsLando didn't change the location, it should be in node_modules/zwave-js/cache

It's in "store" folder now

It's in "store" folder now

Yes, it's in store:
zwavejs2mqtt]$ git status --ignored
Sul branch master
Il tuo branch è aggiornato rispetto a 'origin/master'.

File ignorati:
  (usa "git add -f <file>..." per includere l'elemento fra quelli di cui verrà eseguito il commit)
        bin/zwave-10331.log
        bin/zwave-16501.log
        bin/zwave-3679.log
        dist/
        node_modules/
        store/d743ed1a.json
        store/d743ed1a.metadata.jsonl
        store/d743ed1a.values.jsonl
        store/settings.json

@AlCalzone here it is, I also attached latest log
d743ed1a.values.jsonl.txt
zwave-16501.log

Yup, that confirms my suspicion in https://github.com/zwave-js/node-zwave-js/issues/1090#issuecomment-721699693

I'll probably have some time for a fix later tonight. Will let you know.

@darkbasic https://github.com/zwave-js/node-zwave-js/pull/1094 should enable the controller to remove both the "normal" and the multi channel association. Can you test this from github or should I create an alpha release for you?
Testing from github should work as follows:

clone the repo
in the cloned folder run:

npx lerna bootstrap
npm run build
npx lerna exec -- npm link

in the z2m folder run npm link zwave-js

I'm using zwavejs2mqtt from the dev branch and node-zwave-js from the association-delete-all branch.
I added a node association and then tried to add a multi-channel association, but it doesn't show up, is it normal?
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [] +676ms
  z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1 } ] ] +8s
  z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of  Node 2 +8s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +320ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 [] => [ 1 ] +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [] => [] +0ms
  z2m:Zwave Success zwave api call addAssociations  +2ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +678ms
  z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +4s
  z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of  Node 2 +4s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +284ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 [ 1 ] => [ 1 ] +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [] => [] +1ms
  z2m:Zwave Success zwave api call addAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +719ms

By the way, did you consider using yarn workspaces?

z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +4s
z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of  Node 2 +4s
z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +284ms
z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 [ 1 ] => [ 1 ] +0ms
z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [] => [] +1ms

The multi channel association is added as a node association. Not sure if this is due to the config file forcing a node association or if z2m is mixing this up? @robertsLando

By the way, did you consider using yarn workspaces?

I have never worked with yarn. npm@7 is also getting a workspace feature, but I'm not sure yet what this changes exactly.

Btw, can I interpret the above log as confirmation that the association-delete-all does what it is supposed to?

I've been able to remove a node association or multichannel association, but I couldn't try to delete them when they where both present, because I can only have a node or a multichannel now.
@robertsLando I've found a new bug: if you edit the channel id field (for example because you added a multi channel association) and then you clear it up, you won't be able to create new associations until you refresh the page:
z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: '' } ] ] +14s

It basically targets the "empty string" endpoint.

I've been able to remove a node association or a multi channel association

That is enough for me. At least it seems like your phantom association is gone.

I dunno what you mean with "mixing it up" but I'm just calling the controller methods as you see in the logs, I don't cache anything about associations 😕
About the empty string bug I will fix it tomorrow thanks

I mean this specifically:

z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +4s
z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of Node 2 +4s

The call in the first line should add an endpoint association, the 2nd line looks like it tries to add a node association. Or is this just a display issue? I'm pretty sure that adding endpoint associations works in zwave-js.

Or is this just a display issue

I think I forgot to add the endpoint to the log message

The thing is it also does add a node association, not an endpoint association.

Check it here: https://github.com/zwave-js/zwavejs2mqtt/blob/master/lib/ZwaveClient.js
Line 1097, sorry I'm from the phone and I cannot find how to give you the direct line link

Hm, this all doesn't make sense. @darkbasic I think I need one more logfile from your attempt to add the association.

Here it is:
zwave-121980.log
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +9s
  z2m:Zwave Success zwave api call getAssociations [] +14s
  z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1 } ] ] +13s
  z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of  Node 2 +13s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +388ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 [] => [] +0ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [] => [ { nodeId: 1, endpoint: 0 } ] +1ms
  z2m:Zwave Success zwave api call addAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1, endpoint: 0 } ] +612ms
  z2m:App Zwave api call: addAssociations [ 2, 1, [ { nodeId: 1, endpoint: 0 } ] ] +4s
  z2m:Zwave Assocaitions: Adding Node 1 to Group 1 of  Node 2 +4s
  z2m:Zwave Node 2: value updated: 142-0-maxNodes-1 1 => 1 +367ms
  z2m:Zwave Node 2: value updated: 142-0-nodeIds-1 [] => [] +1ms
  z2m:Zwave Node 2: value updated: 142-0-endpoints-1 [ { nodeId: 1, endpoint: 0 } ] => [ { nodeId: 1, endpoint: 0 } ] +1ms
  z2m:Zwave Success zwave api call addAssociations  +1ms
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1, endpoint: 0 } ] +631ms

There's something weird happening with the device...
During the interview, the controller tries to assign itself as a multi channel association. The device first acknowledges this but then sends another report a few milliseconds later where the association is missing again.
That's why the first get above seems to yield no associations

z2m:App Zwave api call: getAssociations [ 2, 1 ] +9s
z2m:Zwave Success zwave api call getAssociations [] +14s

Then you try to add a node association, but the device already has the multi channel association from before. Since the limit of associations in the group is 1, the node association is not added. The GET which should confirm the add now shows the multi channel association that was added earlier.
Adding the multi channel association again is effectively a no-op

> Both OZW and this driver automatically configure lifeline associations during the device interview. Missing reports are almost always related to misconfigured associations.
A general rule for Qubino Flush devices is, that the ordinary lifeline has to be configured (using ASSOCIATION_SET(groupId=1, nodeId=1)), whereas the multi channel lifeline association must be configured (using MULTI_CHANNEL_ASSOCIATION_SET(groupId=1, mcnodeId=1, endpoint=0), if CC_MULTI_CHANNEL is listed, which means the temperature sensor is connected or an additional input is configured).
The majority of Qubino devices are, in their default configurations, single channel devices, so they require an ordinary association to be configured. They expect the mc lifeline to be configured only, when additional endpoints are enabled.
These two mentioned commands are enough to configure unsolicited reporting.
> zwave-js automatically uses Multi Channel Assocations (with a target endpoint) if possible, otherwise "normal" node assocations.
Like explained above, some Qubino devices will not send any unsolicited values, if a mc lifeline is configured in their default configurations, where they are represented as single channel (root endpoint only) devices.

Like explained above, some Qubino devices will not send any unsolicited values, if a mc lifeline is configured in their default configurations, where they are represented as single channel (root endpoint only) devices.

Just to make sure I understand: Do these devices support MC associations?
If I remember correctly from reading the specs (but I might have mixed this up), Multi Channel Associations should be preferred over Associations starting with MC version 3.

When I turn on the light using the switch command class I expect it to update the level of the dimmer command class accordingly and viceversa. Unfortunately that doesn't happen.

Unfortunately, the Dimmer only sends out unsolicited messages for SWITCH_MULTILEVEL_REPORT and not SWITCH_BINARY_REPORT, hence the toggle widget is not updated. In order of the state of the toggle widget to be updated, polling would have to be enabled (by issuing SWITCH_BINARY_GET commands).
This can also be seen in the zwave zniffer:

> Just to make sure I understand: Do these devices support MC associations?
They do, but only in their non-default configurations: when the temperature sensor is connected or when an additional input is enabled -> CC_MULTI_CHANNEL is listed. In these configurations, the devices are represented as multi channel devices.
> If I remember correctly from reading the specs (but I might have mixed this up), Multi Channel Associations should be preferred over Associations starting with MC version 3
Yes, now they are preffered, as the Silicon's ZIP/Zware libraries also configure a multi channel lifeline by default, but unfortunately, these devices require an ordinary lifeline to be configured, in their default configurations.

They do, but only in their non-default configurations: when the temperature sensor is connected or when an additional input is enabled -> CC_MULTI_CHANNEL is listed. In these configurations, the devices are represented as multi channel devices.

Sorry, I think we misunderstood each other. I was talking about the Multi Channel Association CC, not Multi Channel CC. Currently, the driver checks if that is supported to determine whether a multi channel or a node association is used for the lifeline. It does not check whether the Multi Channel CC is supported.
If the devices do not include Multi Channel CC in their NIF in the default configuration (which it does seem like judging from this log), that is something I can add a check for.

Apologies, I should have worded my answer better.
> Just to make sure I understand: Do these devices support MC associations?
Yes, the Flush devices do advertise CC_MULTI_CHANNEL_ASSOCIATION in all their configurations, but must only be used in their non default configurations. What I wanted to say in my previous replay was, that the multi channel association must be used in device configurations, where CC_MULTI_CHANNEL is listed.

Thinking about it, this check would also make sense by default, not only for Qubino devices. The specs state the following

If an End Point Association is created from the Lifeline group, End Points MUST send relevant Multi
Channel encapsulated commands to the Lifeline group destination.

This requirement cannot be fulfilled when the device does not support Multi Channel CC

When I turn on the light using the switch command class I expect it to update the level of the dimmer command class accordingly and viceversa. Unfortunately that doesn't happen.

Unfortunately, the Dimmer only sends out unsolicited messages for SWITCH_MULTILEVEL_REPORT and not SWITCH_BINARY_REPORT, hence the toggle widget is not updated.

Weird, this is not what I'm experiencing.
  z2m:App Zwave api call: getAssociations [ 2, 1 ] +1s
  z2m:Zwave Success zwave api call getAssociations [ { nodeId: 1 } ] +676ms

As you can see lifeline association has been set correctly.
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  true
] +14s
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +14s
  z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +109ms
  z2m:Zwave Success zwave api call writeValue  +2ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 99 => 99 +565ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 78.5 +1s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 78.5 => 80.5 +996ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms

z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +109ms

@AlCalzone is it a report from the dimmer or is it zwave-js acknowledging the user changed the state of the switch?

z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +14s
z2m:Zwave Node 2: value updated: 38-0-currentValue 99 => 99 +565ms

@petrovcicklemen as you can see in this case I got a level report (two of them to be precise, with the second being completely useless since the state didn't change)
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  false
] +7s
  z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +5s
  z2m:Zwave Success zwave api call writeValue  +3ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 80.5 => 0 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +1s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms

@petrovcicklemen but it this case I didn't get any report at all for the level. This is completely random and happens with an hard resetted controller placed a few centimeters away from an hard resetted Flush Dimmer. Why?

@darkbasic Setting a value from zwave-js also requests the updated (current) value from the device, so that's why you're seeing this in the first log
z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +109ms

I'm not sure where these updates are coming from
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +14s
  ...
  z2m:Zwave Node 2: value updated: 38-0-currentValue 99 => 99 +565ms

You seem to control the device while the interview is still going on, so its a bit hard to tell whether the update was because of a request during the interview or unsolicited

You seem to control the device while the interview is still going on, so its a bit hard to tell whether the update was because of a request during the interview or unsolicited

That's weird, I clearly have an "interview completed" printed in the console before sending the commands and I always wait an additional minute for safety:
  z2m:Zwave Node 2 ready: Qubino - ZMNHDD (Flush Dimmer Plus) +2ms
  z2m:Zwave Scan completed +1ms
  z2m:Zwave Network scan complete. Found: 2 nodes +0ms
  z2m:Zwave Node 2: interview completed, all values are updated +1ms

Anyway I've got plenty of similar results later on:
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  true
] +2s
  z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +506ms
  z2m:Zwave Success zwave api call writeValue  +5ms
  z2m:Zwave Node 2: value updated: 38-0-currentValue 0 => 99 +466ms
  z2m:App Zwave api call: writeValue [
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  false
] +1s
  z2m:Zwave Node 2: value updated: 37-0-currentValue true => false +1s
  z2m:Zwave Success zwave api call writeValue  +2ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 40.3 => 49.7 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 49.7 => 0 +995ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 0 +994ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +0ms

By the way in this case it looks like it updated the level but not the power with the first command, while it updated the power but not the level with the second one.

I always wait an additional minute for safety

Hmm I saw a bunch of BinarySwitchCCSet commands during the interview, so I assumed you triggered them.

By the way in this case it looks like it updated the level but not the power with the first command, while it updated the power but not the level with the second one.

Weird, maybe @petrovcicklemen has some insight on this?

Weird, this is not what I'm experiencing.
Like mentioned by @darkbasic the SWITCH_BINARY values are probably obtained via polling. The picture of the zniffer log, where I've tried changing the output state of the device, shows only SWITCH_MULTILEVEL_REPORTs, not SWITCH_BINARY_REPORTs (METER_REPORTs are missing, since no load was connected).

@petrovcicklemen as you can see in this case I got a level report (two of them to be precise, with the second being completely useless since the state didn't change)
The device might send multiple output state reports, while it is transitioning, so that could be one explanation. This is so the dimmer sliders are updated, during the transition.

@petrovcicklemen but it this case I didn't get any report at all for the level. This is completely random and happens with an hard resetted controller placed a few centimeters away from an hard resetted Flush Dimmer. Why?
Make sure you are testing using the correct switch type and also have correctly configured switch/input 1 type, since this influences the sending of unsolicited reports. If you normally get all level values and one is missing sporadically, then I'd say this is a firmware bug, related to the revision, that you have. Also, changing the state to quickly, might result in such cases, since the device needs some time to send out all its queued messages.

@petrovcicklemen zwave-js does not do any polling, except to refresh the current value once after each SET (but not from different CCs) and when a SupervisionCC encapsulated command tells it that there was an update. Multilevel Switch reports after setting the Binary Switch value (and vice versa) therefore can only be unsolicited updates.

@AlCalzone I've asked my colleague to prepare a sample device with the firmware revision, that @darkbasic has and it'll be tested this friday, since we're not on the firm until then. I'll check if that version sends out also unsolicited SWITCH_BINARY_REPORTs. I did test on the latest revision yesterday and as can be seen from the zniffer log above, no unsolicited SWITCH_BINARY_REPORTs were sent.

We already did the tests: the mentioned firmware revision shouldn't send any unsolicited SWITCH_BINARY_REPORTs, which can be also queried by the gateway, by sending the ASSOCIATION_GROUP_COMMAND_LIST_GET command:

The mentioned command was sent to all the groups on the root endpoint and the byte sequence 0x2503 (SWITCH_BINARY_REPORT) was not listed in any of them, under the "Command" field:

Here's the zniffer log, if you'd be interested in seeing it:
FlushDimmerTestNicolo.zip
Based on this, I think the occurrences that can be viewed in the log are due to polling. I can test the device also on this library, but I can do it sometime next week, if that's ok.

When looking at the above log (after the interview is complete) I would confirm this:

Binary Switch Reports are only sent in response to a Binary Switch Get (which the driver sends after setting the value).
Binary Switch Reports are never sent after switching the node using Multilevel Switch Set
Meter Reports are sometimes sent after switching the node using Binary Switch Set, sometimes once, sometimes twice
Meter Reports are sometimes sent after switching the node using Multilevel Switch Set, sometimes once, sometimes twice
Multilevel Switch Reports are always sent in response to a Multilevel Switch Get (which the driver sends after setting the value).
Multilevel Switch Reports are sent during and at the end of the dimming(?) process

I've asked my colleague to prepare a sample device with the firmware revision, that @darkbasic has and it'll be tested this friday, since we're not on the firm until then

Looks like a bug in the firmware to me, if you could send me a kit to update it I could try if latest one is affected as well.
The device state needs to stay consistent and I can't simply poll everything in a network with ~100 devices, especially since Qubino doesn't support S2 and S0 has quite a bit of overhead.

> * Binary Switch Reports are only sent in response to a Binary Switch Get (which the driver sends after setting the value).
Correct. This is also mandated by the specs (a REPORT should match the GET).
> * Binary Switch Reports are never sent after switching the node using Multilevel Switch Set
Correct. As explained and shown above, the device does not advertise SWITCH_BINARY_REPORT is none of the association groups. You can double check this in the log, provided above.
> * Meter Reports are sometimes sent after switching the node using Binary Switch Set, sometimes once, sometimes twice
There are two configuration parameters that govern the sending of unsolicited METER_REPORTs: 40 and 42. One determines the sending by time, while the other determines a power treshold. The sending of unsolicited reports is also affected by how quicly the output state changes, since it takes a few seconds for the reports to be send.
> * Meter Reports are sometimes sent after switching the node using Multilevel Switch Set, sometimes once, sometimes twice
Same as above.
> * Multilevel Switch Reports are always sent in response to a Multilevel Switch Get (which the driver sends after setting the value).
Correct. The mentioned commands (2603) is advertised in association group 1, which can also be seen above.
> * Multilevel Switch Reports are sent during and at the end of the dimming(?) process
Correct. Multiple switch multilevel reports might be sent to update the dimming slider to indicate progress.

Looks like a bug in the firmware to me, if you could send me a kit to update it I could try if latest one is affected as well.
The absence of unsolicited SWITCH_BINARY_REPORTs is not a bug, as the device does not advertise the mentioned command in any of the association groups, meaning it will never send any SWITCH_BINARY_REPORTs. A dedicated hardware programmer is needed to reflash the devices, but we don't send it around, so you'd have to send the devices to us. I can share these findings with my colleagues and propose that this is added to the firmware, but can't promise this update will be made, as such decisions are not made by me.

There are two configuration parameters that govern the sending of unsolicited METER_REPORTs: 40 and 42. One determines the sending by time, while the other determines a power treshold.

But I was always switching between level 0 and level 99, so the threshold didn't change at all: 0 watts when the light is off and ~80 Watts when the light is on.
Also I'm not clicking on the switch button like mad and I can reproduce it even if I wait a minute between each state change.

A dedicated hardware programmer is needed to reflash the devices, but we don't send it around, so you'd have to send the devices to us.

I know, because I've already sent my devices twice. The first time they didn't test the new firmware and the bug wasn't fixed at all, while the second time they hit another blocker and I've had to wait months before getting my devices back. Every time I send them to you I'm left in the dark (literally, because with no relays I can't turn my lights on and I can't even get some light from the windows because I can't move my venetian blinds either). Can't even let the venetian blinds open because I wouldn't be able to sleep at night: I have plisse' blinds in my bedroom. I'm not even counting the fact that removing and re-installing 50 devices would cost thousands of euros every time if I was not doing it myself. That's why Igor mentioned about sending the programmer if I ever needed to update my devices again and of course I can return it once I'm done. The only other option is sending 3-4 devices each time, but I think we will both loosing our time such way.

But I was always switching between level 0 and level 99, so the delta didn't change at all: 0 watts when the light is off and ~80 Watts when the light is on.
Also I'm not clicking on the switch button like mad and I can reproduce it even if I wait a minute between each state change.

@darkbasic I understand. Like I mentioned in one of my first comments, if METER_REPORTs are missing sporadically, then it's probably a firmware issue. Igor will attempt to replicate this tomorrow. Since this is not an integration issue, he'll be discussing the next steps with you over the support portal.

FYI, #1113 is going to change the interview to set up node associations for lifelines instead of Endpoint associations when Multi Channel CC is not present

Awesome, so I guess we can remove the "noEndpoint": true quirk in @zwave-js/config/config/devices/0x0159/zmnhdd.json?
If I understand correctly that would break the device when a temperature sensor is attached or the additional inputs are used.

already did :)

The changes we discussed are included in v5.4.0

Can this be closed ?

The mutual update between Binary Switch and Multilevel Switch is still not happening, but I don't think there is a good heuristic (for all devices) when to poll the binary switch after a multilevel switch change.

I tried latest version of zwavejs2mqtt (which uses node-zwave-js 5.4.0) and I noticed that the switch command class (2-37-0-targetValue) doesn't reflect the 37-0-currentValue value. So when I click on the 2-37-0-targetValue switch the 37-0-currentValue gets true but the switch is still off because 2-37-0-targetValue is undefined.
  { nodeId: 2, commandClass: 37, endpoint: 0, property: 'targetValue' },
  true
] +10s
  z2m:Zwave Node 2: value updated: 37-0-currentValue false => true +16s
  z2m:Zwave Node 2: value updated: 37-0-targetValue undefined => undefined +0ms
  z2m:Zwave Success zwave api call writeValue  +4ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 0 => 73.2 +2s
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 73.2 => 81.4 +993ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +1ms
  z2m:Zwave Node 2: value updated: 50-0-value-66049 81.4 => 80.8 +998ms
  z2m:Zwave Node 2: value updated: 50-0-deltaTime-66049 0 => 0 +2ms

zwave-5363.log

but the switch is still off because 2-37-0-targetValue is undefined.

@robertsLando that's what we talked about a few days ago. This switch supports a newer version of the switch CCs, but does not report a target value in its reports.
Maybe it does generally make sense not to update the targetValue property when a device does not report it.

Lets discuss this further in https://github.com/zwave-js/node-zwave-js/issues/895

@petrovcicklemen can you please share your thoughts about this https://github.com/zwave-js/node-zwave-js/issues/1138

Like I mentioned in one of my first comments, if METER_REPORTs are missing sporadically, then it's probably a firmware issue.

@petrovcicklemen I confirm that the sporadically missing reports have been fixed by the new firmware, thanks!
Unfortunately the Flush Dimmer doesn't obey parameter 2, meaning that the additional scene input I2 behaves like a bistable switch despite being set as momentary switch (which is the default value). Also there is a big lag between the moment when you press I1 (or I2) and the moment the zwave notification gets sent (4-7 seconds). Hopefully this can be improved as well. I've made a video where I showcase the problem: https://www.youtube.com/watch?v=2INIV4gnIPw


Initialize Channel queue capacity lazily to conserve memory

For some use cases, initializing a channel buffer eagerly (as it is currently implemented) can avoid reallocs, resulting in great performance, especially for smaller ephemeral channels that may very well use the full channel depth. Unfortunately, the tradeoff is a lot of memory usage for other use cases.
For example, in my NATS client, a Channel(NATS::Message) is used to pipe messages off the wire to a message subscriber. The capacity of this channel must be large enough to handle spikes (if not, NATS disconnects the client). The Go client sets the channel capacity to 512k per subscriber. I use 64k for the Crystal client, and even that uses a lot of memory.
To illustrate, I set up 1k subscriptions (simulating duplicate subscriptions for concurrent message handling, underlying subscriptions as the implementation of higher-level messaging operations inside the client, and general sprawl of subscribers):
require "nats"

nats = NATS::Client.new
at_exit { nats.close }

1_000.times do
  nats.subscribe "foo" do |msg|
    pp msg
  end
end
nats.flush

gets

It uses 4GB of RAM:

With this patch, the same code uses 99.5% less memory:

Memory will grow in size up to the high water mark as messages get buffered during normal execution, but almost none of these channels will ever be saturated and many may never use the buffer at all, so fully allocating the capacity for every single channel can be extreme overkill.

There is an issue about this in #11572. We should continue the general discussion there before considering this PR.
Please add a comment with your reasoning to the issue.


Use TLS if connecting outside of localhost

Testing

scenario
trace

local collector, default config
https://app.signalfx.com/o11y/#/apm/traces/294ac1e454292882fd392e6f9bb7a94a

Codecov Report

Merging #792 (db10bc2) into main (1021fa0) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #792      +/-   ##
==========================================
- Coverage   79.55%   79.44%   -0.11%
==========================================
  Files          56       56
  Lines        2798     2832      +34
==========================================
+ Hits         2226     2250      +24
- Misses        525      533       +8
- Partials       47       49       +2

Flag
Coverage Δ

Linux
79.44% <100.00%> (+0.24%)
:arrow_up:

Windows
?

macOS
75.77% <100.00%> (+0.29%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

distro/exporter.go
100.00% <100.00%> (ø)

...n/github.com/lib/pq/splunkpq/internal/connector.go
51.75% <0.00%> (-5.03%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1021fa0...db10bc2. Read the comment docs.


Use versioned CLDR data.

As per the instructions on #826. I have tried for version 32.0.0

Hello @noviluni! Can you please provide your feedback on this when you get time? Thanks!

Hi, yes @kishan3, I was waiting to merge this: https://github.com/scrapinghub/dateparser/pull/601 before as it will be necessary to update the docs and it was merged 13 hours ago :)
I think it will be also a good idea to wait for this to be merged: https://github.com/scrapinghub/dateparser/pull/805 to avoid conflicts.
I mentioned I would handle the first update as it's something that has been never done and I need to polish the process: https://github.com/scrapinghub/dateparser/issues/826#issuecomment-719519992, but I can try to do the same by providing feedback here. Let me handle first the https://github.com/scrapinghub/dateparser/pull/805 issue and then I will come again here.

Ok thanks @noviluni !

Hello @noviluni :wave: How are you.
Are we proceeding with these changes?

Hi @kishan3!
We will continue working on this after merging this: https://github.com/scrapinghub/dateparser/pull/805 to avoid conflicts.
However, we can't merge that because the travis-ci pipelines stopped working and we need to enable Github actions: https://github.com/scrapinghub/dateparser/pull/859 before merging any new PR.
I will try to focus on finishing that PR (help is welcomed), but I need some time. I will notify you as soon as I merge it :)

Thanks @noviluni Let me see if I can help with any of them.


Improve/fix paste handling for multiline strings

I ran into this when trying to paste in a code snippet:
function Linemode:size_and_mtime()
	local year = os.date("%Y")
	local time = (self._file.cha.modified or 0) // 1

	if time > 0 and os.date("%Y", time) == year then
		time = os.date("%b %d %H:%M", time)
	else
		time = time and os.date("%b %d  %Y", time) or ""
	end

	local size = self._file:size()
	return ui.Line(string.format(" %s %s ", size and ya.readable_size(size) or "-", time))
end

This is how it ended up with flow

But if I use something like micro instead it works fine

I've tested this with Windows (WSL Ubuntu)/Windows Terminal and macOS/Ghostty and got the same results.

What exact method are you using to paste? Bracketed paste is supposed to prevent this behavior, but for some reason it seems not to be working. I'm certain ghostty supports bracketed paste and, I'm not entirely sure, but I think windows terminal does too.

Found it! It was the tab characters in the snippet you are pasting that caused my rudimentary paste sanitizer to bork and exit bracketed paste mode. Thus dumping the rest of the input as keystrokes.
I have added tabs to the list of allowed special chars in pastes.

Figures that tabs would cause it, thanks for the fix!


Create GuestIdentityInterface

I think we need to add an interface for the guest identity. I've encountered tasks where several different classes of users were considered guest. We now have the final GuestIdentity class and logic tied to that. We will not be able to get the correct result in the isGuest() method if we use an entity that is different from the provided GuestIdentity.

Interesting. What were the tasks?

@roxblnfk describe use case.
I think in order to implement this needed:

create GuestIdentityInterface
create GuestIdentityFactoryInterface
create SimpleGuestIdentityInterfaceFactory that make GuestIdentity
use GuestIdentityFactoryInterface in CurrentUser for create guest identity

In applications users can create own implementation of GuestIdentityFactoryInterface and GuestIdentityInterface.


signalAlign metrichor version support

I have used metrichor 2.38 for base calling. currently signalAlign is not supporting 2.38 version. Please see below error
signalAlign - indexing reference, done Unsupported Version (1.15.0 and 1.19.0 supported)
How I can run signalAlign for latest metrichor data.

Hello,
Which dragonet version are you using? You can find it in "/Analyses/Basecall_2D_000/" attributes. Are you using the new R9 kits?
If you are, I'm working on updating to R9 chemistry. The models are different so it's a little more involved. Should be ready in ~1 week.

Thanks for the reply. We are using R7 chemistry and dragonet version is 1.15.0
./runSignalAlign --file_directory /2D_Reads/pass/ --ref reference.fasta -o outputdirectory
signalAlign - indexing reference, done   File "./runSignalAlign", line 227, in <module>     sys.exit(main(sys.argv))   File "./runSignalAlign", line 209, in main     alignment.run()   File "/data1/ngs/programs/signalAlign/bin/signalAlignLib.py", line 796, in run     twod_read_path=temp_2d_read)   File "/data1/ngs/programs/signalAlign/bin/signalAlignLib.py", line 74, in get_npRead_2dseq_and_models     if npRead.get_twoD_event_map() and npRead.get_template_events() and npRead.get_complement_events():   File "/data1/ngs/programs/signalAlign/bin/signalAlignLib.py", line 507, in get_twoD_event_map     twoD_init = self.initialize_twoD()   File "/data1/ngs/programs/signalAlign/bin/signalAlignLib.py", line 405, in initialize_twoD     if self.fastFive["/Analyses/Basecall_2D"].attrs["dragonet version"] == "1.15.0":   File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/tmp/pip-build-vCi1L7/h5py/h5py/_objects.c:2453)   File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/tmp/pip-build-vCi1L7/h5py/h5py/_objects.c:2410)   File "/usr/local/lib/python2.7/dist-packages/h5py/_hl/group.py", line 164, in __getitem__     oid = h5o.open(self.id, self._e(name), lapl=self._lapl)   File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/tmp/pip-build-vCi1L7/h5py/h5py/_objects.c:2453)   File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/tmp/pip-build-vCi1L7/h5py/h5py/_objects.c:2410)   File "h5py/h5o.pyx", line 190, in h5py.h5o.open (/tmp/pip-build-vCi1L7/h5py/h5py/h5o.c:3502) KeyError: "Unable to open object (Object 'basecall_2d' doesn't exist)"

Hi,
I send you the offending files to your mail. please check it and help me to solve this issue.
Thanks.

Dear Rand
I am also getting the same error while running following command
Command
./runSignalAlign -d /pass/ -r reference.fasta -o runsignal_output/\
Error
Unsupported Version (1.15.0 and 1.19.0 supported)
problem making npRead for pass/minion_ecolistrain5_5_16_1340_1_ch343_read403_strand.fast5
I am looking forward from you.
Thanks and Regards
Sathish

Hi,
Please see below signalAlign error. I am not getting GOMP_4.0 installation file. Kindly send me the GOMP_4.0 installation file.
./signalMachine: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by ./signalMachine)
Command used :
/programs/ArtRand/signalAlign/bin$ ./runSignalAlign -d /programs/ArtRand/signalAlign/tests/minion_test_reads/sp -r /tests/test_sequences/sp.fasta -o /Methylation_analysis/
Thank you.
Kushal

Hello all,
The patch to fix the Metrichor version will be out today. Sorry about the delay, I have been trying to refactor the codebase for the R9 chemistry.
As for the GOMP_4.0 issue: This is likely a problem with your local c library not having the openMP headers. You could remove the -fopennp flag from include.mk in the /signalAlign/sonLib directory to fix this problem. The main slow down will be to the HDP building, but if you're only performing alignments it should hardly change performance.

Hi Rand,
Thanks a lot. I have solved GOMP_4 issue. Now it's working for test ecoli data. I have followed the manual, I run the signalAlign commands and I got the result. I have normal output (tab separated tsv files). But I am interested in methylated region, Further, how I should process using signalalign output.
Thanks
Sathish

Metrichor version 1.20.0 should work now. Make a fresh pull from branch 'master'. Let me know if there are any other problems with R7.3 data.
As for how to process the methylation data. Three is a script /signalAlign/scripts/call_methylation.py designed for this purpose. There is some explanation here: https://github.com/ArtRand/CytosineMethylationAnalysis. I'll write up a step-by-step on methylation calling and let you know when it's ready/where to find it.

Thanks a lot. Now SignalAlign is working for our data.
If you provide step by step analysis, it will be useful for users.
Best of luck
Sathish

Hi,
call_methylation.py is not working. following command used for calling methylation from signalalignment files
python call_methylation.py --input ..//tempFiles_alignment/ --ref Ecoli.fasta --out ../methylation_result/

Dear All,
Kindly guide me to run the call methylation script. As I understand following files are required to run the call methylation script.

signalalign output files.
reference sequence in fasta file
3.position file
Output file name
I want to know position file format?.

Thanks
Athul

Hello sorry about the slow response, I'm in the middle of writing a tutorial on calling methylation (and refactoring the model to work with R9).
The position file is a tab-separated file with the format
X \t position_0 \t position_1 \t ... position_N \n
X \t position_0 \t position_1 \t ... position_N \n
The first line has the positions for the template stand (the strand in the FASTA reference sequence). The second line has the positions for the complement strand (note, NOT the reverse complement). You can find an example here (https://github.com/ArtRand/CytosineMethylationAnalysis/blob/master/data/ecoli/test_sites.tsv)
Here is a python function you can use for generating a CCWGG substitute file, for example:
def make_CCGG_substitute_file(starts, seq, out_file):
    def check_starts(starts, seq, target):
        for start in starts:
            assert seq[start] == target
        return True
    if os.path.exists(out_file):
        print "Outfile you're trying to make already exists"
        return
    fH = open(out_file, 'w')
    if check_starts(starts, seq, "C"):
        fH.write("X\t")
        for start in starts:
            fH.write("{}\t".format(start))
    fH.write("\n")

    # + 2 because the starts are for the second C in CCWGG and on the complement we want to mark the the C in the motif
    rc_starts = [x + 2 for x in starts]
    if check_starts(rc_starts, seq, "G"):
        fH.write("X\t")
        for start in rc_starts:
            fH.write("{}\t".format(start))
    fH.write("\n")
    fH.close()

# this function just marks all of the base pairs in starts
def make_substitute_file(starts, seq, out_file):
    if os.path.exists(out_file):
        print "Outfile you're trying to make already exists"
        return
    fH = open(out_file, 'w')

    fH.write("X\t")
    for start in starts:
        fH.write("{}\t".format(start))
    fH.write("\n")

    fH.write("X\t")
    for start in starts:
        fH.write("{}\t".format(start))
    fH.write("\n")

    fH.close()

# makes a motif file that is passed to SignalAlign with the -q flag
def make_motif_file(starts, seq, outfile):
    if os.path.exists(outfile):
        print "Outfile you're trying to make already exists"
        return
    fH = open(outfile, 'w')
    for start in starts:
        s = start - 5
        e = start + 6
        q = seq[s:e]
        fH.write("{start}\t{end}\t{motif}\n".format(start=s, end=e, motif=q))```

The manual shows an example of how to run SignalAlign to generate methylation calls on positions in a genome: https://github.com/ArtRand/signalAlign/blob/master/Manual.md#input

Dear Rand
All the best. We are exciting to see your tutorial, Once again thanks for your continuous help. Now Call methylation script is running. I got the output. I have 2 queries.

How to interpret the call methylation output. I got following output for one read. Kindly provide me the column header

1755360	t	0.0	0.0	1.0	0.0 minion_ecoliplasmid17_5_16_4131_1_ch344_read1094_strand.sm.forward.tsv
1755362	c	0.0	0.0	0.0	1.0	minion_ecoliplasmid17_5_16_4131_1_ch344_read1094_strand.sm.forward.tsv

Call methylation script is not accepting signal align output folder but in  your manual you have mentioned that we can provide directory path. But script is accepting individual *.tsv files only.  How to solve this issue.

Regards
Sathish

Hello Sorry about the delay. Almost ready with the tutorial.
The columns are:
site \t strand \t pA \t pC \t pG \t pT \t readID (if you're running the 'variant' option)
site \t strand \t pC \t pmC \t phmC \t readID (if you're running the 'threeWay' option)
You need to pass the signalAlign output files as: ../path/to/output/*.tsv
It will all be cleaned up and easier to use v. soon.
Thanks for your patience.
A


Handle Options.scrollTop as string

Ran into an issue where I was passing in the existing $.scrollTop() value from jQuery (which returns as a string) and NanoScroll was just appending 0 (e.g. "200" became "2000") instead of converting the value to a number. This fixes that.

Seems like a reasonable change, but maybe @jamesflorentino could explain why the 0 is appended there. It's better that he takes a look at this first.

Sorry for the late reply. I initially had 0 on it. But then someone requested to add an offset value.