Reliability?

RJ_Make

Thinking out loud.... In both area's I have z-wave extenders in close proximity of the sensors. Hmmmmm

Damme

@ServiceXp Now when you sayit... I had a wireless mouse that lowerd my reception. A cheap brand, I did't like it and everytime a sensor transmitted the mouse got laggy.

RJ_Make

@gregl said:> This is very weird...but the wierdest bit to me is that you need to clear the eeprom to get it going again!

Are you using the example sketches un-modified for these sensors?

Few ideas:

What about adding some code to void setup to print out all values in the eeprom - to test your idea in them being corrupt?

What about swapping the mini pro's from your working DHT22 sensor and using it for the temp sensor...see if the problem follows....

Change the resistor/add capacitor to the temp sensor in case the output is not ideal from the pro-mini http://www.picaxeforum.co.uk/archive/index.php/t-11268.html
( i have some ds18b20's on long cables using parasite power and i needed to drop the resistor value for stability)

Change the powersupply AND cable !. Are you using a USB port on your computer??
Hows it all connected up? ( post a photo )

Still dealing with this...

Built up a completely new freezer sensor, connected it, and it locked up 8hrs later. My EH40 project with the DS18B20 is also locking up. This is driving me crazy..
I added a cap (.22uF) to my EH40, but it still locked up.

I've removed all near by z-wave devices, so I now know that is not causing it..

RJ_Make

Let me ask you guys this.. Is it 'OK' to power the mini pro via the VCC terminal on the side? This is how I've been powering all my sensors...
Should I be using the RAW pin?

I've been powering the DS18B20 directly from the stepped up 3.3v output of the module (not the mini pro)

korttoma

@ServiceXp
If you are feeding 3.3v to the VCC pin it should be ok but if you are in fact feeding 3.3v to the RAW pin it might not be enough (Input Voltage 3.35 -12 V (3.3V model))

http://arduino.cc/en/Main/ArduinoBoardProMini

RJ_Make

Locked up again this morning @ 7:37am with a temp of -0.1. So a .47uF cap isn't the answer.... I think my last option before giving up on this is to remove the stepup regulator.

Any other idea's?

gregl

@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?

RJ_Make

@gregl said:> @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?

and 2) ---- will do and report back.

Do you think the wire it self could be a/the problem. Since much of the sensor line is also subject to low temps, maybe it's breaking down some how... (Although I'm using 3 different DS18B20 sensors) just talking out loud..... ;-) ....

I have not, but I can add that to the 'things to try' list..

Thanks for you help @gregl

Bandra

@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.

RJ_Make

@Bandra Thank you Sir. I'll report back.

RJ_Make

@gregl
Only sending this, every 30 sec

gw.send(msgTEMP.setSensor(i).set(777, 1));

and this is what I'm getting in return.. Not sure what the fails are about?

RJ_Make

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));
		}

	}

RJ_Make

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.

RJ_Make

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

Yveaux

@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?

RJ_Make

@Yveaux

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.

Yveaux

@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

@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...

RJ_Make

@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!

RJ_Make

@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.

Reliability?

6

11.7k

11.2k

113.0k