HX711 absolute weight computation

[ThomDietrich]

Hey friends,
Related to https://github.com/arendst/Tasmota/blob/development/tasmota/xsns_34_hx711.ino

TL;DR; Would it be possible to change or extend the code for the HX711 sensor, so raw value conversion and reporting of absolute kg measurements is directly handled by Tasmota? If no objections, I will try to contribute a PR.

---

The HX711 weight sensor is supported prominently with two outputs:

• an absolute raw weight value across reboots
• a kg weight value with implicit auto-tare functionality.

However there is no output for:

• an absolute kg weight value across reboots

The last one seems like the one most users actually need.
I would like to understand whether there is a specific reason for this divide. I am not sure which user actually needs an auto-tare sensor and the PR for the raw value (#7171 by @tobox) even mentions that "to do calibration/tare in upper layers." I can confirm that this indeed works well. I have a simple conversion (y = ax +b) doing this in Home Assistant, however would prefer my DIY scale to do this directly. ESPhome supports the conversion directly.

[ThomDietrich]

As no one disagrees with the idea, I assume that no one is against such a change. I will work on the PR in the coming days.

TODO:
[ ] Do not change existing logic (compatibility reasons)
[ ] Add configuration options for a and b to Sensor34
[ ] IF a and b are set, present the absolute instead of auto-tare'ed weight as the state of the sensor

[arendst]

No objections.

[boozeman]

Hi,

When you make PR, do you have possibility to test it with ESP32 too. I think that current HX711 code has some weird shenanigans on going for over 10kg weights.

[ThomDietrich]

Not aware but can test. Feel free to link issue and/or describe in more details.

[boozeman]

Hi,

I can reproduce following situation with 4 different ESP-32 devices and couple of SCK and DAT pin combinations. The scale is normal Wheat Stone Bridge with 3 wire cheap 4 x 50kg sensors. Also tested with 4 wire 200kg single Disc Type (internal wheat stone bridge) sensor with the same results.

Calibration went fine and scale is accurate. I use different reference weights 50g to 3kg when calibrating and testing.

Here is the problem:

Empty scale WeightRaw is 751999 and example 3.775kg of junk WeightRaw is 755738, so it grows until it get about 10.5Kg
When weight goes over 10.5kg (I hop to the scale or pile more stuff on the scale) the WeightRaw drops about 1/10 of empty scale value (~60000) and the value shows 0.000kg

Meanwhile the same Wheat Stone Bridge scale with the same HX711 chip works just fine in ESP8266 flashed by Tasmota.

[ThomDietrich]

Interesting, I happen to remember to have had similar issues a while back but didn't investigate further, let alone raise a ticket... Shame on me.

[arendst]

I cannot reproduce different values for esp8266 and esp32. As your 0kg raw value is way too high any additional weight will likely overflow the 12-bit HX511 register resulting in your experience.

Tasmota's default HX511 gain is set to 128. Reducing it to 64 might bring your raw values within the 12-bit register.

Edit file xsns_34_hx711.ino from line 111 into:

  for (unsigned int i = 0; i < HX_GAIN_64; i++) {
    digitalWrite(Hx.pin_sck, HIGH);
    digitalWrite(Hx.pin_sck, LOW);
  }

Were the raw values for the esp8266 and esp32 about the same?

[arendst]

That looks like a different float implementation between esp8266 and esp32. I see the driver also makes heavy use of long instead of int or uint32_t.

I will investigate.

[ThomDietrich]

@arendst I wonder how far we would want to take a redesign. The calibration and auto-tare functionality looks overall a bit convoluted.

[arendst]

I don't mind a total redesign BUT keep the current functionality and add changing functionality using an #IFDEF.

For now I will change all longs by either int or uint32_t as needed.

[ThomDietrich]

As you are currently working on the code: I'm still willing to implement this feature but I must say that my C skills are a bit rusty and I won't get to it this week. So if you want to give it a stab, I won't complain

[boozeman]

Hi,

Thanks for the help so far. I knew it that there's some difference that explains my high WeightRaw value on ESP32 but not on 8266.

Cheers

[arendst]

Sorry to say but I see no difference between the esp8266 and the esp32. If WeightRaw is that different there must be a change in the bridge connection to the HX711 hardware.

[boozeman]

Yep, this is weird.

Same scale setup 4 x 50kg 3-wire connected as Wheatstone bridge (White to White, Black to Black and Red ones are E+,E-,A- and A+ Red-Black-White-Green), tested 3 different HX711 chips too.

There's one results.

ESP32 pin 19 as DAT and pin 23 as SCK
{"Time":"2022-01-11T20:09:40","HX711":{"Weight":0.000,"WeightRaw":689318},"ESP32":{"Temperature":43.9},"TempUnit":"C"}

ESP8266 pin 5 as DAT and pin 4 as SCK
{"Time":"2022-01-11T19:17:35","HX711":{"Weight":0.000,"WeightRaw":-11140}}

The results are the same with one Sparkfun Disktype 4 wire 200kg scale too. ESP32 get too high weight raw value. When compiling some example sketches using Olav Kallhovd HX711 library, there's no this kind of problem.

I will check all again and scratch my bald head a little more. Found rather old ESP32 issue, clock speed too fast #75 Seems like ESP32 WeightRaw is high values there too. Never mind for that.

[dingausmwald]

Any news on this? I just wrote my expirience with esp32 and hx711 here. Maybe it can help

[ThomDietrich]

Not finished yet but I intent to create a Pull Request within next four weeks! I will work on the discussed feature primarily, but might look into your issue as well... can't promise anything

[dingausmwald]

Did some more testing after my vacuum robot has torn the wires ^^
The weight cells work as expected, when calibrating without weight plate the values scale properly, additionally it was indeed a fail in my design (not enough space for the weight cells to bend). Just the calibration time is a bit short, so i had to be very careful with the bump of my calibration weight. Maybe this could be adjusted to a larger time period. Will do some more testing with Sensor34 3 as this didn't do anything for me the last tests.

[ThomDietrich]

I don't do any calibration but fix the few parameters to default values. This way you get deterministic raw weight values which can then be transformed into calibrated weights -> the topic of this discussion.

Are you saying your issues are indeed not related to the code? Nothing to be improved regarding ESP32?

[boozeman]

I have those huge weightraw readings on ESP32 with single Sparkfun 200kg cylinderl type weight sensor too (4 wires, full wheat stone bridge) tested 3 different HX711 modules. (2 green ones and one Sparkfun version). Tasmota with 8266 (Nodemcu v1) works as intented.

[dingausmwald]

I get some fail readings, huge spikes up and little spikes down. It seems the writings to the sck pin needs a delay like olkal did in his HX711_ADC
https://github.com/olkal/HX711_ADC

Also noticed by Andreas Spiess (the guy with the Swiss accent) at 6:20 minute mark. https://youtu.be/iywsJB-T-mU

This seems to be a needed adjustment to the Esp32 to me.

The calibration time thing mentioned earlier is indeed not esp32 related, rather an improvement to the whole code

[arendst]

Tasmota is using the shiftIn function from Arduino. Comparing bith functions between ESP8266 and ESP32 reveals some remarkable differences.

I'll implement the ESP8266 shiftIn function in the Tasmota HX driver and add a delay for the ESP32.

Hold on.

[ThomDietrich]

Thanks for checking @arendst I did also invest a few minutes last night to build the new feature as discussed. I am in the process of testing and will provide a PR soon after. I still need some help with e.g. reserving some space in TSettings...

[arendst]

How much space do you need? What are the variable sizes (uint8_t, uint16_t or uint32_t)?

[ThomDietrich]

I am not entirely sure to be honest. I would hope for your guidance on this.
I've just created a Pull Request and described my problem there:
#15292

[arendst]

Just released the updated driver using the ESP8266 shiftIn function integrated in the HX711 driver. It also adds 1 miliseconds delay for the ESP32 between digitalWrites.

Pls give it a try and report back.

[arendst]

2 milliseconds still fails too:

Started testing with interrupts disabled during ShiftIns ...

[arendst]

Interrupts disabled didn't solve the issue either.

Latest commit saves 10 samples every second. Then removes the two lows and two highs and presents the average of the other six. Let's see what that brings.

Also solved a regression from v10.0.0.3 where an ESP32 OTA upload failed to save the settings before the reboot resulting amongs others in failing to restore last weight.

[dingausmwald]

Mainly from the video I posted I found out the shiftin command reads 8 bits in a row and those can't be delayed. The HX711 needs 2ms per signal, but the Esp32 is faster than this.

Your latest approach is the same from olkal I guess. Maybe the median works too.

I also found an experimental lib for a delayed shiftin. Have a look
https://github.com/RobTillaart/ShiftInSlow

[arendst]

Latest commit is now stable. No more spikes observed since activation at around 16:00

[boozeman]

I will setup my scale and do the tests. I will inform later today.

[ThomDietrich]

Hey all,
please check the PR and let me know whether your specifc setups would work within the limits of configuration parameters a and b: #15292

[arendst]

PR has been implemented today. Let them play and report any issues.

[boozeman]

Hi,

No spikes for my setup during several hours testing. One more "problem" with sensor34 and ESP32. It auto tares the weight to 0.000 if resetting the device. This is bad if measuring constant weights like water tank. The weight decreases slowly by time when using the water and autotare at reset is no good. This was working earlier with ESP32.

Is there option to change autotare on and off?

sensor34 7 saves the weight to be used as start weight on restart but if there's an electricity blackout?

[tobox]

You are describing the same problem I had a long time ago...

#7171

[ThomDietrich]

The discussion in this thread derailed to the ESP32 issues. But just to remind you, the original thread purpose was "absolute weight computation", which is what I did solve in #15292 and which was merged yesterday. Please also pay attention to the discussion Arendst and I have in comments regarding whether there is another way to solve this, e.g. by disabling auto-tare.

Anyhow, with sensor34 10 and sensor34 11 this problem has a solution or workaround, however you wanna see it.

[arendst]

It auto tares the weight to 0.000 if resetting the device.

Pls define "resetting". With latest version (v11.0.0.6) when I add a load to the scale of say 1kg and I execute a restart command it returns to 1kg. If indeed I press the reset button (or power cycle) it returns to the last saved state. The term "saved state" is crucial here as this by default only occurs on a restart command.

As a workaround you could use a rule which executes command Sensor34 7 on regular basis what you see fit and feel comfortable with wearing out the flash. Maybe doing it every 10 minutes or on every set amount of weight change results in a usable interval.

[dexterbot80]

Hello friends,
After a day of trouble I solved the problem :)
I compiled tasmota for ESP32-POE and in my_user_config.h
I set #define HX711_CAL_PRECISION 5 - default value was 1
This means that I have an almost exact value with that of the reference weight for calibration.

