Jump to content

Bond Node server not discovering new Ceiling Fan


tlightne
Go to solution Solved by Goose66,

Recommended Posts

@Goose66I have added a second ceiling fan to my Bond Bridge but Discover in node is creating errors and the node server does not see the new fan. The original fan (Front Porch Ceiling Fan) is working with out issues. The Bond app sees the new fan and can control it with out issues. I have included a current log.

Hardware is Polisy 5.6.2 PG3x 3.1.29 Bond Bridge is Firmware 3.13.6

Thank you

Bond_6-15-2023_121405-PM.zip

Edited by tlightne
Link to comment

Yes I restarted the node server after I saw the first error but did not help. Do you have to make the bond  Bridge discoverable again? I assumed the Node server already knows about it from the original ceiling fan installation.

I am running the Ring NS, Holiday NS, Open Weather Map NS, ShelleyRGBW2 NS, Ambient Weather NS, Notification NS, Bond NS. 

I have no idea what Avahi/Zeroconf listener is, I have nothing else installed beyond the Node servers listed.

 

Edited by tlightne
Link to comment
  • Solution

Turns out you would need to make the Bridge discoverable again to discover new devices added to the bridge if the Bridge was originally discovered by the automatic discovery (i.e., not specifically identified by hostname in the "hostname" Custom Configuration Parameter). I consider this a bug (or an oversight) however, and I have marked it for change in the next version.

The Zeroconf module allows the node server to broadcast a query to the devices on your network and then listens for responses from compatible devices (in this case Bond bridges and SBB devices). It is the same mechanism as Bonjour that Apple uses to discover Apple devices (printers, phones, macs, etc.) across your network. The error you are getting suggests that some other process on your Polisy (and, specifically another user) has the Zeroconf socket connection open and listening for responses. Since I am unaware of any such native process on the Polisy, I am assuming it's another node server. One of the changes implemented in PG3x is that node servers each now run under their own user ID. So if another node server is utilizing Zeroconf (and holding it open), other node servers will fail to initialize Zeroconf since they are now running under different user IDs. 

I have noted this bug and will have to do further analysis to figure out a fix. In the meantime, a workaround for you should be putting the hostname and token values for your current bridge in the "hostname" and "token" Custom Configuration Parameters for the node server (see the instructions under the "Configuration" tab in the PG3 Dashboard). This should cause the node server to skip the automatic discovery of new bridges through Zeroconf and just look for new devices on the bridge(s) you specify in the Custom Configuration Parameters. Note that, based on the "bug" discussed in the first paragraph of this post, if you don't specify the "token" configuration parameter value for your bridge, then the bridge will have to be discoverable (power cycled) for this to work properly.

Let me know if you need any additional help with this, and hopefully I can get these bugs fixed and get a new version out soon.

  • Like 1
Link to comment

I entered the token and ip address of my bridge and all it discovered the new nodes with out issue. 

Thank for the quick response and the great explanation on the Zeroconf module. The only other node server I can think of the is using anything of mt network would be the ShellyRGBW2 it is driving LED strip lights I have around the eves of my house.

Thank you again..... 

Link to comment
Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Forum Statistics

    • Total Topics
      36.9k
    • Total Posts
      370.2k
×
×
  • Create New...