[Solved] Pin identification on T34 and CB3S W601 models - how to identify TX/RX/VCC/GND?

Gee, hands are falling off.... I bought a set of switches I specifically indicated that I wanted this model and got....mix!

From the outside and functionally seem to be the same, but so what if the inside is again different Curses do not even know what they trade.

Please to the masters @pkaczmare2 and @krzbor for help, because I do not know enough to say which pins are TX/RX/VCC/GND, especially since one of the models has only 4 of them. Can it be treated with Tasmota also?

Here is the module designation CB3S W601 and only 4 pinouts



And here even better, because it is mysterious:
T34
2133K9T4J
X10LUC




Help Gentlemen pliiizzz.

On these devices you can upload OpenBeken , which supports:

Quote:

- BK7231T (WB3S, WB2S, WB2L, etc)
- BK7231N (CB2S, CB2L, WB2L_M1, etc)
- T34 (T34 is based on BK7231N)
- BL2028N (BL2028N is a Belon version of BK7231N)
- XR809 (XR3, etc)
- BL602 (SM-028_V1.3 etc)
- LF686 (flash it as BL602)
- W800 (W800-C400, WinnerMicro WiFi & Bluetooth), W801
- W600 (WinnerMicro chip), W601 (WIS600, ESP-01W, TW-02, TW-03, etc)
- LN882H WIP platform, see sample device teardown and flashing

ra_dzik wrote:

Here is the module designation of the CB3S W601. and only 4 pinouts

CB3S is BK7231N. The leads for programming are compatible with WB3S and TYWE3S. You can solder four wires (ground, 3.3V, RX and TX) and upload the OBK, here flasher:
https://github.com/openshwprojects/BK7231GUIFlashTool
Similar to here, only you select BK7231N in the flasher:


Before programming. programming watch the entire video

ra_dzik wrote:

And here it gets even better, because it is mysterious:
T34
2133K9T4J
X10LUC

T34 is also supported by OBK, you program it as BK7231N.

To program you have to solder four wires (RX,TX, 3.3V and GND), just not sure where to solder them. But there are 4 soldering points on the board...
I suggest using the method of elimination.
1. check where the ground goes from the mother board, probably the ground has a large copper pad, this pad which is connected to it will be ground, GND
2. then you look for 3.3V, you can find it on the other pole of the capacitor which is between 3.3V and ground or look where from the other board 3.3V is connected, but by eye I can already see that probably 3.3V is here:

3. then there are 2 points left and there's the question which is TX and which is RX - but that's only two options, I'd try randomly connecting RX and TX first and then if the flasher doesn't move, I'd swap them places and that's it....


Of course, this is only an abbreviated version, as I assume you are familiar with the BK7231 programming procedure in general, and especially with:
- our tutorials here: https://www.youtube.com/@electrodacom/videos
- the flasher's readme: https://github.com/openshwprojects/BK7231GUIFlashTool
- the list of device interiors: https://openbekeniot.github.io/webapp/devicesList.html

PS: the information about bkWriter 1.60 and hid_download_py is a bit outdated, it is now recommended to use the BK7231GUIFlashTool .

(sorry for the English reply)
I also have a T34 on a 1CH WiFi smart switch and identified a bunch of pins that seem to be GND or 3.3V. Any hunch what would be good candidates for the TX/RX pins?

ra_dzik wrote:

Shucks, my hands are falling off.... I bought a set of switches I specifically indicated I wanted this model and got....mix!

This is why I think that if someone wants to do a smart home with more devices, it's better to give up WiFi and go for ZigBee. I've done an article on PHP-based automation Link , but I recommend you read the first two paragraphs where my opinion is why ZigBee and not WiFi.

@rumpeltux I have never seen such a switch before. It seems that RX/TX is not routed out anywhere, but you can check:
https://developer.tuya.com/en/docs/iot/t34-module-datasheet?id=Ka0l4h5zvg6j8 maybe you can access somehow pins of the case?

@krzbor everything has pros and cons, I prefer when the devices are available and controllable also when the main Home Assistant server is not available, as well as I use the communication directly between the devices (without the participation of HA), I do not like such a centralization that one hub is responsible for everything, but nevertheless I see that the solution presented by you is in some respects very simple and convenient.

>>20942489
Cute thanks!

So here it's not possible to upload any Tasmota only OBK I have to? Gee, I wouldn't want another platform....

