-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
BH1750 sensor resolution options #8016
Comments
The current implementation does continuous reads at H-Resolution Mode (0x10). In the datasheet I cannot see anything with regards to power down advantage over continuous reads. The MTreg is used if the sensor is behind a glass panel and the results can also be calculated by the user. Every suggested features will cost code space so as a trade-off I suggest to add the L-Resolution mode as an option to satisfy your use-case. |
Add command ``Sensor10 0/1/2`` to control BH1750 resolution - 0 = High (default), 1 = High2, 2 = Low (#8016)
Fair enough. Thank you. |
Tested using 8.2.0.3. Switching resolution modes works well. However, the problem is that the max value is still being capped. Wouldn't it be possible to implement MTreg control through the same mechanism The sensors are actually placed in transparent enclosures to protect them from environmental impacts like rain, dust. MTreg is especially there to compensate this, as the enclosure behaves pretty much like a glass panel - as described in the docs. MTreg is an integer between 32 and 254, default value is 69, I'd like to reduce that to around 40. |
It will always be capped to 54612 as that's the result of I had expected the low resolution mode to have a better result as it is supposed to step with 4lx but in the documentation it still seems to return the same value as the High resolution mode so I see no real need for it. I will investigate the impact of adding MTreg. |
Add command ``Sensor10 31..254`` to control BH1750 measurement time which defaults to 69 (#8016)
Have another try |
Oh, by the way, the MT value is NOT persistent. You will have to use a rule to set it's value other than 69 at restart. |
Awesome. The value changes according to the MTreg constant. I will do further testing tomorrow, during bright sunlight, and report back. |
At which start moment do you recommend to set the he valuse? Should it be Something like this should be fine?
|
Yes. System#Boot should be OK |
Setting MTreg to a lower value generates a leaner measurement curve. Capping still occurs but much later. Additionally, setting the value to 34 or below, halves the measured value. Anyway, the lower the MTreg value, the more headroom the measurement has. |
Have you looked for this feature in other issues and in the docs?
Yes
Is your feature request related to a problem? Please describe.
Please add for the BH1750 driver options to change operation mode and resolution. This is a quite clever sensor, it can operate in Continuous mode and One-time mode. One-time mode saves power because the sensor only makes measurements when polled, after data has been read it powers down. In both modes three precisions are available: Low Resolution Mode, High Resolution Mode, and High Resolution Mode 2.
I don't know what modes is the BH1750 at the moment when used with Tasmota, all I see is that when the sensor is put to direct sunlight outdoors, the returned value is capped to 54612. There is an MTreg parameter which could allow fine-tuning of the measurement time window so that a more precise value would be returned depedning on how the user wants to use the sensor.
Describe the solution you'd like
Use SetOption in Tasmota to change between resolution modes. Perhaps set default operation to OneTime mode if not using already that. Use another SetOption to adjust the MTreg parameter to fine-tune the measurement curve.
Describe alternatives you've considered
None.
Additional context
Some more info about it, and datasheet: https://github.com/claws/BH1750/blob/master/README.md
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: