Switch your lights automatically: ESP32cam, Node-RED & Raspberry Pi

Ever wanted to control your light automatically when it is too dark outside? You want to start a project based on an ESP32 and fancy IoT-home automation via Node-RED? Then this small project is for you!!

Our Munich appartment’s kitchen is headed to the east. This means that if we are facing some of the famous German-dark weather-days, it is a little bit too dark in the kitchen. A LED-stripe next to the kitchen sink is enough to brighten everything up again. But then the question arises: Who turns on and off the light? What about night? What about bright days? You guess it already: IoT and Home-automation is our friend and solves the problem.

So, to solve such a huge problem of human mankind 😉 I had a reason to dig into ESP32-micro controllers. My described solution uses an ESP32cam-module to “calculate the current brightness”. Node-RED processes the generated values and controlls the kitchen’s light via FHEM-home automation.

I discovered quite fast that almost all coding was already done by the community. All it needed was some further integration into my system. In my post I describe what I have done to switch my kitchen light. And how you can do so, too 🙂

ESP32cam

Before I describe too much, see my open source code-base: https://github.com/andremotz/esp32cam-skyAnalyzer It is a fork of an already existing code but I was adjusting minor-things for my needs. Eg. a dedicated REST API-endpoint that returns the average pixel’s RGB-value in JSON-format.

The not yet final installation on my window. But it works!

Still want to 3D-print some fancy housing but haven’t finalized my current setup yet. But hey, it does the job!

High level-Architecture

The ESP32cam exposes a HTTP/JSON-based REST-API. Its response includes the average RGB-value.
Business Rule Engine:Node-RED is the central instance that connects all components. A regular request’s response sends a corresponding command to the local FHEM-server. The ESP32cam’s values are stored in an InfluxDB and can be visualized via Grafana.
FHEM has control over my local wireless power-plug switches and can turn on/off several lights, eg my kitchen-light.
As of now, I am using cheap Intertechno-switches that one can buy in every DYI-store in Germany. It uses a simple Fire & Forget-protocoll via 433 MHz. Hence, FHEM/Node-RED does not know whether the switching was successful or not. Therefore, every 5 minutes the system sends out another command.

Super-simple straw-man architecture but it does the job: Switching my kitchen’s light based on some values coming from the ESP32

FHEM

FHEM is a Perl-based home-automation web server. I’m using it for almost 10 years and it does its job. Hence, I never replaced it with something fancy like Home Assistant or whatever solutions are currently en vogue 😉

In the FHEM-community you can also find an article about securing a FHEM-instance with a HTTPS-reverse proxy based on nginx that I wrote some years back.

Fhem showing my 433MHz based Home automation-dashboard

Next to my other home-automation devices: My FHEM-Raspberry Pi 3 with CUL433 MHz sending device

Node-RED

From left to right:

An Inject-node gathers data from the ESP32cam.
getColor/luma/isBright: These nodes are used to convert the RGB-values to a “brightness”-value. Based on a hard coded-threshold, the system sends either a “turn on” or “turn off” command to FHEM.
In parallel, all received values are logged to a local InfluxDB

InfluxDB & Grafana

Grafana Dashboard visualizing the ESP32’s output. The above sawtooth-wave visualizes the micro controller’s uptime in milliseconds. A [Buffer overflow] resets the counter to a negative value but this does not stop me from analyzing the systen’s resilience.

This installation I already had in place because I constantly monitor my Internet’s speed- and ping-values.

The Saw-pattern you see on top helps me to analyse and debug the ESP32’s uptime-issues I still encounter occasionally. It plots the ESP32cam’s uptime in millseconds. Since the used integer creates a buffer-overflow, it starts with a negative value again.

You can see a deviation in the saw-pattern that indicates a restart of the ESP32cam.

Kitchen-Switch

GIF animation of my kitchen-light swtiching on and off automatically, based on the sky’s brightness.

Cool, huh? The result is a LED-stripe that turns on automatically when it is too dark.

Challenges / Next Steps & Lessons Learned

OTA-update: As soon as you start working on an ESP32-based idea you want to have OTA (Over The Air-update) capabilities in place. However, I never got it running with my firmware and my ESP32cam-module.

Buffer-overflow not yet solved: So far I still seem to have a buffer-overflow issue. The camera’s frame-buffer can’t been read after a while. Hence, as a mitigation, I implemented a restart once the exception-handling routine is been called.

But you guessed it already: My real motivation for this project was to work on some tangible small example to use my knowledge in Micro Controllers, C++, IoT and home-automation via Node-RED. So, it was a real pleasure! : )