@Paul-Scarbro There are multitude of solution, but since we are in MySensors Land, let's do a MySensors solution. You'll quickly see that doing that adds a lot of overhead.
We'll use an Arduino Nano or RF Nano if you're going to go whole hog. It can be run from 3.3V or 5V DC, not AC.
The reed switch would be connected to an input of the Nano and one of the outputs would drive a relay. The relay would drive the chime.
Your C++ program would be something like:
#define inputButton 2; // connect reed switch here
#define outputRelay 4; // connect relay to this pin see MySensors Relay example
#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
void setup() {
pinmode(inputButton,INPUT);
pinmode(outputRelay,OUTPUT);
// put your setup code here, to run once:
}
void loop() {
// put your main code here, to run repeatedly:
if (digitalRead(inputButton) == 0) {
digitalWrite(outputRelay,RELAY_ON);
wait(2000); // wait 2 seconds
digitalWrite(outputRelay,RELAY_OFF);
// now wait for door to close
while(digitalRead(inputButton) == 0) ; //does nothing until reed switch opens
}
}
There are some subtleties that I may have glossed over, but this is the gist.
By looking at the MySensors Relay example, you'll see how to integrate this into a MySensors environment. That's where you'd want to get the RF Nano.
I've made the assumption you're familiar with the Arduino IDE and you've looked into the MySensors environment.
@Knightan
I believe that your problem may be related to this block of code. See my thoughts as comments....
if (message.type == V_STATUS) { //This is true for all messages received
// Change relay state
state_1 = message.getBool(); //This sets state for state_1 to the received value.
digitalWrite(LED_PIN_Channel_1, state_1?RELAY_1_ON:RELAY_1_OFF);
// Store state in eeprom
saveState(CHILD_ID_5, state_1);
// Write some debug info
Serial.print("Incoming change for sensor: STATE 1");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
if (message.type == V_STATUS) {
// Change relay state
state_2 = message.getBool(); //This sets state for state_2 to the received value.
digitalWrite(LED_PIN_Channel_2, state_2?RELAY_2_ON:RELAY_2_OFF);
// Store state in eeprom
saveState(CHILD_ID_6, state_2);
// Write some debug info
Serial.print("Incoming change for sensor: STATE 2");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
It seems to me that state_1 = message.getBool(); AND state_2 = message.getBool(). So they both get set to the incoming value.
I think you need to not set both to the same value and instead differentiate them to unique values. I could be wrong as I have not had chance to do anything related to mysensors for a long time now - I also don't use Domoticz.
Have a look at the code on this page, it might help you a lot.... https://www.mysensors.org/build/relay
@nagelc said in New Setup for Home Environment Monitoring – Using NRF24L01+, Arduino Pro Mini, and BME280:
bme280
I read somewhere that the temperature sensor on the BME280 is sort of an afterthought. I did a few experiments comparing them to the DHT11/12/22 and found them only a little better. (Take this with a grain of salt, maybe you'll want to do you're own experiments.) I did do a lot of experiments with the DHT's and they really suck. +/-2°C Which turns out to mean +/-2°C offset (component variation) and +/-2°C measurement: +/-4°C from what the temperature actually is. My experience, yours may be better.
Please post your experience with OTA. I haven't tried it on Arduino's but it's awesome on ESP8266. I hesitate with Arduino's because I had some erratic behaviour running Arduino's when pushing the memory limit.
I, too, use the MQTT data transport to Home Assistant (HA) and I find that excellent. Getting data from HA is a bit tricky, but do-able. I have a flow meter and use HA to store the last read; meaning, if there is a power failure, HA sends the last read on Arduino boot. I don't use the EEPROM because that has a spec of 100,000 writes which the meter would do in about a year, thus, necessitating a new Arduino.
I truly appreciate you sharing. Thanks!
-OSD