OBK is compatible with a large proportion of Tasmota commands, it is compatible with Tasmota Device Groups:

and it is compatible with Tasmota's JSON format, so also with apps from Tasmota:


With Home Assistant you also connect easily:
.

p.kaczmarek2 wrote:

I don't like such centralisation that one hub is responsible for everything

I agree - I am against integration of everything based on HA. If something goes wrong (e.g. HA or hardware failure) then we lose everything including e.g. heating. Therefore, in my opinion, it is best if we have a dedicated computer with MQTT - such an RPi will suffice. Once the MQTT configuration is stabilised, we make a copy of the SD card on the desktop computer, and additionally make a clone of this card necessarily with a check that the clone works. We have a good chance that such a thing without any update will work for 10 or even more years. A possible failure is also easy to reproduce - after all, there is no data on the MQTT server to automate. Instead of the point-to-point communication you mentioned, we can do point->MQTT->point automation. This won't compromise reliability, plus it will allow integration of points made with different technologies: Ethernet, WiFi, ZigBee. Here's an example - we're doing floor control. We can build our own actuator controller based on WiFi or Ethernet, which will have its own logic, but the room temperatures will be taken from the ZigBee sensors installed in each room. In addition, this default control logic can be modified by appropriate MQTT messages sent from the HA, for example. If the HA 'dies' the system will operate autonomously on its parameters.

>>20943871

Respectful @p.kaczmarek2 well I with all due respect wanted to buy a coffee, but this forum does not support blik, only, some American (haaa tfuuu) PayPal, I ask the moderation to expand the forms of payment, and the esteemed gentleman to provide an account number for a symbolic coffee.

Thank you very much, write me a PW and I will give you the details. The paypal comes from the fact that the whole initiative of making IoT comes mainly from the great interest of people from abroad on the English-language Elektroda website. It is also worth looking there sometimes, the community is very active:
https://www.elektroda.com/
And the funds raised go to further development of the firmware including support for further platforms.

>>20942489 Well, I've got quite a bundle with it in the version with CB3S - it requires soldering the chip or, as I saw on some video, the chip next to it, because otherwise you can't program CB3S, because this chip next to it blocks I unfortunately don't have such a skill, to solder one of these two and not break anything I tried without soldering, but it says that it cannot communicate with the chip
Is there any way to do this?

With the T34 version - the chip has the leads underneath the chip, you can't see the legs on the side, so geez I can't identify which lead is RX and which is TX, even though on the datasheet it is described as pins 25 and 26, the tracks go from under the chip and I don't know exactly how to identify this

Any ideas? Help colleagues.

If you have devices which are not listed here:
https://openbekeniot.github.io/webapp/devicesList.html
Have packaging for them (for pictures), and screenshots of where they were bought, and you are able to cover shipping both ways then I can personally flash them, but free flashing I offer only for one piece of each model because by the way I make a teardown entry on the forum. For larger quantities a contractual issue.

Additionally, as it happens with flashing, I can never give 100% certainty that a device will run until I try it myself.

ra_dzik wrote:

Well, I've got quite a bite out of that with the CB3S version - it requires soldering out the chip, or as I saw on some video, the chip next to it, because otherwise you can't program the CB3S, because the chip next to it blocks I unfortunately don't have that kind of skill, to unsolder one of these two and not break anything I tried without unsoldering, but it says that it can not communicate with the chip
Is there any way to do this?

Check with a multimeter where this path goes from RX or there TX and find a place convenient to cut it temporarily.
I have also seen that some people use OTA flashing, but it is per-build (i.e. until someone downloads 2MB of batch from one of the devices of a given series, it will not flash the others).

Mate @krzbor actually had some other idea for it, but I haven't tried it myself and I don't know if it will work

ra_dzik wrote:

With the T34 version - the chip has the leads under the chip, you can't see the feet on the side, so geez I can't identify which lead is RX and which is TX, despite the fact that on the datasheet it is described as pins 25 and 26, the tracks go from under the chip and I do not know exactly how to identify it

As I wrote - as long as these 2 pads are RX and TX then you can forcefully, by trial and error guess. You determine VDD (e.g. from the mother board), determine where the ground is, then you are left with two options, if it doesn't move then you swap RX and TX and then it must move.

Worse, if it's not RX/TX at all, then it's a very hard situation.

Colleagues have helped with their expertise.

Thank you very much.