Reliability?
-
@ServiceXp
My PCBs are winging their way to you (sorry, got forgot to send them for a week or two). They may solve your problem. Let me know when you get them.
-
@ServiceXp
Could you try running a sketch which just uses the dallas temp lib eg: there is is an example called "Single" with the DallasTemperature lib. RUn it for 24hrs and see if it survives.Likewise... in your existing sketch...stop reading the temps ( but leave everything connected) and just send a value every say 30sec to Vera .... and leave for 24hrs or so...see if that survives.
Also have you tried a different PIN for the onewire sensor?
-
The section of code
void sendTemperatureToController(){ //Start time for Temperature readings TemperatureTimeing = millis (); // Fetch temperatures from Dallas sensors //sensors.requestTemperatures(); // Read temperatures and send them to controller for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) { // Fetch and round temperature to one decimal //float temperature = static_cast<float>(static_cast<int>((sensors.getTempFByIndex(i)) * 10.)) / 10.; //float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.; // Only send data if temperature has changed and no error //if (lastTemperature[i] != temperature && temperature != -127.00) { //// Send in the new temperature //gw.send(msgTEMP.setSensor(i).set(temperature,1)); //lastTemperature[i]=temperature; //} gw.send(msgTEMP.setSensor(i).set(777, 1)); } } -
Ok,
The sensor has has been running for ~24 hrs and has not locked up. So the problem is either in the code (which I doubt because I think others would be seeing this problem) or the actual DS18B20's. Maybe a bad run of them?I think I'm going to let it run a while longer like this, just to make sure.
-
Oh and the strangest thing.. those fails stopped.. So I still don't know what those where about..
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0 -
Oh and the strangest thing.. those fails stopped.. So I still don't know what those where about..
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0
send: 1-1-0-0 s=0,c=1,t=0,pt=7,l=5,st=ok:777.0@ServiceXp Your previous logging showed the failing messages being routed from node 2 via 1 to 0 (gateway).
This log shows messages from node 1 directly to 0 (gateway).
This is a different situation, so message routing seems to fail.
Any idea what could cause this?Furthermore, which DS18B20 library do you use?
-
@ServiceXp Your previous logging showed the failing messages being routed from node 2 via 1 to 0 (gateway).
This log shows messages from node 1 directly to 0 (gateway).
This is a different situation, so message routing seems to fail.
Any idea what could cause this?Furthermore, which DS18B20 library do you use?
-
I'm thinking maybe that's because this node is a relaying node?? Other than that I have no ideal.
-
Whatever comes with MySensors.
I did try using another Dallas library (the latest version) but there was a gazillion compile errors so I quickly replace it with existing... :-)
I just don't know enough yet, to work out all those compile errors. -
-
-
I'm thinking maybe that's because this node is a relaying node?? Other than that I have no ideal.
-
Whatever comes with MySensors.
I did try using another Dallas library (the latest version) but there was a gazillion compile errors so I quickly replace it with existing... :-)
I just don't know enough yet, to work out all those compile errors.@ServiceXp said:
- I'm thinking maybe that's because this node is a relaying node?? Other than that I have no ideal.
What do you pass for the 'repeaterMode' flag when calling 'begin' on the sensor object?
This determines whether the node behaves as a sensor or a repeater.
What does your setup look like exactly?How do you power the DS18B20?
Btw. I'll review the DS18B20 code shipped with MySensors. Maybe I can find what causes the hangup.
-
-
-
I'm thinking maybe that's because this node is a relaying node?? Other than that I have no ideal.
-
Whatever comes with MySensors.
I did try using another Dallas library (the latest version) but there was a gazillion compile errors so I quickly replace it with existing... :-)
I just don't know enough yet, to work out all those compile errors.@ServiceXp Seems that you're not alone when Arduino hangs up with DS18B20 connected, see http://tushev.org/articles/arduino/item/46-arduino-and-watchdog-timer.
This guy suffered from condensation causing a 'shortcut' between the sensor wires...IMO a library should never hang on communication errors, but return an error value after a timeout or so...
-
-
@ServiceXp said:
- I'm thinking maybe that's because this node is a relaying node?? Other than that I have no ideal.
What do you pass for the 'repeaterMode' flag when calling 'begin' on the sensor object?
This determines whether the node behaves as a sensor or a repeater.
What does your setup look like exactly?How do you power the DS18B20?
Btw. I'll review the DS18B20 code shipped with MySensors. Maybe I can find what causes the hangup.
@Yveaux said:> @ServiceXp said:
- I'm thinking maybe that's because this node is a relaying node?? Other than that I have no ideal.
What do you pass for the 'repeaterMode' flag when calling 'begin' on the sensor object?
This determines whether the node behaves as a sensor or a repeater.
What does your setup look like exactly?How do you power the DS18B20?
Btw. I'll review the DS18B20 code shipped with MySensors. Maybe I can find what causes the hangup.
-
Here is the link to one project that uses the DS18B20 sensor, The 2nd sketch is pretty much how it's running now (Locks up when there is a call to read the DS18B20, but doesn't when the code is commented out).
-
In all cases, the sensors VCC and GND are connected in common to the power source. Here is the pcb prototype of the EH40 project.

