[question] Network Graph is a flat line

[bushvin]

I have recently adopted ZwaveJS2MQTT, and everything seems to work.

I took the time to perform cleanups, as previous Zwave Control Panels lacked some cleanup features.

My network Graph is a flat line with the controller to the left (in the right purple colour) and all other nodes to the right in grey. Grey seems to indicate they are not connected, however I can assure you they are, as I can control my nodes

I have not checked all nodes, but those I did, did have 'neighbors' (in the debug section of a node).

I have attached the debug info of my Zwave controller (a Z-Wave.ME UZB) and one of the nodes for reference.

controller.json.txt node-006.json.txt

I have tested it on Firefox v85.0.1 and Chromium v88.0.4324.150

Any pointers?

[robertsLando]

Could you also attach a screenshot?

[bushvin]

Here you go

[robertsLando]

@bushvin While you have browser open try to press F12 (chrome) and check if there are errors on console. If so send me a screenshot or the logs you find there

[bushvin]

There are no messages whatsoever. I should have mentioned that I made sure there were none. Apologies.

[robertsLando]

Hummm strange. I would need a nodes dump so, you could use mqtt apis and require getNodes api https://zwave-js.github.io/zwavejs2mqtt/#/guide/mqtt?id=apis

Topic <yourprefix>/_CLIENTS/ZWAVE_GATEWAY-<mqtt name>/api/getNodes/set Payload: {args: []}

You should get the nodes on <yourprefix>/_CLIENTS/ZWAVE_GATEWAY-<mqtt name>/api/getNodes

I know it's not so user friendly right now but I may addd a button on UI to download a bump in future :)

[bushvin]

I'm afraid that doesn't seem to get any result except for a 404

I got the MQTT name from the settings page

[robertsLando]

@bushvin Sorry maybe I didn't explained it well, that needs to be called using MQTT

[bushvin]

Ah... my bad... :/

For future reference these were the commands executed:

To log to file: mosquitto_sub -h mosquitto -p 1883 -u zwavejs2mqtt -P ******** -t 'zwave/#' -d |tee -a zwavejs@mqtt.log

To send the command: mosquitto_pub -h mosquitto -p 1883 -u zwavejs2mqtt -P ******** -t 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwavejs2mqtt/api/getNodes/set' -m "{args: []}"

zwavejs@mqtt.log

[robertsLando]

@bushvin How are you building z2m? Git clone?

[bushvin]

not building, running it in Docker

---
version: '3.7'
services:
  zwavejs2mqtt:
    container_name: zwavejs2mqtt
    image: zwavejs/zwavejs2mqtt:1.2.3
    restart: always
    tty: true
    stop_signal: SIGINT
    networks:
      - zwavejs
    devices:
      - '/dev/ttyACM0:/dev/ttyACM0'
    volumes:
      - zwavejs_store:/usr/src/app/store
    ports:
      - '8091:8091'
networks:
  zwavejs:
volumes:
  zwavejs_store:

[robertsLando]

@bushvin Could you try using version 1.4.0?

[jmgiaever]

This happens to me whenever the neighbors are unknown. What happens if you perform a heal?

[bushvin]

@robertsLando Running 1.4.0 now, and still the same result

@jmgiaever Running that now. keep you posted

[bushvin]

@jmgiaever I do see your point in having bad nodes not reporting correct info, but why would that impact all nodes? Just a thought...

[bushvin]

The "Network Heal" didn't "cure" the issue. But what I did discover, is that 2 nodes seem to be off They do not report, and I cannot heal them 28 and 48. Is it possible these are causing the issue?

[robertsLando]

I sincerly never faced this problem. @AlCalzone ?

[AlCalzone]

Please make a zwave-js log, loglevel debug or silly and attach it here as a file.

That log should probably include a re-interview of an affected node.

[bushvin]

Apologies for my absence. I made sure all dead nodes are gone, so now I only have live nodes.

The graph still shows a "flatline"

Which logs would you like me to put to "silly"?

• General
• Zwave

Are there any particular tasks you want me to perform while logging?

[robertsLando]

Zwave

[AlCalzone]

Are there any particular tasks you want me to perform while logging?

Yep, re-interview one or two of the affected nodes.

[bushvin]

Here's the log file. Hope this helps. zwavejs_1.log.gz

[AlCalzone]

Seems that at least node 6 knows its neighbors:

13:07:27.468 CNTRLR « [Node 006]   node neighbors received: 1, 9, 10, 11, 29, 30, 38, 42, 44, 48, 61
                      , 62, 77, 78, 79, 80, 81, 82, 85, 87, 89, 90, 91, 92, 93, 96, 97, 108, 109, 14
                      2
