logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter

TurkeyMan 4284 31
ADVERTISEMENT
Reply | New topic
  • #1 20365615
    TurkeyMan
    Level 3  
    Teardown of this RCBO/circuit breaker/energy meter from AliExpress.

    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter

    This is a VERY interesting device. Not your mama's wifi circuit breaker, this is a real, proper, mechanical RCBO/circuit breaker.
    This is proper gear, and can be used to completely replace the circuit breakers in your home, rather than the typical arrangement of placing wifi relays/meters in-line after a traditional current limiting circuit breaker and RCBO.
    This is a 2P all-in-one device that does it all.

    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter

    This thing's big, heavy, and feels substantial.
    Let's see what's inside...

    It is sadly quite difficult to break into. There are 4 screws, 2 plastic clips, a plastic RS485 port cover, and very sadly, 5 solid-core rivets which need to be removed, which unfortunately means this device can not be re-assembled very securely after destroying the rivets.
    I drilled the folded end of the rivets and tapped them through with a hammer and a nail. Once everything was removed, it comes apart easily.
    The devices has 2 separate covers that can be removed on each side of the device. The left cover reveals the electronics, and the right cover reveals the mechanical components.

    Holy smokes!
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter
    My suggestion, DO NOT REMOVE THE RIGHT COVER. 3 of the 4 screws are on the right hand side, and they do not need to be removed to modify the device. Just leave those 3 screws in place and leave the right cover on.
    These mechanical parts are all loose. There are at least 4 springs, and lots of floating bits, and they are held in place by guides on the cover itself. I bumped it and spent at least an hour trying to work out how to reassemble it correctly!!

    Let's remove the left side cover:
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter
    Jeezus!! There's a lot going on here.
    Connecting to the switching lever there's a series of FIVE cogs, all very well lubricated.
    Instead of a relay, there's a motor which drives the lever to open/close the circuit.

    There seems to be a shit-load of flux on the surface, it's glossy and it makes it really hard to see what the components are. I spent time trying to get good photos.

    This is the chip closest to the motor:
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter

    This is the one at the opposite corner from the wifi module. I can't read what this is:
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter

    This is the one closest to the wifi module. It's also very difficult to read:
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter

    I'm struggling to believe a device of this complexity can just have a wifi module do everything, I can't see a TuyaMCU, but I can see the TX/RX lines appear to go somewhere, so I fear the worst. I need to remove this board and look at the other side...

    Removing the board is quite difficult; there are 3 small screws, there is a location at the bottom right where the board is soldered down onto a secured fixture (the large blob of solder at the bottom right must be removed to release it), the button on the front (right of the big gear) is glued in place with a urethane compound, the gears and actuator arms get in the way of moving the board so be very careful not to bump them, several wires that lead deeper into the device are quite short and don't allow to lift the board without de-soldering them.

    Lifting the board reveals a second layer circuit board deeper in the device. I lifted the board just enough to get a peek at what's going on, but I couldn't get a comprehensive look without risking mechanical damage:
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter

    And there it is... I reckon that's the MCU I was looking for. Again, it's very hard to read what's written on the chip.

    Fortunately, the circuit board is designed in a way that will make it very easy to flash the wifi module. The main board does not need to be lifted or removed to flash the device. Also:
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter
    There is a perfect location to cut and then repair the TX/RX traces with pads to create the repair located perfectly.

    So, I think I've learned that everything is in good order and this device can be modified. I re-assembled it and turned it on. It works very nicely.
    The stock firmware has a LOT of configuration, at least 20 values can be configured. It allows to configure tolerances for the earth leakage, circuit breaker current, etc. The energy meter is very comprehensive, showing many values.

    Operating the switch with the motor just sounds funny! I'm accustomed to the *click* of a relay.

    So it's relatively easy to flash this device, but before that, I need to learn all the communications. There are so many configurable values; this will be a lot of data!
    ...but how can I sniff the UART safely? It's the same problem as before, the device needs to be connected to mains power for it to reveal the interesting communications.
    I don't want to blow this device up like my other one. How can I safely read data from the UART without a common ground reference, and avoid blowing up my device and my USB bus again?
  • ADVERTISEMENT
  • #2 20365852
    p.kaczmarek2
    Moderator Smart Home  
    Very useful teardown. It would be also helpful to get 2MB dump from this device so further ones can be flashed via OTA hack.

    HT7017 chip?
    Never heard that before, but "8000:1 3V~5.5V UART 单相电量芯片 SSOP-16-150mil Energy Metering ICs ROHS"
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter
    Where are RX and TX legs connected? Maybe to TXD1 and RXD1 of WiFi module?

    PN6850 chip? Or something like that? I can see it has many legs (4 of them) on single copper pour.
    It's a power supply chip.
    Buck/step down converter.

    MAX3085? Not sure, it's hard to read, and I can't see why would be there a RS interface IC.

    And the MCU....
    That MCU is most likely TuyaMCU connected by UART to WiFI module.

    Regarding UART communication sniffing - maybe try to figure out where the 5V rail is and connect your USB power supply there? But it's not a perfect solution, because you won't get measurement data.

    Do you have some kind of ESP module or maybe even a loose BK7231 module? One could connect that one to that device and receive the UART results via WiFi... of course you'd have to solder GND, 3.3V and RX of extra WiFi module to given UART pin of original WiFi module
    Helpful post? Buy me a coffee.
  • #3 20366147
    gulson
    System Administrator  
    Thank you so much for another detailed teardown!! I hope that with @p.kaczmarek2 you will be able to run this product.
  • ADVERTISEMENT
  • #4 20366523
    TurkeyMan
    Level 3  
    p.kaczmarek2 wrote:
    Very useful teardown. It would be also helpful to get 2MB dump from this device so further ones can be flashed via OTA hack.

    OTA hack? What's that? Is there a way to modify these devices without surgery?
    Or do you want the original firmware to search for exploits?

    p.kaczmarek2 wrote:
    HT7017 chip?
    Never heard that before, but "8000:1 3V~5.5V UART 单相电量芯片 SSOP-16-150mil Energy Metering ICs ROHS"
    [BK7231T / WB3S] AT-Q-SMR1-20 wifi DIN rail RCBO circuit breaker + energy meter
    Where are RX and TX legs connected? Maybe to TXD1 and RXD1 of WiFi module?

    They don't seem to connect to the wifi module. I guess they connect to the large chip underneath, but I couldn't get probes under there to follow.
    Since they have no connection to the wifi module, it doesn't really matter though, that whole part of the board will just keep doing whatever it does.

    p.kaczmarek2 wrote:
    MAX3085? Not sure, it's hard to read, and I can't see why would be there a RS interface IC.

    It's for RS485 (modbus probably), where there are 2 ports exposed on the front of the device. This chip *IS* connected to the wifi chip, so it seems the wifi module also manages the RS485 comms... I thought that was a bit surprising.
    Safe to say, we're not gonna have that working any time soon! Although it would be quite cool; it is nice to use Modbus for monitoring these sorts of devices; hard-line RS485 has much higher reliability than wifi. I can imagine a Modbus driver which maps values to coils/registers with their Modbus ID corresponding with the OpenBK value ID. It could make OpenBK generally accessible by Modbus.

    p.kaczmarek2 wrote:
    And the MCU....
    That MCU is most likely TuyaMCU connected by UART to WiFI module.

    Yes, and I expect the HT7017 metering chip is connected to this.

    p.kaczmarek2 wrote:
    Regarding UART communication sniffing - maybe try to figure out where the 5V rail is and connect your USB power supply there? But it's not a perfect solution, because you won't get measurement data.

    Yes, I've done this before with other devices, but it doesn't give any useful data. These devices all seem to have to be on mains to learn anything.
    I'm tempted to just try it and hope for the best... it normally works and I only ever blew up one thing before :P
    I'd like a way to test if it's likely to explode before making the connection. If I put my scope between RX and RX on one side and the other side, there is a weird square wave visible... voltage is kinda high. What would explain a huge voltage difference between 2 devices on their 3.3v circuits? They're plugged into the same neutral circuit... and I can't measure any voltage between GND and the houses N circuit.

    p.kaczmarek2 wrote:
    Do you have some kind of ESP module or maybe even a loose BK7231 module? One could connect that one to that device and receive the UART results via WiFi... of course you'd have to solder GND, 3.3V and RX of extra WiFi module to given UART pin of original WiFi module

    I have a few devices I've blown up... but I think they don't work ;)
    I could get one. It can't be expensive to order an ESP off the internet... but the software to do that is a bit of a question mark? Is there something in OpenBK that can do that right now? It also needs to capture all comms from bootup; so the secondary module kinda needs to be up and running and sniffing before the first one does anything.

    I feel like there must be some way to bridge the TTL between 2 devices... is there an off-the-shelf opto-coupler which will take a signal and vcc/gnd reference on both sides, and then echo the signal across the gap?
  • #5 20369446
    p.kaczmarek2
    Moderator Smart Home  
    Quote:

    OpenBK that can do that right now? It also needs to capture all comms from bootup;


    Not fully yet, but I can add that system for you and maybe save packets to LittleFS.

    Just tell me if you need it, and I will do it per request.

    I want to get that device up and running.
    Helpful post? Buy me a coffee.
  • #6 20369612
    TurkeyMan
    Level 3  
    I ordered an optocoupler, it should be here in a couple of days. Hopefully that can let me capture from a live device safely.

    I agree this is a really good device to support, it's quite a serious device. This thing isn't a toy like most tuya stuff.
    ...but I think it really needs a soft-mod to be broadly usable. Most people wouldn't/shouldn't open this device up. I think removing the rivets from the device creates a safety concern since it can't be reassembled well.

    Don't worry about the UART logging just now. If you want something to work on, please consider the SPI connected meter ;)
    And when this device is working, I would really like to look at a modus driver too. Is there any existing driver code to support that RS485 chip?
  • #7 20369726
    p.kaczmarek2
    Moderator Smart Home  
    The OTA hack can support this if we get an original 2MB flash dump.

    I am aware about SPI but I think that I may chose to do software I2C first. I'll think about it.

    I am also working on next youtube video with my assistant, she's a lot of help but still it takes some time.
    Video will be put here, once released:
    https://openbekeniot.github.io/webapp/devicesList.html

    I don't know much about RS485.
    Helpful post? Buy me a coffee.
  • #8 20545550
    rusudanion
    Level 4  
    >>20365615
    Hello i have same device,can i send you a private message for some info.Thankyou
  • ADVERTISEMENT
  • #9 20806738
    rusudanion
    Level 4  

    Hello, I have the same RCBO with a test button problem. It does not cut the voltage when pressed. I opened the RCBO and found a burnt resistor (under the mainboard). Can you tell me what the code or value of the resistor is? Thank you.
    Attachments:
  • #10 20807990
    morgan_flint
    Level 14  

    rusudanion wrote:
    Hello, I have the same RCBO with a test button problem. It does not cut the voltage when pressed. I opened the RCBO and I found this BURNED RESISTOR (under the mainboard). Can you tell me what is the code or value? Thank you.

    If that resistor is like the one used to test a classic RCBO, its function is to create a small current that flows outside the current transformer, thus making the RCBO trip:
    RCBO schematic showing the connection of a resistor to the L line and TEST button.

    Then, in that case, it's easy to calculate its value, as that current should be (slightly) higher than the residual the RCBO is designed to trip. So if the RCBO is for 230V 30mA, the resistor should be lower than (230*0.9)/30 = 6k9 (0.9 is to allow for a -10% voltage tolerance). I guess 6k2 could be a valid value. As for the power, you'll have to guess from its size; to withstand continuous connection, it should be higher than (230*1.1)²/6200=10W, but as it should only be connected for a very brief period, maybe 0.5-1W would be enough. I guess the limiting factor in this case is the voltage it can withstand. Maybe your resistor got burned because the RCBO didn't trip fast enough due to another problem?

    But check before doing anything that that resistor corresponds with this function (for example, checking that it is connected to the test button); as this is an electronic RCBO, it could also be part of the low voltage feeding circuit for the electronics.
  • #11 20808674
    rusudanion
    Level 4  

    morgan_flint wrote:
    rusudanion wrote:
    Hello, I have the same RCBO with a test button problem. It does not cut the voltage when pressed. I opened the RCBO and I found this burned resistor (under the mainboard). Can you tell me what is the code or value? Thank you.

    If that resistor is like the one used to test a classic RCBO, its function is to create a small current that flows outside the current transformer, thus making the RCBO trip:
    RCBO schematic showing the connection of a resistor to the L line and TEST button.

    Then, in that case, it's easy to calculate its value, as that current should be (slightly) higher than the residual the RCBO is designed to trip. So if the RCBO is for 230V 30mA, the resistor should be lower than (230*0.9)/30 = 6k9 (0.9 is to allow for a -10% voltage tolerance). I guess 6k2 could be a valid value. As to the power, you'll have to guess from its size; to withstand continuous connection, it should be higher than (230*1.1)²/6200=10W, but as it should only be connected for a very brief period, maybe 0.5-1W would be enough. I guess the limiting factor in this case is the voltage it can withstand. Maybe your resistor got burned because the RCBO didn't trip fast enough due to another problem?

    But check before doing anything that that resistor corresponds with this function (for example, checking that it is connected to the test button); as this is an electronic RCBO, it could also be part of the low voltage feeding circuit for the electronics



    Hi, thanks for your kind reply. The resistor is 18kohm 2 watts. I heard from the assistance (since I have a direct channel) and they told me the value of the resistor. It is 18kohm as the RCBO is adjustable from 30mA to 100mA. So I think the resistance is good for all ranges. Inside the RCBO, the resistance is connected to the L line and when you push the TEST button, it makes a contact on the ground of the circuit. Obviously, I tested the RCBO with an EXTERNAL TESTER and it works well. The TEST BUTTON, as in other RCBOs, interposes a resistance between L and N. Being a separate circuit, it does what a TESTER does. In your opinion, is a metal oxide or carbon resistance better?
  • #12 20810926
    morgan_flint
    Level 14  

    rusudanion wrote:
    The resistor is 18kohm

    It sounds like it's a high value, as it would only draw 230/18=12.7mA at 230V, but maybe pressing the button also changes the sensitivity to a lower value... in an electromechanical device it would be lower.
    rusudanion wrote:
    In your opinion, is a metal oxide or carbon resistor better?

    I really don't know, but the burnt one in the photo looks like a metal oxide film
  • #13 20810947
    rusudanion
    Level 4  

    I ordered the resistor on AliExpress. When I received it, I tested it. Yes, it is a metal oxide resistor. I see that metal oxide supports higher temperatures better than carbon film.
  • #14 20817461
    piotrszulc1
    Level 9  
    @TurkeyMan, have you ever got it working with OpenBeken?

    I believe I've got a similar breaker (ZMB9-W-1P), it also has a motor-controlled switch.
    It turned out to be flashable via cloudcutter, so I flashed it with openbk.
    There is a TuyaMCU on board and I discovered the following dpids:

    Code: text Expand Select all Copy to clipboard
    
1: Total forward energy
3: Month energy
4: Daily energy
6: Phase A
9: Fault
11: Switch prepayment
16: Switch
17: Alarm set1
18: Alarm set2
19: Breaker id
20: IMEI IMSI
101: Overload protection


    Their format is as follows:
    Code: text Expand Select all Copy to clipboard
    
    "functions": [
      {
        "code": "month_energy",
        "lang_config": {
          "unit": ""
        },
        "name": "Month energy",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "daily_energy",
        "lang_config": {
          "unit": ""
        },
        "name": "Daily energy",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "switch_prepayment",
        "lang_config": {
          "false": "Off",
          "true": "On"
        },
        "name": "Switch prepayment",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "switch",
        "lang_config": {
          "false": "OFF",
          "true": "ON"
        },
        "name": "Switch",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "alarm_set_1",
        "lang_config": {
          "unit": ""
        },
        "name": "Alarm set1",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "alarm_set_2",
        "lang_config": {
          "unit": ""
        },
        "name": "Alarm set2",
        "type": "Raw",
        "values": "{}"
      }
    ],
    "status": [
      {
        "code": "total_forward_energy",
        "lang_config": {
          "unit": "kWh"
        },
        "name": "Total forward energy",
        "type": "Integer",
        "values": "{\"unit\":\"kW·h\",\"min\":0,\"max\":99999999,\"scale\":2,\"step\":1}"
      },
      {
        "code": "month_energy",
        "lang_config": {
          "unit": ""
        },
        "name": "Month energy",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "daily_energy",
        "lang_config": {
          "unit": ""
        },
        "name": "Daily energy",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "phase_a",
        "lang_config": {
          "unit": ""
        },
        "name": "Phase A",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "fault",
        "lang_config": {
          "credit_alarm": "Credit alarm",
          "fire_alarm": "Fire alarm",
          "high_power_alarm": "High power alarm",
          "leakagecurr_alarm": "leakage current",
          "magnetism_alarm": "Magnetism alarm",
          "miss_phase_alarm": "Miss phase alarm",
          "no_balance_alarm": "No balance alarm",
          "outage_alarm": "Power outage",
          "ov_cr": "Over current",
          "ov_vol": "Over voltage",
          "overload_alarm": "Over load",
          "self_test_alarm": "Self test abnormal",
          "short_circuit_alarm": "Circuit short",
          "surge_alarm": "Surge alarm",
          "temp_dif_fault": "Temperature alarm",
          "unbalance_alarm": "3 phases unbalance ",
          "undervoltage_alarm": "Under voltage"
        },
        "name": "Fault",
        "type": "Bitmap",
        "values": "{\"label\":[\"short_circuit_alarm\",\"surge_alarm\",\"overload_alarm\",\"leakagecurr_alarm\",\"temp_dif_fault\",\"fire_alarm\",\"high_power_alarm\",\"self_test_alarm\",\"ov_cr\",\"unbalance_alarm\",\"ov_vol\",\"undervoltage_alarm\",\"miss_phase_alarm\",\"outage_alarm\",\"magnetism_alarm\",\"credit_alarm\",\"no_balance_alarm\"]}"
      },
      {
        "code": "switch_prepayment",
        "lang_config": {
          "false": "Off",
          "true": "On"
        },
        "name": "Switch prepayment",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "switch",
        "lang_config": {
          "false": "OFF",
          "true": "ON"
        },
        "name": "Switch",
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "alarm_set_1",
        "lang_config": {
          "unit": ""
        },
        "name": "Alarm set1",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "alarm_set_2",
        "lang_config": {
          "unit": ""
        },
        "name": "Alarm set2",
        "type": "Raw",
        "values": "{}"
      },
      {
        "code": "breaker_number",
        "lang_config": {
          "unit": ""
        },
        "name": "Breaker id",
        "type": "String",
        "values": "{\"maxlen\":255}"
      },
      {
        "code": "imei_imsi",
        "lang_config": {
          "unit": ""
        },
        "name": "IMEI IMSI",
        "type": "String",
        "values": "{\"maxlen\":255}"
      }
    ]


    I've searched the forum and discovered OBK setups of other breakers, so I adjusted them to work with mine and got this autoexec.bat:
    Code: text Expand Select all Copy to clipboard
    

