I had good experiences with ESP-Now. The only downside: I never found a good way to bridge between ESP-now and WIFI ... Some claims are on the internet but they never worked out for me. So I wired two esp8266 via serial connection here.
Even espressive own github list this as ToDo GitHub - espressif/esp-now: A connectionless Wi-Fi communication protocol
Shame that ESP don't make a Zigbee version of the ESP32 
Won't be long Julian:
Thanks for sharing that, I had seen it previously but forgot 
Seems like people think that Expressif take at least 12m from announcement to early product. So hopefully we'll see something in Q3 this year.
Let's hope it is compatible with Zigbee2MQTT.
Going to be interesting to see how easy it will be to program it though and how any added programmatic capabilities can be exposed to the Zigbee protocol. I can't imagine that it will be as easy as previous ESP chips given the standards required in the Zigbee protocol.
For power distribution it depends on the locations of the devices really.
You may want more than 1 central PSU to keep the cable runs smaller, but also dependant on where you have Mains power available.
Using a higher voltage is good idea to reduce volt drop, I use some off the shelf 12V power supplies with battery backup (standard with alarm systems CCTV etc). Battery probably not need in most cases but can be handy if devices need to work in power cut (Before anyone asks my wi-fi is also on UPS)
I have a small multiway fuse board in the PSU end with fuses for each cable run, you can also do multidrop at 12V because the power requirments are small. I use cheap 4 core alarm cable. 2 core bell cable would also be OK.
Then I put a buck converter at the ESP end to drop to 5volts, and connect to 5V input on ESP.
The onboard regulator will provide 3,3V for the ESP and you also have 5V for sensors etc that need 5V.
A good shortcut I have used is to pickup power from an existing PIR if it is close by.
Right … until then I had the idea to look into something like this bit to be honest - not enough time to dig deeper
Does that power cable needs to be shielded, to avoid noise being picked up? Or is that perhaps somehow filtered at the end in the buck converter?
Bart - the easiest way is as Dave says - use mains powered cheap phone charger style units - and power these through a cheap USB A to micro USB cable.
If you do need Battery powered then you have a problem as i do not believe any of the custom firmwares (Tasmota etc) do not support deep sleep mode and you will end up having to build your own firmware and then maintain that on an ongoing basis.
I have done this in the past and what i did was to wake the unit every minute - leave the WIFI off and do all my work then compare various values and decide if i needed to wake the radio and send the result so in your case - you could keep a rolling average of pressure over the last 30 minutes (30 readings) and as each new reading comes in (each minute) compare it to the average - if it had not increased by more than 5 percent do not wake the WIFI and send it.
Every hour or so - you could wake the wifi and send the accumulated values for the last hour
If you are going to do this - hard code the IP address on each unit as it makes it make quicker to wake, connect to the AP, send and go back to sleep over using DHCP
Craig
@craigcurtin,
Seems all logical what you say... But indeed then it becomes a second development track, besides to my Node-RED nodes. So I assume I will try to do as much as possible with cheap phone chargers.
My entire setup is getting shaped in my head after a day of huge feedback from lots of nice folks in this community 
The XT-ZB1 is RISC based with an entirely different toolchain to the ESP's so I hope your C++ skills are up to it
ESPhome has a deep sleep module
Deep Sleep Component — ESPHome
Not actually used it myself as all of my sensor platforms are USB powered at present.
I have just used the cheap alarm cable without any issues.
But nothing to stop you using a screened cable (earthed only at 1 end of course ! )
I guess you could add a Decoupling capacitor at ESP also. But this is probably over engineering it 
Thanks guys for all the corrections for deep sleep mode - i did not think any of them were supporting it.
Might be worthwhile doing some experiments i was thinking of then !
Craig
The Wemos D1 Mini supports Deep-Sleep. I used a 15-minute value with our solar-powered weather stations and a 60-minute time with the battery monitor on my hybrid car.
The maximum deep-sleep time for the Wemos is 71 minutes.
I've found a 47uF and a 0.1uF (or 100nF) capacitors (in parallel) across the 5V or 3V3 supply rails helps to avoid the Wemos D1 Mini rebooting. They act as reservoir capacitors and avoid a sudden dip in voltage when the WiFi switches on (as this part of the circuit can draw 140mA).
I don't think I have ever noticed that problem to be fair, but can't do any harm.
Hello Bart,
I have now about 6 Wemos D1 or other ESP32 around my house. I usually power these devices via a Solar panel with a backup battery for overnight support. The solar converter is providing 5v USB and can handle several esp32/Wemos devices.
This works great for me as I do not have outdoor sockets!
I just found pictures one of my 6 constant current high power LED dimmer boards I build for my garden (as mentioned above).
powered by a 24V power supply (the transformer is inside a shed). You see the step down buck converter, a smoothing capacitor (think useless as the ripple I expected would better be smoothed by a small ceramic capacitor instead an electrolytic). 6 cc LED drivers (1-2W) with available enable PIN for PWM dimming. All berried under a foodbrige (this is where a good AP pays). Never had any issues (Even in this noisy environment of 6 dimmers and a switching buck converter)
So nothing fancy. (BTW: One downside of the ESP8266s. They come with now hardware timers for PWM signals. PWMs are generated in software! So keep the frequency down and expect some glitches. Nothing to be worried but good to know)
Not the best picture:
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
