(Display Widget's output of DHT22 data ) Stops working after a few days

@marvin7 Even a DHT22 can be fairly reliable… I have one sittng outside for my solar monitoring project (5 minute readings)

Here is my last month of steady readings from it… Winter here (AKA rain, with spots of showers and occasional downpours :cloud_with_rain:) so the Humidity is actually accurate :stuck_out_tongue:

image

Your story about the lighting is a good one, and would be the kind of thing to look for if something weird happens every 24 hours or so. In my case, it is about 4.5 days, which doesn’t fit any periodic occurences I can think of.

I also tried computing 4.5 days = 388800 seconds, and as I am triggering a sample every 10 seconds, that is 38880 timer events. That’s close to overflow of a 16 bit signed integer (32768), but the timer would have to be about 12% out if it is really 32768 events rather than 38880. I’d hope the timer is not that far off - although I suppose it’s not impossible - my 4.5 days is also only approximate.

Marvin, I take your point about sending something when the DHT fails to return an invalid value, to prove that it is not simply the sensor going wrong. Perhaps I should do this to convince the Blynk guys.

Better still, I have acquired a BME280 sensor, so will update my code to use this in the next few days.

1 Like

Aaach… Out of six, I’m left with ONE - still reliable… The rest is able to correctly show just the temperature.The humidity is somewhere, where the sun not shines… And those “hangs”, where they are unable to send ANY readable data (where isnan is needed)

And that is “correct” way to go!

Hmm, the DHT library has calls to delay of 270 ms in it. So there’s almost 3% out of my 12% error in my “once every 10 s” timings right away.

The timer is based on Simple timer, which is based on the millis count of the processor, which is part of the Arduino core programming… still looking for the Blynk bug connection here?

My solar monitor runs on a Wemos D1 Mini with a DHT22 every 5 minutes, an INA219 current/voltage sensor running every second and simultaneously controlling a repeating sequence of RGB LED strip lighting 24/7.

So far it has been running without reset for 5341 minutes… eventually when it does reset (because, well, in a real world, that happens), it is back up and running in a few seconds and the only way I know there was an issue is the counter resets.

Now I still have my suspicions about the Blynk Library 0.5.0, but aside from the quantitative data I have already presented in another topic, it is still not clear there is any real bug… I somehow survive :slight_smile:

Well… But it is called now “Blynk.timer”… It’s just like with cars failures… Who cares, who is the manufacturer of specific part… It is in a car made by “A”, or “B”, so whose fault is that?? Or am I wrong…?

Yes, I can live with artificially resetting my device with ESP.reset(); after counting at 10s intervals to 66024 = 8640 = 1 day. So far so good, after a few days, but we will see what happens in a few days time.

Well, if while they integrated the timer into the library, the developers made a mistake that caused issues… then yes, bug :slight_smile: (BTW, it has been stable for many months… so no issue there).

But my point was that all this calculation that might indicate overflows has nothing to do with Blynk itself.

And if it did… then how do I manage to keep my much busier project running so long?

This whole argument comes down to who is responsible for “fixing” issues… the user with the issue, code, environment, hands on abilities, etc… or the developers receiving the supposed, unclarified “bug… Bug… BUG!!!” alerts every day? :stuck_out_tongue:

I don’t even do that… I just have a simple sync after Blynk automatically reconnects if a disconnect or reboot issue happens.

I got Your point very clearly, and not argue with that. Especially, when all my devices (past and current) had not met this kind of issue…
But then again… It’s Blynk.timer… :stuck_out_tongue:

one thing came into my mind: the (in)famous “Code provided as is” in almost (?) every licence…

I hear ya… but just becasue my gas cap has my vehicle manufacturer’s name on it, doesn’t mean I blame them for running out of gas.

Besides I was refuting all the calculations as a way of “proving” a Blynk bug through register overflows, something that is not the timers fault.

In the UK, “provided as is” is may not mean much. See for example:

But my device does not disconnect or reboot…

Just I get no data at the other end. The device is shown as still connected.

@ralphrmartin Listen… my whole and entire point here is that unless you have some clear, repeatable, provable, datum that shows that you have tracked an issue down… no one else is going to pursue it.

And even if you have all that, is it an issue that needs to be rectified right away or eventually down the road?

Badgering the developers with “I paid, you fix” isn’t going to go far with this extremely low cost (to us), open source system. :slight_smile:

And that is exactly the reason, why I urge You to check this specific part of code (and as a part of debug fill the data with some dummy values).
Or adopt the code to BMx280’s where I have not met such an issue (stops responding)

1 Like

II’m not so sure it’s the sensor. If a sensor is broken, the esp will not get any data from it, but still the device should send something to the blynk server as long as it is connected. If my ds18b20 sensors have power, but it’s something wrong with the signal, I think the temperature read is -127°C.

If it’s totally disconnected (not any power), the device will still be sending 0 to the Blynk server. To me this sounds like some part of the code on the device is not executed for some reason. Obviously some of the code is runniing because the device is connected, at least the Blynk.run(); is executed.

@blynkola, look for return in the if (isnan) condition check. Then you will see the light. It’s the ONE percent I’m leaving for other bugs, but 99 for sensor (or it’s library)

This thread makes for an interesting read!

When you buy Blynk energy it’s to allow you to add widgets to your mobile device. The code libraries that @ralphrmartin suspects may be at fault are open source, so the UK consumer rights legislation isn’t really relevant to that aspect of the Blynk offering.

The Blynk guys obviously want the best and most reliable product to be available to their users, so will fix bugs as quickly as possible whenever they’re identified. There are a few threads about my project stops working after x number of seconds/hours/days/week’s, but there doesn’t to be any commonality between them and there are also a large number of users who don’t have issues and who are also using the same basic functions within Blynk.
In these circumstances, it’s unreasonable to expect the Blynk developers to take this issue further without the error being replacement capable by others, or multiple users reporting the same issue.

In this particular case it seems that the DHT sensor is the weak point and hopefully changing to a more reliable sensor is a good starting point. Possibly changing the ESP module, or running the device while connected to a totally different Wi-Fi network would be the next steps if changing the sensor doesn’t fix the problem.

If the thread was a little less confrontational then ther would probably be more people chipping-in with ideas and potential solutions. I realise that it takes a while to test, waiting 4.5 days before you know if the issue has been resolved, so maybe getting a couple more ESP devices and running them with a variety of sensors and in different Wi-Fi environments simultaneously would be a good way to move forward?

Pete.

3 Likes