startDriver TuyaMCU
tuyaMcu_defWiFiState 4
startDriver NTP

setChannelType 1 toggle
setChannelLabel 1 "Relay"

setChannelType 2 Voltage_div10
setChannelType 3 Power
setChannelType 4 Current_div1000
setChannelType 5 EnergyTotal_kWh_div100

setChannelType 7 toggle
setChannelLabel 7 "Prepayment"

linkTuyaMCUOutputToChannel 16 bool 1

linkTuyaMCUOutputToChannel 1 val 5

linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP

linkTuyaMCUOutputToChannel 11 bool 7


    This seems to be working fine and even reports correct voltage (although I have not tested it under any load), except that I cannot control the main breaker switch. Flipping it on and off manually does change the state (ie. the state is correctly reported by TuyaMCU), but setting it on/off from the OpenBK does nothing - the state reported by TuyaMCU does not change.
    There must be something missing... Any idea what?
    I kind of have a feeling the TuyaMCU is not in a correct state to run the motor.
    @TurkeyMan mentioned some other chip (was it MAX3085?) connected to beken board. Do you know which pins exactly? Maybe it needs to be put in some state first?
    I was playing with the GPIO doctor and I observed that P7, P8 and P9 sometimes toggle when configured as input, so there might be something there...
    I tried scanning them with i2cscan, but I did not find anything.
  • #15 20817646
    p.kaczmarek2
    Moderator Smart Home  
    I flashed many, many TuyaMCU devices with OBK and it always worked well, so it should work here as well. Let's see what we can do about your issue.
    piotrszulc1 wrote:

    This seems to be working fine and even reports correct voltage (although I have not tested it under any load), except that I cannot control the main breaker switch. Flipping it on and off manually does change the state (ie. the state is correctly reported by TuyaMCU), but setting it on/off from the OpenBK does nothing - the state reported by TuyaMCU does not change.
    There must be something missing... Any idea what?.

    The first thing to try would be to enable the "TuyaMCU queue" in flags, which is a better implementation of TuyaMCU in the testing phrase, but I don't think that will help. Still, it's always worth to give it a shot, as it's just one checkbox to toggle.

    piotrszulc1 wrote:

    There must be something missing... Any idea what?

    That is why doing captures with original firmware is always preferred, then we can capture packets one by one. But if you don't have one, you can try different dpIDs, I as at least two booleans on the list...

    piotrszulc1 wrote:

    I kind of have a feeling the TuyaMCU is not in a correct state to run the motor.

    If you want to speed up testing, you can remove automatic mapping, those:
    Code: text Expand Select all Copy to clipboard
    
