I’m interested in installing an ESP rain sensor. Does anyone have any suggestions? 
Thanks in advance!
This depends a bit what you are trying to measure, i.e. rain rate, accumulated rain or simply detect that it rains (most likely other cases as well).
This one is at least supported in the standard ESPHome package; Hydreon Rain Sensor — ESPHome ($60-100)
Note that with any open source project like this there are a lot of developers out there creating custom components that i.e. supports additional sensors/actuators etc. So just go googling! Also
Myself I have a few of these cheap ( < $1) and simple detectors 1 stücke Wasserstands ensor Sensor zur Erkennung der Flüssigkeits wasser tropfen tiefe - AliExpress 502 lying around, but have yet to integrate them. It is a super simple analog device that I assume can be easily read by the ADC sensor component: Analog To Digital Sensor — ESPHome . No clue of how well they perform, but my expectations are on the very low side 
I went this way:
Yes, this seems like a variant of the cheap sensor board I linked, but difference is (guessing) that with your rain sensor you will get a true or false, but with the one I linked; an analog signal where it might (?) be possible to detect light vs heavy rain.
How well would you say the sensor module itself is working? And how well does the sensor board hold up over time being wetted?
BRG
@seime you are right. There is rain sensor and rain sensor
I guess we should talk about rain presence or rain measurement.
The solution I linked is a rain presence, indeed providing only a RAIN or DRY state.
It is already very helpful to get alerts, close/open shades etc…
I made and installed 2 sensors around the same time I made the post so it is not very long ago (a little over 2 months at the time of writting) and it is early to tell how good it will behave over time.
I made a 3D Printed enclosure, without paying much attention to the waterproofing more than making sure the opening are on the lower side.
So far it has been working pretty well. Rain detection is very fast, going back to the DRY state lags a bit behind since the sensor needs to dry out but it is also useful to prevent a drop to trigger the RAIN state, the drop dripping away, and the sensor suddenly claiming it would be DRY… until the next drop shows up.
So the way you install the sensor (ie the angle of the sensor) is rather important.
Price/size and simplicity are unbeatable. I guess a ESPHome solution would work well too, the only issue would be the battery life as those Sonoff seem to be pretty efficient.
I’ve finally started with this project. I think I correctly flashed the ESP32, and I added it in openHAB. But something’s wrong.
This is the yaml code (sensitive info hidden, of course) I flashed contains this:
esphome:
name: haard-eetkamer
esp32:
board: az-delivery-devkit-v4
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
password: ""
encryption:
key: "(key I copied from https://esphome.io/components/api.html#configuration-variables)"
ota:
- platform: esphome
password: ""
wifi:
ssid: "My wifi network"
password: "The password for my wifi network"
manual_ip:
# Set this to the IP of the ESP
static_ip: 192.168.1.130
# Set this to the IP address of the router. Often ends with .1
gateway: 192.168.1.1
# The subnet of the network. 255.255.255.0 works for most home networks.
subnet: 255.255.255.0
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Haard Eetkamer Fallback Hotspot"
password: "The password"
captive_portal:
switch:
- platform: gpio
pin: GPIO13 #D7
name: "IN1"
id: IN1
- platform: gpio
pin: GPIO27 #D6 ## The initial instructions were GPIO12, but the esphome wizard said "WARNING GPIO12 is a strapping PIN and should only be used for I/O with care. Attaching external pullup/down resistors to strapping pins can cause unexpected failures.", so I chose another pin...
name: "IN2"
id: IN2
- platform: gpio
pin: GPIO14 #D5
name: "IN3"
id: IN3
- platform: template
name: "haard_eetkamer_zomer"
id: haard_eetkamer_zomer
turn_on_action:
- then:
- switch.turn_on: IN1
- switch.turn_on: IN3
- delay: 2s
- switch.turn_off: IN1
- switch.turn_off: IN3
- switch.template.publish:
id: haard_eetkamer_zomer
state: ON
turn_off_action:
- then:
- switch.turn_on: IN1
- switch.turn_on: IN2
- switch.turn_on: IN3
- delay: 1s
- switch.turn_off: IN1
- switch.turn_off: IN2
- switch.turn_off: IN3
- switch.template.publish:
id: haard_eetkamer_zomer
state: OFF
- platform: template
name: "haard_eetkamer_centervuur"
id: haard_eetkamer_centervuur
turn_on_action:
- then:
- switch.turn_on: IN2
- switch.turn_on: IN3
- delay: 1s
- switch.turn_off: IN2
- switch.turn_off: IN3
- switch.template.publish:
id: haard_eetkamer_centervuur
state: ON
turn_off_action:
- then:
- switch.turn_on: IN1
- switch.turn_on: IN2
- delay: 1s
- switch.turn_off: IN1
- switch.turn_off: IN2
- switch.template.publish:
id: haard_eetkamer_centervuur
state: OFF
- platform: template
name: "haard_eetkamer_aan_winter"
id: haard_eetkamer_aan_winter
turn_on_action:
- then:
- switch.turn_on: IN1
- delay: 1s
- switch.turn_off: IN1
- platform: template
name: "haard_eetkamer_uit_winter"
id: haard_eetkamer_uit_winter
turn_on_action:
- then:
- switch.turn_on: IN3
- delay: 1s
- switch.turn_off: IN3
I added an item linked to the channel for IN1 just to test if everything works. It kind of does… When booting the ESP32, the LEDs on the relay module turn on for IN1, IN2, and IN3. But according to my openHAB item, IN1 should be off. If I turn the openHAB switch on, the LED on the relay module goes out…
I created an item for haard_eetkamer_zomer. Switching it, also does the opposite of what I would expect: switch.turn_on: IN1 makes the LED go out, and switch.turn_off: IN1 makes the LED go on again…
I “shut down” the ESP32 (which can only be done by unplugging the power, right?), switched the openHAB IN1 to ON and rebooted the ESP32. The openHAB switch stayed ON, but when I turned it OFF, nothing happened on the relay board. Turning the switch back ON, made the LED go out again.
Am I misunderstanding how the relay module works? Does the LED light indicate the relay is OFF and vice versa? That looks illogical… Are the signals for some reason inverted? Why? But if so, I assume that’s easily fixed with an addition to the yaml code? (However, that seems like fighting symptoms rather than the disease…).
Thanks for your input!
Away from pc, but I had this problem as well. First thing to check is if the relay module is active low or active High. You want the first or you might have to add a transistor to get a 5v signal to pull the signal high (io pins use 3.3v logic and it wont produce a signal strong enough to trigger relay.). Some relay boards have a jumper to select this.
Also be aware of pin options available such as inverted an internal pullups/pull down resistors to avoid a “floating” pin.
Also check the gpio docs on esphome.io for more options and details.
Happy hacking 
How would I check that? This is all the info I have: https://www.amazon.com.be/dp/B07GXBSX58/ref=pe_43847721_689504491_TE_item
Would that then mean the relays aren’t ‘clicking’? Because I can hear them click…
Looks like a familiar board.
Try the inverted: true attribute in the pin config in the yaml.
Brg
1 Like
It looks like that’s working!
But I’m stuck somewhere else… I’m not sure which pins to connect. The fireplace guy said to connect pins GPIO12, GPIO13 and GPIO14 to the relay module, but the esphome CLI wizard said pin GPIO12 was a strapping pin, so I changed that to GPIO27.
Now I just read this in the manual (ESP-32 Dev Kit C V2_EN.pdf - Google Drive) of the ESP32 board I bought (ESP-32 Dev Kit C op az-delivery.de):
Some GPIOs change their state to HIGH or output PWM signals at boot or reset. This means that if outputs are connected to these GPIOs this may get unexpected results when the ESP32 resets or boots. GPIO1, GPIO3, GPIO5, GPIO6 to GPIO11 (connected to the ESP32 integrated SPI flash memory - not recommended for use), GPIO14, GPIO15.
In addition to this, I want to link a MAX6675 temperature sensor to the same ESP32 board I want to connect the relay module to (MAX6675 Temperatur Sensor mit Sonde K-Typ und Jumper Wire für Raspberr). And this is what I found about that module:
- a Russian guide which talks about MISO, CLK and CS
- a guide in English which does the same, but with other pins
- It of course needs power. My ESP32 board has a 5 V output, a 3.3 V output and three GND pins… The temperature sensor should work with 3.3 V, but does it matter which GND pin I use? I can’t imagine the 5 V and 3.3 V on the same GND is okay…? But then again, why are there three GND pins, and isn’t it clear which one should be paired with which Volt out?
Here’s the “pinout” overview from the ESP32 I bought: https://cdn.shopify.com/s/files/1/1509/1638/files/ESP32_DevKit_C_V4_Pinout.pdf?v=1615364529.
I’m in over my head with all the pin categories… If someone who understands more can tell me which pins to use, that would be great.
Thanks!
Check out MAX6675 K-Type Thermocouple Temperature Sensor — ESPHome. many pins will work, and you have many to choose from .
The Esp can configure to a certain extent which pin on the board does what. Esphome handles this for you based on the yaml file. Many pins can be used for general io (gpio) , but things like the builtin uart(s ) and adc(s) have some limitations.
In general as you have noticed Try to avoid the strapping pins. They might work in a particular case or not. Depends on what you connect them to.
All gnd pins are connected, does not matter which one you use.
Happy hacking!
2 Likes
Isn’t GPIO5 regarded a strapping pin, according to the documentation I quoted? But it’s also the SS pin. That seems like a conflict?
Yes, so just pick another unused one that is gpio, update the yaml and move the wire to the corresponding pin😀.
Dx, Sx, GPOIx are all just aliases for physical pins on each particular board, so ensure you have used the correct board identifier whenever you create a new setup (seems like you have).
Using a strapping pin for reading a sensor might work just fine as the communication Protocol is set up afterwards, but for an actuator on a direct gpio signal it might trigger some physical activity during power up.
Remember that Esphome supports different boards and processors, so which pins to use isnt fixed at all and depends on your use case. My personal experience is to always to connect hardware items with DuPont wires first and verify everything works with the Esphome configuration before I heat up the soldering iron 
.
But if GPIO5 is the SS, didn’t the board developer envision this conflict? 
But you’re saying any pin can be the SS pin? There’s no hardware difference?
Strapping pins control boot modes such as flashing etc, but again; (most) pin functionality can be reprogrammed inside the esp32 chip itself. Think of it like an internal switch board . Just pick a non strapping pin if you can.
Google esp32 strapping pins for info on each one
Arne
So if I go with this, that is ok?
[...]
switch:
- platform: gpio
pin: GPIO13 #D7
name: "IN1"
id: IN1
inverted: true
- platform: gpio
pin: GPIO27 #D6 ## The initial instructions were GPIO12, but the esphome wizard said "WARNING GPIO12 is a strapping PIN and should only be used for I/O with care. Attaching external pullup/down resistors to strapping pins can cause unexpected failures.", so I chose another pin...
name: "IN2"
id: IN2
inverted: true
- platform: gpio
pin: GPIO33 #D5 ## The initial instructions were GPIO14, but according to the manual, that is "HIGH" on boot, so I chose another pin.
name: "IN3"
id: IN3
inverted: true
[...]
spi:
miso_pin: GPIO19
clk_pin: GPIO18
sensor:
- platform: max6675
name: "haard_eetkamer_temperatuur"
cs_pin: GPIO32
update_interval: 5s
… even though the documentation of my ESP32 says stuff like this:
… and gives thin pin scheme:
Correct?
what happens if you try it? i.o.w.: just plug it in, the biggest problem you can get is an error message
Aha. My fear was that the biggest possible problem was device destruction.
@seime I have just moved 6 of my esphome devices from MQTT to your binding. It is working great. Thank you!
1 Like
I’m struggling to get some RGBCT bulbs I have working properly with the Native API.
They are set up like this in their ESPHome YAML…
light:
- platform: rgbct
id: rgbct_light
name: "RGBCT_Bulb"
restore_mode: ${light_restore_mode}
red: red_output
green: green_output
blue: blue_output
white_brightness: white_output
color_temperature: ct_output
cold_white_color_temperature: 153 mireds
warm_white_color_temperature: 500 mireds
color_interlock: ${color_interlock}
on_state:
- script.execute: publish_state
The part I’m having the most trouble with is figuring out how to properly set up an Thing/Channel/Item/whatever for the color mode (“rgb” or “ct”) and, when it “ct” mode, the color temperature (between the min and max).
Does anyone happen to have any examples of how to do this cleanly?
(I have it working fine right now with mqtt channels, but it feels a bit clunky to do it that way, and I’m slowly transitioning all my mqtt-based ESP devices to ESPHome and the native API binding.)