💬 Temperature Sensor

[Digdogger]

OK thanks mfalkvidd

[ben999]

Slightly off-topic here... but related to this particular sketch

If you look close enough (and copy-paste the sketch into your IDE) you'll witness that one curly-bracket is technically missing at the end of loop()...

But as I added it to the sketch I got error

Sketch compiles fine "with" the missing curly-bracket... ???

Any comment to that (in my sense) funny behavior ?

[mfalkvidd]

@ben999 the simple answer is probably that the backet isn't missing

Can you show why you think it is missing?

[ben999]

@mfalkvidd

I must have gone mad then

Check the loop()
The last closing curly--bracket is for

for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {

So which one closes

void loop()     {  

If i add one more to "make it right" then hell brakes loose...

sketch_jul31a:110: error: expected declaration before '}' token
 }
 ^
exit status 1
expected declaration before '}' token

1-That's the only sketch behaving this way
2-Even the "IDE-automatic-opening-bracket-finder" (shows which bracket is open when placing cursor on closing bracket) can NOT find the right bracket for loop()...

[mfalkvidd]

Interesting observation @ben999

This is caused by the preprocessing directives.

#if COMPARE_TEMP == 1
    if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) {
#else
    if (temperature != -127.00 && temperature != 85.00) {
#endif

Only one of these if statements will be active. The Arduino IDE probably doesn't evaluate preprocessing directives, so it sees two if statements and therefore thinks it should see two end braces. A way to "fix" this could be to move the starting curly brace to after the preprocessing directives:

#if COMPARE_TEMP == 1
    if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00)
#else
    if (temperature != -127.00 && temperature != 85.00)
#endif
    {

This allows the Arduino IDE to parse the code correctly, and correctly match the braces.

[gohan]

It's time to move to a better IDE

[ben999]

@mfalkvidd
Gosh you're a genius ! And you share your knowledge with style and simple explanation ! But i can only upvote you once

@gohan
No way IDE is nice and simple for nice and simple people like me

[chaeron]

I just upgraded to the MYS 2.1.1 version.

My OneWire temperature sensors were not detected!

I moved the sensors.begin() from setup() to before(), and that seems to have fixed things, and my temp sensors are being detected and read now.

Anyone know why the OneWire library has to be initialized before MySensors setup?

Thanks!

[rejoe2]

@chaeron I assume, you used an old version of the sketch.

Your question most likely is related to a change in the order of the initialisation. This has changed in Version 2.2: from
setup()=>presentation()
to
before()=>presentation()=>setup().

So also the initialisation of sensors had to be reviewed accordingly (eg. to get the number of devices).

[chaeron]

@rejoe2 said in Temperature Sensor:

@chaeron I assume, you used an old version of the sketch.

That is correct....the original code was written over a year ago. Trying to run it under 2.1.1 caused it to fail.

Your question most likely is related to a change in the order of the initialisation. This has changed in Version 2.2: from
setup()=>presentation()
to
before()=>presentation()=>setup().

So where was this rather major change documented? It would probably have broken any 1-Wire examples, including the temperature one.

So also the initialisation of sensors had to be reviewed accordingly (eg. to get the number of devices).

So I figured out....I went looking for documentation on this rather significant change and was not able to find it noted anywhere.

[rejoe2]

There was a rather small note in the 2.0.0 changelog about the introduction of before().

Btw: Another functional routine (preHwInit() (?)) may have been introduced also with 2.1.1 (?). But until now, all of my sketches and tests got along without this preHwInit() functionality. But imo the new structure is pretty good: before() is helpfull to initialise SPI devices on same bus as nRF24 and to collect relevant info like the number of DS18x20, setup() is now also good to send info you only need once (e.g. the Dallas-Chip-ID).

The rest is - at least afaik - not really documented well, but most examples (if you use the updated ones) will work (apart from the DS18x20 example, where other - external - code changes made some parts tricky to use.

I made some working sketches for the Dallas Sensors some time ago based on some ideas I found here in the MySensors forum; they mostly should still work (exept for the change of getConfig() to getControllerConfig()). If you are interested: here .

Kind regards

[rejoe2]

If anyone is interested:

The sketches in my repo have been updated yesterday for complete compability with the new structure and syntax. They compile fine and should work, but I didn't have the time to make functional tests also.
If anyone is interested, I could also add a multibus example with several Sensors at each bus and different timings for each bus. One of my nodes is working on this concept for several days now (Heizung, RS485 version), so I'm pretty confident this will reliably work for longer periods. But it's rather special .

[skywatch]

@rejoe2
Where do we find your repo then?

[rejoe2]

@chaeron
Thx for asking.

Repo-link was mentioned above, @rejoe2 said in Temperature Sensor:

If you are interested: here .

Btw: the sketches have been updated and compile now also with MySensors 2.2.0-beta. But to be honest, I didn't test them with hardware until now. So feedback is appreciated :simple_smile:.

[rejoe2]

Additionally: There is also a multibus version included that uses different timings for reading each of the buses.
For using this sketch, I'm not sure wheter some changes in the DallasTemperature-lib also is required (it is based on an very recent example of the maintainer's guthub version; should be linked in the Arduino Library Manager; I myself applied some changes wrt. this in my local libs).
I may aslo post this in case anyone's interested (and these mods are necessary).

[Dick]

@rejoe2 Any idea why the DallasTemperatureSimple from your GitHub not presenting in Domoticz?

/**
   The MySensors Arduino library handles the wireless radio link and protocol
   between your home built sensors/actuators and HA controller of choice.
   The sensors forms a self healing radio network with optional repeaters. Each
   repeater and gateway builds a routing tables in EEPROM which keeps track of the
   network topology allowing messages to be routed to nodes.

   Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
   Copyright (C) 2013-2015 Sensnology AB
   Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors

   Documentation: http://www.mysensors.org
   Support Forum: http://forum.mysensors.org

   This program is free software; you can redistribute it and/or
   modify it under the terms of the GNU General Public License
   version 2 as published by the Free Software Foundation.

 *******************************

   DESCRIPTION

   Example sketch showing how to send in DS1820B OneWire temperature readings back to the controller
   http://www.mysensors.org/build/temp
   Enhanced Version also sending the Dallas-ROM-ID, MySensors Version >=2.1.0
*/

// 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
uint8_t DS_First_Child_ID = 7; //First Child-ID to be used by Dallas Bus; set this to be higher than other Child-ID's who need EEPROM storage to avoid conflicts
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;
DeviceAddress tempDeviceAddress; // We'll use this variable to store a found device address
int resolution = 12; // precision: 12 bits = 0.0625°C, 11 bits = 0.125°C, 10 bits = 0.25°C, 9 bits = 0.5°C
int conversionTime = 0;
// Initialize temperature message
MyMessage msgTemp(0, V_TEMP);
MyMessage msgId(0, V_ID);

char* charAddr = "Check for faults";
#define SEND_ID

void before()
{
  // 12 bits = 750 ms, 11 bits = 375ms, 10 bits = 187.5ms, 9 bits = 93.75ms
  conversionTime = 750 / (1 << (12 - resolution));
  // Startup up the OneWire library
  sensors.begin();
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Temperature Sensor", "1.2");

  // 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++) {
    sensors.getAddress(tempDeviceAddress, i);
    charAddr = addrToChar(tempDeviceAddress);
    present(i + DS_First_Child_ID, S_TEMP, charAddr);
#ifdef MY_DEBUG
    Serial.println(charAddr);
#endif
  }
}

void setup()
{
  // requestTemperatures() will not block current thread
  sensors.setWaitForConversion(false);

  for (int i = 0; i < numSensors && i < MAX_ATTACHED_DS18B20; i++) {
    sensors.getAddress(tempDeviceAddress, i);
#ifdef SEND_ID
    // 8 will assure a length of 16 of the sent ROM-ID
    send(msgId.setSensor(i + DS_First_Child_ID).set(tempDeviceAddress, 8));
#endif
    sensors.setResolution(tempDeviceAddress, resolution);
    metric = getControllerConfig().isMetric;
  }
}


void loop()
{
  // Fetch temperatures from Dallas sensors
  sensors.requestTemperatures();

  // 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>((metric ? 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(msgTemp.setSensor(i + DS_First_Child_ID).set(temperature, 1));
      wait(20);
      // Save new temperatures for next compare
      lastTemperature[i] = temperature;
    }
  }

  // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
  sleep(SLEEP_TIME);
}

