Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix si7021 temperature/humidity sensor reading #737

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

WizBangCrash
Copy link

Raw reading modified according to the Silicon Labs sample code for the Si7021 sensor.

I've had issues trying to use the Si7021 sensor with Sonoff TH10 and TH16 devices, so looked into why it was always returning TEMP = 0, HUM = 2. The raw vales were not being interpreted as per the data sheet and Linux sample code that Silabs provide.

Raw reading modified according to the Silicon Labs sample code for the Si7021 sensor
@WizBangCrash
Copy link
Author

Apologies. Hold off reviewing this pull request until I update it.
I realise I haven't catered for negative temperatures (its cold in the UK today) :-)
I'll update my commit later today.

Fixed conversion of the Si7021 data and fully tested over large temperature / humidity range.
Also tested the AM2301 sensor (often used as alternative to Si7021)
@WizBangCrash
Copy link
Author

Updates committed and and tested on Sonoff TH16 with DHT22, Si7021 & AM2301 sensors.

@RavenSystem
Copy link

@WizBangCrash Did you test it with DHT11 too?

@WizBangCrash
Copy link
Author

I don't have a DHT11 sensor unfortunately, so I couldn't test that option.

@WizBangCrash
Copy link
Author

@RavenSystem One other thing I have noticed during testing is that the new Sonoff branded AM2301 sensors behave like the Si7021, but the older ASAIR branded AM2301 sensors behave like the DHT22. Both sensors are in identical plastics accept for the information printed on the rear.
This can get quite confusing, especially as the software uses the sensor name as the option. It might be wise to refactor this at some point in the future and have generic 'types' e.g. SENSOR_TYPE_A, SENSOR_TYPE_B and then list the sensors that can be used with each 'type'. Rather than DHT_TYPE_DHT22, DHT_TYPE_SI7021

@RavenSystem
Copy link

Change sensor definitions is not a good idea because a lot of people uses this SDK, and everybody that uses DHT driver will must change code.

I think I have a DHT11. I will test it asap.

@WizBangCrash
Copy link
Author

Change sensor definitions is not a good idea because a lot of people uses this SDK, and everybody that uses DHT driver will must change code.

I'm sure I could make it backwards compatible. I'm just forward thinking as more sensors come to the market. I also looked at automatically switching between modes as I had in initial fix that tried the AM2301 using the old way and when it failed Phase B it would retry Phase A with a longer period. This worked, but I wasn't sure whether to submit it as a fix or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants