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


ZWave nodes losing connectivity


timc

Recommended Posts

I have a number (low hundreds) of devices (PIRs and door sensors). Some of these occasionally drop off the ZWave network (no status messages sent). It looks like this is usually down to low RSSI (< -80dB). However, in connectivity is not restored if the signal strength is restored and the only way to get the devices communicating again is to reset them by pulling out the battery and replacing it.

 

Is this the expected behaviour? Is there any workaround as the devices are not easy to access?

 

thanks

 

TimC

Link to comment
Share on other sites

If low signal strength is the root cause, you should consider putting in some mains powered devices in strategic locations to act as zwave repeaters, and thus boost signal strength.

 

As you have hundreds of devices, you should also ensure that each device is only sending the minimum amount of data so as not to flood the network. Eg turn off periodic temperature and power reports.

 

There are some posts on here with quick app / virtual devices you can load up to help you investigate your traffic too.

Link to comment
Share on other sites

  • Topic Author
  • There are already repeaters in the individual networks (the hundreds of devices are on dozens of networks and network b/w is not an issue for the amount of traffic involved), although I believe that's a design anti-pattern (I'm living with it until I can get enough data to demonstrate/disprove my view).

     

    However, node-node signal strength varies over time as doors open/close, furniture moves, walls get built/torn down, etc.

     

    Should it be the case that a node dropping off the network as RSSI drops below ~-80dB (say when a door closes) rejoins the network when the RSSI again becomes acceptable (say when the door is re-opened). Or should the node stay offline and require a new route adding that is always > ~-80dB?  I'd expect the former behaviour.

     

    I believe that I've seen both behaviours.  If both behaviours are present, I'll need to work out if there are any a priori conditions that can be used to identify future instances of that behaviour.

    Link to comment
    Share on other sites

    On 8/9/2021 at 3:20 PM, timc said:

    Should it be the case that a node dropping off the network as RSSI drops below ~-80dB (say when a door closes) rejoins the network when the RSSI again becomes acceptable (say when the door is re-opened). Or should the node stay offline and require a new route adding that is always > ~-80dB?  I'd expect the former behaviour.

    There is no such thing as "dropping off a network" or "rejoining" in Z-Wave. Such terminology does apply to Zigbee but I am not familiar enough with that protocol to tell you exactly what it means, but users describe it as "devices dropping of the network" and starting to work again when replacing batteries or clicking and holding the "join" button (The older aqara sensors come to mind...).

     

    If you "include" a device it becomes part of the network and can send at any time, until you "exclude" it.

     

    Some buggy devices are easy to reset (eg long press 10 seconds S1 on some capacitive touch wall switches) which might appear like they "dropped of".

     

    Gateway software, like Fibaro HC, do have protective measures to *not* send to dead devices and a devices is considered dead if it failed to respond after a few attempts (mains devices) or when it does not wake up at the expected time (iirc after 2 times "wake up interval" has passed. Possibly 3.)

     

    What you say is hard to debug without tools. I recommend you make a "Zniffer" and start testing.

     

    This post is the best so far to help you see why I recommend this tool...

     

     

    Now I have written this.. I wonder if you already own a Zniffer, because, how else would you be talking about RSSI? Hah!

    • Like 1
    Link to comment
    Share on other sites

  • Topic Author
  • Thanks Petergebruers. It sounds like the nodes are crashing then, as service is restored by popping the battery out and in again.

     

    I'm now a bit suspicious that we may not have recorded the exact scenarios.  I'll try to reproduce the symptoms in a lab.

     

    fwiw, we're grabbing the RSSI from nodes via OpenZwave stack.

    Link to comment
    Share on other sites

    1 hour ago, timc said:

    fwiw, we're grabbing the RSSI from nodes via OpenZwave stack.

    DOH! I am really glad you get that from OZW! I wrote the code to retrieve that bit of information (extended status information) together with Justin Hammond. It has been in the OZW logs since... Let's see...

     

     

    Please login or register to see this code.

     

    Time sure flies... Yeah I contacted Justin on behalf of "Home Assistant" because I was using HASS as a 2nd controller and wasn't happy with OZW 1.4 so I contributed a bit to OZW1.6. But then I got health issues... And a project to integrate OZW via MQTT derailed and now OZW is kind of ... D.E.A.D. Not enough contributors and I bet the C++ code scares people... It is not python or javascript :D

     

    You are the second, maybe 3d person in 2 years time to mention the RSSI values reported by OZW ;)

     

    Anyway, you'll also find routing information which is actual, real live data (not like the "neighbours tables" or graph which don't show any actual routes).

     

    It is an interesting tool. I personally like the free Silabs "PC Controller" which can do tests and report health. That is an alternative to OpenZWave...

     

     

    1 hour ago, timc said:

    It sounds like the nodes are crashing then, as service is restored by popping the battery out and in again.

    That would be my first guess. A Zniffer should show that the device no longer sends data when you "tickle" eg trigger a door sensor.

     

    I have seen strange effects ... when using LiIon CR123 charged to 4.2 V which is a bit out-of-spec but I cannot remember which brand or type of sensor it was. I mostly use LiFePO4 so never higher than 3.6 V. In general, I do not recommend rechargeable batteries, because you won't get a good indication of battery level and their capacity is much lower than primary cells.

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

    4 hours ago, timc said:

    Thanks Petergebruers. It sounds like the nodes are crashing then, as service is restored by popping the battery out and in again.

    I'm now a bit suspicious that we may not have recorded the exact scenarios.  I'll try to reproduce the symptoms in a lab.

     

    actually node should not crash, this is one of the critical steps during certification. 

    Can you share what products (with fw/zwave version) are you talking about?

    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
    Reply to this topic...

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