Adds support for SPL06_007 Temperature & Pressure I2C (+10k2 code)

[rai68]

Description:

Related issue (if applicable): fixes N/A

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.6
• The code change is tested and works with Tasmota core ESP32 V.3.0.0 - No hardware
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[s-hadinger]

+10K seems a lot for this sensor. Can you find ways to reduce it?

[rai68]

I can only get it down to roughly 10k for the library its self, the device has an odd amount of calibration values required, seems to be for accuracy and its speed at reading

[s-hadinger]

I think that the main problem is using double instead of float. This causes the linkage of the huge double libraries that we have avoided until now

[rai68]

Maybe im counting the size wrong? I was just adding up the size of the files in my file explorer, I don't see how changing a double to float could change the size that much, perhaps a different method is used?

[s-hadinger]

I tried on ESP8266, I only see 2.7KB increase.

However you should still move to float. Espressif chips don't have any hardware FPU, so all floating point operations are done in software. double operations library are significantly larger than float and generated code is also significantly larger.

See https://tasmota.github.io/docs/Sensor-API/#floats-not-doubles

We have been chasing down almost all double calculation to replace with float. I'm convinced that you can move to float without any impact.

For example: avoid k = 524288.0d; and prefer k = 524288.0f;

[s-hadinger]

I changed blindly all double to float and it went down to 2.5KB. I expect it to be acceptable then.

Can you please do those changes?

[arendst]

Thx. In order to merge please change chosen sensor index 126 to it's final destination 25

[sfromis]

Noticed an inconsistency in what feature flag bit is used. While decode-status.py has the expected addition of USE_SPL06_007 as the current last non-empty name in the table, support_features.ino looks off.

According to the position, the expected bit should be 0x00000020 (the 5th bit in the last block of bits), but the code is actually using 0x10000000 (skipping the expected bit). Also, 0x10000000 is indicated as free at the end of the feature bits. Should most probably be corrected to 0x00000020.