💬 Temperature Sensor
-
I just tried this today but get an error. Here's the output.....
Arduino: 1.8.3 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
In file included from C:\Users\captain\Documents\Arduino\MYS-HW-CH\MYS-HW-CH.ino:37:0:
C:\Users\captain\Documents\Arduino\libraries\DallasTemperature/DallasTemperature.h: In function 'void loop()':
C:\Users\captain\Documents\Arduino\libraries\DallasTemperature/DallasTemperature.h:252:13: error: 'int16_t DallasTemperature::millisToWaitForConversion(uint8_t)' is private
int16_t millisToWaitForConversion(uint8_t); ^MYS-HW-CH:85: error: within this context
int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
^exit status 1
within this contextThis report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.THis is MYS 2.1.1 installed so a bit baffled as to what is causing the problem, it should just work, right?
Anyone with any insight please let me know! :)
-
I just tried this today but get an error. Here's the output.....
Arduino: 1.8.3 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
In file included from C:\Users\captain\Documents\Arduino\MYS-HW-CH\MYS-HW-CH.ino:37:0:
C:\Users\captain\Documents\Arduino\libraries\DallasTemperature/DallasTemperature.h: In function 'void loop()':
C:\Users\captain\Documents\Arduino\libraries\DallasTemperature/DallasTemperature.h:252:13: error: 'int16_t DallasTemperature::millisToWaitForConversion(uint8_t)' is private
int16_t millisToWaitForConversion(uint8_t); ^MYS-HW-CH:85: error: within this context
int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
^exit status 1
within this contextThis report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.THis is MYS 2.1.1 installed so a bit baffled as to what is causing the problem, it should just work, right?
Anyone with any insight please let me know! :)
@skywatch just follow the instructions on the build page:
This example uses a modified version of the external DTH library, which is included in the MySensors external examples. Please install it and restart the Arduino IDE before trying to compile.
-
-
Hi,
I have only one sensor on the mini pro and I have this in the logs:
2017-07-30 14:41:28.492 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.497 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.501 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.506 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.510 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.515 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.521 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.526 (Mysensor) Temp (Congélateur)Sleep time is set to 60000ms, why the time between 2 messages is around 5ms???
-
Hi,
I have only one sensor on the mini pro and I have this in the logs:
2017-07-30 14:41:28.492 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.497 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.501 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.506 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.510 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.515 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.521 (Mysensor) Temp (Congélateur)
2017-07-30 14:41:28.526 (Mysensor) Temp (Congélateur)Sleep time is set to 60000ms, why the time between 2 messages is around 5ms???
@Digdogger it can depend on a lot of things. The best way to know is to look at the debug logs from the node and the gateway from the time when it happened. There could be a problem with the communication, with the radios, with the power supply, with the sketch, etc.
It could also be that you're using a microcontroller that doesn't support MySensors sleep, such as the esp8266. But it is just a guess. The information that's usually needed to troubleshoot is listed in https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help/
-
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 ?
-
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 ?
-
I must have gone mad then :ghost:
Check the loop()
The last closing curly--bracket is forfor (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 '}' token1-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()...:scream:
-
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) { #endifOnly 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.
-
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) { #endifOnly 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.
-
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!
-
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!
@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 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).
@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 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.
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