Description: This snap is a private, industrial IoT server used internally in an isolated factory environment (OT network) for Volvo Group. It manages Bluetooth sensors, LED visual alerts, and an OPC UA server.
We are requesting the use and auto-connection for several privileged interfaces to allow this headless device to act autonomously and recover from physical disconnections (Self-Healing Architecture):
snapd-control: Required to programmatically restart the wpe-webkit-mir-kiosk daemon locally when our python script detects an HDMI hotplug event. Since the device operates headless, it must recover its display automatically.
gpio-control: Required to drive multi-column industrial LEDs (Andon lights) directly connected to the Raspberry Pi GPIO pins to provide real-time visual alerts to operators on the assembly line.
hardware-observe: Required to monitor the HDMI DRM status (/sys/class/drm/card0-HDMI-A-1/status) to trigger the display recovery script mentioned above.
bluetooth-control & bluez: Required to establish connections with M5600 pressure sensors and dynamically reset/unblock the rfkill Bluetooth interface if the USB Bluetooth dongle is physically unplugged and replugged by an operator.
This snap is set to private, is not intended for the public Store, and will only be deployed on our own provisioned devices on a closed network. Could you please grant the use and auto-connection of these plugs?
Can you open a support ticket? Interfaces like snapd-control are generally scoped such that their installation and auto-connect is only allowed if a snap is installed from a specific brand store.
Regarding the support ticket: I am currently developing this as a Proof of Concept (PoC) within Volvo Group. As we are in the early stages of this industrial project, we do not yet have a dedicated Brand Store or a commercial support contract linked to this specific account.
The device is intended to run in a strictly Air-Gapped / Isolated network. Our deployment process uses snap install --dangerous locally.
If snapd-control is strictly restricted to Brand Stores even for private/sideloaded snaps, is there a recommended alternative interface for a snap to programmatically restart another snap (like our WPE Kiosk) upon a hardware event (HDMI hotplug)?
Or would it be possible to grant at least gpio-control, bluetooth-control, and hardware-observe for now, as those are critical for the assembly line operation?
No not really. Have you considered moving the observation of the relevant event and executing related action closer to one another? As in, within a snap, you can restart the services all you want. Note, snaps can communicate with each other as well, if there’s already some established pattern of communication, you can have one snap notify another. Though it still feels like moving the things around would be less painful.
Thank you for the clarification. I understand the restrictions on snapd-control. For this PoC, we will handle the kiosk refresh logic internally within the application layer to avoid cross-snap restarts.
However, could you please proceed with the review for gpio-control, bluetooth-control, and hardware-observe?
gpio-control is used to drive our industrial LEDs.
bluetooth-control is vital for our M5600 pressure sensors.
hardware-observe is used to detect the HDMI presence via DRM status. These are standard for an IoT gateway and do not grant control over other snaps.