char* addrToChar(uint8_t* data) {
  String strAddr = String(data[0], HEX); //Chip Version; should be higher than 16
  byte first ;
  int j = 0;
  for (uint8_t i = 1; i < 8; i++) {
    if (data[i] < 16) strAddr = strAddr + 0;
    strAddr = strAddr + String(data[i], HEX);
    strAddr.toUpperCase();
  }
  for (int j = 0; j < 16; j++) {
    charAddr[j] = strAddr[j];
  }
  return charAddr;
}

[gohan]

@Dick you are missing

#define MY_NODE_ID x

where x is the unique sensor ID you want to assign to node. If look in the gateway or node log you will see the node asking for an ID

[mfalkvidd]

@gohan Domticz is capable of handing out node ids so using the default auto setting is perfectly fine.

But yes, the debug log from node and gateway will help a lot in determining what the problem is.

[Dick]

@mfalkvidd I already tried a fixed node ID but that was not the solution so I checked the log of domoticz and this is the result:

2017-08-19 11:59:30.260 MySensors: Node: 48, Sketch Name: Temperature Sensor
2017-08-19 11:59:30.261 MySensors: Node: 48, Sketch Version: 1.2
2017-08-19 11:59:38.480 MySensors: Node: 48, Sketch Name: Temperature Sensor
2017-08-19 11:59:38.481 MySensors: Node: 48, Sketch Version: 1.2

So it see the node but it does not pop up as a new device.
The Arduino log shows this:

0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.1
3 MCO:BGN:BFR
6 TSM:INIT
7 TSF:WUR:MS=0
14 TSM:INIT:TSP OK
16 TSF:SID:OK,ID=48
17 TSM:FPAR
59 TSF:MSG:SEND,48-48-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
360 TSF:MSG:READ,0-0-48,s=255,c=3,t=8,pt=1,l=1,sg=0:0
365 TSF:MSG:FPAR OK,ID=0,D=1
408 TSF:MSG:READ,20-20-48,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2066 TSM:FPAR:OK
2067 TSM:ID
2068 TSM:ID:OK
2070 TSM:UPL
2074 TSF:MSG:SEND,48-48-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2086 TSF:MSG:READ,0-0-48,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2092 TSF:MSG:PONG RECV,HP=1
2094 TSM:UPL:OK
2096 TSM:READY:ID=48,PAR=0,DIS=1
2101 TSF:MSG:SEND,48-48-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2110 TSF:MSG:READ,0-0-48,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2118 TSF:MSG:SEND,48-48-0-0,s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
2127 TSF:MSG:SEND,48-48-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2143 TSF:MSG:READ,0-0-48,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2152 TSF:MSG:SEND,48-48-0-0,s=255,c=3,t=11,pt=0,l=18,sg=0,ft=0,st=OK:Temperature Sensor
2162 TSF:MSG:SEND,48-48-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.2
2169 MCO:REG:REQ
2173 TSF:MSG:SEND,48-48-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2183 TSF:MSG:READ,0-0-48,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2188 MCO:PIM:NODE REG=1
2190 MCO:BGN:STP
2191 MCO:BGN:INIT OK,TSP=1
2196 MCO:SLP:MS=750,SMS=0,I1=255,M1=255,I2=255,M2=255
2201 !MCO:SLP:REP
2952 MCO:SLP:MS=30000,SMS=0,I1=255,M1=255,I2=255,M2=255
2957 !MCO:SLP:REP
32960 MCO:SLP:MS=750,SMS=0,I1=255,M1=255,I2=255,M2=255

[mfalkvidd]

@Dick that output doesn't seem to match the sketch you posted. The output says the node is a repeater, but I don't see any repeater activation in the sketch.

[rejoe2]

@mfalkvidd Thx for your observation, I didn't realise that. Did you try to use this sketch also?
As FHEM is the controller sw I use, I am not able to really test this kind of behaviour, that more seemed to be related to domoticz (or other trouble wrt. to this individual MySensors-installation).

@Dick Imo, the node at least when trying to register behaves as necessary: it presents itself to the controller (but the chosen ID seems to be already bound to a different node). In FHEM - not for the node itself but for individual readings - it is necessary to reload the page to see updated readings, if it's the very first time they are sent from node's side (hope, you can follow my thoughts). Maybe domoticz shows a similar behaviour?

[mfalkvidd]

@rejoe2 could you clarify which observation you are referring to?

[rejoe2]

@mfalkvidd I was reffering to this part of the serial output:

0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.1

Imo, the only thing that is not standard is to also use a comment when presenting the individual temp-sensors:

present(i + DS_First_Child_ID, S_TEMP, charAddr);

FHEM doesn't care about that (just ignores this comment), but maybe other controllers don't like that at all. (I added this as it is a possible feature and may be helpful for others), but @Dick , you could try to delete the last argument.

[mfalkvidd]

@rejoe2 the repeater feature is disabled by default, so Dick must have activated it by a define.

[rejoe2]

@Dick Besides the inclusion mode, in FHEM one also has to activate a feature called "autocreate". Is there a comparable routine, and in case if: did you turn it on?
If you have a look in your domoticz log, there most likely appear further trials to register, or not?

[Dick]

@mfalkvidd For your info, I started the sketch cleareeprom to clear my Nano, loaded the script mentioned already and the log I posted is the same so the log must fit the sketch for the DallasTemperatureSimple. The repeater is activated or is it better to turn it off?

[mfalkvidd]

@Dick the repeater feature is turned off by default so there is something very fishy going on.
Have you modified any of the MySensors library files?

[Dick]

@rejoe2 What I see in the Log of Domoticz is that all the nodes are registered and are visible in Black the only blue one is only the Dalles node
2017-08-19 12:44:48.339 MySensors: Node: 3, Sketch Name: Relay
2017-08-19 12:44:48.340 MySensors: Node: 3, Sketch Version: 1.0
2017-08-19 12:47:28.520 MySensors: Node: 48, Sketch Name: Temperature Sensor
2017-08-19 12:47:28.530 MySensors: Node: 48, Sketch Version: 1.2
2017-08-19 12:48:00.005 (GW Mysensors) Light/Switch (Voor Gor Pir)
2017-08-19 12:48:39.405 MySensors: Node: 48, Sketch Name: Temperature Sensor
2017-08-19 12:48:39.405 MySensors: Node: 48, Sketch Version: 1.2
2017-08-19 12:49:36.059 MySensors: Node: 48, Sketch Name: Temperature Sensor
2017-08-19 12:49:36.060 MySensors: Node: 48, Sketch Version: 1.2
2017-08-19 12:51:47.939 MySensors: Node: 12, Sketch Name: Temperature Sensor
2017-08-19 12:51:47.939 MySensors: Node: 12, Sketch Version: 1.2
2017-08-19 12:51:54.329 MySensors: Node: 12, Sketch Name: Temperature Sensor
2017-08-19 12:51:54.330 MySensors: Node: 12, Sketch Version: 1.2
2017-08-19 12:54:56.992 (GW Mysensors) Light/Switch (Serre IRbui)
2017-08-19 12:55:44.429 MySensors: Node: 12, Sketch Name: Temperature Sensor
2017-08-19 12:55:44.440 MySensors: Node: 12, Sketch Version: 1.2

[Dick]

@mfalkvidd I changed the dalles lib with an older one, because in a disussion a wile ago it was advised to get it working. Now this modified Sketch is available I replaced the dalles lib again the latest one. For the rest nothing.

[mfalkvidd]

@Dick this part

2201 !MCO:SLP:REP

of the initial log you posted says that the node cannot sleep because it is a repeater.

This part of the sketch:

  // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
  sleep(conversionTime);

explains that if the node is a repeater, the sleep call must be replaced by wait. If it is not replaced, the temperature sensors will not be ready when getTemp... is called, so the node will not send any values. Domoticz only lists sensors that have sent a value.

[Dick]

@mfalkvidd I chaned the Sleep into Wait but the same log in both Domoticz and on my Arduino. I thought it was an easy go but it appear not to be.

[rejoe2]

@Dick Did you change it at both places ( sleep(conversionTime);)?

[Dick]

@rejoe2 Yes on both location I replaced the sleep into a wait

[Dick]

@mfalkvidd In the Arduino log he Sleep error is not i anymore so that is solved but still no new device in Domoticz

[mfalkvidd]

@Dick if you get the same log on the Arduino as before changing to wait, the sketch upload must have failed. Perhaps your Arduino is broken?
Edit: Sorry, didn't see your last reply.

What does the node log say now?

[Dick]

@mfalkvidd Ths is what the log says
0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.1
3 MCO:BGN:BFR
6 TSM:INIT
7 TSF:WUR:MS=0
14 TSM:INIT:TSP OK
16 TSF:SID:OK,ID=12
18 TSM:FPAR
59 TSF:MSG:SEND,12-12-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
1016 TSF:MSG:READ,0-0-12,s=255,c=3,t=8,pt=1,l=1,sg=0:0
1021 TSF:MSG:FPAR OK,ID=0,D=1
1804 TSF:MSG:READ,20-20-12,s=255,c=3,t=8,pt=1,l=1,sg=0:1
1851 TSF:MSG:READ,4-4-12,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2067 TSM:FPAR:OK
2068 TSM:ID
2069 TSM:ID:OK
2071 TSM:UPL
2075 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2087 TSF:MSG:READ,0-0-12,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2093 TSF:MSG:PONG RECV,HP=1
2095 TSM:UPL:OK
2097 TSM:READY:ID=12,PAR=0,DIS=1
2102 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2111 TSF:MSG:READ,0-0-12,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2119 TSF:MSG:SEND,12-12-0-0,s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
2128 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2144 TSF:MSG:READ,0-0-12,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2152 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=11,pt=0,l=18,sg=0,ft=0,st=OK:Temperature Sensor
2163 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.2
2169 MCO:REG:REQ
2173 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2183 TSF:MSG:READ,0-0-12,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2188 MCO:PIM:NODE REG=1
2190 MCO:BGN:STP
2192 MCO:BGN:INIT OK,TSP=1

[mfalkvidd]

@Dick thanks. The node still doesn't send any values so that's why it does not show up in Domoticz.

My next step would be to manually add serial debug prints at end of setup(), presentation(), and almost everywhere in loop(), to see why it doesn't attempt to send.

[rejoe2]

Very strange.
I just mad the test and copied the code (out of your post above) to my IDE, compiled and uploaded: No problem, worked fine. Node gets registered by FHEM, sends ID once and Temp regularly as expected. For testing, I used just one DS18B20, but that shouldn't make any difference. (And MySensors lib version 2.2-beta, but that also shouldn't be an issue).

Btw: what kind of a GW you are using?
Recently, I came across a situation with a WiFi-GW that absolutely refused to accept new nodes. Using a serial one, everything was fine... Strange thing, too. (The GW itself was ok, there were several other nodes working without any communication problems. the new HW was also ok. Last, the channel was also correct, as all the existing nodes just switched over to the serial GW.... Reflashing that nasty thing also was no solution.)

[Dick]

I put some deug lines i it and after uploadig the sketch it stops here (wait conversationtime.)
setup done.
2191 MCO:BGN:INIT OK,TSP=1
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.

[mfalkvidd]

@Dick could you try printing the value of numSensors in presentation()? (or in loop, it should have the same value there)

[Dick]

@mfalkvidd how can I manage that? sorr for the perhaps stupid qestion?

[mfalkvidd]

@Dick

Serial.print("Number of attached sensors found by the DallasTemperature library: ");
Serial.println(numSensors);

[rejoe2]

@Dick best place would be after numSensors = ... in presentation()

Just to mention that: The Arduino I used already had a node ID (I usually assign it manually). But your problem seems to be something completely different.

[Dick]

@mfalkvidd I tried it in Presentation() and in Loop() inboth no results in the log (copied it as you advised me how to do. so no result bisible). it is getting complex I think!
6 TSM:INIT
7 TSF:WUR:MS=0
14 TSM:INIT:TSP OK
16 TSF:SID:OK,ID=12
17 TSM:FPAR
59 TSF:MSG:SEND,12-12-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
452 TSF:MSG:READ,0-0-12,s=255,c=3,t=8,pt=1,l=1,sg=0:0
457 TSF:MSG:FPAR OK,ID=0,D=1
561 TSF:MSG:READ,20-20-12,s=255,c=3,t=8,pt=1,l=1,sg=0:1
2066 TSM:FPAR:OK
2067 TSM:ID
2068 TSM:ID:OK
2070 TSM:UPL
2074 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2086 TSF:MSG:READ,0-0-12,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2092 TSF:MSG:PONG RECV,HP=1
2094 TSM:UPL:OK
2096 TSM:READY:ID=12,PAR=0,DIS=1
2101 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2110 TSF:MSG:READ,0-0-12,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2118 TSF:MSG:SEND,12-12-0-0,s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
2127 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2142 TSF:MSG:READ,0-0-12,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2151 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=11,pt=0,l=18,sg=0,ft=0,st=OK:Temperature Sensor
2161 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.2
2168 MCO:REG:REQ
2172 TSF:MSG:SEND,12-12-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2181 TSF:MSG:READ,0-0-12,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2186 MCO:PIM:NODE REG=1
2189 MCO:BGN:STP
setup done.
2190 MCO:BGN:INIT OK,TSP=1
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.
fetch sensors.
wait conversationtime.

[rejoe2]

How are your sensors wired? Parasitic or 3 wires?
Sounds like a broken sensor, wrong wiring or a lot of sensors (to much for the pullup used).

[mfalkvidd]

Ok. I give up. If the node isn't executing the serial prints I know no way of troubleshooting.

[Dick]

@mfalkvidd I ony can tell "thanksfo the support ad you time" . Have a nice wekend!!!

[skywatch]

I have been frustrated with this for weeks now. Today I notice that void loop is not closed with a curly brace and if I add one it does not compile.
So what black magic is going on here?

I have been trying to get sensor readings every 2 mins and battery every half hour. But whatever I try it still gives temp every minute and battery at once a minute too. No wonder my batteries are draining so fast.

[mfalkvidd]

@skywatch the curly braces were discussed and explained earlier in this thread.

Could you post your sketch and the debug output of your node?

[skywatch]

@mfalkvidd

Thanks for fast reply! See code below. If you don't see problem there I will debug tomorrow. The battery time is set for 90sec to test, but is taking 18mins between sends!