Now if I put 2000 grams on the scale after calibration, I measure between 1999 and 2001 grams, which is enough for me :)

I hope it helps someone :)
Thanks guys for the great work you are doing here
Regards

[sfromis]

To be a bit hairsplitting, while the precision (number of digits) got better, that does in no way mean exact (accurate values), as the hardware of those load cells can't be trusted to be that fine tuned. Still good enough for most purposes, including having a belief that it is exact 😜

[sfromis]

@arendst Seeing the above, and doing a test, I'm wondering if the default of #define HX711_CAL_PRECISION 1 is too coarse for expectations of precision, like when doing a test calibration with 4000 G, and then seeing the weight as 4080 G a few seconds later.

23:07:20.210 CMD: sensor34 2 4000
23:07:20.223 MQT: xxxxxxxx/stat/SENSOR34 = {"Sensor34":"Load reference weight"}
23:07:28.164 MQT: xxxxxxxx/stat/SENSOR34 = {"Sensor34":"Calibrated"}
23:07:39.140 CMD: status 10
23:07:39.154 MQT: xxxxxxxx/stat/STATUS10 = {"StatusSNS":{"Time":"2024-09-07T23:07:39.147+02:00","HX711":{"Weight":4.080,"WeightRaw":22825,"AbsRaw":502161}}}

