hwmon0 or hwmon1 With SHT21 Sensor

I have an application using a Beaglebone Black and a SHT21 sensor. I set the sensor up with the following command:

echo sht21 0x40 > /sys/bus/i2c/devices/i2c-2/new_device

My scripts that were written with a different Beaglebone Black use the following commands to get readings:

cat /sys/bus/i2c/devices/2-0040/hwmon/hwmon0/temp1_input
cat /sys/bus/i2c/devices/2-0040/hwmon/hwmon0/humidity1_input

On my current Beaglebone there is no hwmon0 but a hwmon1 instead.

What does this mean? Is there a way to know which one it will use? Is there a way to force one or the other?

Hello,

I think, at least w/ the newer images, /dev/bone/i2c/* are the files to use. Please see here:

https://docs.beagleboard.org/latest/intro/bone101/qwiic-stemma-grove-addons.html#using-i2c-with-linux-drivers

There is a short on i2c drivers in Linux dedicated to the BBB and other boards in general.

Seth

P.S. I noticed that there should be sysfs entries/files too but for the SHT21, I found some interesting ideas in the kernel docs.

Humidity¶
humidity[1-*]_input
Humidity.

humidity[1-*]_enable
Enable or disable the sensors.

humidity[1-*]_rated_min
Minimum rated humidity.

humidity[1-*]_rated_max
Maximum rated humidity.

and…

temp[1-*]_type
Sensor type selection.

temp[1-*]_max
Temperature max value.

temp[1-*]_min
Temperature min value.

temp[1-*]_max_hyst
Temperature hysteresis value for max limit.

temp[1-*]_min_hyst
Temperature hysteresis value for min limit.

temp[1-*]_input
Temperature input value.

temp[1-*]_crit
Temperature critical max value, typically greater than corresponding temp_max values.

temp[1-*]_crit_hyst
Temperature hysteresis value for critical limit.

temp[1-*]_emergency
Temperature emergency max value, for chips supporting more than two upper temperature limits.

temp[1-*]_emergency_hyst
Temperature hysteresis value for emergency limit.

temp[1-*]_lcrit
Temperature critical min value, typically lower than corresponding temp_min values.

temp[1-*]_lcrit_hyst
Temperature hysteresis value for critical min limit.

temp[1-*]_offset
Temperature offset which is added to the temperature reading by the chip.

temp[1-*]_label
Suggested temperature channel label.

temp[1-*]_lowest
Historical minimum temperature

temp[1-*]_highest
Historical maximum temperature

temp[1-*]_reset_history
Reset temp_lowest and temp_highest

temp_reset_history
Reset temp_lowest and temp_highest for all sensors

temp[1-*]_enable
Enable or disable the sensors.

temp[1-*]_rated_min
Minimum rated temperature.

temp[1-*]_rated_max
Maximum rated temperature.

Some chips measure temperature using external thermistors and an ADC, and report the temperature measurement as a voltage. Converting this voltage back to a temperature (or the other way around for limits) requires mathematical functions not available in the kernel, so the conversion must occur in user space. For these chips, all temp* files described above should contain values expressed in millivolt instead of millidegree Celsius. In other words, such temperature channels are handled as voltage channels by the driver.

Also see the Alarms section for status flags associated with temperatures.

So, it seems that if the first numerical value 1 in the first link I provided that shows 1 or 2 or 3 or whatever, one can then use this data to handle SHT21 values in their source.

So,

Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):

long v = simple_strtol(buf, NULL, 10) / 1000;
v = clamp_val(v, -128, 127);
/* write v to register */

That is directly from the Linux docs. You will have to get another person to handle the source, i.e. as I am terrible so far w/ source. But! I think these are good pointers for determining the source or echo commands to use to get started.

Hello Again,

So, it does seem that since libsensors3.0, there has been some changes.

If you read this doc. for hwmon-sysfs entries, it should make it sort of clear why things have changed:

https://docs.kernel.org/hwmon/sysfs-interface.html

Seth

P.S. I found a driver too: Kernel driver sht21 — The Linux Kernel documentation .

I’m not with the board right now but I’ll try out the /dev/bone/i2c/2 method.

I read the second link you posted about sysfs-interface. It was not helpful. It states the following:

Each chip gets its own directory in the sysfs /sys/devices tree. To find all sensor chips, it is easier to follow the device symlinks from /sys/class/hwmon/hwmon*.

I know this. What I am after is what determines what number the * is replaced with. I guess I could try and find it in /sys/devices which might be a more consistent path…

Linux in general gives out 0,1,2,3 in order… So something started probing for hwmon0 but failed, on the next load your module got hwmon1…

Regards,

1 Like

@afewgoblins ,

Now, we both know. So, @RobertCNelson , is there any way to handle Linux not blatantly naming hwmon1-~ oddly and w/out a set value?

Seth