Announcement

Collapse
No announcement yet.

Redundant ZNet Strategy

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Redundant ZNet Strategy

    Folks - I'm looking for a good way to have redundant ZNet strategy on the same ZWave network. Friday, I was updating my wireless router (KRACK) when I noticed I had two ZNet devices attached to the same IP address. I logged into the ZNet to see what was going on. It appeared okay and then rebooted the Znet. Unfortunately, in the reboot I toasted the SD card and subsequently the whole ZWave network was down.

    HS has a new SD card coming but being an IT guy, I like to have redundancy and don't like single point of failures. This forum has some very talented folks (Rprade, Pete, Zwolfpack -- thank you) who talk about backups and differences of the GPIO settings versus the SD card.

    I'd like to add a second ZNet as a hot spare if possible.

    Also, when using the Rprade backups using the USB SD card stick Zwolfpack talks about, does this include the GPIO ZWave networking information?

    The hot spare idea is if I'm not home, I can still fix the ZWave and have all of my events run. If I'm home I could just unplug the SD card from the USB stick and plug into a spare ZNet.

    I'm certainly open to other suggestions to prevent a single point of failure in the future. In the mean time I'm waiting on the SD card replacement from HS.

    Thanks -- and thanks to you ZNet experts out there! I'll be learning Perl and SSH next apparently

    Dale.

    #2
    There are two parts to consider.

    1) The Raspberry Pi operating system (the SD card).

    2) The ZWave controller chip NVRAM contents. This chip is on the GPIO daughter card. This is where all the ZWave "smarts" live.

    In this application, the SD card contents generally will only change when the Z-Net firmware is updated (or when you update the Raspbian OS, if you choose to do that). The two backup methods that have been discussed for this are (1) remove the SD and copy it on a PC using WinDiskImager; (2) backing it up in place to a USB mounted SD using the rpi-clone script.

    The Zwave controller chip is backed up via the Zwave plugin management page. I've posted a perl script to automate this process.

    Comment


      #3
      Z -
      Thanks for the advice! If I have a second ZNet on the network, all I would need to do is restore the ZWave settings to the second ZNet. Of course I'd need to change the ZWave interfaces page to point to the spare. Do you see obvious issues with that?

      Thanks.
      Dale.

      Comment


        #4
        I was thinking of doing something similar, but instead of having it as a redundant spare, have it running as a second controller to improve comms. I think that is possible ? And in that case if one fails everything should still work without even having to do anything if I understand it correctly

        Comment


          #5
          Mike -
          That makes sense and sounds reasonable. I might try that approach instead.
          Thanks,
          Dale.

          Comment


            #6
            Originally posted by mikee123 View Post
            I was thinking of doing something similar, but instead of having it as a redundant spare, have it running as a second controller to improve comms. I think that is possible ? And in that case if one fails everything should still work without even having to do anything if I understand it correctly

            Comment


              #7
              I had a primary and secondary Z-Net for a while. It made the whole maintenance a lot more difficult (especially when you try to backup/restore Z-Wave networks) but the main problem is that Z-Wave devices have associations to only one of the Z-Nets. Group 1 normally only supports 1 association so I don't tink full redundancy is possible...
              stefxx

              Comment


                #8
                Originally posted by dbarnes View Post
                Z -
                Thanks for the advice! If I have a second ZNet on the network, all I would need to do is restore the ZWave settings to the second ZNet. Of course I'd need to change the ZWave interfaces page to point to the spare. Do you see obvious issues with that?

                Thanks.
                Dale.
                The only issue with this is that the new znet won't have the routing information from the old one. This is an unfortunate shortcoming -- there doesn't seem to be any way to copy this over, you will need to go thru an optimization cycle.

                If my znet were to go down, I would probably
                0) cuss
                1) swap in the backup SD card.
                2) sub in the spare Raspberry Pi.
                3) swap in the spare GPIO card or the UZB, restore from the latest backup, optimize, and cross my fingers!!

                Comment


                  #9
                  Z -
                  Bummer. You bring up valid points. Now I'm leaning to get a new ZNet with RPi3 board. I've read the RPi3 is more reliable and less likely to corrupt the SD card.

                  Lots to try once I get back up and running.

                  Thanks,
                  Dale.

                  Comment


                    #10
                    Doesn't completely answer your questions, but here is a tip I use to help with this issue.

                    - I keep a spare SD card with my znet that already has the OS on it and is ready to go in case of failure. The image is floating around here somewhere and its an ISO that you just copy to another SD. The SD for a Pi can and do go bad, so this I do for any Pi I am running.

                    - If you are running the latest znet, its built on the Pi 3, which has wifi and ethernet. So this probably explains why you were seeing 2 IP's for the device.

                    Outside of that, I don't think there is much you can do. Having the spare SD means you would be done the time it took to pull apart the znet and swap out the SD card. The zwave info is stored elsewhere on the zwave chip and should never get impacted by such an outage.

                    Comment


                      #11
                      Just to clarify what I said above, the routing info is stored in the controller chip in the Zwave daughter card. So as long as I don't need to swap out the daughter card, my recovery would be simple and quick (the cussing would probably take the longest).

                      Just as a data point - I have yet to trash an SD card, and I probably mess around more than most with Raspberry Pi's... (not that I necessarily do anything useful ).

                      Comment


                        #12
                        I had 3 SD cards fail in my original Z-Net. They were all 4GB transcend cards and it was a Pi B+. They would boot, but would not connect. In June 2015 I switched to Samsung EVO cards and 3 Z-nets. My original Z-net was replaced with a Pi 2 model and I purchased two additional Z-Nets, one was a Pi 2 and the other a Pi 3. I swapped the two Pi 2 boards with Pi 3 boards and created 3 fresh 16GB Samsung EVO cards with v2 1.0.17 software. I haven't had a failure since. Last fall they all updated to v2 1.0.23 firmware.

                        I also keep an imaged SD card with each unit and I notched the cases for easy SD card swapping, just in case there is a failure. I've never had any problems with the Z-Wave daughter cards. I back up the Z-Wave network on all 3 nightly using the Python script that zwolfpack posted. Backups older than 2 weeks are deleted nightly after the backup runs.

                        Each Z-Net is a separate network.
                        HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                        Comment

                        Working...
                        X