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
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....
(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?
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.
@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.
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.
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
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.
The discussion revolves around identifying the TX, RX, VCC, and GND pins on the CB3S W601 and T34 models, particularly after the user received incorrect switches. The CB3S W601 is identified as using the BK7231N chip, which can be programmed with OpenBeken (OBK) firmware. Users suggest soldering four wires (GND, 3.3V, RX, TX) for programming, with advice on locating these pins through methods of elimination. The T34 model is also compatible with OBK, but users express difficulty in identifying the correct pins due to their placement under the chip. Some users recommend using a multimeter for tracing connections and mention the possibility of OTA flashing. The conversation also touches on the preference for ZigBee over WiFi for smart home devices due to reliability concerns. Summary generated by the language model.
Curses do not even know what they trade. 
