Introduction

Being a maker means having to measure things all the time. Usually, the things we measure are relatively straightforward — temperatures, voltages, currents, humidities. Usually, all you need is an off-the shelf sensor and an analog pin or an I2C bus on your microcontroller, a couple of lines of code, maybe a tutorial, and you are done.

But air velocity is different; there are few off-the shelf sensors that a maker would readily use:

• Suppose you wanted to measure the airspeed of your model airplane? Or maybe you wanted to build a simple protection controller to automatically close your motorized awning when it gets windy? You could maybe use a 3D-printed propeller-type sensor, but these are fragile (trust me, I tried a lot), and moving parts are something to be avoided in any project.

• Or maybe you are building something to do with ventilation and you need to measure air flow. While you might find an off-the-shelf sensor for air flow used for air-conditioning, I found these to be quite expensive and not particularly flexible.

Luckily, there is a maker-friendly answer to all these—Pitot tubes. If you never heard of them, I’m pretty sure you at least saw them before: it’s the pointy thing on the nose of most airplanes.

How Does It Work?

To put it simply, a Pitot tube (named after the inventor) is a tube that we insert into the flow of air with the opening pointing into the flow. The air pushes into the opening, producing a measurable pressure change. If we measure this change and know the density and physical properties of the gas, we can calculate the velocity of the flow of air. You can find a nice graphical explanation here.

How Do We Measure the Pressure Difference?

In conditions you are likely to encounter as a maker (roughly room temperature, roughly sea-level pressure, velocities not exceeding 100m/s), Pitot tubes produce rather small pressure differences (tens of millibars/hectopascals at most). Sensors for such low differential pressures with any kind of resolution/accuracy were rather expensive until the advent of MEMS-sensors, but the situation has changed dramatically since then.

You can now buy a Sensirion SDP differential pressure sensor with a pressure range of 125 or 500 Pa, I2C bus connection, some limited intelligence like averaging, and a couple of milliamps of power consumption for ~25€. This sensor, a couple of thin connection hoses to connect to the Pitot tube, and a very basic microcontroller are all you need.

How to Build a Practical Pitot Tube

If you clicked the explainer and the Wikipedia article above, you already know a Pitot tube is basically a stick with two holes or ports, one facing the airflow and one facing to the side. These ports are then connected to the differential pressure sensor by channels of some sort. You could simply point the two hoses coming from your sensor in the right directions, and it would already sort of work.

Of course, if you want any kind of accuracy, there are some things to consider:

• Positioning matters — you need to make sure the rest of your setup is not influencing the air velocity at the point of measurement. Imagine a car with a Pitot tube on the roof — the airflow along the hood, windshield, and roof will be quite different from the free airflow one meter higher or maybe one meter in front of the car. This is why jets have these tubes sticking forward on the nose — it’s the only place where the airflow hasn’t changed much yet.
• Direction matters — if the tube is not pointed straight into the airflow, you will have cosine losses, but you will also be adding pressure on the reference (side) port. Both will play havoc with your accuracy.
• Temperature matters — the calculation of air velocity depends on gas density and temperature. Gas density is again dependent on temperature and absolute pressure. So, depending on your application, you need to measure the temperature of the air near the tube. If you will be flying an airplane model, you should measure the absolute pressure as well.

An Example Design for 3D-Printing

Let me explain the above points using my first Pitot tube design:

As you can see, it is a simple pointed stick with one port on the pointed end and one on the side. At the back, there are two nipples to connect the sensor hoses.

It’s best explained by showing you the section view:

Here, you can see the two channels connecting the ports to the nipples. The chamfers are there to keep the bridging to a minimum. The nipples are a long way away from the ports to avoid any influence on the air velocity, e.g. when holding it.

3D-printing is a fantastic way to make Pitot tubes; you can make the necessary channels and everything in one easily printed piece.

The Actual Measurement

Once you have the Pitot tube connected to the differential pressure sensor, the next step is calculating the actual air velocity.

The Assumptions

I’m assuming ~2–5% accuracy with good repeatability, and a refresh rate in the order of a second or so is enough for your needs here. If you need more, it’s time for a deep dive, sorry. 😅

BTW, did you know: 5% is the difference between a measurement and an indication. Once you go above 5% accuracy, you are measuring things.

Of course, we are talking about volumetric air flow here. But in most practical cases, multiplying the mass air flow by the fixed air density value in your working conditions should give you a useful value.

The Algorithm

It involves several steps:

1. The pressure signal can be a bit noisy. E.g. with the Sensirion SDP810 sensor, the sampling rate can be up to ~2 kHz, which covers even a part of the audio spectrum and is sure to be noisy. A good antidote to noise is averaging, but the good news is, the sensor can do averaging already. It does full averaging for 25 ms and then exponential smoothing after that. As long as you aren’t worried about noise with frequencies under about 40 Hz, this is good enough. If you need to go even lower, read the average every 25 ms and do exponential smoothing yourself. Here is a good primer. It’s really simple to code and covers the majority of »we need to filter noisy input data« use cases, so you need it in your toolbox in any case.

2. You need temperature info. Temperature influences both the Mach velocity and gas density, both factors in the calculation. The Sensirion sensors include a temperature readout, so as long as the sensor is somewhat close to the Pitot tube, this should suffice. If not, add an DS18B20 sensor close to the sensing port of the Pitot tube.

3. You need absolute static (environment) pressure info. If you will never leave ground, assuming the pressure to be 1013hPa (mbar) is good enough, unless you live above about 500m of elevation. If you do, take the value from here. If you are flying a (model) airplane, you will need to have an absolute air pressure sensor on board too.

4. Once you have all this data, the formula to use is (C++, Arduino): v=(a0+((t)*css))*sqrt(5*(pow((fabs(p)/p0*k)+1,0.2857)-1));, where:

   • a0 is the speed of sound in m/s,
   • t is the temperature of the air at the input port,
   • css is the temperature coefficient of the speed of sound (at given absolute pressure, 0.606 at sea level; this is a non-linear relationship, but the value given should be good enough for atmospheric pressures given our assumptions),
   • p is the measured pressure difference (Pa),
   • p0 is the absolute pressure (Pa).
   • k is the Pitot tube coefficient, basically the measure of how much your measuring setup is influencing the airflow around the measuring ports. The good news is: If you positioned the Pitot tube well ahead of the rest of the hardware and did a reasonable job at directing and designing the Pitot tube, you can just say there should not be more than 2% of random influences, and you can set k = 0.98. Or you could take your setup for a ride in the car and calibrate it or at least check your assumptions. But keep in mind — getting the accuracy above 2% will involve some serious work.

The result is given in m/s.

Don’t forget the conversion factors! E.g., with the SDP810, divide the raw pressure value by 240 and the raw temperature value by 200 to get Pascals and °C.

The Hidden Bonus — No Calibration Required

If you look at the above formula, there is only one calibration coefficient, and it is one that we can at least partially omit. So if you built the system well, and you need only a reasonable accuracy (a few percent), no calibration is needed. This is a major advantage compared to other types of sensors, like Venturi or fan-type, etc.

What About the Flow Rate?

Model airplanes are cool and all, but I think the average maker will be more interested in measuring air flows, e.g. for ventilation, air conditioning, burner control, carburetors, etc.

Some examples:

• If you are building a ventilation system with heat recuperation, you need the ingoing and outgoing airflows to be about equal, or you are wasting heat that could be recuperated.

• If you are doing air conditioning, it’s good to have some idea about how clogged your filters are. If a clean filter gives you 100 m3/h of flow at a certain fan power level, a measurement of only 80 m3/h over a certain time means it’s time to clean or replace the filter.

• Burners and carburetors have one job: keeping the ratio of mass flow of air to mass flow of fuel constant. Modern fuel injection systems use a MAF sensor to do this, and this should be the first thing you try, but if that is not an option, measure the air flow at least.

So How Can I Measure Airflow Using a Pitot Tube?

How to Calculate the Flow Rate?

