Auto-connection request: aris-hydronics

store-requests privileged-interfaces
1

snap name: aris-hydronics description: Embedded controller for Aris whole-home hydronic heating, cooling, and hot water systems. Runs on Ubuntu Core on a Raspberry Pi inside a sealed, headless HVAC appliance. Ships three daemons: a Brain (system controller), a CoAP bridge (Thread mesh networking), and a BLE WiFi provisioning daemon (Improv WiFi standard). snapcraft:

https://github.com/ArisHydronics/aris-brain/blob/main/snap/snapcraft.yaml

upstream: https://github.com/ArisHydronics/aris-brain upstream-relation: upstream maintainer

This is a commercial IoT HVAC appliance running Ubuntu Core on Raspberry Pi. Devices are deployed headlessly in mechanical rooms with no user present at install time, so manual snap connect is not feasible.

interfaces:

bluetooth-control:

  • request-type: auto-connection
  • reasoning: The ble-provision daemon implements the Improv WiFi open standard over BLE GATT. On first boot with no network configured, it advertises a BLE service so the installer can send WiFi credentials from a phone or laptop. Without auto-connection, the daemon cannot access the Bluetooth adapter and the device has no way to get on the network.

bluez:

  • request-type: auto-connection
  • reasoning: The ble-provision daemon uses the BlueZ D-Bus API to register a BLE GATT service and manage advertisements. This is used alongside bluetooth-control for the Improv WiFi provisioning flow described above.

network-manager:

  • request-type: auto-connection
  • reasoning: The ble-provision daemon calls NetworkManager over D-Bus to apply WiFi credentials received via BLE. The Brain daemon also reads network state from NetworkManager for diagnostics. Without this interface, BLE provisioning can receive credentials but cannot actually configure WiFi.

network-control:

  • request-type: auto-connection
  • reasoning: The ble-provision daemon reads the device MAC address to generate its BLE advertisement name (“Aris-XXXX”). The Brain daemon uses it for advanced network diagnostics. On a headless appliance, manual connection is not practical.

network-observe:

  • request-type: auto-connection
  • reasoning: The ble-provision daemon checks whether ethernet or WiFi is already configured at startup to decide whether BLE advertising is needed. Without this, the daemon cannot determine network state and would either always advertise (confusing) or never advertise (broken provisioning).
2

This request has been added to the queue for review by the @reviewers team.

3

Hello @matt-aris, Thank you for the detailed request! Given the outlined snap functionality, this is a +1(#voteFor) from me for granting auto-connect to the aris-hydronics snap for the following interfaces: bluetooth-control, bluez, network-manager, and network-observe.

Could you provide some more details around the need for network-control? It is my understanding that network-observe should be sufficient for reading device MAC address and most network diagnostics.

1 Like
4

Hi @elisehdy, thank you for the quick review and the +1!

You’re right — after double-checking our code, network-observe and network-manager together cover everything we need. We use network-manager for WiFi scanning/connecting during BLE provisioning, and network-observe for reading MAC addresses and network state. We don’t use raw sockets, iptables, or any other operations that would require network-control.

Happy to drop network-control from the request. The interfaces we need are:

  • bluetooth-control — BLE GATT server for Improv WiFi provisioning
  • bluez — BlueZ D-Bus API for BLE advertisements
  • network-manager — WiFi configuration during provisioning
  • network-observe — Reading MAC address and network diagnostics

Thanks again for catching that!

5

Friendly bump — this has one +1 from @elisehdy and the scope is narrowed to the four interfaces listed above. Could another reviewer take a look? Happy to provide any additional context.

6

Hey @matt-aris

Given that you are producing the device, I think it should be possible to use [cloud-init](https://docs.cloud-init.io/en/latest/reference/yaml_examples/snap.html) to connect these interfaces.

1 Like
7

Thanks for the suggestion! We do already use gadget connections for the interfaces the gadget can provide (bluetooth-control, network-manager, etc.). However, the store auto-connection grant covers interfaces like bluez and network-observe that aren’t gadget-provided, and importantly ensures new interface plugs are connected automatically during OTA snap refreshes — which matters since these devices deploy headlessly in sealed mechanical spaces with no on-site access.

8

@jslarraz does that address your concern? Would you be able to cast a vote on the remaining four interfaces? Thanks!