Home assistant support (feature request)
itsboo07 opened this issue · 43 comments
Hi thanks for this wonderful project. How to get this work in home assistant without espnow hub. can you try to make this work on esphome instead? i know mqtt should do for now but hoping for some better ideas. and also try to make tutorial video and working in yt . this project is lit🔥 and needs many attention and popularity ❤️💯
Hmmm, ESPHome is a good idea but I'm not really experienced with ESPHome, all I've done is to set up an ESP Wemos D1 as a light level sensor.
Without the ESP hub I don't know what the message protocol would be to HA.
I will have a think about it.......see what can be done.
thanks here are the reference of deep sleep in ESPhome. may be if you can help i can try.
https://esphome.io/components/deep_sleep.html
As it stands, version5 cannot be used inthe deep sleep mode as GPIO16 isn't connected to the reset pin so it can't wake itself up, the whole idea behind version 5 is that it is completely powered down in between being triggered to give a very long battery life.
The earlier versions (Version 3) of the sensor can be used in this way though so may be more compatible with ESP Home but the battery will not last nearly as long but if you use a full size 18650 you can still get a long run time.
As it stands, version5 cannot be used inthe deep sleep mode as GPIO16 isn't connected to the reset pin so it can't wake itself up, the whole idea behind version 5 is that it is completely powered down in between being triggered to give a very long battery life.
The earlier versions (Version 3) of the sensor can be used in this way though so may be more compatible with ESP Home but the battery will not last nearly as long but if you use a full size 18650 you can still get a long run time.
thanks...instead can i use the same v5 circuit and instead of Espnow code...i will flash a mqtt or EPShome code which sends data and turns off by pulling LDO low. will this work?
Yes that should work although I don't know enough about ESPHome to say it will work but it probably will.
Am I right when assuming that deep sleep mode is no longer necessary as you power down the entire mcu?
Besides this I also would appreciate very much to see an ESPhome-flashed version 5.
You did a great job, thanks!
Thanks, that's right deep sleep isn't needed with V5 as it powers down completely.
ESP Home may be possible but I don't know enough about ESP Home to try it but wouldn't use it purely because I want it to last a long time on a small battery.
I asked the question on the home assistant forum about adding ESPHome
Link to my post HA Forum
Good idea, thanks for this information. I keep my fingers crossed!
thanks . i tried with esphome which takes nearly 7-9 secs to boot and send data. i would say mqtt is much better than esphome but espnow is the best. only problem of Espnow is i have 5 door in my house and all are very far from each other. so one espnow receiver won't help. soo stuck with mqtt.
Ok, not the fastest! But it depends on what you want to achieve. To monitor a window it is acceptable for me. @itsboo07, would you please share your ESPHome code?
thanks . i tried with esphome which takes nearly 7-9 secs to boot and send data. i would say mqtt is much better than esphome but espnow is the best. only problem of Espnow is i have 5 door in my house and all are very far from each other. so one espnow receiver won't help. soo stuck with mqtt.
Great news, glad you got it working, it would be helpful too others if you could share you code, maybe even start you own github project?
@gadjet sure i will try to share esphome code later. im trying to test espnow receiver in esphome.
i guess i need to make some changes in espnow transmitter device to make it compatible with esphome?
https://deploy-preview-775--esphome.netlify.app/components/wifi_now.html
I was lucky to find a very helpful guy on home assistant community to write some appropriate ESPHome code. The code is compiled quite well but flashing fails because there is no connection to the ESPHome servr on my raspi (see picture of log file):
Maybe I am mistaken in der flashing procedure, or I soldered the wrong connections to the pcb.
When flashing, I did not connect the external battery (a 9 V battery) to the pcb. Only 3,3V from the FTDI-Adapter is supplied.
I push (and release) the flash button once before flashing. I connected RX to RX and TX to TX (crossing is done on the pcb?!)
@gadjet, can you please check my flashing-setup and my flashing-procedure? What is the reason for the failure flashing?
Hi,
Some pointers to help:-
- make sure you use an FTDI flasher that supplies 3.3v
- make sure the tx and rx are connected the right way FTDI rx to PCB tx etc.
- press the flash button before you add connect the FTDI and keep it pressed until the ESP is powered up.
- don't use external power supply while flashing
One other point, you mentioned powering fro a 9v battery, check the LDO can accept 9V input I can't remember what the spec. was
The LDO will be OK with 9V but the logic gates are powered direct from the battery and they may not survive 9V, I think 6V is their limit
I checked the LDO before but did not for the logic gates, so they will be smashed. Then I have to solder the second pcb (I ordered 10). Ths issue but can not be the reason for the flashing issue, can it?
I just tried flashing again, keeping an eye on the points you mentioned in your previous post. It did not work.
One issue I've had in the past is the solder connections on the esp12 to the PCB, make sure they are good with a good magnifying glass
Does the blue LED on the Esp12 light up at all?
I just tried flashing again
looks like either esp is not powered or gpio0 is not pulled down to gnd. what I can recommend is you can you flash esp first before soldering to the pcb and later you can update code wirelessly. also try to use esphome legacy way of installation.
and more over to test first. try flashing a blink sketch with pin 2(pin 2 coz esp12 should have boot led attached internally wth pin 2) in arduino ide and see if esp gets flashed and works.
I stopped working with esphome and instead made some working progress with espnow which is much better with less power consumption and very low latency (200ms) and boot time. esphome takes around 7 seconds.
Have you tried checking the continuity between the supply pins and ESP pads and made sure that whwn the flash button is pressed the GPIO0 is grounded?
I will follow all your points at the weekend.
Meanwhile please have a look at the ESPHome code from @mulcmu, which he has shared on home assistant community https://community.home-assistant.io/t/esp-home-door-sensor-with-my-own-module/506004/5?u=chincilla
I just checked the connections and pin 1 (square pad should be connected to the RX pin of your FTDI, in the picture you have labelled it RX so if that's RX of the FTDI then that's right.
Yes, I confirm. Because on the pcb this square pad is connected with GPIO1 (TX) of the ESP12. Thanks for clarification.
I am trying to flash the ESP12 separated from the pcb. But it turns out not to be so easy. I am struggling with my breadboard, additional wirings at the ESP with pull-up and pull-down resistors, flash button, reset-button and so on...
I found a source with good advices:
https://www.mischianti.org/2021/05/08/esp12-esp07-esp8266-flash-pinout-specs-and-arduino-ide-configuration-6/#google_vignette
but it will take me some time to come back and report.
@altacoon you don't need a 3d printed case to program esp12 separate instead you can use a 2mm berg male strip and solder jumper or necessary pins to the breadboard for required pull-up and pull down. also you don't need reset . you can just pull down gpio0 for programming and remove gpio0 from gnd and repower the esp.
Glad you got it flashed although I can flash mine whilst on the PCB so not sure what the issue you're having is!
Definitely hope it works OK with ESP home please leave your feedback here and thanks for keeping us in the loop.
I found a bad solder contact at the flash button, meanwhile it is resolved from the pcb.
The sensor is working!
Window is closed an will be opened (node is offline, magnet fixed to the reed switch): When I remove the magnet from the reed switch, the node goes online after 12 s. And goes offline after 35 secondes more.
Same when I close the window (node is offline, magnet removed from the reed switch): When I fix the magnet to the reed switch, the node goes online after 12 seconds and goes offline again after 35 seconds more.
This is the behaviour with mulcmu's ESPHome code (see code in my former post). Sure it can be optimized.
I'm not so sure how much can be optimizer to be quicker besides the 5 second delay in the boot. My intent was to have a bigger than needed delay for troubleshooting so there was a window to initiate an OTA update.
How long is the ESP energized with the ESP-NOW code for comparison?
With espnow is around 300mS from power up until powerdown
Just to clarify: The cycle time I reported was the state change of the node I can observe within my home assistant ESPHome integration. I did not measure the power-on/power-off cycle time of the node itself.
@mulcmu, can I drop these "on_boot-lines" completly from the code as it is obviously running correctly? Or only the delay?
- wait_until:
condition:
api.connected:
- delay: 5s
- switch.turn_off: power_latch
Not to forget: Thanks again for your code, @mulcmu!
I'm glad the yaml config worked out to test it. I was expecting issues with the power_latch staying energized while the esphome code loaded but seems like that worked as expected.
The -wait_until is needed to keep the esp powered until HA connects to the device. I'm not certain but the way I believe it works is HA initiates the connection so the amount of time is variable for this to happen. Until HA connects, the esphome device can't publish any updates to HA.
The - delay: 5s could likely be shortened but not eliminated. This delay give the esphome device time to send the updates to HA before the power_latch is turned off. There might be some c++ code that could go in a lambda to force the update or wait until the updates are done.
The implementation using ESP-NOW is 100 times faster ( 0.3 seconds vs 30 seconds). I don't see any way the esphome implementation will get anywhere close to that. The longer run time will impact battery life dramatically and introduces an issue for handling transitions of the reed switch that are faster than the esphome device can boot and send the data.
I think focusing on a ac powered gateway to translate the ESP-NOW messages to HA is a better approach. A single ESP with a serial connection plugged into the HA server would be most direct. A two ESP gateway could use ESPHome for the HA connection with a UART link to the other ESP sending the ESP-NOW packets.
My current solution is to have an ESP plugged into a raspberry pi running node red and then sending door status via MQTT (along with other sensor data) which is then picked up by HA running on another Pi, I plan to integrate it all on to one Pi when I get around to it.
Extending battery life was my primary goal.
@mulcmu, thank you for the detailed advice. I will then reduce the delay step by step. I understand ESP-NOW seems to be the faster solution, but for the time being I am very glad to have this project proceeded successfully so far- with your kind help, @gadjet and @mulcmu! I will now focus on modifying @gadjet's case, run the sensor in real life and observe the battery lifetime. I have to modify the case because I think of using two button coins 2032 als external power supply (let's see how long they work).
ESP-NOW stays in my brain, but as there is yet no simple HA integration, it will be a long road for me to built up a setup like gadjet describes.
Two 2032 cells !! you might get a few days depending on usage, have a look here to get a calculation https://battery-life.of-things.de/battery-life-calculator.php?_sm_au_=iVVs1n3SWZ18TfTFkj0BvKQs47RR6
Quick calc shows 72 days if the capacity of the battery is 200 mAh with 10 hours in between usage so not as bad as I thought.
With ESPNow it works out as 1400 days
Ok, this is not really satisfying. I will think about it. The LiPos you are using are currently out of stock, I only found this one https://www.amazon.de/gp/product/B09NL3534F/ref=ewc_pr_img_1?smid=A1CTK3ECWVKPGM&psc=1
Perhaps I have to switch to 2 x CR123 batteries.
But by the way: Is your ESP-NOW setup depending on the ESP-cloud in any way or is it running in a completely local surrounding?
Hi, I have started to use Cells from discarded Vapes, a friend of my son gave me 20 used ones and I removed the cells, I have some 550mAH ones and some 1500mAH ones, I designed a new enclosure for the 550mAH Cell size.
ESP-NOW is purely a device to device protocol it doesn't even use the router so definitely a local communcation method and no cloud at all.
Sorry to jump in this conversation like this, but i think it's a trivial task to create an esp receiver for esp now protocol, isn't it... I think it's then possible to make an integration with home assistant in some way. If using raspberry we can tie GPIO from esp to raspberry's gpio, power consumption is not an issue there since it's hooked up to raspberry. Serial communication is surely an option as well. It does require an additional board, but it's stupidly easy to make. Just assign different ID's to the various door sensors and expose them as serial binary sensors.
Yes, I just plug an ESP07 with extrernal antenna into the USB of the Pi and then use Node red to convert data to MQTT messages which I then pickup with HA.
I am running the window sensor now with a 850 mAh-Lipo battery. It fits in your box (with small modifications).
It turned out, that the ESPhome code leads to a problem: I reported that the sensor needs about 10 s to go online then pushes his information and finally shuts down after 25 to 30 s. The state change of the reed switch within this 30 s-period is not transmitted to ha. (@mulcmu, you did foresee this in a previous post).
Does anybody has an idea how to solve this?
Could solve this meanwhile by adequate configuring a template binary sensor, triggered by state change.