Closed bushvin closed 3 years ago
Could you also attach a screenshot?
Here you go
@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
There are no messages whatsoever. I should have mentioned that I made sure there were none. Apologies.
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 :)
I'm afraid that doesn't seem to get any result except for a 404
I got the MQTT name from the settings page
@bushvin Sorry maybe I didn't explained it well, that needs to be called using MQTT
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: []}"
@bushvin How are you building z2m? Git clone?
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:
@bushvin Could you try using version 1.4.0?
This happens to me whenever the neighbors are unknown. What happens if you perform a heal?
@robertsLando Running 1.4.0 now, and still the same result
@jmgiaever Running that now. keep you posted
@jmgiaever I do see your point in having bad nodes not reporting correct info, but why would that impact all nodes? Just a thought...
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?
I sincerly never faced this problem. @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.
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"?
Are there any particular tasks you want me to perform while logging?
Zwave
Are there any particular tasks you want me to perform while logging?
Yep, re-interview one or two of the affected nodes.
Here's the log file. Hope this helps. zwavejs_1.log.gz
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.
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?
Oh sorry I didn't see that. Not a problem on my end then :)
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?
I have now!
And still a flatline
@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?
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.
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
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?
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)
@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 ?
tbh, you should assume that the controller always listens.
PR ready. @bushvin Could you give it a try?
@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
I run docker... is it the 2.1.0 ?
Instead of 2.1.0
use master
tag in your docker-comopse
image: zwavejs/zwavejs2mqtt:master
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?
Wait until this ends: https://github.com/zwave-js/zwavejs2mqtt/actions/runs/614731828 then repull master
It seems the graph works now! Yay. Any idea when it will become stable? I prerer to fix my versions in docker
Starting from 2.1.1
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
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?
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
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.
Humm with zwavejs 7 some properties have changed so could be that , let me investigate
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?
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...
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.
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?
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?