Local and remote devices simultaneously (kind of)

[EAGrahamJr]

A bit of a fun/pointless exercise, but interesting nonetheless...

The small OLED to the right is driven "locally" by a Pi 4 (black vertical box with SparkFun qwiic pHat) and displays the luminosity of a sensor (also attached to the pHat). The application is running on this machine.

The bright LED strip on the left is on a Pi 3B+ - and this is running the GRPC remote server. The LED's are showing the temperature (relative) of the Pi 4, which is sending the LED commands via GRPC.

Unfortunately, it's pretty easy to over-run buffers running a multi-threaded app like this (the GRPC remote just kind of "stops" after a bit, no exceptions), but I don't necessarily think this is a typical scenario.

[mattjlewis]

Very nice, like the OLED, in fact I’d like to improve the OLED support. I’ve been tinkering with ESPHome recently and quite like some of the interfaces they expose.
Not good about gRPC lockup, definitely something to look into. I have done some performance testing to assess the overhead of gRPC but don’t think I’ve seen lockups.
I had assumed it was high performance but I didn’t get great results tbh. Will dig deeper.

[EAGrahamJr]

Well, I'm doing some crazy-:asterisk: multi-threading stuff, so it might be my own stuff. I also apparently had a mis-configured Pi, network issues, and 3 or 4 other things that may have been playing into it, as well.

[EAGrahamJr]

Combination of an uncaught exception, a slow Pi, and trying to do sub-millisecond timing over GRPC. I added a bit of buffering to my app to compensate and it works pretty good.

Part of the "problem" is likely just "efficiency": the GRPC message is larger than the actual data (e.g. one or two byte r/w inside the protobuf wrapper` 😀 ) and it just takes time to process that on both ends, plus the time in the HTTP2 client/server (and threading thereof). So trying to debounce a button is kinda funky...