linkTuyaMCUOutputToChannel

    and then play around the send command, use it at realtime, in commandline, to send dpID packets:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_sendState	[dpID][dpType][dpValue]

    VarTypes can be following: 0-raw, 1-bool, 2-value, 3-string, 4-enum, 5-bitmap.
    So, if you want to send FALSE to dpID 123, you do:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_sendState 123 1 0

    etc, etc. Please try it out and let me know if there is any progress.

    Added after 1 [minutes]:

    piotrszulc1 wrote:

    I was playing with the GPIO doctor and I observed that P7, P8 and P9 sometimes toggle when configured as input, so there might be something there...

    That would be something new. I haven't encountered TuyaMCU device before that is using also WiFI module GPIOs for other purpose than UART communication with the MCU.
    Can you do Tuya config extraction?
    https://www.youtube.com/watch?v=WunlqIMAdgw&ab_channel=Elektrodacom
    Helpful post? Buy me a coffee.
  • #16 20817689
    piotrszulc1
    Level 9  

    p.kaczmarek2 wrote:
    The first thing to try would be to enable the "TuyaMCU queue" in flags, which is a better implementation of TuyaMCU in the testing phase, but I don't think that will help. Still, it's always worth to give it a shot, as it's just one checkbox to toggle.


    Forgot to mention I have this flag enabled already.

    p.kaczmarek2 wrote:

    That is why doing captures with original firmware is always preferred, then we can capture packets one by one. But if you don't have one, you can try different dpIDs, I have at least two booleans on the list...


    Yes, I already tried setting both dpIds for boolean, in all possible configurations.
    I still have the flash dump I have created for creating cloudcutter profile. Can this be flashed back to restore tuya firmware?

    p.kaczmarek2 wrote:

    If you want to speed up testing, you can remove automatic mapping, those:
    Code: text Expand Select all Copy to clipboard
    