// Enable debug prints to serial monitor
//#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No
#define MY_RF24_PA_LEVEL (RF24_PA_LOW)
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
#define MAX_ATTACHED_DS18B20 3
#include <SPI.h>
#include <MySensors.h>
#include <DallasTemperature.h>
#include <OneWire.h>
int BATTERY_SENSE_PIN = A0;  // select the input pin for the battery sense point
int batteryPcnt = 0;
unsigned long SLEEP_TIME = 117000; // 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;
const long interval = 90000;
unsigned long previousMillis = 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);
  analogReference(INTERNAL);
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("HW/CH", "0.4");

  // 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()
{
  // get the battery Voltage
  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;
    int sensorValue = analogRead(BATTERY_SENSE_PIN);
    batteryPcnt = sensorValue / 10;
    sendBatteryLevel(batteryPcnt);
  }

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

  int8_t sleep(1, FALLING, SLEEP_TIME);
}```

[mfalkvidd]

@skywatch doing what you want is a bit hard since millis won't update while the node is in power save mode (sleeping). But this should do it:
set SLEEP_TIME = 2 * 60 * 1000 // 2 minutes
and change

void loop()
{
  // get the battery Voltage
  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;
    int sensorValue = analogRead(BATTERY_SENSE_PIN);
    batteryPcnt = sensorValue / 10;
    sendBatteryLevel(batteryPcnt);
  }
...

to

unsigned int batteryReportFactor = 30*60*1000ul/SLEEP_TIME; // Only report battery every x SLEEP times (x=15 with current values)
unsigned int timesSlept = 0;
void loop()
{
  if (timesSlept < batteryReportFactor) {
    timesSlept++;
  } else {
    // get the battery Voltage
    timesSlept = 0;
    int sensorValue = analogRead(BATTERY_SENSE_PIN);
    batteryPcnt = sensorValue / 10;
    sendBatteryLevel(batteryPcnt);
  }
...

I don't understand why you're using interrupt to sleep though.

[skywatch]

@mfalkvidd said in Temperature Sensor:
Thank you very much for helping out with this! - I will try it today if I can. I guess I could use the same principle to send sensor data every 2 minutes instead of every 1 minute and further reduce battery draw. I know the DS18B20 sensors are correctly going into sleep mode, but the node itself is still using too much juice.

@skywatch doing what you want is a bit hard since millis won't update while the node is in power save mode (sleeping).

There is nothing in the API about this, would be nice if it were added as I don't think I will be the only person with such requirements. Also, what does sleep actually do and are there further things I could do to reduce the power use?

I don't understand why you're using interrupt to sleep though.

That is because I haven't finished this node yet.... I am working on it systematically and in future a water leak detector will be added. But only when this part is working correctly and I have good battery life from the node.

[mfalkvidd]

@skywatch said in Temperature Sensor:

There is nothing in the API about this, would be nice if it were added as I don't think I will be the only person with such requirements.

Good point. I have added a note on https://www.mysensors.org/download/sensor_api_20#sleeping

Also, what does sleep actually do and are there further things I could do to reduce the power use?

It does a lot of things, but basically it puts the radio and the Arduino in power save mode and uses the Arduino's watchdog timer to roughly keep track of time (exact timing is not possible because exact timing requires power, and power save mode is all about saving power).

https://www.mysensors.org/build/battery has the official MySensors recommendations on how to save power in battery-operated nodes.

If you want to dive deeper, start with https://www.gammon.com.au/power

[gohan]

I'd use the sleep time to 2 minutes and then simply set a counter that every 15 loops of the code sends battery status and resets the counter. Imho 2 minutes are quite often for battery life.

[mfalkvidd]

@gohan wasn't that what I did?

[skywatch]

This can't be right, can it???

(http://imagebucket.net/7mtp8rcnqss2/BattGraph.jpg)

[gohan]

@mfalkvidd I'm on mobile, I didn't read the code

[mfalkvidd]

@skywatch it looks normal. The precision is probably 1% and the real value close to 100.5%, so sometimes it will be rounded to 101% and sometimes to 100%.

[mfalkvidd]

@gohan hek has added a great feature that I use a lot on mobile. Click the code box once to maximize it. Super neat!

[skywatch]

@mfalkvidd,

Did you notice the time line on the bottom of the image. I thought it was supposed to send data once every 30 mins. Seems that something isn't right or I am looking at it from the wrong angle.....?

[mfalkvidd]

@skywatch I'm not that versed in c/c++ arithmetic, but I suspect the calculation might overflow. Could you add a debug print to see the value of batteryReportFactor?

[skywatch]

OK I'll do that - seems to be sending battery info every minute still though- strange!

[mfalkvidd]

@skywatch could you post the entire sketch also, to check if something fishy has crept in?

[skywatch]

Here is the sketch, debug will be later today I hope....

// Enable debug prints to serial monitor
//#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No
#define MY_RF24_PA_LEVEL (RF24_PA_LOW)
#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
#define MAX_ATTACHED_DS18B20 3
#include <SPI.h>
#include <MySensors.h>
#include <DallasTemperature.h>
#include <OneWire.h>
int BATTERY_SENSE_PIN = A0;  // select the input pin for the battery sense point
int batteryPcnt = 0;
unsigned long SLEEP_TIME = 2 * 60 * 1000; // 2 minutes Sleep time between reads.
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;
const long interval = 90000;
unsigned long previousMillis = 0;
bool receivedConfig = false;
bool metric = true;
unsigned int batteryReportFactor = 30*60*1000/SLEEP_TIME; // Only report battery every x SLEEP times (x=15 with current values)
unsigned int timesSlept = 0;
// 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);
  analogReference(INTERNAL);
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("HW/CH", "0.5");

  // 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()
{
  // get the battery Voltage
  if (timesSlept < batteryReportFactor) {
    timesSlept++;
  } else {
    // get the battery Voltage
    timesSlept = 0;
    int sensorValue = analogRead(BATTERY_SENSE_PIN);
    batteryPcnt = sensorValue / 10;
    sendBatteryLevel(batteryPcnt);
  }

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

  int8_t sleep(1, FALLING, SLEEP_TIME);
}```

