I’m aware of the sync features with the new PBs running 3.40 and above, I use 3 PBs and a pico as a group and they’re synced nicely.
I have a situation where I’m using an entirely separate PB for a project in my garage, that is driven by a home automation hub, called Hubitat.
Currently it’s using a driver written by @zranger1 which works well, however like firestorm and in the past. It eventually causes the PB to stop responding. I’ve had this experience in the past with websockets and the PB.
I thought I could rewrite the driver to simply connect to the PB and fire off a websocket frame that set a pattern, and then disconnect. This was because for my needs my automation doesn’t need to worry about state, I just want to send a message and change the pattern. If it works great, if not oh well.
However, rewriting the groovy code for the automation eventually cause the PB to stop responding to websockets with timeouts.
So I went to bed thinking about this, and realized/remember the group sync feature with the new firmware.
What if I tricked the PB in my garage to think the Hub for my Home Automation was a leader? Is there documentation on what these datagrams look like? I’m wondering if I spit out some code that would fire off a datagram with a pattern on it that would allow the PB to function normally and not get overwhelmed.
My six year old hubitat died a while ago, and I haven’t yet decided whether to replace it or to move to an open source platform, so I can’t give a lot of direct debugging help at this point.
That said, it’d be interesting to find out what’s going on that causes the PB to stop responding to websockets. Retrieving the pattern list and changing pattern should not be a significant load on either hub or Pixelblaze. So, my first guess would be that the connection is failing and being dropped, then reopened, then dropped again… possibly multiple times in succession.
In the driver source, you can check this by turning on “Debug Logging” for the device, then adding extra logDebug("something happened") statements to the connection management code, which lives in the block between approximately lines 266 and 466. If it is not able to maintain a connection, the first suspect would be wifi signal strength.
On making a fake leader: You could do this pretty easily on any “normal” platform, but the Hubitat doesn’t have any way for apps or drivers to start a thread that listens and responds to random UDP datagrams. So implementing a leader that worked for any length of time would be tough.
I (too?) found that having a controller device ‘wake up’; connect websocket; send command; disconnect’; go to sleep was unreliable.
I’d love a UDP interface! Or for me, BLE or ESP-now would be great, so my controller doesn’t even have to wait while it connects to WiFi AP. I was trying to implement a remote control for pixelblaze, and since the remote runs on battery, it’s off most of the time, until a button is pressed.