Visual programming for Sonoff Basic

Visual programming for Sonoff Basic

For reference, by default, the Sonoff Basic program works with a mobile application through a Chinese cloud service, after the proposed rework, all further interaction with this device will be possible in the browser.

Section I. Connect Sonoff to the MGT24 service

Step 1. Create a control panel

Sign up at mgt24 (if not already registered) and log in using your account.


To create a control panel for a new device, click on the "+" button.

Panel creation example

After the panel is created, it will appear in the list of your panels.

In the “Setup” tab of the panel created, find the “Device ID” and “Authorization Key” fields, later this information will be required when setting up the Sonoff device.

Tab example

Step 2. Flashing the device

Using the utility XTCOM_UTIL download the firmware Sonoff Basic PLC to the device, for this you need a USB-TTL converter. Here instruction and video instructions .

Step 3. Configure the device

Apply power to the device, after the LED lights up, press the button and hold it down until the LED flashes periodically.

At this point, a new wi-fi network with the name “PLC Sonoff Basic” will appear, connect your computer to this network.

Decoding LED displays
LED indication Device Status
periodic double flashing no connection with the router
shines continuously connected to router
periodic uniform blinking wi-fi access point
extinguished no power

Open the Internet browser and enter the text "" in the address bar, go to the device settings network settings page.

Fill in the fields as follows:

  • "Network Name" and "Password" (to bind the device to a home wi-fi router).
  • “Device ID” and “Authorization Key” (for authorizing a device on the MGT24 service).

Example of configuring device network settings

Save the settings and reboot the device.

Here video instruction .

Step 4. Connect sensors (optional)

The current firmware supports up to four ds18b20 temperature sensors. Here video instruction for mounting sensors. Apparently, this step will be the most difficult, as it will require from you direct hands and a soldering iron.

Section II. Visual programming

Step 1. Create scripts

Blockly is used as a programming environment, the environment is easy to learn, so you don’t need to be a programmer to create simple scripts.

I added specialized blocks for writing and reading device parameters. Access to any parameter by name. For remote device parameters, the compound names are used: "parameter @ device".

Drop-down list of options

Example scenario of cyclic load on and off (1Hz):


An example of a script that synchronizes the work of two separate devices. Namely, the target device relay repeats the operation of the remote device relay.


Scenario for a thermostat (no hysteresis):


To create more complex scripts, you can use variables, cycles, functions (with arguments) and other constructions. I will not write all this here in detail, there are already quite a lot of Blockly training material .

Step 2. Script execution order

The script runs in continuous mode, and as soon as it comes to its end, it starts up again. At the same time there are two blocks that can temporarily suspend the script, "delay" and "pause".

The “delay” block is used for millisecond or microsecond delays. This unit strictly maintains the time interval, blocking the operation of the entire device.

The “pause” block is used for second (possibly less) delays, and it does not block the execution of other processes in the device.

If the script inside contains an infinite loop, in the body of which there is no “pause”, the interpreter initiates a short pause by itself.

In case of exhaustion of the allocated stack of memory, the interpreter will stop the execution of such a voracious script (be careful with recursive functions).

Step 3. Debugging scripts

To debug a script already loaded into a device, you can run the program’s tracing step by step.This is extremely useful when the behavior of the script was not the same as the author intended. In this case, tracing allows the author to quickly find the source of the problem and correct the error in the script.

Script factoring factorial in debug mode:


The debugging tool is very simple and consists of three main buttons: “start”, “one step forward” and “stop” (also, let's not forget about “input” and “exit” from the debug mode). In addition to step-by-step tracing, you can set a breakpoint on any block (by clicking on the block).
To display the current values ​​of parameters (sensors, relays) in the monitor, use the “print” block.
Here is a overview video about using the debugger.

Section for the curious. And what about under the hood?

In order for the scripts to work on the target device, a bytecode interpreter and assembler with 38 instructions was developed. A specialized code generator was built into the blockly source code that converts visual blocks into assembler instructions. In the future, this assembler program is converted into a byte code and transferred to the device for execution.

The architecture of this virtual machine is quite simple and there is no special point in describing it, you will find many articles on designing simplest virtual machines online.

Under the stack of my virtual machine, I usually allocate 1000 bytes, this is enough with a margin. Of course, deep recursions can exhaust any stack, but they are unlikely to find practical application.

The resulting bytecode is quite compact. As an example, the bytecode for computing the same factorial is only 49 bytes. This is his visual presentation:


And this is his assembler program:

  shift -1
 ldi 10
 call factorial, 1
 exit: factorial
 ld_arg 0
 ldi 1
 je 8
 ld_arg 0
 ld_arg 0
 ldi 1
 call factorial, 1
 ldi 1

If the assembly form of representation does not have any practical value, then the javascrit tab, on the contrary, gives a more familiar look than visual blocks:

  function factorial (num) {
  if (num & gt; 1) {
  return num * factorial (num - 1);
  return 1;

 window.alert (factorial (10));

As for performance. When I started the simplest scenario of the flasher, I got a 47kHz square wave on the oscilloscope screen (at a processor frequency of 80 MHz).



I consider it a good result, at least this speed is almost ten times faster than Lua and Espruino .

The final part

Summing up, I will say that the use of scenarios allows us not only to program the logic of a separate device, but also makes it possible to link several devices into a single mechanism, where some devices affect the behavior of others.

Also note that the chosen method of storing scripts (directly in the devices themselves, and not on the server) simplifies switching devices that are already working to another server, for example, home Raspberry, here instruction .

That's all, I will be glad to hear advice and constructive criticism.

Source text: Visual programming for Sonoff Basic