13:07:27.468 CNTRLR   [Node 006] Interview stage completed: Neighbors
13:07:27.491 CNTRLR   [Node 006] Interview completed
13:07:27.514 CNTRLR   [Node 006] The node is ready to be used

Not sure if it was this way before too.

[bushvin]

Well, that was also in one of my original posts here. The debug information of the nodes show they do know their neighbours.Is there a way to debug the graph through the web console?

[AlCalzone]

Oh sorry I didn't see that. Not a problem on my end then :)

[robertsLando]

The debug information of the nodes show they do know their neighbours. Is there a way to debug the graph through the web console?

Have you updated to latest 2.0.1 version?

[bushvin]

I have now!

And still a flatline

[robertsLando]

@bushvin Ok seems I have found the problem here but I'm not 100% sure about the solution. ATM to draw a connection I check if a node can forward packets, the forward property is evaluated by node.ready && !node.failed && node.isListening the problem is that ALL your devices have the property isListening set to false. If I remove isListening from the previous formula I get this chart:

Now the question is, would it be ok to remove the isListening from that formula or is it better to keep it there so a user actually know if a device is forwardning packets or not?

[AlCalzone]

would it be ok to remove the isListening from that formula or is it better to keep it there so a user actually know if a device is forwardning packets or not?

It might give a false sense of safety if you think Node X is reachable via Y and Z, although it is actually not because Y and Z are sleeping 99.9% of the time.

[robertsLando]

Update: Based on my last finding seems the main problem is that the controller actually has isListening set to false, If I manually set the controller isListening property to true everything is fine. The question so now is: Why does the controller has that property set to false??

Controller dump:

{
        "id": 1,
        "deviceId": "277-1-1024",
        "manufacturer": "Z-Wave.Me",
        "manufacturerId": 277,
        "productType": 1024,
        "productId": 1,
        "name": "",
        "loc": "",
        "values": [],
        "groups": [],
        "neighbors": [
            6,
            10,
            29,
            30,
            38,
            42,
            44
        ],
        "ready": true,
        "available": false,
        "hassDevices": {},
        "failed": false,
        "lastActive": 1614089541582,
        "interviewCompleted": true,
        "isBeaming": false,
        "isSecure": true,
        "keepAwake": false,
        "maxBaudRate": null,
        "isRouting": false,
        "isFrequentListening": false,
        "isListening": false,
        "status": "Awake",
        "interviewStage": "Complete",
        "productLabel": "UZB",
        "productDescription": "Z-Wave USB Stick",
        "zwaveVersion": 3,
        "deviceClass": {
            "basic": 3,
            "generic": 190,
            "specific": 0
        },
        "hexId": "0x0115-0x0001-0x0400"
    },

@bushvin Please attach a zwavejs log with loglevel set to debug so @AlCalzone can understand if it's a device issue or whatelse

[AlCalzone]

That information only appears if the controller is re-interviewed. I'm not certain that it is important. Maybe a portable controller stick that started the network while not USB powered?

[bushvin]

This is really weird... I have this stick, but lsusb tells me it's this one

I did have the aeotec a long time ago, but I migrated off to this new one after the aeotec started to go faulty... But maybe the chipset is just the same or similar?

This is what lsusb tells me about the stick: Aeotec Z-Stick Gen5 (ZW090) - UZB

Bus 001 Device 003: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0658 Sigma Designs, Inc.
  idProduct          0x0200 Aeotec Z-Stick Gen5 (ZW090) - UZB
  bcdDevice            0.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 1 12345678-9012-3456-7890-123456789012
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0043
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x00
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0000
  (Bus Powered)

[robertsLando]

@bushvin I could do a brutal fix and say that controller always forward but I think this could be both a device issue or something not correctly handled on zwavejs side. @AlCalzone ?

[AlCalzone]

tbh, you should assume that the controller always listens.

[robertsLando]

PR ready. @bushvin Could you give it a try?

[robertsLando]

@bushvin I have merged it with master so you can use tag master to test it. I'm quite sure that will fix your problem as it was fixed on my side

[bushvin]

I run docker... is it the 2.1.0 ?

[robertsLando]

Instead of 2.1.0 use master tag in your docker-comopse

image: zwavejs/zwavejs2mqtt:master

[bushvin]

I updated to master. The web ui tells me it's 2.1.0, I imagine that is right, but the graph is still a flatline. The devices are still being refreshed after the restart, maybe I should wait until that's completely done?

[robertsLando]

Wait until this ends: https://github.com/zwave-js/zwavejs2mqtt/actions/runs/614731828 then repull master

[bushvin]

It seems the graph works now! Yay. Any idea when it will become stable? I prerer to fix my versions in docker

[robertsLando]

Starting from 2.1.1

[Madelaide]

