Bug in the internal I2C LM75 code

[ullix]

I am experimenting with I2C devices and noticed a problem with the I2C LM75AD temperature sensor, using the "native" driver xsns_26, index 20 on the I2C DEVICES list. It fails to deliver a proper value every now and then, and returns an exact zero only for several cycles!

I have used this piece of hardware many times before on different systems, and it has never failed. I then added a Berry-programmed driver to the code, and this performed correctly at the times the native driver failed.

In dark-brown is the temperature (left scale, in °C) from the native driver, in light brown from the Berry driver. Both talk to the same I2C device, an LM75B. Berry has correct values, where the native gives 0 (zero).

Here is an example response; first is native driver, 2nd is Berry driver:
statusSNS: ... 'LM75AD': {'Temperature': 0.0}, 'LM75': {'Temp': 20.75}, ...

In my experience the LM75 is a very well behaved device; those zeros are strange!

[sfromis]

The native driver has a pretty simple logic to read the sensor, which looks like it can only produce a 0 if that matches what the sensor returned.

Tasmota/tasmota/tasmota_xsns_sensor/xsns_26_lm75ad.ino

Lines 70 to 80 in 677eaba

	float LM75ADGetTemp(void) {
	int16_t sign = 1;
	uint16_t t = I2cRead16(lm75ad_address, LM75_TEMP_REGISTER, lm75ad_bus);
	if (t & 0x8000) { // we are getting a negative temperature value
	t = (~t) +0x20;
	sign = -1;
	}
	t = t >> 5; // shift value into place (5 LSB not used)
	return ConvertTemp(sign * t * 0.125f);
	}

The ConvertTemp call is for handling unit C/F, but should not be able to invalidate the input value.

Is your Berry code to read the sensor doing something better?

[ullix]

My conclusion also rests on the 0 (zero). When the sensor produces an error, the returned value is a "missing value", but it is returned as a 0. As example I list some values: In my setup I have a single LM75B chip (at default address 0x48) and I am first calling it by the "native" driver LM75AD, immediately followed by call from my Berry driver BER_LM75B, then repeated in a 1 sec cycle. Here is the outcome over 6 sec:

2026-01-02 22:04:03 getValWFS: #3 LM75AD Temp: 0.0
2026-01-02 22:04:03 getValWFS: #4 BER_LM75B Temp is None

2026-01-02 22:04:04 getValWFS: #3 LM75AD Temp: 0.0
2026-01-02 22:04:04 getValWFS: #4 BER_LM75B Temp is None

2026-01-02 22:04:05 getValWFS: #3 LM75AD Temp: 0.0
2026-01-02 22:04:05 getValWFS: #4 BER_LM75B Temp is None

2026-01-02 22:04:06 getValWFS: #3 LM75AD Temp: 0.0
2026-01-02 22:04:06 getValWFS: #4 BER_LM75B Temp is None

2026-01-02 22:04:07 getValWFS: #3 LM75AD Temp: 0.0
2026-01-02 22:04:07 getValWFS: #4 BER_LM75B Temp is None

2026-01-02 22:04:08 getValWFS: #3 LM75AD Temp: 0.0
2026-01-02 22:04:08 getValWFS: #4 BER_LM75B Temp is None

The LM75B chip fails for 6 sec in a row (based on Berry result 'Temp is None'). During the same time period, the native driver produces '0.0' as float. I conclude that the native driver produces a valid zero when the sensor fails, actually giving invalid data! Instead it should produce a missing value!

So every time the sensor fails - and this seems to happen surprisingly often - a false and highly misleading value is produced!

It is a big No-No, returning as missing-value a value which is well within the range of correct values! Remember, according to the LM75B datasheet https://www.ti.com/product/de-de/LM75B its Temp range is -55...+125 °C.

The proper way of handling such a situation would be to call it a 'nan' (Not a Number) value. In Berry code easily done as math.nan. But if this is not possible, a value of '-99' or 'null' could be a workaround solution.

