Recently enrolled Raspberry-Pi5 devices don't show up on the host calendar

General/User Questions
1

Hello,

I followed the Edge SDK documentation to enroll a Raspberry Pi 5 device on Chameleon CHI@Edge, but it’s not showing up on the host calendar. The documentation doesn’t say much about debugging this, so any help would be really appreciated.

I’m attaching a screenshot that shows the health of the listed devices. Happy to share further details if needed.

Best,
Ravi

Screenshot 2025-02-20 at 7.41.21 PM
Screenshot 2025-02-20 at 7.41.21 PM1728×318 669 KB

2

Hey! I see that you have both a forum post, and a ticket with us.
For reference, (for you and anyone else searching), both are OK, but tickets are the best place for “help, I’m stuck and need someone to fix something”.

I replied there, but also wanted to share context on what that “X/4” health status means, so that its searchable.

Each device has 4 “workers”, which handle synchronizing some bit of state between services to bring the platform up. Once each worker “finishes” its job, the health status increments.

The workers complete in the following order, since they have some interdependencies:

  1. Balena: registers your device in the balena device manager, and populates a “target configuration” for system services that will run on it
  2. Tunelo: Generates the server-side of a wireguard tunnel for your device
  3. kubernetes: once the k3s worker on your device comes up and phones home, this registers it with the k3s cluster that sits “underneath” chi@edge
  4. blazar: once all other parts are happy, and it shows up as a usable kubernetes node, this task makes the device available to reserve via blazar, show up in the calendar, etc…

Unfortunately, there are a lot of things that can go wrong between steps 2 and 3, and we don’t yet show a lot of feedback. A device can make it to 2/4 even if you’ve never turned it on, since those steps run completely on our servers.

Once the device first powers on, and first successfully connects to the internet (this is why we recommend ethernet, to start), it pulls down the “target configuration” from step 1, including a set of service containers.
These service containers are what runs the k3s worker, and what connects to the client-end of the wireguard tunnel, and they must start succesfully before the k3s worker will start up, and the status move to 3/4.

So usually, being stuck at 2/4 means that your device doesn’t have connectivity to the internet, and via the internet to balena or chi@edge’s servers.

In this particular case though, the internet connection was healthy, and it was a misconfiguration on our side giving an old config to PI5s, so the k3s worker never started.

I hope this context is useful!