Once you have the air velocity, calculating the flow is easy: the air flow is simply the product of the average air velocity and the cross-section area of the flow channel. A duct with 1 m2 of area and 1 m/s of average air velocity will thus have exactly 1 m3/s of air flow.

Surely There Is a Catch?

Note the italicized averages above. Airflow velocity inside a duct is not constant across the whole area. At the edges (near the walls of the duct), it will be slower due to air friction with the duct walls. The average velocity is thus the highest in the center of the duct and slowest at the walls. The place where we measure it clearly matters — putting the Pitot tube in the center will give values that are too high, and putting it near the walls will result in values that are too low. So how do we account for this?

One way is to use an engineering approximation — at a certain airspeed and a certain temperature, the average airspeed will be the measured airspeed in the center times a certain coefficient that you would get from engineering tables. But this is not very accurate, both because your airspeeds and temperatures vary and because there are other factors at play — maybe your duct is not straight or there is more roughness (dust) on the bottom than on the top of the duct. Maybe your duct is weird in some other way? Wouldn’t it be nice if we could measure the average air velocity directly?

The Averaging Pitot Tube

It turns out that we can do that, at least mostly. The answer is the averaging Pitot tube. It sounds complicated, but it is simply a normal Pitot tube with several input and reference ports. These ports are connected to a larger cavity (one for the inputs and one for the reference), so the air pressure in the cavity is roughly the average of all the air pressures at individual ports.

Again, it’s easiest to explain with a couple of pictures. The averaging Pitot tube is installed to span the whole width of a duct:

It has several ports over the whole width, which are connected by a large averaging chamber, which gives us an average over the individual port pressures and thus an average pressure difference:

Some designs use a cross shape to average over the height AND width of the channel.

The pressures at the output nipples should roughly correspond to the average air velocity. We can calculate it using the formula in the previous section and then simply multiply with the (known) duct area, giving us the air flow.

Still, this is not a cure-all. You should have reasonably laminar flow in the duct to achieve any accuracy. In practice, this means you should try to put the tube at the end of a long straight duct, and avoid things that cause turbulence, like elbows.

A Practical Example of a Measurement System

To help you see how to put all of this together, I set up a Github repository with the STEP files for the two Pitot tubes and the code for an Arduino based measuring device I built.

From these humble beginnings, I went on to build a balanced-flow ventilation system for my home. It still works after several years. 🥳

Here is the testing setup I used for it. Note the measuring gear (averaging Pitot tube, hoses, and the measuring device) on the leftmost side of the duct. And on the right there are the 3D-printed impellers I was testing:

Let me know if you are interested in this in the comments.

Part 2: The Hardware you Need to Control a Distributed Heating System Through Meter-thick Walls You are Not Allowed to Drill

In part 1 of this series we talked about how to retrofit a temperature control system into an 800-years-old heritage-protected monastery without drilling and running new cables. The solution turned out to be the LoRa (Long Range) radio transmission technology that trades transmission speed for extreme transmission range, enabling us to wirelessly talk to stations behind several thick walls over 100 meters away.

The Constraints

• No changes to the heritage protected building were allowed.
• Retrofit budget was limited, ruling out changes to existing cabling.
• It needed to be retrofitted to existing underfloor heating piping and valves.
• It needed remote per-room temperature control.

The Hardware Structure

Let’s refresh our memory and look at the proposed system structure:

The Hardware Parts

Note: I listed all the hardware parts I used with links to the manufacturer web pages. These are just for your information and I’m not earning any income through these.

Temperature Control Stations

Most of the rooms of the monastery have a large central table containing the electrical installation, and underfloor heating piping with valves, but some had only a small cubicle. I was going to have to install the control stations for these rooms there.

The designer chose to build these tables and cubicles from thick iron plate with laser/plasma cut decorations on the sides. It looks wonderful and they are extremely durable, but it meant I could not hide the entire control station inside — the iron plates were effectively a Faraday cage and prevented any radio communication inside. This meant I had to use control stations made from two parts — the radio communication part on the outside wall, and the power supply box with relays on the inside.

After fruitlessly searching for a suitable off-the-shelf product I decided to build these myself from individual modules:

The Wireless Station

The wireless station was the heart of the station, containing:

1. A Seeeduino XIAO motherboard, providing connectivity for everything else and a small OLED display for installation and diagnostic purposes, and holding:
2. A Seeeduino XIAO microcontroller board, the heart of the control station. It controls the relays and the display, reads the data from the temperature/humidity sensor, and handles the communication with the LoRa board.
3. A Grove LoRa-E5 transceiver board, handling all the wireless tasks.
4. A Grove AHT20 I2C board used to sense the humidity and temperature.
5. The LoRa antenna for the transceiver board. The transceiver actually has it’s own little antenna, but that was not enough, so I used a proper antenna, screwed to an SMA connector with a pigtail cable and an I-PEX connector for the transceiver board.
6. The wiring block.

I had to design a housing for it as well, which I 3D-printed out of flame retardant PETG. It has some holes for the sensors and the diagnostic display. Given that it was installed in a public space, I designed it to be extra sturdy and it also features a holder making it harder to unscrew or break off the antenna.

This was mounted on the outside of the iron tables and connected, using a 6-wire cable, to the power supply and relays board inside.

The Power Supply and Relays board

The wireless station, being publicly accessible, was strictly low-voltage (5V powered) for safety and it needed a power supply and relays to control the 230VAC underfloor heating control valves, so I needed to put all the high-voltage parts on a separate board, safely installed inside the table. It contains:

• A generic 4-relay board with built-in logic-level relay drivers
• A generic 5-watt 230VAC to 5VDC safety switching power supply, powering all the electronics.
• A fuse
• The low-voltage wiring block (above, for the 6-wire cable coming from the wireless station)
• The high-voltage wiring block (below, used to connect the station to 230VAC power and to wire the 230VAC valve actuators)

This board is safely tucked inside the table/cubicle and contains some components that get warm, so I designed a lighter housing. The cover has ventilation holes for cooling, but provides touch protection.

Wireless temperature sensors

After some research, I decided to use an off-the-shelf component, the RAK WisNode Sense Home (RAK7204), for the remaining wireless temperature, humidity and air quality sensors.

These wireless sensors are an elegant solution, running for anywhere from one to several years (depending on signal quality) on one included lithium primary battery. They also feature an automotive air quality sensor, giving us an additional data to monitor, e.g. for ventilation.

I glued some strong permanent magnets on their backs and simply stuck them to a less visible/reachable metal part in the room I wanted to monitor.

The monastery has quite a few rooms and corridors, so I installed 11 of these in all the places not covered with the control stations.

The LoRa Gateway

As explained in the part 1 of this series, using a public LoRa network was not an option for several reasons. This required installing a LoRa Gateway.

After some research, I again went for a solution from RAK, the WisGate Edge Lite (RAK7268). It has since been superseded, but the product on the link is mostly the same.

It only needs network and power. I found that the easiest way to interface with it was using the built-in MQTT server, but we will cover that in the software part of the series.

I installed it in a high place to get the best possible coverage and connected it to the same network switch the application server running Home Assistant was connected to.

The Home Assistant Server

The Home Assistant Server is running on a Raspberry Pi 4 SBC. For storage I used an SSD though an USB-SATA interface cable that allows me to store several years worth of data and backups. It is connected to the same switch as the LoRa Gateway.

Conclusion

In part 1 of this series I described this solution in a general way, but this part is my attempt to clarify by showing you the hardware I used.

As you can see, the off-the-shelf parts are all pretty low-cost components, easy to buy and install. The harder part was to select and integrate the custom wireless control stations, but I was forced to do this due to not finding the right component off the shelf. Still, using the rich plethora of modules available, it is not a big deal to assemble an usable system.

The wireless station design was heavily influenced by the fact it is a one-off project. I took proper care of electrical safety and reliability, but with less than 10 stations built, I did not have to think too much about the manufacturability of it.

The system still runs three years later with the original hardware and has turned out to be very reliable. The only maintenance needed is to replace the wireless sensor batteries as they wear out. In the three years so far, I only had to replace 5 batteries, making this a minimal, once-a-year effort.

The system needs some minimal software maintenance as well, but we will talk about that in part 3.

If you found this article useful, you can buy me a beer here.

Part 1: How to control a distributed heating system through meter-thick walls you are not allowed to drill?

A couple of years ago a friend had a problem: He is in charge of an 800-year-old monastery building now used as a conference center and an event venue. This majestic building was thoroughly renovated about 10 years ago, but the otherwise excellent new heat-pump-based underfloor heating system was missing the provisions for temperature control in individual rooms. Heating all the rooms all the time was wasteful and there was no way to set the temperature higher (e.g. in the conference hall) or lower (for custodial or temporarily unused spaces). Fortunately, the system already included the necessary underfloor heating loop valves, we just needed to find a way to control them.

The building spans about 100 meters with a square footprint and has very thick walls (meter or more). It is of course heritage protected as well, so drilling for new cabling was out of the question. We also really did not want to change the existing cabling; the long cable runs would be both expensive and time-consuming. We had to go wireless.

But there was a big problem: Wireless communication over more than 100 meters of distance and through meter-thick walls is too much for most of the known technologies, like WiFi, Zigbee, Bluetooth, etc. There is also the issue of licensing. What to do?

LoRa

The solution was to use LoRa (Long Range) technology. It is a low-cost, long-range wireless communication technology that uses frequency bands from 400 to 900MHz. The LoRa protocol is much slower (kilobits instead of megabytes) than e.g. WiFi, but this is offset by the fact that it will work over distances of several kilometers in the open. Or, in our case, over 100 meters and through several thick walls. It also does not require a radio license (but you do have to check for legal limits in your area like permissible frequency bands, transmit powers, and duty cycles).

Timing

LoRa transfers data at low speeds, between 0.3 to 50 kbits/s. This is not enough to visit websites, control a robot, or listen to music, but plenty for a heating control system that needs at least several minutes to respond to changing inputs. This is why LoRa is used for monitoring and control of remote systems like weather stations, reservoirs, and even satellites. There are many systems out there that only need to send or receive a few tens of bytes every few minutes or hours.

Complexity

The LoRa protocol is complex to implement from the ground up, but you can buy off-the-shelf gateways and sensor stations, e.g. from RAK. If you want to build custom systems, there are comprehensive software stacks and hardware modules available for all major micro-controller families, e.g. from Seeed. All this makes it possible to build a basic prototype quite quickly.

An IoT Solution or a Closed System?

LoRa is a popular IoT solution and there are internet-connected public LoRa networks all over the world, many requiring a low-cost subscription. This makes it a great solution for mobile stations, e.g. location monitoring for machinery etc., or smaller systems where you don’t want to set up a gateway yourself.

In our case, we had to install a LoRa gateway because of the difficult environment (a public network was available, but the signal would not reach the inside stations). We also have over 20 stations, so the gateway was not a big expense. And there is the issue of control system safety and reliability, both easier to achieve using own gateway.

Control System

System structure

So what does the structure of the whole system look like?

Application Server

The application server is the heart of the whole system. It runs on a Raspberry Pi, runs Home Assistant, and is connected to the MQTT server in the LoRa gateway.

Home Assistant

Home Assistant is an open-source home automation platform that runs on Python. It provides many different components, including a web-based front end with authentication and integrations for climate control, MQTT, backups, data logging, and more. It provides a GUI for our whole system.

Connection To the Sensors and Control Stations

The LoRa gateway makes it possible to talk to all the LoRa sensors and control stations using MQTT. Each underfloor heating valve is represented as an MQTT switch in Home Assistant, while the temperature/humidity/air quality sensors are represented as MQTT sensors. The actual temperature control is done using Home Assistant’s Climate integration as simple thermostats reading the MQTT temperature sensors and controlling the MQTT switches for underfloor heating valves.

Data Logging

The system includes temperature, humidity, and air quality sensors. Their values are all logged inside the Home Assistant system and stored in a database.

Conclusion

This article is an outline of the control system solution and I will be going into more detail in the following articles, where I will be talking about the control station design, the LoRa gateway config, and the Home Assistant config.

LoRa turns out to be an excellent solution for retrofitting monitoring and control into existing distributed systems, giving us the option to avoid expensive cabling and making it easier to respect the heritage protection rules.

Home Assistant was designed for home automation by enthusiasts but grew into a lovely solution for diverse automation needs, including small and medium-sized HVAC and related systems. It needs some attention as the ecosystem grows and changes, but one update a year with maybe some config updates doesn’t take a lot of time. It gives you a gorgeously looking GUI and all the features you need for control and data logging.

One of the larger challenges of decarbonization is the legacy systems. These will often use energy inefficiently (heating everything all the time is an excellent example) and lack things like temperature control, which is important for comfort. Sometimes, it makes sense to rebuild them completely, e.g. to replace fossil-fuel-based systems, but some legacy systems really only need some additional control. In these cases, using LoRa can be a comparatively simple and extremely low-cost solution with incredible ROI.

If you found this article useful, you can buy me a beer here.

When you decide to build or extensively renovate your home, you will need to do a LOT of planning. This series of posts will give you some insights on how to begin to plan your smart home installation.

The Old Way of Doing Things

Our homes weren’t smart until about 10, maybe 15 years ago (for some rare enthusiasts like me).

The old way was to run two circuits of power wiring on separate fuses to each room, one for lamps, the other for outlets. Then you would have the lamps directly hard-wired to the switches and the switches to the power circuit (using wires in cable conduits inside the walls). The outlets would be directly wired to the other power circuit.

For large loads (washing machine, oven, water heater) you would have a separate fuse and power circuit, again directly hard-wired to the corresponding outlet.

All the fuses and a RCD were collected in a main distribution box somewhere near the entrance of the house.

Pros

• Simple to install
• Minimal length of wiring, minimal costs

Cons

• Very hard to make any changes after installation, everything is hard-wired
• Very hard to automate
• Very hard to log useful data

What Is a Smart Home Then?

For me, the defining feature of a smart home installation is the fact that hard-wiring of functions is, to the extent this is sensible, replaced with software and automation elements.

Instead of wiring a switch directly to the lamp the old way, the switch is wired to a controller digital input and the lamp is wired to the controller relay output. When we press the switch, the controller software senses this and switches the relay, turning the lamp on or off.

At first glance, this seems like a really roundabout way of doing things, but it opens all kinds of possibilities:

• You can turn the lamp off automatically once the presence sensor is inactive for a while to save energy.
• You can turn the lamp on automatically when someone enters the room, but only if the illumination sensor shows it’s dark in there.
• If you are deaf, you can set the lights to blink three times if somebody rings at the door.
• You can turn things (e.g. heat) on or off remotely, so you come home from a long trip to a warm home.
• You can reuse the same sensors for different purposes, e.g. presence sensors can be used for alarms, energy saving functions and comfort.

The possibilities are really endless and can help you save money and energy, have more comfort, be safer, etc.

What Are the Main Features of a Well Designed Smart Home System?

Reconfigurability

We all know how we try to make plans and then life happens.

You want to use a different switch for a certain lamp? With a good smart home system, all you need to do is change a line of a YAML file. Adding many features often entails simply installing and configuring a plugin. A well designed system also allows easy hardware upgrades and system extensions (e.g. adding a room) due to it’s modular and distributed nature.

Reliability

Things break. A smart home will have many more parts than a traditional installations and you are certain to have a failure every now and then. It is important the system is built as resiliently as possible.

I cannot overstate the importance of good backup, which is the backbone of reliability in any software-controlled system. It is the difference between an utter catastrophe and an inconvenient chore once something breaks or you are hacked. Make at least daily backups of any relevant files locally (you need a NAS anyway) and invest in a good well-encrypted online backup service to backup at least the important files from there. I found IDrive to work on any Linux SBC and the pricing is reasonable.

Modularity is an important part of reliability—a set of several smaller subsystems will be more reliable, less complex, and easier to troubleshoot than an equivalent big system. There is also an added benefit that most of the overall system will continue to work despite a part being down.

Another important part is wiring. Wireless connectivity can be really helpful where wiring things is impractical, but you should wire everything else. This gives you several advantages:

• No need for batteries. Batteries wear out and this is bad for two reasons: First there are the natural resources being wasted and secondly, a lot of e-waste comes from devices that are simply thrown away instead of replacing the battery (if that is even possible).
• Wireless works most of the time. Wired works all the time.
• Some devices need to be responsive: When you press a button, the lamp should light up in less than a second or you will think there is a problem. Wireless loses packets all the time and you will get weird delays/issues when you least expect them.

Sustainability

Sustainability has several dimensions:

Sustainable Use of Materials

Choosing the right system topology can substantially reduce the amount of work and materials needed. This will also have knock-on effects on reliability and reconfigurability.

Sustainable Choice of Platforms

To put it very simply: If you are building a system that needs to work for a couple of decades, you must actively avoid any closed source products!

15 or 20 years later, that fancy PLC will not be available to buy if you need to replace it. Even more, the programming software for it will likely not work on the future OS (Windows 17?). And since it’s all closed source, you can’t port or hack it. All the expensive gear and precious natural resources will go to waste and you will have to start almost from scratch.

Bought a cloud-enabled app-controlled EV charger? Read about Juicebox and imagine being locked out of your smart home because somebody ran their company into the ground and simply turned off the cloud computers.

What will work forever? Open source software (Linux, Home Assistant and a lot more), open hardware (any Linux SBC or PC, Modbus or MQTT relay/input boxes, etc.) and open industrial communication protocols/standards (Modbus, RS232, RS485, Ethernet, MQTT, and a lot more). If something breaks, these are cookie-cutter modules—even if the one you want to replace is not available anymore, just buy a similar one and reconfigure (RaspberryPi 12 is sure to happen someday).

Sustainable Use of Energy

As you are planning your home, remember that efficiency pays for itself quickly. Buy better performing machines, but don’t pay extra for gimmicks:

• Better home insulation will be more expensive, but then you need a smaller and cheaper heat pump, air conditioning, etc., so it should pay for itself.
• A heat pump does not need a fancy app to control it, just a Modbus interface for your system and the best COP you can afford.
• Invest in ventilation with heat recuperation. Or live with mold. Forget about apps, choose the model with efficient motors and some kind of communication interface. An integrated CO2/VOC sensor is a plus, so you only run it when needed.
• Buy an EV charger that will be locally controllable (i.e. it has a control interface) by your smart-home system so you can charge efficiently. Or build one yourself.
• Some EVs will consume 12kWh/100km, some will consume 25. Buy what you need, but not more. Same size cars from different manufacturers can have very different consumption. Why am I including your car in this article about smart homes? It will be a major consumer of energy, but also has the potential for a LOT of optimization, from smart charging control to V2G. Most important: For the love of Earth, don’t replace it until it stops working or you really need a different one. Buying a new car every few years is easily the most expensive habit of your life and a colossal waste of resources.
• Heating/air-conditioning is easily your biggest energy consumer. Install temperature and humidity sensors in all the residential rooms and make the heating controllable so you can only use the energy you really need.

Questions You Need To Ask Yourself

Having a smart home can save you money, increase comfort and safety, and make your life more sustainable, mainly by reducing your energy consumption. But there are some important questions:

• Could you build it yourself, even if you choose to use a contractor?
• If not, do you understand it well enough to communicate your desires, needs, and concepts to the contractor?
• Do you trust the contractor?
• Is the design clear and well-documented enough for somebody else to continue maintaining the system in case you want to change the contractor?
• Are you able to reconfigure the system yourself after it is built or will you need ongoing support here as well? What about repairs?
• Have you thought enough about the sustainability of the system?
• Did you avoid pitfalls related to closed systems?

Be honest with yourself, the answers to these questions are important! Depending on them, your smart home can be an awesome thing or a source of SEVERE frustration. Good luck!

If you found this article useful, you can buy me a beer here.

The problem

A 3D printer is the most versatile tool any maker can have, but it has possible pitfalls and one of the more insidious ones is damp filament.

What happens: You have the printer dialled-in perfectly, everything works perfectly, a couple of weeks pass and then you try to print something again. It comes out looking terrible: blobs, stringing, ugly surfaces.

This is due to humidity absorbed by the filament. Once the filament enters the hot extruder, humidity expands into steam and plays havoc with the flow of molten material in the nozzle. In really bad cases you can actually hear the pops from the tiny steam bubbles during printing.

Some materials are more sensitive than others—you will be able to leave ABS or PLA out longer than, say Nylon, the worst of them. But one month outside in summer heat will make any filament unusable.

You can delay these problems a lot by storing filaments in an enclosed container and adding some desiccant helps even more. But eventually, any filament will get humid enough to need drying.

The Most Common Solution

On the surface, this looks like a solved problem: e.g. Sunlu dryer boxes work well and are not that expensive. But this kind of dryer box is not without problems:

• They are not cheap, a two-roll box will cost you about ~90€. If you are serious about printing, you will need at least two of those.
• They have 150-200W heaters. If you are paying German electricity prices, each day you use one will cost ~1-2€. And each year has 365 days…

So is there a different way?

How Does Drying Even Work?

The Usual Dryer Boxes

The dryer boxes I mention above work by heating up the air. Hotter air can carry more moisture (relative humidity is reduced) and this “sucks” moisture from the filament due to osmosis (which happens faster due do higher temperature as well). The hot and humid air is then blown out of the enclosure automatically or you need to do it manually after the end of each cycle. Some will take advantage of moisture condensing on the cooler walls, which you must then wipe down.

See this explanation for extra info.

The Proper Way To Dry Things

If you look at industrial dryers or modern clothes dryers, these work differently.

The first step of the process is the same: Blow hot air into the chamber to capture the humidity. The next step is very different, though: The hot humid air is cooled, which causes the excess moisture to condense away, leaving you with dry cool air that you can then heat up again to dry the filament, in an endless circle.

At first glance, this seems like a very wasteful process: instead of simply heating the air, you need to cool it too. But here comes the magic part: You can use a heat-pump to transfer the heat from cooling to the heating part of the cycle. A modern heat-pump is extremely efficient and will only consume about 25% of energy it is able to transfer. So if you need 200W of heating power, you will only need about 40W of electricity for the same effect. What is more, because you are cooling the return air, the return air is very dry and the drying effect is even stronger.

My Solution

The parameters

I wanted a solution that does the following:

• There should be enough space for at least 10 rolls of filament.
• It should be able to work continuously, no wiping down etc.
• It should consume no more than 50W of electricity (a quarter of the consumption of a normal dryer)
• Some monitoring would be nice

The hardware

There are many possibilities:

I could possibly build a really big dryer out of a second-hand clothes-dryer. My neighbor and I actually converted one into a big fruit dryer so his apples and plums don’t spoil after the harvest. But while this is a good way to dry out large amounts of moisture, filaments only contain a few grams of moisture each at most and the dryer will consume 700W of electricity. So this would be a really wasteful way of doing it and it would take up a lot of space.

Maybe a mini fridge? I could use an air duct to heat up the air at the rear heat-exchanger, blow it into a box, and then return it to the cold side of the mini fridge. But this would take extra space and I’m not sure how to cool the air effectively.

In the end I decided to buy a very simple and very cheap room air-dryer on Aliexpress. These small units will consume about 15W and dry out a couple of tens of grams of moisture a day from the surrounding air.

They use a Peltier element instead of a proper heat-pump, but since we need so little drying capacity, this is good enough. The Peltier element, the two heat-sinks and the fan are combined into one compact unit like this:

There is also a power-supply, so you only need some more fans, a control board and a new housing.

The Box

I decided to use a simple plastic storage box I kept the filaments in already. IKEA is a good place to find one that is large enough for your needs. Mine is about 40 x 50 x 60 cm, enough for about 12 rolls.

