Universal InfraRed IoT Learning Remote

[ 298 views ]

In this post I will guide you through the process of building a device that can capture Infrared-messages from an Infrared remote controller (learning mode), and resend the captured Infrared-messages (sending mode). I will use the affordable and easy to use 1of!-experimental boards to prototype, setup and test the hardware. For the documentation of the schematics I will use the awesome open source KiCAD EDA. Together we will build the complete hardware as a true ‘one of a kind’ device.

After that I will show you the steps to make a Printed Circuit Board (PCB) from the schematics. 

Een Nederlandse versie van deze post staat op de site van opencircuit.nl

Principal of Infrared communication

Infrared (IR) communication is a common, inexpensive, and easy to use wireless communication technology. IR light is undetectable to the human eye because it has a slightly longer wavelength (typically 950nm) than normal light (380-780nm) – perfect for wireless communication. An IR remote works by turning a LED on and off in a particular pattern. However, to prevent interference from IR sources such as sunlight or other lights, the LED is not turned on steadily, but is turned on and off at a modulation frequency (typically 36, 38, or 40kHz). 

The time when a modulated signal is being sent is called a mark, and when the LED is off is called a space. Most used IR-remotes use a modulation frequency of 38kHz which means that a mark is represented by a fast (38.000 times/second) “on/off” switching of the IR LED. 

A typical IR-message

An IR-message starts with a lead-in pulse that is much longer than the other pulses. Then there is a start-bit, then comes the actual data and then again a long pulse, to indicate the end of the IR-message (not shown on the image).

Design considerations

  • an IR-receiver-diode to capture the IR-messages
  • an IR-transmitter  (IR LED’s 950nm) to send IR-messages
  • some processing power
  • storage for saving the captured IR-messages
  • two status LED’s
  • the device needs to work with all Infrared remotes that modulate the Infrared signal at 38kHz
  • it must be able to capture 400 pulse-long messages (I need to be able to capture from and send commands to my Airco/Heater).

The obvious choice to interface with the device is by using a webserver and restAPI and consequently the device needs an internet connection. The ESP8266 with its builtin WiFi and flash filesystem storage is the logical processor for this project.

Project setup

The best way to develop any project is by slicing it into small, logical parts and developing and testing these parts one at the time. For now I see three major parts:

  1. The IR-receiver circuit
  2. The IR-sender circuit
  3. The software to glue everything together

The development will be done with the 1of!-boards as they are cheap and easy to use. For the initial setup the 1of!-Wemos processor board is the board of choice as it is easily programmed with a USB cable and for the rest of the circuity a 1of!-Solderless bread board is used. If I’m satisfied with the circuit on the 1of!-Solderless board I will flash the firmware to a 1of!-ESP12 processor board and build the circuitry on a 1of!-Proto board.

The IR signal processing is handled by a fantastic library  [v2.6.2 (20190616)] written by Ken Shirriff, David Conran and others. For additional details on how the library works, see Ken Shirriff’s blog: A Multi-Protocol Infrared remote Library for the Arduino.

Posted in Arduino, Computer, ESP8266, Hardware, KiCAD, WiFi | Leave a comment

Always wanted to own a PDP-11? Now you can!

[ 582 views ]

Some time ago I wrote a post about my trip down memory lane. I visited the Apple Museum Nederland and wrote how that brought me to the micro-KIM computer. A replica of my very first computer: the KIM-1.

But before I build the micro-KIM I found another project. It was the KIM-Uno, a ‘do it yourself clone of the KIM-1’ by Oscar Vermeulen. I made some changes to the firmware, mainly tidying up the firmware, enabling the use of the 6502 timers and a more accurate driver for the 7-segment displays (so you can fire-up every segment like you could in the real KIM-1).

But this is not a post about the KIM-1 or the KIM-Uno but it is about another very interesting project Oscar Vermeulen came up with: the PDP-11 replica. Oscar made the PiDP-11 after the huge success of an other project of him, the PiDP-8, of which he sold more than Digital sold the real thing. There seems to be a huge group of people interested in owning a vintage computer they spend a lot of time with during their (working) life.

