-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tuya bsd plug #6731
Add tuya bsd plug #6731
Conversation
Does the |
Note to self; after this merge Koenkk/zigbee2mqtt.io#2419 |
no, they don't thus the reason to set it to plug3. At least energy, immediate power, and voltage are shown properly with plug_3. Also on plug 1 I had these in logs
on plug_3 only
Maybe later I get Tuya gateway for debugging and getting proper data points. for now plug_3 works better for sure. |
Thanks! |
According to @smart-ctrl polling is not needed for this device (so TS011F_plug_1 should be fine). I think it is not working for your plug because of See this on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files. |
This pull breaks the fix from Koenkk/zigbee2mqtt#20028 that was merged into v16.10.0. My _TZ3000_okaz9tjs plugs are now detected as BSD33_20A (aka TS011F_plug_3, polling) instead of TS011F_plug_1 (no polling). The symptoms in #6731 (comment) are consistent with the current non-dev branch, which does not have the proper check yet. Mine were working fine without polling in v16.10.0, v16.11.0 and v16.12.0. I am pretty sure the above versions should work for you as well @bullmastiffo, or if you're not on the dev branch this external converter should make the plugs work correctly for you. Otherwise it must mean these are different plugs with the same vendor and appversion, which I guess is a problem in itself. |
I'll try to grab logs and check out the external converter shortly. Then we will see how to proceed. Otherwise feel free to rollback for now. |
@DataGhost , thank you for pointing out! I've tested with your external converter, it works as expected. only same problem with magic packet, I will try to get the logs for that later. @Koenkk, So what is the best way forward? Should I just prepare the rollback PR? Shall I move the white label for BSD33_20A to plug_1 or just let it be detected as is? |
@Koenkk , so logs from initialization.
|
@bullmastiffo I've reverted the PR for now, can you provide some more logging what comes after this? |
|
@DataGhost can you provide the debug log when configuring your plug? I think: |
@Koenkk hope this helps. It's from latest-dev (1.34.0-dev 27ccd1a with 16.15.0) not running any external converters.
|
In your case the tuya configureMagicPacket also fails, so that's probably not the issue. @bullmastiffo did you already check with the latest dev which includes the fix from @DataGhost |
I've checked with latest dev, it's same with external converter, everything seems to work (current, voltage, power reporting via plug_1). Magic packet still fails.
|
@bullmastiffo great, you can ignore the failed magic packet thing |
@bullmastiffo @DataGhost some more users are experiencing issues with energy measurements (power/voltage and current work). Do energy measurements work when detected as TS011F_plug_1? |
@DataGhost reverted it! |
@Koenkk cool, will re-test as soon as the new docker image is up but it should probably just work. |
@Koenkk Confirmed this fixes my plugs again. These sure must be fun to support, huh :) I'd help out a bit with the new |
Yet another version of tuya plug with energy polling. (On default plug
TS011F_plug_1
energy is not available. plug_3 seems to work ok)device row in database: