Zupełnie nie na temat, ale masz rację - tak się dzieje, wynika to ze sposobu parowania tych żarówek z chmurą (a konkretnie wykrywania ich przez aplikację mobilną w sieci przez SSDP), problem który wspomniałeś można obejść wyłączając sieć WiFi 5GHz w telefonie (chodzi o to, że telefon i urządzenia IoT muszą być na tym samym Access Poincie = w tym samym fizycznym segmencie sieci by parowanie się udało) oczywiście można wyłączyć AP 5GHz. Ten sam numer mamy gdy obie sieci (2.4 i 5GHz) mają ten sam SSID - zdecydowana większość smartfonów preferuje połączenie 5GHz - rozwiązanie tak samo: albo wyłączasz 5GHz w telefonie albo AP.
Czasem idealnie identyczne objawy daje izolacja klientów bezprzewodowych na AP (musi być wyłączona, w przeciwnym razie 2 klienty sieci bezprzewodowej, którymi są telefon i żarówka czy tam jakiś inny IoT nie będą mogły się porozumieć, to jest tak swoją drogą ustawienie typowo “hotelowe/korporacyjne” i w domu odradzam, bo rodzi tylko takie właśnie problemy).
To akurat nie zależy za bardzo od producenta sprzętu i zdarza się na sprzęcie niemal dowolnego producenta.
Chciałbym powiedzieć “podziękujmy Tuya”, ale inni producenci sprzętu IoT (o dziwo są tacy 
) też często stosują podobne rozwiązania i powstają z tego identyczne problemy, bo mają to samo podłoże (chociaż znam i takich, którzy potrafili się ogarnąć z parowaniem bez konieczności używania apki mobilnej i wtedy taki problem nie istnieje).
Ale powyższe z tym wątkiem nie ma wiele wspólnego - po prawidłowym skonfigurowaniu WiFi to specyficzne firmware ESP połączy się ze wskazaną siecią 2.4GHz, a co dalej to już zupełnie inna kwestia.
Będą logi = będziemy myśleć.
OFF TOPIC
Swoją drogą mamy taki standard (którego “sprawcami” są autorzy HA i ESPHome) umożliwiający konfigurację WiFi innymi metodami (szkoda, że nie jest zaimplementowany w tym projekcie) m.in. za pomocą połączenia szeregowego, dzięki któremu mamy tu wykorzystywaną “konsolę”
