I2C Rotary Encoder


I will address two topics in this post.

The first one is about Rotary Encoders and what you can do with them. The second is about the Inter-Integrated Circuit protocol (I²C), developed by Philips.

Een in het Nederlands vertaalde versie van deze post kunt je hier vinden.

Rotary Encoders

A Rotary Encoder is a device that looks (physically) like a potentiometer but it does not vary the resistance between two/three connectors. Instead it gives pulses when the axle is rotated. Another difference with the potentiometer is that you can rotate the axle over 360° (in fact, there is no limit in how many degrees you can rotate the axle).

Most Rotary Encoders have a switch that is activated when you press the axle. And then there are Rotary Encoders that also have a three colour LED inside (RGB Rotary Encoder) which give you the option to feedback to the user a pallet of colours.

The Rotary Encoder generate pulses when the axle is rotated. Most Rotary Encoders generate 24 pulses at every 360° rotation. In your program you can count these pulses and let the program act on it (for instance: de- or in-crease the voltage of a bench power supply or step through a menu-list).

You may ask: “why use a Rotary Encoder and not just use a potentiometer?”. Well of course there is no “this is better than that” answer. It depends on the project at hand. If you build an analogue HiFi amplifier the potentiometer is probably the better choice. If you have a project with a microprocessor the (digital) Rotary Encoder gives you a lot of options to create a nice user interface (with maybe a fine/coarse change depending on the axle pushed short or long and a coloured feedback to show which mode is active).

This is an example Sketch to “read” a Rotary Encoder. You need hardware bounce control circuitry on pin A and B of the rotary Encoder to make it work reliably:

There is a drawback on using a Rotary Encoder in your project: You need a lot of pins!
One RGB Rotary Encoder needs two GPIO pins for the Encoder itself (plus GND), then you need one GPIO pin for the push switch and three GPIO pins for the RGB LED. Thats a total of six GPIO pins! On, for instance an ESP8266 that leaves only three free GPIO pins to control the rest of your project! On an Arduino UNO you have more free GPIO pins so one Rotary Encoder will not be a problem. But what if you want to connect two or even three Rotary Encoders. On an ESP8266 that’s impossible, but on an Arduino UNO you will also run out of free GPIO pins.

Luckily, there is a solution!

The Inter-Integrated Circuit bus (I²C)

This is called a (data) “bus” because you can connect a lot of devices at it. The “bus” exists of two lines. A clock line (SCL) and a data line (SDA). There is always (at least) one “master” device and all the other devices are “slave” devices. Every device has a unique address to differentiate between each other. I will not go into the depths of the I²C protocol, but normally the master will claim control over the bus and sends a request to a slave with a specific address. The slave in turn will take action on the request either by performing a specific action in the slave itself, by sending data back to the master or simply by sending an acknowledge back to the master to let him know he received the request. Here you can read more about the I²C protocol.

The I²C Rotary Encoder

Wouldn’t it be nice to connect a Rotary Encoder using only the two wires of the I²C bus!?

And that is what this post really is about: A Rotary Encoder that you connect via the I²C bus and control with the I²C protocol.

I developed the firmware and a small PCB with an ATtiny841 micro processor. I chose  the ATtiny841 because it has Wire hardware (the layer underneath I²C) for a Slave builtin. 

The firmware makes the ATtiny841 act like a ‘normal’ I²C Slave at one end and interface with a RGB Rotary Encoder at the other end. For ease of use I wrote an Arduino/ESP8266 Library to interface with the I²C RotaryEncoder.

With this setup it is possible to connect as many (literally!) I²C RotaryEncoders to your microprocessor as you like and still only use two GPIO pins. You can even connect other I²C devices (display’s, sensors etc.) to the same two GPIO pins leaving a lot of GPIO pins free for other purposes.

If you want, you can use the Interrupt pin of the I²C RotaryEncoder.

This pin generates an interrupt for every change in the position of the rotary axle or push button. All I²C RotaryEncoders share the same Interrupt line.

Here you can buy this I2C Rotary Encoder.

How to use the I²C RotaryEncoder in your project

The below code is an example Sketch to interface with the I²C RotaryEncoder (using the Interrupt line):

I2C Rotary Library

The I²C_RotaryLibrary has the following methods:

The library gives you the following setters:








set the value of the Rotary Encoder (-5000 .. + 5000)




set the rotary Step (1 .. 50)




set the Minimum rotary value (-5000 .. +5000)




set the Maximum rotary value (-5000 .. +5000)




set the Rotary Spin thime value (2 .. 100 milli seconds)



uint8_t, uint8_t, uint8_t

set the color of all 3 leds Red, Green, Blue (0 .. 255, 0 .. 255, 0 .. 255)




set the RGB color of all 3 leds (0x000000 .. 0xFFFFFF)




set the PWM value of the Red led (0 .. 255)




set the PWM value of the Green led (0 .. 255)




set the PWM value of the Blue led (0 .. 255)




set the Debounce Time of the switch (5 .. 250 micro seconds)




set the Mid Press Time of the switch (100 .. 5000 milli seconds)




set the Long Press Time of the switch (300 .. 10000 milli seconds)












set a new I²C address for this Slave (1 .. 127)




write a command to the Slave (CMD_READCONF | CMD_WRITECONF | CMD_REBOOT)

The library gives you the following getters:








reads the status byte




read the value of the rotary (-5000 .. +5000)




read the rotary Step (1 .. 50)




read the minimum rotary value (-5000 .. +5000)




read the maximum rotary value (-5000 .. +5000)




read the rotary spin time (2 .. 100 milli seconds)




read the Address Register




read the current Red led PWM value (0 .. 255)




read the current Green led PWM value (0 .. 255)




read the current Blue led PWM value (0 .. 255)




read the Debounce Time of the switch (5 .. 250 micro seconds)




read the Mid Press Time of the switch (100 .. 5000 milli seconds)




read the Long Press Time of the switch (300 .. 10000 milli seconds)




read the Major Firmware Release byte (0 .. 255)




read the Minor Firmware Release byte (0 .. 255)




read the Mode register byte (0 .. 255)




read the Mode register byte and test against (STNG_HWROTDIR | STNG_FLIPMODE | STNG_TURNMODE)

And the library gives you the following helpers:








true if the Rotary Value has changed




true if the Rotary Value > previous value




true if the Rotary Value < previous value




true if the Button is pressed




true if the Button is released before midPressTime




true if the Button is released between midPressTime and longPressTime




true if the Button is released after longPressTime

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

Universal InfraRed IoT Learning Remote


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 | 1 Comment

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


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)


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.

[31-07-2019] Vanaf versie 0.4.5 kan de DSMRloggerWS firmware ook telegrammen van pré DSMR 4.0 standaard Slimme Meters uitlezen!

De firmware en nog veel meer kun je op github vinden!

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 | 337 Comments

1of! Platform for developing ESP8266 devices


      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
  • 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 , , , , , | 3 Comments

Home-Assistant Integratie met de DSMR-logger

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


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 , , , , , , , , , | 46 Comments