No announcement yet.

Secondary Inclusion Controllers

  • Filter
  • Time
  • Show
Clear All
new posts

    Secondary Inclusion Controllers

    I know this topic has been bandied about before, but can someone address how to fix this problem?

    Click image for larger version

Name:	sic.png
Views:	235
Size:	64.7 KB
ID:	1427482

    I cannot keep the secondary inclusion controllers in sync with the main no matter what I try. This causes problems because I cannot associate the device to the controller I want. About the only fix I have found - and its not a good one - is to bring the secondaries from their location one by one to the main periodically, and run the sync over and over until it finally takes. Then I can take the controller back to its location, and change the associations to what I want. After that, everything works great.

    Secondaries are all early (non-plus) Z-Nets, and one old Z-Stick that is plugged into the USB port on the controller (an SEL).

    There has got to be a better way. Even copying the information manually node to node would be preferable to digging these controllers out of cabinets and ceilings every time the topology changes.
    Attached Files

    Don't you wish you had only Zwave-Plus controllers? For mixed devices, they will default to the slow controller but don't you think if controllers then that will have adverse effects to what you are trying to achieve?

    Source :

    The main consideration is the Z-Wave controller - if the controller is not Z-Wave Plus enabled than all devices added to that controller's network will default to acting as Z-Wave. This is because Z-Wave Plus is backwards compatible with Z-Wave, so when Z-Wave Plus devices are installed with Z-Wave devices they behave just like a Z-Wave device.

    If you do have a Z-Wave Plus controller, then you should start to see the benefits of Z-Wave Plus, as long as other devices in any "routes" to the Z-Wave Plus device are also Z-Wave Plus. Otherwise, the device will again default to operating as a plain Z-Wave device.
    Although your intention may have been for different groups of devices to be controlled by a particular controller, there also isn't much information on mixing controllers out there.

    More on that here :

    So for curiosity, can you have more than one SIS on the Zwave network?

    Source : 5.3.3SIS functionality for improvedplug and playexperienceNetwork-wide inclusion via explorer InclusionRequest makes use of a central primary controller. The primary controller assigns a unique node ID to each new node included.explore-supportingnodes may be included from anywhere in the network; also when out of direct reach.By implementing SIS functionality in a central controller based on explore-supporting SDK, one may get the best of both worlds. Classic Z-Wave Nodes may be included via any inclusion controller in the network.Explore-supportingnodes may also be included via any inclusion controller in the network. In addition, the user may activate network-wide inclusion in the primarycontroller, e.g. via a web page.In this mode, explore-supportingnodes may be included from anywhere in the network.
    And poke into this one as well : and here :

    TinkerLand : Life's Choices,"No One Size Fits All"


      Originally posted by Eman View Post
      Don't you wish you had only Zwave-Plus controllers? For mixed devices, they will default to the slow controller but don't you think if controllers then that will have adverse effects to what you are trying to achieve?

      Although your intention may have been for different groups of devices to be controlled by a particular controller, there also isn't much information on mixing controllers out there.

      More on that here :

      So for curiosity, can you have more than one SIS on the Zwave network?

      And poke into this one as well : and here :

      Not sure I understand what all this response means. I don't have more than one SIS. I have multiple inclusion controllers on the same home network. All I want is for them to be synched with the same information, which is clearly intended by the use of the Synchronize All Interfaces in this Network command in the Z-Wave Interfaces page. My contention is that this doesn't work as intended. As to the wanting all Z-Wave Plus controllers, I am not really interested in dumping $1000 to replace my existing Z-Nets, especially when I am already sitting on a useless new S6 Pro that no one at Homeseer can help me bring my existing SEL setup over to. If I didn't have so much money invested in this already, I would have been looking elsewhere.

      All I want is for the inclusion controllers to sync their node data.

      Also: Because the sync doesn't work right, it also doesn't get rid of the removed nodes from the SICs either, which leaves the whole network in a less than optimum state. I know exactly what I have because of a spreadsheet I keep for the entire household, and there isn't a single controller, including the SIS, that is correct.

      It should not be this difficult to have the controllers have the correct nodes in them, be able to sync them with the same information, and keep them that way.


        OK, here is one you will be more able to relate to :
        • Zwave has been a contentious issue (even the High Priests [HST] know this) for a very long time here as you can tell from that link is quite dated and there are lot more like it, you just have to search Google!
        • The reason I dropped in those links above is just to aid you in outsourcing of the deeper understanding of Zwave controllers should you be in the act of building a large network. I understand that they may not be directly HomeSeer specific but they sure are Zwave related!
        • So you must ask yourself questions relative to the information I provided above especially the question of using mixed classic Zwave and Zwave-Plus controllers (if devices and remote controls yes). How big is the House? Do you need 4 even if you have them?
        • And as from your images above the blame / fault may lie elsewhere. Look closer again what is mentioned about SUC :

        TinkerLand : Life's Choices,"No One Size Fits All"


          To elaborate a little further, this was the result of adding a new node. I cannot even include the nodes from a secondary inclusion controller (this always fails), but if I bring the device to my SIS and include it, I can add it normally. Notice that after the node is included, HS tries to update the topology out to all the SICs, and says its successful. It isn't. The nodes don't get added to the SICs, and the new node only shows the SIS as being available. The nodes are still out of sync.

          Click image for larger version

Name:	sic2.png
Views:	204
Size:	100.4 KB
ID:	1427620

          And here, you can see the new network device, and that the Remote Interface to Use clearly only shows the SIS and one other SIC, not all the SICs as it should.

          Click image for larger version

Name:	sic3.png
Views:	189
Size:	58.0 KB
ID:	1427621
          This should show all of the SICs. Here is an example of what the network should look like:

          Click image for larger version

