💬 Temperature Sensor

[skywatch]

Sorry for the dealy, I have had a week of plumbing problems at home - yuck! :(

So, I came back fresh to this and noticed that I had put the interrupt into the code ready for the water leak sensor (apt considering this weeks activities!) - BUT, I had not assigned the pin nor initialised it in the code. So maybe it was floating and giving random triggers?
I tested by changing from int8_t sleep(1, FALLING, SLEEP_TIME); to int8_t sleep(SLEEP_TIME); but now I get battery level sent every single second! - This is making me crazy......

The log for the gateway has the following.....

Sep  3 07:00:37 HAAS rsyslogd-2007: action 'action 17' suspended, next retry is Sun Sep  3 07:02:07 2017 [try http://www.rsyslog.com/e/2007 ]
Sep  3 06:26:28 HAAS rsyslogd0: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/0 ]
Sep  3 06:26:28 HAAS rsyslogd-2359: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/2359 ]

Not sure what the above is all about. Nor the below....

7:15:45 HAAS dhcpcd[474]: eth0: Router Advertisement from fe80::3291:8fff:fe06:64bc

But here is sending data every second.....

Sep  3 12:46:52 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:46:53 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:46:54 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:46:55 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:46:56 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:46:57 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:46:58 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:46:59 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75
Sep  3 12:47:00 HAAS mysgw: TSF:MSG:READ,5-5-0,s=255,c=3,t=0,pt=1,l=1,sg=0:75

Will try debug on node next....

[skywatch]

I.m sure it is a bug in 2.2.0-beta as I have the same issues with another node sending data whenever it changes and not sleeping.

[dertho]

Hi,

is there any known problem / bug with version 2.1.* and the Dallas temp sensor? (I found non in the bug tracker and/or forum)

I updated several nodes from 1.5 to 2.1.1 and now no temp sensor is working. No temp sensor DS18B20 is found by the node, therefore -127.0 is returned to the controller. I checked the wiring - as illustrated in this manual, everything seems right; incl. the pull-up with 4,7 k. I use the modified version of the Dallas-Library included in the examples package, as stated out in this manual.

Thanks,
Thomas

[Mohammed Zaman]

I am not a programmer, but trying to learn by making small projects.
I am trying to build a arduino/ESP8266 with temp sensor so that at a particular set temp it sends a single to another arduino/ESP8266 with relay to turn on a cooler/heater. if there is a thread on this, please help me find it.

[rejoe2]

@Mohammed-Zaman This seems to be possible, you may find more info wrt your topic using "node to node communication" as a keyword for searching the forum.
This might be a good starting point: https://forum.mysensors.org/topic/6386/almost-controller-less-mysensors-switch-light-network/8#

[gohan]

https://forum.mysensors.org/topic/7810/alternative-passive-mode if you don't want to use a gateway.

[sjoerd14]

regarding error:

C:\Users\Admin\Documents\Arduino\libraries\DallasTemperature/DallasTemperature.h:249:13: error: 'int16_t DallasTemperature::millisToWaitForConversion(uint8_t)' is private

In the latest version of Miles Burton's the function is public and compiling fine.
https://github.com/milesburton/Arduino-Temperature-Control-Library

You can import the Lib as zip.
You have to remove \ archive the lib: ...\libraries\DallasTemperature

[mfalkvidd]

@sjoerd14 yes, thanks to MySensors user David Ducatel. The change is tracked in https://github.com/mysensors/MySensorsArduinoExamples/issues/20 and https://github.com/milesburton/Arduino-Temperature-Control-Library/pull/72 but we're still waiting for an official release of milesburton's library.

[nofox]

Hi, I have few in wall nodes mounted under the light switches. I have two relays and one DS18B20 in each node. When i'm turning light on, switching the relay, the DS18B20 readings jumping about 0.8 degrees celsius up. When I switch off the relay readings back to normal. Anyone have similar problems ? Sensors are away from from node board, relays etc. so it's not about the heat from atmega or relays.

[gohan]

Is the temperature gradually rising after the relay is activated or it is instantly jumping 0.8°?

[nofox]

Jumping 0.8 immediately after switching the relay and sometimes rising very slow during the time when relay is on.

[gohan]

That makes it quite difficult to figure out the problem. Can you make another node with same setup and see if you get the same results and if you do try unplug the relay and see what happens

[skywatch]

It's probably a voltage drop from the psu when the relay is engaged and drawing current. That will cause the output voltage to dip slightly.

If it is only momentary you can add a beefy capacitor across the power supply, but if the readings change for the whole time the relay is on, you really need to replace the relay with something that uses less power (triac/mosfet??) - Or get a more stable power supply with good regulation.

A final thing might be more noise on the power line with the psu sending more current with the relay on. again a smoothing capacitor would help if this were the case.

You could also try looking into the wiring and see if the relay cables and the ds18b20 cables are far enough apart, some induction might be going on there between the cables. Also, make sure everything goes back to a single ground point. I can't imagine how an earth loop would cause what you describe, but it's always a good thing to do.....

Another thought to think about is matbe the magnetic field from the relap power cables are inducing into the sensor cables.

[ben999]

Hi
Can we talk about redundancy please? What if one or more sensor fail on a one-wire bus? Would it make the whole line unusable?
As part of a central heating MySensorization i would like to have groups of 3 sensors and have some sort of redundancy check.
Would i be allowed to run multiple one-wire busses on a single arduino?
Thanks a lot foryour help

[mfalkvidd]

@ben999 you can have as many onewire buses as you have digital pins. Just add more of these:

#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
OneWire oneWire(ONE_WIRE_BUS);

[ben999]

@mfalkvidd thanks a lot. Yes, that looks good to me. I will have a go.

The real big question now is about what happens when one or more sensor fails on the line.
I am not talking about removing a sensor, which doesn't produce any fault.
My concern is how does a DS18 ends its life under normal operation? Complete shortcut?

[mfalkvidd]

@ben999 I don't think there are any guarantees on how it will fail. If there are, the datasheet should list them.

[zboblamont]

@ben999 I cannot remember WHERE I read it, but if a DS18B20 fails it will either send impossible results when addressed or fail to be addressed at all as it is digitally addressed. Only cable short circuits can pull the entire chain down, as I found out when two socket pins had crossed over (sensor crimped into telephone plugs).

[ben999]

@mfalkvidd thank you for the idea. Had a look (boooooring reading for me :D ) but no mention to failiure

@zboblamont you're right. Seems that a faulty sensor return "85" (top of my head). And a "dead" sensor looses its bus address (next sensor on the chain takes its address and so on)

Thanks a lot gentlemen :)

[rejoe2]

@ben999 said in 💬 Temperature Sensor:

And a "dead" sensor looses its bus address (next sensor on the chain takes its address and so on)

That's not exactly right. Each of the 1-wire devices uses a hardcoded, unique address that can not be changed.
So if you use the standard sketch with multiple DS18B20, in case of detached or replaced sensors you may get reported the measured temperatures comming from the same physical DS18B20 device under a different ChildID (after node reboot). To avoid effects like that, one has to take additional measures as described here . In short:

• Use an array with the physical ID's to address them
• Store a hash-array (done automatically) to identify "known" physical ID's that have once been attached to the bus as well as the ChildID used for MySensors.