Thanks!

[mfalkvidd]

@skywatch code looks good to me. What type of Arduino are you using?

[skywatch]

I am using a pro mini 3.3v 8MHz. I would ideally like to get a 1MHZ bootloader onto it but the last try stopped the temperature sensors sending data (although battery levels were still sent!)..... Hope it helps.

[mfalkvidd]

@skywatch could you also print the return value of the sleep function. Maybe that interrupt is triggering it so it returns early?

[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 ) 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.

[ben999]

@rejoe2 oooooooooh great! thanks a lot, exactly what i was looking for !!!

[rejoe2]

@ben999 You are welcome

[pintman]

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?

[cashew75]

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]

Have you tried another controller like mycontroller?

[cashew75]

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

pls post the code that is not working

[cashew75]

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

[pepson]

Anybody has sketch for sensors dallas DS18b20 with identify it with ID Dallas ?
And i can change value 16 to more sensors ? Example 20 ?

[APL2017]

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?

[mfalkvidd]

@apl2017 if I'm looking at the same sketch as you are looking at, the metric variable is never used. getControllerConfig() is used to fetch the controller's metric setting instead.

[gniazdoj]

@Rene046
Hi guys

Hi
can you advice how to manage Domoticz to display 2 decimals under Temperature sensors page, when following line MsgTemp.set(temperature,2) I can see on arduino serial monitor, mysensors sent 20.75 value, the same value i can see under child item with Hardware tab but not on sensor where 20.75*C is rounded to 20.8. its fine for general log but i want to have stable temperature for heating system. I have added code to count average from last X records like 20 or 40 with 0.25 steps, this stabilize Heating system and protect it against on/off to frequently.
Additionally when i use JSON it will present proper value under sensor page, same with ESPEasy and 2 decimal configuration on ESP.
do you know how i can changed domoticz to force him to present 2 decimals?

Mysensors 2.3.1/2.3.2
Domoticz 4.10717
raspberry pi

Thank you
Jakub

[kimot]

Domoticz globally or only with MySensors ?
My Domoticz is the same version like yours.
Temperatures from ESPeasy are with two decimals on Temperature sensors page, but on devices page only one decimal.
Exactly the opposite like you wrote.