Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Feature Requests
  3. Semi static parent modification

Semi static parent modification

Scheduled Pinned Locked Moved Feature Requests
11 Posts 2 Posters 1.9k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B Offline
    B Offline
    bilbolodz
    wrote on last edited by
    #1

    Some background information:

    I've bunch (over 30) nodes (NRF24) in my garden, there are working as lamp switches. I'm also using message signing. Because of RF range and required good signal quality (signing demands real stable RF network) I'm using repeaters.
    In my code I'm using:

    int8_t myParrentNodeId;
    int8_t myRF24PALelel;
    
    #define MY_PARENT_NODE_ID myParrentNodeId
    #define MY_RF24_PA_LEVEL myRF24PALelel
    

    trick to change preferred parent for nodes without needs of having different sketch image for each node and reflashing.

    Unfortunately sometimes (because of unknown reason) node changes parent node to some distant repeater node and communication with these node (over "new parent") is very poor. It's also very hard to recover node from such state (reboot command needs signing, signing needs good radio connection, radio link is poor because node is using very distant repeater).

    I've some ideas which could be implemented to remedy such situations:

    1. Possibility to BLACKLIST some repeaters - it should be a array(?) in RAM/EEPROM which contain IDs of forbidden parents

    2. Possibility to declare " MY_PARENT_NODE_IS_STATIC" but with fixed (in RAM or EEPROM) backup parrent ID. It will allow to limit possible parent to two good (in range) nodes but not break connectivity in case of primary parent failure

    3. Better RF link quality verification to be 100% sure that whole path to controller is performing well.

    4. It could be also a good idea to make possible enable/disable working node "as parent" without recompilation (easier tunning of large Mysensors network).

    1 Reply Last reply
    1
    • gohanG Offline
      gohanG Offline
      gohan
      Mod
      wrote on last edited by
      #2

      The problem with NRF24 is that you can't really measure quality of signal unless you do some traffic and check how many lost packages you had.
      Did you have issues with repeaters since you are asking how to increase reliability?

      1 Reply Last reply
      0
      • B Offline
        B Offline
        bilbolodz
        wrote on last edited by
        #3

        @gohan said in Semi static parent modification:

        Did you have issues with repeaters since you are asking how to increase reliability?

        Sorry but I don't quite understand you.....

        1 Reply Last reply
        0
        • gohanG Offline
          gohanG Offline
          gohan
          Mod
          wrote on last edited by
          #4

          Since you are asking to have a backup connections on the nodes, I was wondering if you had reliability issues on the repeaters

          1 Reply Last reply
          0
          • B Offline
            B Offline
            bilbolodz
            wrote on last edited by
            #5

            Now I've limited number of repeaters (4 in each corner of the house) and my problems with connectivity are less frequent but yes: from time to time my nodes are jumping to other repeater and in some cases there is a problem with RF link.

            1 Reply Last reply
            0
            • gohanG Offline
              gohanG Offline
              gohan
              Mod
              wrote on last edited by
              #6

              I got that, I was trying to understand why you don't want to use static parent id

              B 1 Reply Last reply
              0
              • gohanG gohan

                I got that, I was trying to understand why you don't want to use static parent id

                B Offline
                B Offline
                bilbolodz
                wrote on last edited by
                #7

                @gohan Static parent id would solve my problem BUT what if one repeaters (Murphy's law: most important) fail? 1/3 of my node network gone..... If I can blacklist some nodes (very distant from sensor) I can enable repeater feature on more nodes and have more redundant network. Similar with "static with backup": I can put more repeaters talking with more PA power and be 100% sure that node will talk to controller via one of "preferred parent".
                Of course it's just my idea but maybe it's worth to think about it?

                1 Reply Last reply
                0
                • gohanG Offline
                  gohanG Offline
                  gohan
                  Mod
                  wrote on last edited by
                  #8

                  I'd say that if you have been running the setup for long time without issues you should keep the fixed parent. Of course unless you have repeaters that regularly hang

                  1 Reply Last reply
                  0
                  • B Offline
                    B Offline
                    bilbolodz
                    wrote on last edited by
                    #9

                    OK I will probably fix my parents.

                    1 Reply Last reply
                    0
                    • gohanG Offline
                      gohanG Offline
                      gohan
                      Mod
                      wrote on last edited by
                      #10

                      Always keep in mind "don't touch what is working" :D

                      1 Reply Last reply
                      0
                      • B Offline
                        B Offline
                        bilbolodz
                        wrote on last edited by
                        #11

                        I know it's very good rule.

                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        8

                        Online

                        11.7k

                        Users

                        11.2k

                        Topics

                        113.1k

                        Posts


                        Copyright 2025 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • MySensors
                        • OpenHardware.io
                        • Categories
                        • Recent
                        • Tags
                        • Popular