[Beluga] Asteroid-Health: Step counter doesn't work

[therealmaxmoon]

I've installed AsteroidOS temporarily on my Oppo Watch [Beluga] using this tutorial.

After this, I've activated wifi over adb shell and updated everything with the following command:

opkg update && opkg upgrade

Then I've installed Asteroid-Health with the following command:

opkg install asteroid-health

After opening the app it only shows the following text:

You haven't yet logged any steps today

And the text doesn't change even if I am moving all the time.

What am I missing? 🤔

UPDATE

I did a permanent installation, because I thought Asteroid-Health doesn't have a persistent storage, but the issue is still there.

[moWerk]

Thanks for finally documenting this.
I have started an initiative to add the stepcounter state to the feature matrix on the website.
But that will need actual testing on all watches.
AsteroidOS/asteroidos.org#461

[Snoarlax]

Looking into this issue, it seems that the D-Bus service created by sensorfw is not sending messages relating to step counter updates as expected. Consequently, the Asteroid-Health app (which uses sensorlogd which connects to sensorfw) is not able to pull the step counter data.

I am in the process of debugging this further, but i suspect the issue is likely either the sensorfw layer or the libhybris layer (which sensorfw uses to use the relevant HAL that provides access to the sensor data on the watch).

root@beluga:~# busctl introspect com.nokia.SensorService /SensorManager/stepcountersensor
NAME                                TYPE      SIGNATURE RESULT/VALUE               FLAGS
local.StepCounterSensor             interface -         -                          -
.bufferInterval                     method    -         u                          -
.bufferSize                         method    -         u                          -
.description                        method    -         s                          -
.errorString                        method    -         s                          -
.getAvailableBufferIntervals        method    -         a(uu)                      -
.getAvailableBufferSizes            method    -         a(uu)                      -
.getAvailableDataRanges             method    -         a(ddd)                     -
.getAvailableIntervals              method    -         a(ddd)                     -
.getCurrentDataRange                method    -         (ddd)                      -
.hwBuffering                        method    -         b                          -
.id                                 method    -         s                          -
.interval                           method    -         u                          -
.isValid                            method    -         b                          -
.removeDataRangeRequest             method    i         -                          -
.requestDataRange                   method    i(ddd)    -                          -
.setBufferInterval                  method    iu        -                          -
.setBufferSize                      method    iu        -                          -
.setDataRangeIndex                  method    ii        b                          -
.setDataRate                        method    id        -                          -
.setDefaultInterval                 method    i         b                          -
.setDownsampling                    method    ib        -                          -
.setInterval                        method    ii        -                          -
.setStandbyOverride                 method    ib        b                          -
.standbyOverride                    method    -         b                          -
.start                              method    i         -                          -
.steps                              method    -         (tu)                       -
.stop                               method    i         -                          -
.type                               method    -         s                          -
.bufferInterval                     property  u         0                          emits-change
.bufferSize                         property  u         0                          emits-change
.description                        property  s         "steps since boot"         emits-change
.errorCodeInt                       property  i         0                          emits-change
.errorString                        property  s         ""                         emits-change
.hwBuffering                        property  b         false                      emits-change
.id                                 property  s         "stepcountersensor"        emits-change
.interval                           property  u         0                          emits-change
.isValid                            property  b         true                       emits-change
.standbyOverride                    property  b         false                      emits-change
.steps                              property  (tu)      0 0                        emits-change
.type                               property  s         "StepCounterSensorChannel" emits-change
.StepCounterChanged                 signal    (tu)      -                          -
.propertyChanged                    signal    s         -                          -
org.freedesktop.DBus.Introspectable interface -         -                          -
.Introspect                         method    -         s                          -
org.freedesktop.DBus.Peer           interface -         -                          -
.GetMachineId                       method    -         s                          -
.Ping                               method    -         -                          -
org.freedesktop.DBus.Properties     interface -         -                          -
.Get                                method    ss        v                          -
.GetAll                             method    s         a{sv}                      -
.Set                                method    ssv       -                          -
.PropertiesChanged                  signal    sa{sv}as  -

I will look into this further, but i'm seeing some interesting error messages in sensorfw which may indicate a bug:

