Replies: 2 comments 1 reply
-
I think you answered your own question with the steps you take to see the bulbs in the app... |
Beta Was this translation helpful? Give feedback.
-
I misspoke on the device brand, it is a Globe Electric PAR20 RGB WiFi smart bulb. FCC page here In my case, the tuya rebranded light uses a belken - BK7231Txxx chip. This chip has OSS firmware that is a replacement for tasmota/esphome on these belken and other chips. It requires desoldering/soldering and flashing the chip but, at least, it is doable. I cant find ANY information on how to interface with these types of tuya lights requiring BLE wake packets. Most Tuya BLE devices are added into tuya cloud and have UUID's and such. In my case, the BLE MAC is 1 digit incremented from its Wi-Fi MAC, i.e.: WiFi MAC: d8:1f:12:f4:85:0b There is a Tuya-BLE HASS integration that can see and attempt to configure these bulbs. But, it fails on scanning the Tuya cloud because the bulb was added as a wifi device, and the BLE part of the bulb is not registered in Tuya cloud. The library is more for devices like fingerbot, etc. I have not explored if I can modify that library to try and communicate with the BLE part of the bulb using the WiFi devices encryption key. So far, there doesn't seem to be a way to connect to these bulbs using BLE to wake them easily. I am going to attempt to flash the custom firmware onto a bulb and see if it works properly. I can backup the original firmware so, if anything goes wrong I can always go back to base. Here is an example video of a teardown, desoldering, flashing and resoldering of a christmas light style smart bulb using Belken bk7231n chip -> https://www.youtube.com/watch?v=2e1SUQNMrgY&list=PLzbXEc2ebpH0CZDbczAXT94BuSGrd_GoM&index=4 |
Beta Was this translation helpful? Give feedback.
-
I know there are a couple fo other discussions about this issue but they have no solutions. I opened an issue and it was closed immediately so here I am. Ive done basically everything I can do to solve this issue and it is still persisting. The only idea I have left is that there is some sort of magic packet to wake the device before it accepts commands.
I have 6 MEOS (tuya rebranded) colour Wi-Fi PAR20 bulbs. I have set them up with Tuya Local, The 6 bulbs are in an IoT VLAN with no access to DNS or internet. The bulbs cannot make any network requests at all but, any LAN devices can talk to the bulbs (so HASS can send them commands).
So here is a typical scenario, the bulbs will show as “Unavailable” in HASS. I open the tuya smart android app, enable Bluetooth and the app can see bulbs (bulbs were added to tuya smart app in the beginning to get device keys). If I toggle the bulbs using the tuya app, all of a sudden the bulb becomes available to HASS. I can control the bulb from HASS for a bit but, eventually, the bulb goes unavailable again until I use the tuya smart life app to toggle it.
This is why I think there is some sort of wake word, the tuya app can wake the bulb and only then can HASS see the bulb. I know the tuya devices have a 1 TCP connection limit, I force stop close the tuya smart life app after toggling all bulbs so HASS can control them for a short time.
I am assuming this must be a quirk specific to the MEOS bulbs, or possibly just newer iterations of the tuya firmware. All bulbs are either 3.4 or 3.5 protocol. localtuya does not support 3.5 yet, so I am using Tuya Local.
I have live viewed my firewall logs to make absolutely certain that the tuya bulbs have 0 access to anything. The FW is stateful, so if a LAN device send s a request to a tuya bulb, the tuya bulb can reply to the asking host. When HASS actually sees the bulbs, it can control them no problem, so it's deff some sort of unknown issue going on.
Any insight would be great, I'm at my ropes end trying to enjoy tuya devices locally, it's a 5-minute operation to control the bulbs from HASS.
Beta Was this translation helpful? Give feedback.
All reactions