Hi all,
This is a request for comments on a future feature.
I’ve been working on adding outgoing websocket connections. This would let you set up a websocket server somewhere, local or remote, that your Pixelblazes could connect to.
This would open up the possibility of controlling Pixelblazes remotely without a bunch of port forwarding tricks, and open the door for integration with other cloud services and integrations. You could also run this locally, and do Firestorm like things.
What could/would you do with this?
What Would be Supported
- The same websocket protocol and capabilities that exist now would be available, just with the connection going out to a server.
- I want to give folks a template/starter server project so that they can run their own PB server either locally or hosted somewhere.
- This would likely be a nodejs service, not totally unlike Firestorm. What would you like to see provided in a starter server?
- This would be enabled with a URL option in settings. You could add bits of data or tokens to the URL that the server could use, and the websocket can query the config to get the device ID, name, and other settings.
- This would work with group sync. Any pattern/control changes on the leader would sync even if followers weren’t connected to the remote service. Followers could also be connected for configuration/monitoring purposes, but would still sync patterns from their leader.
What it Wouldn’t Do
- I don’t plan on streaming status updates and preview frames since those could eat considerable bandwidth over potentially remote connections. At least not by default, or indefinitely, perhaps requested by a command. Otherwise, bandwidth is minimal with only pattern change notification messages.
- Aside from things already supported via the websocket like patterns, config, etc., the remote server wouldn’t have the same kind of full access to modify the files on a Pixelblaze that the local http API has.
- Initially, this will be over http, not https, though I hope to add that at some point. This is mainly due to the complexity and resource constraints of managing certs and the encryption itself.
- They joke there’s no ‘S’ for Security in IoT, even less without https, but I’m keeping an eye out for potentially dangerous things that this would open up. Firmware is already signed and prevents installing malware and that sort of thing (plus the websocket can’t push random firmwares), so your PB won’t be taken over if the remote service is compromised. But if hacked, it could delete patterns, config, and set LEDs to 100% full white. If you have thoughts/concerns on this I’d love to hear them!
Potential Directions / Uses
- Remote pattern, controls, and brightness management
- Coordinating several Pixelblazes distributed over more than a LAN/WLAN, like public installations with a hotspot.
- Easier home automation integrations
- Adapter / relay services like MQTT
- Future cloud service. While I want to start with and always have a cloud-free option, I think something like this could be useful for many folks. I’d like to hear your thoughts on this.