root@beluga:~# journalctl -u sensorfwd -b-0
Feb 23 12:53:47 beluga systemd[1]: Starting Sensor daemon for sensor framework...
Feb 23 12:53:48 beluga systemd[1]: Started Sensor daemon for sensor framework.
Feb 23 12:53:49 beluga sensorfwd[621]: Hybris sensor manager initialized
Feb 23 12:53:49 beluga sensorfwd[621]: HYBRIS CTL invalid sensor type: 8
Feb 23 12:53:49 beluga sensorfwd[621]: HybrisAdaptor::HybrisAdaptor(const QString&, int) no such sensor "proximityadaptor"
Feb 23 12:53:49 beluga sensorfwd[621]: Node ' "proximityadaptor" ' state changed to invalid
Feb 23 12:53:49 beluga sensorfwd[621]: SensorManagerError:  "adaptor 'proximityadaptor' can not be started"
Feb 23 12:53:49 beluga sensorfwd[621]: Node ' "proximitysensor" ' state changed to invalid
Feb 23 12:53:49 beluga sensorfwd[621]: "proximitysensor instantiation failed"
Feb 23 12:53:49 beluga sensorfwd[621]: SensorManagerError:  "sensor has not been instantiated"
Feb 23 12:53:58 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:53:58 beluga sensorfwd[621]: No initial data for heart rate monitor
Feb 23 12:53:58 beluga sensorfwd[621]: No initial data for heart rate monitor
Feb 23 12:53:59 beluga sensorfwd[621]: [SocketHandler]: Socket connection for session 1 hasn't been estabilished. Considering session lost
Feb 23 12:53:59 beluga sensorfwd[621]: [SocketHandler]: Trying to remove nonexistent session.
Feb 23 12:54:08 beluga sensorfwd[621]: [SocketHandler]: Socket connection for session 6 hasn't been estabilished. Considering session lost
Feb 23 12:54:08 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:54:08 beluga sensorfwd[621]: [SocketHandler]: Trying to remove nonexistent session.
Feb 23 12:54:08 beluga sensorfwd[621]: [SocketHandler]: Socket connection for session 8 hasn't been estabilished. Considering session lost
Feb 23 12:54:08 beluga sensorfwd[621]: No initial data for heart rate monitor
Feb 23 12:54:08 beluga sensorfwd[621]: [SocketHandler]: Trying to remove nonexistent session.
Feb 23 12:54:08 beluga sensorfwd[621]: [SocketHandler]: Socket connection for session 10 hasn't been estabilished. Considering session lost
Feb 23 12:54:08 beluga sensorfwd[621]: [SocketHandler]: Trying to remove nonexistent session.
Feb 23 12:57:46 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:57:46 beluga sensorfwd[621]: No initial data for heart rate monitor
Feb 23 12:59:31 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:59:55 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:59:55 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:59:56 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:59:56 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:59:56 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 12:59:56 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 13:00:43 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter
Feb 23 13:00:43 beluga sensorfwd[621]: "stepcounteradaptor" No initial data for step counter

[xuv]

Landed here to confirm that I have similar issues with Oppo Beluga. I've looked at the files in /home/ceres/.asteroid-sensorlogd/ and it shows some log files. But all entries under stepCounter show 0.
While entries under heartrateMonitor show different values.

Thanks @Snoarlax for looking into this. Anyway we can help here?

[Snoarlax]

I've taken a short break for now, but am currently trying to debug sensorfw. My current theory is that there is an issue in how sensorfw detects and loads the relevent HAL for the step counter, i've tried some patches but nothing has worked so far. I'll jump back on it when I have more time but feel free to take a look also and work alongside me if you have any ideas - someone with stronger debugging skills might be able to solve this one quicker.

[xuv]

Since I'm quite new to all this, I'm not sure I can be much productive. But will give a try. One question though: this has worked before. People have had the stepcounter working at some point? If so, should we try to look what changed between then and now? Le 8 mars 2026 09:43:23 GMT+01:00, Snoarlax ***@***.***> a écrit :

…

