For a few months I have been interested in seeing how my Z-wave mesh network looked. Today I threw together something fairly fast for this purpose.
Sadly it’s written in PHP since I am more of a web developer. It would be much more suiting to have it in Python of course. Ultimately it should be built into the Z-wave component though, in my opinion.
Anyway. I just wanted to share my code with others who might be interested as well. Personally I pretty much wanted to see which nodes had a direct connection with the controller, and if any nodes had more than two hops.
I agree. As I wrote above, ultimately it should be written in Python and as a component. Maybe even included in the zwave-component.
But my competence with Python isn’t good enough to do it properly. Therefore I rather solved my own problem as fast as possible and published it more as a proof of concept, and as something others can use until someone makes a more proper implementation (which I hope for).
And, if you are interested, I can say that it would be amazingly useful. I regularly come across folks who’re struggling with Z-Wave. Having a graph like that accessible via the UI would massively help me (and others) in helping them.
I did misunderstand you, thanks for explaining. Frontend isn’t really my thing, though I might try to investigate how hard it would be. It’s not like my code does everything itself either, depending on external libraries and tools (GraphViz) which I don’t know if I can solve in Polymer.
I honestly feel that it’s quite self explanatory by looking at the screenshot. All green connections are connected to the controller, representing 1 hop. Lightblue 2 hops, yellow 3 hops. All solid lines are a part of shortest way to the controller, the dashed lines are not.
It also doesn’t explain what red means. In this case, it’s a battery powered remote, so it doesn’t have neighbours of its own. Mind you, I think the age of the OpenZWave log has found a feature - I’ve got a few nodes with green lines, that clearly aren’t directly from the controller.
I felt it was self explanatory with my own graph which was included. With your’s it’s definitely messier. It’s obvious that there are issues when parsing the OZW log in this case. Either because the log is wrong, because I didn’t understand it, or because there is a code error.
The red nodes are supposed to be connection-less. Afterwards I have realized that my parser of the OZW log might interpret the log as “one way connections” towards them. Ie, Node A has a connection to Node B, but Node B has no connections. Maybe there are better solutions if one analyzes the log and actually understand it. My log did not have those features when I wrote the program.
I am more interested in your NodOn actually. Since it has no connections, it should be red as far as I know. It clearly isn’t.
Regarding the green connections that are not towards the controller, it would be interested to see the lists of neighbors for “garage_closed_car” for example. Something like $ grep -E '(Node002.*Node [0-9]|Node002.*Neighbors of this node are)' OZW_Log.txt should give all relevant lines for Node002. You would have to find out which Node number the garage door has via the UI. The same data for number_sign which it’s connected to might be relevant as well, it might be a “one way connection” according to the logs. But from the top of my head I can’t figure out why it has “1 hop”.
The idea of the code is to drop all neighbors for a node whenever a new list starts. Maybe it doesn’t. Or maybe it’s something else. The code isn’t really tested, I wrote it, it worked for me, as far as I could see.
It looks more horizontal because you have a lot of nodes connecting directly to the controller (this is functionally awesome, btw). Seems as though graphviz is starting with a hierarchical tree so direction connections end up in a line closer to the controller. The only way to fix this would be to add another metric of data to move how close/far the nodes are from the controller or some type of wrapping and a fixed width to the image.