Yet Another lastWorkingRoute visualiser

[10der 830]

Please stop forcing the use this app!

Edited November 20, 2019 by 10der

[Momos 101]

On 9/11/2018 at 3:54 PM, chaicka said:

I have both the older z-wave double relay switch (FGS-222) and the newer z-wave plus double switch 2 (FGS-223). Only the newer FGS-223 is mis-behaving (not responding to z-wave mesh reconfigure and visual-mesh shows last updated 01/01/1970 despite this FGS223 module was recently re-included). @T.Konopka, possible to have a look at the FGS-223 module with firmware 3.3 if there is really something wrong with HC2 getting mesh info from FGS223?

 

I think i got to the root of this problem.  Now my zwave plus double switches are updating correctly.

 

Yesterday one my Fibaro zwave plus wall plugs started to act strange, as in not responding to any UI or LUA commands, but only to the physical button press.  After some fiddling time and hair pulling i noticed in the GUI a lock icon on the wall plug... somehow it changed its mode to secure ?!?! I never add any device in secure mode and that wall plug was working fine until yesterday.   Excluded it from the network, added it again with the default add settings (not secure) and lock icon disappeared.  Wall plug started working again from GUI/LUA.

 

Remembering the issue with the double relays..  i see they all have the freaking lock icon in the GUI .  go figure... redone above procedure an them and now they work fine and update mesh  

 

How could a device switch from non secure mode to secure by itself.. that's beyond me ...

 

 

[Cameleon 17]

This looks great, good work. Going to fire it up tonight when I get home. Now to get @FIBARO to add it to HC2  

[petergebruers 1,261]

On 10/4/2018 at 12:02 AM, Tony270570 said:

but why node 4 is the center of the world in this house ?? it's really place less then 2 meter from the HC2 does it mean that I need to move the HC2 to get a better communication with all those device ? I'll also try this, I've got a stronger antenna and I'll connect it tonight !!! 

 

Node 4 is the most used repeater (I deliberately use "repeater" and not "router") because it has the lowest NODE id. Node ID is on the advanced page of your device. It is NOT the device ID, but usually,and very likely, it has a low device ID as well... Because when you add your first device, it gets Node ID 2 (the first one available after Node 1 = the controller) and the first available device ID is 4. But in my case, it is this one:

 

 

nodeId: 3 is master 8 slave 596 is "Plafondlamp in Living."

 

Yes, you guessed it, when I rebuild my network (about 2 years ago) I added a device, then decided to replace it. So I do not have a Node ID 2 and also my first device is 8 instead of 4

 

Why did the "routing algorithm" pick that device? Because it simply tries node Id 2 ... 3 ... 4 ... until someone is "alive". It also prefers a direct connection and it also takes into account the reliability of the node, but basically it just starts at 2 and counts up. The most used repeater could be 1 meter away from your HC! If you started to build your network by adding devices close to your HC, it probably is within a few meters... Which might seem odd but if the device works, that's good enough.

 

Z-Wave node's have no "distance" concept. They cannot measure the distance to the HC (this is a little white lie) and because of that they only see two kinds of devices. If they are reachable, they are neighbors. And if those other devices do not respond to a "ping" command and don't ever send data to you (because they are far away or you unplugged them) then they are NOT neighbors. If a neighbor is mains powered, it is a "candidate repeater".

 

The controller (and all of its secondaries, but they are likely battery powered so they do not repeat messages) is the only device that gets a "view" of all the possible neighbors. So it is able to show this data. Also, when you do "mesh update" aka "neighbor update" the controller sends back possible routes to the device. This "primes" the device with routes that should work. The number of possible routes depends on the SDK version that built the device. So it depends on its age and some design decisions. I do not know all the answers, this part of Z-Wave is undocumented and all I know is deduced from some publications and observing the network with a sniffer.

 

When you power down the that most used repeater, you'll notice delays. Not always, and not necessarily on the devices that you expect. Devices that cannot have a direct connection, will retry and find alternatives amongst the routes (the ones it got from the HC when you last did "update neighbors") or simply walk all ids... 2 ... 3 ... and some devices (afaik all Z-Wave Plus devices but also some older ones) can try a kind of broadcast as a last resort.

 

I think some devices simply learn and store the newer route(s) and not much will happen. I haven't done a lot of testing. I think older devices might keep trying a direct connect and also try non-working routes... Those are the ones that really need a "update mesh". Because (a) it will learn node X is no longer there (b) the controller will give it new routes. I think that is the reason why 4.5XX started to do a daily mesh update.

 

BTW it is possible to "orphan" a node if you remove a repeater, but it is rare. I was able to get such a situation by moving an FGMS so it only really had two or three possible neighbors. When I cut power of one of them, it could no longer be reached from the HC2. So in this particular case, if you try "mesh update" on that FGMS nothing will happen. Because the device might not be able to hear the command. You would think the HC2 can always broadcast and find a repeater but I was able to prove that did not happen. I tested this long time ago and at that time I did not have a Z-Wave sniffer. The only solution is to bring the HC closer to the device. Or the other way around, but in that case you risk it gets out of reach again.
 

EDIT: I left out some details and I do not claim I know everything... If you do some research, you'll find Z-Wave networks can have a SIS server (or SUC, but that is older and SIS implies SUC) to manage routes. AFAIK the HC cannot have this role. See "Implementing SUC/SIS support" in "Z-Wave 500 Series Appl. Programmers Guide". Somewhere in that text they explain why low node ids act as repeaters: <<<The lost battery operated routing slave start(s) to send “I’m lost” frames to each node beginning with nodeID = 1. It continues until it find a routing slave which can help it>>>

Edited October 15, 2018 by petergebruers

[10der 830]

I was just thinking out loud.... why Forum doesn’t have FAQ topic? IMHO such posts like Peter’s posts should or must be in FAQ chapter 

Edited October 15, 2018 by 10der

[Tony270570 92]

@petergebruers thank you for those explanations, for sure I still have a lot to learn !

[petergebruers 1,261]

On 10/15/2018 at 1:07 PM, 10der said:

IMHO such posts like Peter’s posts should or must be in FAQ chapter 

Thanks for the (hidden) compliment...

 

1 hour ago, Tony270570 said:

thank you for those explanations, for sure I still have a lot to learn !

I'd say (a) for most people mesh routing just works, so you can study the subject because it interests you or you are really unlucky and have to diagnose your mesh routing (b) there aren't many good resources to learn. There is a book by Dr Paetz but it is a bit outdated (edit: not "outdated" at all but it not updated in a while, eg does not cover Z-Wave Plus) and does not have a lot of detail when it comes to routing. (C) You really need a Z-niffer to diagnose, this LWR/NBR thing is for guidance only.

 

BTW I wrote this script "for internal use", but since quite a few users want to know more I've decided to update it and publish it

 

It displays LWR and NBR but also detects "controllers" and to get an idea of the "age" of the device I've also added Z-Wave version and SDK. Be careful, higher SDK number does not mean more recent.. The "5" series largely ran in parallel with the "4" series. The "Protocol" number gives a better indication of age.

 

Please login or register to see this code.

Script:

Please login or register to see this attachment.

Edited October 16, 2018 by petergebruers

[Kage 36]

Thanks Peter, still learning a lot here.

 

Can you explane maybe this "status and then the error"

They working correctly 

 

