They are visible via the leader using a getPeers request.
Not yet. I’ve got some pieces done, but likely won’t have time to put them all together 'till after burning man.
1 Like
OMG This is amazing and it works so FLAWLESSLY!
I helped a friend set up their pixelblaze yesterday and after updating the firmware on mine to the new 3.40, everything just…worked.
@wizard this is such a genius ploy to sell more pixelblazes, because now I’m realizing I need a bunch of them to make more fruits!
3 Likes
There actually is a getPeers function in PBClient, so I was able to find the followers.
1 Like
Quick question before I break out a bunch of boards and run tests – @wizard what happens when PixelBlaze which have been set to follow the leader comes in and out of WiFi range?
As is unsurprising for anyone who’s read anything else I’ve posted in this forum, this is for a set of Wearables at Burning Man. I’d love ~10 different PixelBlaze (attached to coats, backpacks, helmets, etc) to be showing the same pattern sequences when they’re near each other, and then to fail gracefully when folks wander off and the devices can no longer “see” each other – and then re-sync if the leader comes into WiFi range of any of the follower devices.
I’d love to get a read on what SHOULD happen before testing, or even if that use case with mobile PB works in this release. Thanks.
@ZacharyRD, I just tested this, for nearly identical reasons – contemplating building a PB leader “beacon” on top of giant art car so when anybody with a camp Pixelblaze comes in range, they pick up audio information from the car’s sound system.
When the leader goes offline or the follower loses connection, the follower:
- continues in follower mode, running whatever pattern it was running when disconnected. (You can’t change patterns without taking it out of follower mode.)
- displays something like: “Follow: --Offline–” on its settings screen.
When the leader becomes available again, it reconnects automatically and keeps on following!
1 Like
Bingo, thanks @zranger1 ! That just saved me a set of testing. We’re doing basically the same thing, except I very much don’t have an art car.^ Luckily, with the palette rotation functionality I worked on with you, it can hold on a single pattern and be visually interesting for quite a while.
I COULD also built a composite pattern with multiple effects in it for this purpose – do you happen to recall which of the reference patterns I think you wrote gives example code for that?
^ My one rule of running Burning Man camps – come say hi to me at Bubble TEAse, 9:00 & C this year, serving Bubble Milk Tea 2-4 PM – has always been “no art cars, they only lead to pain and suffering” – especially since I live in the downtown of a major city. Bless you and everyone else who organizes them.
One more question – the pattern that is being run by the leader does not need to be locally on the follower devices, correct, even if they move out of WiFi range, @zranger1 ?
No, it doesn’t. The leader sends the pattern binary to the follower, and the follower just keeps it 'till the leader changes. If disconnected, it just keeps going.
The multisegment pattern and docs live here on github. It’s large these days – it’s used by a couple of commercial products and other open source home automation things, so there’s a lot of code for dealing with automation controls.
The core idea is simple though. For every subpattern you just write an individual beforeRender() and render(), make a table of pointers to the functions, then in the real beforeRender() and render(), you call the appropriate subpattern do the actual work. Just rotating through the subpatterns on a timer would be simple and nice looking.
1 Like
I’d like to add some fail safe mode that would let a follower continue playing a local. playlist or something. Then at some point a connection less method for more casual sync, like roving burner groups.
One idea until then, patterns could check for sensor board data stopping changing then do something different until it gets back in range.
3 Likes
Thanks – merging my 3-4 favorite patterns into a single pattern this way is now a stretch goal for me pre-Burning Man. (But also having a day job and running a theme camp both make that… borderline).
I’m not sure I understand your backup option here, but yes please to a feature request of “if follower loses connection to lead board, start playing pattern playlist; if connection is restored, continue following” – but I can visualize all sorts of ways that’d be a hard feature to implement in practice and have a lot of messy edge cases.
The workaround / backup option possible today would look like a super pattern that had everything you needed. In beforeRender it would compare some sensor board data against a previous copy. If different reset a time accumulator and copy the new value. If it’s the same, add to the accumulator. When the accumulator reaches some threshold, initiate the backup functionality. If new sensor board data arrives, resume normal operation.
Most sensor board data will have some noise, making them change between samples. EnergyAverage would be an easy one to start with. The whole frequencyData array is very unlikely to be identical between SB samples.
The super pattern could have a few patterns it cycles through while in backup mode.
1 Like
@wizard, I was going to ask about having followers save their state when connected and return to it when disconnected. A local playlist sounds great!
1 Like
This is so freakin’ cool!!! Is there a limit to how many PBs can become followers?
We’ve tested up to one leader and nine followers.
One limit we’re aware of is that if one of the Pixelblazes is providing the wireless network (it’s configured in Access Point mode and the others have joined that WiFi to create the sync group), you can’t have more than 10 clients connected to a Pixelblaze that’s serving as an access point. This is more a limitation of the ESP32 chip’s ability to handle a WiFi workload. More than that should work when using a traditional WiFi access point / router.
1 Like
I’m curious if anyone has integrated node ID’s into patterns?
Context: I have a set of wearables that’s following a leader with a sensor. Most of the time they’ll be using the same patterns, but I’d also like to have a couple patterns that, for example, would split frequencies or colors across each wearable. But, switching mappings back and forth on each PB wouldn’t be practical.
@john1 - Yes, a couple of us have tried it and it works pretty well. Just put your code for branching based on nodeId() in the condition of an if statement, and apply a different color or consume different frequencies based on it.
1 Like
I’m finally sitting down to play with this feature, with a PB+SB and PB.
I am wondering how being an AP and/or Leader impacts CPU and/or network performance. Obviously the PB+SB will be the Leader … and so I am thinking the other one should be the AP.
Any thoughts/comments? I guess if I had more followers, I might want to make the Leader the AP, since every WiFi packet goes through the AP and fewer bounces means the UDP is more likely to arrive 