A difference of 2% seems outside of what users would reasonable expect from calibration. Of course, the hardware may not really be that accurate, but still the calibration should be reflected as a result, with deviations "only" due to what might be caused by changes in temperature or whatever.

What are the downsides of a more fine-grained HX711_CAL_PRECISION default?

[arendst]

I'll have a look today.

UPDATE1: Doing a test on my ESP8266 with a single 5Kg loadcell and a 1.554 kg load I see no deviation:

14:09:15.664-026 CMD: sensor34 2 1554
14:09:15.665-026 SRC: Serial
14:09:15.668-026 CMD: Grp 0, Cmd 'SENSOR', Idx 34, Len 6, Pld 2, Data '2 1554'
14:09:15.676-023 MQT: stat/hema1/RESULT = {"Sensor34":"Load reference weight"}
14:09:21.712-023 MQT: stat/hema1/RESULT = {"Sensor34":"Calibrated"}
14:09:22.381-026 CFG: Saved to flash at F9, Count 292, Bytes 4096
14:09:26.678-023 MQT: tele/hema1/SENSOR = {"Time":"2024-09-08T14:09:26","HX711":{"Weight":1.555,"WeightRaw":1836,"AbsRaw":822581}}
14:09:32.439-026 CMD: status 10
14:09:32.441-026 SRC: Serial
14:09:32.444-026 CMD: Grp 0, Cmd 'STATUS', Idx 1, Len 2, Pld 10, Data '10'
14:09:32.452-023 MQT: stat/hema1/STATUS10 = {"StatusSNS":{"Time":"2024-09-08T14:09:32","HX711":{"Weight":1.554,"WeightRaw":1836,"AbsRaw":822549}}}

