Xiaomi-Philips bulb support #3055
Comments
|
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. |
|
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. |
|
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. |
stale
bot
added
the
stale
|
Hi biotecov I just used your adaption and it works great. No problems what so ever. Thank you for your efford. |
stale
bot
removed
the
stale
|
Hi, There is still interest on supporting this Bulb? Anyone is working in a PR ? |
|
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
<#3055 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AlKJ8w7EsCFUzyKRRFu_VjQIoKfNZb6Gks5uak4ugaJpZM4U1MOG>.
|
|
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 |
|
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. |
|
I brought one specifically for teardown purposes :P. Unfortunately I've not received it yet. But I'll keep you updated ;) |
|
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. Is the formula in file xdrv_04_light.ino, line 465 correct? 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? |
|
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
<#3055 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AlKJ85zn7j9T808BKLwpp2PQjmUMLukOks5u4RzQgaJpZM4U1MOG>.
|
|
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. |
|
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
<#3055 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AlKJ8xrr0rW5zzcpER32XBCT9R0_jkBUks5u4yBfgaJpZM4U1MOG>.
|
|
Ok... I've received both Xiaomi-Philips E27 & E14 bulbs and took some pictures. Lets start with the E27 Bulb Lets finish with the E14 Bulb So final conclusion: |
|
Hey, very nice explanations and photos. Can you add that to the wiki please? Thanks 👍 |
|
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. |
wow that sound really interesting. |
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. |
|
Unfortunately this firmware seems to be incomplete. Unfortunately it freezes 5 times on the sentence for 4sec: 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. 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. |
|
Just received my Xiaomi-Phillips bulb today. 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? |
|
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. |
|
If connected correctly, the webui should be able to control whites and colors.
https://tasmota.github.io/docs/Lights/#4-channels-rgbw-lights
… On 12/06/2021 10:00 AM Sander van Rossem ***@***.***> wrote:
I've tested the PWM pins on the ESP32 board.
GPIO2 - WW - PWM
GPIO4 - CW - PWM
GPIO19 - B - PWM
GPIO21 - R - PWM
GPIO22 - G - PWM
ESP Chip Id: 7762116 (ESP32-U4WDH)
Flash Size: 4096 kB
Program Size: 1303 kB
Free Program Space: 1856 kB
Free Memory: 176.6 kB (frag. 64%)
I used SetOption92 1 to get cold and warm white working. RGB isn't working properly, only blue works, anyidea? I'm not familiar with Tasmota.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3055 (comment) , or unsubscribe https://github.com/notifications/unsubscribe-auth/AICIRZUASNANQNJ25VUNLJDUPTMYBANCNFSM4FGUYODA .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
|
|
Hi everyone! Found this thread while flashing esphome onto my e14 philips bulbs. (Yeah, I know it's a little offtopic and we discuss tasmota here) It looks like those bulbs also have a thermistor wired to ESP8266 ADC pin. So far I've guesstimated it to be a 100k thermistor, downstream with a 500k resistor. E.g. the esphome config looks like this: sensor:
- platform: ntc
id: the_ntc
sensor: resistance_sensor
calibration:
b_constant: 3950
reference_temperature: 25°C
reference_resistance: 100000
name: "$hostname NTC Temperature"
# Example source sensors:
- platform: resistance
id: resistance_sensor
sensor: source_sensor
configuration: DOWNSTREAM
resistor: 500000
reference_voltage: 3.3
name: $hostname Resistance Sensor
internal: true
- platform: adc
name: "$hostname RAW ADC"
internal: true
id: source_sensor
pin: A0
update_interval: 3s
filters:
- median:
window_size: 3
send_every: 1
send_first_at: 1These give me a bit rough readings, but correlating with the bulb temperature. Can someone share higher quality photos of the PCB if you have some of those bulbs torn apart? I really wonder what the real resistance is. |
|
I'm trying to do the same with the Wiz Colors A.E27 bulb. I pulled off the plastic cap and this is what's underneath. No screws visible. I am a bit afraid to break anything. What's the best way to remove this LED part so I can access the PCB?
|
|
Try to remove the glue carefully. Sometimes a bit heat can help. The board is plugged. |
|
I used the Wiz app to install four of the Philips-Wiz bulbs on my network. Home Assistant recognized all four and they are now controlled with Home Assistant. |
I'm trying to pry a screwdriver between the edge of the board and the case, is that the way to get the board out? Can I apply pressure there? |
|
Try the remove the glue around the LED board carefully. I assume there is a lot of glue or thermal paste under the board. Try to avoid the too much pressure/force. |
|
I have two E27 bulbs that are sold as Wiz Connected A60, the warm white (2700K) variant: https://www.wizconnected.com/it-it/p/lampada-led-lampadina-a60-e27-x2/8719514550070 I opened one, without damaging it: Photos
ESP32-SOLO-1! Unfortunately I see no pads to access the UART interface. How should I proceed? |
|
Basically: Look harder 😀 Maybe that just means to use to exposed edge pins on the module, should be the pinout from here: Next potential hurdle may be if they chose to seal the ESP32 to block firmware replacement. In that case, the "cure" is to replace the module with a clean one. |
|
Success! Photos
Upon connecting GPIO0 to ground and applying power: Template: {"NAME":"WiZ A60","GPIO":[0,0,416,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"FLAG":0,"BASE":1}Please note that I had to use an external 3.3V power supply as my USB to TTL UART converter wasn't able to provide enough power to the ESP32. |
|
Great 😄
That's just expected for adapters with CP210x or fake "FTDI". The recommended "golden CH340G" is much easier to deal with, as it has an extra vreg on the board for 150 mA of 3.3V power. Maybe add to the Tasmota Supported Devices Repository, https://templates.blakadder.com/ including how to flash it. |
It's a DSD TECH SH-U06A, powered by a PL2303GC. I've read in the docs about the issue and "golden CH340G", but it's not a problem for me as I have a CV/CC bench PSU.
Sure, I'll do it as soon as possible! |
|
Firmware backup: WiZ_A60_2700K.bak.bin.zip Info on the casing: Photo
https://templates.blakadder.com/wiz_8718699786038.html I submitted the entry to the templates repository through Google Forms, as indicated on the website. |
Could you describe how you managed to take the board out? I tried it with a small box cutter to no avail. The housing is very hard and sturdy and doesn't allow prying a small screwdriver next to the board. |
|
The usual way of getting into bulbs is to pop off the plastic dome. Sometimes doable with some degree of "persuasion", maybe a rubber mallet, sometimes takes softening it up with heat or solvent. Varies by how each bulb type is built, and there is no general answer. (Of course, I have no experience with this particular one) |
|
@sfromis thank you I should've been more clear about that, I meant getting the board out, not popping off the dome. Updated my question. |
|
Images posted shows clear signs of the usual "mess" with some glue-like material used to bond the metal led disc to the base. The cure is the same again. Mechanical persuasion, possibly helped by heat/solvent. Sometimes slicing around with a box cutter to take off parts of the material, to get to the edge of the disc. The construction is that the disc rests on a lip on the base, with that glue-like thing to fix it there, and fill up the crack. |
|
@sfromis is right. In my case I poured plenty of alcohol and then sliced around the (aluminium) board to take off all the material (silicone?). The board actually has a cutout, it's not a full circle. I took advantage of that by leveraging a tiny flat head screwdriver against the housing. Alternatively, you could put together an improvised extractor made of solid steel wire and insert it through the ESP32 slot. By the way, I made a backup of the firmware on the second bulb, just in case. |
On your photo the second one , the black and white cable is black the gnd and withe 3.3v? |
|
The opposite, sorry for the confusing colors. |
|
I found a much better way to open the bulb, which is actually required if you want to secure the AC line wire. The circular contact at the bottom pops off quite easily with a flat head screwdriver and you can then remove the E27 connector. At that point it's just a matter of pushing the board out at the top, after removing the glue. |
|
I hope to flash it today, on the photo's on the back, the black is the 3.3v and white the ground. |
|
I think I see it, you connect the white cable form front to back on the side of rx and tx first pin |
|
Yes, when in doubt you can check the datasheet: https://www.espressif.com/sites/default/files/documentation/esp32-solo-1_datasheet_en.pdf Pinout
|
|
I did open the bulb, same partnumber , and what I see, and es32-c3. Only I can't find the the right pins. I hope that someone knows a datasheet for it but it looks like an own WIZ esp32-c3. It has more pins 8 in total to the print. I can see op the print the tx, rx and gndm but nog de GPIO8 and 9 for flashing it. It look like the ESP8684-WROOM-07 ESP32-C2 CBLC5, but this one have less pins to the print and not the full shape Some photos
|
|
Could you try to provide a better photo of the second shot? There is a RX, TX and GND test pad visible. Are the two test pads on the left labeled too? |
|
Like this? |
|
This thread should provide some details about the module: https://www.reddit.com/r/wiz/comments/wzcvcd/wiz_wifi_modules_esp32solo1_vs_esp32c3/ This is the datasheet of the ESP32-C3-WIZ2012 module: https://fcc.report/FCC-ID/2AGBW-WIZ2012/5260304.pdf These are the pads we are looking for: Probably bad news about your bulb: https://templates.blakadder.com/unsupported/walmart_6000201820584.html |
|
There exists an exploitable glitch attack against ESP32-C3 parts, so someone with a will could extract the key, I guess, but yeah, not great. |
and others
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
The text was updated successfully, but these errors were encountered: