A few months ago, I started working on an MCU Card design, which borrows from the idea of a standard desktop PC, in which there are a main-board, MCU and expansion slots, to add and remove peripherals as needed quickly.
The ESP-12E Card is a continuation of that project, with the ultimate goal to have a universal “main-board” that can accept various MCUs and standardised “expansion modules” that perform a specific task.
ESP-12E Card
The PCB
The ESP-12E Card contains the bare minimum components to allow the chip to function. There are no power regulators or USB-to-TTL converters onboard. Code is flashed via an external USB-to-TTL converter, with Flash and Reset buttons on the actual PCB, or available in the 2×20 Pin female header at the bottom of the card.
Most of the GPIO is also broken out to the 2×20 pin header, with the exception of the 6 GPIO that is usually connected to the internal Flash on the ESP-12E module.
I have made provision for enough power and ground pins on the header as well.
As far as GPIO is concerned, They have been grouped together by function, as much as possible at least, to make interfacing with the base-board as easy as possible.
The Schematic
ESP-12E Card Schematic
The schematic is not complicated. It is a standard ESP-8266 configuration, with all non-essential components removed.
The “base-board” ( a sneak preview )
Sneak preview of the Base Card
In a future article, I will tell you more about this ( for the time being limited to I2C ) base card. [ a quick explanation: When I mean limited to I2C, it relates to the fact that at the moment, the base card, ( a prototype ) can only communicate back to the MCU via I2C protocol from each of the expansion slots, as well as via two dedicated IRQ lines from each slot ]Power is supplied via a small SMPS module.
Manufacturing the PCB
Over the past eight years, PCBWay has continuously upgraded their MANUFACTURING plants and equipment to meet higher quality requirements, and now THEY also provide OEM services to build your products from ideas to mass production and access to the market.
The PCB for this project has been manufactured at PCBWay. Please consider supporting them if you would like your own copy of this PCB, or if you have any PCB of your own that you need to have manufactured.
If you would like to have PCBWAY manufacture one of your own, designs, or even this particular PCB, you need to do the following… 1) Click on this link 2) Create an account if you have not already got one of your own. If you use the link above, you will also instantly receive a $5 USD coupon, which you can use on your first or any other order later. (Disclaimer: I will earn a small referral fee from PCBWay. This referral fee will not affect the cost of your order, nor will you pay any part thereof.) 3) Once you have gone to their website, and created an account, or login with your existing account,
4) Click on PCB Instant Quote
5) If you do not have any very special requirements for your PCB, click on Quick-order PCB
6) Click on Add Gerber File, and select your Gerber file(s) from your computer. Most of your PCB details will now be automatically selected, leaving you to only select the solder mask and silk-screen colour, as well as to remove the order number or not. You can of course fine-tune everything exactly as you want as well.
7) You can also select whether you want an SMD stencil, or have the board assembled after manufacturing. Please note that the assembly service, as well as the cost of your components, ARE NOT included in the initial quoted price. ( The quote will update depending on what options you select ).
8) When you are happy with the options that you have selected, you can click on the Save to Cart Button. From here on, you can go to the top of the screen, click on Cart, make any payment(s) or use any coupons that you have in your account.
Then just sit back and wait for your new PCB to be delivered to your door via the shipping company that you have selected during checkout.
CAN-Bus allows us to add a lot of devices to a single bus (theoretically up to 127, with a practical limit of about 110). It was logical to decide to use CAN-BUS for communication between my LoRa-CAN Module and remote nodes in my ongoing farm telemetry system. In a previous project, I introduced the LoRa-CAN Gateway, which will be used to send/receive messages from the master control unit, the SX127x-RA-02-Module.
Today, I will focus on the design of the node device, an Arduino compatible CAN Relay Module PCB, with a built-in, CAN Controller and Transceiver ( MCP2515 and TJA1050 ), and the option to be powered from a LiPo battery (18650 or Single 3.7v Lipo cell), with charging provided by an MH-CD42 Module, similar to that used in the SX128x project mentioned above. The Module can also be powered directly from up to 12v DC by placing Jumper H2 in the V-REG position…
As mentioned in a previous project, the MH-CD42 module can provide up to 2A of current to charge a battery and provide 5V DC on a direct bypass circuit to power the rest of the circuit while the battery is being charged. This feature makes it ideal for my intended use, as I would only be needing battery power at night when the off-grid solar powered inverter is not actively charging the main batteries, and providing 220v AC.
The CAN Relay Module PCB was designed to be as compact as possible, with a total footprint of the standard Arduino UNO. As space was at a premium, and to ensure that there are the absolute minimum additional components that will consume power when operating from the battery, I have not included any USB-to-Serial converters onboard. Firmware can be uploaded with an AVRASp, USBASP, Arduino as ISP or even an external USB-to-Serial converter ( providing that you load a bootloader into the Atmega Chip).
All of the unused GPIO pins on the ATMEGA chip is broken out into headers, with the exception of D10 ( which is used as CE/SS on the MCP2515 CAN controller), D9 which is connected to the Interrupt from the MCP2515, and D4, which is used to control the onboard Relay.
The MH-CD42 Module, and LiPo or 18650 Battery are completely optional, The device can function without these, by moving the H2 jumper to the VREG position as already mentioned above. This will divert the DC Voltage(Up to 12v) from the DC input adapter to the build-in 5v LDO voltage regulator to power the device.
If you place the H2 Jumper in the VBAT position, you need to install the MH-CD42 module to provide power to the rest of the PCB, as well as keep the LiPo battery or 18650 Cell charged…
Please NOTE:
When the MH-CD42 module is in use, the total DC input voltage through the DC input adapter SHOULD NOT exceed 5.5v DC! This is a limitation in the operating parameters of the MH-CD42 module. Not paying attention to this will result in damage to the MH-CD42 Module.
You could also power the module with REGULATED 5v DC, directly from any 5v header pin. Please note that in this case,
1) The battery won’t be charged.
2) The LDO regulator will not be in operation.
The Microcontroller
The CAN Relay Module can use any of the ATMEGA8a/88/168/328 AVR microcontrollers, as the pinout is identical. I believe this is an advantage, especially with the current chip prices, where my last quote for an ATMEGA328P-AU was 69$USD!!!! This is in comparison to the 4 to 5 USD each for an ATMEGA8a or ATMEGA168 ( We must also remember though that the 328p is very well known, and thus have higher demand. The 8a/88 or 168 are less well known, have much less memory and flash area, and will thus be cheaper. A word of action though, I had strange issues with I2C on the Atmega8a with Mini core, to such an extent that I2C does not work at all?
If you plan to use I2C on this board, install a 328p right from the start, and save yourself a lot of headaches!
This is the Relay driver circuit. As you can see, it is optically isolated, and active LOW. This means that you have to pull D4 LOW to energise the relay. Also note that, although the relay is optically isolated from the microcontroller, the coil is NOT galvanically ISOLATED. The load, which is magnetically switched, will be truly galvanically isolated, providing of course that you don’t do something silly like using a common ground to the PCB as a common on the relay…
This is the Processor and Power-supply schematic. The circuit is basically a standard Arduino Nano, with modifications for the CAN Controller on the next schematic page. Note that the MH-CD42 is not shown on the schematic. The VBAT net connects directly to the VIN pin on the unit, with the BAT net connecting to the positive of the battery. VOUt-5v from the module goes directly to the 5v net. All grounds are commoned.
This is the CAN Controller and Transceiver circuitry. The MCP2515 connects directly to the SPI bus on the microcontroller via D13, D12 and D11, with D10 as CE/SS and D9 as Interrupt or IRQ. It is important to note that although the MCP2515 is a 3v capable device, the TJA1050 Can transceiver is 5v only. This prevents us from running the PCB at 3v unless, of course, we change the TJA1050 out for a 3v capable device…
As I am currently working on the final integration of the two modules, I am not yet ready to publish my final code, showing the operation between the CAN-Bus and LoRa-to-CAN Gateway device in this post. Once I am happy that all issues are definitively sorted out, I will publish my code.
This PCB was manufactured at PCBWAY. The Gerber files and BOM, as well as all the schematics, will soon be available as a shared project on their website. If you would like to have PCBWAY manufacture one of your own, designs, or even this particular PCB, you need to do the following… 1) Click on this link 2) Create an account if you have not already got one of your own. If you use the link above, you will also instantly receive a $5USD coupon, which you can use on your first or any other order later. (Disclaimer: I will earn a small referral fee from PCBWay. This referral fee will not affect the cost of your order, nor will you pay any part thereof.) 3) Once you have gone to their website, and created an account, or login with your existing account,
4) Click on PCB Instant Quote
5) If you do not have any very special requirements for your PCB, click on Quick-order PCB
6) Click on Add Gerber File, and select your Gerber file(s) from your computer. Most of your PCB details will now be automatically selected, leaving you to only select the solder mask and silk-screen colour, as well as to remove the order number or not. You can of course fine-tune everything exactly as you want as well.
7) You can also select whether you want an SMD stencil, or have the board assembled after manufacturing. Please note that the assembly service, as well as the cost of your components, ARE NOT included in the initial quoted price. ( The quote will update depending on what options you select ).
8) When you are happy with the options that you have selected, you can click on the Save to Cart Button. From here on, you can go to the top of the screen, click on Cart, make any payment(s) or use any coupons that you have in your account.
Then just sit back and wait for your new PCB to be delivered to your door via the shipping company that you have selected during checkout.
ATMEGA328P Module with integrated LoRa and CAN-BUS
INTRODUCTION
In my quest to perfect my LoRa telemetry system, I have gone through quite a few prototypes by this time. This post will focus on the next node design. Due to the fact that the area where I will deploy the system is quite large, but with roughly square boundary fence-lines, I decided to try and reduce the number of LoRa Radio nodes needed to cover the entire area. This opened up the opportunity to utilise CAN-BUS to attach sensor-only nodes to a Radio node and have them report status on exception as well as on requests from the radio node.
The device will thus function as a LoRa-to-CAN-BUS Gateway, with some local automation to control the transmission of data to the master station. This concept can also be adapted for use in other areas, such as home -automation, or an industrial setting.
At the heart of the device, I have stuck with the versatile ATMEGA328P, which, current chip shortages excluded, and current high prices excluded, are a very inexpensive chip, with lots of well-tested libraries, and a relatively low learning curve, largely due to its very wide use in the Arduino ecosystem.
The LoRa component is handled by the RA-02 or even RA-01H module, from AI-Tinker (not sponsored). This device, as we have seen in the previous prototypes, requires the use of logic level converters, due to the fact that it only accepts 3.3v logic levels. While I could get rid of those if I powered the ATMEGA328P from 3.3v, it would give rise to two problems, of which one will still force the use of level converters…
I chose to run the ATMEGA328P at 16Mhz, which basically forces me to use 5v to power the chip. The second reason is not so obvious unless you read a few datasheets very thoroughly…
The CAN-Bus component is handled by the MCP2515 Standalone SPI-to-CAN Controller, as well as the TJA1050 CAN Bus transceiver.
This is where things get interesting… The MCP2515 can operate on 3.3v, but the TJA1050 is a 5v only device. I could thus in theory use logic level converters only between the MCP2515 and the TJA1050, while running the rest of the circuit on 3.3v…
Given that I would rather run the ATMEGA328P on 16Mhz, as well as the fact that my LoRa Radio Module circuit, with its logic level converter circuitry, works extremely well, I decided not to change that, and keep the CAN Bus running at 5v all the way through, as I would still have to use a 5v regulator on the PCB anyway just for that purpose.
IO connections for LoRa and CAN BUS modules
You can order this PCB directly from PCBWay, by clicking here
Both of the two integrated components ( Lora and CAN ) are SPI devices. This means that they share common SCK, MISO and MOSI lines ( provided on the ATMEGA328P by pins D13, D12 and D11 respectively. The individual SPI device is then further selected for operation by the use of a CE pin, one unique pin per device, which is pulled low by the MCU to indicate to the device that it should pay attention to the data being transmitted on the SPI bus…
Both LoRa and CAN makes use of other pins as well, LoRa needs a Reset pin, connected to D9, a CS/CE Pin on D10 as well as a hardware interrupt pin, connected to D2. ( Note that this is for use with Sandeep Mistry’s LoRa Library. The Radiolib library would require an additional pin, usually connected to DIO1 on the LoRa module. The device does not provide access to those pins in its current layout, so you can only use it with the Sandeep Mistry library, for now at least… )
The CAN module uses a CE/CS pin at D4, with an IRQ pin on D6, which, although not a hardware interrupt pin, does have PCINT functionality.
Pins D10, D9 and D2 are not broken out for user access. although I decided to give access to D4 and D6, as well as the SPI bus, D11, D12, D13, to allow interfacing with logic analysers, or adding other SPI devices to the bus…
This brings us to a very interesting point… Does the two SPI devices actually play nice together? and what do I mean by “playing nice together”?
To answer that question, we are forced to first look at a bit of theory, as well as understand the fundamental differences between SPI and I2C…
The Difference between SPI and I2C
Most of us will be quite familiar with I2C, as it is a very common protocol used to connect sensors to a microcontroller. It consists of only two IO lines, SDA for data, and SCL for the clock. Each device on the bus has its own built-in address, like in the case of a PCF8574 IO expander, this address can be selectable between 0x20h and 0x27h. All of the devices share these common data lines, and will only respond when specifically addressed by the master controller… Unless you accidentally put two devices with the same address on the same bus, (if that would even work), there is no way that the wrong device would respond to any request for data…
SPI on the other hand, operates on a completely different principle, making it quite a few times faster than I2c, with data being simultaneously sent and received by the active device… SPI is also known as a four-wire protocol. Each device has a minimum of 4 data lines, namely SCK ( clock), MOSI ( for data transmitted FROM the Master TO the slave device ), MISO ( for data transmitted TO the master FROM the slave device) and a CE or CS ( Chip select ) pin.
SCK, MISO and MOSI are COMMON to all devices, meaning it is shared between all of them. CE/CS is a unique pin for EACH device, meaning that if you had four SPI devices on a bus, you would have to have four individual CE/CS pins!
A device will, or rather should only respond to data on the SPI-BUS IF the master pulls its respective CE/CS pin LOW. It should now very quickly become clear to you that this can become a very very complex mess, very quickly.
Let us take a very good example. the ST7789 SPI display module, has a cheap version, commonly sold on Ali-express, as we ll as other online stores. This particular module, I assume in a bid to make it easier to use, has the CE/CS pin internally pulled down to ground by default… So what about that, you may ask? What is wrong with that, as it saves you an IO pin?
It is in fact very wrong, a fact that you will very quickly discover if you ever tried using one of those displays on an SPI bus together with other SPI devices… Nothing will work, or only the display will work ( if you are lucky)
But why?
Pulling CE/CS LOW, signals to the chip that it should respond to instructions on the common SCK, MISO and MOSI lines. having the pin internally pulled LOW, thus forces that chip to always respond, even when it should not. Thus contaminating the entire SPI-BUS with garbage…
The answer to the question
After that very long-winded explanation, which is still extremely basic, it is time that we get back to our original question:
Does the Sx127x ( RA-02 ) Module and the MCP2515 Can Controller play nice on the same bus? The answer is not straightforward, as it comes down to which libraries you use…
Remember that the library must pull down the CE/CS pin of the device that it wants to communicate with. Some libraries wrongly assume that they are the only ones in use, and ignores the simple fact, that they should release the CE/CS pin AFTER EVERY transaction, to free up the bus for other devices to use it as well…
After extensive testing, I can however say that Sandeep Mistry’s LoRa Library, as well as the mcp_can library, does indeed play nice together. These two libraries do not keep the individual CE/CS pins pulled LOW, and allows the spi bus to be shared.
This is not the case with the ST7789 Module discussed above, where the hardware actually pulls the pin ow the entire time…
Taking a closer look at the PCB
Let us take a closer look at the PCB. The Ra-02 Module ( LoRa ) dominates most of the left-hand side of the PCB, with the ATMEGA328P on its right. The RA-02 is surrounded by the level converters, using the BSS138 N-Channel Mosfet, and 10k resistors (Q1 to Q6, R1, R2, R3, R4, R5, R6, R8, R9, R10, R11, R12, R13)
C1 and C2 are bypass capacitors for the Ra-02 module
In the bottom left corner, we have a hardware reset button, to reset the ATMEGA328P, with a yellow jumper (H1) next to it. This jumper controls the 120ohm ballast resistor (R17) for the CAN bus. Removing the jumper will remove the ballast. Directly below that is the CAN connecter, marked as U5, with CH as CAN-H, and CL as CAN-L ports.
U3 and U4, together with R18, R19, X2, C16, C17 make up the CAN components on the PCB. Decoupling is provided by C6, C7, C8 as well as C9 and C12 ( Includes the ATMEGA328P’s decoupling as well )
An ICSP programming header is provided above U1 ( ATMEGA328P) for use with USPASP, AVRASP or Arduino as ISP and similar.
No USB to serial converter is provided on the board, Serial upload is possible is loaded with an Arduino bootloader for the Arduino NANO ( to make use of all the analog inputs). RxD, TxD and DTR pins are broken out on opposite sides of the PCB, as well as access to 3.3v, 5v and GND pins.
A DC power socket is provided. it can accept up to 12v DC, although I would recommend not to go over 7.2 volts, to not stress the LDO regulators, at the back of the PCB ( LDO1, and LDO2) too much.
You can order this PCB directly from PCBWay, by Clicking here
in the picture above, I have connected a USB-to Serial converter, as well as CAN-BUS to the device.
Schematic Diagram
The detailed schematic diagrams are provided below:
Sheet 1 (above) takes care of the ATMEGA328p and it supporting circuitry, as well as the power supply via LDO regulators.
Sheet 2 (below) takes care of the Logic Level converters, RA-02 (Sx1278) LoRa Module, and CAN-BUS controller and transceiver circuitry.
A combined example utilising both LoRa and CAN at the same time, will be released with the next part of the project, namely the CAN-Relay Module
This PCB was manufactured at PCBWAY. The Gerber files and BOM, as well as all the schematics, will soon be available as a shared project on their website. If you would like to have PCBWAY manufacture one of your own, designs, or even this particular PCB, you need to do the following… 1) Click on this link 2) Create an account if you have not already got one of your own. If you use the link above, you will also instantly receive a $5USD coupon, which you can use on your first or any other order later. (Disclaimer: I will earn a small referral fee from PCBWay. This referral fee will not affect the cost of your order, nor will you pay any part thereof.) 3) Once you have gone to their website, and created an account, or login with your existing account,
4) Click on PCB Instant Quote
5) If you do not have any very special requirements for your PCB, click on Quick-order PCB
6) Click on Add Gerber File, and select your Gerber file(s) from your computer. Most of your PCB details will now be automatically selected, leaving you to only select the solder mask and silk-screen colour, as well as to remove the order number or not. You can of course fine-tune everything exactly as you want as well.
7) You can also select whether you want an SMD stencil, or have the board assembled after manufacturing. Please note that the assembly service, as well as the cost of your components, ARE NOT included in the initial quoted price. ( The quote will update depending on what options you select ).
8) When you are happy with the options that you have selected, you can click on the Save to Cart Button. From here on, you can go to the top of the screen, click on Cart, make any payment(s) or use any coupons that you have in your account.
Then just sit back and wait for your new PCB to be delivered to your door via the shipping company that you have selected during checkout.
After quite a few experiments, and playing with a lot of ideas, we have finally produced and tested an almost final prototype for the MCU-8266-12E IoT Controller Port Extender Card. While the baseboard already has quite a lot of free GPIO pins for additional sensors and devices, It did however have quite a few issues, namely a lack of sufficient Power outputs, difficulty access to the I2C bus, as well as only 2 relay outputs. Granted that you do have access to unused pins on the PCF8574 Port Extender, We nonetheless decided that an add-on card would definitely make sense to allow this device to really be more useable.
While looking at various ideas for this card, the most flexible seemed to be the APE Protocol device as documented in ESPHome. They used a standard Arduino board for that, but we decided that, after testing it with an Arduino Nano, since it seems to work well, let us just design a dedicated PCB. It also looks much better as well 🙂
The beginning of the APE (Arduino Port Extender) Device. MCU-8266-12E with Arduino Nano (left) and MCU-8266-12E with the newly designed APE Card (right)
Some Features (Aside from being a fully functional Arduino clone as well)
1). Dedicated LDO Regulators for 5v and 3.3v (800mA each), with jumpers to switch them on or off (receive power only from the IoT Motherboard). 2.) Dedicated Logic Level Converter on the I2C Bus ( This is sort of very much needed 🙂 The Atmega 328P-AU is running at 5v on this device, to enable it to run at 16Mhz.. and the ESP8266 on the Motherboard is a 3.3v device..
There are also 3x 3.3V I2C Headers, complete with 3.3v and Ground, as well as a single 5v I2C header 3). 8 Analog Inputs ( While practically you can only use 6 of these if you use I2C ) 4). Voltage Divider provided on A0 to measure VIN ( to be safe, we calculated the resistors for 22v) 5). 100R current limiting resistor on A1 and A2, to measure 5v and 3.3v as well… Analog inputs A0, A1 and A2 can be switched back to normal operation by changing the jumper at J2,J3 or J4 from On to Off. 6). 12 Digital Inputs/Outputs (14 if you use D0 and D1 as well), as well as a Jumper to remove the LED on D13. 7). Full access to the PCF8574 and ESP8266 Pins from the motherboard below.
Pictures of the PCB
Side by side MCU-8266-12E (left) 8266-12E-Port Extender (right)
Side by side MCU-8266-12E (left) 8266-12E-Port Extender (right)
Side by side MCU-8266-12E (left) 8266-12E-Port Extender (right) [ with unpopulated PCB at bottom]
Blank PCB 8266-12E-Port Extender
Blank PCB MCU-8266-12E IoT Controller
Top view 8266-12E PE
8266-12E-PE side view { from bottom)
Right side view – 8266-12E-PE
Left side view – 8266-12E-PE
Stacked on-top-of MCU-8266-12E
Stacked – Top Side view
Stacked – Right side view
Stacked – Left side view
Pictures of the PCB, alone and with the MCU-8266-12E IoT controller
Circuit Diagram
ATMega328P-AU Circuit diagram with LDO Regulators, headers and supporting circuitry.Analog measuring circuitry, level converters and supporting circuitry and headers
Uploading Code to the ATMega328P
Uploading code to the device requires the use of either an ISCP programmer ( Arduino as ISP works well ) or in the case of a pre-boot loaded chip, a USB-to-Serial converter. We did not find it necessary to add a dedicated USB-to-Serial converter onto the PCB. It is quite easy enough to do any flashing with the tools mentioned above.
Make sure that the PCB is not stacked when doing this. ( This will prevent excessive current use of other components when you supply 5v to the PE card.
Procedure to upload using ICSP
During assembly, you are required to solder a single 90-degree bend pin header on the bottom side of the PCB, in the same hole as the board side edge of the RESET push-button. This will serve as the RESET Pin for the ISCP. Other connections are as follows:
H2 Header <- > ICSP Programmer MOSI (E11~) – MOSI ( or Pin 11 on Arduino as ISP ) MISO (E12 ) – MISO ( or Pin 12 on Arduino as ISP ) SCK (E13) – D13 (or Pin 13 on Arduino as ISP ) RESET – D10 (or Pin 10 on Arduino as ISP )
5v and Ground from Arduino as ISP or ISCP Programmer to any 5v and ground pin on the PE Card
Please note the description above for assembly of the RESET pin header
Procedure to upload using USB-to-Serial converter
H1 Header
E0/Rx <- to Tx of USB-to-Serial converter E1/Tx -> to Rx of USB-to-Serial converter
H2 Header
DTR <-> to DTR of USB-to-Serial converter [ This connection is needed for successful uploading. Don’t leave it out ]
5v and Ground from the USB-to-Serial converter to any 5v and ground pin on the PE Card
Testing with ESPHome APE protocol and the MCU-8266-12E IoT controller
The following Arduino Sketch needs to be uploaded to the device. It will allow the device to function as a custom I2C device. Feel free to change the I2C address in the sketch as you choose, but remember to use the same address in your ESPHome YAML configuration file
The following C header file needs to be uploaded to your Home Assistant ESPHome folder.
// Must disable logging if using logging in main.cpp or in other custom components for the
// __c causes a section type conflict with __c thingy
// you can enable logging and use it if you enable this in logger:
/*
logger:
level: DEBUG
esp8266_store_log_strings_in_flash: False
*/
//#define APE_LOGGING
// take advantage of LOG_ defines to decide which code to include
#ifdef LOG_BINARY_OUTPUT
#define APE_BINARY_OUTPUT
#endif
#ifdef LOG_BINARY_SENSOR
#define APE_BINARY_SENSOR
#endif
#ifdef LOG_SENSOR
#define APE_SENSOR
#endif
static const char *TAGape = "ape";
#define APE_CMD_DIGITAL_READ 0
#define APE_CMD_WRITE_ANALOG 2
#define APE_CMD_WRITE_DIGITAL_HIGH 3
#define APE_CMD_WRITE_DIGITAL_LOW 4
#define APE_CMD_SETUP_PIN_OUTPUT 5
#define APE_CMD_SETUP_PIN_INPUT_PULLUP 6
#define APE_CMD_SETUP_PIN_INPUT 7
// 8 analog registers.. A0 to A7
// A4 and A5 not supported due to I2C
#define CMD_ANALOG_READ_A0 0b1000 // 0x8
// ....
#define CMD_ANALOG_READ_A7 0b1111 // 0xF
#define CMD_SETUP_ANALOG_INTERNAL 0x10
#define CMD_SETUP_ANALOG_DEFAULT 0x11
#define get_ape(constructor) static_cast<ArduinoPortExpander *>(constructor.get_component(0))
#define ape_binary_output(ape, pin) get_ape(ape)->get_binary_output(pin)
#define ape_binary_sensor(ape, pin) get_ape(ape)->get_binary_sensor(pin)
#define ape_analog_input(ape, pin) get_ape(ape)->get_analog_input(pin)
class ArduinoPortExpander;
using namespace esphome;
#ifdef APE_BINARY_OUTPUT
class ApeBinaryOutput : public output::BinaryOutput
{
public:
ApeBinaryOutput(ArduinoPortExpander *parent, uint8_t pin)
{
this->parent_ = parent;
this->pin_ = pin;
}
void write_state(bool state) override;
uint8_t get_pin() { return this->pin_; }
protected:
ArduinoPortExpander *parent_;
uint8_t pin_;
// Pins are setup as output after the state is written, Arduino has no open drain outputs, after setting an output it will either sink or source thus activating outputs writen to false during a flick.
bool setup_{true};
bool state_{false};
friend class ArduinoPortExpander;
};
#endif
#ifdef APE_BINARY_SENSOR
class ApeBinarySensor : public binary_sensor::BinarySensor
{
public:
ApeBinarySensor(ArduinoPortExpander *parent, uint8_t pin)
{
this->pin_ = pin;
}
uint8_t get_pin() { return this->pin_; }
protected:
uint8_t pin_;
};
#endif
#ifdef APE_SENSOR
class ApeAnalogInput : public sensor::Sensor
{
public:
ApeAnalogInput(ArduinoPortExpander *parent, uint8_t pin)
{
this->pin_ = pin;
}
uint8_t get_pin() { return this->pin_; }
protected:
uint8_t pin_;
};
#endif
class ArduinoPortExpander : public Component, public I2CDevice
{
public:
ArduinoPortExpander(I2CBus *bus, uint8_t address, bool vref_default = false)
{
set_i2c_address(address);
set_i2c_bus(bus);
this->vref_default_ = vref_default;
}
void setup() override
{
#ifdef APE_LOGGING
ESP_LOGCONFIG(TAGape, "Setting up ArduinoPortExpander at %#02x ...", address_);
#endif
/* We cannot setup as usual as arduino boots later than esp8266
Poll i2c bus for our Arduino for a n seconds instead of failing fast,
also this is important as pin setup (INPUT_PULLUP, OUTPUT it's done once)
*/
this->configure_timeout_ = millis() + 5000;
}
void loop() override
{
if (millis() < this->configure_timeout_)
{
bool try_configure = millis() % 100 > 50;
if (try_configure == this->configure_)
return;
this->configure_ = try_configure;
if (ERROR_OK == this->read_register(APE_CMD_DIGITAL_READ, const_cast<uint8_t *>(this->read_buffer_), 3))
{
#ifdef APE_LOGGING
ESP_LOGCONFIG(TAGape, "ArduinoPortExpander found at %#02x", address_);
#endif
delay(10);
if (this->vref_default_)
{
this->write_register(CMD_SETUP_ANALOG_DEFAULT, nullptr, 0); // 0: unused
}
// Config success
this->configure_timeout_ = 0;
this->status_clear_error();
#ifdef APE_BINARY_SENSOR
for (ApeBinarySensor *pin : this->input_pins_)
{
App.feed_wdt();
uint8_t pinNo = pin->get_pin();
#ifdef APE_LOGGING
ESP_LOGCONFIG(TAGape, "Setup input pin %d", pinNo);
#endif
this->write_register(APE_CMD_SETUP_PIN_INPUT_PULLUP, &pinNo, 1);
delay(20);
}
#endif
#ifdef APE_BINARY_OUTPUT
for (ApeBinaryOutput *output : this->output_pins_)
{
if (!output->setup_)
{ // this output has a valid value already
this->write_state(output->pin_, output->state_, true);
App.feed_wdt();
delay(20);
}
}
#endif
#ifdef APE_SENSOR
for (ApeAnalogInput *sensor : this->analog_pins_)
{
App.feed_wdt();
uint8_t pinNo = sensor->get_pin();
#ifdef APE_LOGGING
ESP_LOGCONFIG(TAGape, "Setup analog input pin %d", pinNo);
#endif
this->write_register(APE_CMD_SETUP_PIN_INPUT, &pinNo, 1);
delay(20);
}
#endif
return;
}
// Still not answering
return;
}
if (this->configure_timeout_ != 0 && millis() > this->configure_timeout_)
{
#ifdef APE_LOGGING
ESP_LOGE(TAGape, "ArduinoPortExpander NOT found at %#02x", address_);
#endif
this->mark_failed();
return;
}
#ifdef APE_BINARY_SENSOR
if (ERROR_OK != this->read_register(APE_CMD_DIGITAL_READ, const_cast<uint8_t *>(this->read_buffer_), 3))
{
#ifdef APE_LOGGING
ESP_LOGE(TAGape, "Error reading. Reconfiguring pending.");
#endif
this->status_set_error();
this->configure_timeout_ = millis() + 5000;
return;
}
for (ApeBinarySensor *pin : this->input_pins_)
{
uint8_t pinNo = pin->get_pin();
uint8_t bit = pinNo % 8;
uint8_t value = pinNo < 8 ? this->read_buffer_[0] : pinNo < 16 ? this->read_buffer_[1] : this->read_buffer_[2];
bool ret = value & (1 << bit);
if (this->initial_state_)
pin->publish_initial_state(ret);
else
pin->publish_state(ret);
}
#endif
#ifdef APE_SENSOR
for (ApeAnalogInput *pin : this->analog_pins_)
{
uint8_t pinNo = pin->get_pin();
pin->publish_state(analogRead(pinNo));
}
#endif
this->initial_state_ = false;
}
#ifdef APE_SENSOR
uint16_t analogRead(uint8_t pin)
{
bool ok = (ERROR_OK == this->read_register((uint8_t)(CMD_ANALOG_READ_A0 + pin), const_cast<uint8_t *>(this->read_buffer_), 2));
#ifdef APE_LOGGING
ESP_LOGVV(TAGape, "analog read pin: %d ok: %d byte0: %d byte1: %d", pin, ok, this->read_buffer_[0], this->read_buffer_[1]);
#endif
uint16_t value = this->read_buffer_[0] | ((uint16_t)this->read_buffer_[1] << 8);
return value;
}
#endif
#ifdef APE_BINARY_OUTPUT
output::BinaryOutput *get_binary_output(uint8_t pin)
{
ApeBinaryOutput *output = new ApeBinaryOutput(this, pin);
output_pins_.push_back(output);
return output;
}
#endif
#ifdef APE_BINARY_SENSOR
binary_sensor::BinarySensor *get_binary_sensor(uint8_t pin)
{
ApeBinarySensor *binarySensor = new ApeBinarySensor(this, pin);
input_pins_.push_back(binarySensor);
return binarySensor;
}
#endif
#ifdef APE_SENSOR
sensor::Sensor *get_analog_input(uint8_t pin)
{
ApeAnalogInput *input = new ApeAnalogInput(this, pin);
analog_pins_.push_back(input);
return input;
}
#endif
void write_state(uint8_t pin, bool state, bool setup = false)
{
if (this->configure_timeout_ != 0)
return;
#ifdef APE_LOGGING
ESP_LOGD(TAGape, "Writing %d to pin %d", state, pin);
#endif
this->write_register(state ? APE_CMD_WRITE_DIGITAL_HIGH : APE_CMD_WRITE_DIGITAL_LOW, &pin, 1);
if (setup)
{
App.feed_wdt();
delay(20);
#ifdef APE_LOGGING
ESP_LOGI(TAGape, "Setup output pin %d", pin);
#endif
this->write_register(APE_CMD_SETUP_PIN_OUTPUT, &pin, 1);
}
}
protected:
bool configure_{true};
bool initial_state_{true};
uint8_t read_buffer_[3]{0, 0, 0};
unsigned long configure_timeout_{5000};
bool vref_default_{false};
#ifdef APE_BINARY_OUTPUT
std::vector<ApeBinaryOutput *> output_pins_;
#endif
#ifdef APE_BINARY_SENSOR
std::vector<ApeBinarySensor *> input_pins_;
#endif
#ifdef APE_SENSOR
std::vector<ApeAnalogInput *> analog_pins_;
#endif
};
#ifdef APE_BINARY_OUTPUT
void ApeBinaryOutput::write_state(bool state)
{
this->state_ = state;
this->parent_->write_state(this->pin_, state, this->setup_);
this->setup_ = false;
}
#endif
The file should be named “arduino_port_expander.h”
Make the following changes to your ESPHome YAML configuration file for the MCU-8266-12E device
esphome:
name: mcu-8266-12e-01
platform: ESP8266
board: nodemcuv2
includes:
- arduino_port_expander.h
# Note the include file - This loads the APE Header
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
password: "<your password will be different - dont change it>"
wifi:
ssid: <your ssid>
password: <your password>
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "MCU-8266-Hotspot"
password: "password"
captive_portal:
i2c:
# PCB Prototype
sda: GPIO5
scl: GPIO4
# PCB Rev 1.5 or higher, comment the above 2 lines
# and uncomment
#sda: GPIO4
#scl: GPIO5
#################### - IMPORTANT ###########
scan: true
id: i2c_bus_a
pcf8574:
- id: 'pcf8574_hub'
address: 0x22 # Set at 0x22, feel free to change to your liking, Remember to set the chip to the address you choose as well
pcf8575: false
time:
- platform: sntp
id: ha_time
timezone: "Etc/GMT+7"
status_led:
pin:
number: GPIO16
inverted: true
#Define the APE as a custom component, taking care to ensure that:
#1). The I2C Bust ID is the same as the one you have defined in the I2C: Section
#2). The address of the APE is the same as the one you set in the sketch
custom_component:
- id: ape
lambda: |-
auto ape_component = new ArduinoPortExpander(i2c_bus_a, 0x08,true);
return {ape_component};
sensor:
- platform: custom
lambda: |-
return {ape_analog_input(ape, 0), // 1 = A1
ape_analog_input(ape, 1),
ape_analog_input(ape, 2)};
#We define 3 analog inputs (A0,A1,A2) to monitor voltages on the card
#Note that you MUST define them in the sensors section below as well AND
#THAT THEY MUST BE IN THE SAME SEQUENCE THAT YOU DEFINED THEM IN ABOVE HERE
#
#ALSO NOTE THAT YOU CAN "NOT" use A4 and A5, as they are used for I2C !
#
# As an example, of adding another 3 analog inputs, your definition above will change to:
#
# return {ape_analog_input(ape, 0),
# ape_analog_input(ape, 1),
# ape_analog_input(ape, 2),
# ape_analog_input(ape, 3),
# ape_analog_input(ape, 6),
# ape_analog_input(ape, 7)};
#
#
# Now define the sensors connected to these analogs below:
sensors:
- name: "PE Card VIN"
id: analog_a0
device_class: "voltage"
unit_of_measurement: "v"
accuracy_decimals: 2
filters:
- lambda: return x * (22.00/1023.0);
- throttle: 60s
# We use a lambda to scale the value of VIN - Our Voltage divider was designed around 22 volt
# thus we need 22 volt here in the calculation as well to make it accurate
#
- name: "PE Card 5v"
id: analog_a1
device_class: "voltage"
unit_of_measurement: "v"
accuracy_decimals: 2
filters:
- lambda: return x * (5.02/1023.0);
- throttle: 60s
- name: "PE Card 3v"
id: analog_a2
device_class: "voltage"
unit_of_measurement: "v"
accuracy_decimals: 2
filters:
- lambda: return x * (5.02/1023.0);
- throttle: 60s
# The ATMega328P 's Analog Reference is set to 5v internally, thus we need to also scale the
# 3v input with a maximum of 5v ...
# In case you enabled the other 3 Analog Inputs above, you need to add the following
#
# - name: "Analog 3"
# id: analog_a3
# filters:
# - throttle: 60s
# - name: "Analog 6"
# id: analog_a6
# filters:
# - throttle: 60s
# - name: "Analog 7"
# id: analog_a7
# filters:
# - throttle: 60s
#
#
- platform: adc
pin: VCC
name: "ESP8266 Chip Voltage"
id: mcu_voltage
unit_of_measurement: "V"
device_class: "voltage"
accuracy_decimals: 2
update_interval: 60s
- platform: wifi_signal
name: "WiFi Signal Sensor"
id: wifi_strength
device_class: "signal_strength"
unit_of_measurement: "dBm"
update_interval: 240s
#Digital outputs function the same
output:
- platform: custom
type: binary
lambda: |-
return {ape_binary_output(ape, 2),
ape_binary_output(ape, 3),
ape_binary_output(ape, 4),
ape_binary_output(ape, 5),
ape_binary_output(ape, 6),
ape_binary_output(ape, 7)};
outputs:
- id: ape_output_p2
inverted: false
- id: ape_output_p3
inverted: false
- id: ape_output_p4
inverted: false
- id: ape_output_p5
inverted: false
- id: ape_output_p6
inverted: false
- id: ape_output_p7
inverted: false
- platform: gpio
id: relay_1
pin:
pcf8574: pcf8574_hub
number: 0
mode: OUTPUT
inverted: true
- platform: gpio
id: relay_2
pin:
pcf8574: pcf8574_hub
number: 1
mode: OUTPUT
inverted: true
- platform: gpio
id: led_status_1
pin:
pcf8574: pcf8574_hub
number: 2
mode: OUTPUT
inverted: true
- platform: gpio
id: led_status_2
pin:
pcf8574: pcf8574_hub
number: 3
mode: OUTPUT
inverted: true
binary_sensor:
- platform: gpio
id: push_button_1
name: 'Relay1 Pushbutton'
device_class: ''
pin:
pcf8574: pcf8574_hub
number: 4
mode: INPUT
inverted: true
on_press:
then:
- switch.toggle: switch_relay1
- platform: gpio
id: push_button_2
name: 'Relay2 Pushbutton'
device_class: ''
pin:
pcf8574: pcf8574_hub
number: 5
mode: INPUT
inverted: true
on_press:
#min_length: 50ms
#max_length: 500ms
then:
- switch.toggle: switch_relay2
filters:
- delayed_on_off: 50ms
switch:
- platform: output
id: switch_relay1
name: "Relay No. 1 (#0)"
output: relay_1
on_turn_on:
- output.turn_on: led_status_1
on_turn_off:
- output.turn_off: led_status_1
- platform: output
id: switch_relay2
name: "Relay No. 2 (#1)"
output: relay_2
on_turn_on:
- output.turn_on: led_status_2
on_turn_off:
- output.turn_off: led_status_2
- platform: restart
id: reboot_switch
name: "Reboot Me"
This PCB was manufactured at PCBWAY. The Gerber files and BOM, as well as all the schematics, will soon be available as a shared project on their website. If you would like to have PCBWAY manufacture one of your own, designs, or even this particular PCB, you need to do the following… 1) Click on this link 2) Create an account if you have not already got one of your own. If you use the link above, you will also instantly receive a $5USD coupon, which you can use on your first or any other order later. (Disclaimer: I will earn a small referral fee from PCBWay. This referral fee will not affect the cost of your order, nor will you pay any part thereof.) 3) Once you have gone to their website, and created an account, or login with your existing account,
4) Click on PCB Instant Quote
5) If you do not have any very special requirements for your PCB, click on Quick-order PCB
6) Click on Add Gerber File, and select your Gerber file(s) from your computer. Most of your PCB details will now be automatically selected, leaving you to only select the solder mask and silk-screen colour, as well as to remove the order number or not. You can of course fine-tune everything exactly as you want as well.
7) You can also select whether you want an SMD stencil, or have the board assembled after manufacturing. Please note that the assembly service, as well as the cost of your components, ARE NOT included in the initial quoted price. ( The quote will update depending on what options you select ).
8) When you are happy with the options that you have selected, you can click on the Save to Cart Button. From here on, you can go to the top of the screen, click on Cart, make any payment(s) or use any coupons that you have in your account.
Then just sit back and wait for your new PCB to be delivered to your door via the shipping company that you have selected during checkout.
With the initial prototyping of my IoT Controller now completed, and software performing as expected, I have started with the development of an add-on shield. The base device offers 2 built-in relays, and access to another 6 IO Ports on the PCF8574, as well as all the GPIO on the ESP-12E. This is all good and well and suits my initial purposes well, but
I do however now see a need to add more sensors to the device, as well as find an elegant way to power it directly from mains power, while not having lots of wires going anywhere.
So the next steps will be:
Design an add-on-shield to provide me with the following: – Analog inputs. The ESP-12E has only one, and that will be very limiting in some situations. -Digital Inputs and Outputs While there are still unused GPIO ports on the existing board, native to the ESP-12E, having the ability to connect additional devices and sensors will definitely be a good option to have in future. -Some sort of Display Small OLED I2C displays are cheap and easy to use. I can also go full colour with an SPI display…
From here on, I have to decide on how and what. I can go the discreet chip route, by using dedicated I2C chips that provide all these functions, or I can add a secondary micro-controller to the shield, which would provide more flexibility, but can also add complexity to the final design…
Please follow along and join me on the next part of this design journey. I can not promise anything yet, but I do guarantee that it will be exciting…
Welcome to Part 3 of this build. If you are new to this series, Part1 and Part2 can be found by clicking on the respective links. Today, we will look at the completed PCB for our IoT Controller. Full disclosure, There are some issues, ranging from components that have still (15 days after being ordered, not been delivered), as well as 3 minor errors on the PCB ( That is entirely my fault ). We will look at how I have overcome the problems to still end up with a functionals PCB. Please note that the errors in the PCB Artwork have BEEN CORRECTED and that the version for public download does not contain any errors. You can thus order it with confidence.
During the design phase, I have forgotten to add a ground to the 5v regulator, and its supporting smoothing capacitors. These components were not initially included in my design, but, while added in later after I decided that since I will be designing the PCB to operate from many different voltage inputs, a reliable 5v source that is not dependent on USB power should be added… The components were added to the schematic, and I forgot to add the ground. It went undetected on the PCB design, as the Ground plane is a copper area…
In the picture above, you can see that I have temporarily fixed it with two wire links from the ground of C1, to the grounds of C10 and C11 respectively. These grounds connect back to U2.
C1 is another issue. Originally designed as a 100uf Electrolytic capacitor, I had to settle for a 10uf Tantalum. The reason being that the ordered capacitors are still floating in logistics space… with no definite ETA.
Error on I2C labelling, as well as I2C Pins at IC2
The following error was not so easy to spot. It gave me quite a headache to find. As I normally use netlabels on all the pins of any IC that I use, I have correctly labelled ESP12-E GPIO5 as SCL and GPIO4 as SDA. These netlabels were then transferred onto the PFC8574’s pins but in reverse! Note to self: Always re-read the pinout in the datasheet! To make matters worse, I flipped the SCL and SDA labels on the pin header…
How to fix: I am fortunate that the ESP12-E, like all other ESP Modules, does not have fixed I2C pins. If this was an Atmega based project, the boards would have been useless if tracks could not be cut and reconnected! On the ESP12-E, I2C is however software allocated to any desired GPIO pin. It was thus easily fixed by just swapping the two pins in software.
The third problem encountered is another logistics issue. This is in the process of being resolved, but, as you will soon see, is not actually a problem at all…
I have added support for an onboard USB to Serial converter, via a CH340G chip. The chip requires a 12Mhz resonator or crystal. My dear supplier accidentally sent me an 8 Mhz version. I have thus decided to depopulate the entire USB to Serial circuit, leaving just the USB Port and protection diode on the board. (To allow for powering via USB).
This does mean that programming the board becomes a little more complicated, connecting an external USB to Serial Adapter, and pressing and holding the flash button while pressing and releasing reset for each upload, followed by a manual reset afterwards. This is a pain, but, as I will be using these boards with ESPHome, only required once. All future uploads will be OTA anyway, and the correct components can be retrofitted when they arrive at a later stage.
Powering on the PCB
The PCB was first powered on with an external USB to serial converter and using the Arduino IDE, a simple sketch testing the I2C addressing of the chip, as well as the functioning of all onboard relays and LEDs.
The board was then flashed with ESPHome, using the procedure described in Part 1. I then proceeded to measure the current required by the board, to make sure that it is as designed.
Current Requirements Powered from 9V to 12V DC via the DC Barrel Connector
Standby, Wifi Connected to Home Assistant, All relays and LEDs off 75mA All relays energised, status LEDs all on 255mA
Integrating and Testing with EspHome and Home Assistant
The configuration for ESPHome was updated and uploaded to the device OTA. I decided to add a monitor for the VCC input of the ESP12-E, a remote Restart button, and an external DHT11 Temperature and Humidity sensor. The updated code is available below
esphome:
name: iot-controller-8266-01
platform: ESP8266
board: nodemcuv2
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
password: "2f8a73f47f1893f3f7baa391c4d0ba96"
wifi:
ssid: "<your ssid>"
password: "<your password>"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Iot-Controller-8266-01"
password: "y4aaH7vMITsC"
captive_portal:
#--- DO NOT COPY ANYTHING ABOVE THIS LINE ---
# when using this, you need to reassign the status LED to another GPIO
#deep_sleep:
# run_duration: 5min
# sleep_duration: 2min
i2c:
sda: GPIO5
scl: GPIO4
scan: true
id: i2c_bus_a
pcf8574:
- id: 'pcf8574_hub'
address: 0x22
pcf8575: false
status_led:
pin:
number: GPIO16
inverted: true
# Reassign this LED to another GPIO when using deep sleep mode !
sensor:
# Monitor VCC on the ESP12-E
- platform: adc
pin: VCC
name: "Device Input Voltage"
unit_of_measurement: "V"
# Monitor the WiFi Signal Strength at the device
- platform: wifi_signal
name: "WiFi Signal Sensor"
unit_of_measurement: "dBm"
update_interval: 240s
# Add Temperature and Humidity Sensor
- platform: dht
pin: GPIO2
temperature:
name: "Room Temperature"
unit_of_measurement: "°C"
icon: "mdi:temperature"
device_class: "temperature"
state_class: "measurement"
accuracy_decimals: 2
humidity:
name: "Room Humidity"
unit_of_measurement: "%"
icon: "mdi:water-percent"
device_class: "humidity"
state_class: "measurement"
accuracy_decimals: 2
update_interval: 60s
# Outputs to control relays and led's
output:
- platform: gpio
id: relay_1
pin:
pcf8574: pcf8574_hub
number: 0
mode: OUTPUT
inverted: true
- platform: gpio
id: relay_2
pin:
pcf8574: pcf8574_hub
number: 1
mode: OUTPUT
inverted: true
- platform: gpio
id: led_status_1
pin:
pcf8574: pcf8574_hub
number: 2
mode: OUTPUT
inverted: true
- platform: gpio
id: led_status_2
pin:
pcf8574: pcf8574_hub
number: 3
mode: OUTPUT
inverted: true
# Monitor the two local control pushbuttons on the device
binary_sensor:
- platform: gpio
id: push_button_1
name: 'Relay1 Pushbutton'
device_class: ''
pin:
pcf8574: pcf8574_hub
number: 4
mode: INPUT
inverted: true
on_press:
then:
- switch.toggle: switch_relay1
filters:
- delayed_on_off: 50ms
- platform: gpio
id: push_button_2
name: 'Relay2 Pushbutton'
device_class: ''
pin:
pcf8574: pcf8574_hub
number: 5
mode: INPUT
inverted: true
on_press:
#min_length: 50ms
#max_length: 500ms
then:
- switch.toggle: switch_relay2
filters:
- delayed_on_off: 50ms
# Allow control from inside Home Assistant
switch:
- platform: output
id: switch_relay1
name: "Relay No. 1 (#0)"
output: relay_1
on_turn_on:
- output.turn_on: led_status_1
on_turn_off:
- output.turn_off: led_status_1
- platform: output
id: switch_relay2
name: "Relay No. 2 (#1)"
output: relay_2
on_turn_on:
- output.turn_on: led_status_2
on_turn_off:
- output.turn_off: led_status_2
# Add a remote Reboot switch
- platform: restart
name: "Reboot Me"
After uploading this configuration, Home Assistant was configured to reflect the changes.
Home Assistant showing the IoT Controller status ( EE Lab Area ) as well as Admin stats (Master Control Panel)
I have decided to split the different status and control outputs from the device into two cards, One in the EE Lab Area, which will later be moved into the actual room(s) where the device will be deployed, as well as on a Master Control Panel. From here, I can reboot individual devices, see their voltages and WiFi Status
Tasmota
As promised before, I did test the device with Tasmota. I had to do a custom compile to get support for the PCF8574. Performance was however VERY poor. ESPHome is snappy and quick, even in local mode. Tasmota seemed to have at least a one-second delay on doing anything. I thus abandoned it, and won’t be making use of it in this project anymore. The flexibility of ESPHome to do what I want, how I want it, is definitely missing in Tasmota. Hopefully, that will change in the future?
Order this PCB for yourself
You can order this PCB from PCBWay as a shared Project, by clicking here. New users will get a $5 USD coupon for use with their first order if they follow the link below to sign up for an account.
I would also like to thank Wendy at PCBWay for once again being a star. The project went smoothly and was very well produced. Make sure to consider using PCBWay for your next PCB order.
Conclusion and further steps
I am in the process of building and assembling another 2 of these devices. I have also ordered and received PolyCarbonate enclosures to mount them in. As this is an ongoing project, I still plan to add I2C temperature measurement chips to each, to measure the temperature inside the enclosure. An Air quality sensor, as well as a CO2 sensor, is also planned, with a possible Display Shield to provide test output locally at the device. This display, at the moment at least, is planned as an I2C Oled or similar. There are also plans to do an option to directly power the unit from 220V AC via an additional base-board for now, or a complete redesign, incorporating everything on one board. Thank you for following along, I hope that you found it educational and entertaining. Please consider joining us on Patreon. We are in the process of creating exclusive content for that platform, as well as for http://144.126.248.244. Most of the content will also remain free for all as usual.
In my previous post, available here, I have shown you the initial stages of designing and developing our own IoT controller. Today, while the PCB has just arrived from PCBWay, and while we wait for the rest of the components to arrive, we will continue with the software development of the device. I will also show you the beautiful PCB that I got from PCBWay!
For today’s post, we will focus on configuring ESPHome, get it to work together with Home Assistant, as well as have a look at those PCB’s!
Our next step will be to write the YAML configuration file…
YAML configuration
ESPHome uses the YAML language to define IO and automation. These files are then parsed, converted into C/C++ and compiled. The resulting Binary File is the uploaded OTA to the device via WiFi.
We will still be using our Virtual Machine Image of Home Assistant, running inside VirtualBox on our PC. Go ahead and start that, and then open Home Assistant in your Web Browser. Then click on ESPHome. You will see a screen similar to the one above.
While we are at this point, I believe it is a good time to clarify why we do the development in a virtual PC, and not directly on our Home Assistant instance running on a Raspberry Pi. The reason is actually very simple. Home Assistant seems to have issues with completely removing unused entities. This is not a problem, but you could potentially end up with a lot of stale entries in your production Home Assistant Server. The VM solution allows us to test everything away from the actual server, and then, when we are done, recreate the working device on the actual server. That way, there is almost no chance of damaging your existing Home Assistant Server, which you may already have spent some time on to set up just the way you want it…
Continue by clicking on the EDIT link, in the iot-con-prototype device that we created in the last tutorial. You will see a file similar to this …
This is the default configuration file generated by ESPHome. We will build on this file… Note that your OTA Password will be different. DO NOT CHANGE OR MODIFY IT IN ANY WAY!
When we edit YAML, indentations are extremely important, so try to follow exactly what I am doing.
Our IoT Controller uses I2C to communicate with the PCF8574 chip. Let us assume that you have set your address to 0x22h by using the dip switch on the PCB, you could of course set any other address, just make sure that you know what it is.
We now need to tell ESPHome that we have an I2C Bus and that it needs to scan this bus for devices. That way, we can see in the logs if it actually detects our device or not.
We give this device the id of pcf8574_hub and specify its address as 0x22. We also NEED to specify that it is NOT the 16 port pcf8575 variant.
Now we can start configuring our outputs. for our purposes, we will have two relay outputs, as well as two status LEDs. In the actual circuit, the pcf8574 will sink the pins connected to these, as the chip can sink more current than it can safely source. Refer to the relay driver schematic for more information on that.
The syntax should be straightforward, every output will have a platform, in this case, gpio. Then we will need a unique ID, let us say relay_1 Now, we need to specify the physical pin to use. Now here, you could also specify a native pin on the actual NodeMCU device that we are using for testing, but we will specify a pin on the pcf8574 instead. This is done with the pin: directive pin: pcf8574: pcf8574_hub // This tells the parser to use the device at address 0x22 that we specified before. number: 0 // use GPIO 0 mode: OUTPUT // this can be either INPUT or OUTPUT, for our case, it should be OUTPUT. inverted: true // Invert the logic of the pin.
Once again, it is needed, as we are sinking current into the pin, and the circuit was designed that way… You can however use it noninverted if you really want, it will just look a bit odd on Home Assistant, if your On state, actually meant Off
The next section will be called binary inputs and may seem a bit confusing at first. But, trust me, it is not. This is just the way that we define our physical push buttons on the device. We need those, in the event that our Home Assistant Server is offline, or when we need to physically press a button on the device.
What? Why? Are we not building an IoT Controller? Why should we press any physical buttons on it? Well, the answer to that is quite obvious. There will definitely be times that you want to control an attached device by pressing a physical button. It does not make sense to scurry around, swiping through apps on your smartphone, while you are standing right next to the device in question. To leave out this basic functionality, would be plain silly, and in my view, bad engineering.
The syntax is almost the same as the outputs above, but we are also adding automation: We want the relay to be toggled each time the button is pressed. This will allow us to use only one button per relay to switch it on or off. We are also adding a filter, in this case, a bit of debouncing, of 50ms. This will prevent the chattering of the contacts on the switch from generating more than one event for each button press.
The final section of the file will be a switch: section. This will allow you to control the relays from inside Home Assistant. ( The outputs are considered an internal to ESPHome function, and will thus not be exposed to Home Assistant. Add the following lines to the file
You can see that the syntax is once again very easy to understand. We also specify that the status LED for the relevant relay channel be switched on or off with the relay. This also happens when you press the physical switch. The name element will be the Name of the Output that will be displayed in Home Assistant. You can change it to your liking here, or you can also change it inside Home Assistant itself.
The completed file should now look like this. NOTE that if you decide to copy-paste the file from here, as I would recommend, you should only copy from the i2c section to the end of the file. Do not copy the WiFi and other sections. Your own file already has your own settings.
Well done, That was quite easy. Copy and paste the file into the edit screen that you have opened in ESPHome.
If everything went well. you should see an option to save or install as in the picture below.
YAML configuration file. ESPHome
If you can see both Save and Install, it means that your file syntax is correct. If not, go back and carefully check your indentations, as well as the spelling of the commands. It should not be a problem if you copied it from above…
Now click on save. You will get a confirmation. Make sure that the prototype is connected to the USB port of the computer, or to another power source. Wait a few seconds to make sure that it is connected to the network, and then click Install.
ESPHome will now parse your YAML file, generate the needed code, and compile it. After that, it will upload the new firmware to your device. Wait until you can see the device restart and connect to the network in the log window.
The Firmware is compiled and the uploaded OTA
The device had booted, note that the PCF8574 has been detected and that we can see our configuration data (in purple text)
Configuring Home Assistant
We can now start to add this all to Home Assistant. It is also very likely that you will be prompted to add the device by Home Assistant itself. If this did not happen, or like with my testing image on the VM, you have a lot of old stuff floating around as well, we can do it manually …
Go to the Configuration Menu, and click on Integrations.
Click on the esp8266-nodemcu option on ESPHome
Click on the entities, next to the device …
The available entities ( selected with a blue checkmark ). Entities with a red warning are stale, meaning old, unavailable or offline… You can remove them, but they tend to show up again on their own…
We can now select the two relays, as well as the Pushbuttons. Then click on Enable selected.
When you now go back to the Home Assistant Home screen, you will see your device with its controls, on the screen. You can now control the device from Home Assistant. You will note that the two push-buttons are also present in Home Assistant, but, they are only indicators. This means that while they will change state briefly when you press the physical switches, they can not be controlled directly from Home Assistant. They can however be used in automation, or at least I believe so. The debouncing times are however rather short, so I would recommend that you base any automation on the actual relay states instead. A sneak preview of the PCB
As promised above, I will now give you a quick preview of the PCB’s. They were manufactured by PCBWay
I am once again awed by the precision of these bords. They are absolutely flawless and exactly true to my design. The irregular isolation cut-outs are exactly to speck and size, the silkscreen is crisp and not blurred. All component footprints are correct, and there seem to be no shorts or open circuits on initial testing with a multimeter.
You can get your own version of these for only $USD 5.00 excluding shipping from here I believe you will be just as impressed as I am.
So let us look at these boards…
PCB’s in packaging
Securely packaged in vacuum-packed bubble wrap
Topside of the PCB
Top Side of PCB
Back of PCB, isolation cutouts clearly visible
The PCB’s have arrived.
My biggest frustration now will be to wait for the rest of the components to arrive. I already have some of them in stock, and can repurpose some others, but I think that I will rather wait for everything to arrive so that I don’t have to assemble them in stages. I plan to assemble 2 of the 10 boards and make some of the remaining 8 available to interested people. Contact me on messenger if you are interested.
Conclusion
This concludes part 2 of this series. In part 3, we will look at the assembled PCB’s, as well as take a more detailed look at using them together with Home Assistant. I will also attempt to do the Tasmota integration, this will involve compiling my own special version of Tasmota.
I am also planning to release the assembly process as a series of pictures or maybe a video on Patreon.
If you like what I do, I want to ask you to consider becoming a Patron. With some assistance from generous people like yourself, I can create some more interesting projects.
The Internet of Things (IoT), as well as Home Automation, are steadily gaining popularity all the time. You can already buy quite a lot of commercial products or do your own D.I.Y implementation. Many different companies offer various devices and modules to help you do your project easily. But many of us will know that these modules always come with a lot of wires and connections, which can be very unreliable, and also unsightly to look at.
Most of these solutions are also relying on you placing some stuff on an electronics-breadboard, or strip-board for more permanent installations. You can also decide to design and manufacture your own custom PCB.
On the software side of this problem, there are many commercial and open-source solutions available, and most of them work with almost anything on the market (With various degrees of complexity and a varying learning curve).
Having access to a few ( four to be exact ) Raspberry Pi Computers, as well as a huge number of ESP8266, ESP32, Arduino and STM32 Development boards that are lying around in my working area, as well as being quite lazy to do repetitive tasks, I have been playing with the idea for quite a while to automate some or maybe all of the lights in my house. I have also built quite a few device prototypes, only to tear them down again after testing them.
The reason for this, and this is only my own opinion, is that an electronics breadboard is meant for prototyping only. They are not reliable in the long term, and they look extremely messy. Using a certain development board, and connecting all of the supporting components and modules to it, also leaves quite a mess. So,
1) The project must be contained on a single PCB. 2) It must have WiFi and or Bluetooth support (ESP8266 does not have this [ Bluetooth ]) 3) It must be able to be powered from 220v mains directly, OR, through a single Plug Type AC to DC converter, preferably something already available on the market. 4) The power supply unit must supply adequate power to the unit. 5) I want to make some actual use of a Raspberry Pi, as they were not meant to lie around gathering dust 🙂
6) Once completed, the project should be able to be updated OTA or with as little fuss as possible. 7) The freedom to code in whatever language I want, as well as be easy to use with prebuilt firmware like ESPHome and or Tasmota and the likes.
Taking into consideration cost, as well as flexibility, I decided on using the ESP8266 and in later versions ESP32. These have WiFi and Bluetooth already built-in but have a nasty breadboard form factor. The popular NodeMCU is a great starting point, but it has many small design flaws, most of which were fixed in later versions, but, as I live in SE Asia, and electronics are super cheap, you never know what you get.
With this in mind, I have decided to design my own controller, based on the ESP-8266 12E Module. This will give me the flexibility I need while allowing me to add custom components and features as needed, which is not possible with a stock version.
As far as Software is concerned, Home Assistant, running on a Raspberry Pi 4B with 4Gb Ram will be sufficient to control all of this. Firmware on the ESP12-E can be either ESPHome, Tasmota, or something that I write on my own, connecting to the internet and using MQTT for communication. (The options here are also almost too many to mention, but, IFTTT, Adafruit IO, and Blynx come to mind… Alexa and Google Assistant support are also possible, but definitely not required in my application at this moment.
Any permanent project grows on you, and over time, you will want to add features and functions. Keeping this in mind when you start designing saves a lot of headaches later. I will thus definitely make sure to provide access to the I2S, SPI and Serial Peripherals.
Prototyping and Initial Testing
Software It is quite impossible to design something without building a prototype, and doing some very rigorous testing. To do this, I have started with a copy of Home Assistant running in a VM on my HP ML350G Debian server computer. This way, I can quickly test Home Assistant, and make sure everything works as I want it to, without having to do it on the PI. This will mean that I will have to re-do most of the software configuration again on the PI, but it gives me the flexibility to take snapshots and restore them if something goes wrong.
The procedure that I followed, for VirtualBox, can be found here. I am sure that it will be very similar for Windows users.
Start Home Assistant
When you have completed the installation, you can go ahead and start Home Assistant.
You may now open Home Assistant in your browser by going to http://<your-ip-address>:8123 and pressing enter. You will see something similar to this:
Install ESPHome
You may now scroll down to the Supervisor Menu Item, Click on the Addon Store link, and Install ESPHome.
Please make sure that you select “start on boot”, “watchdog”, “auto-update” and “show in the sidebar” Also, make sure to start the add-on
You are now ready to flash ESPHome onto your development board. Please note that you will have to repeat this step on the actual PCB device that we will design and build later. For now, we will however use a standard NodeMCU v3 module, as it contains the ESP-12E module that we require.
As we have not configured HTTPS in our Home Assistant installation, we can only flash the initial firmware using an external application. This application is called ESPHome Flasher, and you can download it here.
Prepare to Flash
We need to create an initial device in ESPHome. to do this, you need to click on the ESPHome Menu Item in the Home Assistant sidebar. Then click on the Green and White + sign at the bottom right corner…
Give your device a descriptive name, I went with iot-con-prototype. Also, add your WiFi network credentials (SSID and Password). Then click on NEXT.
You now have to select your ESP board. I went with NodeMCU.
Click on NEXT when you are done. You will now be alerted that a configuration has been created. Click on the Close button.
You will now see your device in the list. The red line means that the device is OFFLINE.
If you have not installed ESPHome Flasher yet, now is a good time to do it. When you are done, connect the NodeMCU module to the computer’s USB port and start ESPHome Flasher. Note: On Linux, you dont have to install it. you can just start it from the terminal using ./ESPHome-Flasher-1.3.0-Ubuntu-x64.exec ( this example is for Debian ) yours may differ … sudo may be required
Select the communications port from the dropdown menu. Now go back to Home Assistant, ESPHome Screen. Click on the Install link (in yellow) of the device that we added previously. Then click on Manual Download
ESPHome will now compile your initial firmware and prompt you to save the .bin file it has generated.
Take note of the location of this file, we will need it for the next step.
Now you can go back to the ESPHome Flasher window, and browse to the .bin file that you have just generated and downloaded.
When this is done, you can click on Flash ESP. The firmware will now be flashed onto the NodeMCU device that we will use as our prototype.
You can close the Flasher application when you see predominantly purple text in the console window. This means that the device has connected successfully with your WiFi network, and by extension, also with ESPHome and Home Assistant.
If you now go back to ESPHome, you will see that the device has a green line above its name, which means that it is online. Please note that at this stage, the device does not do anything, as we have not yet configured it. That will be our next task, but before we do that, we will have to start playing with some of the physical hardware yet.
Designing the Hardware
I have decided to base this controller on the popular NodeMCU v3 development board. This little board makes use of the ESP12-E module, designed by AITinker, from whom I have bought many well-designed modules before. The module (NodeMCU) is in a BreadBoard form factor, and thus clearly meant for prototyping, or use on a base-board of some kind. I do however have some issues with this module, namely:
1. Many of these units are in fact clones. Some of these does not have proper protection between the board and the USB port to power them. This makes it dangerous to connect power to the VIN pin. 2. The board does not have a built-in 5v regulator. The 5v output (VIN) is thus taken directly from the USB port that powers it. This limits the total available current to the board and all peripherals to the 500mA available from the USB port.
All of these issues are however easy to overcome, as Espressif has made available excellent documentation on using their modules. I will thus be using this documentation as a reference design for my own device.
Another issue is expandability. The module provides many broken out GPIO pins (D0 to D8), but in order to remain super flexible for future expansion, I would have to make sure that I keep the built-in peripherals, like i2c, spi, and uart free for connection to external addon components in future. To solve this, I have decided on using the PCF8574 I2C IO Expander. This means that…
D0 (GPIO16) needs to be kept free for Wake up from deep sleep mode D1 (GPIO5) SCL line of I2C Bus D2 (GPIO4) SDA line of I2C Bus D3 (GPIO0) connected to Flash Button, and also a strapping pin D4 (GPIO2) Tx of UART 1 D5 (GPIO14) HSCLK – SPI Clock D6 (GPIO12) HMISO – SPI MISO D7 (GPIO13) Rx UART 2 / HMOSI – SPI MOSI D8 (GPIO15) Tx UART 2 / HCS – SPI CS as well as a strapping pin D9 ([Rx] GPIO03) Rx UART 0 D10 ([Tx] GPIO01) Tx UART 0
Looking at this, it is thus very clear that I2C is the way to go, as it will use only two pins, leaving the other GPIO’s free for future expansion.
Relay Driver Circuit, status led(s) and user control
The PCF8574 has very weak current sourcing capabilities, but it can sink 25mA per IO pin. As I will be driving the chip from 3v, this will however not be enough to drive a 5v relay. I will thus be making use of an optocoupler to drive the relay from 5v, using a general-purpose NPN transistor. That way, I can make sure that I do not overload the IO line on the PCF8574, as well as keep the 3v and 5v lines isolated from each other. (They will however still share a common ground).
Relay Driver Schematic
As you can see from the schematic above, the relay driver(s) will be connected to P0 and P1 of the PCF8574. A 200-ohm resistor will limit the current to about 16.5mA @ 3.3v. This is well within the tolerance of 25mA for the PCF8574 as well as the 50mA limit of the EL357N Optocoupler chip.
On the output side, I made use of the S8050 general purpose NPN transistor, capable of a 25v collector-emitter voltage, ant a continuous current of 500mA. Move than sufficient to drive the +/- 70mA to 80mA of current required by the relay coil. The current through the phototransistor side of the optocoupler is limited by a 1k resistor to the base of the transistor, to 5mA.
PCF8574 IO Expander Status LED(s) and User Input Schematic
Provision is made for up to four (4) pushbuttons, by pulling pins P4 to P7 down to ground, through an external push-button connected to a 2-way pin header. The design allows for the pin to be used for another function as well, with an additional breakout pin provided on the edge of the board.
Likewise, the two status LED’s on P2 and P3 is connected via a 470-ohm resistor each, driving them at approximately 7mA each. This is once again within the 25mA sink limit of the PCF8574. These pins can also be used to connect to other hardware instead via the breakout header at the edge of the board.
The user input(s) and status led circuit was purposefully kept as plain as possible, as it is very likely that the additional 6 ports taken up by these will be used for other purposes instead.
USB to Serial Interface
The USB-to-Serial interface is done by using a CH340G. I have not modified the reference design from the original NodeMCU v3 too much, as it works well, and thus need no changes. I did however make sure that there is a protection diode between the USB 5v line and the VIN line on the PCB. Most of the existing NodeMCU boards does not do this, or when they do have the protection diode, that line is directly connected to the VIN pin. in my view, that is not ideal, and can cause unnecessary damage to your computer’s USB port or NodeMCU board in the event that you power it from an external source, and also use USB power to upload code… Not that it should be done that way anyway, but rather safe than sorry later.
USB-to-Serial Schematic
The two transistors (VT1, and VT2) is used to do very cleverly put the board into programming mode, as well as reset it after flashing, without the end-user having to press any of the flash or reset buttons. This is also part of the reference design on some of the NodeMCU boards. I can not comment if it is standard. I found it useful, so decided to include it as well.
ESP-12E with strapping pins and power supply
The ESP-12E module, as manufactured by AITinker, seems to be quite stable and easy to use. It does however have a couple of caveats, to enable it to function as intended. The strapping pins (discussed later) should be in a certain state at bootup time, and failure to adhere to that will definitely cause a failed boot or wrong startup mode.
GPIO0, GPIO2, EN and RST should be pulled HIGH for a NORMAL boot, while GPIO15 should be pulled LOW. Pulling GPIO0 LOW at boot, will put the board into FLASH mode.
Another change that I made is that I did not break out the raw Analog input pin, as is done on some of the boards ( as a VV pin, or sometimes as an unlabeled, or reserved pin). The Analog input pin on the stock module is designed for around 1.0v input. This is fed from a resistor divider, to effectively scale your 5v input down to valid levels.
ESP-12E and Power Supply Schematic
GPIO16 (D0) is used internally by the ESP-12E to wake the module from deep sleep. This is done by connecting GPIO16 to the reset pin. To wake up the module, GPIO16 is internally pulled LOW, thereby resetting the module. I have decided to add a user-selectable jumper that can be enabled to connect GPIO16 to RESET, that enabling this functionality. It is however to be noted that the jumper must ONLY be set AFTER the relevant deep sleep mode has been enabled in the firmware for the module.
The standard NodeMCU has only a single 3.3v voltage regulator installed. I added a dedicated 5v voltage regulator as well and powered it directly from the VIN pin. This regulator will only function when the device is powered from an external power source, with an upper voltage limit of 15v DC. Protection for the USB port is provided by a diode between VCC_USB and VCC5V.
As I have mentioned at the start of the article, this is a show and tell, of how I solved a particular problem that I had. I do not believe in re-inventing the wheel, but to adapt and improve as and where I see fit, to my own purpose. This project will by no means be unique, or better or worse than other similar devices on the market today. It is however designed to suit my particular needs for my particular project.
The design of the PCB and Schematics was done in EasyEDA, which I believe to be quick and easy to use, as well as Linux friendly. (There does not seem to be many of those around, KiCAD being the exception to that rule. I have however not been too successful in using that before, to no fault of KiCAD at all. I am just not prepared to learn a new EDA CAD package just for the sake of doing it. Time is precious, and I can get everything I need to do done with EasyEDA).
PCB Layout
The PCB is dual-layer 99.06mm x 83.058mm. Six mounting holes are provided. The ESP-12E is placed at the top, roughly in the left-hand corner. As per Espressif design recommendations, no tracks are routed underneath the antenna area. An approximate 15mm x Board width area is also kept clear of any tracks or ground plane(s) to also prevent interference with the RF signal generated by the device. All components are mounted on the top payer of the PCB and are as far as possible grouped together by their function and purpose in the circuit. As the two onboard relay modules will very likely be used to switch mains power, they have also been excluded from the ground plane(s). Cutouts around all possible mains power carrying pads and tracks were also added to prevent tracking.
A DC Power Socket, and USB port, as well as access to the single Analog Input, Enable, Reset Pin and Button and VIN pin is provided on the left-hand side of the PCB. All other IO pins, as well as the six remaining ports on the PCF8574 IO expander, is accessible on the right. Note that GPIO4 and GPIO5 ( D1 and D2 ) were hard-wired as I2C lines. They should thus not be used for any other purpose. All other pins are accessible and broken out, clearly labelled with their GPIO numbers, as well as NodeMCU style Dx numbers. There are also an additional 6 IO pins broken out at the bottom of the ESP-12E module, to provide access to the seldom-used SDCard interface.
PCB Top Layer ( Rendered )
PCB Bottom Layer (Rendered)
3D Render PCB from Left
Manufacturing the PCB
This PCB will be manufactured at PCBWAY. The Gerber files and BOM, as well as all the schematics, will soon be available as a shared project on their website. If you would like to have PCBWAY manufacture one of your own, designs, or even this particular PCB, you need to do the following… 1) Click on this link 2) Create an account if you have not already got one of your own. If you use the link above, you will also instantly receive a $5USD coupon, which you can use on your first or any other order later. (Disclaimer: I will earn a small referral fee from PCBWay. This referral fee will not affect the cost of your order, nor will you pay any part thereof.) 3) Once you have gone to their website, and created an account, or login with your existing account,
4) Click on PCB Instant Quote
5) If you do not have any very special requirements for your PCB, click on Quick-order PCB
6) Click on Add Gerber File, and select your Gerber file(s) from your computer. Most of your PCB details will now be automatically selected, leaving you to only select the solder mask and silk-screen colour, as well as to remove the order number or not. You can of course fine-tune everything exactly as you want as well.
7) You can also select whether you want an SMD stencil, or have the board assembled after manufacturing. Please note that the assembly service, as well as the cost of your components, ARE NOT included in the initial quoted price. ( The quote will update depending on what options you select ).
8) When you are happy with the options that you have selected, you can click on the Save to Cart Button. From here on, you can go to the top of the screen, click on Cart, and make any payment(s) or use any coupons that you have in your account.
Then just sit back and wait for your new PCB to be delivered to your door via the shipping company that you have selected during checkout.
Conclusion of Part 1
This is the end of a very long part 1. We have started to look at the steps involved to get started with designing our own IoT Controller, did some initial software installation, and took a detailed look at the schematics and PCB…
In part 2, we will look at
1) Writing the configuration for ESPHome to control your device 2) Look at Tasmota as an alternative way to control the device 3) Integrating the device into Home Assistant 4) Have a go at writing our own firmware using the Arduino IDE to control the device using MQTT 5) Depending on how long shipping of the components and PCB takes, assembly and testing of the actual device
Thank you for your time. This is a very long article, and I appreciate your interest.
So many people asked me which Lora Module I use for my projects. In this part of the series, I will show you, as well as shed some light on another module, that although seemingly cheap, is, unfortunately, according to me, a complete waste of time and money.
Heltec LoRa 32 v 2 – The good stuff ( according to me at least)
Technical SpecsElectrical SpecificationsPinout
Installation in Arduino IDE:
Installation of the libraries into the Arduino IDE is quite easy, just follow the link to heltec…
The Bad ( according to me )
The following module, is, according to me, an absolute waste of time and money. Documentation is impossible to find, and that that you do find, as often incorrect. The pin-outs are wrong, with no definite standard.
I am talking about the TTGO Lora V1 or V2 or what ever ??? can seem to even find that answer reliably. I was initially attracted to this module, as it was allegedly compatible with the heltec version, and did not have the oled screen, which, to be honest, is not always needed in every project. It was also about 25% cheaper, and could be sourced locally, without enriching the greedy shipping companies 😉 (I just have to rant about this, as 25USD to ship 100g worth of stuff is a ripoff. Either that or 60 to 90 days of guess-if-it-will-arrive mail is not on ( and even that is 10 USD!)
So, having high hopes, I ordered one of these boards, hoping to use it together with my heltec boards… It arrived, and that was well the top came of.. I could immediately see that the quality of the PCB was quite bad. Documentation was missing, and even the supplier sent me to a heltec pinout, which, after a quick test were definitely not correct…
Google turned up mixed results, and eventually I found a sort of accurate pinout …
Alleged pinout for TTGO LoRa device
This pinout also turned out to be only about 50% correct, and after manually trying to map out the pins, I was sort of confident enough to test it further…
Further problems arose, LoRa does not work, I2C does not work, SPI does not work shall I continue…? 🙂 It now seems clear that the board that I bought was a clone of a clone, and a very bad one at that … I will post a picture of the actual board below, in the interest of education, to inform others not to get duped as well. Likewise, If I am the mistaken party, and you have had success with this board, please give me a message/yell and lets share some knowledge
The Front (Top Side) of the Module
Front (Top) of the moduleBack (Bottom) of the module
I hope that you found this useful and that I will see you for part 3 of the series, where I will get into the actual coding.
When designing IoT solutions, we all encounter the problem of connecting our device(s) to each other, either directly, or through the internet. In Urban areas, it is quite easy to use WiFi or even GSM to achieve this, but these solutions often come with additional costs in the form of subscriptions. Although it is possible to run your own WiFi network free of charge, you will soon run into issues with the range…
Enter LoRa (short for Long Range) Radio communication. LoRa is a radio technology derived from chirp spread spectrum technology. It uses an ISM band, meaning it is unregulated in most countries, if you use the correct frequency for your country, that is.
It is also extremely low power, making it ideal for use with battery-powered devices. The technology is available in Node-to-Node, as well as Node-to -Gateway modes.
In this series, I will show you how to use a few of the existing LoRa Modules available on the market.
Ai-Tinker Ra-02 (Sx1278)
Ra-02 Lora Module, with spring antenna, by Ai-Tinker
This Module is conveniently broken-out onto a breakout board. It is sort of bread-board friendly (depending on the size of your bread-board) and is nicely labelled. It is also extremely cheap ( around $USD5 each, depending on where you buy from).
Caveats
There are quite a few important things that you should know about these modules before you start using them.
Disclaimer: The caveats listed below are by no means complete, or even valid. They are the result of experimentation by myself, with the intent to destroy a few modules, to see how hardy they are. Also take into mind, that living in SE Asia, it is quite common to buy something from a shop, where the seller has no or only a very limited idea of what he or she is selling, and are thus usually quite unable to provide any technical support.
To summarise: USE YOUR HEAD. If I did leave out something, it is quite possible that I forgot, or decided not to include it on purpose. This is a general guide, and you should ideally do your own research as well. That is the best way to learn.
1) Always connect an Antenna. This may seem like a logical one, but it is extremely important. The module is capable of quite a lot of transmission power, and operating it without an antenna will quickly damage the module, permanently.
2) ONLY use 3.3v, even on the control lines (the module uses SPI). This is quite important, as it is not very clearly stated by the suppliers, and will result in very short-lived component operation 😉 If you absolutely have to use 5v, use a level converter. (There are examples available on the internet, where they use this chip directly from an Arduino Uno. I can confirm that that approach does work, BUT, not for very long. I have purposely sacrificed a pair of transceiver modules so that you don’t have to. You can also adjust the SPI frequency, in the event that your level converter is not capable of running at a high SPI frequency.
3)Make sure that you connect ALL the ground pins on the device. This is another area that is not fully explained by the user manual and does “unexplainably” result in damaged modules.
4) Use short, good quality cables, and if possible, keep the module off the breadboard. While testing the modules, I found that the usual DuPont wires, as everyone should know by now, are quite unreliable. Combine that with a bread-board that has seen its share of use, and it is a definite recipe for headache 🙂
5) LoRa Antennas are polarised, make sure you have your antennas in the same orientation. Although this will not prevent it from working over short distances, it makes sense to just do it correctly. Good RF practices never hurt anybody 🙂
Connecting to Arduino
A Note on Power: It is important to power this module from a decent dedicated 3.3v power-supply. The Arduino Uno does sometimes have a 3.3v regulator on-board. From my tests, it is however not always up to the task, as the module may spike up to 120mA when transmitting. It is thus also recommended to have a nice fat capacitor across the power lines (decoupling cap) to soak up any spikes.
As mentioned above, a level converter is mandatory for a 5v Arduino. You may do without it if you use a 3.3v Arduino, but once again, your mileage will vary 🙂
Both the transmitter and receiver uses the same connections, which are listed below:
LoRa SX1278 Module
Arduino Board
3.3V
–
Gnd
Gnd
En/Nss
D10
G0/DIO0
D2
SCK
D13
MISO
D12
MOSI
D11
RST
D9
Connections to the Arduino from a LoRa RA-02 Module
Remember that you NEED a Level converter between the LoRa Module and the Arduino.
Software Library
The software library that we will use in our example is the excellent library from Sandeep Mistry. We will just include this into the Arduino IDE, and then use a slightly modified version of the examples for our experiment. It is also important to note that we will use Node-to Node communication, NOT LoRaWan. This means that all your communications will essentially be unencrypted, and not addressed. This does however allow you the flexibility to design and implement your own addressing scheme.
LORA code for Transmitting Side
#include <SPI.h>
#include <LoRa.h>
int counter = 0;
void setup() {
Serial.begin(115200);
while (!Serial);
Serial.println("LoRa Sender");
if (!LoRa.begin(433E6)) { // Set the frequency to that of your //module. Mine uses 433Mhz, thus I have set it to 433E6
Serial.println("Starting LoRa failed!");
while (1);
}
LoRa.setTxPower(20);
}
void loop() {
Serial.print("Sending packet: ");
Serial.println(counter);
// send packet
LoRa.beginPacket();
LoRa.print("hello ");
LoRa.print(counter);
LoRa.endPacket();
counter++;
delay(5000);
}
LORA code for Receiver Side
#include <SPI.h>
#include <LoRa.h>
void setup() {
Serial.begin(115200);
while (!Serial);
Serial.println("LoRa Receiver");
if (!LoRa.begin(433E6)) {
Serial.println("Starting LoRa failed!");
while (1);
}
}
void loop() {
// try to parse packet
int packetSize = LoRa.parsePacket();
if (packetSize) {
// received a packet
Serial.print("Received packet '");
// read packet
while (LoRa.available()) {
Serial.print((char)LoRa.read());
}
// print RSSI of packet
Serial.print("' with RSSI ");
Serial.println(LoRa.packetRssi());
}
}
Where to from here?
If all went well, you will see packets being received in the serial monitor of the Arduino IDE, connected to the receiver module. You will also see that the data from this example is sent as a string… It is however also possible to send binary data, by using the LoRa.write() function.
In the next part of this series, I will show you how to use LoRa with the ESP32/ESP8266, as well as a working example with binary data transmission and an addressing scheme in part 3.
