Okay, so let me tell you about my doorbell, from a #networking perspective.
When you push the button by the door, it sends a message over the #zigbee wireless mesh network in my house. It probably goes through a few hops, getting relayed along the way by the various Zigbee light switches and "smart outlets" I have.
Once it makes it to my utility closet, it's received by a Zigbee-to-USB dongle, through a USB hub (a simple tree network) plugged into an SFF PC. From there, it gets fed into zigbee2mqtt, which, as the name implies, publishes it to my local #mqtt broker.
The mqtt broker is in the small #kubernetes cluster of #raspberrypi nodes I run in my utility closet. To get in (via a couple of #ethernet switch hops), it goes through #metallb, which is basically a proxy-ARP type service that advertises the IP address for the mqtt endpoint to the rest of my network, then passes the traffic to the appropriate container via a #linux veth device.
I have #HomeAssistant, running in the same Kubernetes cluster, subscribed to these events. Within Kubernetes, the message goes through the CNI plugin that I use, #flannel. If the message has to pass between hosts, Flannel encapsulates it in VXLAN, so that it can be directed to the correct veth on the destination host.
Because I like #NodeRed for automation tasks more than HomeAssistant, your press of the doorbell takes another hop within the Kubernetes cluster (via a REST call) so that NodeRed can decide whether it's within the time of day I want the doorbell to ring, etc. If we're all good, NodeRed publishes an mqtt message (more VXLANs, veths, etc.)
(Oh and it also sends a notification to my phone, which means another trip through the HomeAssistant container, and leaving my home network involves another soup of acronyms including VLANs, PoE, QoS, PPPoE, NAT or IPv6, DoH, and GPON. And maybe it goes over 5G depending on where my phone is.)
Of course something's got to actually make the "ding dong" sound, and that's another Raspberry Pi that sits on top of my grandmother clock. So to get there the message hops through a couple Ethernet switches and my home WiFi, where it gets received by a little custom daemon I wrote that plays the sound via an attached #HiFiBerry board. Oh but wait! We're not quite done with networking, because the sound gets played through PulseAudio, which is done through a UNIX domain socket.
SO ANYWAY, that's why my doorbell rarely works and why you've been standing outside in the snow for five minutes.
The last update has been a while. I focused my attention to the MFDs (Multi-function display). This part didn’t get much attention yet and I was caught between the difficult choice to learn yet another fancy framework, like Raylib, that would do OpenGL ES 2.0 without X11 on the Raspberry – or just throw the might of my CoffeeLake at it and go with ReactJS since most of the data was already available via NodeRED anyway. Also… ARWES is just so cool 🤩
I went with ReactJS and ARWES again, simply because I have some experience in this by know thanks to my Streaming Overlay I wrote with it. Hobbling it up to NodeRED was just a matter of installing SocketIO to transport the messages. It’s all a very hacky mess but it gets the job done.
Video demonstration of my simulated cockpit made from cardboard on a budget mainly used to play Elite Dangerous in early 2022. This is work in progress.While seeking through the available data I noticed that I don’t get velocity values from Elite. That’s not so important in space but kinda interesting for me in planetary flight to satisfy the flight sim gamer in me as well. I noticed tho that I do get timestamped latitude, longitude and altitude values so shouldn’t it be possible to “simply” calculate this, right? Right?
This was when I dived into the rabbit hole of calculating velocity and heading on planetary objects using a spherical coordinate system and while I didn’t nail it exactly how Elite does it the result is close enough. The game provides the required data to go crazy here – most important the radius of the current object. In theory I could start writing some primitive AFS (Auto Flight System) routines now, which I’m totally going to explore at some point in the future just because 🤓
https://beko.famkos.net/wp-content/uploads/2022/02/simpit-velocity-calculations.jpgChecking my maths – yes, altitude is added to the mix so velocity is mostly correct as long as no rapid course changes are madeAfter spending way too much time with this and the Pythagorean theorem (Yes mum, a game made me do maths. MATHS! 🤯) I settled with some calculations and data for my current ship to the right and targeted ship data on the left. This is sort of tricky because many game events update different parts of the data so timestamps have to be kept in mind and a game specific parsing strategy is required. See the last part of the demonstration video to get an idea how this looks.
https://beko.famkos.net/wp-content/uploads/2022/02/simpit-situational-awareness.jpgImproving situational awareness by putting the video feed of wingman / gunner on the central MFD.Another point to tick off my list was getting the head tracking to work in Elite (again). Now this is very Linux PC specific so you may tune out on this paragraph. On Linux PC I’d usually compile Opentrack with the Wine Glue, patch in my appdata dir for Proton and hope that it’s still ABI compliant to Just work™. Alas recent Proton is sandboxed within pressure vessel and the usual approach of memory mapping is simply no longer working, if I got the gist of this right.
So my current strategy is to download and drop the Windows build of Opentrack into the game folder and chain-load the EXE with the game where the Opentrack EXE would listen on UDP while my native Opentrack BIN would send via UDP. A task not made easy with Proton but it is possible. The following snippet may give you some pointers:
#!/bin/bashexport STEAM_COMPAT_DATA_PATH=/games/steam/steamapps/compatdata/359320export STEAM_COMPAT_CLIENT_INSTALL_PATH="$HOME/.steam/steam"python3 /games/steam/steamapps/common/Proton - Experimental/proton run opentrack.exe
Why running Opentrack twice? The native build performs a lot better with my webcam and every frame really count here. Reading data via UDP is not much of a burden for Proton. This also saves me the trouble of fiddling with Wine Glue, a painful compile process nobody should endure involving installation of many many additional 32bit libraries. Hilarious but it works.