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).
This request has been added to the queue for review by the @reviewers team.
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
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!
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.
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
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.
@jslarraz does that address your concern? Would you be able to cast a vote on the
remaining four interfaces? Thanks!
Hi — bumping this again. This request has been open since February 19 and we’re now approaching a month.
We have one +1 from @elisehdy for the four interfaces (bluetooth-control, bluez, network-manager, network-observe — we dropped network-control per her feedback). We just need a second reviewer vote to finalize.
We have devices deployed in the field that rely on OTA snap refreshes, and without auto-connect those refreshes break interface connections on headless, sealed appliances with no way to manually reconnect.
We’re pending production rollout on this approval. Would really appreciate someone being able to take a second look. Thanks!
Hey @matt-aris
Sorry for the delay in my response.
We do already use gadget connections for the interfaces the gadget can provide (bluetooth-control, network-manager, etc.)
Could you please clarify whether you are using the generic pi gadget snap or you are using a custom gadget snap?
I don’t know if we should grant these auto-connections in the public store, this sounds like something that should be in a dedicated enterprise store to be honest.