The Housing

My idea was to put the entire Peltier block along with two temperature sensors (DS1820, hot and cold side), a humidity sensor (AHT20, for monitoring) and two fans (hot and cold side) inside the box as a drying unit.

A small hole in the side of the box connects this drying unt with the control box outside. The control box contains the power supply, an ESP8266 controller and a couple of relays for control.

There is also a small outlet for the condensed water on the bottom of the cold side housing. This is connected to a small tube and routed outside the box.

Here is the Fusion project, if you want to play with it.

The First Prototype

Control

I decided to use ESPHome and integrate it into my Home Assistant system to control the whole thing.

The first version was over-engineered, with PWM control of both fans and measurements on hot and cold side. It turns out you only need to monitor humidity and control two relays, one for the Peltier element and the hot side fan, the other for the cold side fan. You could even do without the cold side fan at the expense of a slightly lower drying power.

The Algorithm

The algorithm is simple:

1. Turn on the Peltier and the hot side fan.
2. Wait for a while for the water to condense on the cold side. (The hot side fan is strong enough to ensure the circulation on the cold side too.)
3. Turn off the Peltier and turn on cold side fan to blow the water off the heat sink ribs down into the water outlet. A minute is enough. This is optional, water will drip down on it’s own until there is very little moisture left.
4. Repeat.

It also needs a safety feature to turn off the whole thing if the hot side heats up above 45 °C (i.e. fan problems).

I also added an automation that only turns the dryer on when there is extra power available from the solar plant I have installed. This is optional, but it does keep the whole thing from taking energy from the grid.

Final Thoughts

The whole thing cost me about 70€ at most and it works. There is one drawback: It takes a few days to dry a moist filament roll, but it keeps everything nice and dry afterwards. It seems that putting in a moist roll does not affect the rest of the stored rolls at all.

The ESPHome Code and Planned Improvements

Planned improvements

The code is for the current over-engineered system. The next version will have no PWM, no cold side fan, and no cold side temperature sensor. The hot side fan power will be fixed using a resistor. There will be only one relay that controls both the Peltier and hot side fan. The power supply will be next to the hot side fan to use the wasted energy to heat the box.

The Code

esphome:
  name: susilnik
  friendly_name: susilnik

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "secret"

ota:
 —platform: esphome
    password: "secret"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  use_address: secret

one_wire:
 —platform: gpio
    pin: 13

sensor:
 —platform: aht10
    temperature:
      id: temperatura
      name: "Temperatura"
    humidity:
      id: vlaznost
      name: "Vlaznost"
    update_interval: 60s
 —platform: dallas_temp
    address: 0x090417b10b0cff28
    name: "Temperatura topla stran"
    id: temperatura_topla_stran
 —platform: dallas_temp
    address: 0x690517a0c505ff28
    name: "Temperatura hladna stran"
    id: temperatura_hladna_stran

i2c:
  sda: 4
  scl: 5
  frequency: 10kHz

switch:
 —platform: gpio
    pin: 16
    name: "Vklop 12V"
    id: vklop_12v
    restore_mode: ALWAYS_ON

output:
 —platform: esp8266_pwm
    pin: 12
    frequency: 10 Hz
    id: pwm_hladni_ventilator
 —platform: esp8266_pwm
    pin: 14
    frequency: 10 Hz
    id: pwm_hladilni_ventilator

fan:
 —platform: speed
    output: pwm_hladni_ventilator
    name: "Hladni ventilator"
    id: hladni_ventilator
 —platform: speed
    output: pwm_hladilni_ventilator
    name: "Hladilni ventilator"
    id: hladilni_ventilator

time:
 —platform: homeassistant
    id: homeassistant_time
    on_time:
      #Safety functions
     —minutes: /1
        seconds: 0
        then:
          if:
            condition:
              switch.is_on: vklop_12v
            then:
             —if:
                  condition:
                    or:
                     —sensor.in_range:
                          id: temperatura_topla_stran
                          above: 45
                     —sensor.in_range:
                          id: temperatura
                          above: 40
                  then:
                    switch.turn_off: vklop_12v
     —minutes: 55
        seconds: 0
        then:
          if:
            condition:
              switch.is_on: vklop_12v
            then:
              fan.turn_on:
                id: hladni_ventilator
                speed: 50
     —minutes: 57
        seconds: 0
        then:
          fan.turn_off: hladni_ventilator
      #Start cooling fan for PSU
     —minutes: /1
        seconds: 0
        then:
          if:
            condition:
              switch.is_on: vklop_12v
            then:
              fan.turn_on:
                id: hladilni_ventilator
                speed: 50
            else:
              fan.turn_off: hladilni_ventilator

If you found this article useful, you can buy me a beer here.

What Do I Mean by Low Power?

I was involved in an art project where we wanted to use a smallish (10 x 15cm) solar panel to power an e-paper display inside a gallery, controlled by an ESP32 micro controller.

This would be a pretty trivial job outdoors: the panel has 5W peak power and I could just put a small DC-DC converter on it to get stable 3.3V power from it during normal daylight.

Indoors, the game changes completely, due to two main issues: low illuminance and low solar panel efficiency at low illuminance.

Outdoors, the illuminance will be anywhere from 1000 to 100000lux during the day. On the other hand, normal indoor lighting would normally range from 100 to 500lux. This alone reduces the available power from the solar cell by a factor of 200 or more. 5W turns into 25mW.

But there is another problem: The solar panel efficiency drops at low light. At full illuminance, the total power conversion efficiency of a modern solar panel can exceed 20%, but the same panel will have a much lower efficiency at low light due to interior current leakage. The expected 25mW turns into 5 or 10mW at most with normal indoor lighting.

To put this in perspective: ESP32 will consume somewhere around 900 mW transferring data via WiFi and some 20 to 70 mW with radio off. See this helpful article.

So is there no way to power the ESP32 using our solar panel?

The Solution

Our project involves refreshing an e-paper display at certain intervals and e-paper consumes power only during the refresh (drawing). So the solution is to somehow store the miniscule amount of available energy until there is enough to draw the next picture, turn everything on, draw the picture, save the data for the next one, and power off.

The Hardware

On the hardware side, I achieved this using a solar harvester chip AEM10941 evaluation board that very efficiently charges a single super-capacitor. This super-capacitor in turn powers a low-power, low-voltage boost converter and this powers the ESP32.

The Software

But the hardware alone is not the solution yet: I needed a way to turn off everything so the harvester has the chance to charge the capacitor up, do the drawing only when the capacitor is full and then turn off everything again until there is enough power available.

ESP32 Deep Sleep

The solution is to implement the deep sleep on the ESP32. While in deep sleep, the ESP32 chip only consumes 10μA, but it powers off almost everything, leaving only a small portion of slow RTC RAM and a counter that periodically wakes it up.

So how does it all work?

1. The system spends most of the time in deep sleep, where the combined power usage of the power harvesting system, converter and ESP32 never exceeds about 150μW.

2. Every 5 or 10 seconds it wakes up for a fraction of a second to measure the capacitor voltage:

   2a. If the voltage is not high enough, it goes to deep sleep again.

   2b. If the voltage is high enough, it draws the picture, stores the sequence number into the RTC RAM and goes to deep sleep again.

3. Rinse and repeat.

Pick the Right ESP32 Board!

There is a possible pitfall here: Some ESP32 development boards, like the basic ESP32 Dev Module, power additional circuitry (level converters, USB-to-RS232 chips etc.) from the 3.3V rail. This means they will always use at least 10mW of power, regardless of the deep-sleep mode, which is useless for our use case. I had really good experience with the Olimex ESP32-DevKit-LiPo boards in this respect, but there are other well built development boards out there.

There Are Always Unintended Consequences

Remember how the chip powers off almost everything when in deep sleep? All the regular RAM contents are lost too, only the sequence number in RTC RAM remains. So when I try to draw the next picture, the system doesn’t know a picture was already drawn previously and simply draws over it. The results are really ugly:

I spent way too much time thinking how to fix this…

One option would be to use a full refresh, but that would entail the annoying blinking of the whole display. Then I thought about adapting the library and storing some of it’s variables in the RTC RAM. This seemed like a sure way to lose all my remaining hair, though.

After a lot of thinking, I finally thought of a nice hack. The system doesn’t know what was displayed previously? I should draw the exact same picture as the last time to “refresh it’s memory” and right afterwards draw the new one.

This worked beautifully:

Conclusion

Super-capacitors are a wonderful way to power small devices that work at intervals when there is not much power available. They are preferable to batteries due to their much better cycling ability. I like things that you can put on a wall and expect them to work for years and years instead of becoming electronic waste soon.

And if you use deep sleep with ESP32, always keep in mind the lost RAM contents when the chip wakes up again.

The Code

#include <GxEPD2_BW.h>

#include "GxEPD2_display_selection_new_style.h"

#include "bitmaps/images.h"
#include <pgmspace.h>

#include <driver/adc.h>
#include <esp_sleep.h>

RTC_DATA_ATTR int pic_index = 0;
const int adcPin = 34; // GPIO34 (ADC1_CH6)
const int sleepTimeSeconds = 3; // Sleep time in seconds
const int array_size = sizeof(images)/sizeof(images[0]);
const int refresh_size = 30;

void setup()
{
  // Configure ADC
  adc1_config_width(ADC_WIDTH_BIT_12);
  adc1_config_channel_atten(ADC1_CHANNEL_6, ADC_ATTEN_DB_11);
  
  // Read the voltage on pin 34
  int adcValue = adc1_get_raw(ADC1_CHANNEL_6);
  float voltage = adcValue * (3.3 / 4095.0); // Convert ADC reading to voltage

  if (voltage>2.45) { // Only if voltage is high enough
    if (pic_index%refresh_size == 0 || pic_index%array_size == 0) {
      display.init(0, true, 2, true); // first update should be full refresh
    } else {
      display.init(0, false, 2, true); // following updates should be normal refresh + draw previous picture to avoid artifacts
      display.drawImage(images[(pic_index-1)%array_size], 0, 0, 400, 300, false, false, true);
    }

    display.drawImage(images[pic_index%array_size], 0, 0, 400, 300, false, false, true);
  
    display.hibernate(); //Turn off voltage converters inside the display to save power

    pic_index++;
  }

  // Configure the ESP32 to wake up after a fixed delay
  esp_sleep_enable_timer_wakeup(sleepTimeSeconds * 1000000);
  esp_deep_sleep_start();
}

void loop()
{
}

If you found this article useful, you can buy me a beer here.

If you’ve been reading my DIY EV Charging Point Basics post, you probably wonder how all the options mentioned might be distilled into a practical DIY project. This post describes a charging point I actually built. I will explain why and how I made the individual choices, list an actual BOM, describe how everything is connected and even give you the configuration files I used in the first version.

Design Objectives

Some Background

I built this charging point for a neighbor friend who recently, after some deliberation, decided to start driving an EV in the best possible way for “beginners”: He bought a used short-range EV he uses as the “second car” to drive to work and do errands (he has a big family, so there are many errands to take care of). This saves him a ton of gas money and the objectively better driving experience is simply the icing on the cake.

Until now, he was using the charging cable he got with the car, but this was slow (only half the available charging power) and he had no handy sockets to plug it in, forcing him to use an extension cord. So we talked and I offered to help him build a proper Type 2 charging point, enabling him to use the full charging power and avoid dealing with the “cable salad”, while having everything properly prepared for the next EV that is sure to come in time. We sat down, talked and decided what to build.

Parameters

• He does not have a smart home solution, so the solution had to be standalone.
• We decided it would be best if we installed it on the outside wall of his house, next to his driveway.
• To keep the charging point visually clean, we would use a socket, not a cable.
• Although his present car only has a one-phase internal charger, we decided to build a full three-phase charging point, since the difference in costs is minimal and we wanted to keep everything future-proof.
• With 3x 20A distribution fuses, dynamic current control was a must.
• He needs minimal access control, a switch in the house was enough.
• There should be some easy way to charge only at night, when energy is cheaper. But there should also be an option to charge at any time to top up the car when needed.

Design Choices

After the parameters were set, it was relatively easy to decide on the final solution:

• I decided to use the SimpleEVSE controller to take care of the SAE J1772 standard signalling and control since I had good experience using it in the past.
• I would use a ESPHome controller, connected to the WiFi to control the EVSE controller (current and time control, monitoring).
• The charging point would have it’s own weatherproof switchboard on the outside wall, containing the fuse, relay, EVSE controller and the ESPHome controller. The socket would be built right next to it.
• He had some space left in an auxiliary switchboard inside the house, so we would put the RCD switch there, so it can also serve as an access control switch to turn off the whole charging point when needed.
• We would install a cheap smart electricity meter in the main switchboard to measure the currents on distribution fuses. Since this switchboard is on the other side of the house and wiring an extra data transfer cable to the charging point would be a problem, I decided to read it using a separate ESPHome controller connected to the home WiFi network.

The Actual Build

In our case, the system is housed in two small boxes, but if your installation allows, you could connect the energy counter directly to the charge control ESPHome controller, saving yourself one extra ESPHome controller and getting better reliability.

BOM:

Current Supervisor:

• Wiring box as your situation requires
• An energy meter with Modbus interface, e.g. this one or this one
• RS485 to 3.3V converter, e.g. this
• ESP8266 or ESP32 module, e.g. this
• A 5V power supply

Charge Control Unit:

• Wiring box
• RS485 to 3.3V converter, e.g. this
• ESP8266 or ESP32 module, e.g. this
• 12V to 5V DC-DC converter, e.g. this
• EVSE DIN controller, buy it here, the have many other parts for this project too
• 4-pole contactor, like this one
• A RCD, type B, like this one
• A MCB (fuse), 16A B-type in our case
• A 4P T2 surge protecting device (SPD), like this one
• A type 2 socket, like this one

Build Instructions

Use the schematic as your guide. Be careful about proper grounding, correct wire and component sizing, weatherproofing, wiring screw torques etc. DIN-rails are your friend.

You should have enough experience with electric projects to be able to build and customize this from the data I provided. If you don’t, it’s likely you are not able to build it safely on your own, so talk to people who understand it better.

Example Code for the Two ESPHome Controllers

Current Supervisor:

esphome:
  name: stevec

esp8266:
  board: d1_mini
  
# Disable logging to be able to use Modbus
logger:
  baud_rate: 0

ota:

wifi:
  networks:
 —ssid: "ssid"
    password: "pass"

web_server:
  port: 80

uart:
  id: mod_bus
  tx_pin: GPIO1
  rx_pin: GPIO3
  baud_rate: 9600
  stop_bits: 1
  parity: even

modbus:
  id: modbus_stevec
  send_wait_time: 200ms
  flow_control_pin: GPIO5

modbus_controller:
 —id: stevec
    address: 24
    modbus_id: modbus_stevec
    update_interval: 5s
    setup_priority: -10

sensor:
  #Template sensor
 —platform: template #Max phase current, will be written by lambda
    name: "TokMax"
    id: tokmax

  #Readouts of individual phase currents from the smart meter
 —platform: modbus_controller
    modbus_controller_id: stevec
    id: tokr
    name: "TokR"
    address: 0x0008
    unit_of_measurement: "A"
    register_type: "read"
    value_type: FP32
    accuracy_decimals: 1
    filters:
     —sliding_window_moving_average:
          window_size: 6

 —platform: modbus_controller
    modbus_controller_id: stevec
    id: toks
    name: "TokS"
    address: 0x000A
    unit_of_measurement: "A"
    register_type: "read"
    value_type: FP32
    accuracy_decimals: 1
    filters:
     —sliding_window_moving_average:
          window_size: 6

 —platform: modbus_controller
    modbus_controller_id: stevec
    id: tokt
    name: "TokT"
    address: 0x000C
    unit_of_measurement: "A"
    register_type: "read"
    value_type: FP32
    accuracy_decimals: 1
    filters:
     —sliding_window_moving_average:
          window_size: 6


