[bug] Tailwindcss icons not showing in deb build

Describe the bug
icons from @egoist/tailwindcss-icons are not showing up in a built application(deb, or AppImage). In development they work
Reproduction

create a tauri app (i used solid as the frontend, but i think this shouldn't matter)
add tailwindcss (i also added solid-ui, i dont think that is important here though)
add @egoist/tailwindcss-icons and a iconify collection like @iconify-json/tabler
use an icon like i-tabler-sun in your frontend code
check that it is displayed when running tauri dev
build the application (for linux)
install the deb or run the appimage
-> The icon should be missing in the built application

Expected behavior
Icons work just like in development
Full tauri info output
[✔] Environment
    - OS: Linux 17.0.0 x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.46.3
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
    ✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.11.1
    - pnpm: 9.1.0
    - yarn: 1.22.22
    - npm: 10.2.4
    - bun: 1.1.39
    - deno: deno 2.0.6

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-dialog 🦀: 2.0.3
    - @tauri-apps/plugin-dialog : 2.0.1
    - tauri-plugin-fs 🦀: 2.0.3
    - @tauri-apps/plugin-fs : 2.0.2
    - tauri-plugin-shell 🦀: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1
    - tauri-plugin-store 🦀: 2.1.0
    - @tauri-apps/plugin-store : 2.1.0

[-] App
    - build-type: bundle
    - CSP: default-src 'self' ipc: http://ipc.localhost; img-src 'self' asset: http://asset.localhostdefault-src 'self' ipc: http://ipc.localhost; img-src 'self' asset: http://asset.localhost
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: SolidJS
    - bundler: Vite

Stack trace
No response
Additional context
The icons are included in the css built by tailwindcss

Can you try a debug build via the --debug flag (output in target/debug/bundle/) and check the devtools console (right click -> inspect) for errors? My guess would be that it's a csp issue.

Yes, you were right:
I get these errors in the console:
[Error] Refused to load data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' width='24' height='24'%3E%3Cpath fill='none' stroke='black' stroke-linecap='round' stroke-linejoin='round' stroke-width='2' d='M8 12a4 4 0 1 0 8 0a4 4 0 1 0-8 0m-5 0h1m8-9v1m8 8h1m-9 8v1M5.6 5.6l.7.7m12.1-.7l-.7.7m0 11.4l.7.7m-12.1-.7l-.7.7'/%3E%3C/svg%3E because it does not appear in the img-src directive of the Content Security Policy.
[Error] Refused to load data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' width='24' height='24'%3E%3Cpath fill='none' stroke='black' stroke-linecap='round' stroke-linejoin='round' stroke-width='2' d='M12 3h.393a7.5 7.5 0 0 0 7.92 12.446A9 9 0 1 1 12 2.992z'/%3E%3C/svg%3E because it does not appear in the img-src directive of the Content Security Policy.
[Error] Refused to load data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' width='24' height='24'%3E%3Cpath fill='none' stroke='black' stroke-linecap='round' stroke-linejoin='round' stroke-width='2' d='M3 10a7 7 0 1 0 14 0a7 7 0 1 0-14 0m18 11l-6-6'/%3E%3C/svg%3E because it does not appear in the img-src directive of the Content Security Policy.
[Error] Refused to load data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' width='24' height='24'%3E%3Cg fill='none' stroke='black' stroke-linecap='round' stroke-linejoin='round' stroke-width='2'%3E%3Cpath d='M10.325 4.317c.426-1.756 2.924-1.756 3.35 0a1.724 1.724 0 0 0 2.573 1.066c1.543-.94 3.31.826 2.37 2.37a1.724 1.724 0 0 0 1.065 2.572c1.756.426 1.756 2.924 0 3.35a1.724 1.724 0 0 0-1.066 2.573c.94 1.543-.826 3.31-2.37 2.37a1.724 1.724 0 0 0-2.572 1.065c-.426 1.756-2.924 1.756-3.35 0a1.724 1.724 0 0 0-2.573-1.066c-1.543.94-3.31-.826-2.37-2.37a1.724 1.724 0 0 0-1.065-2.572c-1.756-.426-1.756-2.924 0-3.35a1.724 1.724 0 0 0 1.066-2.573c-.94-1.543.826-3.31 2.37-2.37c1 .608 2.296.07 2.572-1.065'/%3E%3Cpath d='M9 12a3 3 0 1 0 6 0a3 3 0 0 0-6 0'/%3E%3C/g%3E%3C/svg%3E because it does not appear in the img-src directive of the Content Security Policy.
[Error] Refused to load data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' width='24' height='24'%3E%3Cpath fill='none' stroke='black' stroke-linecap='round' stroke-linejoin='round' stroke-width='2' d='M19.5 12.572L12 20l-7.5-7.428A5 5 0 1 1 12 6.006a5 5 0 1 1 7.5 6.572'/%3E%3C/svg%3E because it does not appear in the img-src directive of the Content Security Policy.

now the question is how do i fix this, cause i can't just include all the icon urls in the csp.
btw this is my tauri.conf.json:
{
    "$schema": "https://schema.tauri.app/config/2",
    "productName": "comic_reader",
    "version": "0.1.0",
    "identifier": "com.comic-reader.app",
    "build": {
        "beforeDevCommand": "bun run dev",
        "devUrl": "http://localhost:1420",
        "beforeBuildCommand": "bun run build",
        "frontendDist": "../dist"
    },
    "app": {
        "windows": [
            {
                "title": "comic_reader",
                "width": 800,
                "height": 600
            }
        ],
        "security": {
            "csp": "default-src 'self' ipc: http://ipc.localhost; img-src 'self' asset: http://asset.localhost",
            "assetProtocol": {
                "enable": true,
                "scope": ["**"]
            }
        }
    },
    "bundle": {
        "active": true,
        "targets": "all",
        "icon": ["icons/32x32.png", "icons/128x128.png"<EMAIL_ADDRESS>"icons/icon.icns", "icons/icon.ico"]
    }
}

now the question is how do i fix this, cause i can't just include all the icon urls in the csp.

Then i think the only thing left is the 'unsafe-inline' property 🤔

I fixed it with adding data: to img-src: like this:
{
    "$schema": "https://schema.tauri.app/config/2",
    "productName": "comic_reader",
    "version": "0.1.0",
    "identifier": "com.comic-reader.app",
    "build": {
        "beforeDevCommand": "bun run dev",
        "devUrl": "http://localhost:1420",
        "beforeBuildCommand": "bun run build",
        "frontendDist": "../dist"
    },
    "app": {
        "windows": [
            {
                "title": "comic_reader",
                "width": 800,
                "height": 600
            }
        ],
        "security": {
            "csp": {
                "default-src": "'self' ipc: http://ipc.localhost",
                "img-src": "'self' asset: http://asset.localhost data:"
            },
            "assetProtocol": {
                "enable": true,
                "scope": ["**"]
            }
        }
    },
    "bundle": {
        "active": true,
        "targets": "all",
        "icon": ["icons/32x32.png", "icons/128x128.png"<EMAIL_ADDRESS>"icons/icon.icns", "icons/icon.ico"]
    }
}


Does the source package has any dependencies? like python version etc.

The Python version I am using is:
Python 3.5.0a1 (default, Jul 15 2015, 17:58:06)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-51)] on linux
When I run "python ../tracker/rabit_demo.py -n 2 basic.rabit".
I get :
Traceback (most recent call last):
File "../tracker/rabit_demo.py", line 96, in
tracker.submit(args.nworker, [], fun_submit = mthread_submit, verbose = args.verbose)
File "/home/zhaoyin.zy/rabit/tracker/rabit_tracker.py", line 316, in submit
master.accept_slaves(nslave)
File "/home/zhaoyin.zy/rabit/tracker/rabit_tracker.py", line 259, in accept_slaves
s = SlaveEntry(fd, s_addr)
File "/home/zhaoyin.zy/rabit/tracker/rabit_tracker.py", line 53, in init
magic = slave.recvint()
File "/home/zhaoyin.zy/rabit/tracker/rabit_tracker.py", line 35, in recvint
return struct.unpack('@i', self.recvall(4))[0]
File "/home/zhaoyin.zy/rabit/tracker/rabit_tracker.py", line 33, in recvall
return ''.join(res)
TypeError: sequence item 0: expected str instance, bytes found
AssertError:ReConnectLink failure 2
Socket RecvAll Error:Connection reset by peer

it seems to be my problem, I have not fully tested on python three. seems the recv of python function received int instead of string. So res is a list of bytes array instead of string and join did not work.
If you are interesting  can you send a PR to fix this problem?
Thanks!

sorry for the late reply.
PR? what's the meaning?


Package simply not works

