I would target UART. I’m pretty sure there is no way to create “server” components in ESPHome for the likes of I2C or SPI.
You will have to device your own “protocol”, though. See Lambda Magic — ESPHome for pointers using uart.
I would target UART. I’m pretty sure there is no way to create “server” components in ESPHome for the likes of I2C or SPI.
You will have to device your own “protocol”, though. See Lambda Magic — ESPHome for pointers using uart.
Thanks for the link to the Lambda Magic. I’m aware of Lambda, but I had not seen that site. I’m quite new to create my own ESPHome code.
Yes, UART was my first thought too, but I wanted to ask an open question in case there is some clever function I don’t know about. ESPome have all kind of weird & wonderful things already built in!
But with UART it’s easy to add a RS232 level shifter circuit like MAX232 on each side to add some more robustness to the signal and avoid exposing the ESP32 I/O directly to the environment.
For “error correction” it will probably be enough here to go at low speed and just send the data maybe three times and only accept it if all three are the same.
A simple “protocol” maybe can be something like:
Anyone that has done something similar and is willing to share some code?
Did you look into just having one esp and say long wire runs to the greenhouse sensors from the pump one? Not sure how feasible that is and guessing you’ve thought about it but curious if/how that was knocked out.
Quick search…
To be honest, I’d put wireless and long-wires-in-a-wet-environment on the same level as far as expected reliability… To improve wireless reliability, I’d just put a cheapo dedicated router for that purpose.
Keep in mind that pure wired also implies hardwiring a way to upload firmware updates, no logging, … (unless you keep wireless for “non-essential” functions like this).
One ESP is of course the easiest way and something I have considered, but it will have some drawbacks in my opinion.
My experience is that a proper installed hardwired connection hardly never can beat wireless. Well ok, maybe hardwire isn’t the best chose for space flights then…
However, as it looks like there is no easy “of the shelf” solution to handle hardwired signals between two ESPHome I’m starting to thinking on a plan B for wireless, at least to start with:
Problem 1: Flooding
The biggest fear is that the stop/shut off command not will be received and causing a flooded greenhouse.
Solution 1: Hart beat
This can probably be handled in a way where the “pump ESP” only open the water valve for a short time. That means the “greenhouse ESP” must resend that trigger as long it’s requesting for more water. This will acting like a hart beat / watchdog and stop the water if the signal for some reason is lost.
Problem 2: Drying / HA down
I will have the automations local in the ESP not being dependent of Home Assistant running.
Is it possible for two ESPHome nodes to communicate and trig the water “hart beat” if HA is down but wifi is up?
Never used it myself, but ESPHome has a “web server” component that does just that
together with “http request”, I guess
That web server solution looks interesting, but I’m afraid that may me a little over my head to master, at least for the moment.
Thinking this over a little more during some grass cutting the last hours I may have a solution that hopefully will be both quite easy and reliably enough for my needs:
For now I think this will be the way I go, at least to start with.
Any obvious thought errors?
Honestly, if that’s over your head, UART will be worse
As both ESP will have the same logic, I don’t think you need the level shifter, but that’s a bit above my head
I’m not that deep into this new fancy web rubbish. I’ll stick to an good old trusted UART, like I used to in the -90s!
Well to be honest, it feels like a web server is a little to much and komplex for my needs, but I can be wrong. Could be worth to have a look at.
However, I will start with the UART trace as that (hopefully) will give me a system with both robustness and some flexibility where the core functions are working regardless of wifi, HA or any other surrounding systems, as long as I have 230VAC power.
You are absolutely right about that the level shifters are not needed from a signal level aspect, but it is not wise, and not a common praxis, to expose the “naked” I/Os to the world. Especially if the wires are long, like they will be in my case, the risk is quite high that the sensitive, high impedance 3,3V inputs will pick up some noise that can interfere or block the signal, or worse be destroyed by some electro static discharge (ESD).
Those risks can be reduced by using the MAX232 level shifter as they will boost the signal several volts (to RS232 level) and bring some basic ESD protection to it as well.
Not needed in theory or on the bench, but probably nearly a “must have” in the real world.
Are you comfortable with reading uart in ESPHOME? It’s a bit more involved than writing it.
Nope, not at all.
But until I know better I believe that the Magic Lambda Custom UART Switch example will do pretty much what I want - I hope!
As long as the interrupt pick up the receiving message and i don’t overflow the input buffer, I think it will be pretty straight forward.
We’ll find out…
Whats the hard part in your opinion?
If you’re comfortable with the custom sensor approach you should be fine. c++ scares me.
There’s this kind of thing too, which gives a good overview of the challenge and an alternative. I tend to use this approach to read uart.
That’s looks interesting. I may give that a try as well.
If you would make an effort to read the documentation, you’d quickly realize its not rubbish at all and it’s very simple to use.
Yes, now when I have a solution that I believe is right for my purpose, I will dig down deeper into the documentation and do some testing.
Your plan re uart and max232’s will work just fine. I’ve done exactly this and it works fine over long runs that I’ve tested up to a few hundred feet.
Yes, correct used RS232 is a fairly reliable and easy communication over reasonable distances.
How did you implement the readings?
@Pjoms it’s probably not be best/cleanest implementation but here’s a snippet of one of the switches on the receiver side:
- platform: template
id: text_switch_z2
name: "Text Switch 2"
lambda: |-
if (id(uart_readline).state == "1-Z2-ON") {
id(relay2).turn_on();
return true;
} else if(id(uart_readline).state == "1-Z2-OFF") {
id(relay2).turn_off();
return false;
} else {
return {};
}
I think I´m on something here that can have the potential to work.
This is what I have done:
The function is:
I have just tested this a little on the bench, but so far it looks good!
binary_sensor:
- platform: template
id: water_valve1
name: "Water Valve 1"
lambda: |-
static bool b_prohibit = false;
if (id(uart_readline).state == "OPEN_VALVE_1") {
if (b_prohibit == false) {
id(uart_readline).publish_state("");
b_prohibit = true;
return true;
} else {
return false;
}
} else {
b_prohibit = false;
return false;
}
filters:
- delayed_off: 5s
on_press:
then:
- uart.write: "Water ON\n"
on_release:
then:
- uart.write: "Water OFF\n"