Mastr LWR                 Status Timestamp            Neighbors           Status Timestamp              Node Slave   Proto SDK   Name of a slave, library type
   89 1                        ok 2018-10-17 03:19:05  56:1,91,93,...          ok        2018-10-17 03:19:05 =     2    4  2,78==5.02 P3 "Woonkamerlamp in Woonkamer" - Basic Routing Slave.
   91 1                        ok 2018-10-17 03:00:33  66:1,89,93,...          ok        2018-10-17 03:00:33 =     4    5  3,52==4.54.02 "Subwoofer in Woonkamer" - Enhanced Routing Slave.
   93 1                        ok 2018-10-17 03:00:58  71:1,89,91,...          ok       2018-10-17 03:00:58 =     5    6  3,52==4.54.02 "Openhaardlamp in Woonkamer" - Enhanced Routing Slave.
   95 1                        ok 2018-10-17 03:01:15  77:1,93,97,...          ok       2018-10-17 03:01:15 =     7    7  3,52==4.54.02 "Eettafellamp in Woonkeuken" - Enhanced Routing Slave.
   97 1                        ok 2018-10-17 03:01:42  52:1,91,95,...          ok       2018-10-17 03:01:41 =     8    8  2,78==5.02 P3 "Keukenkastonderlamp in Woonkeuken" - Basic Routing Slave.
   99 1                        ok 2018-10-17 03:02:03  64:1,91,93,...          ok       2018-10-17 03:02:03 =     9    9  2,78==5.02 P3 "Keukenkastbovenlamp in Woonkeuken" - Basic Routing Slave.
  101 1                       ok 2018-10-17 08:02:08  44:1,89,91,...       error      2018-10-16 08:02:16 =    19   10   4,5==6.51.06 "Overlooprookmelder in Overloop" - Enhanced Routing Slave.
  103 1                       ok 2018-10-17 03:34:23  27:1,89,91,...       error     2018-10-05 02:15:17 =    20   11  3,67==4.55.00 "Woonkeukeneye in Woonkeuken" - Enhanced Routing Slave.
  105 1                       ok 2018-10-17 04:00:47  11:1,91,93,...       error     2018-10-05 02:15:18 =    21   12  3,67==4.55.00 "Woonkamereye in Woonkamer" - Enhanced Routing Slave.
  107 1                       ok 2018-10-17 05:17:01  15:1,93,95,...       error     2018-10-05 02:15:19 =    22   13  3,67==4.55.00 "Haleye in Hal" - Enhanced Routing Slave.
  109 1,95,408          ok 2018-10-17 03:02:30  51:93,95,97,...         ok     2018-10-17 03:02:30 =    23   14  3,52==4.54.02 "Schuurkoelkast in Schuur" - Enhanced Routing Slave.
  111 1                       ok 2018-10-17 03:03:02  53:1,89,91,...          ok      2018-10-17 03:03:02 =    24   15  3,52==4.54.02 "Multimedia in Woonkamer" - Enhanced Routing Slave.

[petergebruers 1,261]

When the HC2 asks the device to update its neighbors, that process sometimes fails. It is not about a failing device, it is about failing to do or respond to that "update command". It might surprise you, but a small % of these "mesh updates" just fails and this may be a random thing. I'd save the report and see what changes tomorrow.

 

Some devices have trouble responding to that auto mesh update, AFAIK these are possible causes and fixes:

• @Momos had consistently failing FGS-223, they displayed a "lock" symbol meaning "secure mode" but he says he never included any in secure mode. You might want to check the browser, see if the title bar of the device show a padlock icon.
• It might fail due to interference, either noise or too many things going on
• Battery devices need to "wake up". If you have disabled wake up (set to 0) or set it very high this might happen. Try to wake it up by clicking the button, wait 20 seconds then run that report again. Also bear in mind the command is queued at 03:00... Suppose Wake up interval is 12 h, then the actual update might happen at 15:00. If you run your report before it has updated, you'll see missing or older data. This might be the case for "Overlooprookmelder in Overloop".
• Try "mesh update" on the Configuration, Z-Wave page in your browser. Select a master or a slave of this device and observe the status window at the top.
• Something went wrong when the device was included. Try exclude (remove) and include (add) device. That is annoying because you get new IDs but some things get set during inclusion so there is no other way and it is easy to try.
• Probably, some device firmwares are buggy. Some devices are slow to respond and the HC might not wait long enough.

The number of neighbors looks good to me, and also length of LWR is OK. Judging by its name device 109 is in a shed outside, so 1,95,408 seems plausible.

 

Here's a battery operated device from my network that fails the mesh reconfigure

 

Please login or register to see this code.

When I do a manual mesh reconfigure:

Please login or register to see this code.

I tried to replace the battery because is says < 50%... Nope, still failed.

Exclude and include: the HC2 receives a neigbor list. But when I try a manual mesh reconfigure...

Please login or register to see this code.

Oh! Well! I guess I'll have to investigate that! Long shot: I guess this is a "slow" device. But I do not worry too much: the device is working, has plenty of neighbors (41) and uses a direct connection. Like before... Nothing to worry about.

[Cameleon 17]

Does anyone else get devices that are down as Undefined or the room is Undefined? I get a few, and it appears to be those with multiple slaves. I cant post up the example as I am work atm and don't have remote access to the web server that runs the visualisation script. 

 

Note - I did notice the script has a typo - you have Undeined instead of Undefined  

[10der 830]

10 minutes ago, Cameleon said:

you have Undeined instead of Undefined

fixed. thank you!

