Dee – single channel light switch – firmware

HARDWARE

Hardware and setup for flashing is described in the following article:

FIRMWARE FEATURES

  • Control over MQTT broker.
  • State-report contains additional information of switches state – server gets informed if switch is actually pressed by user or not.
  • On ESP a Light-Sleep mode is activated, which allows to reduce consumption from 0.8w to 0.5w, without any side-effects on switches reaction.
  • Might be configured with some settings. It’s possible to invert manual switches.
  • It’s possible to adjust configuration without necessaty to uninstall and reflash module.

WORKING MODES

  • Red LED is on – module is powered on and firmware successfully initialized.
  • Blue LED blinks – module in configuration mode. At this moment open WiFi hotspot “Dee-xxxxx” is enabled. Configuration page can be accessed at IP 192.168.4.1. Or, if network connection isn’t lost, it’s possible to access configuration page at local IP address.
  • Blue LED is on – module in fully operating mode.

OPERATION CONTROLS

  • Has two operating modes: each manual switch state change triggers relay state change; or manual switch turns on/off light only if it moved to appropriate position.
  • Enter configuration mode: quickly press some switch 5 or more times.

CONFIGURATION

  • SSID, password – WiFi network connection.
  • mqtt server, port, client name, user, password – connection to MQTT broker. Note: Client name must be unique! This name also used for Access Point name, and as a Hostname.
  • mqtt output topic – topic for output of relay 1 current state. Value is 0/1 for off/on states. Additionally contains a manual switch state by providing a dot in the end.
    Examples:
    ‘0.’ – relay is off, switch is pressed.
    ‘1’ – relay is on, switch released.
    ‘1.’ – relay is on, switch pressed.
  • mqtt commands topic – topic for relay commands input.
  • respect switch stateswhen disabled, each manual switch state change triggers relay state change. When enabled – pressing manual switch, turns on relay. If relay already was on, then does nothing.
  • invert switch keys – inverts manual switch logic (also makes effect on mqtt output of ‘.’ symbol).

CONTROL COMMANDS

  • 1 – turn on light (closes relay).
  • 0 – turn off light (opens relay).
  • set – enter configuration mode. Analogue pressing ‘Pairing button’ or quick switch on-off more than 5 times.

SOURCES

See GitHub: https://github.com/ai91/dee

Note that it uses development branch of WiFiManager. This branch can start wifi-manager in non-blocking mode. In this mode the module remains fully operable and can be controlled with manual switches (for example if network wasn’t configured properly). Master-branch still doesn’t support this mode.

MORE

There is also a configuration example of MajorDoMo server (unfortunately in Russian only):

Detritus – two-channel light switch – firmware

HARDWARE

Hardware and setup for flashing is described in the following article:

FIRMWARE FEATURES

  • Control over MQTT broker.
  • State-report contains additional information of switches state – server gets informed if any of switches is actually pressed by user or not.
  • On ESP a Light-Sleep mode is activated, which allows to reduce consumption from 0.8w to 0.5w, without any side-effects on switches reaction.
  • Might be configured with some settings. It’s possible to swap switches and relays.
  • It’s possible to adjust configuration without necessaty to uninstall and reflash module.

WORKING MODES

  • LED blinks – module is in configuration mode. At this moment open WiFi hotspot “Detritus-xxxxx” is enabled. Configuration page can be accessed at IP 192.168.4.1. Or, if network connection isn’t lost, it’s possible to access configuration page at local IP address.
  • LED is on – module is in fully operating mode.

OPERATION CONTROLS

  • Has two operating modes: each manual switch state change triggers relay state change; or manual switch turn on/off light only if it moved to appropriate position.
  • Enter configuration mode: quickly press some switch 5 or more times.

CONFIGURATION

  • SSID, password – WiFi network connection.
  • mqtt server, port, client name, user, password – connection to MQTT broker. Note: Client name must be unique! This name also used for Access Point name, and as a Hostname.
  • mqtt output topic 1 – topic for output of relay 1 current state. Value is 0/1 for off/on states. Additionally contains a manual switch state by providing a dot in the end.
    Examples:
    ‘0.’ – relay is off, appropriate switch is pressed.
    ‘1’ – relay is on, appropriate switch released.
    ‘1.’ – relay is on, appropriate switch pressed.
  • mqtt commands 1 topic – topic for relay L1 commands input.
  • mqtt output topic 2 – topic for output of relay L2 current state.
  • mqtt commands 2 topic – topic for relay L2 commands input.
  • swap relays – when checked, swaps manual switches for relays (S1 controls L2, S2 controls L1).
  • respect switch states – when disabled, each manual switch state change triggers relay state change. When enabled – pressing manual switch, turns on relay. If relay already was on, then does nothing.
  • invert switch keys – inverts manual switch logic (also makes effect on mqtt output of ‘.’ symbol).

CONTROL COMMANDS

  • 1 – turn on appropriate relay (closes).
  • 0 – turn off appropriate relay (opens).
  • set – enter configuration mode. Analogue pressing ‘Pairing button’ or quick switch on-off more than 5 times.

Sources

See GitHub: https://github.com/ai91/detritus

Note that it uses development branch of WiFiManager. This branch can start wifi-manager in non-blocking mode. In this mode the module remains fully operable and can be controlled with manual switches (for example if network wasn’t configured properly). Master-branch still doesn’t support this mode.

More

There is also a configuration example of MajorDoMo server (unfortunately in Russian only):

Dorfl – blinds control – firmware

Hardware

Hardware and setup for flashing is described in the following article:

Firmware features

  • Control over MQTT broker.
  • Approximately knows state/position of blinds. Fully opened blinds – is zero-position. Once close-switch is pressed for one second – it’s position 1. Every time switch button is pressed, the module calculates time of operation and updates position state (and pushes value to MQTT queue). Means server-side gets info about current position of blinds (fully opened, half-closed, or fully-closed), and can send more precise commands to control blinds. It’s posible to send a command for relative positioning (like “close down-relay for 3 seconds”), or for absolute positioning (“move blinds to the position of 6 seconds from fully-opened”. In this case module will automatically adjust position from current state, without necessity to fully open in advance – it simply makes minimum-required movement to get into desired state). Due to fact that position is calculated by module itself, rather than server, network communication is not a problem at all (unstable network, laggy MQTT broker, etc).
  • Also state-report contains additional information of switches state – server gets informed if any of switches is actually pressed by user or not.
  • On ESP a Light-Sleep mode is activated, which allows to reduce consumption from 0.8w to 0.5w, without any side-effects on switches reaction.
  • Might be configured with some settings. It’s possible to invert zero-position, swap switches and relays.
  • It’s possible to adjust configuration without necessaty to uninstall and reflash module.

Working modes

  • LED blinks – module is in configuration mode. At this moment open WiFi hotspot “Dorfl-xxxxx” is enabled. Configuration page can be accessed at IP 192.168.4.1. Or, if network connection isn’t lost, it’s possible to access configuration page at local IP address.
  • LED is on – module is in fully operating mode.

Operation controls

  • Lock remote control in fully opened/closed state: if keep manual switch pressed, the remote control is blocked.
  • Lock remote control at any position: turn switches off, then quickly press switch on, press off, then again press on and keep in this state (off->on-off-on). At this moment remote control gets blocked and relay remains in open state.
  • Enter configuration mode: quickly press some switch 5 or more times.
  • Even if some manual switch remains pressed forever, relay gets automatically opened after MaxPos seconds.

Configuration

  • SSID, password – WiFi network connection.
  • mqtt server, port, client name, user, password – connection to MQTT broker. Note: Client name must be unique! This name also used for Access Point name, and as a Hostname.
  • mqtt position output topic – topic for output of current curtain position. Value is always in range [0, MaxPos]. Value is an integer with amount of seconds from completely open blinds. Usually it’s written on relay open (after blinds movement is done), but when triggered with manual switch – also on trigger time. When triggered with manual switch, it also contains a dot in the end.
    Examples:
    ‘0’ – blinds fully open.
    ’30’ – blinds at position 30 (means was closing at least for 30 seconds. But can be more, if MaxPos = 30)
    ’30.’ – position 30 seconds and switch is pushed. (i.e. remote control is blocked).
  • mqtt commands topic – topic for commands input.
  • blinds max pos – maximum blinds position (MaxPos).
  • invert zero-position – inverts relays for open/close direction. By default L1 is for opening, L2 for closing.
  • invert switch keys – inverts manual switch logic. By default S1 is for opening, S2 for closing.
  • disable manual lock – when set, the “Lock at specific position” is disabled. Experimental, to get rid of potential problems when it interferes with normal work.

Control commands

  • mvr<XXX> – move to relative position XXX. XXX can be negative. If XXX negative – it moves curtain UP (closes L1 relay). If positive – DOWN (L2 relay). Absulute value of XXX – is amount of seconds to keep closed relay.
    Examples:
    mvr5 – close relay L2 for 5 seconds (closing curtains)
    mvr-60 – close relay L1 for 60 seconds (opening curtains)
    mvr0 – open both relays. I.e. stop curtains.
    Note: module takes care of conflicts and guaratees only one relay can be closed at a time. I.e. sequental mvr5 mvr-5 won’t burn engine, rather terminates/cancels first command.
  • mva<XXX> – move to absolute position XXX. XXX can be negative or any big number. If XXX is out of range of curtains [0, MaxPos], then after XXX seconds it will be set to 0 or MaxPos.
    Examples:
    mva0 – fully open curtains.
    mva5 – move curtains from current position to position 5 seconds from fully-open position. If current position is 3, then it will keep L2 closed for 2 seconds. If current position is 9, then will keep L1 closed for 4 seconds.
    mva60 – fully close curtains. Will be keeping L2 closed for 60 seconds, then position value will be set to MaxPos.
    mva-60 – fully open curtains. Will be keeping L1 for 60 seconds, then position value will be set to 0.
  • set – enter configuration mode. Analogue pressing ‘Pairing button’ or quick switch on-off more than 5 times.

Sources

See GitHub: https://github.com/ai91/dorfl/

Note that it uses development branch of WiFiManager. This branch can start wifi-manager in non-blocking mode. In this mode the module remains fully operable and can be controlled with manual switches (for example if network wasn’t configured properly). Master-branch still doesn’t support this mode.

More

There is also a configuration example of MajorDoMo server (unfortunately in Russian only):

Dee – single-channel relay module hardware

Module is based on WiFi Light Switch module from LoraTap.

Module’s main controller is a TYWE3S, based on ESP8266.

Original firmware works through tuya could, just like a two-channel module. And exactely same reasons to flash own firmware.

To flash firmware we need an RS232 interface with 3.3v. I was using FTDI.

We need 5 connection points.

TYWE3SFTDI
VCCVCC
GNDGND
RXTX
TXRX
IO0GND

Connection is pretty simple. Don’t forget to set 3.3v on FTDI! It’s necessary to pull IO0 to GND to boot in flash-mode.

Following GPIO’s are used in the module:

GPIO ModeDescription
0outRed LED (1 – on, 0 – off)
4inSwitch (1 – released, 0 – pressed)
12inPairing button (1 – released, 0 – pressed)
13outRelay (0 – open, 1 – close)
16outBlue LED (1 – off, 0 – on)

Unfortunately, it’s hardly possible to solder connection-wires without unsoldering TYWE3s module or relay. Therefore I had to design and print a jig. 3D model can be downloaded from Thingiverse.

Set following parameters in the Arduino Studio:
Generic ESP8266 Module, CPU 80MHz, Crystal 26MHz, Flash Size 1MB

Gonna flash Dee firmware:

Dorfl/Detritus – two-channel relay module hardware

Module is based on WiFi Curtain Blind Switch module from LoraTap.

Module’s main controller is a TYWE2S, based on ESP8285.

The great thing about this module, is a full and independent access to relays and GPIO’s. Means with custom firmware it’s possible to turn it into two-channel light switch. Though it’s also possible to make a mistake in relays-control logic – it’s possible to close both relays and burn blinds engine. Therefore we gonna be carefull 🙂

There are two versions of the module in the official store: V1 and V2. I’ve ordered and inspected both of them. I can tell that quality of V2 is higher – soldering is cleaner, cuts are more precise. Though schematics and components are exactely same in both versions. The main difference is in the firmware. V2 supports switch-buttons, while V1 work properly with toggle buttons. But I don’t think it makes a big deal here, as we are going to flash own firmware anyways. In my opinion it doesn’t really makes sense to pay extra for ‘perfect cuts’.

Original firmware isn’t interesting for us. It operates through tuya-cloud. First of all it’s requires permanent internet-connection. Then it might get communication delays. Also it’s not so easy to get control from own software (though community are reverse engeneering). Last but not least, I don’t entrust external access to my private zone. Therefore gonna nail it. 🙂

To flash firmware we need an RS232 interface with 3.3v. I was using FTDI.

We need 5 connection points.

TYWE2SFTDI
VCCVCC
GNDGND
RXTX
TXRX
IO0GND

Connection is pretty simple. Don’t forget to set 3.3v on FTDI! It’s necessary to pull IO0 to GND to boot in flash-mode.

Following GPIO’s are used in the module:

GPIOModeDescription
3outLED (1 – off, 0 – on)
4inswitch S1 (1 – released, 0 – pressed)
5inswitch S2 (1 – released, 0 – pressed)
12outrelay L1 (0 – open, 1 – close)
13inpairing button (1 – released, 0 – pressed)
14outrelay L2 (0 – open, 1 – close)

It’s easy to solder connection wires. During development and testing I was using following setup (be carefull with 220v connection! don’t forget to disconnect FTDI from computer. It’s disconnected on the picture)

Set following parameters in the Arduino Studio:
Generic ESP8285 Module, CPU 80MHz, Crystal 26MHz, Flash Size 1MB

Gonna flash two options:

Bluedio T4 Flashing


Warning! Actions described below can brick your headset! I’m sharing my experience only, and don’t recommend to repeat that. Any damage caused to your data or property is on your own risk.
If warning doesn’t stop you, and you still want to repeat my experience, I’d recommend to treat as you already have bricked headset. You have no headphones anymore. You are lucky if they are recovered. And you are very lucky if audio-lag issue is resolved in the end. But only if you are lucky. You have no headset. Accept that 🙂

Problem description. Early revisions of Bluedio T4 headset (produced till mid of June 2017) have audio desynchronization issue when connected over Bluetooth. There is an audio lag up to one second. It’s not possible to configure player with artificial audio delay, as the audio lag is not stable – it floats from 0 to 1000ms. If I got it right, the delay depends on audio stream parameters. It always starts synchronously, but lag is accumulating over the time. As a side-effect, you may notice while listening music – once one sets on pause, the sound keeps going in headphones for another second. The problem existed when connected to all my devices.
(I had one exception with one computer of mine – probably caused by usage of some specific Bluetooth profile, or driver: there takes place some correction of synchronization. It happens once a second. During this correction the sound is interrupted and video is skipped for some frames. As result it was painful to watch videos on this computer at all.)
There is no issue when connected over cable. But that’s understandable – when connected like that, sound goes directly to phones, skipping processor (neither volume is controllable, nor ANC works).

If you can’t deal with watching videos via cable connection, and have no fear to brick your headset (see warning above), and you have a soldering iron with thin tip, and some experience – you might consider to fix the issue.
The issue doesn’t disappear completely! But the lag gets reduced to acceptable level. As an example, here are two video samples captured before and after flashing.
1. Before flashing

2. After flashing

(Unfortunately the computer with sound-hicks keeps hicking. But interval between hicks significantly increased – now it get’s interrupted once in 15 seconds (sometimes longer), and interruptes are not so noticeable as before (though on some videos there are no issues at all).
Anyway, be aware – the issue isn’t gone completely, but became at least acceptable.
Upd. After I’ve changed bluetooth drivers on hicking PC – the problem has gone completely.

In the beginning I need to clarify – the production line flashing tool was used. From the Chinese production line. With Chinese user interface. It’s hard to understand which setting is for. More over – I wasn’t able to get confirmation of successful flashing, as all operations were either failing on test cycle, or falling into endless loop on verification step. But in the end my MAC address has been updated, and lag disappear. Therefore I tend to believe the flashing was successful 🙂
To understand how the flashing tool works I had to use serial port monitor, plus arduino-compatible SoC for headset emulation (I was using NodeMCU ESP 12E).
The UI of the tool has been partially translated – with only purpose is to ease references to UI elements in this instruction.

Bill of materials:
1. Soldering iron with thin tip
2. Any module for 232 serial port emulation over USB (or any other possibility to connect to headset’s board via COM-port). I was using PL2303, FTDI, and CH341A. The last one was used on final flashing procedure. The main requirement – the COM port should support connection on 921600 baud.
3. Windows PC (real, or emulated – doesn’t matter. But should get access to the COM port)
4. Screwdrivers, wires, etc. If you have first two items from the list, I’m pretty sure you have the rest 🙂

Here we go.
-1. Write down old MAC address. The only purpose – is to verify result. It’s also possible to flash original address, but I don’t really see any reason to do so. I was using this app.
0. Full charge battery.
1. Disassemble right earphone. I’d recommend to use a rubber sucker to not scratch plastic surface. The cap is held by three clips. That’s probably most critical HW part – I was disassembling headphones three times, and every time was not sure if I can break some clip. The most interesting stuff (PCB, battery) are in the right phone.
If you are curious, here is the left one – just to prevent you from unreasonable risk.
There are some service-points on the down side of board. Apparently they are used on service line – there are signs of connections.
Probably it’s necessary to use all of them for full production line support. But for us it’s enough to use only three of them.
2. Solder connectors to points marked with SCL, DAT, GND
3. Connect to the 232 interface like follows:
RX → DAT
TX → SCL
GND → GND

(I believe it’s clear that you may use no dupont-connectors like I did, by simply soldering wires directly, or don’t solder at all. But… you know… )
4. Plug USB module into PC, install drivers, start the flashing tool.
5. First execution is probably may be omitted, but helps to understand if everything works as expected:
5.1. Select COM port, disable others. (Port settings → Scan Ports → COMx → OK)
5.2. Open settings. (Firmware Configuration → usr/pwd: lyfoes.com/lyfoes.com)
5.3. If required, fix the path to the firmware image, and correct other settings based on following picture.
The BT Address NAP/UAP/LAP parameters are responsible for the new MAC address. When it’s really required, you may enter the original address and try to find out which pattern generator is to be used to avoid ‘correction’ of the entered values 🙂 I entered original one and used the pattern like on screenshot, but in the end it was automatically modified in the third byte.
5.4. Save settings, and press the ‘Start’ button on the main screen (blue circle with triangle). The tool opens then the COM port in 921600 8N1 mode and waits for handshake initiated by headset (it doesn’t write anything to the port unless receives first packet starting with 0xBE500003).
5.5. Press the power button on headset. If everything is connected right, drivers are in order, the correct port is selected – the progress should start. The headset blinks with red-blue LEDs. The first cycle (obviously emulation) runs for dozen seconds, then second cycle starts, goes until 20% and fails with error message. The headset remains with red LED on. Wait until red LED turned off and headset is ready for another connection attempt (around couple minutes).
6. The flashing.
6.1. Open settings and uncheck checkboxes “calibration” and “Factory pattern”.
6.2. Repeat previous step: start flashing, press power button. First cycle goes around 13 seconds. On second something weird has happened on mine – the tool changed status to “verification” and didn’t update any progress anymore. The headset also didn’t demonstrate any activity. But there was some data transmission visible in the serial monitor (though transferring data didn’t look like a part of firmware – there rather were some repeatable patterns). To be sure, I did wait for over than half of an hour. Afterwards I simply disconnected headset. And it was a panic moment – it didn’t react anymore, like it was bricked. After some experiments, it awake when I connected a charger on its USB port. Once checked, found updated MAC address, and no audio lag anymore.
I do suspect that after first cycle has ended, the headset enabled some keep-alive mode, and was waiting for some command by power button, or some other condition had to fulfill. Unfortunately I didn’t came to idea to check all possible variants – it was a deep night, I was falling asleep 🙂
Short video with demonstration of procedure:

But my initial idea was to replace the ‘blackbox’-tool with own flasher (taking into account I have the whole communication protocol). But lack of free time drives all the investigations to never-ending project. Did repair own headset – is enough to stop. Just sharing what I have at the moment. Nerveless there is a place for further investigations, if somebody would like to…

TODO, when get bored, get some free time, and wish:
– get some final firmware with all bugfixes, when it’s released (need to get in touch with Bluedio’s engineers, steal, beg, or give myself away in the end 🙂 again :-).
As an option – find out how to download a firmware from headset, get some final revision of headset (when it’s on market). (there is released some T4S model — check if there any hardware improvements, or software only)
– I don’t really like default sounds (“power off”, “device connected”, etc). Would like to replace them with short beeps.
– The ultimate plan — get the firmware sources. And then aptX and who knows what else… 🙂
– Or forget about, and use what I have now, while it works. In the end to buy something else 🙂
If somebody would move further in investigations – please share the info (here, or via email: anar@ibn.by).

Oh, yes. Almost forgot. Link to the flashing-tool archive.
password: lyfoes.com