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


  • 0

Is manual routing possible?


baskalex

Question

I have a Danalock which is situated on the edge of HC2 range and it receives commands maybe one time out of 10. But it stubbornly doesn’t want to do any hops via intermediary devices which there are plenty of between the lock and controller. Fibaro door-window sensor located on the same door for example easily hops via two devices and works reliably. 
so the question is if it’s possible to manually set its routing to make hops? Probably with UZB?

Link to comment
Share on other sites

Recommended Posts

  • 0

check if your danalock have possibility to work via other node in network (not only in theory). Did you do  MESH reconfig for Danalock  from z-wave menu of HCx

Link to comment
Share on other sites

  • 0
  • Inquirer
  • When I first installed it, it did one hop and worked reliably. I had to reinclude it recently and haven’t managed to make it hop again unfortunately. Mesh reconfig on my HC2 works only for grid powered devices for some reason. When I try to do it for battery-powered devices, there is no reaction from the controller at all. 

    Edited by baskalex
    Link to comment
    Share on other sites

    • 0

    Hello! 

     

    Did you try to provide mesh network reconfiguration for mains powered devices that are close to Danalock? 

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • @macieck

    Actually yes. And I have another update btw. The lock itself seems to have found a good route to the controller, because when I lock or unlock it manually it’s status in the controller web UI is updated instantly. But the controller is stubbornly trying to communicate directly. 

    Edited by baskalex
    Link to comment
    Share on other sites

    • 0
    12 hours ago, baskalex said:

    The lock itself seems to have found a good route to the controller, because when I lock or unlock it manually it’s status in the controller web UI is updated instantly. But the controller is stubbornly trying to communicate directly.

    Interesting question... I have used the free "Silabs PC Controller" to force a device to use an APR aka "Application Priority (return) Route" so it always tries this route first (so before "direct", other routes and explorer frames). It works... But what you are asking is the reverse from what I did, the route from the controller to the device. I haven't tried that because the device I used it on happens to be a Wall Plug in "always on mode" so the controller never talks to the device (there is nothing to say ;)). Theoretically, APR can be set on the controller as well so maybe you'll find out for us and report back ;)

     

     

    If you want to know more about Z-Wave routing, I highly recommend this topic by @robmac on the OpenHAB forum

     

    Please login or register to see this link.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • @petergebruers

    thanks for the input! I’ve actually read Robmac’s post and I understand that device-to-controller and controller-to device are absolutely two different routes :) 

    I think I will buy a UZB stick and see what I can do with it. I hope I will not ruin the whole network :) 

    Basically I think my controller has some kind of bug working with battery-powered devices. It just doesn’t update routes to them. I had similar problem with Remotec ZXT 120 and solved it by switching it from FLIRS to always listening. Then I updated neighbors and it almost instantly started Working reliably.

    Also I checked Danalock neighbors with a scene from the forum and it actually knows it’s neighbors, but the controller just doesn’t try new routings. 
     

    P.S. Finaro support just said to reconfigure mesh for Danalock and when I answered it’s not working they just vanished :) Typical unfortunately. 

    Link to comment
    Share on other sites

    • 0
    2 minutes ago, baskalex said:

    I hope I will not ruin the whole network :) 

    No, ruining the network, that won't happen. Please do make a backup of your HC2 before you begin. In the past there was an issue when you removed that extra controller (when you're done with PC Controller and have set the route and want to clean up) you no longer could include devices, because the HC2 would think that dongle was an inclusion controller. I haven't tried in a while, I am not sure if that bug is solved. Fibaro support can fix that, or you do a restore, but I think that will remove your routing hack, which is not helpful.

     

    Even if you set a "bogus" route (which is quite possible eg if you tell it to use node 232 and that node does not exist on your network) the routing engine will try alternatives... But you'll get a consistent delay because you've told it to use that APR first.

     

    9 minutes ago, baskalex said:

    Also I checked Danalock neighbors with a scene from the forum and it actually knows it’s neighbors, but the controller just doesn’t try new routings. 

    If you have a Zniffer capture, I'm interested... AFAIK the routing algorithm favours lower node IDs and shorter routes, so "direct" is definitely the shortest possible. What I've seen on my network and also mentioned by other users is "long routes" probably caused by - and now we have to speculate - a device or the controller becoming unavailable for a while and then going into "explorer mode" and learning some 3-4 hop route while the device was actually reachable with much shorter route(s) before that happened. Once it learns such a long (but working) route it stays in the LWR. But what you suggest is the opposite, instead of "long" routes the controller seems to try direct only and because it is unreliable, you cannot always control it, correct?

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 1 hour ago, petergebruers said:

    because it is unreliable, you cannot always control it, correct?

    Yes, exactly. 
    It’s nice to know I won’t kill anything. So I’m going to buy a uzb and see what can be done.
    I don’t have a zniffer unfortunately, because it’s actually the only problem I haven’t been able to solve. Which is quite surprising for me, because I have a relatively big network :) 

    maybe after I solve the routing problem I will convert UZB into zniffer. 

    Link to comment
    Share on other sites

    • 0
    17 minutes ago, baskalex said:

    I don’t have a zniffer unfortunately, because it’s actually the only problem I haven’t been able to solve.

    Ah, I kind of suspected that. Only Zniffer can help diagnose routing issues. The data you see on HC is not reliable, because the controller hides much of the details, there is not much Fibaro can do to fix that. So your idea that the device X uses route Y based on the info you have may be wrong. For example "neighbours" and LWR stats are not realtime.

     

    21 minutes ago, baskalex said:

    maybe after I solve the routing problem I will convert UZB into zniffer. 

    I see what you mean, you want to buy a "controller" so want to use it to "fix" things - you cannot buy a UZB-3 with Zniffer firmware. Makes sense, but still feels a bit backwards, I would first "Znif" to diagnose, then maybe flash with controller firmware if you are sure you'll need it to set an APR. Or buy 2 of them, you might get free shipping.

    Link to comment
    Share on other sites

    • 0
    40 minutes ago, baskalex said:

    Yes, exactly. 
    It’s nice to know I won’t kill anything. So I’m going to buy a uzb and see what can be done.
    I don’t have a zniffer unfortunately, because it’s actually the only problem I haven’t been able to solve. Which is quite surprising for me, because I have a relatively big network :) 

    maybe after I solve the routing problem I will convert UZB into zniffer. 

     

     How are you going to decide the best route to try? I hope you succeed but I think  it will be a bit of a lottery and a zniffer would be my first stop. @petergebruers has told me RF is weird so many times that I am now not surprised by what works and what does not. I am however surprised he did not add that warning to his post. 

     

    Also your symptoms are odd.

     

    If direct has not worked it will not be LWR as something else worked. Then next time that route that worked OK must also fail so what is happening is all routes are unreliable not just direct. It does sound like a strange case and likely caused by something other than just routing. Without zniffer you are assuming it is trying direct but it might not be.

     

    Could it be an issue with flirs and wake rather than routing? 

     

     

     

     

     

    Link to comment
    Share on other sites

    • 0

    It is possible to set a route from the controller to the device, only fibaro has to add that.

     

    in some software you can set the route, see screenshot

    Please login or register to see this attachment.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 1 hour ago, robmac said:

    all routes are unreliable not just direct

    This is very unlikely, because a) there is a Fibaro door sensor right on this very door and it works fine and b) there is Fibaro double switch located literally 30 cm from the lock and it also has a stable connection. 

    1 hour ago, robmac said:

     How are you going to decide the best route to try?

    Basically I just wanted to check which route the above-mentioned double switch uses and route it the same way. 

    1 hour ago, robmac said:

    Could it be an issue with flirs and wake rather than routing? 

     

    Probably, but as I said I have this problem with two different devices - ZXT-120 and Danalock. With ZXT I've solved it by switching it to always-listening and dragging a power cable near to it :) So I think the problem is on HC2 side. I think it can't get neighbour nodes from FLIRS devices for some reason. Console stays blank when I try to do mesh reconfig for a FLIRS device. And it works normally when I do it for mains-powered devices, or devices with a wake-up button (Danfoss RS). I agree it's all very strange. Because I remember that before I could move ZXT-120 around and it always found good routing. 

      

    So, after reading your posts I think I should definitely start with a zniffer. One last question - Do I need exactly UZB-3? Can't I go with UZB-5 or 7 for Zniffer? Cause I think I will have problem finding UZB-3 with RU frequency.

     

    P.S. I'me quite flattered to have such valued members of community as @robmac and @petergebruers in this post trying to help :) 

    2 minutes ago, akatar said:

    It is possible to set a route from the controller to the device, only fibaro has to add that.

     

    in some software you can set the route, see screenshot

    Please login or register to see this attachment.

    I think this is exactly what I need. So I will start with Zniffer and then try to use secondary controller to set the route manually, If I don't find any specific problem. Thanks for the input.

    Edited by baskalex
    Link to comment
    Share on other sites

    • 0
    1 hour ago, baskalex said:

    Probably, but as I said I have this problem with two different devices - ZXT-120 and Danalock. With ZXT I've solved it by switching it to always-listening and dragging a power cable near to it :) So I think the problem is on HC2 side.

    I think you have solved one by turning of frequent listening.

     

     

    FLiRS is a bit odd and certainly not reliable yet as far as I have observed.

     

    Look at this. I am sure the RF got to the device as I was further away than the device was from the controller.

     

    RSSI 50 is fine even at the zniffer so was a lot better at the device.

     

    Firstly the order looks odd. See the white paper. 

     

    The ACK takes over 1s and for a lock you probably wait for the position report if HC2 is doing a good job. After all you want to know the bolt slid.

     

    So that could be 1 s + say 1s for the bolt to slide and report to be generated + another 0.3 s + processing at both ends so 2.5s could be what you would expect and 1.5 would be very good.

     

    Please login or register to see this attachment.

     

     

    Below is how silabs says it works but it has to rely on the repeater having a protocol that understand flirs. I have no idea if older devices do support.

     

    This above is direct so not even my UZB3 running the latest firmware is doing it as described.

     

    Please login or register to see this attachment.

    Please login or register to see this link.

     

    Quote

    The FLiRS device alternates between sleep mode and a partially awake mode in which it is listening for this beam signal at the rate ranging from once per second to four times per second (this is the designer’s choice). When the FLiRS device receives this beam, it immediately fully wakes up and then communicates with the controller or other Z-Wave device utilizing standard Z-Wave protocol commands. If the device does not hear a Beam it goes back to full sleep for another period until it partially awakes again and listens for a Beam. It is this partially awake mode combined with the special Beam that provides for battery lives on par with fully sleeping devices while providing communications latencies of around one second.

     

    The other way is just normal unsolicited coms. As soon as the lock reports it travels like standard zwave. 

     

    And remember this is all in the protocol layer so HC2 is just running the same code as any other controller running the same protocol layer. Possibly the protocol in my very recent firmware has an issue that was not in historic protocols but your repeaters will have a load of other versions of the protocol.

     

    The latest firmware for 700 series boasts a fix for FLiRS to make it faster so even in the very latest it is not all settled.

     

     

    The firmwares for 500 do not include region

    image.png.783fa2ec160cc87aace41126ac236330.png

     

     

    there is a dropdown for frequency in Zniffer BUT FROM READING the NVR0 is factory programmed so not convinced it will change anything but possibly  the zniffer firmware may include allowing editing this region though there is no specification for the values for Russia.

     

    Probably best to find an older RU controller that has a specific sniffer firmware available. If you can not get one as Russian frequency 869.2 is so close to EU 868.42 I am sure an EU would only have slightly less reception and possibly the drop down does change the settings as the actual components are the same. 

     

    I am not sure how much you loss. @petergebruers do you have any idea how much would be lost from a SAW tuned to 868.42 when the signal is 869.2? 

     

     

    hmm here is one and it is pretty flat +/- 5 MHz. I don't want to give a bum steer but I think you will lose nothing and as it is not a transmitter no issue with regulations. 

     

    Please login or register to see this attachment.

     

     

     

     

    Edited by robmac
    • Like 1
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • I’ve managed to order z-wave.me UZB 3 stick. Should arrive tomorrow. Will keep u posted if I find anything :) 

    Link to comment
    Share on other sites

    • 0
    20 hours ago, robmac said:

    I have no idea if older devices do support.

    I wish Silabs published a sheet with which feature was introduced when...

    "Beaming" landed quite a while ago if I am correct, ZW300-ish so say devices with firmware after ... 2010. According to the spec, BEAM is always 40 k with the exception of "3 channel radio" which only exists in Japan and Korea. So for EU/US beam should be pretty unambiguous.

     

    See T-REC-G.9959-201501-I!!PDF-E.pdf

     

    8.1.3.13 Beam formats on channel configurations 1 and 2
    FL nodes operating in channel configuration 1 or 2 shall be able to receive and transmit the continuous beam format at data rate R2.
    8.1.3.14 Beam formats on channel configuration 3
    FL nodes operating in channel configuration 3 shall be able to receive and transmit the fragmented beam format at data rate 3.

     

    Data rate 3 = 100k and channel config 3 means 3 frequencies all capable of doing 100k. We do not have that in most parts of the world.

     

    Zniffer logs "Beam Start" and "Beam End" so should be detectable in Zniffer if the lock can "hear" a beam.

     

    20 hours ago, robmac said:

    am not sure how much you loss. @petergebruers do you have any idea how much would be lost from a SAW tuned to 868.42 when the signal is 869.2? 

    You beat me to it, it is indeed "pretty wide" and 5 MHz is what I'd say. But attenuation for US versus EU is significant, say -40 dB

     

    To find the right module, I would always check this table

     

    Please login or register to see this link.

     

    There are many frequencies, but only 3 types of module (because of de width of the SAW filter).

     

    14 hours ago, baskalex said:

    I’ve managed to order z-wave.me UZB 3 stick. Should arrive tomorrow. Will keep u posted if I find anything :) 

    Zniffer will be your friend ;)

    • Like 1
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • A small update from my side:

    I've received the UZB today (it turned out to have 500 series chip, but it's not an issue after all) and after some fighting with horrible silabs site, have managed to convert it to Zniffer according to the instruction.

    As expected by the more professional forum dwellers the routing was not the problem. Actually it was quite trivial. Turns out one of my FGS-223s went rogue and sent power reports every second effectively spamming the network. And it just happens that it's situated right in the middle of the apartment and a lot of traffic is supposed to be routed via it. Basically just didn't let through the wake-up beam, so the lock just couldn't wake up when it was needed. After I fixed the rogue parameters of the FGS, HC2 almost instantly found a good route to the lock and now it works great! Hail to the king zniffer! :)

     

    Thanks a lot to @robmac, @petergebruers and all the other forum-members for your great help! I will continue zniffing around and improving the network :) 

    Link to comment
    Share on other sites

    • 0

    I don't understand why there is no logfile in hc2, perhaps in hc3?

    then you can see these things happen.

     

    The controller i use has a realtime logfile and you can see every thing that happens.

    • Like 1
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 2 minutes ago, akatar said:

    I don't understand why there is no logfile in hc2, perhaps in hc3?

    then you can see these things happen.

     

    The controller i use has a realtime logfile and you can see every thing that happens.

    Yes, that would help a lot. HC has log only in terms of device states. It could definitely be helpful to have more logging and network - diagnostics possibilities. So-called diagnostics panel is a shame.

    Link to comment
    Share on other sites

    • 0
    46 minutes ago, baskalex said:

    Yes, that would help a lot. HC has log only in terms of device states. It could definitely be helpful to have more logging and network - diagnostics possibilities. So-called diagnostics panel is a shame.

    It would always be nice but if the network is full of traffic some commands will never get to the controller to be logged. Newer firmware and devices provide a lot more information. It would be great if it were available but other than a few experimental versions of controllers it is not yet available.

     

    I believe the certification is getting more rigorous so possibly in newer controllers we will see it.

     

    You would still will not see everything if the network is spammed  so zniffer will always be a big help.

    Link to comment
    Share on other sites

    • 0
    14 minutes ago, robmac said:

    It would always be nice but if the network is full of traffic some commands will never get to the controller to be logged. Newer firmware and devices provide a lot more information. It would be great if it were available but other than a few experimental versions of controllers it is not yet available.

     

    I believe the certification is getting more rigorous so possibly in newer controllers we will see it.

     

    You would still will not see everything if the network is spammed  so zniffer will always be a big help.

    i am trying to underdstand.

    but if the signals are not reached, they are also not reaching the zsniffer? that is also a controller?

    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...