Is this meant to be fixed? I have the latest public updates (my app says v2.2.0, zwjs 6.6.1, zwjs server 1.1.1) but I still have a flat line. If I hover ona node they indeed list all the node's neighbours.

I note this error when I reload the graph page, but I don't know if it is related. PS: my controller node is 94, not 1.

[Violation] 'setTimeout' handler took 86ms [Violation] Forced reflow while executing JavaScript took 35ms 10[Violation] Added non-passive event listener to a scroll-blocking event. Consider marking event handler as 'passive' to make the page more responsive. See [Violation] 'setTimeout' handler took 53ms [Violation] Forced reflow while executing JavaScript took 37ms

[robertsLando]

PS: my controller node is 94, not 1.

That's the problem so, ATM I assume controller node as always 1. Could you change it's id anyway?

[Madelaide]

Okay good to know, I would love to change it back to 1, but although aeotec say it is possible, it is also likely to nuke the network as it would require removing and adding the device back (to a second zstick) until it cycles (roughly 140 times) back to node 1. So I think I'll wait until you can update it, or I eventually do it myself.

I previously managed to write a chord network graph with ozw (https://github.com/Madelaide/ZwaveChordGraph but so far haven't worked out how to tie it into the vue/mesh of the zwavejsmqtt - web/HTML is not my forte. See below

[bushvin]

Hi,

I noticed that since v 3.0.0, my graph has flatlined again. Is it possible this PR has been undone? Let me know if I need to open a new Issue.

[robertsLando]

Humm with zwavejs 7 some properties have changed so could be that , let me investigate

[robertsLando]

I have submitted a posssible fix but I didn't see anything different that could cause the break. Could you send me a node export please?

[bushvin]

Indeed, my controller has the isControllerNode property set to true:

{
    "id":1,
    "deviceId":"277-1-1024",
    "manufacturer":"Z-Wave.Me",
    "manufacturerId":277,
    "productType":1024,
    "productId":1,
    "name":"zwave_me_usb_00",
    "loc":"",
    "values":[],
    "groups":[],
    "neighbors":[29,30,38,42,44,6],
    "ready":false,
    "available":true,
    "hassDevices":{},
    "failed":false,
    "lastActive":null,
    "isSecure":true,
    "keepAwake":false,
    "maxBaudRate":null,
    "isRouting":false,
    "isFrequentListening":false,
    "isListening":false,
    "inited":false,
    "hexId":"0x0115-0x0400-0x0001",
    "dbLink":"https://devices.zwave-js.io/?jumpTo=0x0115:0x0400:0x0001:0.0",
    "productLabel":"UZB",
    "productDescription":"Z-Wave USB Stick",
    "protocolVersion":2,
    "endpointsCount":0,
    "isControllerNode":true,
    "dataRate":0,
    "deviceClass":{
        "basic":3,
        "generic":190,
        "specific":0
    },
    "status":"Unknown",
    "interviewStage":"Complete",
    "_name":"zwave_me_usb_00"
},

What I did notice, is the ready property is set to false, which leads me to believe entity.forwards is set to false in the graph. I wonder why my device is in such a state...

[bushvin]

After performing a re-interview the controller node is set as ready, and the graph works as expected. However, the device is apparently unknown now

{
    "id":1,
    "deviceId":"NaN-NaN-NaN",
    "manufacturer":"Unknown manufacturer 0xXXXX",
    "name":"zwave_me_usb_00",
    "loc":"",
    "values":[],
    "groups":[],
    "neighbors":[6,29,30,38,42,44],
    "ready":true,
    "available":true,
    "hassDevices":{},
    "failed":false,
    "lastActive":1617708868829,
    "supportsBeaming":false,
    "supportsSecurity":true,
    "isSecure":false,
    "keepAwake":false,
    "maxBaudRate":null,
    "isRouting":false,
    "isFrequentListening":false,
    "isListening":false,
    "inited":true,
    "hexId":"0xXXXX-0xXXXX-0xXXXX",
    "dbLink":"https://devices.zwave-js.io/?jumpTo=0xXXXX:0xXXXX:0xXXXX:0.0",
    "productLabel":"Unknown product 0xXXXX",
    "productDescription":"0xXXXX",
    "protocolVersion":2,
    "nodeType":0,
    "endpointsCount":0,
    "isControllerNode":true,
    "dataRate":100000,
    "deviceClass":{
        "basic":3,
        "generic":190,
        "specific":0
    },
    "status":"Awake",
    "interviewStage":"Complete",
    "_name":"zwave_me_usb_00"
}

I'm starting to wonder whether my controller is fubar.

[robertsLando]

What I did notice, is the ready property is set to false, which leads me to believe entity.forwards is set to false in the graph.

Yeah that's the problem! That's so strange, @AlCalzone any clue why that node should never trigger the ready event?

@bushvin could you provide a zwave-js log file please?