Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


  • 3

Yet Another lastWorkingRoute visualiser


10der

Question

Please stop forcing the use this app!

Edited by 10der
  • Like 7
  • Thanks 4
Link to comment
Share on other sites

Recommended Posts

  • 0

eh i don't have physical switches at those :(  through the interface the device changes state and all seems to work as it should.

BUT: mesh reconfiguration doesn't work for any other device also...and they respond to physical button change and interface updates. 

Just the little log window in the top doesn't show anything.

 

 

Link to comment
Share on other sites

  • 0
Just now, Momos said:

 Just the little log window in the top doesn't show anything

Maybe it is already queued. I think to flush the queue, you have to reboot the HC.

 

If it does not update after a reboot... Try any other node. If you can find any node that does do mesh update, I'd recommend you exclude and include that FGS. Since you got no switch on S1 I can understand that might be a tad difficult...

Link to comment
Share on other sites

  • 0

@10der, very nice visualizer. Perhaps i could gather some info regarding web servers and php and make some solution for End-users as DIY sollution (End-users who are not that technical).

 

Fibaro handle it in Installer app in slight different way.

Please login or register to see this spoiler.

Just this case is funny, becouse Wall Plug named Lampa skříň communicates through Wall plug named Zásuvka in the other room literaly on another side of building and than back to HC. Point is Wall plug named Lampa skříň is closer to HC (cca 2,5 meter, they are in the same room) and other one cca 8 meters through Wall.

 

Edited by jakub.jezek
Link to comment
Share on other sites

  • 0
Just now, jakub.jezek said:

Just this case is funny, becouse Wall Plug named Lampa skříň communicates through Wall plug named Zásuvka in the other room literaly on another side of building and than back to HC. Point is Wall plug named Lampa skříň is closer to HC (cca 2,5 meter, they are in the same room) and other one cca 8 meters through Wall.

I often get this question.

 

This is normal.

 

Z-Wave does not have the concept "distance". We humans do have spatial information. Z-wave does not

 

A "neighbor" is "a device within reach".

 

If you have a compact network, almost any node can use almost any other node as repeater.

Link to comment
Share on other sites

  • 0
9 minutes ago, petergebruers said:

If you have a compact network, almost any node can use almost any other node as repeater.

For now it is just 1st floor of my House. When it will be done and properly tested, then network will expand.

 

9 minutes ago, petergebruers said:

A "neighbor" is "a device within reach".

I know that. Also HC2 is neighbour of that Wall plug (image in spoiler below). It just use different routers. Another Wall Plug in Chodba (also named Zásuvka) uses this Lampa skříň Wall plug  as a route to HC.

 

I know about "distance", but this is just confusing. Why to accept command from different route if it is used as a hop to another.

 

Please login or register to see this spoiler.

Cool, but that image in your 1st post is great. End-users like nice images.

