Replies: 7 comments 48 replies
-
I see no reason why we should remove it, not all feedbacks about it are so bad |
Beta Was this translation helpful? Give feedback.
-
|
This is my first zwave controller and I have certainly had tons of issues with it. My network is about 40 devices I believe. |
Beta Was this translation helpful? Give feedback.
-
So on the larger-ish side. We're working with Silabs to get this resolved, but it will take a while. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds great let me know if I can do anything to assist. |
Beta Was this translation helpful? Give feedback.
-
|
Right now the ball is on Silabs' side again. They have a bunch of logs they'll have to work through and understand it. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
It doesn't give accurate data about routing or even what neighbors are actually present. I am happy to give you examples of this. If it gives wrong data about those two critical sets of info, then it has much bigger opportunity for misleading people on faults, and increases mean time to repair. If you believe it's routing info is accurate, or the neighbor data is accurate, I am happy to send you examples of where it isn't, though from the various forums, people seem to acknowledge it is wrong in both of those aspects. But if you disagree with that I am happy to send the data. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know about battery powered devices, but I think the network graph is great. Can you please share some examples of why do you believe it's bad? I personally would love to have SNR information for neighbours: the network graph should show information about the best SNR available for direct paths, 1 hop paths, 2 hop etc. I have some nodes with a terrible direct path SNR which fakes you into believing they are in direct range, while in reality most of the times they operate in 1 hope paths. That would be a really nice addition. |
Beta Was this translation helpful? Give feedback.
-
|
The graph is very pretty. It's also totally disconnected from what is actually happening in the network. For example, mine regularly shows battery powered yale locks as routing nodes, which they can't be. The neighbor info is also wrong. I see nodes that only show no neighbors, but they can be communicated with, so that is also wrong. There is almost nothing correct in the graph, at least in my setup. The SNR data would be nice, but much more important is getting the neighbor and routing data to be presented correctly. I had given examples in this ticket at the start, but you can look at the forums and see many many complaints on this, and even some of the core HA devs agreeing the network graph is incorrect. The core zwavejs code doesn't seem to get this data right either, but displaying wrong data is far worse than not having a graph. |
Beta Was this translation helpful? Give feedback.
-
|
Are you saying that the neighbors information from zwave-js is plain wrong? Do you have any data to back it up? |
Beta Was this translation helpful? Give feedback.
-
|
ATM what I show in that graph is what comes from zwavejs. If data is not correct means there is something wrong on zwave-js side or maybe the controller has some problem/bug. Only @AlCalzone can say more about this |
Beta Was this translation helpful? Give feedback.
-
|
I will start adding my battery powered devices in a couple of days, I'll let you know if I notice any issue with the neighbors, because so far it seemed pretty accurate. On the contrary for the battery powered devices I will rely heavily on the network graph because most of them will be out of direct reach. |
Beta Was this translation helpful? Give feedback.
-
|
I am the OP. Here is a nice pic to show you some of the issues: Note the battery powered poolhouse door and side door yale locks are shown as routers, which they can't be. The rec room lock says it has no neighbors when I mouse over it, though it still works, yet obviously has a route. It may be that zwavejs has good data and the graph is not displaying it properly, but the data represented in the graph is very often wrong. See these threads for supplemental info: https://community.home-assistant.io/t/z-wave-graph-without-the-python/64275/461 https://community.home-assistant.io/t/zwavejs2mqtt-ui-seems-disconnected/297741 https://community.home-assistant.io/t/zwavejs-routing-through-battery-powered-locks/321402/20 https://community.home-assistant.io/t/70-zwave-device-network-stuck-healing-for-over-24hrs/332425/23 There are others, but you can get the general feel for widespread issues with the network graph. |
Beta Was this translation helpful? Give feedback.
-
|
zwavejs2mqtt: 5.6.0 |
Beta Was this translation helpful? Give feedback.
-
|
Could you give a try to https://github.com/zwave-js/zwavejs2mqtt/releases/tag/v5.6.1 or a newer version? There has been a fix in the forwarding checks for battery devices |
Beta Was this translation helpful? Give feedback.
-
Aside from the issue that battery powered nodes should not be displayed as routing, I can assure you, the info that zwave-js has access to is also wrong very often. People seem to focus too hard on this graph IMO. It doesn't tell you much, except which node sees which neighbors, as long as the controller has this information already (which it might not). It does not tell you which routes are being used, it does not tell you how well the nodes see each other. And sometimes, routes are actually being used that seem impossible by looking at the graph. |
Beta Was this translation helpful? Give feedback.
-
|
Al, that is consistent with many comments on the forums. ZwaveJS is materially much worse in terms of any real info about the Zwave Mesh than is available from Homeseer or even Hubitat. I came from Homeseer, and it told me the actual routing and data rates of each link, and even allowed me to manually specify a return route (I think routes in Zwave do not have to be symmetrical). Both of these companies have relationships with silicon labs, so not clear if they have special access to drivers etc... I think I finally have my configuration stable (it was stable when I converted from Homeseer, but I started breaking things when I saw the network graph showing routing that was much different than before), else I would probably have migrated everything to my hubitat Zwave radio. All this bad data is why the graph is so misleading and causes people to waste time and break things trying to fix routing and bad connectivity. Better to have no data than wrong data. Oh, I did upgrade to the latest version. Now the rec room lock is showing 1 neighbor, but the graph still shows routing through battery powered locks which is impossible:
|
Beta Was this translation helpful? Give feedback.
-
That would be highly desirable of course, but the current implementation is still better than nothing IMO (minus the bugs, which must be fixed). |
Beta Was this translation helpful? Give feedback.
-
|
PS I often do check version on the zwavejs2mqtt instance that runs on a raspberry pi. It didn't tell me that there was a new version, or at least if it did I missed it. When I initiate the check, what is supposed to happen if an upgrade is available? |
Beta Was this translation helpful? Give feedback.
-
|
The new version is just for config files updates, not for zwavejs2mqtt updates |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I get it. Thanks. Is HA supposed to prompt you that there is a zwave2mqtt update available? How are users supposed to know an update to the docker is available? |
Beta Was this translation helpful? Give feedback.
-
|
@frenck is the hass addon maintainer and maybe could answer to this, I have no clue |
Beta Was this translation helpful? Give feedback.
-
If you are using the Community Addon, then the Supervisor will notify you, or might even be able to auto-upgrade. It sounds like you are using a standalone Docker installation? In that case, since this project has no relation to the HA project, there's no reason HA would notify you of a new release. There are probably a ton of ways to auto-update containers or get notifications, but see Watchtower or Diun for some popular examples. I personally use Github notifications. You can watch releases for this project and get an email anytime a release is published. The docker image will be available either before the email is sent, or maybe soon after. When I get an email I check the release notes, and update the image and re-create the container if I actually need the update. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply. Yes, I run zwavejs2mqtt on a raspberry pi located in the central part of the house closest to the devices, as opposed to my HA instance, which runs as a guest VM on a computer in the basement. This allows me to not to need USB passthrough etc... on the VM. Same with deconz driving zigbee. Ok, so sounds like there is no notification of updates in the zwavejs2mqtt UI, or a flag via websockets to drive a HA notification? I'll try the github approach. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, attached is the help file from Homeseer's zwave controller utility. This is for HS3 and a bit dated, but you can see the functionality that is built into that system for Zwave support. What version of the Silicon Labs zwave library is the current version of the zwavejs using? I think Homeseer is now using 7.14, since it fully supports the features of the 700 series stick. |
Beta Was this translation helpful? Give feedback.
-
|
You're right, I didn't consider the lack of NWI. You'll have to include the node in direct range anyways and then fix the mesh. The driver offers methods to control the TX power. I'm not sure though what the effect on inclusion will be. |
Beta Was this translation helpful? Give feedback.
-
|
I have a 700 stick, but the conversion from the 500 stick to the 700 stick was done before my switchover to ZwaveJS2MQTT. And the node that is reporting the lock as a neighbor is not the controller, but a aeotec zwave repeater. Agree that TX power is not that helpful for range, unless you have a 700 series repeater with the same TX power levels. But it does help with normal devices handling faster data rates from the controller. The repeater in my network that reports the lock as a neighbor is visible to the controller, but the lock is not. In general devices are scattered reasonably far since I use Lutron for lighting control, and zigbee for almost anything else. However, other locks that ZwaveJS says are router nodes are close to the controller. |
Beta Was this translation helpful? Give feedback.
-
Did you do anything special or just excluded the nodes on one stick and re-included on the other? Because the mentioned issue isn't specific to Z-Wave JS, but rather the 700 series stick firmware. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry if I wasn't clear. I converted from the 500 stick to the 700 stick (running 7.15) in homeseer. I then exported the security key, and brought the network into ZwaveJS2MQTT without any re-pairing. Everything seemed to work, but when I saw the map showing crazy routing and neighbors out of whack, I immediately started troubleshooting and removing and reincluding devices and moving things around. This is what actually caused a ton of instability and brokenness. So when I reached out about this on the HA forums, people told me the network graph was all wrong and not to believe what it said. Once I knew the data could not be trusted, I did a bunch of trial and error and got the network stable again over the course of a month. When I asked why such a misleading set of info was being reported, one of the mods said that HA wasn't responsible for this code and I should start a discussion here. :) |
Beta Was this translation helpful? Give feedback.
-
|
Do you still have access to HomeSeer and can check if it reports the same neighbors? |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the comments about battery devices being shown as "routers" in the default network graph view... This change modified the graph to only show devices which report Based on the driver documentation for
I'm wondering if the check should be this instead: forwards:
node.isControllerNode ||
(node.ready && !node.failed && node.isRouting && node.isListening),Should it be assumed that they will not route messages if Patio Door is a door sensor, Node 11 is a smoke alarm. Maybe the default view should be "All Edges" so there's no confusion that the network graph is not a routing graph. There's no mistaking that a node is a router in this view. I have no clue what the line colors and fill mean though.
|
Beta Was this translation helpful? Give feedback.
-
|
I think every non-controller battery device in existence is either "Routing slave" or "Enhanced 232 Slave" library type (not sure if that's what's parsed in the NIF). All the battery devices in my network, except for a portable controller, report true for isRouting, to that is obviously not the correct criteria for the graph. |
Beta Was this translation helpful? Give feedback.
-
|
I discussed this with @robertsLando about 3 weeks ago. It seems like the discussed change didn't make it into the codebase correctly: |
Beta Was this translation helpful? Give feedback.
-
|
Fixed on master now |
Beta Was this translation helpful? Give feedback.
-
HI. I just converted a zwave network from Homeseer to ZwaveJS, and the network graph was very misleading. It indicated that battery powered locks were acting as routers, and even node neighbor info in there was wrong. For example, a dome valve controller in graph says it's only neighbor is a lock (when I mouseover it), but it's still pingable and operates fine.
I know there is work going on to fix the graph, but this kind of misleading info had me chasing my tail for days and adjusting a perfectly functional network setup. From threads on the home assistant boards, it appears this is a common occurrence.
Can the network graph function be removed until it presents reliable info?
Beta Was this translation helpful? Give feedback.
All reactions