Entrant 84 : Controlling 433MHz Outlets with ESP8266
Posted: Tue Mar 15, 2016 1:29 pmUser
RinusW
Description
This project realises a system for controlling remote control power outlets and dimmers working with 433 MHz receivers. The system uses an ESP-12F SoC coupled to a 433 MHz transmitter. The ESP-12F uses the Lua NodeMCU firmware and operates as a UDP server waiting for switch commands for certain known switch outlets and dimmers. Such a command can take the next form: "p=kko i=12 u=3 a=1". When a valid command is received, this command is translated into high and low pulses according to the switch protocol. Since no presumptions are made relating to the protocols, a wide variety of controllable switches can be accommodated, as long as the protocol for that switch is known. The current implementation supports 4 different outlet families, including a remote controlled dimmer. These families are:
1. KaKu switch PAR-1000 with remote PAT-103, can also be used with switch ACM-1000.
command: "p=kko i=[0..15] u=[0..31] a=[1|0]"; PAR-1000 uses only i=[0..3] u=[0..2]
2. KaKu dimmer ACM-100 with remote AYCT-102.
command: "p=kkd i=[0..2^26-1] u=[0..15] [a=0|d=d[0..15]]"
3. Quigg/Globaltronics GT-7008AS switch with remote GT-7000
command: "p=qg7 i=[0..4095] u=[0..3] a=[1|0]"
4. Quigg/Globaltronics GT-FSI-08 switch with remote GT-1000
command: "p=qgg i=[0..15] u=[0..3] a=[1|0]"
In general the i is the group-id of the switches, and the u is the unit within the group. The a stands for action with 1=on, 0=off, and d<value> is the dim value. The software as implemented will not check for valid values of the parameters. Invalid parameters will probably result in a program crash and a reboot of the system.
The Lua software consists of 5 files, contained in the file "Lua_code_Xmit_433MHz.zip":
init.lua: provides a Wifi connection in Station mode, and then calls testInit.lua
testInit.lua: Init some global variables and the gpio pin, and compiles and exec the other files.
ServerUDP.lua: contains the code for the UDP server. Calls execute() function in exec.lua after a valid command is received.
exec.lua: interpret and execute valid commands for the supported protocols. Uses functions for the different protocols defined in protocols.lua.
protocols.lua: contains for each supported protocol an encoding function, generating the width of the pulses needed. Uses functions defined in the file prothelp.lua.
prothelp.lua: contains functions to determine the binary representation of the command string for each supported protocol.
All the files contains a lot of comment and therefore are self explanatory. Notice that in exec.lua the function gpio.serout() is used to send out the series of pulses. This is a blocking function and as such should not take to long to execute. This limits the length of the pulse series. The longest series in use right now is for the Quigg GT-FSI-08 switch, and has a length of 125 ms. Although this is quite long, it didn't led to any problem. The system is in use for several month now. Notice that the pulse sequence is transmitted a second time to improve the reliability. The protocol used by the switches does not provide in a feedback, by repeating the command we increase the probability to a response. However in general the reliability is very good.
The circuit diagram is shown in the file "433MHz_circuit_diagram.jpg”, and is quite simple. Next to the ESP8266 an AMS1117-3.3 voltage regulator is used for creating 3.3V from the 5V supply. And of course a FS1000A 433 MHz transmitter is also included. Although the transmitter is connected to the +5V supply, no level shifting is needed for the gpio port of the ESP12. The file "Lay-out 433MHz circuit.jpg" shows a simple single sided PCB lay-out, used by me only as template for placing and soldering the components on a single sided prototype board. The file "realization circuit.jpg" shows the realised system as in use for the last few months.
Nothing has been said about the use of this system. And that is because it can be used in a lot of different ways. The one thing that is important is that the client system (the user interface) is able to send UDP messages. For example, I used it with a rule on the IFTTT site to switch on some lights when certain conditions are met. One could also use Blynk (on another ESP8266?) to control your lights. In my home situation I'm running a website on a Raspberry Pi that enables me to control 11 light points. The file "MySwitches.jpg" shows the web page as user interface. The code for this webserver can be made available. Btw, two dimmers are actually not controlled by this 433 MHz system, but are using WiFi dimmers build also using ESP8266 devices. These dimmers control 12V led armatures. The shown Ledstrip Control is a ledstrip of 60 WS2812B leds controlled by another ESP12. But that is another project.
Parts
1. ESP8266 type ESP12F
2. FS1000A 433MHz transmitter
3. AMS1117-3.3 voltage regulator
4. Capacitor 47 uF – 35V
5. Capacitor 47 nF
6. 3 pin and 2 pin header male for serial RS232 and for 5V power
Links
Video
Images
RinusW
Description
This project realises a system for controlling remote control power outlets and dimmers working with 433 MHz receivers. The system uses an ESP-12F SoC coupled to a 433 MHz transmitter. The ESP-12F uses the Lua NodeMCU firmware and operates as a UDP server waiting for switch commands for certain known switch outlets and dimmers. Such a command can take the next form: "p=kko i=12 u=3 a=1". When a valid command is received, this command is translated into high and low pulses according to the switch protocol. Since no presumptions are made relating to the protocols, a wide variety of controllable switches can be accommodated, as long as the protocol for that switch is known. The current implementation supports 4 different outlet families, including a remote controlled dimmer. These families are:
1. KaKu switch PAR-1000 with remote PAT-103, can also be used with switch ACM-1000.
command: "p=kko i=[0..15] u=[0..31] a=[1|0]"; PAR-1000 uses only i=[0..3] u=[0..2]
2. KaKu dimmer ACM-100 with remote AYCT-102.
command: "p=kkd i=[0..2^26-1] u=[0..15] [a=0|d=d[0..15]]"
3. Quigg/Globaltronics GT-7008AS switch with remote GT-7000
command: "p=qg7 i=[0..4095] u=[0..3] a=[1|0]"
4. Quigg/Globaltronics GT-FSI-08 switch with remote GT-1000
command: "p=qgg i=[0..15] u=[0..3] a=[1|0]"
In general the i is the group-id of the switches, and the u is the unit within the group. The a stands for action with 1=on, 0=off, and d<value> is the dim value. The software as implemented will not check for valid values of the parameters. Invalid parameters will probably result in a program crash and a reboot of the system.
The Lua software consists of 5 files, contained in the file "Lua_code_Xmit_433MHz.zip":
init.lua: provides a Wifi connection in Station mode, and then calls testInit.lua
testInit.lua: Init some global variables and the gpio pin, and compiles and exec the other files.
ServerUDP.lua: contains the code for the UDP server. Calls execute() function in exec.lua after a valid command is received.
exec.lua: interpret and execute valid commands for the supported protocols. Uses functions for the different protocols defined in protocols.lua.
protocols.lua: contains for each supported protocol an encoding function, generating the width of the pulses needed. Uses functions defined in the file prothelp.lua.
prothelp.lua: contains functions to determine the binary representation of the command string for each supported protocol.
All the files contains a lot of comment and therefore are self explanatory. Notice that in exec.lua the function gpio.serout() is used to send out the series of pulses. This is a blocking function and as such should not take to long to execute. This limits the length of the pulse series. The longest series in use right now is for the Quigg GT-FSI-08 switch, and has a length of 125 ms. Although this is quite long, it didn't led to any problem. The system is in use for several month now. Notice that the pulse sequence is transmitted a second time to improve the reliability. The protocol used by the switches does not provide in a feedback, by repeating the command we increase the probability to a response. However in general the reliability is very good.
The circuit diagram is shown in the file "433MHz_circuit_diagram.jpg”, and is quite simple. Next to the ESP8266 an AMS1117-3.3 voltage regulator is used for creating 3.3V from the 5V supply. And of course a FS1000A 433 MHz transmitter is also included. Although the transmitter is connected to the +5V supply, no level shifting is needed for the gpio port of the ESP12. The file "Lay-out 433MHz circuit.jpg" shows a simple single sided PCB lay-out, used by me only as template for placing and soldering the components on a single sided prototype board. The file "realization circuit.jpg" shows the realised system as in use for the last few months.
Nothing has been said about the use of this system. And that is because it can be used in a lot of different ways. The one thing that is important is that the client system (the user interface) is able to send UDP messages. For example, I used it with a rule on the IFTTT site to switch on some lights when certain conditions are met. One could also use Blynk (on another ESP8266?) to control your lights. In my home situation I'm running a website on a Raspberry Pi that enables me to control 11 light points. The file "MySwitches.jpg" shows the web page as user interface. The code for this webserver can be made available. Btw, two dimmers are actually not controlled by this 433 MHz system, but are using WiFi dimmers build also using ESP8266 devices. These dimmers control 12V led armatures. The shown Ledstrip Control is a ledstrip of 60 WS2812B leds controlled by another ESP12. But that is another project.
Parts
1. ESP8266 type ESP12F
2. FS1000A 433MHz transmitter
3. AMS1117-3.3 voltage regulator
4. Capacitor 47 uF – 35V
5. Capacitor 47 nF
6. 3 pin and 2 pin header male for serial RS232 and for 5V power
Links
Video
Images