Xiaomi-Philips bulb support

[biotecov]

Hello, I wonder if tasmota could incorporate support to the Xiaomi-Philips bulb. It should be easy with the info I include below (I have a modified tasmota running on it now).

The Xiaomi-Philips bulb is a dimmable LED bulb with E27 socket, resulting from a joint venture between Philips and Xiaomi. The bulb connects to your router by wifi to control intensity and color temperature using the Xiaomi app, of course, via the Xiaomi cloud, but only through the China servers so far, so I wondered if it would be using esp8266 and if ti could be hacked ... My guess was correct, and here we are.

I managed to open the bulb by inserting a knife between the sphere and the body (be careful not to dammage something inside or even worse, to hurt yourself, because both pieces are firmly glued together). Inside is an ESP8266 controlling 6 cold white leds and 6 warm white leds. Thankfully, below an insulator is a pad with connectors for GND, Tx, Rx, Vcc, GPIO15 and GPIO00 (in this order). I ignore the purpose of the GPIO15, but the remaining connectors do their usual role. I flashed the bulb with tasmota 6.0.0a, set it as Generic, and started to search how to control the lamp.

To make it short I discovered GPIO12 controls color temperature without modifying total intensity, and GPIO15 controls light intensity without changing color temperature. It is different from other lamps where one GPIO usually controls the cold leds, and another one the warm leds, so I had to modify the code to accomodate this lamp.

Attached is a patch to add a definition for this device in sonoff_template.h, and this specific control to xdrv_04_light.ino. I am happy with the result, and this post is just to make this available to others, and maybe the tasmota developer may find it is worthwhile to incorportate to the regular tasmota code. Sure, the changes may be implemented in a clever way (I am new with tasmota, neither I had any previous experience with Arduino), and some other changes are certainly missing, but the result is good enough for me as I can control the lamp from the web interface and also from mqtt.

Regards to the tasmota developper and to all tasmota fans and contributors.

philips-patch.txt

[reloxx13]

use generic module and set the gpios instead of changing the code uneccessery.

every esp8266 chip can be flashed with tasmota, no need for suche a big story line.

if you want to write a howto, visit the wiki.

[biotecov]

Hi reloxx13. I am sorry that you missed the part where I explain that this device uses a sheme that does not fit in the present generic Tasmota module without mods. It uses 2 PWM, yes, you can configure them, yes, but Tasmota does not handled them the way the device expects, and the result is unpractical.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AneDijkstra]

Hi biotecov

I just used your adaption and it works great. No problems what so ever. Thank you for your efford.

[ascillato]

Hi,

There is still interest on supporting this Bulb?

Anyone is working in a PR ?

[biotecov]

Hello, I continue using two units of this bulb at home with Tasmota modified as I described in the original post. It's running without troubles and I am aware of at least one more person that wrote me telling that he has applied with success the mods too. Supporting this bulb adds very little hassle to the code, so I cannot see any fundamental reason for not including support for it, but that's just my opinion. Tasmota is a great software and I'll be equally happy with it in any case.

On 09/13/2018 02:23 PM, Adrian Scillato wrote:

Hi,

There is still interest on supporting this Bulb?

Anyone is working in a PR ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3055#issuecomment-420987490, or mute the thread https://github.com/notifications/unsubscribe-auth/AlKJ8w7EsCFUzyKRRFu_VjQIoKfNZb6Gks5uak4ugaJpZM4U1MOG.

[ascillato]

Hi,

I don't understand why you didn't make a PR before with your changes. The modifications in your txt file are fine.

Making the PR #3787 for Theo to review it.

Thanks

[TimelessNL]

Did anyone try the e14 version of the Xiaomi Philips bulbs? Ebay link

I've ordered one to give it a try, but I fear that these bulbs cannot be opened without destroying them in the process.

[MortenVinding]

Did anyone try the e14 version of the Xiaomi Philips bulbs? Ebay link

I've ordered one to give it a try, but I fear that these bulbs cannot be opened without destroying them in the process.

I for one very much would like to know if they can be opened. If you succeed please post some pictures (maybe also if you don't 😁)

[TimelessNL]

I brought one specifically for teardown purposes :P. Unfortunately I've not received it yet. But I'll keep you updated ;)

[jmw6773]

Hello @biotecov. Thank you for adding this patch to Tasmota. It is much easier than trying to get the Xiaomi Philips token and I'd much rather use Tasmota than Xiaomi's propitiatory system. I've found that when setting the color temperature the value returned in that stats MQTT topic is the inverse of what was sent to the cmnd topic.

Is the formula in file xdrv_04_light.ino, line 465 correct? The formula "347-((my_ct * 136) / 100) + 153" turns the value I'm expecting.

i.e. When sending a value of 153 to the topic 'cmnd/philipsbulb/CT' the value returned to 'stat/philipsbulb/RESULT' is {"POWER":"ON","Dimmer":48,"Color":"122,255","HSBColor":"0,0,48","Channel":[48,100],"CT":500}

Am I doing something wrong?

[biotecov]

Hello Jonathan, to my understanding, it looks like you are right.

I am successfully controlling my two Xiaomi Philips lamps from the phone using the IoT MQTT Panel app, and this is working well for me because I do not care about the returned mqtt value in this case. In fact, until you told me, I did not even noticed that the returned CT value was wrong. I have just tried with my installation, and I confirm your observation.

With respect to the formula you mention in xdrv_04_light.ino, it is not part of my patch, it was already there before my patch, and I ignore the potential side-effects than changing it could have on other types of lamps (is the reported CT value wrong for other lamps too?).

I am not an expert on this kind of devices, so I just devised my patch to be able to control the lamp with minimal changes or additions, and I did not looked about returned values. If you have the time to devise how to fix this without disturbing the control of other lamps, I encourage you to contribute the relevant mods. I am sure that other users would benefit.

Best regards,

Ricardo.

On 12/12/18 4:12 PM, Jonathan wrote:

Hello @biotecov https://github.com/biotecov. Thank you for adding this patch to Tasmota. It is much easier than trying to get the Xiaomi Philips token and I'd much rather use Tasmota than Xiaomi's propitiatory system. I've found that when setting the color temperature the value returned in that stats MQTT topic is the inverse of what was sent to the cmnd topic.

Is the formula in file xdrv_04_light.ino, line 465 correct https://github.com/arendst/Sonoff-Tasmota/blob/development/sonoff/xdrv_04_light.ino#L465? The formula "347-((my_ct * 136) / 100) + 153" turns the value I'm expecting.

i.e. When sending a value of 153 to the topic 'cmnd/philipsbulb/CT' the value returned to 'stat/philipsbulb/RESULT' is {"POWER":"ON","Dimmer":48,"Color":"122,255","HSBColor":"0,0,48","Channel":[48,100],"CT":500}

Am I doing something wrong?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3055#issuecomment-446621841, or mute the thread https://github.com/notifications/unsubscribe-auth/AlKJ85zn7j9T808BKLwpp2PQjmUMLukOks5u4RzQgaJpZM4U1MOG.

[jmw6773]

Sorry, I didn't mean to imply that it was your patch at fault. I haven't had any issues with the changes you added for the Xiaomi Philips support. I'm using node-red to send the MQTT signals and only noticed the issue when I added it to my Home Assistant system. Not being able to leave well-enough alone, I had to look into it more.

It looks like the issue is that the formula used in xdrv_04_light.ino is wanting to calculate the CT using the iwarm value from the LightSetColorTemp function and not that icold value that the Philips bulb uses. The easiest fix is to add an if/else to check the module used and use the correct formula, like you did in your patch in the LightSetColorTemp function.

[biotecov]

Jonathan, I think you are right.

On 12/14/18 4:51 AM, Jonathan wrote:

Sorry, I didn't mean to imply that it was your patch at fault. I haven't had any issues with the changes you added for the Xiaomi Philips support. I'm using node-red to send the MQTT signals and only noticed the issue when I added it to my Home Assistant system. Not being able to leave well-enough alone, I had to look into it more.

It looks like the issue is that the formula used in xdrv_04_light.ino is wanting to calculate the CT using the iwarm value from the LightSetColorTemp function and not that icold value that the Philips bulb uses. The easiest fix is to add an if/else to check the module used and use the correct formula, like you did in your patch in the LightSetColorTemp function.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3055#issuecomment-447204774, or mute the thread https://github.com/notifications/unsubscribe-auth/AlKJ8xrr0rW5zzcpER32XBCT9R0_jkBUks5u4yBfgaJpZM4U1MOG.

[TimelessNL]

Ok... I've received both Xiaomi-Philips E27 & E14 bulbs and took some pictures.

Lets start with the E27 Bulb [skill level: MODERATE] After removing the dome with a knife like @biotecov did, I quickly noticed that the pads are not easily accessible So I removed the LEDs with some heat and patience :) (powerful iron recommended) to give myself some room to work with. After that I quickly soldered the required wiring and programmed the ESP (bad soldering but since these wires are only temporary I didn't mind), And the programming went uneventful. I also removed the heatshrink afterwards, since it was not in the best shape anyway. Which revealed the solder pads entirely in the process. After reapplying some new heatshrink it looked brand new 👍 apart from some dried flux. So thanks for supporting this bulb in Tasmota, It's working great!

Lets finish with the E14 Bulb [skill level: HARD] Ok... this bulb needed some more (forced) love to split appart. I started with a knive and ended with a screwdriver after which it finely split apart. to reveal our beloved ESP (esp-wroom-02). With this bulb it's really necessary to remove the LED plate, so that's what I did. This revealed the RX/TX/VCC/GND pads on the pcb. So again I (badly) soldered the wires temporally onto the PCB. Unfortunately GPIO0 is covered by the big white glue blob so I had to find another solution. I found the pinout and manually held a GND wire at GPIO0 during powerup. Which got my ESP in UART download mode. So after flashing I soldered everything back together and tried it out. This bulb works (kinda) fine, the CW/WW slider controls the cold white LEDs and the brightness slider controls the warm white LEDs.

So final conclusion: The E27 bulb is great. Easy to flash and outputs allot of light. Only one thing I noticed. The Cold/Warm slider is always set to Cold when opening the webpage. The E14 bulb is fine. Hard to flash and will probably have some damage afterwards. It does however put out some nice light (be it 2x LEDs less than the E27)

[ascillato]

@TimelessNL

Hey, very nice explanations and photos. Can you add that to the wiki please? Thanks :+1:

[TimelessNL]

Sure, never edited a github wiki before. So I'll see what I can do.

I was also thinking that it would be nice to support a Xiaomi-Philips OTA way of flashing. Since my described way works, but is quite destructive for the little E14 bulb.

[MortenVinding]

Hi! I would like to flash Tasmota to the E14 bulb, but I don't want to open it, because if i open it thats equals a destroyed led bulb. I think, that the OTA way is possible, but I can't get it working. We can publish OTA packages via the python-miio library. Do you know how to do that?

wow that sound really interesting. I'm still waiting for my first Xiaomi Philips bulb (first order never arrived 😡), but I'm sure that would make these bulb's much more interesting! Where do you read that the python-milo library supports OTA?

[TimelessNL]

Where do you read that the python-milo library supports OTA?

There seems to be code in place to support a kind of OTA update: see code snippet. But since there is a large possibility that this Xiaomi firmware uses a different partition layout I'm unsure if this may even work.

There is however another party that concentrate them self's on hacking Xiaomi devices. They also dumped the original firmware . When I have time I could write this firmware to a Nodemcu to see how this OTA firmware update mechanism works.

[TimelessNL]

Unfortunately this firmware seems to be incomplete. Searching for strings in the firmware indicates that Xiaomi uses the ESP RTOS SDK. OS SDK ver: 1.5.0-dev(7f7a714) compiled @ May 15 2017 17:20:32 So I packed the Xiaomi firmware file with RTOS_v1.5 (using this archive Xiaomi-Philips-E27.zip) and flashed it to my NodeMCU (4MB) as it being a ESP8266 with 1MB flash: esptool.py --port /dev/ttyUSB0 write_flash --erase-all --flash_size 1MB -fm dout 0x0 boot_v1.5.bin 0xFC000 esp_init_data_default_v08.bin 0x01000 xiaomi_philips.bin which seemed promising at start:

OS SDK ver: 1.5.0-dev(7f7a714) compiled @ May 15 2017 17:20:32
phy ver: 1055_1, pp ver: 10.7

rf cal sector: 251
tcpip_task_hdl : 3fff2080, prio:10,stack:512
idle_task_hdl : 3fff2140,prio:0, stack:384
tim_task_hdl : 3fff4980, prio:2,stack:512
reset reason: 4
08:00:00.002 [PT] Booting into normal mode...

08:00:00.002 [PT] DeviceId: ZigBee Node, Dimmable Light

pwm version:1.0.2
08:00:00.002 [PT] RESTORE EVENT

08:00:04.437 [PT] pSwitchOnRstCount: 3

08:00:04.438 [PT] power on: bri 254

08:00:04.438 [PT] power on: cct 5700

08:00:04.438 [PT] StartUp to light

data  : 0x3ffe8000 ~ 0x3ffe8abc, len: 2748
rodata: 0x3ffe8b90 ~ 0x3ffeae20, len: 8848
bss   : 0x3ffeae20 ~ 0x3fff1ea0, len: 28800
heap  : 0x3fff1ea0 ~ 0x40000000, len: 57696

_|      _|  _|_|_|  _|_|_|    _|_|  

_|_|  _|_|    _|      _|    _|    _|

_|  _|  _|    _|      _|    _|    _|

_|      _|    _|      _|    _|    _|

_|      _|  _|_|_|  _|_|_|    _|_|  

psm init success

error: OTP read error, -2

Unfortunately it freezes 5 times on the sentence for 4sec: 08:00:00.002 [PT] RESTORE EVENT after which it will enter a continuous (unfrozen) boot loop putting out the log above.

So that's where my investigation currently stops. Since I guess it is missing Xiaomi's specific userdata I have no way of restoring a NodeMCU as being a Xiaomi-Philips E27 bulb to test the OTA process. Also it is complaining about OTP (One-Time-Password?) which could be a security measure to validate the SPI chip, that's why I don't think my NodeMCU can simulate a Xiaomi bulb) So my questions is (since I was so eager to flash my bulb with Tasmota and did not create a backup in the process): Does someone have a full backup of the original Xiaomi-Philips firmware?

I do however doubt that OTA updating Xiaomi's firmware into Tasmota will ever work. Since Tasmota is not using RTOS and therefor the flash is formatted differently.

[MortenVinding]

Just received my Xiaomi-Phillips bulb today. Hoped TimeLessNL had the OTA flashing in place by now 😜

Have just opened it up, not to hard with a iSesamo tool, slowly pushing the dome until the glue let lose.

TimeLessNL: which is the best way to dump the flash? Suppose using ESPTool?

[TimelessNL]

Haha. Sorry mate, I was a little bit to eager to get my bulbs working last time :P

Yeah a esptool dump should be fine. Thanks!

I bought myself another e27 bulb so if the NodeMCU simulation does not work it has to wait untill I receive my 3th bulb.

[MortenVinding]

No worries I was being sarcastic, just so happy that someone is working to make OTA work. Even if we may never succeed.

I’m doing the download now but it failed at 460800 baud and at 9600 it gonna take some time.

Do you know if it is a 1MB flash chip?

[MortenVinding]

I was trying to get catch the boot up messages from original firmware, but did not seem to find the correct port settings.

Does anyone have them?

[TimelessNL]

460800 is quite high. Better stay on 115200 I guess.

I suspect it to be a 1MB Flash chip indeed. But esptool should be able to detect it any how. Also I flashed the 1MB tasmota myself and it worked fine, so unless it's bigger I think it should be 1MB.

The default baudrate of the Xiaomi firmware is the less common 76800, so if you're able to see the ESP's bootmessages you should also see the Xiaomi's firmware output.

[MortenVinding]

Yes that was just from the readme for ESPTool. Found out that 230400 is max working speed.

etecting chip type... ESP8266 Chip is ESP8266EX Features: WiFi MAC: 7c:49:eb:4f:87:0f

Chip ID: 0x574f870f

Flash: Manufacturer: c8 Device: 4015 Detected flash size: 2MB

So it looks like it a 2MB chip

[MortenVinding]

just dumped like: python ./esptool.py -p /dev/cu.usbserial-A9ALPNFR -b 230400 read_flash 0 0x200000 flash_contents2.bin

Do you think that is okay? I'm a bit eager to flash Tasmota so really wanna make sure the dump is okay now 😆 flash_contents2.bin.gz

[TimelessNL]

Ah wow... didn't expect that. I'm curious why they needed 2MB chip...

If esptool didn't report any errors this time I think the dump would be fine. I'll try out tomorrow. Thanks for your help!

Ps. For your own privacy remove the chipid/mac addresses from your message ;)

[MortenVinding]

And I finally did get the boot message:

bcn 0 del if1 usl sul 0 0 ⸮⸮⸮PV⸮⸮ET⸮⸮⸮⸮T⸮⸮+⸮⸮u⸮U+UZ⸮Z⸮T⸮⸮⸮TQT⸮QQ⸮⸮jP⸮T⸮⸮⸮⸮⸮⸮⸮ZT⸮(⸮⸮⸮jQ⸮%⸮(⸮⸮⸮⸮QB⸮⸮⸮UB⸮⸮Y⸮ZT⸮(UE⸮⸮⸮⸮QEu⸮⸮⸮⸮⸮eURB⸮⸮⸮Օ⸮k⸮⸮⸮ZT⸮(U⸮⸮⸮jQ⸮⸮E⸮jQ⸮⸮⸮T⸮T⸮u⸮⸮⸮Zյ⸮⸮jUJTE⸮⸮jU⸮⸮⸮⸮U⸮UT⸮⸮⸮⸮UT⸮E⸮⸮⸮uT ⸮⸮⸮⸮⸮⸮U%⸮⸮⸮TT⸮U⸮⸮UU(Z⸮UR⸮⸮⸮⸮U⸮JT⸮⸮QTjP⸮P⸮Vխ⸮⸮⸮QEQ⸮OS SDK ver: 1.5.0-dev(7f7a714) compiled @ May 15 2017 17:20:32 phy ver: 1055_1, pp ver: 10.7

rf cal sector: 507 tcpip_task_hdl : 3fff2080, prio:10,stack:512 idle_task_hdl : 3fff2140,prio:0, stack:384 tim_task_hdl : 3fff4980, prio:2,stack:512 reset reason: 4 08:00:00.003 [PT] Booting into normal mode...

08:00:00.003 [PT] DeviceId: ZigBee Node, Dimmable Light

pwm version:1.0.2 08:00:00.003 [PT] RESTORE EVENT

08:00:04.438 [PT] pSwitchOnRstCount: 1

08:00:04.439 [PT] power on: bri 254

08:00:04.439 [PT] power on: cct 5700

08:00:04.439 [PT] StartUp to light

data : 0x3ffe8000 ~ 0x3ffe8abc, len: 2748 rodata: 0x3ffe8b90 ~ 0x3ffeae20, len: 8848 bss : 0x3ffeae20 ~ 0x3fff1ea0, len: 28800 heap : 0x3fff1ea0 ~ 0x40000000, len: 57696

| | ||| ||| ||

|| || | | | |

| | | | | | _|

| | | | | |

| | ||| ||| ||

psm init success

OTP read OK

JENKINS BUILD NUMBER: N/A

BUILD TIME: Aug 29 2017,16:09:45

MIIO APP VER: 1.3.0_0035

MIIO MCU VER: N/A

MIIO WIFI VER: 1.5.0-dev(7f7a714)

MIIO DID: 93284628

MIIO WIFI MAC: 7c49eb4f870f

free_heap[after init]: 12464

uap ssid is philips-light-bulb_miap870f

xiaomi init pass

mode : softAP(7e:49:eb:4f:87:0f) dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1) add if1 bcn 100

[MortenVinding]

it even has a interactive command prompt: Debug commandlist

[command] [ARG]

---

help
reboot
restore
setwifi ARG: <"ssid"> <"passwd"> RET: ok/ error getwifi ARG: none RET: <"ssid"> / error gettemp ARG: get temperature data stop_mcmd ARG: stop miio cmd RET: none model ARG: RET: getversion ARG: get firmware version getheap ARG: get heap: ok/error mac ARG: none RET: ok/error bri ARG: bright pwm test, 0-100 RET: ok/error cct ARG: cct pwm test, 0-100 RET: ok/error setcct ARG: cct control test, 0-100 RET: ok/error setbri ARG: bri control test, 0-100 RET: ok/error setbricct ARG: bri and cct control test, 0-100 RET: ok/error applyscene ARG: apply scene: ok/error

[TimelessNL]

Great. I'm curious what the OTP mechanism is. I suspect it to be something of One Time Password, but the esp8266 lacks the encryption feature the esp32 has... so I'm uncertain how Xiaomi implemented this OTP mechanism.

Would be fun to see if you flash your backup and use --erease-flash while doing so, see if the firmware still boots.

[TimelessNL]

Mmh... I just tested your dump on a NodeMCU and it gave me the same bootloop as before... :(

I will investigate what bootloader is used for the Xiaomi firmware in your dump, but until I got my 3th bulb, I cannot work on the OTA update just yet.

So stay tuned :)

[MortenVinding]

Took me some time to figure out that --erase-flash is only in esptool => 1.6 But I did flash Tasmota, which worked perfectly 😀

Then I went back and did a: python esptool.py --port /dev/cu.usbserial-A9ALPNFR -b 230400 erase_flash

and then wrote my dump back again: python esptool.py --port /dev/cu.usbserial-A9ALPNFR -b 230400 write_flash -fs 2MB -fm qio 0x0 flash_contents2.bin

...And the bulb booted right back in to the Xiaomi/Philips firmware

So maybe it checks against MAC address or something? Or the boot loader is different as you mentioned.

[MortenVinding]

Just tried to flash my dump to a WeMo D1 mini. I got the same boot loop as you mentioned: error: OTP read error, -2

[TimelessNL]

Ah good to know that your dump works as a restore on your Xiaomi bulb! I bought myself some ESP-WROOM-02 modules, to see if these might work. Since you're also getting the OTP read error on another ESP module. So it has to be something in the WROOM module or another hardware identification method.

Something else: In my previous how-to for the E27 and E14 bulb I forgot to mention that I also tested the Xiaomi-Philips Downlight which worked perfectly with Tasmota. I had some troubles flashing it though. I had to use GPIO0 from the main PCB(power supply), otherwise I was not able to get it into UART download mode.

Got some pictures from that other github repo where you can see the Xiaomi-Philips Downlight teardown: And I soldered the GPIO0 on the main-pcb (power supply) board (see IO0 marking at the interconnect): The ESP-WROOM-02 module also had a GPIO0 spot but this one didn't work for me:

[MortenVinding]

Interesting didn't think about the WROOM difference.

Maybe I should try to flash the Xiaomi dump you found to my bulb? Would be interesting to see if it's a hardware difference or if it looks for some specific serial number (maybe OTP = One Time Programable... part of the flash?)

But what is the advantage of getting the Xiaomi firmware on to a new module? Can you do more on that than on the bulb directly?

[TimelessNL]

Yeah that would be interesting! my compiled firmware file can be found some posts ago. The command you'll need is also mentioned.

The advantage is that it is much easier to work on. No manual GPIO0 switching and such. Also powering the Xiaomi bulb mid circuit (applying 3v3 on the WROOM module directly) is not very good for the 230v PSU in the bulb. It may work fine for a while but in the end is not supposed to and could lead to strange errors.

[MortenVinding]

So I cleared the flash with erase_flash and then proceed to flash using your command (removing the --erase-all since my esptools doesn't support that). Even keept the --flash_size 1MB option...

And the Xiaomi firmware booted right up and started to brodcast the BSSID.

So it seems there is nothing that ties the firmware to the hardware like serial number, MAC or the like.

It's gonna be interesting to see if you can install it on the WROOM device.

[dmsergeevich63]

I flashed my esp8266EX ESP-12E, but I didn’t see the bssid and couldn’t find a lamp in mihome. A reset using 5 distortions did not help. I get the error error: OTP read error, -2 What did you change to overcome this error?

[TimelessNL]

@MortenVinding ah good to know, so maybe it has something to do with the "One Time Programmable" feature. I hope that my "test" Xiaomi bulb will arrive anytime soon, so I can continue my research :). I'm also gonna try if I can alter the dump in order to skip the OTP check.

@dmsergeevich63 I think you've misread or posts. We're having the same OTP error. Only the original Xiaomi bulbs seem to support the firmware for now.

[razvanu]

Hello i've just 'fried' a rs232.to.ttl convertor, how cand i find out wich pins have to solder? rx,tx,gnd and vcc ? and for dw mode have to short gpio0 with gnd ? i guess with NO AC connected :D and where to get original firmware? mine was crashed after update from 1.2.7_0028 to 1.3.0_0035​

[LurchiStromberg]

Hi Folks, sorry for asking here, but i didnt found a proper Thread and dont want to start a new one.

Is the Yeelight YLXD10YL Smart Square LED Ceiling Light working with Tasmota too ?

Its this Lamp:

https://www.gearbest.com/flush-ceiling-lights/pp_009125052030.html?wid=1433363

[the4anoni]

Any progress on flashing Tasmota on philips zhirui e14 frosted via OTA ? I want to flash tasmota, but I don't have any soldering skills :(

[exetico]

@TimelessNL - Did you manage to fix it? Maybe even OTA with Tasmota :-) (For the E14)

[akikanellis]

@TimelessNL I was wondering how you managed to remove the aluminium plate underneath the LED plate? I have been pulling for a good 20 minutes now and can't get it off.

[exetico]

@AkiKanellis Did you manage to get it free? I would like to do the same, if i can't do anything "remotly".

[akikanellis]

@AkiKanellis Did you manage to get it free? I would like to do the same, if i can't do anything "remotly".

I did, but not in a way I would recommend. The plate was attached very strongly to the point that I was bending it the more I was pulling. I suspected glue was at play so I used my heat gun multiple times, that did not work.

At some point, I had it so damaged by pulling that I decided to just go all the way and destroy the rest of it so that I can open it up.

I bent one edge of the plate in order to free it and then pulled it, since I had pretty much destroyed the bulb at that point, I also removed the board from inside.

On the rim of the plate, I can see some kind of adhesive, instant-glue like - something that did not seem intended to be removed so it makes sense that I couldn't do it.

All in all, I would definitely not recommend doing this because it destroys the bulb. I am planning on buying different E14 bulbs to these given how much of a pain this was.

[TimelessNL]

@offtopic Sorry for my late response, my priorities have shifted for quite a while that's why my public activity is reduced.

But I've used a vice with a towel to remove the metal plate: If you place the bulb in a towel and then slowly apply pressure using the vice (with a little luck) it will 'pop' and the metal bracket is then removable. Just make sure you place the PCB parallel with the vice 'mouth' so it will not be crushed. The damages on the top as seen in my pictures are not from this method but are because I used some pry-tools to get the plastic cap removed.

[AneDijkstra]

[cid:image001.jpg@01D609C4.DB105910] Hallo

I did not have to remove the aluminium plate or the led plate because the pcb with the programming points are in reach from above. I only had to remove a pice of heatshrink from the pcb. Your device looks different from mine. Maybe a different version.

Greetings GAD

Van: Aki Kanellismailto:notifications@github.com Verzonden: vrijdag 3 april 2020 13:40 Aan: arendst/Tasmotamailto:Tasmota@noreply.github.com CC: GADmailto:anedijkstra@live.nl; Commentmailto:comment@noreply.github.com Onderwerp: Re: [arendst/Tasmota] Xiaomi-Philips bulb support (#3055)

@AkiKanellishttps://github.com/AkiKanellis Did you manage to get it free? I would like to do the same, if i can't do anything "remotly".

I did, but not in a way I would recommend. The plate was attached very strongly to the point that I was bending it the more I was pulling. I suspected glue was at play so I used my heat gun multiple times, that did not work.

At some point, I had it so damaged by pulling that I decided to just go all the way and destroy the rest of it so that I can open it up.

I bent one edge of the plate in order to free it and then pulled it, since I had pretty much destroyed the bulb at that point, I also removed the board from inside.

On the rim of the plate, I can see some kind of adhesive, instant-glue like - something that did not seem intended to be removed so it makes sense that I couldn't do it.

All in all, I would definitely not recommend doing this because it destroys the bulb. I am planning on buying different E14 bulbs to these given how much of a pain this was.

[IMG_20200403_123236]https://user-images.githubusercontent.com/6104879/78356764-14ac1980-75a8-11ea-9e80-30be60398c50.jpg

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/arendst/Tasmota/issues/3055#issuecomment-608386662, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGVYMQMEL34PV36VG7UIZ33RKXDKFANCNFSM4FGUYODA.

[exetico]

@AkiKanellis Thanks for the reply. Maybe i should try and sell it, or give it away, and pick up some of the cheap ones, from the local store. There's plenty of devices, which are ready for Tasmota OTA-flashing.

@AneDijkstra - Maybe i should try and see how my device looks, and give it a try :-D