cwtv
/
wing-monitor
3
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2 Commits 1 Branch 0 Tags 4.7 MiB
Go 100%
Go to file
Jan Koppe 7de7a8ddaa
correct warn level identifier, disable mqtt autoreconnects 
warning level must be identified with 'warn' string to be formatted by
viri.

with the autoreconnecting things enabled, the mqtt library will try to
infinitely reconnect without showing the underlying issue. for now,
let's rather fail hard on the face and spit out the issue on the
console. better connection handling is still required, not sure how it
behaves when the mqtt connection breaks during runtime.
 		2024-12-16 17:04:00 +01:00
LICENSE initial commit 2024-12-14 21:52:32 +01:00
README.md initial commit 2024-12-14 21:52:32 +01:00
go.mod initial commit 2024-12-14 21:52:32 +01:00
go.sum initial commit 2024-12-14 21:52:32 +01:00
main.go correct warn level identifier, disable mqtt autoreconnects 2024-12-16 17:04:00 +01:00
wing-monitor initial commit 2024-12-14 21:52:32 +01:00

README.md

WING Monitor

This tool is used to monitor the recording status of a Behringer WING audiomixer.

It comes equipped with a dual slot SD card recorder. It also supports the standard OSC protocol in addition to its own proprietary protocol. Via OSC, we can control the entire mixer and also monitor the recording status.

The tool will check the recording status and remaining space every second via OSC. It checks for the following conditions:

  • At least one SD card is currently recording
  • All SD cards have at least 10 minutes of recording time left
  • No SD cards are in an "unknown" state.

There are additional ERROR conditions that can be checked via OSC, but these are not implemented yet.

When such a condition is detected, the tool will send an alert message to an MQTT broker. The alert message will contain a very brief text description of all the conditions that are currently not met.

To avoid spamming the MQTT broker, the tool will only send an alert after a minimum duration, and then repeat the alert after some duration. These durations are individual per alert, as some conditions are more severe than others (not recording at all versus space is running low).

Please do not take this code as an example - I do not call myself a developer. There's a lot of room for improvement, but it only needs to survive one very soon upcoming event for now.

Usage

  1. Clone this repository
  2. go build
  3. Run ./wing-monitor -help to see all options. The only one required by default is -wing-ip to point the tool to a WING mixer. You likely want to configure the MQTT broker as well.

Future Work

Keep track of requested parameters versus received parameters.

Because OSC is being used over UDP in this case, we effectively are dealing with asynchronous communication. When sending a request for a parameter to the WING, the response can come at some point after, in a random order, or not at all. Right now we're just ignoring this fact.

It would probably be a better idea to keep a log of all requests and match them with incoming responses. This way we know if we're still missing a response for a request.

If we're not doing that, the internal state representation might be wildly inaccurate: We might think that the WING is recording, but it isn't, because we're not getting any responses to our requests.

A quick-fix that I'll probably implement is to just keep track of the last time we received a response for a parameter. If it's been too long, we should start alerting.

Make this be a prometheus exporter instead

Currently this tool does a bad job of mimicing a full monitoring solution. I'd rather have it only be a good exporter and then use a commonly used prometheus/alertmanager stack to manage the alerts. This will also allow us to monitor the tool itself (including any OSC weirdness).

Why stop there? Generic OSC exporter?

In the end, we will be just requesting parameters via OSC and exporting them to prometheus. This could be done for any device that supports OSC. We could make this a generic exporter that can be configured to monitor any parameter from any device. I'm not sure how feasible this is, though. Many responses can be strings, which can be ugly to map to prometheus metrics.

License

This project is licensed under the MIT License - see the LICENSE file for details.