I tried to use your package as dependency and getting data from here:
http://feed.rutracker.org/atom/f/1880.atom
but unfortunately package does not seems to work. All tests is failing even from it original sources
node-feedparser` unit test
  1) rss without tags
  2) atom without tags
  3) rss with tags
  4) atom with tags

0 passing (8s)
4 failing

1) node-feedparser unit test rss without tags:
   Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

2) node-feedparser unit test atom without tags:
   Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

3) node-feedparser unit test rss with tags:
   Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

4) node-feedparser unit test atom with tags:
   Uncaught Error: Not a feed
    at FeedParser.handleEnd (node_modules/feedparser/main.js:123:13)
    at Object.SAXStream._parser.onend (node_modules/sax/lib/sax.js:184:8)
    at emit (node_modules/sax/lib/sax.js:615:33)
    at end (node_modules/sax/lib/sax.js:654:3)
    at Object.SAXParser.end (node_modules/sax/lib/sax.js:149:24)
    at SAXStream.end (node_modules/sax/lib/sax.js:234:16)
    at FeedParser._flush (node_modules/feedparser/main.js:1066:17)
    at FeedParser.<anonymous> (node_modules/readable-stream/lib/_stream_transform.js:135:12)
    at finishMaybe (node_modules/readable-stream/lib/_stream_writable.js:371:12)
    at endWritable (node_modules/readable-stream/lib/_stream_writable.js:378:3)
    at FeedParser.Writable.end (node_modules/readable-stream/lib/_stream_writable.js:356:5)
    at StringStream.pipe (node_modules/string-stream/index.js:34:8)
    at module.exports (index.js:46:12)
    at Request._callback (test/index.js:14:16)
    at self.callback (node_modules/request/request.js:186:22)
    at Request.onRequestError (node_modules/request/request.js:845:8)
    at Socket.socketErrorListener (_http_client.js:308:9)
    at emitErrorNT (net.js:1271:8)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

I very like the idea of your parser so please if it possible add some fixes. I even don't know could I read needed RSS source using this

Sorry, i have't test it for a long time, i will do some test and add this module to travis.
If i find some bug, i will fix it as soon as possible.

Hi, i have make some tests on travis. It's ok to parse http://feed.rutracker.org/atom/f/1880.atom.
I think it could be your network's problem.
There is travis link node-feedparser.


Support RGB565

Some system that I emulate generate video frames with that format. It would be great if I could create a texture with that format and update the pixels directly. Right know I have to convert the formats in software before updating the texture.
I could contribute something for OpenGL, but I wouldn't know what to do WRT the other backends.

IIRC sokol_gfx.h actually had RGB565 support in the past as optional format, but it wasn't supported well enough to justify keeping it in (the current list of pixel formats is basically what WebGPU supports, and they did extensive research what formats are supported across GPUs and 3D APIs, and this doesn't include any of the packed 16-bit formats: https://www.w3.org/TR/webgpu/#texture-formats
D3D11 and Metal only have BGR565 formats not RGB565 (D3D11 only since D3D11.1, while sokol_gfx.h currently uses D3D11.0), and on GL you might hit a software-conversion step on texture upload if the input format doesn't match a supported hardware format).
TL;DR: not a fan of adding RGB565 support back in :)

Nah, that's a totally valid reason. I thought RGB565 was universally supported. Maybe I can come up with a shader to get two pixels from RG and two from BA to avoid the CPU conversion, although I'm not sure it would make a difference in the grand scheme of things, given the software framebuffers are small.

Ok, I'll close this then as 'not planned' :)


[Proposal] Support CSS property Inheritance

See the example below:
<template>
  <div style="color:blue">
    <text>blue</text>
  </div>
</template>

The text color should be blue, but it shows black on the phone. (demo)
I think we should support the inheritance, which is a useful and powerful technique in writing styles.
Properties we should support
The full list of inherited properties could be found in W3C's spec. Here is a summary on stackoverflow: Which CSS properties are inherited?.
But we do not need to support all Inheritable properties (many properties are not support originally).
Here is a candidate list I organized:

color
font-family
font-size
font-style
font-weight
line-height
text-align

Quite a short list.
The most important property we should support at first is color and font-size.

On hold, temporarily move to #1494 . It will be reopen when we actually doing this.

After two years, when should this issue reopen?


Add missing imports to resolve called predicates

The global_prefix_expand2 predicate is called from frame.pl and the merge_separator_split/3 is called from database_utils.pl.

Thanks for noticing. As far as I could see, we resolved this by importing them now.


Override the collections' fetching methods in order to get a nested output

A Collection is a Paginator. So that is the place to the output nested.

Rejected. The output nesting has been resolved over a custom hydrator ("How to retrieve embedded collections?").

Rejected. The output nesting has been resolved over a custom hydrator ("How to retrieve embedded collections?").


Change MIN_GENESIS_TIME of altona config to 2020/6/27 12:30pm

As discussed, change MIN_GENESIS_TIME to saturday with the original 48hr offset for a genesis on monday. This will bring in more genesis deposits, but that should be fine

Perfect.


HHH-4962: Taking @OneToMany(mappedBy) Into Account

@AuditMappedBy can already be used to define an inverse mapping for envers.
Being unable to see any reason why standard annotations may not be taken
into account mappedBy from @OneToMany is used for an inverse @ManyToOne
mapping and can be overridden by @AuditMappedBy.

Hi Matthias!
Thanks for submitting pull request. Don't you think that it would be more consistent if CollectionMetadataGenerator.searchMappedBy(PersistentClass, Table) method was modified as I did here: https://github.com/lukasz-antoniak/hibernate-core/commit/12464d7d73292db8c60cd619840868ccd5918ce9? Anyway, your changes to AuditedPropertiesReader and/or my to CollectionMetadataGenerator, does not make ImplicitMappedByTest test pass. IMO the type of relation presented in this JIRA issue shall be mapped as "fakeOneToManyBidirectional", and CollectionMetadataGenerator.addCollection() method needs to be adjusted. Could you investigate further?
Regards,
Lukasz Antoniak

I think that I have solved this issue. Please see another commit: https://github.com/lukasz-antoniak/hibernate-core/commit/19c7a8197f485abf7e1bd0547025df311a9ad049.
The @OneToMany.mappedBy() attribute has to be read as Matthias suggests. Otherwise it is difficult to differ bi-directional relation with @JoinTable on the owning @ManyToOne side from other relations (for example OneToManyComponentTestEntity, ParentReferencingChildTest, BasicList, IdMapKey, BasicMap, BasicWhereJoinTable, ManyToManyInverseToSuperclassTest etc. tests fail) inside CollectionMetadataGenerator.addCollection() method.
Adam, if you have time please check my findings.
Regards,
Lukasz Antoniak

Ah, this is indeed a case not covered yet :)
And it must be in fact treated same as a "fake" relation. Code looks good, if the new test passes, and the old test as well, push it ;)

Issue resolved. Thanks Matthias.


Update requirements and instructions to update

JMM

This is to pull in https://github.com/googlefonts/glyphsLib/pull/1048


anisotropy beta parameter

I have written some rough code to evaluate the anisotropy parameter β  tools.anisotropy(), in my fork. Example, examples/example_anisotropy()

Notes/issues:
(1) Code is rough, needs further testing (by me), exception checks, unit tests.
(2) Uses scipy.optmize.curve_fit().  Currently center_image_by_slice() uses scipy.optimize.minimize() - I should make them consistent.
(3) tools.reproject_image_into_polar() returns polar angle reference to the horizontal direction (? I think). Our θ should be with respect to the vertical direction. I am not sure whether the correction should be applied within the reproject... function?
(3) Both calculate_speeds() and now anisotropy() reproject the image coordinates. This may be wasteful, when only one evaluation is required.

@stgg, great work! The anisotropy calculation is one of fundamental tools for many VMI spectroscopy labs, and it's a central feature of the BASEX program, so I think that many users will be looking for it.
It would be helpful to see a definition of the anisotropy parameters, since I have never made use of them. But I am on vacation and don't have my books in front of me, and I can't find a solid definition in a paper. Do you have a textbook that has a good definition of the anisotropy parameters that you can take a photo of and post here?
What you are calculating is Beta_2, right? I know that people often like to look at higher order beta parameters, typically even ones. But in some cases odd beta parameters may be useful as well. We should probably have an option to include higher order terms.
Regarding #2: The use of scipy.optimize.curve_fit() has me a little bit worried. I'll bet that a nonlinear fit is the best way to extract beta from a nice dataset (like the beautiful ones that you collect). But nonlinear fits do not always converge, and they are very dependent on the starting conditions, often finding false minima. It seems like if we are just extracting one number from a curve, there should be a simpler way. scipy.optimize.minimize() at least lets you set the bounds on the anisotropy parameter. It seems like this should be beneficial. We should also return an estimate of the error of the anisotropy parameter.
Regarding #3: I think that you are correct that we should set theta=0 to be in the vertical direction. I'm not sure of the easiest way do do this. Probably we can change theta = np.arctan2(y, x) to theta = np.arctan2(x,y) in cart2polar in tools.py (and swap the sin and cos in polar2cart). Alternatively, we can switch things around in the reproject_image_into_polar() function, but it seems best to change our fundamental definitions of where theta=0 is.
Regarding #4: Is the reprojection into polar coords the most expensive part of the anisotropy calculation? If so, I think that you are correct that it's silly to potentially calculate it twice. What about renaming your function something like "polar_integrate" and having it return an object with properties results.radial_intensity  (aka, "speeds"), results.radial_intensity_std_dev (just to provide some error estimate for the first), results.anisotropy, and results.anisotropy_error. Perhaps provide a boolean argument anisotropy=False to allow users to toggle the anisotropy part of the calculation on and off.
Eventually we can delete the current calc_speeds and replace with this new polar_integrate.
(Actually, now that I look at your function, I see that it returns a lot of other things as well. Can you explain a little more what these are?)
Currently, your code provides an option to specify the theta range used (which I think makes sense), and also the r range. To me, it seems like the calculation can just be done for all r values and the user can just as easily sort out later which values are meaningful to them. Is there a reason that the r-range must be specified at this stage?
Anyway, it's great to see a first draft working!

@DanHickstein thanks for your, as usual, very comprehensive code review, and for taking time from your vacation. I am also on summer vacation, and hope to head to the beach tomorrow (a not so trivial trip from an inland city).
Just a few quick responses to some of your comments:

Anisotropy parameter definition
The commonly cited reference in photoelectron spectroscopy is http://dx.doi.org/10.1063/1.1668742

Experiment measures intensity vs angle providing β via Eq.(1). Quantum mechanics calculates β via Eq. (2). Eq. (1) is for linearly polarized light, illuminating a non-polarized target. As you note, there are higher order anisotropy parameters, but they are not generally of importance for photoelectron measurements. It is difficult enough to determine accurate values for β.
My favourite theoretical derivation is given in Chapter 2 of the thesis by Sara Thorin
"Design and construction of a velocity map imaging spectrometer" (2004) Lund University
http://www.lunduniversity.lu.se/lup/publication/2261125

I made use of curve_fit because it is easy to use, and readily provides the parameter (fit) error(s). I will investigate the many other options.

reproject_image_into_polar(): Your solution theta = np.arctan2(x,y) looks like the best choice.

Not so much the time evaluate the polar coordinates, but that the operation would no doubt already have been done  in the speed calculation. Perhaps, we need one of @rth 's classes(?) to keep track of results. I will think about your other options.

The θ range allows for exclusion of the inverse Abel center image noise, and processing only one quadrant of an image that had been previously quadrant co-added.

The r range specification is necessary to, provide for integration across a spectra feature (actually a simple .sum()), to increase the signal/noise. This aspect is essential in order to extract a good estimate of the anisotropy parameter. Note, also, the β depends on the kinetic energy of the electron, so each transition (peak) has a different anisotropy parameter. My code does not, yet, correctly, return multiple β values.
(somehow stuffed up the item numbering)

To overcome @DanHickstein  issue 2) above I have split the anisotropy code into:
(a) calculate_anisotropy_distributions(IM, radial_ranges=None) and
(b) anisotropy_parameter(theta, intensity)
calculate_anisotropy_distributions() mirrors calculate_speeds(), sums over the other axis
anisotropy_parameter() performs the least-squares fit to 1+βP2(cosθ) to extract β
Modified examples/example_anisotropy_parameter.py

Okay, this sounds good. I think that the BASEX.exe program returned the anisotropy parameter as a function of the radial coordinate (i.e., a whole array of beta values, one for each radial pixel). Is this something that is feasible here, or is the fitting too slow to make this practical? It's actually pretty slow in the BASEX.exe program as well (~5 seconds for 1000x1000 on a new i7 desktop if I recall).

In principle, this can be done. In practice, the fitting of β may be nonsense, due to the low signal/noise of each polarIM column (theta), as indeed basex.exe returns for my photoelectron images.  For consistency with the old basex.exe formalism I will investigate whether it is sensible to provide this (mis-)feature.

I just looked at the C-code for the anisotropy distributions in BASEX.exe (here is the relevant function, here is the whole CalcThread.cpp file) and I'm not quite sure why it doesn't produce reliable results, since it's calculating the anisotropy distributions straight from the coefficients of the basis functions and not doing any fitting. I suppose that signal to noise could still play a role. Perhaps the centerline noise throws it off?
Anyway, we can, by default, use a coarser grid for generating the anisotropy versus r array in order to give us a better chance of having sufficient signal-to-noise. For example, we could use a bin size of, say, 3 radial pixels. It would make the calculation faster as well.

Perhaps, basex.exe is not calculating  beta vs r?
Through the magic of ssh, Linux, and Wine, I may run basex.exe on my Mac (at home, from an unix system at the ANU):

The speed distribution is:

The anisotropy distribution is:

The above curve(s) make no sense to me.
PyAbel (hansenlaw) gives:

radial-range
anisotropy parameter (β)

255-270     |   +0.10+-0.12
275-295     |  -0.15+-0.04
330-355     |  -0.18+-0.02

If we are talking about the same quantity, the PyAbel analysis provides 3 β data points, for r~262, 285, 340.
The main peak fit is shown (right most plot). Note, for slow electrons (at 812 nm eKE is ~ 0.1 eV) the electron distribution is almost isotropic, β has small values, and the fit, rightmost figure, looks poor.
PS: I realize that an image 1024x1024 pushes the 1000 limit of basex.exe, but 1024x  is what I had handy. I am pretty sure the same odd anisotropy data is still generated for sizes less than 1000.

Hmmm, it's weird that the BASEX anisotropy looks so terrible. They published reasonable anisotropy values in Fig. 5 of their paper: http://www-bcf.usc.edu/~reisler/assets/pdf/67.pdf
As I recall, the BASEX.exe may be sensitive to the absolute values of your input image. What range of pixel intensities are you feeding into BASEX? Can you try multiplying them by 10, 1000, or maybe 0.01?

Changing the image size does little to improve the ...ansio.dat data.

I have coded Eq. (16) of the BASEX paper (cited in the comment above)  here

(my apologies for the poor plot structure)

The image looks similar to Fig. 2. However, the inverse Abel transforms (hansenlaw, basex, and the original basex.exe) are substantially different to Fig.4 . I believe selected amplitudes may be different, i.e. not 2000, 200, 50.
abel.hansenlaw and abel.basex agree with each other, but do not handle the inversion very well, possibly due to coarse a grid.  basex.exe is more like Fig. 4., but note that this may be due to the lack of negative values.
The anisotropy from basex.exe is still crazy, it looks nothing like Fig. 5.
@DanHickstein the basex paper does not explain how β  is extracted. The .cpp code has a /baux1(0,0); which may be causing an issue, but the radial data, similarly normalized(?) is fine. The is insufficient code to track down the method.
The ansiotropy parameters extracted from tools.anisotropy_parameter() give:
Calculating angular distribution:

radial-range
anisotropy parameter (β)

  5- 15        |    +1.24+-0.09
 10- 20       |    -1.44+-0.03
 15- 25       |     +0.45+-0.02
 65- 75       |     -0.14+-0.01
 80- 90       |    +2.37+-0.01
 95-105      |     -1.06+-0.01
140-150     |     +4.81+-0.12
150-160     |    +0.66+-0.00

The selected intensity variation for peak at radius 95-100 shown in 2nd right figure. Note, the intensity variation vs angle for the data(red) cf the fit (blue) differs for each 1/2, suggesting that the data center is not quite in the middle (another bug fix job to do).  Amazingly enough it has about the right value, β=-1.
I think that further play with the basex model image I(R, theta), is in order, scaling the amplitudes to give a speed distribution similar to Fig. 4, and perhaps, the r-grid to allow hansenlaw and basex to behave. I have noted in the past that the hansenlaw algorithm will overshoot due to too large a grid. I usually use a bigger image size, however a change of grid size dr may have the same effect.
Apologies, the above is very rushed ...

Oh! I love that you have coded up the model image from the BASEX paper. Maybe you can add this function to abel.tools.py as something like sample_image_dribinski()
Here is the complete c-code for BASEX in case you want to try to track down the problem with baux1: https://dl.dropboxusercontent.com/u/3816350/BASEX C-code.zip
But, really, it's not our problem to fix BASEX.exe, we just need to make our own code work...
You are using an even image (316x316) right? I think that our BASEX method still works with odd-sized images.

add this function to abel.tools.py as something like sample_image_dribinski()

Or elsewhere?  We have quite a few standard image functions (Gaussian -1D, -2D, 'curve A') in abel.test_<method>.py perhaps they can be combined into one file, and moved out of the directory tests?
@rth has created abel.analytical.py with the comment:

This file includes functions that have a known analytical Abel transform.
They are used in unit testing as well for comparing different iAbel impementations.

but, IMO, the (nice python) class structure may discourage user examination of the functions. Perhaps, the non-class functions (including abel_step_analytical() and sym_abel_step_1d()) may be added at the top?

@DanHickstein, @rth, @DhrubajyotiDas
As the result of testing some of the algorithms, I have found the origin of the  Fig. 4 (of the BASEX paper) vs calculated intensity difference in the speed profile (mentioned above).
It is due to the lack of the Jacobian factor. If included the intensities agree with the published figure:

# code to evaluate the speed profiles
from abel.hansenlaw import fabel_hansenlaw_transform, iabel_hansenlaw_transform#

#NB these imports have changed due to my implementation of how tools.py is split (open to change)
from abel.tools.analytical import sample_image_dribinski
from abel.tools.symmetry import get_image_quadrants
from abel.tools.vmi import calculate_speeds

import matplotlib.pyplot as plt

# BASEX sample image
IM = sample_image_dribinski(n=361)

# core transform(s) use top-right quadrant, Q0
Q0, Q1, Q2, Q3 = get_image_quadrants(IM)

# forward Abel transform
fQ0 = fabel_hansenlaw_transform(Q0)

# inverse Abel transform (of the forward Abel transform)
ifQ0 = iabel_hansenlaw_transform(fQ0)

# speed distributions, repeat for Jacobian=False
speed, radial_coords = calculate_speeds(ifQ0, origin=(0,0), Jacobian=True)

orig_speed, orig_radial = calculate_speeds(Q0, origin=(0,0), Jacobian=True)

#plot as required

Awesome! That looks beautiful.

It works!


Post release automated changes for notificationhubs releases

[Manual] Post release automated changes for azure-notification-hubs

/check-enforcer evaluate

API change check
API changes are not detected in this pull request.


When deploying the Distribution the CachePolicy creation returns 400 Bad request

When deploying the Distribution, the CachePolicy creation returns 400 Bad request. As a result deploying a next app with all defaults will not work.
A way to fix it will be to use override:
overrides: {
      nextjsDistribution: {
        imageResponseHeadersPolicyProps: {},
        serverCachePolicyProps: {
          headerBehavior: CacheHeaderBehavior.allowList(
            'accept',
            'rsc',
            'next-router-prefetch',
            'next-router-state-tree',
            'next-url',
            'x-prerender-revalidate',
          ),
        },
      },
    },

There is a conflict between accept-encoding and enableAcceptEncodingGzip: true. Being set both at the same time.

PR: https://github.com/jetbridge/cdk-nextjs/pull/188
Fixes the issue.


Add YLXD05YL and YLXD01YL support (Mediatek devices)

Is it possible to assist with flashing the YLXD05YL and YLXD01YL models of the Yeelights?
Photos attached of mainboards.
Thankyou

Bad news: The heart of the white daughterboard is a Mediathek microcontroller. Esphome has ESP8266 and ESP32 support only. Your device aren't Esphome compatible. :-(

Ah ok, thought that might be the case when I pulled it apart. Thanks anyways

Do you like to replace the white daughterboard with an esp32? The task isn't easy but possible.

Interesting, I'd assume a fairly good understanding of the schematics of the board would be needed no?

Yes. I try to outline the steps to get a better undestanding what needs to be done:

Use the pads at J2 to power the daughter board. Attach 3.3V + GND to a power supply providing 3.3V. Don't attach the LEDs! Don't power the device with 230V. Attach RXD, TXD and GND to a USB-to-TTL serial adapter.
Open a serial console. You should see some output of the stock firmware.
Try to control the device by the android app. Do you see any output at the serial console?
Remove the power. Try to understand / identify which pads of the white daugther board are connected to the led driver. Trace the lines / use a continuity tester.

We are ready if you've identified the following pins:

START
3.3V
GND
RXD
TXD
C (Cold white), PWM signal
W (Warm white), PWM signal
Night light (if supported), PWM signal
Standby / Power supply (if supported)

As soon we know the location of the pads of the different functions we will try to compare the pin layout of an esp32 wroom. I hope the esp32 can be attached/soldered 1:1 to the board. If not: The relevant pins needs to be wired to the corresponding pin (gnd, 3.3v, txd, rxd) of the esp32.

As soon we know/assume the location/pads of C, W, N and Standby we can verify our assumption by driving the stock firmware via the app. F.e. turn on the light and drive cold white to 100%. You should measure between C and GND a voltage of max. 3.3V (of it's less than 3.3V the max voltage of C is limited). Turn on the night light and measure the min/max voltage/setting of the nightlight. Turn the light on/off. Measure the voltage at the standby pin.

As soon you know your device very well, we can replace the white daughter board. I assume a lot of pads aren't connected. If we find pads/connections without knowing the purpose we are doomed. ;-)

Excellent guide, next weekend when I have time I'll start poking around

Hello Syssi!
Thank you for your wonderful work!
I have similar light.
So i can see output on UART. Miio net, miio monitor etc. It reacts when i change settings in yeelight app i.e.  "new britght 67".
Should i look for particular messages?

You can identify a PWM signal if you measure the voltage of a GPIO. If you change the brightness the voltage should change.

So the reason was mediatek doesn't output pwm signal when is not connected to the mains.
Now i've managed to find cold and warm leds.
Is there way to disable mediatek without displacing it?
i'd want to connect esp32 to test everything. And only displace old MCU after everethyng is working.
Tried to connect start with the groud but no effect.

So these pins i discovered so far:
Anten	 -
Anten	 -

         	 -

RX	         -
TX	         start

       -

CldLED	 -
WrmLED	 -

       -

       -

       G

       3v3

G	         3v3
G	          -

nightlight is very low warm leds. What the nightlight pin does and how to find it?
Same with RGB backlight. I'm not familiar with how it works yet. Should it be 3 different pins?

The nightlight pin is a PWM pin too. It drives the warm white LEDs in a very low brightness range.
The RGB backlight are 3 PWM pins one per color.

I prefer to remove the Mediathek MCU before assembling the ESP32 because it will be hard to remove the power supply from the Mediathek MCU only.

Hi Sebastian!
Thanks!
So the pinout now looks like this:

What else should be considered before desoldering Mediatek?
Your yaml contains "power_supply" pin. Is it necessary or it could be not present in my device?

At some devices a GPIO ist used (Low vs. High) to turn the LED driver on and off. Please check all remaining pins while turning the lamp on and off. Do you see a GPIO flipping between 0 and 3,3V?

What these two pins could be meant for?
Also i provided 3,3V to cold and warm LED pins when the light was turned off and the LEDs worked.
Does it mean that the driver is always on and all we need is just to provide PWM output?

5 pins are always high but they are not connected to 3.3pin
4 pins are always low

Just keep this in mind.
What these two pins could be meant for?

I don't know.

Also i provided 3,3V to cold and warm LED pins when the light was turned off and the LEDs worked.
Does it mean that the driver is always on and all we need is just to provide PWM output?

Good idea. I think you are safe now. :-)

Finally got it working!
Sebastian, thank you for the help!
Issues so far:

Noise in night mode. May be i use not correct frequency for the LEDC component.  It's 1220Hz now.
Need to make least voltage about 0,67V for main light.  Don't know how to do it yet. So the light can disappear when i'm changing color temperature or move lovelace scale to thee left.
Don't know why, but blue pin now turn the greern light) could make bridge when soldering. I'll fix it later.
Bluetooth dimmer probably won't work ever. There is open issue but nothing happens so far: https://github.com/esphome/feature-requests/issues/293
May be you can advice lovelace card for such ceiling lights? All-in-one card

Could you provide a photo and your yaml as contribution?

2. make least voltage about 0,67V for main light.  Don't know how to do it yet. So the light can disappear when i'm changing color temperature or move lovelace scale to thee left.

try these frequency settings to get ride of the noise.
`output:

platform: ledc
pin: GPIO19
id: output_warm
frequency: 4882Hz

platform: ledc
pin: GPIO21
id: output_cold
frequency: 4882Hz

platform: ledc
pin: GPIO23
id: output_nightlight
frequency: 9765Hz`

I have the same light an was already thinking for a while to try this too. My soldering skills or the tools I where using have been simply not enough for the job. However I manged to restore full functionality except the Bluetooth remote.
There you go.
@syssi use any of the files for contribution if you want.
https://github.com/jaddel/ESPHome-Configurations/tree/master/Devices/Ceiling Yeelight YLXD05YL

@jaddel I've updated my ceiling lamps to esphome 1.18.0b3. In the past there where connection dropouts at the history. With 1.18.0 the connection is rock solidsolid.

Can't say that my soldering skills are good as well. But it works.

make least voltage about 0,67V for main light.  Don't know how to do it yet. So the light can disappear when i'm changing color temperature or move lovelace scale to thee left.

try these frequency settings to get ride of the noise.
`output:

platform: ledc
pin: GPIO19
id: output_warm
frequency: 4882Hz
platform: ledc
pin: GPIO21
id: output_cold
frequency: 4882Hz
platform: ledc
pin: GPIO23
id: output_nightlight
frequency: 9765Hz`

Thank you, i will!

i do for sure.
Actually i have both remote and dimmer.
The dimmer is not visible by miihome mod.
Remote is visible but returns error when try to pair with mihome mod.
Now i've managed to get mediatek back  into mihome mod, but no pairing .txt is available yet...

Well, miio returns another error:
C:\Users\user>miiocli device --ip  --token  raw_command ble_dbg_tbl_dump '{"table":"evtRuleTbl"}'
Running command raw_command
Error: {'code': -9999, 'message': 'user ack timeout'}

I assume at the daughterboard of your ceiling lamp is a small eeprom connected via i2c which is used to store the key. As long as your mediatek uC isn't back in place it's unable to retrieve the key from the eeprom.
I've used this modded mihome app: https://github.com/custom-components/ble_monitor/issues/289#issuecomment-844014615
Steps to pair the dimmer and retrieve the token:

Uninstall the original MiHome app
Install the modded APK (unknown sources must be enabled)
Login (use the region india as location/cloud/storage bucket)
Go to the settings of your android device (settings -> app -> mihome app) and make sure the app has permissions to write to the internal storage and to use the "phone permission". The first permission is required to write files to yor smartphone. The second permission is required for BLE (I hope I didn't miss a permission here).
Use a file manager to take a look at your internal storage. Do you see a vevs/ directory here?

If not: Close / kill the app and start it again. If the app has the permission the folder should be created now.
If yes: Goto the directory vevs/ and create a subdirectory called logs: vevs/logs/.

Close / kill the app.
Open the app. Goto the scanner/radar symbol at the top right corner and "scan" your environment for BLE advertisements.
Press and rotate the dimmer to provide some traffic
The dimmer should show up at the list of discovered devices.
Click on the dimmer to start the pairing.
If step 9 (pairing) doesn't complete start again at step 5. I had to disable bluetooth at my smartphone once and restart the app. If the pairing is successful it's super fast (3-6 seconds).
Take a look at the internal storage. You should find a file called pairings.txt now. Alternatively use the https://github.com/PiotrMachowski/Xiaomi-cloud-tokens-extractor to login into the cloud and retrieve all devices from region i2 (india).

It should look like this:
$ python3 token_extractor.py
Username (email or user ID):
***********************
Password:
***********************
Server (one of: cn, de, us, ru, tw, sg, in, i2) Leave empty to check all available:
i2

Logging in...
Logged in.

Devices found for server "i2":
   ---------
   NAME:     小米无线开关2
   ID:       blt.7.16mdp9hbd0g00
   BLE KEY:  ababababababababababababFFFFFFFF
   TOKEN:    efefefefefefefefefefefef
   MODEL:    yeelink.remote.ctrl
   ---------

Press ENTER to finish

The key abababababababababababab is the key you are looking for.

Dear Sebastian!
Thank you for so comprehensive guide!
I've tried two different smartphones, but both still can't pair with remote.
Reinstalled several times. Rebooted phones, turned bluetooth on/off...
Dimmer is not visible at all. I'll keep trying with different phones. But it doesn't look good so far(
Now i even think about resoldering mediatek back. To get control over bluetooth devices.
Another guess: i've unpaired remote in mihome app. But not sure the remote "knows" about that.
Pressed "M" and OFF buttons together as well...

If I remember correctly the modded mihome app can be used to pair the dimmer only. @rezmus Do you agree?
Do you know the instructions of the ble monitor? May be I missed an important step to press the pairing button of the dimmer:
https://github.com/custom-components/ble_monitor/blob/master/faq.md#how-to-get-the-mibeacon-v2v3-encryption-key
In my case I had to start, stop and re-install the app multiple times. At the end everything went well. The BLE keys of the devices doesn't change over time. I printed the key to the back of my dimmers now ;-)

app can pair both dimmer and remote, for sure the one bought separately pid 339. not sure if light bundle remotes can be paired, depends on pid. do you have proper version of the app? click + and go to household security. scroll down to remote control, view more. you should see remote/dimmer icons there. i paired both with the app recently without issues.
bt device does not know if it's paired or not. it just keep sending adv encrypted with constant key. any device arround which knows algo and key can decrypt.

@lazzzrus if you still have no luck with the app here's python script to auth device and read beaconkey directly (use pid 950 for dimmer and 339 for remote).
https://github.com/rexbut/mikettle/blob/master/get_beacon_key.py

@lazzzrus @rezmus It looks like there is another solution to retrieve the BLE key now: https://github.com/rexbut/mikettle/blob/master/get_beacon_key.py

@syssi look at previous comment ;)

You are fast as hell! :-)

Still no luck with Android. The only difference it now sees the dimmer. But can't pair as well. Thank you guys! Will try a python!

This thing looks cursed.
I've installed two instances of debian in virtualbox on two different hosts, also raspbian in raspberry pi.
Always get the same result:
# python3 get_beacon_key.py F8:24:41:C3:37:36 950      Activate pairing on your 'F8:24:41:C3:37:36' device, then press Enter:
Connection in progress...
Traceback (most recent call last):
  File "get_beacon_key.py", line 144, in <module>
    main(sys.argv)
  File "get_beacon_key.py", line 141, in main
    get_beacon_key(mac, product_id)
  File "get_beacon_key.py", line 96, in get_beacon_key
    peripheral = Peripheral(deviceAddr=mac)
  File "/usr/local/lib/python3.7/dist-packages/bluepy/btle.py", line 391, in __init__
    self._connect(deviceAddr, addrType, iface)
  File "/usr/local/lib/python3.7/dist-packages/bluepy/btle.py", line 439, in _connect
    raise BTLEDisconnectError("Failed to connect to peripheral %s, addr type: %s" % (addr, addrType), rsp)
bluepy.btle.BTLEDisconnectError: Failed to connect to peripheral F8:24:41:C3:37:36, addr type: public

@lazzzrus I also have a mediatek board on my yeelights and the board layout looks the same. So far i managed to desolder the mediatek board. It is not clear to me what is the pinout i should be using. Is this the correct pinout?
https://github.com/syssi/esphome-yeelight-ceiling-light/issues/10#issuecomment-827154861

I hope this helps a bit.

Amazing. Thanks @syssi!

I just received my ESP32 board I have more questions. In the initial discussions it was mentioned that the following pins need to be identified:

START
3.3V
GND
RXD
TXD
C (Cold white), PWM signal
W (Warm white), PWM signal
Night light (if supported), PWM signal
Standby / Power supply (if supported)

The following I understand how I should be mapping/connecting

3.3V
GND
C (Cold white), PWM signal
W (Warm white), PWM signal
Night light (if supported), PWM signal

The following I understand what they are, but do not understand how and why we need to connect them. Do we connect them to the TX and RX of the ESP32 or use other gpio pins

RXD
TXD

The following I don't know what they are for, or which pins on the ESP32 I should connect them to

START
Standby / Power supply (if supported)

I am also assuming R, G, B pins are more for lights that have RGB support, which mind doesn't so thus I don't have to connect them
any thoughts @syssi? Thanks in advanced :D

You are right: RXD and TXD isn't important. Both pins are required the flash esphome once. You don't need to solder these pins to the daughter board. START is also not important because it's the RESET pin of the Mediatek micro controller. At the beginnen I was unsure about the purpose of the pin. STANDBY is important if you ceiling lamp doesn't turn on if you apply a PWM to C or W. The STANDBY pin turns the power supply of LED driver board on/off (on some devices).

Gotcha. I'll give it a try and see what i get

@syssi It works great. Just got everything wired in. One thing - the light seems to turn off before hitting 1% brightness. How do I adjust it so that it will stay on at 1%?

This is a well known issue: https://github.com/syssi/esphome-yeelight-ceiling-light/issues/15#issuecomment-850946633
If you are able to solve/improve it please share your configuration!

For others to reference this post in the future, this is the configuration I used that worked for me
#Variables
substitutions:
  device_name: main-bedroom-light
  friendly_name: Main Bedroom Light

esphome:
  name: ${device_name}
  platform: ESP32
  board: nodemcu-32s
  platformio_options:
    platform<EMAIL_ADDRESS>    platform_packages: tasmota/framework-arduinoespressif32 @ 3.10006.210420

web_server:
  port: 80

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# logger:
api:
ota:
  password: !secret ota_password

output:
  - platform: ledc
    pin: GPIO19
    id: output_warm
    frequency: 4882Hz
    min_power: 0.07
    zero_means_zero: true

  - platform: ledc
    pin: GPIO21
    id: output_cold
    frequency: 4882Hz
    min_power: 0.07
    zero_means_zero: true

  - platform: ledc
    pin: GPIO23
    id: output_nightlight
    frequency: 9765Hz

light:
  - platform: monochromatic
    name: "${friendly_name} Nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    on_turn_on:
      - light.turn_off: night_light

Cool! I didn't know zero_means_zero.

May be you should try to pull-down/pull-up the standby pin once. Just to make sure the lamp doesn't turn off in one of the cases. It's possible the LED driver / power supply runs permanently now and it would be better to use the standby pin.

Have anyone found out which pin is 'standby' on mediatek board?
Anyway, I have already installed the lamp on the ceiling, and I don't want to climb to it yet :) So far everything is working fine without any failures, including when I powering off/on lamp. But I will keep in mind in case something goes wrong.

ndby pin turned out to be unnecessary. And here my config:
#Variables

Any updates on how it's working so far? Is it dimming nicely?
I have three of those, just want to be sure before I proceed :)

May be you should try to pull-down/pull-up the standby pin once. Just to make sure the lamp doesn't turn off in one of the cases. It's possible the LED driver / power supply runs permanently now and it would be better to use the standby pin.

Have anyone found out which pin is 'standby' on mediatek board? Anyway, I have already installed the lamp on the ceiling, and I don't want to climb to it yet :) So far everything is working fine without any failures, including when I powering off/on lamp. But I will keep in mind in case something goes wrong.

Any updates on how it's working so far? Is it dimming nicely?
I have three of those, just want to be sure before I proceed :)

May be you should try to pull-down/pull-up the standby pin once. Just to make sure the lamp doesn't turn off in one of the cases. It's possible the LED driver / power supply runs permanently now and it would be better to use the standby pin.

Have anyone found out which pin is 'standby' on mediatek board? Anyway, I have already installed the lamp on the ceiling, and I don't want to climb to it yet :) So far everything is working fine without any failures, including when I powering off/on lamp. But I will keep in mind in case something goes wrong.

Any updates on how it's working so far? Is it dimming nicely? I have three of those, just want to be sure before I proceed :)

I just finished doing this with my ylxd01yl (ceiling1) and it's dimming perfectly, also got the remote to work over bluetooth using https://github.com/dentra/esphome-components/tree/master/components/miot_ylyk01yl and with the bindkey I extracted using the mi home app that's linked somewhere above in this thread (https://ru.kapiba.ru/mihome/files/public/others/MiHome_6.5.700_63911_vevs_dimmer.apk).
I believe this: https://github.com/dentra/esphome-components/tree/master/components/miot_ylxx0xyl_pair also works to get the bindkey, though. Might be easier. I basically used the same yaml setup as wf1nder did, just included the bluetooth remote setup in there as well.

Thank you all guys, I managed to get my YLDX01YL to work perfectly thanks to you. I set up my bluetooth remote a little different though. I used this repo https://github.com/dentra/esphome-components/tree/master/components/miot_ylxx0xyl_pair to get the bindkey off of the remote that came with my light and from the same author I used this repo https://github.com/dentra/esphome-components/tree/master/components/miot_ylyk01yl to make it work on the esp32 that's controlling the lights.
I tried the ble_monitor setup linked above as well, but I believe it only works using the bluetooth on the home assistant itself (or I might have done something wrong), but the room I use the remote in is too far away for it to have a stable connection.
I used pretty much the same yaml as wf1nder, just with the added automations for when a button on the remote is pressed, and it's working great so far!

Hello,
I somehow managed to remove the mediathek device from my YLXD05YL (was very hard with my beginner tools). If I compare my board with the screenshots in this issue, it seems that mine is different? Can someone help me please? :) i know that I have to clean the board first, but my bottle with isopropanol is empty..

I assume your biggest issue is the shorting of the two pads at the bottom left of the photo. ;-) Could you provide some more and high-res photos of your mainboard?

Which pads do you mean? The ones which are completely „brown“? Is there something I can do to rescue the board? :(
Is Github compressing the photos? The last one should already be high-res.
But here some more.

It's fine now. I was talking about the two connected pins next to C39.

Could you provide a photo of the mediatek board? I would like to make sure this board hasn't changed.

I have found this picture, it looks like this is the same layout:

Do you know if this is a working configuration? I would connect 3,3V and GND to the same row where the START pin is, but all the others to same as shown in the picture.

Looks good to me. The photo of @jaddel does fit to your board.

Ok, thank you :) I will give it a try later today.

Successfully changed the mediathek controller with an esp32 last night. Thank you and all the others for the great work on this repository!
Just seven more yeelights left :grin:   at least two of them are the new arwen lights (YLXD013-B)

Congratulations! 🎉 If you convert or flash new lights like the YLXD013-B please try to identify the required GPIOs using the stock firmware/microcontroller first. This can be done easily using a multimeter. Ping me if you need support.

Converted the second YLXD05YL today. This time I have used the esp32-cam module from azdelivery because this one has a connector for the yeelight antenna onboard. It is working, but if i turn off the light it is transitioning from 100% to 0% and changing the colour from warm white to cold white shortly before turning off. The first ceiling light doesn't show this behaviour. Do you know what could be wrong?
Here is my yaml:
#Variables
substitutions:
  device_name:  deckenleuchte-schlafzimmer
  friendly_name: Schlafzimmer

esphome:
  name: ${device_name}
  platform: ESP32
  board: nodemcu-32s
  #board: esp32dev

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:
  password: "xxx"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Yeelight-Test Fallback Hotspot"
    password: "xxx"

captive_portal:

output:
  - platform: ledc
    pin: GPIO13
    id: output_warm
    frequency: 4882Hz
    min_power: 0.07
    zero_means_zero: true

  - platform: ledc
    pin: GPIO12
    id: output_cold
    frequency: 4882Hz
    min_power: 0.07
    zero_means_zero: true

  - platform: ledc
    pin: GPIO14
    id: output_nightlight
    frequency: 9765Hz

light:
  - platform: monochromatic
    name: "${friendly_name} nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6500 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: on
    on_turn_on:
      - light.turn_off: night_light

The two YLXD013 will be the last ones, which I'm going to convert. The multimeter is ready ;)

Could you try to change the light to 100% warm white and 0% cold white and turn the light off again? This time the transition is "warm" only. Right?
If you mix WW and CW (f.e. 50/50) and turn off the ligh you should see the effect always. It's because the WW LEDs are less intense because of the low number of LEDs IMO. It's possible the gamma correction could help here.

Alright, I have changed it to 100% warm white and now the transition is warm only. Thank you, I will also give the gamma correction a try.

I can convert a yeelight.celing.4 (YLXD02YL), following the above tutorials and also I could set the upper RGB ring light, wiring the pins R, G and B of

I hope this helps a bit.

Find the code I used for it:
output:
  - platform: ledc
    pin: GPIO26
    id: plafon_rgb_rojo

  - platform: ledc
    pin: GPIO27
    id: plafon_rgb_verde

  - platform: ledc
    pin: GPIO5
    id: plafon_rgb_azul

light:
  - platform: rgb
    name: "Aro Plafón Salón"
    id: plafon_aro_rgb
    red: plafon_rgb_rojo
    green: plafon_rgb_verde
    blue: plafon_rgb_azul

I have also could get the encryption_key of the yeelight YLKG08YL dimmer, following option 5 of the guide (get_beacon_key python script) and could add it to Home Assistant though ble_monitor integration.
What I can not find is any info about how to automaticethe dimming of the light using the YLKG08YL sensor..
Someone have an example?
thank you

I've been able to replace the Mediatek board with an ESP32 in YLXD02YL and almost everything is working but now I have flickering on low brightness (20%) on cwww light. If I set the temperature to 2700K or 6500K it doesn't flicker, just when both channels are mixed. I've tried different ledc frequencies but the behaviour is the same.
Does anyone know how to fix this?
Thanks

I've been able to replace the Mediatek board with an ESP32 in YLXD02YL and almost everything is working but now I have flickering on low brightness (20%) on cwww light. If I set the temperature to 2700K or 6500K it doesn't flicker, just when both channels are mixed. I've tried different ledc frequencies but the behaviour is the same. Does anyone know how to fix this? Thanks

Hi, I just finished replacing  the same model and it works fine. I used yeelight_light_ceiling20.yaml as template and wired the ESP32 according to this.
One thing I had to change (and I got stuck there for a while) was LEDC frequency. But it was not so easy:
I had this working quite fine, but night light was emitting strong audible noise. So I wanted to change the ledc frequency - Mediatek was running this at 20kHz (WW/CW at 10kHz) and esphome default is just 1kHz. So I changed it for the night light but it didn't help. It just limited my maximal brightness. Weird right? I checked it with oscilloscope and I was still getting only 1kHz with lower duty cycle.
I later discovered (and don't quote me on this) that you can't just have multiple different ledc frequencies.
More info here
So I changed the frequency to 20kHz (10kHz was still emitting some noise) for all channels (WW, CW, R, G, B, Night_light) and it started working just fine. Maybe something like this happens in your case aswell?

Maybe something like this happens in your case aswell?

Yes, that was the problem! I still had some flickering so I've set the frequency as yours (20kHz) and it works perfectly now!

I would like to collect the miIO model identifiers / mDNS names of the mediatek lamps above. Could somebody help here?

Hi, I have YLXD01YL, YLXD04YL and YLXD05YL.
YLXD01YL shows as yeelink.light.ceiling1
YLXD04YL shows as yeelink.light.ceiling3
YLXD05YL shows as yeelink.light.ceiling3
I am taking this info from Yeelight app, settings and info about device and it is shown there

Hi, I own a YLXD01YL.
I've read this thread carefully and I decided to try to modify it to run ESPHome but after modding it I experienced a problem.
This light will not be used as "always on/software off", in fact it will be turned on & off by a classic switch, cutting the live.
The problem is that when I turn it on (via the wall switch) it emits a very short and bright flash, then it goes to its default setting I set on the yaml, it's very annoying and I didn't find a solution, I thought at the standby/power pin, but it seems that nobody here is using it, I don't know if my model has one and if I should use it.
I used an ESP8266 (wemos d1 mini pro) because it's the only one with an antenna connector lying around, I don't think it should worst than an ESP32 in this application.
Some photos:

and this is my config:
#Variables
substitutions:
  device_name:  xiaomi-bagno
  friendly_name: Xiaomi Bagno

esphome:
  name: ${device_name}

  on_boot:
    priority: 600
    # ...
    then:
      - light.turn_off:
          id: night_light
      - light.turn_on:
          id: ceiling_light
          brightness: 70%
          color_temperature: 3600K

esp8266:
  board: d1_mini_pro

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "myKey"

ota:
  password: "myPwd"

wifi:
  ssid: mySSID
  password: myPwd
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${device_name} Fallback Hotspot"

captive_portal:

output:
  - platform: esp8266_pwm
    pin: GPIO14
    id: output_warm
    frequency: 10000Hz
    min_power: 0.07
    zero_means_zero: true

  - platform: esp8266_pwm
    pin: GPIO12
    id: output_cold
    frequency: 10000Hz
    min_power: 0.07
    zero_means_zero: true

  - platform: esp8266_pwm
    pin: GPIO15
    id: output_nightlight
    frequency: 10000Hz

light:
  - platform: monochromatic
    name: "${friendly_name} nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
    restore_mode: ALWAYS_OFF
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6500 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: on
    on_turn_on:
      - light.turn_off: night_light
    default_transition_length: 0s
    restore_mode: ALWAYS_ON

I tried different PWM values and it doesn't help.
default_transition_length doesn't help aswell
Any help on this?

Just did the conversion on my YLXD05YL. The light was flickering badly on Nightmode if the brightness was above 30%. That's completely gone now!
Used a 'naked' ESP-12E on one of these little breakout boards. No issue with software PWM so far. Thanks for all the work!
Desoldering the Mediatek chip is a PITA though. Needed to use a heatgun, since solder wick didn't seem to work.

Anyone managed to convert YLXD01YL? Could you share photos and esphome yaml please? I have few of these and would like to get rid if stock firmware.

Anyone managed to convert YLXD01YL?

Yeah I did about a year ago and still works great. I can't find any after photos but did find this one where I wrote down the pinouts. Process of replacing it is basically the same as with the other ones on here.

#Variables
substitutions:
  device_name: bedroom-light
  friendly_name: Bedroom

esphome:
  name: ${device_name}

esp32:
  board: esp32dev
  framework:
    type: arduino

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

logger:
api:
ota:
  password: !secret ota_password

external_components:
  - source: github://dentra/esphome-components

sensor:
  # Presence based on MAC address
  - platform: miot_ylyk01yl
    mac_address: !secret mi_remote_mac
    bindkey: !secret mi_bindkey
    on_click:
      # String (Required), The button name (case insensitive):
      #     on, off, dimmable or sun or moon, plus or +, moonlight or M, minus or -
      - button: "on"
        then:
          - logger.log: button ON click
          - light.turn_on: night_light
      - button: "off"
        then:
           - logger.log: button OFF click
           - light.turn_off: night_light
           - light.turn_off: ceiling_light
      - button: "+"
        then:
           - logger.log: button PLUS click
           - if:
              condition:
                light.is_on: ceiling_light
              then:
                - light.dim_relative:
                    id: ceiling_light
                    relative_brightness: 5%
                    transition_length: 0.1s
                - delay: 0.1s
           - if:
              condition:
                light.is_on: night_light
              then:
                - light.dim_relative:
                    id: night_light
                    relative_brightness: 5%
                    transition_length: 0.1s
                - delay: 0.1s
           - if:
              condition:
                - light.is_off: night_light
                - light.is_off: ceiling_light
              then:
                - light.dim_relative:
                    id: ceiling_light
                    relative_brightness: 5%
                    transition_length: 0.1s
                - delay: 0.1s

      - button: "-"
        then:
           - logger.log: button MIN click
           - if:
              condition:
                light.is_on: ceiling_light
              then:
                - light.dim_relative:
                    id: ceiling_light
                    relative_brightness: -5%
                    transition_length: 0.1s
                - delay: 0.1s
           - if:
              condition:
                light.is_on: night_light
              then:
                - light.dim_relative:
                    id: night_light
                    relative_brightness: -5%
                    transition_length: 0.1s
                - delay: 0.1s
      - button: "M"
        then:
           - logger.log: button MOON click
           - if:
              condition:
                light.is_on: ceiling_light
              then:
                - light.turn_off: ceiling_light
                - light.turn_on: night_light
           - if:
              condition:
                light.is_on: night_light
              then:
                - light.turn_off: night_light
                - light.turn_on: ceiling_light
      - button: "sun"
        then:
          - light.control:
              id: ceiling_light
              color_temperature: !lambda |-
                if(id(ceiling_light).remote_values.get_color_temperature()==167){
                  return 370;
                }
                else{
                  return 167;
                }
          - logger.log: button SUN click

output:
  - platform: ledc
    pin: GPIO19
    id: output_warm
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO21
    id: output_cold
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO22
    id: output_nightlight
    frequency: 9765Hz
    max_power: 0.92

light:
  - platform: monochromatic
    name: "${friendly_name} Nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    on_turn_on:
      - light.turn_off: night_light

for me it was important the remote kept working as well, so I used these 2 repos by dentra to help me with that. https://github.com/dentra/esphome-components/tree/master/components/miot_ylxx0xyl_pair https://github.com/dentra/esphome-components/tree/master/components/miot_ylyk01yl
If you don't want to keep bluetooth remote functionality you could just leave out the entire sensor part.
Hope this helps!

Thanks. I gave it a try, although other light shows 12 instead of 01, but pinout seems to be the same, so is the board.
When I power on the light, it does briefly (for 1/3 of second?) turns on and off, but then no reaction to any light operations from within HA.
I have soldered 5 pins in total (VCC, GND, cold/warm/night light). I have used GPIO9, 18, 19 on my ESP-C3-12F. ESP itself works ok, I can flash it wirelessly. But that's it.
Any clue?

I did go ahead and converted also YLXD01YL.
So the only thing that "bugs" me is that compared to stock yeelight FW, this one has slightly longer boot. I measured (+-) that stock takes 0,85 seconds to turn on after AC is switched on (i use relays in switches to shut it off) where this one takes about 1 second. Not big deal, but slightly noticeable.
I tried playing around with on_boot actions, priorities, default transition set to 0s - none of this makes any difference. I guess this is just the way it will be.
What is your experience - how long does it take to turn on after switched on @syssi @NopeFinder ?

Same here. My Yeelights are  always powered. I will prepare a test bench setup to reproduce the issue.

I have switched from ESP32 to ESP8266 (Wemos D1 Mini). Powering is now instant. The only issue is there is small flicker (like 3 blinks) upon powering it. Below is my config. I am saving preferences to flash every minute.
I did try on_boot automation, but even with high priority, light turned on with 100% brightness and 6000K, only after few seconds (way longer than previously on ESP32) it switched to set value (80% and 3000K). Also restore mode did not work the way it did on ESP32. So below config is something that works instantly, but I would like to see if anything can be done about those 3 short blinks upon turning power on:
#Variables
substitutions:
  device_name: kids-light
  friendly_name: Kids Light

esphome:
  name: ${device_name}
#  on_boot:
#    priority: 1200
#    then:
#      - light.turn_on:
#          id: ceiling_light
#          brightness: 80%
#          color_temperature: 3000K

esp8266:
  board: esp01_1m
  restore_from_flash : true

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "xxx"

ota:
  password: "xxx"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Kids-Light Fallback Hotspot"
    password: "xxx"

captive_portal:

output:
  - platform: esp8266_pwm
    pin: GPIO5 #D1
    id: output_warm
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: esp8266_pwm
    pin: GPIO4 #D2
    id: output_cold
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: esp8266_pwm
    pin: GPIO0 #D3
    id: output_nightlight
    frequency: 9765Hz
    max_power: 0.92

# Example usage in a light
light:
  - platform: monochromatic
    name: "${friendly_name} Nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    on_turn_on:
      - light.turn_off: night_light
    #restore_mode: RESTORE_AND_ON
    #restore_mode: ALWAYS_ON
    #default_transition_length: 0s

preferences:
  flash_write_interval: 1min

I guess you can fix the flickering if you don't use GPIO0 for the nightlight because GPIO0 is enabled/pulled high on boot (cp. https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/). Please try GPIO14 (D5) or GPIO12 (D6) instead.

Thank you @syssi , it was indeed due to this. I moved night light to GPIO14 (D5) and the issue is gone. Now it is almost perfect. The only thing that still happens is - when I power it on via AC, for a very brief moment, it looks like it starts dimmed (or night light starts) and then immediately goes to desired (either restored from flash, or set on boot) color/brightness (with or without transition, depending on how it is set). This isn't as annoying as 1 second delay or flicker, but still - maybe i am just missing something. Below is my config with omitted unnecessary piece of code:
#Variables
substitutions:
  device_name: kids-light
  friendly_name: Kids Light

esphome:
  name: ${device_name}
  on_boot:
    then:
      - light.turn_on:
          id: ceiling_light
          brightness: 90%
          color_temperature: 3100K

esp8266:
  board: esp01_1m
#  restore_from_flash : true

output:
  - platform: esp8266_pwm
    pin: GPIO5 #D1
    id: output_warm
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: esp8266_pwm
    pin: GPIO4 #D2
    id: output_cold
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: esp8266_pwm
    pin: GPIO14 #D5
    id: output_nightlight
    frequency: 9765Hz
    max_power: 0.92

# Example usage in a light
light:
  - platform: monochromatic
    name: "${friendly_name} Nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    on_turn_on:
      - light.turn_off: night_light
    #restore_mode: RESTORE_AND_ON
    #restore_mode: ALWAYS_ON
    default_transition_length: 0s

preferences:
  flash_write_interval: 1min

I had a chance to do few more tests. It looks like that it is night light that gets triggered for a split second on the boot. If I disconnect GPIO pin that connects the night light, it is not happening.
I have tried D5, D6 and D7 and all behave the same.
Any idea why?

If you play with the idea to add a resistor please double check the LED driver board is probably already equipped with a pull-down/pull-up resistor. Please don't destroy your driver board while tinkering!

I am not sure my skills are good enough to try that. I rather disconnected the night light completely for now as I barely used it anyway.
However I would be willing to try if I knew exactly what and how :)

Same here. I don't want to instruct you to do dangerous things where I am not 100% sure they are a good idea.

I will give it a try and try various esp32 or esp8266. I am reading that this may be just the thing for wemos, and others (even clones) may behave differently. So i ordered a few and will report back.

@avion23 Do you like to add your 5 cents of a professional here?
Short summary: This picture describes what we have done: https://user-images.githubusercontent.com/19818061/211223563-126fef62-f918-4a00-a9bb-7778376285ed.jpeg
We've replaced a Mediatek microcontroller with an ESP8266. The ESP is attached to a LED driver board and the three colors (RGB) can be controlled using PWM. A fourth PWM signal is used to control a subset of the LEDs as nightlight.
The issue: The nightlight flickers on boot-up of the ESP. I assume the output pin of the ESP is floating and causes the flicker. How can we make sure the LED driver isn't equipped with a pull-up/pull-down already? If the resistor is missing I would like to add one to pull the line to a logic level to "turn/keeping off the nightlight if there is no PWM signal".

It is recommended to use a pullup or pulldown resistor in this application. Based on the assumption that the lines switch an N-Channel MOSFET, it is appropriate to use a pulldown resistor. This is based on my assumption that a high output from the ESP8266 results in the light being turned on. A resistor value in the range of 10k Ohm to 100k Ohm should be suitable.
To provide mechanical isolation of the solder joints, consider applying a small amount of adhesive to the lines.

@stomko11 I've found this article on reddit today: https://static.xtremeownage.com/blog/2023/esphome-on-critical-infrastructure/
It mentions early_pin_init: false. You could give this setting a try too.
https://static.xtremeownage.com/blog/2023/esphome-on-critical-infrastructure/
https://esphome.io/components/esp8266.html

@syssi this works on switch only, not on pwm. So I would not be able to adjust code to make things work.

I had a chance to do few more tests. It looks like that it is night light that gets triggered for a split second on the boot. If I disconnect GPIO pin that connects the night light, it is not happening. I have tried D5, D6 and D7 and all behave the same. Any idea why?

GPIO4 and GPIO5 are the only pins on the ESP8266 that are always high impedance and do not float during boot. I'd test those if I were you. Will start to play with my YLXD01YLs myself in the coming days.

I did, however you need 3 PINs - night light, warm white, cold white.

I did, however you need 3 PINs - night light, warm white, cold white.

The setup below works fine for me. One of the pins not being on GPIO4, GPIO5, or GPIO15 leads to a short flash of the respective color during boot.
ESP8266 D1 mini clone
GPIO4: WW
GPIO5: CW
GPIO15: Nightlight

It is that flash that annoyed me on esp2866. And delay on esp32 (got used to it)

It is that flash that annoyed me on esp2866. And delay on esp32 (got used to it)

The flash is gone if you use those three pins on the esp8266.
Here's an explanation for the flashes during boot if other pins are used:
https://rabbithole.wwwdotorg.org/2017/03/28/esp8266-gpio.html

Tell me why, when I turn off the light, the lamp does not go out evenly?
`output:

platform: ledc
pin: GPIO19
id: output_warm
frequency: 4882Hz
min_power: 0.07
max_power: 0.92
zero_means_zero: true

platform: ledc
pin: GPIO21
id: output_cold
frequency: 4882Hz
min_power: 0.07
max_power: 0.92
zero_means_zero: true

platform: ledc
pin: GPIO23
id: output_nightlight
frequency: 9765Hz
max_power: 0.92

light:

platform: monochromatic
name: "${board_name}_nightlight"
id: night_light
output: output_nightlight
gamma_correct: 0
on_turn_on:

light.turn_off: ceiling_light

platform: cwww
name: "${board_name}"
id: ceiling_light
cold_white: output_cold
warm_white: output_warm
cold_white_color_temperature: 6000 K
warm_white_color_temperature: 2700 K
gamma_correct: 0
constant_brightness: true
on_turn_on:

light.turn_off: night_light
-`

Tell me why, when I turn off the light, the lamp does not go out evenly?

Tell me why, when I turn off the light, the lamp (YLXD17YL) does not go out evenly? Cold&Warm 50/50 https://youtu.be/jaf6tGkBfgs Cold&Warm 0/100 https://youtu.be/ibINSGMekM0 Cold&Warm 100/0 https://youtu.be/JFTfzDFalsA
output:
  - platform: ledc
    pin: GPIO19
    id: output_warm
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO21
    id: output_cold
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO23
    id: output_nightlight
    frequency: 9765Hz
    max_power: 0.92

light:
  - platform: monochromatic
    name: "${board_name}_nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${board_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    on_turn_on:
      - light.turn_off: night_light

Solved the problem by adding
gamma_correct: 0.4
default_transition_length: 200ms

I converted YLXD01YL - thx! I tore out this "Mediatek" chip with a regular soldering iron, losing a few pads, but fortunately they were unimportant (butcher) :P

Everything works, but... in cwww mode, when the brightness is set to 1-30%, flickering occurs. This problem does not occur in "nightlight" mode. I tried different frequencies (9765Hz/20000Hz) but I didn't see any changes. Anyone have an idea how to fix this?
My yaml:
#Variables
substitutions:
  device_name: komputerowy-yeelight-ceiling
  friendly_name: komputerowy-yeelight-ceiling

esphome:
  name: ${device_name}
  friendly_name: komputerowy-yeelight-ceiling

esp32:
  board: esp32dev
  framework:
    type: arduino
#  framework:
#    type: esp-idf
#    version: recommended

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "XXXX"

ota:
  password: "XXXX"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

#do pilota
#external_components:
#  - source: github://dentra/esphome-components

output:
  - platform: ledc
    pin: GPIO19
    id: output_warm
#    frequency: 9765Hz
#    frequency: 20000Hz
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO21
    id: output_cold
#    frequency: 9765Hz
#    frequency: 20000Hz
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO22
    id: output_nightlight
    frequency: 9765Hz
#    frequency: 20000Hz
    max_power: 0.92

light:
  - platform: monochromatic
    name: "${friendly_name} Nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    on_turn_on:
      - light.turn_off: night_light

external_components:
  - source: github://dentra/esphome-components

sensor:
  # Presence based on MAC address
  - platform: miot_ylyk01yl
    mac_address: "XXXX"
    bindkey: "XXXX"
    on_click:
      # String (Required), The button name (case insensitive):
      #     on, off, dimmable or sun or moon, plus or +, moonlight or M, minus or -
      - button: "on"
        then:
          - logger.log: button ON click
          - light.turn_on: night_light
      - button: "off"
        then:
           - logger.log: button OFF click
           - light.turn_off: night_light
           - light.turn_off: ceiling_light
      - button: "+"
        then:
           - logger.log: button PLUS click
           - if:
              condition:
                light.is_on: ceiling_light
              then:
                - light.dim_relative:
                    id: ceiling_light
                    relative_brightness: 5%
                    transition_length: 0.1s
                - delay: 0.1s
           - if:
              condition:
                light.is_on: night_light
              then:
                - light.dim_relative:
                    id: night_light
                    relative_brightness: 5%
                    transition_length: 0.1s
                - delay: 0.1s
           - if:
              condition:
                - light.is_off: night_light
                - light.is_off: ceiling_light
              then:
                - light.dim_relative:
                    id: ceiling_light
                    relative_brightness: 5%
                    transition_length: 0.1s
                - delay: 0.1s

      - button: "-"
        then:
           - logger.log: button MIN click
           - if:
              condition:
                light.is_on: ceiling_light
              then:
                - light.dim_relative:
                    id: ceiling_light
                    relative_brightness: -5%
                    transition_length: 0.1s
                - delay: 0.1s
           - if:
              condition:
                light.is_on: night_light
              then:
                - light.dim_relative:
                    id: night_light
                    relative_brightness: -5%
                    transition_length: 0.1s
                - delay: 0.1s
      - button: "M"
        then:
           - logger.log: button MOON click
           - if:
              condition:
                light.is_on: ceiling_light
              then:
                - light.turn_off: ceiling_light
                - light.turn_on: night_light
           - if:
              condition:
                light.is_on: night_light
              then:
                - light.turn_off: night_light
                - light.turn_on: ceiling_light
      - button: "sun"
        then:
          - light.control:
              id: ceiling_light
              color_temperature: !lambda |-
                if(id(ceiling_light).remote_values.get_color_temperature()==167){
                  return 370;
                }
                else{
                  return 167;
                }
          - logger.log: button SUN click

  - platform: miot_ylkg0xyl
    # String (Required), device MAC-address.
    mac_address: "XXXX"
    # String, (Optional), device bind key. Will use "xiaomi_account" from "miot" if absent to automaticaly get the bindkey.
    bindkey: "XXXX"
    # List, Automation (Optional), The automation activated when you make specified action
    on_short_press:
      # List, Any automation
      - then:
          - logger.log:
              format: knob was short pressed %u times
              args: ["x"]
          - if:
             condition:
               and:
                 - light.is_off: night_light
                 - light.is_off: ceiling_light
             then:
               - light.turn_on: night_light
#          - if:
#             condition:
#               light.is_on: ceiling_light
#             then:
#               - light.turn_off: ceiling_light
#               - light.turn_on: night_light
          - if:
             condition:
               light.is_on: ceiling_light
             then:
               - light.turn_off: ceiling_light
          - if:
             condition:
               light.is_on: night_light
             then:
               - light.turn_off: night_light
               - light.turn_on: ceiling_light
    on_long_press:
      - then:
          - logger.log: knob was long pressed
          - light.turn_off: night_light
          - light.turn_off: ceiling_light
    on_rotate_left:
      - then:
          - logger.log:
              format: knob was rotating left on %u
              args: ["x"]
          - if:
             condition:
               light.is_on: ceiling_light
             then:
               - light.dim_relative:
                   id: ceiling_light
                   relative_brightness: -15%
                   transition_length: 0.1s
               - delay: 0.1s
          - if:
             condition:
               light.is_on: night_light
             then:
               - light.dim_relative:
                   id: night_light
                   relative_brightness: -15%
                   transition_length: 0.1s
               - delay: 0.1s
    on_rotate_right:
      - then:
          - logger.log:
              format: knob was rotating right on %u
              args: ["x"]
          - if:
             condition:
               light.is_on: ceiling_light
             then:
               - light.dim_relative:
                   id: ceiling_light
                   relative_brightness: 15%
                   transition_length: 0.1s
               - delay: 0.1s
          - if:
             condition:
               light.is_on: night_light
             then:
               - light.dim_relative:
                   id: night_light
                   relative_brightness: 15%
                   transition_length: 0.1s
               - delay: 0.1s
          - if:
             condition:
               - light.is_off: night_light
               - light.is_off: ceiling_light
             then:
               - light.dim_relative:
                   id: ceiling_light
                   relative_brightness: 15%
                   transition_length: 0.1s
               - delay: 0.1s
    on_rotate_left_pressed:
      - then:
          - logger.log:
              format: knob was pressed and rotating left on %u
              args: ["x"]
    on_rotate_right_pressed:
      - then:
          - logger.log:
              format: knob was pressed and rotating right on %u
              args: ["x"]

Replaced MTK board with ESP32-WROOM-32UE and it worked perfectly, however i needed to change pwm frequency for night light pin to 19531Hz, because it produced audible whining noise on 4882Hz and 9765Hz.

I am very late to the party, but I have successfully replaced mediatek with ESP32-C3  SuperMini. Haven't tried yet to connect dimmer. So far works seamless except dificulties to set ambient light to warm light (pure red/gree/blue works perfectly though).
Just in case, attaching my configuration. Which is a composition from configurations posted previously with adaptation for c3 SuperMini, and some minor additions like turn on light on power restore.
#Variables
substitutions:
  device_name: bedroom-light
  friendly_name: Bedroom

esphome:
  name: ${device_name}
  friendly_name: ${device_name}

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: arduino

# Enable Home Assistant API
api:
  encryption:
    key: ""
logger:

ota:
  password: ""

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${device_name} Fallback Hotspot"
    password: !secret wifi_ap_password

captive_portal:

output:
  - platform: ledc
    pin: GPIO00
    id: output_warm
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO01
    id: output_cold
    frequency: 4882Hz
    min_power: 0.07
    max_power: 0.92
    zero_means_zero: true

  - platform: ledc
    pin: GPIO02
    id: output_nightlight
    frequency: 9765Hz
    max_power: 0.92

  - platform: ledc
    pin: GPIO05
    id: rgb_red

  - platform: ledc
    pin: GPIO06
    id: rgb_green

  - platform: ledc
    pin: GPIO7
    id: rgb_blue

light:
  - platform: monochromatic
    name: "${friendly_name} Nightlight"
    id: night_light
    output: output_nightlight
    gamma_correct: 0
    restore_mode: ALWAYS_OFF
    on_turn_on:
      - light.turn_off: ceiling_light
  - platform: cwww
    name: "${friendly_name}"
    id: ceiling_light
    cold_white: output_cold
    warm_white: output_warm
    cold_white_color_temperature: 6000 K
    warm_white_color_temperature: 2700 K
    gamma_correct: 0
    constant_brightness: true
    restore_mode: ALWAYS_ON
    on_turn_on:
      - light.turn_off: night_light
  - platform: rgb
    name: "${friendly_name} Ambient"
    id: ambient_light
    red: rgb_red
    green: rgb_green
    blue: rgb_blue

Why do you use these two settings, especially for ESP8266?
min_power: 0.07
max_power: 0.92

@rufik It should act like a calibration of the brightness setting. Let's assume the LED goes off if you set the brightness to 5% or the LED doesn't get brighter for values above 90% you can adjust here. The second idea is to replicate the behaviour (voltage levels) of the OEM firmware.


createActionPack

createActionPack it's like createAction from redux-actions (see README)

I'm kinda just jumping in here, but as a consumer of this middleware, I wonder is this layer of abstraction even necessary? What's the key advantage here that makes this a must-have, and not just a neat addition?
Would this let you create multiple actions at once with one call to createActionPack like with redux-actions? e.g.
const { increment, decrement } = createActions({
  INCREMENT: (amount = 1) => ({ amount }),
  DECREMENT: (amount = 1) => ({ amount: -amount })
});

If so, I can see this being nice, although it doesn't really look like it. Anyway, just curious, I think this package is great, and if its a definite improvement, that's awesome, just wondering what exactly the key takeaway is.


How can I install the latest version of Typescript without Internet (offline)?

I have Internet connection in my home and I can install the latest version of TypeScript with this command: npm install -g typescript , But unfortunately There is no Internet at my work place (in fact we are not allowed to use Internet , I know its  embarrassing!! )
Beside this I googled But It seems There is no offline installer for Typescript. My question is how can I handle this problem ?
I am totally new to npm and a step by step workaround would be so appreciated .

GitHub isn't quite the place for Q&A, but to answer your question...
When at home, making sure you don't already have a node_modules folder, type
npm i typescript
Then copy the entire node_modules folder to a flash drive and copy to your work machine. To install it on your work machine, you can just copy it to the destination and invoke Typescript through node. You can also create a .sh or .bat file (depending on platform/terminal) in a globally accessible directory that runs node node_modules/typescript/bin/tsc so you can use tsc from the command line globally.

You can also download from the Releases page (though all of those include the tests, source code, etc).
There's also other mechanisms like npmbox though I've never tried that.

@sia-git could you tell me a little bit more about what your workplace's restrictions are? For example, can you bring in a USB drive? Do you have an internal npm mirror? Bringing in @bowdenk7.

@cliffkoh
Hi and thanks for your response
I know GitHub isn't quite the place for Q&A , But really I couldn't find a reference about my problem ,
anyway , I think, offline installation could be an important issue for many people and should be  handled.
could you please elaborate this part of your answer that was about creating a .bat file ? what is your mean by a global access directory in windows Os ?
@DanielRosenwasser
yes I can use a USB drive at my work place  , But we have not an internal npm mirror .
I have no idea  how its possible to create that ?

@sia-git You should be able to find the .bat file at node_modules/.bin/tsc.bat. One way to make it globally accessible is to add it to the PATH environment variable.

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


Error -1007 after/during login in BrowserForm

Any clue or any idea what to do to further debug ?

that means the account has not yet accepted the terms of service, you need to accept the terms of service from official launcher before able to use this one

Is it possible to accept them from the website ?
As the launcher is full black since I'm on Linux I have no idea how I can accept those terms without seeing the accept button
Maybe the only is to have a Windows machine on which I accept them.

you might be able to accept the TOS from the launcher URL

Thanks !

I tried to but when logging in it is saying to me that I cannot login in that region, it must be default on other than the EU/NA region.

Logging in works, but I don't see any terms to accept

are you using a new account? that's never started the game before? I think the terms page only shows up when you click start game button

No it's a very old account I used first in 2021, I did reactivate the account when I logged in first, it was scheduled to be deleted in 2026.

can you play the game when logging in from the official?

I haven't tried this as the launcher on Linux is full black, the bug has been fixed but the fix upstream hasn't been released in Proton or any official Wine release yet.

Closed due to inactivity