Snoarlax left a comment (AsteroidOS/asteroid#324) I've taken a short break for now, but am currently trying to debug sensorfw. My current theory is that there is an issue in how sensorfw detects and loads the relevent HAL for the step counter, i've tried some patches but nothing has worked so far. I'll jump back on it when I have more time but feel free to take a look also and work alongside me if you have any ideas - someone with stronger debugging skills might be able to solve this one quicker. -- Reply to this email directly or view it on GitHub: #324 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[moWerk]

Following up on Snoarlax's finding that the sensorfw D-Bus interface is valid and the stepcounteradaptor is created but never receives data:
My full journal analysis after a fresh flash on a belugaxl confirms the vendor.sensors-hal-1-0 HIDL service crashes with exit code 255 on every boot, tho sensorfwd bypasses this by opening the sensor .so file directly via libhybris.
The kernel-level SensorHub registers successfully on boot, and HRM and barometer both deliver data correctly through the same path. Sugggesting the issue is specific to how the sensor hub routes step data.
A possible cause an LLM pointed me at is that "the OPPO sensor hub firmware requires OPPO's proprietary Android system services to activate step counter routing through the standard Android TYPE_STEP_COUNTER (sensor type 19) interface. Without those services running under AsteroidOS, the HAL simply never fires StepCounterChanged events regardless of movement."

A useful next debugging step would be to check if the HAL reports "sensor type 19" as present when enumerated, which would confirm whether this is a HAL registration or a data delivery issue.
I am not sure if i find time to "vibe" on this. I frankly miss basis and it would sure be more efficient if someone like Snorlax would find time to investigate further instead of me prompting in circles. Maybe i'll give it a shot at some point.

[h-rihani]

Following up on the sensorfw / libhybris investigation above, I did some more debugging on a real Beluga watch with adb.

Disclosure: this debugging work was done with help from GPT-5.4.

One extra concrete data point: on my AsteroidOS install, the value exposed by sensorfw for the step counter never changes from zero:
busctl get-property com.nokia.SensorService /SensorManager/stepcountersensor local.StepCounterSensor steps

Even after movement, this stayed at (tu) 0 0.

That seems to narrow it further to the current sensorfw HybrisStepCounterAdaptor path.

The most concrete code-side thing I found to try is in sensorfw:

adaptors/hybrisstepcounteradaptor/hybrisstepcounteradaptor.cpp

For the sensorfw revision Beluga is using, the patch I would test is setting a default interval before starting the step counter in HybrisStepCounterAdaptor::startSensor():

unsigned int interval_us = 200 * 1000;
setDefaultInterval(interval_us);

I cannot test a rebuilt package myself because I do not have the full Beluga/AsteroidOS build environment set up locally, but this looks like the most concrete next thing to try from the code side. If someone else here has the proper build/setup to test this patch, that would be very helpful.

[moWerk]

I cannot test a rebuilt package myself because I do not have the full Beluga/AsteroidOS build environment set up locally, but this looks like the most concrete next thing to try from the code side. If someone else here has the proper build/setup to test this patch, that would be very helpful.

Tested the setDefaultInterval patch via D-Bus directly (no rebuild needed, the method is exposed on the sensorfw interface):

dbus-send ... local.StepCounterSensor.setDefaultInterval int32:200000
dbus-send ... local.StepCounterSensor.start int32:42

ssh root@beluga 'dbus-send --system --print-reply --dest=com.nokia.SensorService /SensorManager/stepcountersensor local.StepCounterSensor.setDefaultInterval int32:200000 dbus-send --system --print-reply --dest=com.nokia.SensorService /SensorManager/stepcountersensor local.StepCounterSensor.start int32:42'

Handle 0x13 confirmed active in logcat throughout the test.
05-07 17:10:19.651 I/SensorService( 4298): >>>>>>>>>>>>>activate handle =0x13 enabled=1<<<<<<<<<<<<

Value stayed at (0, 0) over 20 minutes of walking.

ssh root@beluga 'dbus-send --system --print-reply --dest=com.nokia.SensorService /SensorManager/stepcountersensor org.freedesktop.DBus.Properties.Get string:local.StepCounterSensor string:steps'
method return time=1778175063.817149 sender=:1.87 -> destination=:1.127 serial=180 reply_serial=2
   variant       struct {
         uint64 0
         uint32 0
      }

The interval patch does not change the outcome in my testing.

A separate finding from my session (using Claude) that is fixable:

"The vendor RC file for the sensors HAL contains a post-fs-data trigger that sets chmod 0777 on /dev/std_sns. This trigger never fires in AsteroidOS because vold does not run. Without it, the sensors HAL starts as user system, fails to open /dev/std_sns (crw------- root root), and crashes with exit 255 before registering with hwservicemanager. After manually applying chmod 0666 to the snshub device nodes, the HAL opens std_sns successfully, registers properly, and all sensors including the step counter are correctly activated. The step counter still returns zero, but the HAL is now in a healthy state. This permissions issue should be fixed in the port regardless of the step counter outcome — a udev rule for the snshub device nodes would be the right fix.

The fundamental step counter problem appears to be in the OPPO sensor hub MCU firmware, which requires OPPO's proprietary Android system services to enable its pedometer algorithm. The HAL correctly exposes the sensor and accepts activation, but the MCU simply does not report steps without those services."

I am not certain about the final verdict but wanted to share these findings in case it might help.

[moWerk]

While investigating the std_sns permissions issue, I got a hint to an older meta-smartwatch issue (#146) by MagneFire that appears highly relevant to solving step counting properly.

Again via Claude:

"That issue documents that the OPPO sensor hub MCU is controlled via binder messages sent to deamonserver, which is already running on AsteroidOS as part of the beluga android-init config. The Java decompilation work done there reveals the exact transaction format used to send mode commands to the MCU:

_data.writeInterfaceToken(ISensorHubService.DESCRIPTOR);
_data.writeInt(bussnessID);
_data.writeInt(1);
data.writeToParcel(_data);
mSensorHubService.transact(1, _data, _reply, 0);

For Power Saver mode the relevant business IDs were found to be 373-375. The step counter enable command would be a different ID in the same SensorHubManager class, likely in boot-framework.vdex. If that ID can be found via decompilation or by stracing the deamonserver on a stock Android boot, a small libgbinder-based tool following the bluebinder or geoclue-hybris-plugin pattern could send it on AsteroidOS boot to activate the pedometer algorithm in the MCU firmware."

This seems like the most concrete remaining path forward. The infrastructure is already in place as it seems. It just needs the right message ID and payload afaiu.

[moWerk]

Further investigation with full eMMC dump and live journal/logcat analysis on a freshly flashed belugaxl points to a specific failure in the MCU initialzation chain.

The deamonserver (which is already running on AsteroidOS as part of the android-init config) logs the following on every boot:

getService mcu ERROR

This happens roughly 17 secunds after boot, right after the snshub driver logs "the MCU just reset, received first frame". The sequence is:

deamonserver opens /dev/snshub_data and writes an initial message
MCU resets and sends its first frame
deamonserver attempts to bind to an Android service named "mcu" via the service manager
the bind fails because that Java system service does not exist on AsteroidOS
deamonserver enters a broken state, flooding the log with "read fail err=-1, errno=4"

On stock OPPO Android, the "mcu" service is the McuManager system service (android.app.wear.McuManager), which is part of the WearOS framework layer. Without it, the MCU initialization sequence never completes after the reset, and the pedometer algorithm in the MCU firmware stays inactive.

I also captured the exact nanopb protobuf wire format that the sensors HAL writes to /dev/std_sns when activating a sensor. For reference, activating the step counter (Android sensor type 19, handle 0x13) would be a 20-byte message with the sensor handle encoded as a fixed32 at field offset 5 in the ActivatePayload sub-mesage. Writing this directly to std_sns had no effect, which is consistent with the MCU not being initilized.

I own a few beluga variants and can flash one back to stock WearOS. The most useful thing that could come from that is stracing the deamonserver during a stock boot to capture exactly what gets written to /dev/snshub_data after the MCU reset, and what the "mcu" service provides to complete the initialization. That sequence could then potentially be replayed on AsteroidOS, either via a small tool using the existing deamonserver binder interface or by writing the snshub_data bytes directly.

A separate but fixable issue found along the way: the vendor RC file for the sensors HAL contains a post-fs-data trigger that sets chmod 0777 on /dev/std_sns. This trigger never fires on AsteroidOS because vold does not run. The sensors HAL starts as user system, fails to open std_sns, and crashes with exit 255. Adding a udev rule for the snshub device nodes fixes this and gets the sensors HAL properly registered with hwservicemanager. It does not fix step counting but it is a real improvement worth landing separately.