My Berry code is simple, but it does produce 'nan' values. One catch, though: the Python3 json functions do not recognize 'nan', but they do recognize 'null' (and make a Python 'None' out of it). So I workaround by changing 'nan' to 'null' before I json_append :-(

class BER_LM75B
    var wire          # if wire == nil then the module is not initialized
    var addr
    var dataReg
    var name

    var Temp

def init()
    import math

    self.name = classname(self)
    self.close()

    self.addr = 0x48
    self.dataReg = 0x00
    self.Temp = math.nan

    self.wire = tasmota.wire_scan(self.addr)
    if self.wire
        var v = self.wire.read(self.addr, self.dataReg, 2)
        print(f"I2C: Device 0x{self.addr:2X} detected on bus {self.wire.bus}")
    end
    tasmota.add_driver(global.BER_LM75B_instance := self)
end

def close()
    tasmota.remove_driver(global.BER_LM75B_instance)
    tasmota.remove_cmd(self.name)
end

def readTemp()
    import math
    if !self.wire return nil end  # exit if not initialized

    var Tbin  = 0
    self.Temp = math.nan
    var b  = self.wire.read_bytes(self.addr, self.dataReg, 2)
    if size(b) == 2
        Tbin = (b[0] * 256 + b[1]) >> 5
        if Tbin == 2047                         # 2047 dec = 111 1111 1111 bin
            self.Temp = math.nan
            return
        end
        if Tbin & 0x400                         # 0x400 == 0b0100 0000 0000  negative value
            Tbin = Tbin - 0x800                 # 0x800 == 0b1000 0000 0000
        end
        self.Temp = Tbin * 0.125
    end
end

# trigger a read every second
def every_second()
    if !self.wire return nil end  # exit if not initialized

    self.readTemp()
end

# display sensor value in the web UI
def web_sensor()
    if !self.wire return nil end  # exit if not initialized

    import string
    var msg = string.format("{s}BER_LM75B Temperature{m}%0.2f °C{e}", self.Temp)
    tasmota.web_send_decimal(msg)
end

# add sensor value
def json_append()
    import string
    import math

    if !self.wire return nil end  # exit if not initialized

    var stemp = "null"
    if !math.isnan(self.Temp) stemp = f"{self.Temp:0.2f}" end
    var msg = string.format(',"BER_LM75B":{"Temperature":%s}', stemp)
    tasmota.response_append(msg)
end

end
temp = BER_LM75B()

A minor other quibble I have: these sensors come as 'LM75', 'LM75A', and 'LM75B'. The 'D' in LM75AD does not belong there, because it is just a package variant, which has nothing to do with the code. The 'LM75' has 9 Bit resolution, the A and have 11 bit. The B is the latest variant (with some better stability specs). Code-wise, A and B are the same.

[arendst]

Try latest dev branch with this change 971ddc7

[ullix]

I'd be happy to test. Where do I find which bin file for download?

[sfromis]

Just do an upgrade to a development binary, like from the usual https://ota.tasmota.com/tasmota32/ (depending on chip variant and if you selected a special binary.

[ullix]

my current Web-UI says: [Tasmota 15.2.0 (release-tasmota32) by Theo Arends](https://github.com/arendst/Tasmota) which means - I believe - that I am not using a development version, and thus have to install this [tasmota32.factory.bin](https://ota.tasmota.com/tasmota32/tasmota32.factory.bin) 2968k 20260104 00:19 by using esptool.py?

[sfromis]

No, just regular OTA upgrade via the URL which in this case is http://ota.tasmota.com/tasmota32/tasmota32.bin
(Assuming that this matches your chip variant)

[arendst]

I just received my batch of LM75B's and the first ones seem to work just fine. Setting WebRefresh 1000 every second a GUI update shows a valid temperature.

I suppose you did solder the correct pads for a fixed I2C address as documented in the datasheet:

Because the input pins, SCL, SDA and A2 to A0, are not internally biased, it is important that they should not be left floating in any application.

[ullix]

Interesting requirement! I checked my LM75B datasheets from 3 different companies, and none mentions the need for soldering the pads. In which one did you find it?

No, my pads weren't soldered.

[sfromis]

Quick Google search found the text on https://www.nxp.com/docs/en/data-sheet/LM75B.pdf under 7.3 Slave address.

Strictly speaking, that is about the chip as such, and does not say what your breakout board may or may not be doing to satisfy that requirement. Hence, the datasheet does not talk about soldering pads.

[arendst]

It's in here https://www.nxp.com/docs/en/data-sheet/LM75B.pdf (cross posted)

Looking at my breakout board it's clear those address pins are floating. There is no external pull-up resistors other than the I2C interface and SO open drain output. The latter shouldn't be there.

[arendst]

And if all is well you could end up with this:

[ullix]

;-)

I measured the resistance of the address pads on my breakout board against VCC and GND, and in all cases R was inf! So, they were floating. Strange, because breakout board manufacturers usually make thin connections, which can be scratched off, if needed. Even stranger that only NXP is mentioning floating pins, not TI, not Maxim, not Nat.Sem.

I have now soldered the pads, installed Tasmota 15.2.0.2 (a9e75e7-tasmota32) on a ESP32-D0WD-V3 v3.0, and ran my code overnight. In some 46k readings not a single fail! So, I cannot tell whether the new missing value works, because the LM75B on Tasmota is too reliable :-/

[arendst]

Well it seems to work as expected when I remove one sensor I receive this:

{"Time":"2026-01-05T10:35:13","LM75AD-48-1":{"Temperature":22.375},"LM75AD-49-1":{"Temperature":22.250},"LM75AD-4A-1":{"Temperature":null},"LM75AD-4B-1":{"Temperature":22.000},"LM75AD-4C-1":{"Temperature":22.250},"LM75AD-4D-1":{"Temperature":22.375},"LM75AD-4E-2":{"Temperature":22.250},"LM75AD-4F-2":{"Temperature":22.375},"TempUnit":"C"}

Notice the null value for sensor LM75AD-4A-1.

[ullix]

Wonderful! When I remove my LM75B I get a 'null' and my Python is happy!