💬 Temperature Sensor
-
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.
-
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 -
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 -
@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);@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 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 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?@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 I don't think there are any guarantees on how it will fail. If there are, the datasheet should list them.
@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 :)
-
@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 :)
@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.
-
@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.
-
When I try to compile the sketch for an ESP8266 I get an error in DallasTemperature.h which results in an error in OneWire.h
OneWire.h:108:2: error: #error "Please define I/O register types here" #error "Please define I/O register types here"Is it possible to make the sensor run on an ESP?
-
Hi, I'm having a hard time getting this Temperatursensor to work with Home Assistant. When i start it it doesn't register with the HA. If I use the same hardware and switch out the sensor to a DHT sensor (new sketch of course) then it works out of the box, HA sees the sensor. I've tried changing the Dallas DS18B20, but nothing. If i look at the logs the gateway have no problem with the sensor. Is there something in the code for the sensor that doesn't add up to it being presented to HA in the right way? I'm quite the newbie when it comes to programming.
-
@gohan No I have not. I have a RF-Link also connected to the HA and it's working great. As I said, if I use the same hardware that I used to control the Dallas sensor and change the sensor to a DHT sensor the DHT sensor is accepted by HA and shows up as a sensor. That's why I was asking if there is something in the code for the Temperature sensor sketch that has to be changed to be able to present it to HA.
-
@gohan Thanks for the quick reply! Well I've use the standard sketch for this Temperatur sensor. This is the code i've got.
// Enable debug prints to serial monitor //#define MY_DEBUG // Enable and select radio type attached #define MY_RADIO_NRF24 //#define MY_RADIO_RFM69 #include <SPI.h> #include <MySensors.h> #include <DallasTemperature.h> #include <OneWire.h> #define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No #define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected #define MAX_ATTACHED_DS18B20 16 unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds) OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs) DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. float lastTemperature[MAX_ATTACHED_DS18B20]; int numSensors=0; bool receivedConfig = false; bool metric = true; // Initialize temperature message MyMessage msg(0,V_TEMP); void before() { // Startup up the OneWire library sensors.begin(); } void setup() { // requestTemperatures() will not block current thread sensors.setWaitForConversion(false); } void presentation() { // Send the sketch version information to the gateway and Controller sendSketchInfo("Temperature Sensor", "1.1"); // Fetch the number of attached temperature sensors numSensors = sensors.getDeviceCount(); // Present all sensors to controller for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) { present(i, S_TEMP); } } void loop() { // Fetch temperatures from Dallas sensors sensors.requestTemperatures(); // query conversion time and sleep until conversion completed int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution()); // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater) sleep(conversionTime); // 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>((getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.; // Only send data if temperature has changed and no error #if COMPARE_TEMP == 1 if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) { #else if (temperature != -127.00 && temperature != 85.00) { #endif // Send in the new temperature send(msg.setSensor(i).set(temperature,1)); // Save new temperatures for next compare lastTemperature[i]=temperature; } } sleep(SLEEP_TIME); }``` -
Looking at code example it seems to be sufficient to set bool metric = false to get readings in Fahrenheit, but node still returns readings in C. Any idea why?