Name:	sic4.png
Views:	185
Size:	52.7 KB
ID:	1427622


            I have this feeling that whatever nodes the SICs collect is taken over by the SUC/SIS. I don't know if I read somewhere but trying find more information on it.

            Edit : Seems to be on the boarder line of touching on it

            Static ID Server (SIS)

            Even having a SUC in the system does not solve the problem that only one controller has the primary privilege and therefore, is the only controller allowed to include new devices. This limitation is overcome by enhancing the SUC functionality by another function called ‘SIS‘ = Static ID Server.

            The SIS acts as depot for new Node IDs that can be assigned by mobile controllers. Having a SIS present in the network allows every controller in the network to include devices. The controller will just request a new Node ID from the SIS and assign this new Node ID to the server. The SIS ensures that Node IDs are only assigned to one node - avoiding conflicts. The only requirement is that mobile controller has a network connection to the SIS server in order to request a Node ID.

            SIS Server in a Z-Wave-Network

            Using a SIS in your network as a number of advantages and disadvantages:
            • The network topology and information about all nodes are saved in a static controller - much better protected than within a mobile battery-powered device.
            • All controllers in a network can include new devices.
            • The network configuration and handling becomes very flexible.
            • Functionality is only available in Z-Wave firmware version v3.4 and later - network devices with older firmware will not support this configuration.
            • The Inclusion controller can only integrate devices if it has a wireless connection to the SIS.
            • The SIS represents a “Single Point of Failure”. A damaged SIS could result in a complete new network setup.

            Since the SUC/SIS functionality is already included in the firmware of most modern static controllers, or USB dongles, most Z-Wave networks can take advantage of these functions if a static controller is present (as long as you activate it).

            A static controller can also be used as a primary controller, as well as having SUC/SIS functionality. This configuration is typical in real networks.

            Controller rules shown in a Gateway User Interface
            Networks with Portable Slaves

            If a SUC controller is present in the network it is able to determine a new position of a slave and update the network’s routing table accordingly. The procedure to achieve this is called “Get Lost –Algorithm” and only works for Routing Slaves (slaves that have some knowledge of the network’s routing information).

            A normal slave is not allowed to send unsolicited messages and therefore, can never determine any change of its position in the network. However, Routing slaves are allowed to do this.

            If a routing slave sends an unsolicited message that fails, it will assume that its routing table is no longer valid.

            As a first step this node will send out a broadcast “cry for help” message to the network. A node that receives this message knows that the sender has found itself in a new location. This node, however, cannot provide the “crying” node with an updated routing table. If this node is a routing slave it will forward the “cry for help” message to the SUC.

            The SUC can update its own routing table and assign new routes to the crying node by performing the same steps it would do when including the device. The “cry for help” message is able to auto-heal a network in case a node has been moved.

            In order to have a working auto-healing function within the network, the following requirements must to be fulfilled:
            • A SUC needs to be present in the network.
            • The moved nodes must be a routing slave not a standard slave (to allow unsolicited messaging).
            • In the new position there must be at least one routing slave in range.
            • The moved node must detect that he was moved. This is only possible if this node sends out an unsolicited message.

            Edit : This one is also old

            TinkerLand : Life's Choices,"No One Size Fits All"


              Again this guy here tries to touch on it
              Source : This is where the SIS/SUC scheme comes into play. It was an improvement to the zwave topology which muddied the definition of “primary” a little.
              Traditionally you would have one primary controller and only that one controller could include devices. The secondary could only control them.
              With a SUC, you would still have one controller with a primary role but now it could be mobile and you would keep the Static Update Controller (SUC) static. As its name indicate, it is static location wise and is the reference point of the mesh topology, recording the routing table of the mesh. It is a controller which is supposed to be always on and in your application likely should be the vera… though the vera does not support it. Ha!
              Enters the SIS, Static ID Server, which needs to be the SUC of your network if you want a SIS. The SIS records not just the routing table but also manages the inclusions from multiple primary controllers on the network. Yes this opens up quite a bit of possibilities but also confusion. The SIS would be called now the “true primary” and the others would be secondary with primary capability. It means that any of these secondary controllers can include devices but that they report any new inclusion to the SIS.
              Again the vera doesn’t really support this even though it is a zwave level firmware capability… So it actually works but you can’t enable it with the vera. Almost any other zwave controller can do it.

              From what that sounds like is that If you have an SUC/SIS on the network, is you would then set all the other controllers as primary in their own networks which they would then report to the SUC/SIS for the wider network topology BUT if you set the other controllers as secondary inclusion controllers (SICs) then that means their roles are inclusion and control so they handover their nodes info to the SUC/SIS/Primary controller

              Edit : Text in orange is not true and does not apply according to this :
              • So based on the images you provided your network should be already setup correctly for as long as your Primary is also the SUC/SIS.
              • Now the reason I left that text in orange is for you to see this : There are a lot of people (including the High Priests [HST]) who got quite tired of answering questions may be because they feel unappreciated (I don't harbor that sentiment it's a contextualized analytics of the situation) or I could be wrong on that one that their work is lost in the big HomeSeer database. Often times they assume that one has not done an exhaustive search about something asked before.
              • Most questions asked before can be found in their respective forums. (A quick Google search by say including yourtopic at hand will show you a lot of options to which one may be the answer to your question)

              AND THUS CREATING AN SUC/SIS/Primary


              TinkerLand : Life's Choices,"No One Size Fits All"


                Further detailed Z-wave Compliance Overview :

                Page 3 of 43 :

                TinkerLand : Life's Choices,"No One Size Fits All"