linkTuyaMCUOutputToChannel

    and then play around with the send command, use it in real-time, in the command line, to send dpID packets:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_sendState	[dpID][dpType][dpValue]

    VarTypes can be the following: 0-raw, 1-bool, 2-value, 3-string, 4-enum, 5-bitmap.
    So, if you want to send FALSE to dpID 123, you do:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_sendState 123 1 0

    etc, etc. Please try it out and let me know if there is any progress.

    I tried that and it was not working at all, but this was with the mapping linkTuyaMCUOutputToChannel. Will disable it and try again.
    p.kaczmarek2 wrote:

    Can you do Tuya config extraction?
    https://www.youtube.com/watch?v=WunlqIMAdgw&ab_channel=Elektrodacom

    Yes, I will try it later and post here.
  • #17 20817699
    p.kaczmarek2
    Moderator Smart Home  
    Ok. Another idea. Run this command to see what TuyaMCU will respond:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_sendQueryState

    Maybe there are some dpIDs that are not yet listed?

    PS: Was it working with Tuya firmware?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #18 20818578
    piotrszulc1
    Level 9  

    p.kaczmarek2 wrote:
    PS: Was it working with Tuya firmware?

    Are you asking if the breaker was working as expected with Tuya? Yes, it was.

    Here's the result of
    tuyaMcu_sendQueryState cmd (channel mapping disabled):
    Code: text Expand Select all Copy to clipboard
    
Info:CMD:[WebApp Cmd 'tuyaMcu_sendQueryState' Result] OK
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 10 01 00 01 00 20 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 16, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 01 02 00 04 00 00 00 00 18 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 0
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 09 05 00 01 00 1D 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 9, dataType 5-DP_TYPE_BITMAP and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 0C 06 00 00 08 08 DE 00 00 00 00 00 00 09 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 19 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 6, dataType 0-DP_TYPE_RAW and 8 data bytes
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 12 00 00 0C 01 01 00 10 03 01 01 13 04 01 00 AF 15 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 18, dataType 0-DP_TYPE_RAW and 12 data bytes
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 12 13 03 00 0E 45 54 55 31 2D 49 4F 54 2D 57 49 46 49 00 D3 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 25 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 19, dataType 3-DP_TYPE_STRING and 14 data bytes


    The same dpids are also published periodically by TuyaMCU itself. Odd that not all dpids are here... (eg. 11 is missing).

    p.kaczmarek2 wrote:
    Can you do Tuya config extraction?

    I did, unfortunately the resulting json file seems to be corrupted and BK7231Flasher says "Sorry, no meaningful pins data found." I have tried several times, using the latest bk7231flasher_1.1.3.

    Code: text Expand Select all Copy to clipboard
    
{
	"uart_baud":"9600",
	"uart_databit":"3",
	"uart_parity":"0",
	"uart_stopbits":"1}bt_hid",
	"prod_test":"false "
}


    I can see if it's possible to attach the raw file here.
    Attachments:
  • #19 20818636
    piotrszulc1
    Level 9  

    Playing with tuyaMcu_sendState command doesn't seem to trigger any answer from TuyaMCU...
    I have noticed in other posts on this forum that in most cases MCU sends the product key during initialization. Nothing like that happens on my breaker. So maybe the initialization is not finished for some reason? Should I try and enable MQTT?
  • #20 20818695
    p.kaczmarek2
    Moderator Smart Home  
    That JSON is as expected. That's what i wanted to see, just to confirm baud rate setting.

    MQTT will not change anything as long as you have:
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_defWiFiState 4

    in your autoexec.bat. This will set TuyaMCU state to "connected to cloud", so device thinks it's paired.

    How do you know that nothing like that happens on your breaker? It may happen, just before wifi connects.
    Helpful post? Buy me a coffee.
  • #21 20818780
    piotrszulc1
    Level 9  

    piotrszulc1 wrote:
    "uart_stopbits":"1}bt_hid",

    Is this expected? Really? Seems to me like a wrongly constructed JSON.

    p.kaczmarek2 wrote:
    tuyaMcu_defWiFiState 4

    As you can see in my autoexec.bat - I have it. When I set it to 3 there is no difference... So maybe it's not working as expected?

    Added after 2 [minutes]:

    I've read somewhere that there are devices which report "cloud readiness" via a GPIO... I wonder if this is the case here...
  • #22 20818849
    p.kaczmarek2
    Moderator Smart Home  
    The JSON extractor is very simple and it skips the Tuya filesystem format we don't know and tries to reconstruct the JSON, that's why it may look strange, but the result is still useable virtually all the time, just like in your particular case, I wanted to see the uart baud rate and here it is.
    There is nothing more in JSON of TuyaMCU devices.

    tuyaMcu_defWiFiState was not modified in source code for a very long time, but if you expect that there is a bug, you can try older build, just keep in mind that downgrade is not supported and you may need to reconfigure device from scratch.

    Where did you find a GPIO information about that? To the best of my knowledge, all TuyaMCU devices encountered so far are using only RX and TX, none of other GPIOs are used. Futhermore, if a GPIO were to be used, I'd guess it would be specified in JSON.

    Do we know what is the exact meaning of those dpIDs:
    Code: text Expand Select all Copy to clipboard
    
