Tuya compatible smart-bulbs TASMOTA-ized

[Via Hackaday]  —  Don Howdeshell picked up a couple of “Merkury” branded smart bulbs in a Black Friday sale and, discoverering that they were Tuya compatible, has very kindly blogged not just his update experience and a tear-down, but also the TASMOTA template for the bulbs he found (just in case your’s are different, you can find more templates for Merkury smart bulbs in the template repository).

Although you might find availability and shipping a bit patchy at the moment because of the ongoing virus outbreak,  there are lots of smart bulbs on AliExpress and Banggood which are now showing “Tuya Compatible” flags, which should be a good indicator of ESP-based hardware.  We’re also starting to see some E14 base (candle/candelabra sized) smart bulbs appearing, too.

Don used Tuya-Convert to re-flash his bulbs and this is just a reminder that Tuya-Convert also ships complete with a recent version ( at the time of writing) of TASMOTA.


Recovering data from TASMOTA config back-up files

Okay, so you have a TASMOTA-enabled ESP8266 board in a place which is difficult to access and the latest upgrade doesn’t quite go as planned.  The upgrade itself appears to work, but the configuration back-up from the previous revision doesn’t take (your ESP is missing some peripheral devices).  Unfortunately, it’s also a custom build, not a shop bought device with a pre-rolled config already in the (vast) array of choices already shipped with TASMOTA.  What to do (other than retrieve the device and open it up)?  [“Document your projects better, you pillock!”]

Well, as I found out earlier, there is help at hand in the form of the command-line Python program by Norbert Richter:-  decode-config.py.

The good news is that it does (even more than) what you’d expect and can be used for recovering configs directly from a device, or converting between input and output formats.  The bad news is that it isn’t immediately obvious how to use it and it’s also very fussy about what version of Python you have (more especially right now, with the impending doom of v2.7 rushing towards us at the speed of a new year’s party-popper).

DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade….

…etc, etc. So, before you do anything else, grab the latest version of decode-config.py from it’s own repository, as that one is already Python3-ified. You’ll probably need to install dependencies, too (check the header comments).

Anyway, here’s a really, really short intro to using decode-config.py to recover data from older config files, so that you can plug that data straight back into your latest release.

decode-config.py --full-help

Will, as you expect, give a fairly verbose listing of the options.

decode-config.py -f /path/to/saved/configs/Config_Sonoff_6.3.0.dmp

Will give you an extremely verbose (and virtually indecipherable) JSON listing of the whole configuration (better than nothing, but not by much).

decode-config.py --indent-json 4 -f /path/to/saved/configs/Config_Sonoff_6.3.0.dmp

Will give you a reasonably formatted version of that same, JSON output (we’re getting there!).

decode-config.py --indent-json 4 -f /path/to/saved/configs/Config_Sonoff_6.3.0.dmp -g rules

Will give you a much shorter, much more useful, formatted JSON output of your saved rules (assuming you have any) preceded by a bunch of housekeeping information about the decode-config.py program itself and the system you’re running it on.

The sections which you can use with the “-g” flag are listed as:- “Control, Devices, Display, Domoticz, Internal, Knx, Light, Management, Mqtt, Power, Rf, Rules, Sensor, Serial, Setoption, Shutter, System, Timer, Wifi”, most of which are self-explanatory, but not all of which seem to work as you’d expect when trying to recover data from much older revisions of TASMOTA (as an example of this, the GPIO information which I was searching for was tagged onto the end of the “Mqtt” data). So, eventually I happened on this final invocation, which seemed to produce sane (and much more readable) output from the same back-up file.

decode-config.py -T command -f /path/to/saved/configs/Config_Sonoff_6.3.0.dmp

This (the winner!) provides output which you can scroll through directly, or as I did, save to a file for future reference. The data is grouped under the same headings as listed above in plain ASCII text. Everything appears to be grouped together logically (unlike the JSON output) and the only problem I found was an apparent off-by-one error in the numbering of the GPIOs (starting from GPIO1, rather than GPIO0) …which was fixed before I even finished this article (world record support times!).

So, that’s my brief introduction to decode-config.py, a bacon-saver if ever there was one.

Late News  —  Norbert (the author of decode-config) has just let me know that binary versions of the utility are also available for multiple operating systems, so there’s no longer any need to update Python.

PicoLibc adds hooks for ESP8266/ESP32 builds

Keith Packard has been putting in a lot of work over the past few months on PicoLibc, his lightweight libc replacement, which is specifically aimed at memory-limited embedded systems.  Keith has been steadily increasing the functionality of PicoLibc and has attracted some additional contributors along the way.  One of those contributors, Jonathan McDowell in Belfast, has just added the hooks for compiling xtensa-lx106-elf binaries.  Jonathan notes that it has been tested on an ESP8266 with the 2.2.1 + 3.0.1 Espressif NONOS SDKs + GCC 9.2.1 from Debian.

Over at CNX Software, Siji Sunny recently put together a (non-ESP specific) description of how to configure, compile and build code using PicoLibc under Linux, so it should now be possible (with Jonathan’s additions) to cross-compile for the ESP8266 using that handy guide.  In the meantime, Keith is continuing with additional work on integration of the ESP8266 and ESP32 targets.

Netatalk/AFPD/TimeMachine server set-up on FreeBSD-12.1

This entry is more of a memo to myself to remind me of  what the syntax is for the /usr/local/etc/afp.conf file for FreeBSD-12.1.

I’m consolidating a couple of my servers onto one physical machine (the Beelink AP35 which I mentioned a few months back)†, using FreeBSD as the OS.  Not surprisingly, the syntax for the afpd daemon‡ set-up is very different from the ARM-Linux box which is currently running that particular service (which provides a local TimeMachine server for all of the Mac users in the family).  This is the magic incantation which worked for me:-

login message = “AFP Service on \”herons\””
vol preset = TimeMachine
log level = default:debug
log file = /var/log/afp.log
uam list = uams_guest.so,uams_dhx.so,uams_dhx2.so
mac charset = MAC_JAPANESE
unix charset = UTF8
mimic model = Xserve
zeroconf = yes
zeroconf name = “Herons-Store”

[Herons TimeMachine]
path = /store/TimeMachine
cnid scheme = dbd
ea = ad
time machine = yes

The “log level” setting of “default:debug” is quite verbose, but really helps with debugging problems during set-up.  Once your configuration is up and running you can remove that line completely to go back to the default logging level of “default:note”.

The “Mimic model” setting tells the server which Apple device icon to display on the client machine.  Using “Xserve” shows a rack-mount server, but you can also try “TimeCapsule8,119” or “TimeCapsule6,116” to see two different versions of a TimeCapsule icon.

The “zeroconf” lines were essential (in my environment, anyway) to having the clients recognize the new server.

The “charset” lines are probably unnecessary (or at least will need local modification) for users outside of Japan.

†  The AP35 is classed as a “mini-pc” (basically a device aimed at the set-top box market, but with an Intel CPU, rather than ARM).  This model comes with a dual-core J3355 CPU and 4 x USB3 ports, making it quite a versatile little machine.

‡  Note that the current, “approved” method for implementing a non-Mac hosted TimeMachine is the Samba (SMB) suite.  However, the older netatalk method described above is still simpler and a lot lighter (in terms of the number of support packages pulled in when using “pkg install”) than Samba if you only want to implement a TimeMachine instance (as opposed to a general, network file server).

Modtronix ESP32 Ethernet Gateway

This was spotted by Jean-Luc, over at CNX Software.  It turns out that Modtronix are not only still around, but they’re getting into the ESP world now, too (and I count both of those as being good news …I still keep a functioning Modtronix SBC45ECR1 board in my spares box).

Modtronix are currently running a crowdfunding campaign for an Ethernet-enabled ESP32 gateway board over on Crowd Supply (which has already reached its target).  The board is interesting in that it not only has Ethernet, but also a micro-SD card slot for extra storage, an additional STM32F030F4 ARM Cortex-M0 processor which, by default, is configured as an i2c expansion, a type-C USB port for power and data and a barrel-jack as an alternate power input (up to 16v).

The STM32F030F4 is the baby in that processor range, with only 16k of flash and 4k of RAM, but still makes this an interesting combination.  Unfortunately, at the time of writing, the GitHub repository doesn’t have any code posted, so we’re going to have to wait and see just how many of the little ARM chip’s peripherals are available to the ESP32.

One tip for navigating the Modtronix GitHub is that the schematics for the main board are actually there, but just not in the “pcb” directory …they’re in the “images” directory (and also linked from the README.md in the “docs” directory).

Flashing the Sonoff TX/T0 US Version

The latest version of the Sonoff “smart” light-switch, the TX, is significantly different from the older ones. For a start, Itead have taken notice and created the front-panel for the US version in portrait, rather than landscape orientation. However, as one of the other changes was to remove all of the graphics (barring a small “Sonoff” label along the bottom), the orientation hardly matters now, anyway.  There’s also a black version available (and the Itead  site photo of the new, graphics-free front panel with blue, LED backlighting shows this version).Black version showing switch back-light

The new, plain white (or black)  front panel is fairly thick, with a single slot on the bottom edge for levering it open from the main body of the switch  —  which is required before you can fit it in the wall. The thickness of the front panel means that removing it from the body before it is fitted into the wall is a little difficult; while the front panel doesn’t flex, the thinner plastic of the body twists alarmingly. The best way to overcome this seems to be to lay the whole device on a flat surface, face down, then firmly press down with one thumb on the screw mounting hole (on the back-plate, just above the slot) before using a large, flat-bladed screwdriver to lever the back-plate away from the front panel. It does take quite a bit of force to open it.Press firmly & lever open

Removing the front panel allows you to screw the main body into the wall cavity, but also gives us access to the PCB so that we can flash TASMOTA onto the ESP8285 controller before fixing it into its permanent home.

The top PCB (with the switches and the ESP8285) needs to be disconnected from the main body of the device before programming and pulls off fairly easily (the design is asymmetric, so the PCB can only be inserted back into the body in one way).  The PCB layout also seems to have changed quite a bit since the previous version and there’s no “TP2/GPIO0” test point on the reverse side of this board.  Luckily, the other common connection point, the pad on R19, is still available, but in a different position on the PCB.Position of GPIO0 on R19

GPIO0 is on the end of R19 which is closest to the ESP8285 chip (the larger of the two chips, on the R/H side of the photo).

The contacts for a (3.3 volt) USB adapter are visible on the bottom, R/H side of the PCB photo (click to enlarge) and, as usual, GPIO0 needs to be briefly connected to ground when powering up the device to put it into programming mode.  I just used a flying lead clipped to ground at one end, touching the other end against the resistor pad while connecting the 3v3 supply.  Programming instructions for the “T1” version of the switch still work for this version.

Version 7 of TASMOTA is now available and the template for the T1/TX is also available from GitHub,  simply choose the correct template for your specific device and copy the string from the web page, then select Configure->Configure Other from the main menu on your newly installed device, paste the text into the Template input section, tick the Activate box and hit save.  Once the ESP has rebooted you will see the toggle boxes for each of the individual switches at the top of the main menu.

ESP12 — Bad batch out there

Just in case you haven’t seen it yet, GeekEnArgentina has reported on a bad batch of ESP12 boards which he received.  The symptoms were an endless boot loop when trying to program the device, with the problem being temporarily (and mysteriously) suppressed when a finger was touched to the upper, L/H corner of the ESP’s RF shield.

After two days of hectic troubleshooting (GeekEnArgentina was trying to ship out an order of 50 units to a customer), he eventually isolated the problem to a capacitor in the antenna circuit (which is assumed to be the wrong value, similar to the !470Ω LED resistor issue from a couple of years back).

His descriptions of the issue and the troubleshooting process are well worth a read.