In my last post, I went over some mile high view details of ESP-NOW and my plan to replace the largely analog control scheme for my target activator system with some microcontroller boards running ESP32 and ESP8266 chips. That these systems can provide wireless communications for far less than the cheapest alternative that I had found thus far. However, in making that jump, there are many other advantages, some of which feed from one another, but all rooting in using the MCU boards to control the system.

The control box primarily becomes just more control-y, able to leverage MCU features in the activator and trigger devices. The control box will have user friendly lights to indicate whether the activator has been reset and the trigger is ready. With an arming feature, it will be able to ignore trigger inputs during stage reset. With wireless triggers, there is no need to choose an input polarity. Once a later version is configured with a display, more sophisticated features, such as sequencing multiple activators from one trigger or battery charge level from remote devices.

The activator benefits in several ways, where using an MCU introduces cascading improvements. Immediately, I realized that a big problem will be that the activator will now need an internal battery. Since the MCU can take over the timer relay’s one function, that relay can come out, leaving more room for the MCU and a battery. I don’t need a connector for the wire, but I will need a power switch and the external antenna.

I was watching a YouTube video about multitasking MCUs. One of my favorite videos on the subject involved adding more things that were happening at the same time, first a blinking LED, then an LED that fades in, then a button that lights and LED and finally a servo that sweeps, with all of these running simultaneously. BTW, all of that revolves around programming the various delays needed without using the built in delay() function because the MCU can do nothing else while that particular delay is running.

Wait a second, ‘servo’? Epiphany! I can replace the 12 volt lock motor with a suitably strong servo; I don’t need to protect the lock motor if there is no lock motor to protect. Oh, and any servo will be a LOT smaller than the lock motor, so now I have more room for the battery. Oh, and the lock motor was the only reason I was going to need a 12 volt battery, so now I can use a smaller battery, like a 7.4 volt RC car battery, which are made to be easy to swap out and charge.

Hardly mentioned thus far is that the trigger devices can be remote and wireless. There is a good argument for keeping the hardwired connector for certain triggers that don’t really need to be automated. On the other hand, a wireless trigger appliance that hardwired triggers can plug into makes all triggers look alike to the controller software.

The short version (I know, I’m not good at telling the short version of anything) of implementing ESP-NOW is that there are quite a few serviceable example sketches showing how to set it up and get it working between almost any number of devices. The examples tend to show unidirectional commuications, with one or more transmitting devices paired with one or more receiving devices. At minimum in my application, I need for the control box to receive from a trigger device and send to an activator device. The control box really needs to be able to communicate in either direction. Taken a bit farther, an activator needs to be able to send it’s status and a trigger might need to be able to receive a command, so from the ground, I need to deploy them as bidirectional.

At this point, however, I am pretty happy to have unidirectional communications that is responsive. In the little video below, the window on the left is the ESP32-S3-Box set up a the sender. I have a button push set up to trigger it sending it’s data, in this case the number ’25’. On the right is the D1 Mini Pro set up to print any data it receives as soon as it receives it.

This video is not particularly easy to see the details, but I think you can tell that there is only a tiny delay between when the S3-Box senses the button and when the D1 Mini displays the received data.

Interestingly, the button press needs work. No matter how debounced the button is, it somehow sends the data twice per button closure and once upon button release. None of the logic in place *should* do that, but it does. I suspect it will be because the example code scans for all slave devices and puts them in an array. The button press triggers a loop which counts through the list of slaves and sends the data to each. I am guessing that something in that loop is to blame for the multiple sends. I don’t want to completely eliminate the loop because a near future version needs to e able to sequence through several activtors. Plus, my button press might not be perfectly well executed. Maybe it isn’t as debounced as it should be.

My first implementation of the wireless setup will actually have the units hard coded to eliminate such issues until I am ready to tackle them. I don’t need to be fighting on multiple fronts.

The activator software really doesn’t need to do much for a successful version 1.0. Receive the activate command, operate the servo as required to release the physical device, then sense whether the physical device has been reset or not.

Once I had really decided to go with the MCU route, the primary trigger device that I have been thinking about is a ESP-NOW equipped photobeam sensor. Like the activator, version 1.0 of the trigger doesn’t need to do just a gob of stuff, just send a signal to the controller when triggered. Everything after that is gravy.

There is one potential problem. The photobeam I *have* requires 12 volts and all the alternatives that work in the same basic way, with the emitter and detector in one device that points to a retroreflector on the other side of the detection area, also all start at 12 volts. This means that the trigger device will either have to have a different battery than the control box and activator, or I need to get 12 volts from somewhere.

There are boost voltage converters that use switching power supply technology to boost voltage. Of course, there is no free lunch, so a boost converter draws the same amount of power it converts. To supply 12V at 1A would take 1.6A from a 7.4V battery, plus a little to account for efficiency loss. Happily, the photobeam draws 40mA or less and, at this point, I’m not sure how much the D1 Mini Pro pulls, but I’d bet I can probably use one and a 7.4V battery and be just fine. I guess we will find out.

Longer term the the data protocol I develop should include the activator and trigger devices sending a periodical status packet. This will be used as a general keep alive communication, but the structure of status message will include a device ID that the user assigns, a bit or two to identify that type of device it is and other status information, like battery condition and whether the activator needs to be reset. I have 250 bytes to play with, but one or two bytes should suffice.