A larger loadcell or multiple loadcells likely will have a larger toleration resulting in a bigger deviation.
Let me chk what a single 20Kg loadcell does....

UPDATE2: Doing the same test on my ESP8266 with a single 20Kg loadcell and a 1.554 kg load I do see a deviation:

14:21:52.248 CMD: sensor34 2 1554
14:21:52.250 SRC: Serial
14:21:52.251 CMD: Grp 0, Cmd 'SENSOR', Idx 34, Len 6, Pld 2, Data '2 1554'
14:21:52.257 MQT: stat/scale1/RESULT = {"Sensor34":"Load reference weight"}
14:21:58.215 MQT: stat/scale1/RESULT = {"Sensor34":"Calibrated"}
14:21:58.277 CFG: Saved to flash at F7, Count 131, Bytes 4096
14:22:03.240 MQT: tele/scale1/SENSOR = {"Time":"2024-09-08T14:22:03","HX711":{"Weight":1.564,"Count":156,"WeightRaw":2834,"AbsRaw":334425}}
14:22:08.423 CMD: status 10
14:22:08.425 SRC: Serial
14:22:08.426 CMD: Grp 0, Cmd 'STATUS', Idx 1, Len 2, Pld 10, Data '10'
14:22:08.465 MQT: stat/scale1/STATUS10 = {"StatusSNS":{"Time":"2024-09-08T14:22:08","SHT3X":{"Temperature":26.7,"Humidity":60.9,"DewPoint":18.5},"HX711":{"Weight":1.564,"Count":156,"WeightRaw":2834,"AbsRaw":334449},"TempUnit":"C"}}

Interesting.
Let me play with HX711_CAL_PRECISION as @dexterbot80 did and see how to come up with a formula...

UPDATE3: Indeed, setting to HX711_CAL_PRECISION to 4 fixes the deviation:

14:37:39.470 CMD: sensor34 2 1554
14:37:39.471 SRC: Serial
14:37:39.473 CMD: Grp 0, Cmd 'SENSOR', Idx 34, Len 6, Pld 2, Data '2 1554'
14:37:39.477 MQT: stat/scale1/RESULT = {"Sensor34":"Load reference weight"}
14:37:45.451 MQT: stat/scale1/RESULT = {"Sensor34":"Calibrated"}
14:37:46.316 CFG: Saved to flash at F9, Count 138, Bytes 4096
14:37:50.418 MQT: tele/scale1/SENSOR = {"Time":"2024-09-08T14:37:50","HX711":{"Weight":1.554,"Count":155,"WeightRaw":2807,"AbsRaw":1333608}}
14:38:09.034 CMD: status 10
14:38:09.035 SRC: Serial
14:38:09.037 CMD: Grp 0, Cmd 'STATUS', Idx 1, Len 2, Pld 10, Data '10'
14:38:09.044 MQT: stat/scale1/STATUS10 = {"StatusSNS":{"Time":"2024-09-08T14:38:09","SHT3X":{"Temperature":30.4,"Humidity":51.3,"DewPoint":19.2,"HeatIndex":31.9},"HX711":{"Weight":1.555,"Count":155,"WeightRaw":2807,"AbsRaw":1333708},"TempUnit":"C"}}

Problem is, setting it fixed to 4 will change current calibrated scales. Working on a solution...

[arendst]

Solution is in latest dev branch.

Adding an optional option to command
Sensor34 2 <weight in gram> <precision> - Set reference weight with larger precision (1..10) and start calibration

The precision option overrules define HX711_CAL_PRECISION

Values larger then 10 are likely overflowing uint32_t AbsRaw and are not supported.

[lalo-uy]

El El sáb, 7 set. 2024 a la(s) 07:01, dexterbot80 ***@***.***> escribió:

It is more stable only after 30 minutes, I don't understand why even if I have the same weight of 2000 grams on the scale I measure values ​​between 1900 and 1913 grams.

That is a well know problem of the load cells. I try to use them to monitor a tank that change 10% of is weight in a week and was imposible, but with the best quality ones.