Thanks for the help!
-
@ServiceXp Seems that you're not alone when Arduino hangs up with DS18B20 connected, see http://tushev.org/articles/arduino/item/46-arduino-and-watchdog-timer.
This guy suffered from condensation causing a 'shortcut' between the sensor wires...IMO a library should never hang on communication errors, but return an error value after a timeout or so...
@Yveaux said:> @ServiceXp Seems that you're not alone when Arduino hangs up with DS18B20 connected, see http://tushev.org/articles/arduino/item/46-arduino-and-watchdog-timer.
This guy suffered from condensation causing a 'shortcut' between the sensor wires...
IMO a library should never hang on communication errors, but return an error value after a timeout or so...
I think if this problem winds up being directly related to the DS18B20, its going to have to be a manufacturing issue, because I have 3, (brand new) of these things and they all lock up the Arduino's (3 different mini pros, with 3 different DS18B20's of the same batch)
I'm not even sure the watchdog timer would help in my case, because in most cases, once the sensor is locked up, the only fix is to clear eeprom and re-install sketch.
-
Oh and power is introduced on the upper left side of the board in the pictures.
-
Maybe already checked, but i'm remembering that a while ago i created a library for light intensity and other LED based stuff, after a while my device also locked up, after searching for merely a week i found a little memory leak in one of my libraries which was just related to a incorrect fixed size char array. It also used the eeprom for storing particular LED settings.
It happened every time after storing a particular setting after a coupe of hours, if stored after 5 minutes there was no problem but the device then just locked up after a couple of hours.
I also had to reset eeprom values before i could continue....
I also remember with a tmp36 receiving 500 degrees celcius values, which was related to a bug code which had nothing to do with it.
If there would be a leak somewhere in the code it can completely #%$#% up. It's the only thing i can come up with now.
-
@Yveaux said:> @ServiceXp Seems that you're not alone when Arduino hangs up with DS18B20 connected, see http://tushev.org/articles/arduino/item/46-arduino-and-watchdog-timer.
This guy suffered from condensation causing a 'shortcut' between the sensor wires...
IMO a library should never hang on communication errors, but return an error value after a timeout or so...
I think if this problem winds up being directly related to the DS18B20, its going to have to be a manufacturing issue, because I have 3, (brand new) of these things and they all lock up the Arduino's (3 different mini pros, with 3 different DS18B20's of the same batch)
I'm not even sure the watchdog timer would help in my case, because in most cases, once the sensor is locked up, the only fix is to clear eeprom and re-install sketch.
@ServiceXp said:
I think if this problem winds up being directly related to the DS18B20, its going to have to be a manufacturing issue,
Could be the case of course, but I would also setup an endurance test with a completely different ds1820 library and see how this behaves over time. In the onewire library there is an example sketch for ds1820 that only uses the onewire library.
Maybe you could try this one.
Just to rule things out, and please run it without mysensors.Good luck!
-
Was excited last night, a new batch of DS18B20 arrived, so I connected it, uploaded the original sketch and........ This morning @ 4:48 with a temp of 74.6F it locked up.
Well, I guess it's not the DS18B20 hardware... This is just ridiculous, I've got to be doing something wrong here....
-
As suggested by @gregl, I loaded the 'single' sketch found in the MySensors download on one of the other sensors that was locking up and put it in the freezer for ~2 days. Removed it this morning, and connected it to the serial monitor. (there was a power cycle when moving from the batteries to the serial connector) and it was humming along just fine.
-
@ServiceXp said:
As suggested by @gregl, I loaded the 'single' sketch found in the MySensors download on one of the other sensors that was locking up and put it in the freezer for ~2 days. Removed it this morning, and connected it to the serial monitor. (there was a power cycle when moving from the batteries to the serial connector) and it was humming along just fine.
-
Wouldnt that power cycle have also reset any evidence of if the sketch was hanging? try connecting just a wire from gnd to gnd and the TX from the mini pro to the RX on your programmer.
-
Can you post ( codebender) your sketch as you have it? I can run it up and see if i can replicate.
-
-
@ServiceXp said:
As suggested by @gregl, I loaded the 'single' sketch found in the MySensors download on one of the other sensors that was locking up and put it in the freezer for ~2 days. Removed it this morning, and connected it to the serial monitor. (there was a power cycle when moving from the batteries to the serial connector) and it was humming along just fine.
-
Wouldnt that power cycle have also reset any evidence of if the sketch was hanging? try connecting just a wire from gnd to gnd and the TX from the mini pro to the RX on your programmer.
-
Can you post ( codebender) your sketch as you have it? I can run it up and see if i can replicate.
- 'most' of the time, when this 'event' takes place the Arduino's eeprom has to be cleared and new sketch uploaded. I would say 7 out of 10 times this is necessary. One time disconnecting the DS18B20 allowed the Arduino to restart, and a few times connecting the Arduino to the programmer allowed it to restart.
I updated the DallasTemperature and OneWire libraries to the most recent version I could find yesterday, and so far (it's been about 13 hrs so more time is needed) this Arduino is still functioning. I also changed power source (so I could monitor the communications) using the programmer. It has locked up in the past using the programmer, which led me to think it's NOT a power issue, but really at this point I'm running out of hair to pull out.
CodeBender doesn't seem to be working ATM.. When it comes back I'll post the sketch..
-
-
-
- 'most' of the time, when this 'event' takes place the Arduino's eeprom has to be cleared and new sketch uploaded. I would say 7 out of 10 times this is necessary. One time disconnecting the DS18B20 allowed the Arduino to restart, and a few times connecting the Arduino to the programmer allowed it to restart.
I updated the DallasTemperature and OneWire libraries to the most recent version I could find yesterday, and so far (it's been about 13 hrs so more time is needed) this Arduino is still functioning. I also changed power source (so I could monitor the communications) using the programmer. It has locked up in the past using the programmer, which led me to think it's NOT a power issue, but really at this point I'm running out of hair to pull out.
CodeBender doesn't seem to be working ATM.. When it comes back I'll post the sketch..