time:
 —platform: sntp
    id: sntp_time
    on_time:
      # Every 10 seconds do readout of max phase current
     —seconds: /10
        then:
         —lambda: |-
              id(tokmax).publish_state((id(tokr).state > id(toks).state) ? ((id(tokr).state > id(tokt).state) ? id(tokr).state : id(tokt).state) : ((id(toks).state > id(tokt).state) ? id(toks).state : id(tokt).state));              

This is simple: We talk to the Modbus electricity meter every 10 seconds to get the three currents. We do a moving average to keep track of fast current changes. The result (largest average current) is available over HTTP API.

Charge Controller:

esphome:
  name: evse

esp8266:
  board: d1_mini

# Disable logging to be able to use Modbus
logger:
  baud_rate: 0

ota:

http_request:
  useragent: esphome/ESP8266
  timeout: 10s
  esp8266_disable_ssl_support: yes #to prevent OTA filing
  id: http_request_data

wifi:
  networks:
 —ssid: "ssid"
    password: "pass"

web_server:
  port: 80

uart:
  id: mod_bus
  tx_pin: GPIO1
  rx_pin: GPIO3
  baud_rate: 9600

modbus:
  id: modbus_evse

modbus_controller:
 —id: evse
    address: 0x01
    modbus_id: modbus_evse
    update_interval: 30s
    setup_priority: -10

sensor:
 —platform: template #Max phase current, will be written by lambda
    name: "TokMax"
    id: tokmax

  #EVSE sensors
 —platform: modbus_controller
    modbus_controller_id: evse
    id: set_charge_current
    register_type: holding
    address: 1000
    value_type: U_WORD
    name: Set Charge Current
    unit_of_measurement: A
    device_class: current
    state_class: measurement
    accuracy_decimals: 0

 —platform: modbus_controller
    modbus_controller_id: evse
    id: vehicle_state
    register_type: holding
    address: 1002
    value_type: U_WORD
    name: Vehicle State
    accuracy_decimals: 0

 —platform: modbus_controller
    modbus_controller_id: evse
    id: ctrl_bits
    register_type: holding
    address: 1004
    value_type: U_WORD
    name: Control Bits
    entity_category: diagnostic
    disabled_by_default: true

 —platform: modbus_controller
    modbus_controller_id: evse
    id: evse_state
    register_type: holding
    address: 1006
    value_type: U_WORD
    name: EVSE State
    accuracy_decimals: 0

#Manual current setting slider
number:
 —platform: modbus_controller
    modbus_controller_id: evse
    id: set_charge_current_input
    address: 1000
    value_type: U_WORD
    name: Set Charge Current (Input)
    unit_of_measurement: A
    min_value: 0
    max_value: 16
    step: 1
    use_write_multiple: True
    write_lambda: |-
      if (x > 0 && x < 6) {
        return 6;
      }
      return x;      

#Switch for turning EVSE on or off. Note the negated function: switch on = EVSE off!
switch:
 —platform: modbus_controller
    modbus_controller_id: evse
    id: disable_charging
    name: Disable Charging
    use_write_multiple: True
    register_type: holding
    address: 2005
    bitmask: 16384

#Template binary sensor for enabling/disabling the whole EVSE system, used for time scheduling to reduce electricity costs
 —platform: template
    name: Enable
    id: enable
    restore_state: true
    optimistic: true
    turn_on_action:
     —switch.turn_off: disable_charging
    turn_off_action:
     —switch.turn_on: disable_charging

#Readouts and automation
time:
 —platform: sntp
    id: sntp_time
    on_time:
      # Every 30 seconds do readout of max phase current
     —seconds: /30
        then:
         —http_request.get:
              url: http://stevec.local/sensor/tokmax
              headers:
                Content-Type: application/json
              verify_ssl: false
              on_response:
                then:
                 —lambda: |-
                      json::parse_json(id(http_request_data).get_string(), [](JsonObject root) {
                        id(tokmax).publish_state(root["value"]);
                      });                      
      # Every 5 minutes do current control
     —seconds: 0
        minutes: /2
        then:
         —lambda: |-
              //Current limits of system
              const float max_phase_current=20, max_charge_current=16, min_charge_current=6;
              //Only do current control if EVSE is ON
              if (!id(disable_charging).state) {
                //Only do current control if max phase current is too high or charge current setting is reduced (plus offset to prevent corrections under 1A, which have no effect)
                if ((id(tokmax).state > (max_phase_current + 0.5))||(id(set_charge_current).state < max_charge_current)) {
                  //If max phase current is too high (plus offset)
                  if (id(tokmax).state > (max_phase_current + 0.5)) {
                    //If current is low enough to limit properly
                    if (id(tokmax).state < (max_phase_current + id(set_charge_current).state—min_charge_current)) {
                      //Reduce current setting by exactly the excess current
                      auto call = id(set_charge_current_input).make_call();
                      call.set_value(id(set_charge_current).state—(id(tokmax).state-max_phase_current));
                      call.perform();
                    } else {
                      //Turn off EVSE to cool everything off
                      id(disable_charging).turn_on();
                    }
                  } else if (id(set_charge_current).state < max_charge_current) {
                    //Increase current setting by exactly the unused current capacity
                    if ((id(set_charge_current).state—(id(tokmax).state-max_phase_current)) < max_charge_current) {
                      auto call = id(set_charge_current_input).make_call();
                      call.set_value(int (id(set_charge_current).state—(id(tokmax).state-max_phase_current)));
                      call.perform();
                    } else {
                      //Or set maximum charge current
                      auto call = id(set_charge_current_input).make_call();
                      call.set_value(max_charge_current);
                      call.perform();
                    }
                  }
                }
              }              

      # Every 15 minutes turn EVSE back on
     —seconds: 0
        minutes: /15
        then:
         —if:
              condition:
                lambda: |-
                  return id(enable).state;                  
              then:
               —switch.turn_off: disable_charging

This is the main functionality. We set up the Modbus communication with the EVSE controller and prepare the necessary variables to control it. My neighbor did not want to have the whole Home Assistant setup, so the control works via a slider in the inbuilt web server.

The control principle is simple – if the average max current exceeds the permitted maximum, the charging current is set to a lover value. E.g. with 20A limit, if the actual phase current is 22A and the set charging current is 16A, the charging current is reduced by 22-20 = 2A, e.g. to 14A. If there is headroom (a big load has disconnected), the charging current is set higher in the same way. This repeats every 5 minutes.

In extreme cases, where the charging current would have to be reduced under 6A (minimum for the EVSE standard), the charging point is turned off until the next 15 minute interval. This should cool off the fuses enough. Keep in mind that normal fuses should hold a significant overload for tens of minutes (standard requirement is: blow in less than one hour for 45% overload, over one hour for 13% overload).

All that is left is a simple option to turn the whole thing on or off via a switch in the web server or an API call.

Final Notes

This was intended as an illustration of how to build a safe EV charging point with dynamic current control. There are literally thousands of ways how you could go about achieving this, but the general outline will always be the same:

Measure current coming into your home, compare to limit, set charging current, repeat. Turn off EVSE for 15 minutes, if load is too damn high 😉

This could be thought of as trivial, but there is an important point here: if you buy a ready-made charging point, it needs to dynamically control the charging current! If you buy a “dumb” charging point, you are going to be paying for blown fuses at least some of the time and extra power capacity all the time.

If you found this article useful, you can buy me a beer here.

Why DIY an EV-charging Point?

• It’s fun to build things yourself 🎉
• You can save some money 💰
• You have so much freedom: how it looks, how it works, it’s almost entirely up to you 🤓

Disclaimer

Unless you know how to DIY some serious electrical installations on your own AND have done that before, DO NOT start building a charging point. A short list of things that could go wrong: fire, electrocution, blown mains fuses, blown built-in car charger…

