Making the WiFi button for home automation was fun but the 7 second delay for it to take
effect was not so great. In this video, we are going to take a look at an even more efficient
WiFi button that uses ESP-NOW as the main communication protocol. This allows us to
trigger automations in near real time, that’s 280 milliseconds.
You can also view the battery status within Grafana which allows you to monitor its health.
The current consumption is very low and I do not have the correct tools to measure the
actual values so I used a one-ohm resistor to get a visual representation of the current
consumption and this is what it looks like.
The voltage values here correspond to the current consumption. If we assume the same
average current consumption as last time, which was 74mA and if we only adjust for this
shorter time duration which has changed from 7 seconds to 280 milliseconds, then the new
run time for 5 activations a day, when powered from two standard AA batteries is a crazy
big number of almost 68 years.
Obviously, we’ve reached a point now where it would make more sense to use smaller coin
cell batteries. Moving on to the sketches and they themselves can be easily expanded
to suit your requirements, which means that you can use this as the base to trigger automations,
monitor the status of your doors or windows and you can also create a sensor network around
your home. I will be attempting to make a sensor node in a future video so do consider
subscribing to stay updated.
We have already covered all the topics in a previous video so if you are not familiar
with anything that I am about to talk about then please use the Home Automation playlist
to watch the relevant videos.
Let’s take a look at a simple setup, where we have one button and one bridge.
The button is going to spend most of its time in the inactive state. If you remember correctly,
we have a MOSFET that disconnects the battery to extend the runtime. When the button is
pressed, the MOSFET switches ON to power the WeMos D1 mini which then quickly latches the
MOSFET to keep it ON so that it can send the data. The button then calculates the battery
voltage and gets ready to send the data. However, in order to send the data to the correct node,
it needs to know the MAC address of the bridge. Once it sends the data, it then switches OFF
the MOSFET which shuts everything down until the button is pressed again. That is pretty
much everything that the button is doing, so let’s take a look at the button sketch
to see how this has been implemented.
This may look like a lot of code, but this top half is mainly to help you setup everything.
There are also a handful of definitions to help you configure the sketch to your requirements.
Printing data like this is particularly useful when debugging, however it wastes CPU cycles
and since we want to conserve energy, make sure that you disable debug mode by setting
this to 0 as that will eliminate the print statements. You can set it to 1 when you want
to enable the print statements. Everything else is pretty similar to the ESP-NOW video.
As mentioned earlier, we need to specify the MAC address of the bridge, so please change
this to suit your setup. We then define a data packet which gives us the structure of
the data that will be sent. I added the buttonId so that you if you have multiple buttons,
you can use this to identify which one was triggered. The buttonValue field is not used
right now but you could use this if you like. We then have the batteryVoltage which ranges
between 0 to 42. You need to divide this by 10 to get the actual battery voltage which
is a maximum of 4.2V for a Lithium-Ion battery. Whenever data is sent, we check the status
and print out the appropriate message. We also set this flag to true to indicate that
we have attempted to send a message, this will make sense in a minute. In the setup
function, we start by taking the MOSFET gate pin LOW which latches it in the ON state.
If we are in debug mode, then we quickly print out the MAC address before proceeding. We
then initialize ESP-NOW, setup the connection details including the transmission callback
function. Once all of that is done, we can frame the data packet and start sending the
data. This part here obtains the battery voltage for us and I will explain that next.
The battery voltage is analog in nature, this means that we need to connect it to an analog
input pin in order to get its value. The WeMos D1 mini has a single Analog input pin marked
A0, but instead of being directly connected to the microcontroller,
It first passes through a voltage divider network that’s present on the board. This
is very critical because the maximum analog voltage that the ESP8266 can handle is 1V.
So, when you connect 3.3V to pin A0, the voltage divider reduces this to 1V as seen here. The
maximum battery voltage for a single Lithium-ion battery is 4.2V which means that we need to
modify this voltage divider network a bit. All we need to do is add a 100K ohm resistor
between pin A0 to the supply voltage. The two resistors in series give us a value of
330K ohms, and when run the calculations again, you can see that we are exactly at 1V maximum.
And that is exactly why I have this resistor seen here that is being held in place with
some hot glue. I have also added the MOSFET control circuit from the previous version
and the schematic is shown on screen.
The voltage calculation should now make more sense. We multiply by 4.2V because that’s
the max voltage we are sensing and we also multiply by 10 so that we don’t have to
deal with decimal values although, you could simply change this variable type if you wanted
to. Before sending the data, we set the attemptedTransmission flag to false as this will be set to true
once the data has been sent. Once that happens, we switch OFF the MOSFET and go to sleep.
In reality, we will never reach this line as the power will get cut off as soon as the
MOSFET switches OFF. I have also added a little timeout condition here which will force the
board to go to sleep after 5 seconds, in case it was unable to send the data for any reason.
So that is what the button sketch looks like. The data will then be received by the bridge
and before it can send the MQTT request, it has to do two things. It first needs to identify
who sent the data so that it knows that type of data it is. Once it figures this out, it
can then create the correct MQTT request and send it to Home Assistant. To help you understand
everything better, I created this sketch which simply prints out the data it receives.
Again, it is very similar to the one we looked at in the ESP-NOW video. We start by printing
out a couple of debug messages, and then specify the function which will get called whenever
we receive data. The function first tries to determine the data type, once it has this
information, it will then read the data and then print it out for us to view. If it cannot
recognize the data type, then it will print an error with the MAC address of the sender.
The way it determines the data type is pretty interesting. Since we know the MAC address
of the nodes, we can compare them to the node that sent the data. There are different ways
by which you can compare the MAC addresses and I decided to write a function that first
converts the individual arrays to strings and then compares the two strings to see if
they match. You could also manually set the MAC address for each board and use a single
character to identify a type of node. The choice is yours. For now, I have only defined
the buttonPacket data structure and packet type. You could add more to expand this the
way you like.
All that’s left to do is add the MQTT section and this is what the final sketch looks like.
Here we have the MQTT related statement which contain the Wi-Fi network details, the broker
details along with the topic. We’ve taken a closer look at all of this in previous videos.
All these other statements are similar to what we have seen in the previous sketch.
What’s different is that we now connect to the WiFi network before initializing ESP-NOW.
In the loop function, we simply maintain a steady connection to the MQTT broker and make
sure that we are processing any data that needs to be sent to it. When we receive a
valid packet, we create a payload that contains the data as a JSON object and we then send
it to the MQTT broker. Converting it to JSON allows us to easily work with it in Node-RED.
I am not an expert in using Node-RED, Grafana or InfluxDB but I will quickly go over it
all to show you how I did it.
This is what the raw data looks like and it is similar to the data that we sent. We can
then use a JSON block to convert this to an Object that looks like this. Now that we have
the key value pairs, we can work with this data more efficiently. For that, we use a
switch node to determine which button was pressed based on the id value. If I had more
buttons in the setup, then I would add more cases here. For now, whenever button 1 is
pressed, I simply toggle the workspace lamp. That is all you need to do to create an automation.
If you want to visualize the values being sent then you first need to store it within
InfluxDB. That is why I have this node here. The influxDB out node stores this data as
a measurement with the name shown here. You will need to specify the database first and
if you followed the videos then all these three values will be homeassistant. That’s
all there is to it. When you press the button, you will see the appropriate messages below
the nodes and the light will be toggled instantly.
To visualize the data, we can open up Grafana and create a new dashboard. You can then select
the data source which is the same name that we stored it under. We can then select the
measurement value that we want, specify the last value and then divide it by 10 to get
the voltage reading. To change the way the data is displayed, you can head over to the
visualization tab and change the display type. You can then specify the title, units, limits
and decimals. You can also head over to the settings tab to give this panel a name, and
then save it. Once done, you will then be able to view the status visually, which is
pretty cool.
So that is how you can do all of this amazing stuff. There’s obviously a lot more that
you can do and I am not sure if we could cover all of that on this channel. Hopefully the
sketches will give you something to work with as a start. I realize that some of this may
be a bit advanced, but we have been doing this for a long time now so most of it has
been covered numerous times. Hope you found this video useful. Do consider subscribing
if you haven’t already. Thank you for watching and I will see you in the next one!