How to use sensors in mangoh-yellow

How to use sensors in mango-yellow??

As for temperature, api is well supplied as in “le_temp”.

Is there an api that makes it comfortable to use accelerometers, gyroscopes, pressure, humidity, air quality, temperature and photometric sensors?

You can fetch that information from the Data Hub using the Data Hub APIs. Some of the other APIs may be available in some cases, but in many cases they have not yet been implemented for Yellow.

To generate the Data Hub API documentation, you can

$ cd apps/DataHub
$ make docs

The documentation will appear under docs/html. You can view it by opening the it in a web browser.

$ firefox docs/html/index.html

Unfortunately, this is not quite as straightforward as using specialized APIs, but once you learn how to do it, it works the same for any type of sensor or actuator that is connected to the Data Hub.

For example, to get the mangOH Yellow’s light sensor to start performing readings, you need someone to set its period and enable resources. This can be done via Octave or using the dhub command-line tool. You can also use the Data Hub’s Admin API to do it from your own app.

admin_PushNumeric("/app/light/period", 0, 10.0 /* seconds */);
admin_PushBoolean("/app/light/enable", 0, true);

Then, to fetch the last light sensor reading, you can use the Data Hub’s Query API.

double timestamp;
double value;
le_result_t result;

result = query_GetNumeric("/app/light/value", &timestamp, &value);
if (result == LE_OK)
    // handle reading.
    // handle lack of reading.

Or, if you’d prefer to get a call-back every time a new sensor reading is taken, you can set that up using the Admin API.

static void ProcessLightLevelSample(double timestamp, double value, void* contextPtr)
    // Process the sensor reading.

    admin_AddNumericPushHandler("/app/light/value", ProcessLightLevelSample, NULL);

Thanks your answer!!

I try to study your answer…!
but in many cases they have not yet been implemented for Yellow…??? i’m so sad…
Where i can refer to API just a little?? you know?


In general, you can check what services are being offered by running the sdir list command on the target device shell. Look in the SERVICES section of the output.

I see that the following sensor APIs are available:

  • <root>.ma_battery
  • <root>.light
  • imu.imu (gyro and accelerometer)
  • imu.temperature (temperature of the IMU)
  • environment.mangOH_bme680

Unfortunately, because the apps that serve the ma_battery and light APIs are running unsandboxed, they just show up as “<root>” in the list of services. You should be able to bind to those using “<root>.ma_battery” and “<root>.light”, but you can also bind to those using “battery.ma_battery” and “light.light” (because the apps that serve those are called “battery” and “light”).

You can use find and grep to hunt for which applications’ .adef files export those APIs, if you want. For example,

$ find -name '*.adef' | xargs grep 'ma_battery'
./apps/BatteryService/battery.adef:        battery.batteryComponentRed.ma_battery
./apps/BatteryService/battery.adef:        battery.batteryComponentYellow.ma_battery
./samples/BatteryClient/batteryClient.adef:    batteryClient.batteryClientComponent.ma_battery -> battery.ma_battery

Sadly, I can’t think of a more user-friendly way to find this information. (Seems like there’s an opportunity to add a handy Legato feature for this.) But, as I said, you should be able to bind to “<root>.ma_battery” and “<root>.light” (exactly as it appears in the sdir list output) to make it work. The only downside of binding to <root>.ma_battery instead of battery.ma_battery is that your binding would break if the battery app were changed to run in a sandbox. But, that’s easy to fix.

To find the .api files, you can use find.

$ find -name ma_battery.api

Once you have “required” the .api files in your Component.cdef, added your bindings to your .adef or .sdef, and run a build, you can find the generated .h files using find. E.g.,

$ find -name ma_battery_interface.h

I hope this helps.