💬 Temperature Sensor

[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 :D

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

[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:grinning: .

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