Edited by jakub.jezek
Link to comment
Share on other sites

  • 0
  • Inquirer
  • @jakub.jezek in anyways I have added hint :) what you asking... last updated

     

    Please login or register to see this image.

    Edited by 10der
    Link to comment
    Share on other sites

    • 0
    12 minutes ago, jakub.jezek said:

    Why to accept command from different route if it is used as a hop to another.

     

    I'm not sure what you are asking

     

    - If the device and the controller are within reach, the route is [1]

     

    - if direct connection is not possible, the "routing algorithm" selects a repeater. It prefers to use a route that worked before. If it does not know, I think it might just cycle through the list of neighbors until it finds a working repeater. The controller collects routing data and gives feedback to nodes of working and non-working stuff. This algorithm is not documented anywhere!

     

    Suppose you have 5 nodes, A to E.

     

    Suppose they are spaced out like this:

     

    A --- B -- D --- controller --- C --- E

     

    node A cannot reach the controller, but "neighbor update" tells the device: node B and D are within reach.

     

    Then it will select node B to act as a repeater.

     

    It has no concept of distance, B might be further from the controller than D. But Z-Wave does not know that.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 3 minutes ago, petergebruers said:

    node A cannot reach the controller, but "neighbor update" tells the device: node B and D are within reach.

    P. what happened if I make cut-off on B or D device? Is HC2 rebuild routing on-fly?

    Link to comment
    Share on other sites

    • 0

    check this out :)  those nodes work just fine for a long time :) in fact all system works fine 

     

    Please login or register to see this attachment.

    • Thanks 1
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • @Momos 1970y means what device never was updated... alas

    btw, nice picture. cool script :)

    Link to comment
    Share on other sites

    • 0

    i will go exclude and include one of them... for the fun of it and to see what happens

    Link to comment
    Share on other sites

    • 0

    WOW!!!

    3 minutes ago, Momos said:

    check this out :)  those nodes work just fine for a long time :) in fact all system works fine 

     

    Please login or register to see this attachment.

     

    Mine is much less complex and more clear now:

    Net3.PNG.c03ded49427f9c814ece4737ab3b20e3.PNG

    I have still to check for consistency. But It's looking great :D Anyway, thanks a lot @10der.

    Link to comment
    Share on other sites

    • 0

    So i did exclude and include one of those "purple" devices, a fibaro zwave plus double relay.  Inclusion went smooth, device is working fine, but a manual command to refresh neighbor list still doesn't do anything. works fine on other devices after reboot.

    Any thoughts ?

    Link to comment
    Share on other sites

    • 0
    1 hour ago, petergebruers said:

     

    This is normal.

     

     

    @10der, thanks for this. It looks really nice! :)

     

    @petergebruers and any other with relevant knowledge: how to use this information for our benefit? :)

    Should we try removing/adding until all devices have short routes? Should we check this when there seems to be an issue with a device?

    Thanks!

    Link to comment
    Share on other sites

    • 0

    @petergebruers

     

    About the part you mentioned mains powered modules...

    Please login or register to see this code.

    The one and only I found and it was definitely not temporary is a Fibaro FGS223 (Double Switch 2), firmware is the latest available to OTA update - v3.3 I think. No amount of mesh reconfigure for the device or the surrounding device worked/fixed the 'orphan' issue. You are right that exclude and re-include does fix it. ;)

    1 hour ago, Momos said:

    So i did exclude and include one of those "purple" devices, a fibaro zwave plus double relay.  Inclusion went smooth, device is working fine, but a manual command to refresh neighbor list still doesn't do anything. works fine on other devices after reboot.

    Any thoughts ?

     

    Is it the Double Switch 2 (FGS223)?

     

    Hmmm...I am facing the same behaviour. Reconfigure Mesh for this device simply doesn't get a new neighbour list. Mine is firmware 3.3 (the OTA firmware released just not too long ago). And it is no longer 'orphan' cause I have exclude and re-included. Still, it shows lasted update 01/01/1970 as well as it doesn't respond to the 'reconfigure mesh network' command.

    Edited by chaicka
    Link to comment
    Share on other sites

    • 0
    37 minutes ago, chaicka said:

     

    Is it the Double Switch 2 (FGS223)?

     

    Hmmm...I am facing the same behaviour. Reconfigure Mesh for this device simply doesn't get a new neighbour list. Mine is firmware 3.3 (the OTA firmware released just not too long ago). And it is no longer 'orphan' cause I have exclude and re-included. Still, it shows lasted update 01/01/1970 as well as it doesn't respond to the 'reconfigure mesh network' command.

     

    Yes same device !! and all of them are doing the same 

     

     

    Link to comment
    Share on other sites

    • 0
    6 hours ago, petergebruers said:

    It very hard to find good documentation (routing is the "secret sauce" of Z-Wave) - everything has to be tested and reverse-engineered. Some information is contradictory, in one document they say something along this line: "a controller must not use explorer frames to discover a route" and somewhere else "... controller can use explorer frame to ...". 

     

    it depends on SDK version and implementation, take older Fibaro module (e.g. UBS) and you will see how it ping 1->232 devices, take a newer one and you will see explorer frame.

     

    4 hours ago, petergebruers said:

    Z-Wave does not have the concept "distance". We humans do have spatial information. Z-wave does not

     

    it does since some time / SDK via RSSI, and combined with response time it gives some kind of best way / distance calculation, hard to observe, but when using mix of zwave / zwave plus modules in a triangle, the best route is longer than direct line of sight. But you right, somehow voodoo tech

    • Thanks 1
    Link to comment
    Share on other sites

    • 0
    3 hours ago, Momos said:

    Inclusion went smooth, device is working fine, but a manual command to refresh neighbor list still doesn't do anything. works fine on other devices after reboot.

    Thank you for trying. I do not know what could be causing this. Unless someone has a good explanation, I think it might be difficult to find out without a ZSniffer or access to your Z-Wave logs.

     

    1 hour ago, chaicka said:

    Hmmm...I am facing the same behaviour. Reconfigure Mesh for this device simply doesn't get a new neighbour list. Mine is firmware 3.3 (the OTA firmware released just not too long ago).

     

    Interesting. Let's see if we get more reports...

     

    I remember an odd problem with an FGS-223. TO be more precise, the problem seemed to affect an FGS-223 but my very well be caused by something else.

     

    @Lode notiiced... "scene events" sometimes reached the controller, but not always. I am reasonably sure the device switched between "direct" and "routed" connection.

     

    I think the issue is still unresolved:

     

     

    3 hours ago, 10der said:

    P. what happened if I make cut-off on B or D device? Is HC2 rebuild routing on-fly?

     

    Maybe I will answer that in more detail later, it is a bit complicated to get the details right.

     

    Short answer: if the A has no direct connection and knows sending data via B worked, it will make three attempts to send to B. Then it will mark node "B" as non-functional repeater. It then selects another route (if it has them in cache), tries a neighbor or if everything else fails it will try a kind of broadcast.

     

    In this scenario, the HC2 did not provide routes. In fact, it learns from the device itself it has a better route. So that is the "last working route".

     

    If the HC2 has data for some node and its routing cache says it should route over B, then the controller will try B three times, then mark that node as "a bad repeater".

     

    You will notice a delay in this case, because the node first has to find out B really does not answer.

     

    BTW if you have dead nodes, this is somewhat related to this, but "dead" is a concept at the HC software level, while "bad repeater" is a concept at the Z-Wave network layer. All this routing stuff is handled by the Z-Wave chip. The concept of a dead node only exists in the software layer of the HC. It is important not to keep sending data to offline devices, because the routing layer will keep trying all those alternatives to reach the (offline) device.

     

    25 minutes ago, tinman said:

    it depends on SDK version and implementation, take older Fibaro module (e.g. UBS) and you will see how it ping 1->232 devices, take a newer one and you will see explorer frame.

    @tinman as always, thank you for sharing your insights with us!

     

    Indeed, people think there is only Z-Wave and Z-Wave Plus but it is pretty much a constantly evolving standard! That is why we often ask "what Z-Wave version or SDK is this device". Do you know if there documents describing what features were introduced with a certain SDK?

     

    Yes, I have seen this difference between UBS and modern Z-Wave Plus device in my network too ;-)

     

    One thing though, when I said: <<<"a controller must not use explorer frames to discover a route" and somewhere else "... controller can use explorer frame to ...". >>> I was specifically talking about a *controller*, not a routing slave. If you want me too look up where they said something like "a controller must not use explorer frames" I'll try to do that. It surprised me, because you would think a controller "par excellence" should be able to use explorer frames. Maybe it indeed depends on SDK version of the controller.

     

    32 minutes ago, tinman said:

    it does since some time / SDK via RSSI, and combined with response time it gives some kind of best way / distance calculation

     

    Thanks, I left RSSI out of this discussion because I am not sure if this gives gives Z-Wave the concept of "distance" like we perceive it. From the scarce info I have, I deduced it is pretty much helping to promote or demote candidates in the routing cache... But okay... it resembles distance, but taking into account the apparent thickness and attenuation of obstacles. I forgot about the effect of response time, thank you for reminding me. Which is not something we humans see as "distance".

     

    This is intriguing stuff, isn't it?

     

    3 hours ago, 3JL said:

    @petergebruers and any other with relevant knowledge: how to use this information for our benefit? :)

    My answer might surprise you, but I think it is not... very... useful... as a diagnostic tool. Mostly... "red herrings".

    It looks great though.

     

    I wonder, did any one diagnose slow response with this LWR graph? Or find any other problem? And fix it?

    • Thanks 1
    Link to comment
    Share on other sites

    • 0
    3 hours ago, 3JL said:

    how to use this information for our benefit? :)

     

    benefit? hmm, when everything works, no benefit. When something didn't work as expected, it might help to find the issue (like a cleaning personal removing wallplug, or daughter giving party each every time parents not at home - now you might wonder why, well, lot of people means lot of objects blocking zwave, and when at that time wind gust comes and breaks your venetian blinds, you will not know why scene was not working). During last years i visited lot of houses/flats, with sometimes very wired issues, especially combination of bad routing plus broken or misconfigured devices makes things very bad. For years it was always job for some exerts, zwave alliance was always like "add extra device when something didn't work" - which of course didn't make things better when devices are not working properly in first place, it will even get worse! But now there are tools available for installers and power users. Yes, sometimes it is hard to understand, but the basics are simple -> less communication is better, more devices is better, stable gateway is a must (add everywhere variable to be able to stop all scenes / VDs when necessary with one click), understanding of dependency between zwave gateway and external services is (more and more) important.

    • Thanks 1
    Link to comment
    Share on other sites

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Answer this question...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×
    ×
    • Create New...