Zwavejs2mqtt: [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 [email protected]

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

[email protected]

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

[bushvin]

@robertsLando what severity level? Debug, or Silly?

[robertsLando]

Silly

[AlCalzone]

Yeah the controller is handled differently than other nodes, so I'll need to see a log that includes the startup

[bushvin]

I'm not sure if there's a difference in logs generated after changing settings and saving them or after a restart of the container.
This is the log generated after changing settings and saving them.
Also restarted the container to grab those logs, but I'd like to keep it running a while until all battery nodes have dialed home.
zwavejs_1.log.gz

[bushvin]

And by the way, I'm running zwavejs/zwavejs2mqtt:3.0.3

[AlCalzone]

Hm, for some reason your controller has

"isListening": false

which could explain what's happening. I don't know how this can be. I think I'll need to see the log from the re-interview too.

[robertsLando]

The main problem is that I fixed that but then now also never get ready event

[AlCalzone]

Yeah, that causes the node to never get marked as alive. This is just plain wrong for a controller - could be an indication of memory corruption on the stick.

[bushvin]

The stick is a zwave.me UZB1 stick, however lsusb tells me otherwise:
Bus 001 Device 006: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
But maybe they use the same chipset...
If you would need to recommend a controller, which would you recommend?

[bushvin]

Here's the logs after restarting the container, including a re-interview of the controller (Node 001)

zwavejs_1.log.gz

[AlCalzone]

Are you sure this is the correct log? I don't see a re-interview.

If that re-interview confirms the suspicion, you could hard-reset the controller. This will reset the corrupted NVM, but also means you'll have to re-pair your entire network.

If you would need to recommend a controller, which would you recommend?

Probably one of the new 700-series ones.

[bushvin]

This is awkward... I copied the old log. sorry about that, here's the right one
I believe it starts at 2021-04-08T13:07:00.454Z
zwavejs_1.log.gz

[AlCalzone]

Yup, that one's memory is toast. I've marked the lines that should be different with a *:

2021-04-08T13:07:00.562Z CNTRLR « [Node 001] received response for protocol info:
                                  basic device class:    Slave *
                                  generic device class:  UNKNOWN (0xbe) *
                                  specific device class: Unused (?)
                                  node type:             Controller
                                  is always listening:   false *
                                  is frequent listening: false
                                  can route messages:    false (?)
                                  supports security:     true
                                  supports beaming:      false
                                  maximum data rate:     100000 kbps
                                  protocol version:      2 *

[bushvin]

poodoo!

allright. I know what to do the coming weeks.

From what I saw checking zwavejs2mqtt doesn't support multiple controllers on a single container. Reckon it will work if I have 2 containers each with a dedicated controller (and volumes, and ports, obviously)?

700-series aren't even released it seems :(

[AlCalzone]

From what I saw checking zwavejs2mqtt doesn't support multiple controllers on a single container. Reckon it will work if I have 2 containers each with a dedicated controller (and volumes, and ports, obviously)?

@robertsLando I guess 2 containers it is?

700-series aren't even released it seems :(

Oh... I think some peeps got their hands on some.

[robertsLando]

It works with 2 containers you just need to map them to different ports and the correct tty, that's it.

[jmgiaever]

poodoo!

allright. I know what to do the coming weeks.

From what I saw checking zwavejs2mqtt doesn't support multiple controllers on a single container. Reckon it will work if I have 2 containers each with a dedicated controller (and volumes, and ports, obviously)?

700-series aren't even released it seems :(

I bought mine at DigiKey, it's not Aeotec though and I haven't tested it. But I got the link from another HA user that said it worked great.

[bushvin]

Thanks, @jmgiaever , I found a shop closer to home with the same part: mouser

Rather surprised by it's cheap price.

[DayRunner131]

@robertsLando, was this fix integrated into a ZwaveJS2Mqtt v3.5.0? I'm encountering the flat lined Network Graph too and have recently updated to v3.5.0.

[robertsLando]

Please provide me your dump. Just press on advanced button on control panel UI

[DayRunner131]

Thanks for looking into this.

nodes_dump.json.txt

[robertsLando]

Same problem, the controller node has no neighbors:

"neighbors": [],

@AlCalzone What could be the cause?

@DayRunner131 Could you kindly provide also zwavejs log file please? Remember to set log level to debug

[DayRunner131]

I'm running the ZwaveJS instance in HomeAssistant. Can only dump at one level so I hope it's at the Debug you've requested.
zwave_js_dump.json.txt

[robertsLando]

nope it's not that one. Enable logs in zwave settings from zwavejs2mqtt ui, set log level to silly and log to file enabled. Now go to Store page, here you will see the zwavejs log file and you will be able to download it

[DayRunner131]

OK, that was my second choice. I only enabled logging to file this morning, so it's only got about an hours worth of logs at the moment.

EDIT-STANDBY, wrong file

Correct one,
zwavejs_356.log

Ugg, early morning. Just saw you wanted it set to Silly. New file... now more coffee.
zwavejs_356 (2).log

[bushvin]

I may be overstepping my paygrade here, but @DayRunner131 , have you recently tried healing your controller node?

I'm setting up a new N/W and noticed the controller's neighbors didn't get updated for some reason. After healing it, my (new) N/W is no longer a flatline.

Healing your controller node may generate a lot of traffic when you have a lot of devices, if memory serves me well, so you may want to do this at an opportune moment.

[DayRunner131]

I may be overstepping my paygrade here, but @DayRunner131 , have you recently tried healing your controller node?

Yes, yesterday. Same flatline before and after.

[andyboeh]

Same problem for me, flat line before and after the upgrade to 3.5.0. My controller node has no neighbors, healed just before upgrading to 3.5.0.

[robertsLando]

@AlCalzone Seems this is a problem on zwavejs side ?

[johntdyer]

samer problem, a network heal didnt seem to help

[robertsLando]

I need nodes export to debug this @johntdyer

[DayRunner131]

@robertsLando Have you determined if all our issues are linked and are ZwaveJS2MQTT bugs?

[robertsLando]

Not easy to debug, IMO it's not a zwavejs2mqtt bug, the problem IMO is that some devices are not reporting neighbors correctly or controller is not ready (in this case could be a bug on zwavejs side too). Btw without logs and a nodes dump it's hard to debug. The first bug of this issue was solved, the others are all related to different things

[DayRunner131]

Not easy to debug, IMO it's not a zwavejs2mqtt bug, the problem IMO is that some devices are not reporting neighbors correctly or controller is not ready (in this case could be a bug on zwavejs side too). Btw without logs and a nodes dump it's hard to debug. The first bug of this issue was solved, the others are all related to different things

@robertsLando I guess I need to know where to go from here... seems others are having the same issue and I never had this problem before the update to V3.5.0+. I also see a bug report open at ZwaveJS, https://github.com/zwave-js/node-zwave-js/issues/2335 for the same issue. What more can I provide to track the issue down?

[robertsLando]

You can export a nodes dump from control panel > advanced button > export nodes

About logs you have to enable them in settings and enable log to file, then go to store UI and download those files and attach them here

[johntdyer]

_>I need nodes export to debug this @johntdyer

@robertsLando

nodes_dump.json.zip

[robertsLando]

Like the other guy this seems a controller problem, it has no neighbors. @AlCalzone I think this is related to https://github.com/zwave-js/node-zwave-js/issues/2335

@johntdyer Could you also provide zwavejs logs please?

[johntdyer]

@robertsLando how long do you need me to run in debug / silly mode ?

[dkmcgowan]

I have this same issue, I'm running inside home assistant, the controller has no neighbors, here is my nodes dump

nodes_dump.zip

[dkmcgowan]

I ended up fixing the controller on my end but noticed the network graph was still not updated, working back and forth this merge ended up getting put in

https://github.com/zwave-js/node-zwave-js/pull/2559

with this new method seems like it should get called when a node is added, removed, or the network is healed, then the neighbors list will get updated correctly

[AlCalzone]

with this new method seems like it should get called when a node is added, removed, or the network is healed, then the neighbors list will get updated correctly

No, zwavejs2mqtt is supposed to call it for all nodes and use the result to draw the network map. The neighbors property shouldn't be used anymore. I've notified the HA devs and they'll implement something on their end too.

[andyboeh]

In zwavejs2mqtt 4.2.0 and up this should be fixed, right?
I'm running 4.2.1/7.4.0 and my network graph is still a flat line. The controller node has no neighbors:

refreshNeighbors {
success: true,
message: 'Success zwave api call',
result: {
'1': [ [length]: 0 ],
'6': [ 8, 11, 12, 13, 14, 18, [length]: 6 ],
'7': [ 8, 9, 10, 11, 12, 13, 14, 18, [length]: 8 ],
'8': [ 6, 7, 9, 10, 11, 12, 13, 14, 18, [length]: 9 ],
'9': [ 7, 8, 10, 11, 12, 13, 14, 18, [length]: 8 ],
'10': [ 7, 8, 9, [length]: 3 ],
'11': [ 6, 7, 8, 9, 18, [length]: 5 ],
'12': [ 6, 7, 8, 9, 18, [length]: 5 ],
'13': [ 6, 7, 8, 9, 18, [length]: 5 ],
'14': [ 6, 7, 8, 9, 18, [length]: 5 ],
'18': [ 6, 7, 8, 9, 11, 12, 13, 14, [length]: 8 ]
}
}

Do I need to perform some sort of cleanup action or do you want me to provide more logs?

[AlCalzone]

The other nodes look pretty well connected, but the controller itself isn't seen by any nodes either.
That's a bit suspicious IMO, since it usually hints towards corruption of the stick's memory.

Have you tried a network heal? If that doesn't change anything, I'd exclude the nodes, hard-reset the stick and include the nodes again.

[andyboeh]

Thanks for the suggestion - I tried that and it worked to some degree, although the graph is still a flat line. I tried with the Sigma Designs Z-Wave PC Controller as well and the network was in either case reported as broken.

I ordered a new controller dongle.

[robertsLando]

@andyboeh Did you also tried to call the refresh node action directly from the mesh?

[andyboeh]

Yes, I tried both several times: network heal and refresh nodes directly from the mesh.

What finally made me order a new device was the fact that Z-Wave PC Controller from Sigma Designs was also unable to correctly set up a network (in fact, I also tried to build the network with this stack and it did not work). I'm sure it will work when the new device arrives - this might take a few days.

[robertsLando]

Ok let us know if replacing the controller fixes the problem :)

[andyboeh]

Replacing the controller and clearing the browser cache fixed it for me - the graph is working fine now!

[robertsLando]

clearing the browser cache

Hummm this is kinda useless as I don't store any nodes information in cache, btw glad the issue is fixed now :)

[andyboeh]

That's strange - here's the whole story:
I use Firefox on Arch Linux - relatively up to date. Only one node had a connection to the controller, all others were disconnected. I checked the log at that time and could verify that all neighbors were reported correctly.
I then tried to open the control panel in Chromium and noticed that the connection graph was correct. So I switched back to Firefox, graph was still incorrect. Then I cleared the browser cache (really only the browser cache), reloaded and the graph was correct.

[robertsLando]

Weird, all data are sent via websockets... Let's see if someone else reports this, I will investigate

[andyboeh]

Aha, I might have found something - should I open a new bug report?

After adding a device, a full page reload seems to be necessary (clearing the cache is not required). Otherwise, the neighbors of the controller node are not updated in the graph (i couldn't capture the neighbors of the controller node in the screenshot, but device 10 was missing):

[robertsLando]

@andyboeh Yes please open a new bug to keep track of that :)