Cloud is an extension, not the starting point

LilBub can pair with the Android companion over Bluetooth, accept nearby control, and keep local faces and device state without an account. Cloud connectivity adds account-backed management, synchronization, remote access, web Face Studio sessions, applet services, and a direct Wi-Fi route to the backend.

You can keep phone services available while cloud services are disabled. The device stores the connectivity choice and applies it regardless of what a browser or backend would prefer.

Choose the connection you need

Connection	What it is good for	What it needs
Nearby	Pairing, local control, local faces, and phone-provided features	Android companion, Bluetooth, and device approval
Phone-assisted	Cloud-authorized work delivered through a connected phone	Linked account, active phone session, and nearby Bluetooth
Direct cloud	Remote management while no phone is nearby	Wi-Fi, cloud link, and configured backend and broker services
Offline	Face, device UI, and state that already lives on the device	No active transport

The active route can change as the phone, Wi-Fi, or configured services become available. A route describes how a command is being carried; it is not a promise that every feature works on every route.

Control connectivity on LilBub

Open Settings → Connectivity on the device. This build exposes three independent choices:

• Phone services allows the nearby companion path.
• Cloud services allows account-linked cloud work when the device is linked and a network is available.
• Automatic updates controls scheduled update checks separately from ordinary cloud commands.

Disabling cloud services stops the direct cloud application route. It does not erase local faces or revoke an approved phone. Disabling phone services does not silently enable the cloud as a replacement.

Link to an account

Pairing starts with an explicit choice on LilBub:

• Connect phone app begins nearby Android pairing. Both screens show a short code for comparison before the device grants control.
• Link on the web shows the code used by the signed-in management site.

The device does not switch between these methods on a timer. If you chose the wrong path, cancel it and start the intended one.

A cloud link associates the device with an account and provisions the credentials needed for its direct broker connection. Nearby Android use continues to have its own device-approved identity.

What happens when a phone is nearby

Bluetooth is the preferred application route while an approved companion session is active. The phone can carry authorized work between the backend and the device. Wi-Fi may remain associated for a quick fallback, but the firmware pauses its direct MQTT application route so the same command is not delivered twice.

If the phone route ends and cloud services are enabled, LilBub can resume its direct Wi-Fi route. If neither route is available, the product reports the device as offline instead of pretending that a command was applied.

What still works offline

An offline LilBub continues to render its face and run device-local behavior. Existing device settings, installed content, local applet storage, and paired controller records remain on the device according to their own lifecycle.

Offline means that remote commands and synchronization must wait or fail cleanly. It does not mean the device has lost its identity or local state.

Features that depend on a remote service—such as a cloud integration fetching fresh external data—cannot complete until an appropriate route returns.

Diagnose an offline Bub

Work from the device outward:

1. Check the device UI. Confirm that phone or cloud services are allowed for the route you expect.
2. Check the nearby path. On Android, confirm Bluetooth permission, the approved device, and whether another client already owns the single nearby connection.
3. Check Wi-Fi. Confirm that the device has a known profile and is associated with the intended network.
4. Check the cloud link. A Wi-Fi connection alone does not create account ownership or broker credentials.
5. Check service health. The API, broker, Redis coordination, and account persistence each have separate failure modes.
6. Confirm delivery. A browser receiving an HTTP success is not enough for a device command; the device acknowledgement proves that the command reached firmware.

Developers can use the read-only checks in Serial and DeviceControl to separate device, Wi-Fi, pairing, API-target, and MQTT state.

Where data lives

Local faces can remain on the Android phone when no account session is active. Device-owned settings and applet data remain on LilBub. Account-linked persistent data is handled through the backend and its configured persistence. Short-lived presence and route leases belong to Redis. The broker carries device messages; it is not the system of record for account data.