MicroPython Forum (Archive)

Ok so,


I have built a display unit consisting of two columns of 32 leds each (an East column & a West column). 64 LEDS total, which are connected to an ESP32 via a MAX7219 display driver.

I have uPython code to light a single LED anywhere in each stack depending on a East or West variable ranging in value 0 - 4096.

I have two linear taper 10k ohm potentiometers connected to the ESP32's at ADC pins 34 & 35, which create the values of the above variables.

I can dial the pots end to end and achieve an analogous single lit LED, positioned in the appropriate E / W display stack.

VIDEO

I have a means of mechanically linking the rotation of the pots to my 2 garage doors East & West.

The plan is to use this display to indicate the real time position of each of my garage doors. (Yes I realize its overkill and a simple pair of closed / open lights would be sufficient, but wtf, I'm retired, what else is worth doing?)

I want the display to be remote from the garage, say in the kitchen, so that we can know where each garage door is without having to go to the garage to look.

My plan is to use a second ESP32 to read the pots and then relay the positonal data to the display ESP32 via some wifi protocol.

I am drawing a blank however on the best way to achieve this part and the usual googling around doesn't seem to be turning up the golden nuggets I need to proceed on my own. It seems to me that UDP communications might be sufficient but bluetooth (distance?), espNOW (uPython support?) also suggest themselves as does TCP. (Even MQTT might be a contender but it seems a stretch to me as I don't have a broker running locally and don't want to be dependent on cloud resources.)

Also seems to me that I'd like to have the ESP32 at the garage 'push' the data to the display unit and not have the display blindly initiating the data transactions. Also, to minimize net traffic, I'd like things to go quiet, unless a change in garage door position is detected. Although an "I'm still here" watchdog indicator at the display end might be useful to keep me assured that the units are still in good with each other. (and my OCD at bay)

I am not well versed in the use of sockets to achieve this and I'd like to hear some suggestions from the experts on how best to proceed. I need to extend the envelope of my learning curve a bit here, which is the whole point of this project really. So, you experts . . . .

Your thoughts?

Thanks, cheers and good health!


Brian H.
Uxbridge Ont Canada

Sockets are your friend, well at least after some time. I have no idea how far it is from your garage to your kitchen but distance or thick walls can rule out Bluetooth. UDP or TCP is more a matter of taste here where TCP is more reliable because of re-transmissions and such included in the TCP layer.

I feel WIFI is the obvious solution and can easily be done 2 ways. 1: Find an extra WIFI router, I bet if you look around you can find one in your drawers of buy a second hand one for almost nothing . Set it up with its own SSID "MYGARAGE" it does not need to have any internet connection as long as you only want to link kitchen and garage. 2: The other option is to make one ESP32 Access Point (AP) and the other ESP32 Station (STA). There is of course a third option, Use an ESP32 as router in the middle, this will extend your network distance without using a regular router. It is of course possible to link both ESP32 to your current WIFI network if you have one if you insist on being able to check the status from your phone while at home. Checking while not at home is a totally different animal. Opps that's more than 2 ways....

Regardless of solution you make one ESP32 Server, and the other Client. There are good examples of this in the documentation under Network. A super simple TCP server / client solution. I don't really care what purists say but Static IP number is your friend too in this case. Make sure all ESP have their own Static numbers or you can not connect to them after a restart. This is easy to do when you configure the WIFI setup anyway. Invent your own Data format, something super easy that you can parse easily when receiving. "FromGarage,Data0,Data1"

If you have a Push or Pull system is up to you but I feel it would make sense that the garage unit updates the Kitchen when something have moved and if it have not moved it sends a communication check message on a regular interval.

MQTT would require a broker and I don't see how you can run a broker on a ESP32 and for your use case it is overkill.

Home automation projects are funny and tend to grow organically. Are you aware it is possible to add a paper out sensor to toilet paper??

Assuming both devices can join your home WiFi, then using TCP sockets to talk between then sounds like a good idea.

However, I'd avoid using sockets directly, and instead use one of the many HTTP server and client options. I'd recommend using https://github.com/miguelgrinberg/microdot for the server, and urequests (included in the firmware) for the client.

microdot includes an example of controlling a GPIO pin from an HTTP endpoint.

Another WiFi approach is micropython-iot developed by myself and Kevin Köck. This requires a server script which can run on a board such as a Raspberry Pi. The protocol is very simple in that each endpoint sends and receives strings from a socket or uart-like interface. There is an example script where a pushbutton on one ESP lights an LED on another.

The benefit relative to trying to use sockets is resilience. WiFi is unreliable, suffering unpredictable outages which will break a socket connection. They break other protocols too, including official MQTT. The underlying code in micropython-iot recovers from outages, client and server reboots with no need explicitly to code around them.

Hi Peter,

Another WiFi approach is micropython-iot developed by myself and Kevin Köck.

Thanks for this suggestion, I am very glad to be acquainted with your micropython-iot work. A tip of the hat to you and Kevin Köck to be sure.

This approach however, would appear to require a third intermediary station (RPi) as "server". This represents a significant increase in overall system complexity, have I misunderstood ?

I take your point about ESP32 resources and resulting ESP32 based socket connection fragility in the long term. In my head though, I was not imagining that the connection in this project, would attempt to be a permanent thing. The doors remain motionless 99% of the time I would guess. I had rather imagined the connection being closed most of the time and only initiated, once some movement of one of the doors was sensed. Likewise I see the connection only persisting for a few minutes after the last detected motion. At all other times the connection would be terminated and closed in an orderly manner.

Am I being too optimistic here?

I do acknowledge btw, the micropython-iot server's potential as an 'if you build it they will come' opportunity for use by also being available for relaying data for other future systems. This tempts me.


Cheers & best regards,

Brian H.

microdot includes an example of controlling a GPIO pin from an HTTP endpoint.

Thanks Jimmo, for this worthy suggestion, The lack of documentation looks a bit daunting however.

I shall attempt to persevere with it.

Thanks again.

Brian H.

An advantage of micropython-iot is its extensibility, but it does need a server. This can be minimal: mine is an original V1 Raspberry Pi which runs 24/7.

However in your application resilience may not be an issue. Your door sensor could disconnect from the WiFi altogether, only connecting when there's something to report; it could sleep or even power down completely. If the receiver (running 24/7) acted as a server you could use a socket, with the door sensor disconnecting from the server (and then WiFi) when its job is done.

Another off-the-wall idea is to forget WiFi and use a pair of NRF24L01+ radios. I have an application which has been running for several years, built before there were any usable WiFi enabled targets. This has three Pyboards waking up once an hour, send a message to an always-on Pyboard, and go back to deepsleep. The batteries on the remote Pyboards last for about two years. There is an official driver and I have written some support modules.