It took Oscar two years building this kit, mainly because he wanted the console (and the switches) to be an accurate replica of the original PDP-11/70 console. He designed the console, switches and everything else exactly as you remember, only at a 60% scale. It looks like the real thing and operates like the real thing. This is due to two other projects Oscar incorporates in this project. The hart is the SimH simulator and the blinking leds are made possible by the BlinkenBone project. The processing power comes from a Raspberry Pi that has time to spare. In my case it doubles as a music server.

Posted in Computer, Hardware | Tagged , , , | 2 Comments

DSMR-logger V4 (Slimme Meter uitlezer)

[ 2,846 views ]

In augustus 2018 publiceerde ik een project voor het uitlezen van de Slimme Meter.

Aan de hand van de vele reacties van de mensen die het project hebben nagebouwd en mijn eigen ervaring met versie 3 van de DSMR-logger vond ik het tijd worden om een nieuwe versie van de hardware en de firmware te ontwikkelen.

Een aantal gebruikers gaf aan gebruik te maken van externe diensten om de gelogde data in grafieken weer te geven. Ik heb ook de behoefte aan een grafische weergave van de gelogde data maar ik wil voorkomen dat ik daar externe diensten voor moet gebruiken.

De doelstellingen voor versie 4 van de DSMR-logger zijn ongeveer gelijk gebleven aan die van versie 3 met dien verstande dat ik méér data op de DSMR-logger wil opslaan én dat ik de gelogde data ook in grafieken wil kunnen bekijken.

Tot en met versie 3 van de DSMR-logger wordt iedere seconde een telegram van de Slimme Meter ontvangen. Daarvan wordt slechts een klein deel (iedere tien seconden) één telegram ook daadwerkelijk verwerkt. Op zich is dat geen probleem want de overige negen telegrammen vallen gewoon in een groot gat maar .. de ESP8266 UART moet wél op deze vloed aan data reageren (de UART is interrupt driven). Zowel de Slimme Meter als de DSMR library van Matthijs Kooijman hebben een mogelijkheid om telegrammen alleen op afroep te versturen (Slimme Meter) of te vragen (DSMR library).
Het werkt zo: De Slimme Meter verstuurd alléén een telegram als de Data Request pin “hoog” is. De DSMR library heeft een functie call “enable(true)” die een pin van de ESP8266 “hoog” maakt en deze “hoog” houdt tot er een volledig telegram is ontvangen (waarna de pin “laag” wordt gemaakt).
Omdat ik voor de eerdere versies van de DSMR-logger een ESP-01 bordje wilde gebruiken kon van deze functionaliteit geen gebruik worden gemaakt eenvoudigweg omdat de ESP-01 niet genoeg pinnen heeft om er één voor vrij te maken.

De ESP-12(E/F) heeft wel voldoende GPIO pinnen en aanzienlijk (4x) zoveel geheugen als de ESP-01(S). Het was daarom een logische keuze om deze variant van de ESP8266 te gebruiken voor versie 4 van de DSMR-logger.

Het prototype en Proof of Concept heb ik op een 1of!-ESP12 processor bordje met een 1of!-Proto bordje gemaakt.

Data Request Circuit

Voor het “hoog” en “laag” maken van de Data Request pin van de Slimme Meter heb ik verschillende varianten uitgeprobeerd. Met een combinatie van één of twee transistoren en/of MosFets kreeg ik het niet stabiel werkend. Uiteindelijk is het een opto-coupler geworden.

Hieronder staat het schema voor de Data Request functionaliteit:

Het circuit wordt gestuurd vanuit GPIO12 van de ESP8266 en zorgt ervoor dat bij een “hoog” signaal de led in de opto-coupler gaat branden.

Hierdoor zal de transistor “sluiten” (hij gaat geleiden) waardoor de 5Volt op de collector (pin5) direct op de emitter (pin4) terecht komt (hij wordt “hoog”). Hierdoor zal DTR_SM ook “hoog” worden en zal de Slimme Meter een telegram versturen.


Telegram ontvangen

Het telegram wordt door de Slimme Meter via pin 5 van de RJ12 connector met een geïnverteerde 5volt TTL logica verstuurd. Voor de ESP8266 moet dit signaal zowel (terug) geïnverteerd- als geschikt gemaakt worden voor 3v3 logica van de ESP8266.

In rust zal R6 de Base van Q1 “hoog” trekken, waardoor Q1 “gesloten” wordt en de Collector, en daarmee Rx_SM “laag” zal zijn. Als Tx_SM “laag” is zal de Base van Q1 óók “laag” worden en zal Q1 “open” gaan staan. De Collector en daarmee ook Rx_SM zal door R8 naar 3v3 getrokken worden. Rx_SM is dan dus “hoog”. Komt er bij Tx_SM een “hoog” signaal binnen, dan zal de Base van Q1 ook “hoog” worden. Hierdoor gaat Q1 geleiden en zal de Collector samen met Rx_SM “laag” worden.


Hiernaast zie je hoe dat deel van het schema er op het 1of!-Proto bordje uit ziet.



I2C Interface

Een aantal bouwers van versie 3 vroeg of het mogelijk is in een volgende versie een klein Oled scherm op te nemen. Er zijn twee mogelijkheden om een Oled scherm aan te sturen. Eén is via een SPI interface de andere maakt gebruik van de I2C interface. Ik heb ervoor gekozen de I2C interface te gebruiken.

In versie 4 is een uitbreiding poort met I2C interface opgenomen die ook voor andere modules gebruikt kan worden. In de firmware wordt een Oled scherm aangestuurd.

Er kan in de J4 poort direct een Oled-module worden gestoken. Omdat niet iedere verkrijgbare Oled-module dezelfde aansluitingen heeft moet via draad-bruggen de juiste aansluitingen van J2 naar J3 worden doorverbonden (met name GND en 3v3 zitten niet op alle Oled-modules op dezelfde plaats).


ADC Interface

Een groot nadeel van de Slimme Meter is dat deze de energie van de zonnepanelen sommeert met die van de verbruikers op dezelfde groep.

Zo krijg je nooit een inzicht in de werkelijk opgewekte energie en de werkelijk verbruikte energie. De opgewekte energie kun je ook (buiten de Slimme Meter om) meten met een AC Stroom Sensor (bijvoorbeeld een SCT013-030 of ECS1030-L59). Deze klem je om de, in de meterkast binnenkomende, fase draad van de zonnepanelen en ze geven een spanning af die afhankelijk is van de stroom die door de kabel loopt. Voor gebruik van dit soort sensoren is de ADC (Analoge to Digital Convertor) pin van de ESP8266 uitermate geschikt. In het schema van de DSMR-logger v4 heeft deze, via een weerstands-deler een bereik van 0-5volt. Door R12 en R13 (5% tolerantie, een kleinere tolerantie is beter) aan te passen kun je dit bereik veranderen.

Putting It All Together

Om het schema van de nieuwe DSMR-logger te complementeren moet het basis-circuit van de ESP8266 nog worden toegevoegd (zie mijn post over de 1of!-ESP12). Dit basis circuit bestaat uit de ESP-12, de 3v3 voeding, een Program Interface en de schakeling rond de Reset en Flash buttons.

Dit resulteert in het complete schema voor de DSMR-logger V4:

Uitgebreide (‘technische’) documentatie van dit project kun je hier vinden.


      Een complete kit met alle onderdelen kun je hier kopen.

En hieronder staat een plaatje van het prototype zoals ik dat op de 1of!-bordjes heb gemaakt en getest.

En een life versie van het prototype in de meterkast:

Posted in Arduino, Computer, ESP8266, Hardware, Uncategorised, WiFi | 66 Comments

1of! Platform for developing ESP8266 devices

[ 1,116 views ]

 
      Je kunt een Nederlandse versie van deze post hier vinden.
 

Developing hardware almost always run through the same stages:

  • It starts with an idea
  • You design a concept on paper or in your head
  • Using a solder-less breadboard you connect parts to see that it works as you hoped it
    would
  • Depending on the number of units you need, you either design a PCB or you copy the
    breadboard schematic to an experiment board
  • Task fulfilled! You can sit back and relax.

If you, as I do, regularly design devices with ESP8266 processors you run into the same pitfall every time. The form factor of the ESP8266 (f.i. the ESP-12) is not specially breadboard friendly.

Bringing the ESP8266 to the Breadboard

If you use a 400 holes breadboard (90x65mm) almost 33% of the available space is needed for an ‘ESP8266 on a piggy board’ and more alarming: There are no holes besides the piggy board to connect wires to!





If you use a Wemos D1 you also lose about 30% of the available space, but at least you have the luxury of one row of holes on both sides of the Wemos D1.






But if your favourite is the NodeMCU board the numbers are even larger.
You lose 60% of the solder-less bread board!






And why? If you want to design a device with an ESP8266 you always need a basic schematic just to operate the ESP8266. It is contra productive to set that up on a breadboard just because you want to interface a view passive or active components to make your idea work.

To sum it up, you need:

  • five resistors
  • two push buttons
  • a voltage-regulator
  • circuitry that delivers the 3v3 needed by the ESP8266
  • a pin-header to upload firmware to the ESP8266.

A total of ten – eleven components that évery ESP8266 design needs.
And yes! there are benefits in using a Wemos D1 or NodeMCU board for the fact that they have all the hardware I described before ánd they have an USB to Serial chip on board. Because of that chip you can easily program these boards by just connecting the USB cable to your computer and press the upload icon on the Arduino IDE.

But…they are way to complex!
If you design a device with a ESP8266 you almost certainly do that because of the WiFi functionality of that processor. And once you have configured the WiFi settings you don’t need the USB to Serial chip anymore. Even updating the device with new firmware can easily be done “Over The Air”! So, if you want to develop a device with an ESP8266, the USB to Serial chip will make your design much more complex and more expensive, you need special skills or tools to solder the chip on a PCB and you will probably never use the functionality in real life devices.

And there are more arguments not to use these bulky boards for developing your own devices (apart from the fact that it is far more satisfying to design everything yourself). For instance if your device needs the ESP8266’s Analogue to Digital Convertor (ADC) and you start of with the Wemos D1 you need to know there is a voltage divider on the Wemos connected to the ADC pin and you have to make sure you use the same voltage divider in your overall design. And I get so confused by the naming of the IO-pins. You have the physical pin number (is pin 1 on the left top or ..), the made up ‘D-number’ and the underlying GPIO-number. Why?? And you can solder the pin-headers on the Wemos D1 with the ESP8266 on top or on the bottom. That messes up the physical pin numbering quit a lot!

Therefore I designed a solution that can be used as a development platform with a breadboard an experimenter board or an “one of a kind” end product.

Lets bring the Breadboard to the ESP8266

What I have done is made a processor board with an ESP8266, USB power, 3v3 regulator, a view resistors and elco’s, a Reset and Flash button and a 20 pole connector with all the available and usable pins from the ESP8266 plus GND, 3v3 and 5 volt power lines. You can choose to power the ESP8266 by soldering either a micro USB-B connector to the board or an ‘Arduino UNO’ large USB-B connector. To flash the ESP8266 you need an ‘USB to TTL’ cable or a simple USB-programmer and connect the ground, TxD and RxD to the programming header on the processor board (the 1of!-ESP12 can also be powered by the programming header if you apply 3v3 to the connector). To set the ESP8266 in flash-mode you press the flash-button and hold it pressed. Then you press the reset-button, release the reset-button and then release the flash- button. The ESP8266 is now in flash-mode and stay’s that way until you have uploaded your sketch or until you press the reset-button again (and if you program well, you can upload sketches wirelessly -‘Over The Air’- and never have to push buttons again).

The 20 pole connector has all the GPIO-pins 01, 02, 03, 04, 05, 12, 13, 14, 15 and 16 in that order so you never need to check what physical-pin is what ‘D-number’ is which GPIO-pin!

If you connect something to GPIO05 you program pinMode(5, mode) and digitalWrite(5, state) or digitalRead(5)!

SP1 and SP2 are not connected to anything but if you know what you’re doing and want to use GPIO09 and GPIO10 (which is not recommended) you can connect a wire from the ESP12 to these spare pins.


This board is called ‘1of!-ESP12’ and once you have one of these you can connect it with a ‘1of!-Proto’ board and start prototyping.











There is also a 1of!-Wemos board and there are two 1of!-Proto boards.











The smaller 1of!-Proto board has 18×22 (378) holes and the larger one has 25×22 (532) holes.









Small 1of!-Proto board connected to the 1of!-ESP12 with the ‘UNO’-like USB-B connector

On the bigger board you can solder a 20 pin female-header and glue a 90 x 65mm solder-less breadboard on it.

If you made your device on the breadboard or on the experiment board you can simply disconnect it from the processor board and start your next project on a new 1of!-Proto board or you can make it an “one of a kind device” and put your design in a standard box. If you made a killer-device you can convert your proto design into a real PCB by simply combining your own design and the simple basic ESP8266 schematic into a complete schematic in your favorite CAD program and create the PCB from there.

The whole 1of!-family (februari 2019)

 
     opencircuit.nl sells the 1of!-boards as kits!
 

I have made some instruction videos on how to make the 1of!-boards

Posted in Arduino, Computer, ESP8266, Hardware, WiFi | Tagged , , , , , | 2 Comments

Home-Assistant Integratie met de DSMR-logger

[ 2,161 views ]
Belofte maakt schuld. In mijn post over de DSMR-logger heb ik belooft om ook een post te schrijven over de integratie van Home-Assistant met de DSMR-logger.

Die belofte willig ik met deze post in.

Home-Assistant is, naar mijn bescheiden mening, één zo niet dé meest universele en robuuste Domotica oplossing die momenteel bestaat. De manieren waarop Home-Assistant gegevens uit andere systemen kan halen is bijna onuitputtelijk. Het is alleen zaak de voor jou beste manier te vinden.

Home-Assistant kan gegevens via een restAPI uit andere systemen (en dus uit de DSMR-logger) halen maar dat heeft als nadeel dat als je meerdere gegevens uit zo’n extern systeem wilt halen en deze allemaal beschikbaar worden gesteld via één restAPI deze restAPI voor ieder veld aangeroepen wordt en er dus héél veel data “over de lijn gaat” en het externe systeem ook vrij zwaar wordt belast.

Daarom heb ik, voor het uitlezen van de DSMR-logger, gekozen om Home-Assistant (HA) de gegevens uit een bestand (platform: file) te laten halen. Dat bestand staat op dezelfde computer waar ook HA op draait waardoor de overhead wordt geminimaliseerd.

Het werkt zo:

Middels een python programma doen we een request naar de DSMR-logger om de actuele gegevens van de Slimme Meter te geven. Dit programma moet periodiek (zeg één maal per minuut) gestart worden. Dat is de taak van ‘cron‘. Cron is een Unix/Linux deamon die, op basis van tijd, jobs start. In ons geval moet hij dus het python programma “DSMR_Actual.py” starten.

Met het commando ‘crontab -e’ (als user root!!) kun je de volgende regel in crontab aanbrengen:

Het programma DSMR_Actual.py ziet er zo uit:

In regel 5 krijgt ‘url’ de verwijzing naar de restAPI van de DSMR-logger waarmee de actuele gegevens worden opgevraagd.
Regel 6 zet dit om in een request aan de DSMR-logger en regel 9 stopt het antwoord van de DSMR-logger in de variabele ‘r’ die vervolgens in regel 10 gedecodeerd in de variabele ‘response’ wordt gestopt. Uiteindelijk schrijft json.dump() de terug gekregen response naar het bestand ‘/tmp/DSMR-Actual.json’.

Dat bestand ziet er dan zo uit:

Om het geheel een beetje overzichtelijk te houden heb ik alle scripts die ik voor HA gebruik in de map ~/.homeassistant/scripts/ gestopt.

Vervolgens moeten we aan HA duidelijk maken dat ze de gegevens van de DSMR-logger uit het bestand /tmp/DSMR-Actueel.json moet halen.

Ik heb al mijn sensor-configuraties in de map ~/homeassistant/sensors gestopt. In het configuration.yaml bestand heb ik de volgende verwijzing staan:

Deze regel zorgt ervoor dat alle .yaml files die in de map sensors/ staan als configuratie bestand van de HA installatie worden geparsed en opgenomen.

Eén van de sensor configuratie files is DSMT_Actueel.yaml. Deze heeft de volgende inhoud:

Om deze gegevens ook daadwerkelijk op de front-end van HA te krijgen moet ook groups.yaml worden aangepast.

De Home-Assistant front-end geeft dan dit inzicht:

Posted in Scripts, Uncategorised | Tagged | 5 Comments

DONOFF – WiFi enabled light dimmer

[ 2,323 views ]

Part-1 – Introduction

Years ago I started building RF devices to measure temperatures and switching lights on or off. I even wrote a small book (in Dutch) about my findings and experiments. But I always wanted to overcome the main disadvantage of RF devices: no feedback about the status of the lights. I thought that could be done better and with the introduction of the small ESP8266 WiFi enabled processors it could! But SONOFF beat me with there WiFi enabled switches. One great disadvantage of the SONOFF devices is the poor software. To make the switches usable you have to upload third party (mainly Open-Source) firmware and install a Home-Automation solution to control the switches. Another disadvantage of the SONOFF switches is .. well they are switches (Switch On Off). So there is room for improvement!
 
Albeit: I introduce to you: DONOFF (Dimmer On Off)!

Een nederlandse versie van deze post kunt u hier vinden.

Keep on reading

Posted in Arduino, DONOFF, ESP8266, Hardware, SONOFF, WiFi | Tagged , , , , , , , , , | 22 Comments

DONOFF – WiFi enabled light dimmer (Part 2)

[ 1,452 views ]

Part-2 – The Electronics

This is part 2 of the four parts posts about the DONOFF ecosystem.

• Part 1 – Introduction
• Part 2 – The Electronics (this part)
• Part 3 – The Firmware
• Part 4 – Building a DONOFF device

In the first part I introduced the DONOFF ecosystem and the design goals.
In this part I will try to explain the electronics.

The hundreds of posts on the internet about mains dimmer designs all use a triac to cut-off part of the sine waves of the AC mains. Some do this by leading-edge cut-off, where the first part of the sine wave is cut-off:

Another method is by trailing-edge cut-off where the last part of the sine wave is cut-off:

As elegant and nice as these solutions may be, they only work with resistive loads (incandescent lights). You can, at least in the Netherlands, no longer buy incandescent lights and in the near future the only lights available will be LED lights.

You cannot dim LED lights by either trailing- or leading-edge cut-off! But (dimmable) LED lights can be dimmed with Pulse Wide Modulation (PWM). PWM switches the power to the LED light on and off at a (relatively) high frequency.

The DONOFF hardware uses this PWM to dim the (dimmable) LED lights but PWM can also be used to dim incandescent lights (So as a bonus, DONOFF can also dim incandescent lights).

Keep on reading

Posted in Arduino, DONOFF, ESP8266, Hardware, SONOFF, WiFi | Tagged , , , , , , , | 1 Comment