Adults with electrical engineering background only!

What To Build?

Just a Charging Cable

It’s hard to make a reliable current limiting solution this way, so it’s probably not worth the extra effort – just buy a standard one.

But it can be a worthwhile option if you need to repair a dead charging cable. Just buy a SimpleEVSE controller, a 2-pole relay, and a power supply and put it in the old charging cable casing. Please don’t forget to put a Type A RCD on the supply side cable to keep it safe – you never know what’s behind a socket you did not install yourself.

A Full-blown Type 2 Charging Point

This is where all the options are: current limiting, automation, access control, visual design, cable v. socket, integration, automation…

Options

Current Limiting

I think it’s not an option, actually. Either:

• You risk blowing the distribution fuses every time you forget you are charging a car and you turn on an electric oven or another large load for more than a few minutes.

Or:

• You pay through the nose for bigger distribution fuses.

  Where I live, the standard option is 230V, 3x 20A. Most EVs now have 3x 16A or larger built-in charger. This gives you 4 amps of headroom. Any significant appliance like an oven, washing machine, vacuum, cooking plate, microwave, etc. puts you in the danger zone. So, if you want to be sure, you need at least 35A fuses. This is costly for several reasons:

  • First of all, bigger fuses directly increase your electric bill even before you use any extra power. In EU, the difference will be on the order of several hundred euros per year.

  • You will have to pay for the change and take care of the paperwork.

  • Your existing house connection likely does not have big enough cabling so you need to upgrade this as well.

  • Your local transformer station could already be loaded to the limit and you can’t even get the extra capacity even if you are willing to pay for it.

The downside to current limiting is a slightly more complicated installation and charging will sometimes take a little longer when you have big loads turned on in your house.

Cable or Socket?

My preference is clear: use a socket.

Pros: It looks cleaner (no “elephant trunk” on your wall), it’s easier to weatherproof, and every EV owner owns a Type 2 charging cable.

Cons: You have to take the cable out of your car before you plug it in. But when you come home, you usually have to take groceries etc. out of the car anyway, so it’s not a big deal.

Access Control

I think most people reading this own a house and are thinking about building a charging point of their own in their own driveway or garage. If this is the case, you don’t need access control unless you live in a really rowdy neighborhood. Let’s face it, most people will not park a car in a driveway belonging to someone else, much less hook up a charging cable unless they REALLY need it. Even if they do, this will cost you a few euros at most. If you are in this situation, you can probably afford a few euros – we should look out for each other, when we can.

Nevertheless, if you need access control, it’s quite easy to arrange and you have several options:

• The standard solution seems to be RFID. This is an easy option to implement, you just need a RFID reader:
  • Most RFID-readers have the option to simply hard wire an output to the device you want to control. In this case, any EVSE controller should have an input pin to control. Just program your reader, connect the output to the controller and you are done.
  • You could use the SimpleEVSE-Wifi solution – a simple ESP8266 board you can connect your RC522 RFID-Reader to. It takes care of access control and many other things as well.
• You could control the charging station via your Home Assistant system. A simple switch there can turn your charging point on or off, but you can also do so much more – time control, control according to your photovoltaic plant production, the possibilities are endless.
• Just wire a simple key-controlled switch, hooked to the enable input of your EVSE controller. Install a switch inside your home and connect it to your EVSE controller. It could even be just your RCD switch. Turn on when needed.

What Hardware To Use

Electrical Components

Any charging point needs these at a minimum:

• An RCD protection switch, type B.

  This is expensive, but important! A regular RCD (type AC) could fail to protect you in case your car charger fails in a way that makes the fault current non-sinusoidal (e.g. leakage on only one leg of the rectifier). A type B RCD is a more expensive, but it will reliably trip for DC fault currents as well, which are unlikely, but possible in case of catastrophic damage of the built-in charger in the EV. It is also required by the relevant standard (IEC 60364-7-722:2018). Current capacity should be equal to or larger to your fuse rating. Trigger current should be according to your country standard (30mA for me).

• A fuse.

  A regular installation fuse with the same nominal current you want the charging point to have, type A or B (no need for starting current protection).

• A relay.

  A relay (or a contactor) that breaks all the phases AND the neutral. E.g. for a 3-phase charging point you need a 4-pole relay. Nominal relay current should be at least 120% of the nominal fuse current. (E.g. for a 16A charging point, use at least a 20A relay.)

• A surge protection device.

  An over-voltage protection device, type 2, 2-pole for 1-phase and 4-pole for 3-phase charging points. If your car is not protected from lightning (e.g. away from the building, no roof, etc.), use T1+T2.

• An enclosure.

  It’s best to put all of these in an enclosure with a DIN rail. If the enclosure is exposed to the elements, it needs at least an IP55 rating. Some people prefer to put their RCD switch inside the house, so they have an easy way to turn off the entire charging point there as a kind of access control.

• Cable or socket.

  Also expensive, but you don’t want to skimp here, since it is subject to wear. I usually put it next to the enclosure and build an extra sturdy bracket for it – it takes some force to plug and unplug the Type 2 cable.

The EVSE Controller

You could implement everything using a simple ESP8266 board and some peripherals. But unless this is something you dream about doing, I would very much recommend you go modular: Buy a proven EVSE controller to do all the SAE J1772 standard signalling and control (pilot signal, current control, relay control, enable/disable).

A good option is the Simple EVSE open source project. You can build it yourself or buy a built module at GWL. I built three chargers using their kit already and can recommend them (they have sockets, cables, relays, etc. too). But there are other options too: OpenEVSE, DehneEVSE, smartWB, and others.

You could also buy a ready-made charging point – you can now buy them at hardware stores. But you will a) overpay for the components you get and b) lose a lot of flexibility. Always go open-source when you can, it will save you trouble in the long run (when the supplier decides to stop supporting it).

The Charging Point Controller

The EVSE controller will take care of the signalling and turning the relay on or off. But what about current control, access control, automation, supervision, energy metering, cost counting etc.? This is where it gets interesting. You have many options:

No Extra Controller

If you don’t want any of the above options, just build a dumb charging point. You need a RCD, fuse, EVSE controller, relay and a socket/cable. It will work, but read about the options to understand why this may not be a good idea.

Ready Made Integrated Solution

Some solutions, like OpenEVSE and smartWB, already take care of some of these options. In essence, they contain both the EVSE controller and the charging point controller. But in my opinion the extra cost is not worth it now that we have ESPHome to play with. Just read their githubs and send these awesome guys some beer money via the donation link, they deserve it.

Simple EVSE-WiFi

A simple ESP8266-based solution with an in-built web server for the Simple EVSE charging controller that will take care of:

• Default functions:
  • Turning the charging point on or off
  • Setting the charging current
  • Charge logging
  • Control of the SimpleEVSE charging controller registers
  • HTTP API for automation
• Optional functions:
  • With added RC522 RFID-Reader:
    • Authentication
    • User management
  • With an added S0 or ModBus energy meter:
    • Measuring charging power
    • Metering charged energy (included in log)

You will need to control the current via the API if you want current limiting. This is easily achievable e.g. in Home Assistant, where you probably already have a smart energy meter integrated. Use the REST service integration.

ESPHome

A truly versatile solution that works with an ESP8266 or ESP32 board. It is extremely convenient, you simply program your ESP board via USB once and then you can change the configuration any time using OTA via WiFi. You simply change the YAML file and run the upload program.

The magic of ESPHome is it can work standalone very well, but it is also EXTREMELY easy to integrate into Home Assistant. Whatever hardware you choose to integrate into your charging point (energy meter, sensors, RFID, display, buzzers, LEDs, etc.), you simply add to the YAML configuration file using provided integrations. You can then link these directly using automations within ESPHome or indirectly in Home Assistant.

Conclusion

These are some of the options and things you need to know if you want to build a homebrew EV charging point. In the next post, I present an example solution using ESPHome that includes current limiting and works standalone.

If you found this article useful, you can buy me a beer here.