I have a mesh of three hubs - C7, C8, C8pro; they are all in the same network, even if they are connected to different physical routers. They all live in the default 192.168.1.x address space.
Occasionally, C8pro will start seeing (and listing) C8 as under a "different" address (something like 169.x.y.z), and it will reflect state change in C8's linked devices, but it won't be able to control them (when it tries, nothing happens). The only way to snap out of that situation is to restart C8, and wait for C8Pro to update its knowledge of C8 (or nudge it by reconnecting the hub mesh devices).
All hubs are connected using dhcp - even if on the router side they are assigned to stati addresses.
Has anyone else seen something like this? Anything I should investigate further?
That address says that the hub in question was not able to recieve an IP lease from DHCP when it expired.
Well, the question would be why - considering that the router deals with that as a static ip association... Even assuming the router is crazy (after all, it's Verizon...), why would that happen only with that hub and not the others - which are configured the same way?...
Would be something specific with that hub <-> router communication. I used to have one hub that would come up faster than the router when there was a power blip, and it would do that all the time - fixed it by putting both on a UPS so now they don't go down and thus no problem unless I create it manually.
No power outages this night; but it is true that the hubs went through their weekly power cycle the night before this one; that said, things worked well yesterday evening...
It is odd, because the C8 hub still reported the correct 192.168.1.19 address, but C8pro would list it in hub mesh with the funky address. I was able to connected to C8 through the http interface and perform operations normally.
Interesting.. Have you tried clicking the Reconnect button in the Hub Mesh settings when this situation occurs?
I did on the C8Pro side (the only context where the wrong address was displayed); it came back with the same address - good for C7, bad for C8. The only way to make it snap out of it was to reboot C8.
It's also "funny" that the meshed C8 devices were still showing up online on C8pro; even showing their correct state! It's only when I tried to send them commands that things would not work.
The problem persists - it happened again today.
I also tried (as described here) to set http://hubs.ip.address.here/hub/advanced/setInitialHubMeshPeers?... the list of initial peers on C8Pro to include explicitly C7 and C8, but even after a "reconnect", C8Pro was pointing to the bogus address for C8 (and, again, during all this C8 was working perfectly fine and it was reachable).
Before restarting C8 (which seems to be the only thing which snaps C8pro out of it), I changed C8's network configuration to be static (after all, the router already assigns a fixed IP to it). We'll see if that changes anything in the coming days, but I am skeptical.
I've seen this same odd behavior off and on for the last 3 years. I tried solving it by calling an undocumented end point to set the remote hub IP but that didn't help. See this thread for info about the endpoint...
(never mind, looks like you already tried this...)
The only thing that helped was to prevent hub hard disconnects by installing a UPS power supply on my two hubs. This prevents them from dropping off the network suddenly which appears to be what caused them to fail reconnecting to Hub Mesh reliably. Go shopping on Amazon for an inexpensive UPS and put your hubs on one and it should get better.
Yeah, I saw that thread, and tried that endpoint; it did nothing for me. The issue is not power-related for me - it happened when power was stable and nothing went down.
What seems to have fixed it (you never know, being such on occasional issue) has been to set the C8 - the hub whose IP ended up mistakenly identified by the other hub, C8pro - to static mode; considering it was already associated to a static IP router side, it really made no practical difference to me to change its own networking settings to be static; but that seems to be preventing this problem from coming back.
