Does it have a limit to how many it can manage?
No limit, though the packets have to make it to Firestorm and be on the same network. Can you get a packet capture of port 1889, e.g. with wireshark or tcpdump?
I suppose I could do that. If the discovery service found them all, doesn’t that prove they’re all on the same network and in range of the AP? I should mention that Firestorm is running on a raspberry pi. What might prevent the packets from getting to the pi?
Of the 8 Pi’s in this project, half are v2 and half are v3. It’s curious that Firestorm is seeing all the v2’s, and then only one of the v3’s (it also doesn’t see Claire’s v3, but that’s not part of the project)
FWIW, I had 6 v2’s and 1 v3 working at once on Firestorm a month ago.
I did want to point out the discover.electromage.com will cache entries it hasn’t seen in a while, whereas Firestorm will remove them if not found in the current discovery beacon; Also I recall seeing the discovery service list everything found behind my public IP, even if Firestorm couldn’t see them all due to different wifi routing/subnet setups.
All that said, I did have a setup while beta testing v3 (about 3-5 months ago) where I knew there were 3 PB (versions unknown, sorry) on my local subnet with confirmed unique names, IPs, and MACs; and Firestorm only showed 2. I didn’t have time to investigate more and haven’t been able to repro since.
Not necessarily, the discovery service works by external IP address. Based on those local IPs, it doesn’t look like you have separate local networks, but that doesn’t necessarily mean there isn’t some partitioning happening.
It also keeps the record for quite some time, as PBs only report in once an hour. I assume that you can still access the missing ones.
It’s interesting that only V3s are missing, let me see if the discovery ID is bad/non-unique in some way. I had to change how V3 gets it’s unique ID compared to V2 and might have missed something…
Sure enough. Mystery solved! Thats what I get for using the wrong 32 bits of a 48 bit number! And to think I had fixed a similar issue in another place but left the discovery code undiscovered. Also explains why not all PBs would trigger the issue in Firestorm.
I’ll try to push out an updated for V3 a bit later today.
4 Likes
Well, almost.
I’ve reconfigured all the PB’s and the RPi to connect to a mobile standalone wifi access point. Now firestorm sees 7 of 8 PB’s have been found at their new IP addresses, but it still thinks one of them (v3.12) is at the old IP address from the other network. Is there any way to force an update?
Nevermind, I figgered it out.