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?
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", ×tamp, &value);
if (result == LE_OK)
{
// handle reading.
}
else
{
// 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.
}
COMPONENT_INIT
{
...
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?
Hi,
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.
–Jen