can you update index.html from 1st post? 

 

 

[Cameleon 17]

37 minutes ago, 10der said:

fixed. thank you!

can you update index.html from 1st post? 

 

 

I'll give it a go when I get home

[AndyY 11]

6 hours ago, Cameleon said:

Does anyone else get devices that are down as Undefined or the room is Undefined? I get a few, and it appears to be those with multiple slaves.

 

Hello @Cameleon

 

I had some hidden devices shown as 'undefined'. I found following section in html code and uncommented this line '//el.visible &&':

Please login or register to see this code.

This solves my problem with undefined devices. Maybe this helps you too...

[Cameleon 17]

el.visible is already uncommented on my version. 

 

Tried the new version and no change. I had been trying various (albeit not to logical) changes to some master/slaves and managed to get one more to show which room its in. But no idea what change made it work as trying the same on other devices that show 'undefined' made no difference. Does changing the room/visibility/etc show up straight away in a refresh of the devices API call? Doing a diff on the response there does appear to be changes. 

 

Any way to debug the code?

[10der 830]

2 hours ago, Cameleon said:

Any way to debug the code?

 

 

yep! 

 

in html code put 

console.log("aaaa");

in browser F12 / show Console tab

 

in the code you may put console.log("aaaa"); as you want... to what happened. 

 

about undefined room., it's can happen only if no slave devices... I do not know how it's can happen cuz all Fibaro devices should have at least 2 (two) device items for the device should.

 

                // Oops!
                if (slaves.length === 0) return dev.id + ":" + "undefined";
 

 

 

btw, the root issue here function getDeviceName(dev) {

btw2: 

how I trying to find room and device name by master id: 

 

MasterId 777 ( hidden, usually without a name and assigned room)

   Id 778 - Main Switch in WC room

 

so,  html scrip trying to get 1st slaved device (778) and get from this device name and room name.

 

   

 

[lroovers 0]

Nice job!

 

In changed line 20 to below so its in dutch and gives some info about the colors.

 

    <p>
    <span style="color:#ff0000;">Normaal</span> | <span style="color:#d3d3d3;">Batterij</span> | <span style="color:#adadad;">zwaveWakeup</span> | <span style="color:Violet;">Emty route</span> 
        Voer device id in (zie Mouse over): <input type="text" id="selection" value=""><input type="button" id="select" value="Toon Route"><br>
    </p>

[Cameleon 17]

7 hours ago, 10der said:

 

yep! 

 

in html code put 

console.log("aaaa");

in browser F12 / show Console tab

 

in the code you may put console.log("aaaa"); as you want... to what happened. 

 

about undefined room., it's can happen only if no slave devices... I do not know how it's can happen cuz all Fibaro devices should have at least 2 (two) device items for the device should.

 

                // Oops!
                if (slaves.length === 0) return dev.id + ":" + "undefined";
 

 

 

btw, the root issue here function getDeviceName(dev) {

btw2: 

how I trying to find room and device name by master id: 

 

MasterId 777 ( hidden, usually without a name and assigned room)

   Id 778 - Main Switch in WC room

 

so,  html scrip trying to get 1st slaved device (778) and get from this device name and room name.

 

   

 

I have a feeling its the devices where the actual slave we want isn't the first slave, so may have to loop through them to find the valid one. I tried to make the other slaves hidden but that only seemed to work for one of them which is a bit confusing. I'll have a go at debugging. 

[10der 830]

if you have a device with MasterId and disabled Slave you will get, yes, undefined. otherwise, I do not need loop cuz I filtered slave list by only visible and not disabled devices...

[chaicka 195]

@Momos

Nice catch and sharing.

 

Unfortunately, my unresolved case on the Double Switch 2 is not due to 'secured' mode as there is no 'lock icon' on any of its node/endpoints (be it show and hidden). Now that I have jumped onto the 4.511 Beta, will find time to exclude and re-include again and see if this time round, it gets resolved.

[chaicka 195]

Guys, is this graphical representation still working with HC2 4.530?

 

I am seeing nothing after updating to 4.530.

[petergebruers 1,261]

14 minutes ago, chaicka said:

Guys, is this graphical representation still working with HC2 4.530?

I don't know, but my non-graphical version is still working. Which suggests there were no fundamental changes on 4.530...

 

Please login or register to see this attachment.