@@ -8,14 +8,42 @@ mediactl sports a touchscreen that allows control of the media technology in tha
...
@@ -8,14 +8,42 @@ mediactl sports a touchscreen that allows control of the media technology in tha
## architecture
## architecture
There is a fastapi web service (`localhost:8000`) running behind an nginx reverse proxy that exposes it to the world. The service has a systemd unit file located at `/etc/systemd/system` (see section below).
There is a fastapi web service (`localhost:8000`) running behind an nginx reverse proxy that exposes it to the mediahell network. The service has a systemd unit file located at `/etc/systemd/system/mediactl.service` (see section below).
The touchpanel is started with raspi-autologin and the `.xinit` file located in the `d0` user directory (see section below). The files of the running webservice are located at `/home/d0/mediactl` (see section below for hints if you want to edit those files).
The touchpanel is started with raspi-autologin and the `.xinit` file located in the `d0` user directory (see section below). The files of the running webservice are located at `/home/d0/mediactl` (see section below for hints if you want to edit those files).
## autostart on RPI
```mermaid
See [this](https://blog.r0b.io/post/minimal-rpi-kiosk/) for a description of how to start chromium via `/home/d0/.xinit` – note: this file contains the screen blanking settings (`xset s 600 0` )
The fastapi code receives commands via Websockets from a browser and then uses the connector implementations in [src/devices](src/mediactl/devices/) to send/receive commands to these devices. The results are then sent back via websocket to said browser to give a quick feedback of what is going on. The javascript handling that is in [static/modules](static/modules).
The entry point handling the websockets on the client (browser) side is [ws.js](master/static/ws.js). The javascript part could be organized better and more generically, but it works and is highly customizable.
On the server side (FastAPI) most of the system state (including the device connectors mentioned above) is organized in the class `System` in [src/mediactl/system.py](src/mediactl/system.py).
The main entry point of the whole application [src/mediactl/main.py](src/mediactl/main.py) is relatively typical for a FastAPI application, the only noteworthy thing is that the application maintains *two* websocket connections at the same time, one for sending/receiving commands, one for scheduled sending of the current system status back to the connected browsers. I tried for half a day to do this with one websocket, but it turned out to be more trouble than it was worth.
Within that `main.py` file the async function `handle_incoming_messages(data)` is responsible for handling received commands. If one wanted to add new commands, it would be here.
## Autostart chromium in kiosk mode
See [this](https://blog.r0b.io/post/minimal-rpi-kiosk/) for a description of how to start chromium via `/home/d0/.xinit` – note: this file contains the screen blanking settings (`xset s 600 0` ) which are responsible for blacking out the screen.
| AC123 Remote | GPIO and GND | Controls Screen motor via Radio (Up/Down/Stop) | GPIO, Pull port to GND to switch | [screen.py](src/mediactl/devices/screen.py) |
| GPIO 21 | Kramer | Switch to Input 4 | Pull to GND to switch | Brown+Brown/White |
| GPIO 20 | Kramer | Switch to Input 3 | Pull to GND to switch | Blue + Blue/White |
| GPIO 26 | Kramer | Switch to Input 2 | Pull to GND to switch | Orange + Orange/White |
| GPIO 16 | Kramer | Switch to Input 1 | Pull to GND to switch | Green + Green/White |
| GND (34) | AC123 Remote | GND | GND | Black |
| GPIO 13 | AC123 Remote | Screen moves Up | Pull to GND to switch | Green |
| GPIO 6 | AC123 Remote | Screen stops | Pull to GND to switch | White |
| GPIO 5 | AC123 Remote | Screen moves Down | Pull to GND to switch | Red |
## AC123-Remote
This is the screen remote we got from the company who added the motorized screen to the room. I tried to reverse engineer the custom 433 Mhz protocol, but then decided to just use the remote control which offers 3.3V pins. This has the benefit that mediactl could always "know" wheter the screen has previously been moved down or not (except if you shutdown the system inbetween).

# Development
## Isolation in mediahell, how to use apt
Devices can't reach the outside world in mediahell (hence the name). This also includes things like `apt`. To update/install packages you have to use a SSH-tunnel to your dev machine.
In `/etc/apt/apt.conf.d/proxy.conf` there is a proxy connection setup:
In `/etc/apt/apt.conf.d/proxy.conf` there is a proxy connection setup:
**⚠ Important:** If you edit any of the static files (css/images/js/etc) you need to run the `./deploy_static.sh` script afterwards, else those changes will not be used in production !
**⚠ Important:** If you edit any of the static files (css/images/js/etc) you need to run the `./deploy_static.sh` script afterwards, else those changes will not be used in production !
| Allen&Heath AHM16 | Ethernet | Audio DSP and Mixer | [TCP Protocol](https://www.allen-heath.com/content/uploads/2023/11/AHM-TCP-Protocol-V1.4.pdf)(essentially MIDI over IP) |
| RPI 3B "projctl" | Ethernet/WIFI (REST via mediahell wifi) | Controlling and monitoring the projector | see [code.hfbk.net](https://code.hfbk.net/medientechnik/ext-lib/projctl) |
| Kramer VS-411X | GPIO and GND | Switching HDMI-Sources, Audio Extractor | GPIO, Pull port to GND |