Closed thatso closed 6 years ago
Generally, it is not reading the sensor that is the problem. For laser particle sensors, you generally need to put them to sleep and then wake them up and you need to make sure you give them to settle. This would require an additional pin hook up to control sleep mode. It might be done differently on other devices, so there probably isn't a one size fits all solution to this.
For the CO2 sensors, most/all of them require a significant warm up time (at least a min). Only after it has stabilized is the reading valid and even then most of them are specified to run continuously to maintain calibration.
For the BME280 the code has already been modified to put it into the non-self heating mode.
The PM2.5 laser particle sensors are probably the ones most likely to benefit from implementation of sleep mode.
By the way $20 is considered cheap for a CO2 or PM2.5 sensor. Even a few years ago, $100 was considered dirt cheap for these, with real ones costing multiple hundreds of dollars.
Yes, most sensors not only have a typical response time which renders too many readings within this time obsolete, but they can also have a warmup time and readings before that are invalid. i just did not want to go into too many details as my suggestion already contained a lot of text. ;-) Nevertheless, I'd appreciate some reasonable code changes mainly for the SDS011 when used for general air quality monitoring. According to the datasheet, it supports a discontinuous work mode. Glad to hear this was already done for the BME280 to keep readings stable. BTW: even if you consider 20 USD per sensor historically cheap, I'd still like to extend the lifetime from less than one single year of continuous usage to several years of timed interval usage.
The code is open source, so you are free to make any changes to it you feel are necessary/desirable. That is how the changes to the BME280 happened. Some people noticed that the sensor was reading high. Other people referenced some other repos that had made some changes for it. Since I was using one and I noticed the same thing, I looked at the changes in the other repo. I also read the data sheet very carefully. I then made a simple implementation of the data sheet recommended configuration. Theo took a look at it and implemented it in a more generic way (so it worked for all the BMx sensors) and then everyone benefited.
I have a PM 2.5 laser sensor somewhere on my bench in the basement, but it is very low on my priority list, so I probably won't get to it for months. When I do I will consider how to put the sensor in sleep mode for most of the time.
I already said: I am no coder. However, I've discovered meanwhile that ESPEasy apparently has all of the functionality that I was looking for. I get it that Tasmota is mainly meant for Itead devices. As nobody here is interested in prolonging the lifetime of sensors, I'm closing this request. Lesson learned: carefully choose the right tool for the job. This time, Tasmota was the wrong choice.
I think your request is good, but you are correct that choosing the right tool is always a good idea. Each tool has different trade-offs. Implementing something like you asked in a general way is not simple. It would also complicate the use of sensors. But, in the case of sensors that have very short lives that can be extended by powering down it does make sense to have that capability.
https://github.com/arendst/Sonoff-Tasmota/pull/2841 Looks like it might do what you want.
While some sensors like HTU21D are dirt cheap and can be sourced on Aliexpress for less than 1 USD complete with breakout board, others like MH-Z19B or SDS011 are higher priced in comparison like 20 USD each. Worse, they have a rather limited service life: the datasheet of the SDS011 states 8000 hours which means less than one year of continuous use. I've hooked up some sensors to a Wemos D1 (planning to use MQTT) and the readings on the web interface are constantly updating in real time. This is nice to check basic functionality, but I'd strongly prefer way less readouts to extend the sensors' usable lifetime. I know that I can set TelePeriod to i. e. send one reading only every 5 minutes. However, I believe that this does not change the fact that the sensors are still being read continuously meanwhile.
Could you include some parameters in user_config.h to set the reading intervals of different sensors? Or better: could you optionally change the sensor read intervals to be identical to the TelePeriod time?
Non-stop reading sensor values does not only limit the service life, but can also have negative effects on the accuracy. Some examples: