When designing an arcade cabinet that is running a Linux-based operating system, it is somewhat convenient to have messages relayed to some IoT device in order to be notified whenever certain events occur. As netplay for retroarch is currently designed, in order to play a multiplayer game, a user starts a hosting session and various other users connect to the netplay session. Hosting a netplay session will announce the game and the address to a lobby such that connecting users browsing the available games will see the game and then connect. However, waiting for a random player to join can take time such that all the attention cannot be permanently focused on the arcade machine.

The following design uses a few technologies used by Wizardry and Steamworks in the past and creates a system through which connecting clients to a netplay session will be displayed remotely on a desktop computer. Note that this document describes the entire setup which might be too specific, however someone implementing the same system can at any point deviate from the instructions and create something different. For instance, the goal has been to broadcast netplay connections to a notification server such as gotify and then receive the notifications via Winify (some Wizardry and Steamworks software to connect to a gotify server and display notifications) but it is entirely possible to announce the connections via a digital assistant such as Amazon Alexa.

• Winify for retrieving notifications from a remote gotify server,
• a gotify server installed somewhere accessible relative to the arcade machine being monitored,
• Lakka, even though Lakka has been used as the distribution for running retroarch, the system will apply the exact same way on a different Linux-based system,
• node-red, used for intercepting MQTT messages, formatting them and then sending them to the gotify server,
• mosquitto_pub for the Linux machine running the publisher script (mosquitto_pub and mosquitto_sub can be obtained for AARCH64 locally)

where:

• x.x.x.x:55435 is the IP address and port for netplay that the arcade machine is listening on,
• y.y.y.y:aaaaa is the IP address and port for the client connecting to the local netplay session

The flow should be easy to understand, in sequence:

• the arcade hosts a netplay session for a game,
• a client connects to the arcade netplay session,
• a script on the arcade machine detects the connection to its netplay port and publishes a message to an MQTT broker via the mosquitto_pub command,
• node-red sends a formatted message to a gotify server,
• Winify is used as an application to subscribe to the gotify server and pull the notification that a netplay client has connected

As a matter of comment, all blocks can run on separate machines and distributed across any IP range. Similarly, it should be said that Winify can be installed on any number of machines, in case the user wishes to receive notifications on multiple machines.

For the rest of the document, each individual block will be described in sequence.

Assuming that the operating system is Linux and that the machine benefits from the mosquitto_pub command as well as some basic Linux tools, the MQTT TCP port publishing script can be downloaded and stored on the local machine. We will assume that the arcade is running Lakka, but it should be obvious to any user that the same concept can be adapted to any other retroarch flavour.

The MQTT TCP port publishing script is downloaded and placed at /storage/.local/usr/local/bin/tcp-state.sh and made executable. Similarly, the mosquitto_pub tool is either cross-compiled or obtained locally for AARCH64 and then placed at /storage/.local/usr/local/bin/mosquitto_pub.

Finally, the /storage/.config/autostart.sh script should be modified in order to start the /storage/.local/usr/local/bin/tcp-state.sh script when the arcade machine boots up. Just adding the following line at the top of autostart.sh should suffice:

/storage/.local/usr/local/bin/tcp-state.sh &

The tcp-state.sh script is customizable and the parameters should be changed within the configuration section to specify the MQTT broker parameters, the configured retroarch port as well as other parameters relevant to the local install on the arcade machine.

The tcp-state.sh script has been designed with minimal requirements in mind and it has been the preferred method given that Lakka has been the retroarch distribution of choice especially since Lakka is based on LibreELEC that has a read-only filesystem thereby not allowing more powerful environments or tools to be installed unless the entire Lakka distribution is recompiled to include them.

Similarly, and unfortunately, retroarch does not contain any special API nor hooks that could be used for a more elegant solution to poll for certain events that take place within retoarch. In fact, in similar projects, python has been used to publish MQTT messages from the arcade machine to node-red but due to some python environment bugs within the current LibreELEC distribution, the fallback has been to use a simple shell script.

The corresponding node-red flow just subscribes to the topic configured in the tcp-state.sh on the arcade machine, listens for messages, formats the messages and passes them to a HTTP request that is made to a gotify server.

where, the interesting parts of the flow would be:

• the Report-by-Exception (RBE) node is used in order to not send multiple notifications for the same established connections,
• sending a message to the gotify server is performed via a simple HTTP POST connection to the gotify server

The HTTP POST node is configured with the following URL:

http://localhost:50111/message?token=BvxxYhy-2p-tVP1

where:

• localhost:50111 is the IP and port pair where the gotify server is listening for requests,
• BvxxYhy-2p-tVP1 is the token that was generated when creating a new application on the gotify server

After installing the gotify server, an application must be created, perhaps with an artistically suitable icon to match.

The token is then retrieved and to be used with the HTTP POST node in node-red as described for the previous chapter.

Winify is a Windows-only tool to receive notifications from a gotify server; it does so by subscribing to the gotify notification stream such that it does not use any polling but rather a producer-consumer pattern in order to not use up too many resources.

Nevertheless, there are many applications for various environments, even mobile devices, that are able to subscribe to a gotify server and receive notifications.

Using low-cost IoT devices is a good way to add a lot of quality of life to an arcade machine, particularly since distributions such as Lakka are designed to run on Small Board Computers. With some scripting and quite a minimal setup, it is possible to centralize certain events and be able to then, in turn, trigger other actions depending on what took place on the arcade machine.

In previous projects, logs have been read in from retroarch but unfortunately that solution is not really robust given that log files do not necessarily contain formatted information. Instead, and quite counter-intuitively, just a simple polling shell script seems to do the trick.