Posts made by karl261

How would you do this?Like this? I tried to move it to the setup function.
This is also a version I found using non blocking (millis()) code.

// if you uncomment this, you can get test and debug updates about everything the sensor is doing by using the serial monitor tool.
//#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24 // A 2.4Ghz transmitter and receiver, often used with MySensors.
// #define MY_RF24_PA_LEVEL RF24_PA_MIN // This sets a low-power mode for the radio. Useful if you use the verison with the bigger antenna, but don't want to power that from a separate power source. It can also fix problems with fake Chinese versions of the radio.
// #define MY_RADIO_RFM69 // 433Mhz transmitter and reveiver.
// Choose if you want this sensor to also be a repeater.
// #define MY_REPEATER_FEATURE // Just remove the two slashes at the beginning of this line to also enable this sensor to act as a repeater for other sensors. If this node is on battery power, you probably shouldn't enable this.
// Are you using this sensor on battery power?
// #define BATTERY_POWERED // Just remove the two slashes at the beginning of this line if your node is battery powered. It will then go into deep sleep as much as possible. While it's sleeping it can't work as a repeater!
//#define MY_RF24_PA_LEVEL RF24_PA_LOW
#define MY_PARENT_NODE_ID 99
#define MY_PARENT_NODE_IS_STATIC
#define MY_NODE_ID 8
#define MY_BAUD_RATE 9600
// LIBRARIES (in the Arduino IDE go to Sketch -> Include Library -> Manage Libraries to add these if you don't have them installed yet.)
#include <SPI.h>
#include <MySensors.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#define RELAY_1 4 // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define NUMBER_OF_RELAYS 1 // Total number of attached relays
#define RELAY_ON 1 // GPIO value to write to turn on attached relay
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay
//Added this nteger to avoid stupid collect2.exe: error: ld returned 5 exit status.
//It seems adding one or removing one (or plenty) solves the error.
//int stupidinteger=0;
//int stupidintegertwo=0;
//int stupidintegerthree=0;
// VARIABLES YOU CAN CHANGE
#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No. Can save battery.
#define ONE_WIRE_BUS 7 // Digital pin where Dallas sensor(s) is/are connected.
#define maxAttachedDS18B20 16 // Maximum amount of teperature sensors you can connect to this arduino (16).
const long measurementInterval = 10000; // Time to wait between reads (in milliseconds).
float tempThreshold = 0.1; // How big a temperature difference has to be before an update is sent. Makes the sensor less precise, but also less jittery, and can save battery.
//VARIABLES YOU PROBABLY SHOULDN'T CHANGE
#define TEMP_CHILD_ID 0 // for MySensors. Within this node each sensortype should have its own ID number.
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[maxAttachedDS18B20]; // creates an array to hold the previous temperature measurements for each possible sensor.
int numSensors = 0; // variable to contain the number of found attached sensors.
unsigned long measurementSleepTime = 0; // variable to store the calculated Sleep time if the node is battery powered.
bool metric = true; // Variable that stores if the sensor will output the temperature in Fahrenheit of Celsius. The gateway sends this preference to the node.
bool receivedConfig = false; // This is not used in the code, but perhaps MySensors requires this?
// Mysensors settings
MyMessage msg(TEMP_CHILD_ID,V_TEMP); // Sets up the message format that we'l be sending to the MySensors gateway later. The first part is the ID of the specific sensor module on this node. The second part tells the gateway what kind of data to expect.
void before()
{
sensors.begin(); // Startup up the OneWire library. It allows multiple sensors to talk over one wire (one pin).
for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) {
// Then set relay pins in output mode
pinMode(pin, OUTPUT);
// Set relay to last known state (using eeprom storage)
digitalWrite(pin, loadState(sensor)?RELAY_ON:RELAY_OFF);
}
}
void setup()
{
metric = getControllerConfig().isMetric;
for(int i=0; i<maxAttachedDS18B20; i++)
{
lastTemperature[i] = 0; //Pre-filling array with 0's.
}
sensors.setWaitForConversion(false); // requestTemperatures() will not block current thread
#ifdef BATTERY_POWERED // If the node is batter ypowered, we'll let Sleep take over the scheduling.
measurementSleepTime = measurementInterval;
measurementInterval = 0; // When the Arduino is asleep, millis doesn't increment anymore (time stops as it were). To fix this, we'll set the measurement interval time to 1, so that when the arduino wakes up it will immediately try to measure again.
#endif
//Serial.begin(115200); // for serial debugging.
//Serial.println("Hello world, I am a sensor node.");
}
void presentation()
{
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Maischen relay and Dallas non blocking", "1.0");
for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) {
// Register all sensors to gw (they will be created as child devices)
present(sensor, S_BINARY);
}
numSensors = sensors.getDeviceCount(); // Fetch the number of attached temperature sensors
for (int i=0; i<numSensors && i<maxAttachedDS18B20; i++) {
present(i, S_TEMP);
}
}
void loop()
{
// You should not change these variables:
static boolean dallasIsMeasuring = true; // Used to indicate when the time is right for a new measurement to be made.
static boolean dallasIsCalculating = false; // Used to bridge the time that is needed to calculate the temperature values by the Dallas library.
unsigned long currentMillis = 0; // The millisecond clock in the main loop.
static unsigned long previousMeasurementMillis = 0; // Used to remember the time of the last temperature measurement.
static int16_t conversionTime = 0; // Used to store the time needed to calculate the temperature from measurements.
currentMillis = millis(); // The time since the sensor started, counted in milliseconds. This script tries to avoid using the Sleep function, so that it could at the same time be a MySensors repeater.
// Let's measure the temperature
if(dallasIsMeasuring == true && currentMillis - previousMeasurementMillis >= measurementInterval) { // If we're not calculating, and enough time has passed, we'll start again.
dallasIsMeasuring = false; // We're measuring, so let's take it off our to-do list.
//Serial.println("Starting new measurement(s)");
previousMeasurementMillis = currentMillis; // Mark the time of the initialiation of this measurement.
// Fetch temperatures from Dallas sensors
sensors.requestTemperatures();
// query conversion time. Apparently it takes a while to calculate.
//conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
conversionTime = millisToWaitForConversion(sensors.getResolution()); // This is a modified version of the line above, to deal with the problem in the current Dallas library.
dallasIsCalculating = true; //Next step is to re-calculate the temperature again.
}
// Next, let's calculate and send the temperature
if(dallasIsCalculating == true && currentMillis - conversionTime > previousMeasurementMillis) {
dallasIsCalculating = false; // We're doing this now, so check calculating off the to-do list too.
for (int i=0; i<numSensors && i<maxAttachedDS18B20; i++){ // Loop through all the attached temperature sensors.
//float temperature = getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i); // Fetch the temperature form the current sensor
float temperature = static_cast<float>(static_cast<int>((metric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
//Serial.print("Sensor #");
//Serial.print(i);
//Serial.print(" says it is ");
//Serial.print(temperature);
//Serial.println(" degrees");
if(temperature != -127.00 && temperature != 85.00) { // Avoids working with measurement errors.
if (COMPARE_TEMP == 1 && abs(temperature - lastTemperature[i]) < tempThreshold) { // is the temperature difference bigger than the threshold?
//Serial.print(temperature - lastTemperature[i]);
//Serial.print("- difference too small, so not sending the new measurement to the gateway.\n");
} else {
//Serial.print(temperature - lastTemperature[i]);
//Serial.print("Sending the new temperature to the gateway.\n");
send(msg.setSensor(i).set(temperature,1));
lastTemperature[i] = temperature; // Save new temperatures to be able to compare in the next round.
}
}
}
// Both tasks are done. Time to wait until we should measure again.
//Serial.print("zzzzZZZZzzzzZZZZzzzz\n");
#ifdef BATTERY_POWERED
unsigned long quicktimecheck = millis(); // check how much time has passed during the measurement (can be up to 750 milliseconds), and then calculate from that how long to sleep until the next intended measuring time.
unsigned long sleeptime = measurementSleepTime - (quicktimecheck - previousMeasurementMillis); //How much time has passed already during the calculating? Subtract that from the intended interval time.
sleep (sleeptime);
#endif
dallasIsMeasuring = true;
}
}
// This function helps to avoid a problem with the latest Dallas temperature library.
int16_t millisToWaitForConversion(uint8_t bitResolution)
{
switch (bitResolution)
{
case 9:
return 94;
case 10:
return 188;
case 11:
return 375;
default:
return 750;
}
}
void receive(const MyMessage &message)
{
// We only expect one type of message from controller. But we better check anyway.
if (message.type==V_STATUS) {
// Change relay state
digitalWrite(message.sensor-1+RELAY_1, message.getBool()?RELAY_ON:RELAY_OFF);
// Store state in eeprom
saveState(message.sensor, message.getBool());
// Write some debug info
//Serial.print("Incoming change for sensor:");
//Serial.print(message.sensor);
//Serial.print(", New status: ");
//Serial.println(message.getBool());
}
}

Yes, the 10 seconds is, because I am using it to control the heating of a mash (beer). So I want the temperature (if it changed) to be sent very often.

The line with getControllerConfig() I have from the mysensors temperature sensor sketch example.

Actually my initial post has an error, maybe I can correct. Yes, the temperature should be checked every 10 seconds. But when the sensor failed it kept sending the same temperature every 6 or 7 minutes in the same interval. So not as specified by the sketch.

I am having trouble with a node. It is a combined Dallas temperature sensor with a relay.

Everything works fine, but after about a day the node starts to behave weird. Sketch attached.

Once it kept on sending the temperature, but did not react to requests to switch the relay anymore.
A power cycle did not help, maybe some capacitors were not fully empty, another power cycle and everything was back to normal.
Another time the same thing happened: The node kept sending the temperatures, but no reaction on the relay.
Another time it failed like this: It kept sending the same temperature over and over again, the true temperature was definitely different (so it was not reading the temperature from the Dallas). It just sent the same temperature, in some strange regular interval, every 7 minutes or so. No matter that the sketch only sends the temperature if it is different from the previous one. Also no reaction on the relay.

I do not know what happens, the node somehow works and operates and sends temperatures, but somehow gets confused. The issue is reproducible it seems, I just need to let it run for 24 hours or more.

Any ideas? Anything wrong in the sketch? Maybe some variable or number that is overflowing? Or the time or the Atmega (millis)?

It is a self built node with an Atmega328p running at 8 MHz with the internal clock. I have built other nodes like this some with 1 MHz that read the temperature around the house, all working fine. But totally different sketches.

Thanks very much in advance for any ideas!

// if you uncomment this, you can get test and debug updates about everything the sensor is doing by using the serial monitor tool.
//#define MY_DEBUG
// Enable and select radio type attached
#define MY_RADIO_NRF24 // A 2.4Ghz transmitter and receiver, often used with MySensors.
// #define MY_RF24_PA_LEVEL RF24_PA_MIN // This sets a low-power mode for the radio. Useful if you use the verison with the bigger antenna, but don't want to power that from a separate power source. It can also fix problems with fake Chinese versions of the radio.
// #define MY_RADIO_RFM69 // 433Mhz transmitter and reveiver.
// Choose if you want this sensor to also be a repeater.
// #define MY_REPEATER_FEATURE // Just remove the two slashes at the beginning of this line to also enable this sensor to act as a repeater for other sensors. If this node is on battery power, you probably shouldn't enable this.
// Are you using this sensor on battery power?
// #define BATTERY_POWERED // Just remove the two slashes at the beginning of this line if your node is battery powered. It will then go into deep sleep as much as possible. While it's sleeping it can't work as a repeater!
//#define MY_RF24_PA_LEVEL RF24_PA_LOW
#define MY_PARENT_NODE_ID 99
#define MY_PARENT_NODE_IS_STATIC
#define MY_NODE_ID 8
#define MY_BAUD_RATE 9600
// LIBRARIES (in the Arduino IDE go to Sketch -> Include Library -> Manage Libraries to add these if you don't have them installed yet.)
#include <SPI.h>
#include <MySensors.h>
#include <DallasTemperature.h>
#include <OneWire.h>
#define RELAY_1 4 // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define NUMBER_OF_RELAYS 1 // Total number of attached relays
#define RELAY_ON 1 // GPIO value to write to turn on attached relay
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay
//Added this nteger to avoid stupid collect2.exe: error: ld returned 5 exit status.
//It seems adding one or removing one (or plenty) solves the error.
//int stupidinteger=0;
//int stupidintegertwo=0;
//int stupidintegerthree=0;
// VARIABLES YOU CAN CHANGE
#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No. Can save battery.
#define ONE_WIRE_BUS 7 // Digital pin where Dallas sensor(s) is/are connected.
#define maxAttachedDS18B20 16 // Maximum amount of teperature sensors you can connect to this arduino (16).
unsigned long measurementInterval = 9250; // Time to wait between reads (in milliseconds).
//float tempThreshold = 0.1; // How big a temperature difference has to be before an update is sent. Makes the sensor less precise, but also less jittery, and can save battery.
//VARIABLES YOU PROBABLY SHOULDN'T CHANGE
#define TEMP_CHILD_ID 0 // for MySensors. Within this node each sensortype should have its own ID number.
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[maxAttachedDS18B20]; // creates an array to hold the previous temperature measurements for each possible sensor.
int numSensors = 0; // variable to contain the number of found attached sensors.
unsigned long measurementSleepTime = 0; // variable to store the calculated Sleep time if the node is battery powered.
bool metric = true; // Variable that stores if the sensor will output the temperature in Fahrenheit of Celsius. The gateway sends this preference to the node.
bool receivedConfig = false; // This is not used in the code, but perhaps MySensors requires this?
// Mysensors settings
MyMessage msg(TEMP_CHILD_ID,V_TEMP); // Sets up the message format that we'l be sending to the MySensors gateway later. The first part is the ID of the specific sensor module on this node. The second part tells the gateway what kind of data to expect.
void before()
{
sensors.begin(); // Startup up the OneWire library. It allows multiple sensors to talk over one wire (one pin).
for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) {
// Then set relay pins in output mode
pinMode(pin, OUTPUT);
// Set relay to last known state (using eeprom storage)
digitalWrite(pin, loadState(sensor)?RELAY_ON:RELAY_OFF);
}
}
void setup()
{
for(int i=0; i<maxAttachedDS18B20; i++)
{
lastTemperature[i] = 0; //Pre-filling array with 0's.
}
sensors.setWaitForConversion(false); // requestTemperatures() will not block current thread
#ifdef BATTERY_POWERED // If the node is batter ypowered, we'll let Sleep take over the scheduling.
measurementSleepTime = measurementInterval;
measurementInterval = 0; // When the Arduino is asleep, millis doesn't increment anymore (time stops as it were). To fix this, we'll set the measurement interval time to 1, so that when the arduino wakes up it will immediately try to measure again.
#endif
//Serial.begin(115200); // for serial debugging.
//Serial.println("Hello world, I am a sensor node.");
}
void presentation()
{
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Maischen relay and Dallas", "1.0");
for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) {
// Register all sensors to gw (they will be created as child devices)
present(sensor, S_BINARY);
}
numSensors = sensors.getDeviceCount(); // Fetch the number of attached temperature sensors
for (int i=0; i<numSensors && i<maxAttachedDS18B20; 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 = millisToWaitForConversion(sensors.getResolution());
// sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
// Serial.print("Library");
// Serial.print(" says its conversion time is ");
// Serial.print(conversionTime);
// Serial.println(" ms");
wait(conversionTime);
// Read temperatures and send them to controller
for (int i=0; i<numSensors && i<maxAttachedDS18B20; 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.;
// Serial.print("Sensor #");
// Serial.print(i);
// Serial.print(" says it is ");
// Serial.print(temperature);
// Serial.println(" degrees");
// 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
Serial.print(temperature - lastTemperature[i]);
Serial.print("Sending the new temperature to the gateway.\n");
// Send in the new temperature
send(msg.setSensor(i).set(temperature,1));
// Save new temperatures for next compare
lastTemperature[i]=temperature;
}
// else {
// Serial.print(temperature - lastTemperature[i]);
// Serial.print("- difference too small, so not sending the new measurement to the gateway.\n");
// }
}
wait(measurementInterval);
}
// This function helps to avoid a problem with the latest Dallas temperature library.
int16_t millisToWaitForConversion(uint8_t bitResolution)
{
switch (bitResolution)
{
case 9:
return 94;
case 10:
return 188;
case 11:
return 375;
default:
return 750;
}
}
void receive(const MyMessage &message)
{
// We only expect one type of message from controller. But we better check anyway.
if (message.type==V_STATUS) {
// Change relay state
digitalWrite(message.sensor-1+RELAY_1, message.getBool()?RELAY_ON:RELAY_OFF);
// Store state in eeprom
saveState(message.sensor, message.getBool());
// Write some debug info
//Serial.print("Incoming change for sensor:");
//Serial.print(message.sensor);
//Serial.print(", New status: ");
//Serial.println(message.getBool());
}
}

So, only the outdoor sensors fail. It is now more than one that failed.

I have one in the living room -- perfect.

And, very strange: I have one in the green house. Huge T differences, sometimes very hot, and often 100% humidity. Actually conditions should be worse for this sensor compared to the outdoor sensor. But: it is just fine.

Now after 2-3 month more outside the sensor seems to be finally dead. No reaction anymore. Also the 2nd one in the greenhouse does not reply anymore. I'll have to check. The one in the living room is fine.

It seems that at least the ones I bought are not really lasting long outdoors.

So, this story also continues. After having these problems, I brought the sensor into the house and left it running for the past several weeks in the living room. Actually it is working fine. No more problems.

Now, for Christmas, I have brought it back outside to the birdhouse. And it is still working fine, even at -10 °C. Let's see how long it will last this time.

What I also noticed is that now I have a second of these in the greenhouse where the humidity is definitely from time to time 100%. At 4°C. But both outdoor sensors somehow never reach 100%, but stop somewhere between 85-90%. It seems they are not made to detect 100% humidity.

The supercaps are needd because when the powerbank switches there is a short power interruption. The supercaps are buffering this.

The 5V voltage regulator is needed, because when the power bank is charging and discharging at the same time its output voltage drops to 4.6 V or so. The voltage regulator keeps this at 5 V at all times.

@AWI Ok, so the bosst converter has arrived. Now I have a stupid question: Should I add the boost converter before of after the caps? Somehow I cannot figure out the advantages / disadvantages of one or the other method.

The problem with my power bank is, that the voltage drops to 4.5 V when the power bank is charging. When I disconnect the power bank from its supply, the voltage is 5 V as expected.

@r-nox Hm, it is reading every 15 seconds at the moment. Do you think this is too much?

The current sensor is not completely broken, it seems. Sometimes it is showing "normal" values. I brought it into the house to test it, and in the house it seems to show normal values. I will know more tomorrow morning.

According to its specs it is supposed to be good for weather monitoring. But then, it seems it does not like "weather" too much.

I also found it strange that in the past 30 days the maximum humidity it read was 87 %. And for sure there were plenty of nights here with 100 %. But ok, I could live with that. But it has started to show far too low values for humidity, down to 0 %. I'll leave it in the house for 1-2 days and then see how it behaves outside.

It does not look that it was much longer time. But instead like the sensor before, the current one is now showing values between 0-22% humidity. T seems to be fine. That is SO disappointing. It seems that these things are not suitable for outdoor use. Lasted only a month...

@Mark-Swift Where do you see the failures? Do you have a log output?
The code is for mysensors 2.0.0. Did you adapt all the network specific #define in the beginning of the sketch to your network? In my example there is a static parent set and the static parent has the ID 99. If that does not exist, there will be failures.

For those who need and don't have a display like me, here is my sketch version for output to the serial console. So what I do is, I run around with a laptop connected to the node and watch the serial console, or, I just move around with a tablet and the node. The tablet is connected to my raspi and I watch the output of my gw on the pi using picocom. Picocom handles very well the missing line feeds in the output. The gw output is also very informative, there are no statistics, but still I see when stuff fails...

@AWI Ok, I got it working somehow, now with the original Keypad_I2C library, because it had the functions ready to write to the pins... But it needs some more tine tuning. And it does not work all the time, sometimes I need to reset the PCF, by disconnecting it from power and then restart the Arduino.

In the log below the first try does not work, the second try after reset it works.

@AWI I am trapped between "collect2.exe: error: ld returned 5 exit status" errors and non working sketches. This is the world of pain. I am tempted to give up. It just does not make sense. I like things that do make sense...

The interrupt is not working any more. At least I don't see it on the Voltmeter. The interrupt pin remains high all the time.

I think this is because to get the key pressed, the library is scanning through the pins and writes different high low states to the ports of the pcf. This kills again the interrupt functionality.

Yes, if I take out the loop function char key = kpd.get_key(); then the interrupt works again, because the library only writes 0xf0 and then it works. When the library is scanning, it does not work anymore.

maybe it is possible to write 0xf0 before going to sleep... Then it won't scan, just wait for the interrupt?

With the knew knowledge of 0xf0 writing I could also test the keypad_I2C library.

@AWI Ok, so far so good. If I connect 4 high wires to rows and 4 low wires to columns (or vice versa, no idea) then the interrupt pin indeed changes to 0. If I connect the interrupt pin of the IC to D3of the Arduino and then both through a pull up of 10 kOhm to Vcc, the interrupt is at 3.3 V. If I press a key it goes down to 0.040 V. That should be enough to read it as low.

@AWI yeah, I kind of thought the same. I'll try to have rows high and colls low and see if the interrupt pin finally triggers. I should have some pull up on the interrupt pin. Then I'll need to see if I need any pull up or down on the other lines..,

@ayo Hmmm I experienced this also Once with the default repeater node sketch. The radio failed completely when commenting out the my_debug.
However, it went away somehow, so I cannot debug it. It went away after several reuploads of the sketch. So maybe there was just something wrong during programming in my case...

@AWI ok, I guess you are right. I will do some more tests with grounded foil.

Actually I have some really nice and thick Al metal. I could use it to build some better permanent shielding of the module.

Actually I would like to give my repeater a metal enclosure. But it is built in a way that inside its case the 220 V are converted to 5 V. So I prefer the plastic case. I am too afraid that by some stupid failure there are 220 V on the case and somebody touching it. Hm, so maybe I should rebuilt the repeater with an external 5 V supply and a metal case.

@tbowmo No, it does not seem to be the humidity. Now in the evening that the temperature drops and the humidity rises I have quite regular readings.

Anyway, it's strange. Nobody is at home -- Conditions did not change. It did not work last night and during today (readings once very two hours more or less), but since the late afternoon I get readings every 10 minutes (as it is supposed to be). So: What is better now then it was last night and evening and during today? The moon phase???

@tbowmo I will observe. Today it is dry and there are still dropouts. But then for 20 m? with a +PA+LNA? I would expect this thing to go 100 m... Maybe a bad soldering point that is affected by humidity?

@Sander-Stolk I have exactly the same problem with my bird house node. It is about 20 m away from the repeater. Both are 1000 m radios and aluminium shielded. The repeater uses LOW setting. The birdhouse node used MIN for 3 weeks and worked fine, then the dropouts appeared, sometimes for a whole day there is no message coming through. The repeater is working fine, I tested it with @AWI's quality meter sketch. The birdhouse node is 10 times checked, it is ome of the "My Slim AA ..." nodes, very simple setup. I recently changed the radio setting to LOW, but same results, it works for a few hours then dropouts start.

Unfortunately I cannot advise you, just tell you that I have similar problems. I have no idea what to do, I discussed in detail with @Oitzu but I am still having dropouts.

I will need to do further testing if the repeater can reach the node, what is sure is that the node cannot reach the repeater.

@AWI Thanks. I am in the train now and I am spending my time to try to understand how things work. I also made some progress in my brain. My idea is similar, but you already have a sketch ready. I will try it out, I guess on Saturday. Until then I will try to deepen my knowledge of the libraries.

It is also possible with the "original" library, but you are right: the "new" library is much clearer.

@AWI Yes, basically, 4 inputs should be set to high in the library, and 4 inputs to low. Rows and columns. I had a look at the library examples yesterday, but so far it is beyond my programming skills. As far as I understand from all the docs this is theoretically possible.

Then, if done so, the pcf should detect a change in the low/high of the input pins and also detect what key was pressed. Or better the library interprets the received data by i2c correctly.

@AWI I don't recall that columns and rows have a different level. Of what I measured yesterday was that all 8 pins of the keyboard were at 3.3 V. So the only thing that happens is that there will be a connection made between column and row when a key is pressed. It seems that nothing is pulled up or down.

So you think the ic can do it? Then we have to re-program the library...

I put in an on / off switch. So before I type, I switch the whole thing on, wait until it registers with the gw, and then here we go. And then off. No need to sleep and wait for interrupts.

I can install a button device. So, the thing is sleeping, I press the button, the thing wakes up for 30 secs, that gives me time to type and send, and back it goes to sleep.

I have a 4x4 keypad. So, I don't need the ABCD. I could connect the ABCD in a way, that it acts like button device, so I can trigger the interrupt with ABCD, then type my number, and then it goes back to sleep.

Ok, in the end I am stuck. So, I got the keypad working, no problem. But I cannot get it to trigger an interrupt. The PCF8574 has an interrupt pin, but it seems this does not work with this keypad. Or at least I could not figure out how to. So, my keypad speaks I2C now, but still has no interrupt capabilites.

Can anyone advise?

If not I will need to build the circuit from @AWI. Btw, in that circuit, Are ALL resistors 10 MOhm?

@AWI No, I don't have an oscilloscope. Would be nice though. Searching the net it seems that other people who tried also see low voltages. I think these caps are responsible. If each cap has a voltage drop of 0.8 V then I easily get down to 4.77 V...

Well, I guess then I will change the BME280 to a new one and see how it goes. Let's see how long it lasts. If it is made for weather monitoring, it should withstand normal weather conditions if not exposed to rain???

@bjacobse Thanks for the advice. Indeed, looking at the API sometimes helps. But a sketch example is even better.

So, in case of the Ei Electronics 650C it is like this:
It has two pins for connecting wires. I found that terrific -- very simple. So, when there is no Alarm going on, there is 0 V on these two pins. If there is an alarm triggered, there are 5.6 V on the two pins. Sounds ideal. I figure, that I have to put also 5.6 V on these two pins to trigger the alarm from external.

But, where do I go from here? I usually use 3.3 V Arduinos. How can I wire this? Does a digital pin of a 3.3 V Arduino take 5.6 V? Or do I need a voltage divider?

Then, I guess I have to connect the + pin to let's say digital pin 3. Because digital pin 2 is used by the radio -- in case we are using interrupts in the future. And the - pin I connect to gnd. Is that right?

Then, I can use the reed switch sketch and try the interrupt thing from the API. Right?

I guess, when I set the 3.3 V Arduino D3 pin to high it will have 3.3 V, right? So I need to figure out if the Ei650C also triggers at 3.3 V. And if so, I would need to check that it is not drawing too much power from the pin. If it does not trigger, what to do? Sounds like using a 5 V Arduino.

How lonng would two AA batteries last if the Arduino was sleeping and the Radio was awake? With 2.0.1 radio interrupt will arrive and power can be saved.

Are the above assumptions correct? Nobody with a ready fire alarm sketch?

Edit: I love this fire alarm. It triggers at 3 V. Perfect. Can't believe it. The good thin about this model that is has one of these 10 year lithium batteries. I like that too.

@AWI Maybe it has to do with the box. Hm. Because I had another node out there, same sensor, and it was just hanging in the bird house protected against rain. And it still works fine. Still, there was no sign of any moisture in the box...

Hm.... I did not find any moisture in the box. So you think I need plenty of more holes? Hm, the sensor was directly behind the hole. On the picture one cannot see the sensor.

Rain normally cannot reach the box. But ok, I could think of something more special.

The housing on your photo, where can you buy it?

Another thing: if I protect the holes against insects, what would I use? Because I don't want to measure wet tissue or so. So it would be some synthetics. Or a fine mesh of something. But in this moment I have no idea...

I've been playing around with the bme280 for a while. I like this sensor, it seems to be very accurate and it is easy to install.

Now, one of them is running outdoors. It is in a plastic box, I made a little hole of 4 mm diameter in the box and placed the sensor behind the hole. I thought like this it is well protected. The sensor points north and it sits in an open bird house 2 m above ground. No rain should be able to reach the box and sensor.

However, recently I brought it into the house and noticed that the humidity is off by 15 %. Too high compared to all other bme280 and other sensors I have.

Could it have been damaged sitting outside?

I tried to recondition the sensor like written in the specs, but the humidity value is still too high.

That is bad news, because I cannot put a new bme280 every 3 weeks... That gets too expensive.

So, what to do? The Bosch specs clearly say it's ideal for outdoor weather monitoring. That is great, but how do I prevent this thing from showing wrong values?.

@marekd Great controller! For the keypad: I see from the code that you use the I2C code. How did you connect your keypad? Did you use a I2C extension chip? And, which keypad_i2c library do you use? I found multiple on the net.

@tekka Yeah, that's what I actually use. Since I normally don't move my sensors and repeaters, having the parent node static sounds like a good thing to do.

I look forward to the 2.0.1 release. There seem to be a lot of cool new things inside.

@tekka, @oitzu, Still, this nrf is driving me nuts. My sensor in the garden has worked just fine for three weeks, and nothing has changed. Now it makes problems. It is still running, because once per day one Temp reading or similar is getting through. Battery is just the same as before.

Do you have any idea why it could have stopped working? I don't see any reason why the repeater should stop receiving the values. The repeater works fine, it relays all other nodes. And the geometry between repeater and garden sensor has not changed.

@Yveaux So, basically this means that in the future we can have the arduino sleeping and when a message comes in it wakes up from the interrupt? Sounds like repeaters could run on battery then. If there is not too much traffic.

@AWI I have such a keypad 4x4 and I would like to use it with the famous my slim aa battery node. I think I understand your drawing. What I don't understand is what diodes do I need to use? I mean what type?

Also, if I was to include a green and red diode, or a bi-colour diode, what specifications would they need to have? Any links to the usual "shops"?

Total madness: I uploaded the same sketch again, and now it is using 99.

Questions:

Can I see in the log whether it "found" the parent or if it is using the parent I put into the sketch?

Is it possible to avoid this transport failure counter? Like, when I put
#define MY_PARENT_NODE_ID 99
#define MY_PARENT_NODE_IS_STATIC
into my sketch I just want the node to send, whether it reaches the parent or not. Is that possible?

@Oitzu Is that so? How could I find out if my nrf accepts the max setting? Maybe it is not using it at all. What is the default then? I also saw that @GertSanders was recommending to use the "high" setting as maximum. Maybe that is why?

@tekka yes, these fails come and go, I see them all the time, but not at the same place necessarily. The logs posted above show plenty of them.

I don't understand this radio trouble.,the distances between the nodes are not long. The radios are all connected using all tricks, the relay is a nrf24+pa+lna which is located in a good location... Maybe all radios are crap? There is only one wifi network and it is not very busy... It's my own. Maybe I should change the channel? 110 or so sounds good. I am using default now. Power is set to max for all nodes, the nrf24+pa+lna is shielded from itself, I put small antenna extensions on the normal ones after @petewill, they all have nice caps, gw and repeater have excellent power sources, ...

I found a script how to test nrf radios... Maybe I should try that?

If I was going to buy new radios, just to try, which ones are the best???

Edit: Hm, I think if I use antennas, it really helps if they all point into the same direction. Like all horizontal or all vertical. Which would make sens, wouldn't it?

@tekka Well, yes, I added the two lines you suggested, re-compiled, and then it was not using the 99. And also some posts above, I had these weird messages transmitted 6-7 times, see logs. This happend while MY_DEBUG was commented out.