11: Switch prepayment
16: Switch

    What is prepayment? Maybe you need to send a combination, first dpID 11, then 16, or something like this?
    Helpful post? Buy me a coffee.
  • #23 20818924
    piotrszulc1
    Level 9  

    I've learned about this GPIO on ESPHome, see here: https://esphome.io/components/tuya.html about the status pin. There's also a link there to the Tuya dev website which seems to be the source of this information.

    p.kaczmarek2 wrote:
    What is prepayment?

    I believe the device was designed for landlords in mind, so that they could allow the tenants to prepay the electricity bill. Once the prepaid amount is used, the device would cut the power. This is only my speculation, but anyway I don't think this switch matters in this case. I remember it was there also on the Tuya app and I didn't have to touch it at all to flip the main switch.
  • #24 20820177
    p.kaczmarek2
    Moderator Smart Home  
    That's good to know. Still, it doesn't seem like we're anywhere closer to solving the issue. We might need original firmware data capture for that, so we can compare with ours and tell what's missing.
    Helpful post? Buy me a coffee.
  • #25 20890599
    ferbulous
    Level 18  
    piotrszulc1 wrote:

    This seems to be working fine and even reports correct voltage (although I have not tested it under any load), except that I cannot control the main breaker switch. Flipping it on and off manually does change the state (ie. the state is correctly reported by TuyaMCU), but setting it on/off from the OpenBK does nothing - the state reported by TuyaMCU does not change.
    There must be something missing... Any idea what?
    I kind of have a feeling the TuyaMCU is not in a correct state to run the motor.
    @TurkeyMan mentioned some other chip (was it MAX3085?) connected to beken board. Do you know which pins exactly? Maybe it needs to be put in some state first?
    I was playing with the GPIO doctor and I observed that P7, P8 and P9 sometimes toggle when configured as input, so there might be something there...
    I tried scanning them with i2cscan, but I did not find anything.


    Hi , are you able to control the main breaker switch now?
  • #26 20890687
    p.kaczmarek2
    Moderator Smart Home  
    @ferbulous
    piotrszulc1 wrote:

    I was playing with the GPIO doctor and I observed that P7, P8 and P9 sometimes toggle when configured as input, so there might be something there...

    I had the same while testing new Zmai90 and I discovered it indicates a bridge relay, see related topic:
    https://www.elektroda.com/rtvforum/topic4014818.html
    A bridge relay uses two GPIOs to control a latching relay, you need to set two GPIO roles for that:
    A table fragment describing GPIO settings for relay control.
    Helpful post? Buy me a coffee.
  • #27 20891158
    ferbulous
    Level 18  
    @p.kaczmarek2 thanks, planning to get a similar one with that toggle switch

    Smart WiFi circuit breaker Tongou with remote control via Tuya Smart Edition mobile app.
  • #28 20891210
    p.kaczmarek2
    Moderator Smart Home  
    Feel free to buy one, Bridge driver works and was tested by me and @valeklubomir , I can help with setting it up
    Helpful post? Buy me a coffee.
  • #29 21097468
    Roeller
    Level 2  

    Hello,

    So, I saw this is the same as the TONGUE TOSMR1 (SMR1) device.

    I saw all the teardown and all the springs and plastic clips.. So my question is: Is it easy/possible to JUST unscrew the left side, solder the TX/RX, flash and that's all?
    (don't want to drill plastic clips and stuff and then turn it back in my 230 main circuit ;) )

    Is the flash specifically for the RS485 version (modbus) or also for the WIFI version? I heard the RS485 version does not have WIFI?
  • #30 21167561
    as-2
    Level 12  
    Hi
    You may find the ESPhome log useful (I failed with the ESPHome configuration) Communication 115200

    [15:14:14][C][wifi:599]: WiFi:
    [15:14:14][C][wifi:427]: Local MAC: B8:06:0D:E5:19:2F
    [15:14:14][C][wifi:432]: SSID: [redacted].
    [15:14:14][C][wifi:435]: IP Address: 192.168.1.225
    [15:14:14][C][wifi:438]: BSSID: [redacted].
    [15:14:14][C][wifi:440]: Hostname: 'rcbo'
    [15:14:14][C][wifi:442]: Signal strength: -62 dB ▂▄▆".
    [15:14:14][C][wifi:446]: Channel: 6
    [15:14:14][C][wifi:447]: Subnet: 255.255.255.0
    [15:14:14][C][wifi:448]: Gateway: 192.168.1.1
    [15:14:14][C][wifi:449]: DNS1: 192.168.1.1
    [15:14:14][C][wifi:450]: DNS2: 192.168.1.1
    [15:14:14][C][logger:185]: Logger:
    [15:14:14][C][logger:186]: Level: DEBUG
    [15:14:14][C][logger:188]: Log Baud Rate: 115200
    [15:14:14][C][logger:189]: Hardware UART: UART2
    [15:14:14][C][uart.lt:101]: UART Bus:
    [15:14:14][C][uart.lt:102]: Type: hardware
    [15:14:14][C][uart.lt:104]: Port number: 1
    [15:14:14][C][uart.lt:106]: TX Pin: 11
    [15:14:14][C][uart.lt:107]: RX Pin: 10
    [15:14:14][C][uart.lt:109]: RX Buffer Size: 256
    [15:14:14][C][uart.lt:111]: Baud Rate: 115200 baud
    [15:14:14][C][uart.lt:112]: Data Bits: 8
    [15:14:14][C][uart.lt:113]: Parity: NONE
    [15:14:14][C][uart.lt:114]: Stop bits: 1
    [15:14:14][C][homeassistant.time:010]: Home Assistant Time:
    [15:14:15][C][homeassistant.time:011]: Timezone: 'CET-1CEST,M3.5.0,M10.5.0/3'
    [15:14:15][C][tuya.number:034]: Tuya Number 'Undervoltage'.
    [15:14:15][C][tuya.number:034]: Unit of Measurement: 'V'
    [15:14:15][C][tuya.number:035]: Number has datapoint ID 116
    [15:14:15][C][tuya.switch:068]: Tuya Switch 'The rcbo switch is working'.
    [15:14:15][C][tuya.switch:090]: Restore Mode: always OFF
    [15:14:15][C][tuya.switch:024]: Switch has datapoint ID 16
    [15:14:15][C][tuya.switch:068]: Tuya Switch 'Live updates'
    [15:14:15][C][tuya.switch:090]: Restore Mode: always OFF
    [15:14:15][C][tuya.switch:024]: Switch has datapoint ID 109
    [15:14:15][C][tuya.sensor:029]: Tuya Sensor 'Voltage'
    [15:14:15][C][tuya.sensor:029]: State Class: ''
    [15:14:15][C][tuya.sensor:029]: Unit of Measurement: ''
    [15:14:15][C][tuya.sensor:029]: Accuracy Decimals: 0
    [15:14:15][C][tuya.sensor:030]: Sensor has datapoint ID 6
    [15:14:15][C][captive_portal:088]: Captive Portal:
    [15:14:15][C][mdns:116]: mDNS:
    [15:14:15][C][mdns:117]: Hostname: rcbo
    [15:14:15][C][esphome.ota:073]: Over-The-Air updates:
    [15:14:15][C][esphome.ota:074]: Address: rcbo.local:8892
    [15:14:15][C][esphome.ota:075]: Version: 2
    [15:14:15][C][esphome.ota:078]: Password configured
    [15:14:15][C][safe_mode:018]: Safe Mode:
    [15:14:15][C][safe_mode:019]: Boot considered successful after 60 seconds
    [15:14:15][C][safe_mode:021]: Invoke after 10 boot attempts
    [15:14:15][C][safe_mode:022]: Remain in safe mode for 300 seconds
    [15:14:15][C][api:139]: API Server:
    [15:14:15][C][api:140]: Address: rcbo.local:6053
    [15:14:15][C][api:142]: Using noise encryption: YES
    [15:14:15][C][lt.component:013]: LibreTiny:
    [15:14:15][C][lt.component:014]: Version: v1.5.1 on cb3s, compiled at Jul 25 2024 14:17:28, GCC 10.3.1 (-O1)
    [15:14:15][C][lt.component:015]: Loglevel: 3
    [15:14:15][C][tuya:041]: Tuya:
    [15:14:15][C][tuya:054]: Datapoint 6: raw (value: 09.21.00.00.00.00.00.00 (8))
    [15:14:15][C][tuya:058]: Datapoint 1: int value (value: 594)
    [15:14:15][C][tuya:058]: Datapoint 15: int value (value: 0)
    [15:14:15][C][tuya:056]: Datapoint 16: switch (value: ON)
    [15:14:15][C][tuya:074]: Product: '{"p":"pqcmqh1ufgmalru0","v":"1.0.2", "m":2}'


    And a configuration file from tuya local (it's attached), which is fully functional

    P.S..
    I have noticed a lack of refreshing of Datapoints that do not change value, e.g. leakage current last changed 4 days ago if I force a leakage value, it is immediately reported and the Datapoint value is refreshed.
    Attachments:
Reply | New topic
Report a violation of the law

Topic summary

The discussion revolves around the teardown and analysis of the AT-Q-SMR1-20 WiFi DIN rail RCBO circuit breaker and energy meter, highlighting its mechanical design and capabilities compared to traditional setups. Users express interest in extracting firmware via OTA hacks and discuss the internal components, including various chips like HT7017 and TuyaMCU. There are inquiries about UART communication, RS485 connections, and the potential for Modbus integration. Additionally, troubleshooting issues related to a faulty test button and burnt resistors are addressed, with users sharing insights on resistor values and types. The conversation also touches on flashing firmware and configuring the device for better functionality.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT