EAMPDW-TY63 Alternative Firmware: Access Measurement Data with OpenBeken via TuyaMCU

Question

In fact, I managed to read the data locally from this device a long time ago using Node-red, but I would prefer that it had nothing to do with TUYA - i.e. the need to extract the ID and Key, etc. After I figured out how to read data locally, it turned out that someone made a modification...

p.kaczmarek2 · Accepted Answer

Hello, this device is most likely built based on TuyaMCU, so the procedure would be like this:
https://www.elektroda.com/rtvforum/topic3933836.html
https://www.elektroda.com/rtvforum/topic3928897.html
From what I can see the dpIDs are already known:
[syntax=yaml]
esphome:
name: power-meter
platformio_options:
board_build.flash_mode: dio

esp32:
board: esp32-c3-devkitm-1
variant: ESP32C3
framework:
type: esp-idf

# Enable logging
logger:
baud_rate: 0

# Enable Home Assistant API
api:
encryption:
key: !secret api_key

ota:
password: !secret ota_key

wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password

# Enable fallback hotspot in case wifi connection fails
ap:
ssid: "Power-Meter Fallback Hotspot"
password: !secret ap_key

uart:
rx_pin: GPIO20
tx_pin: GPIO21
baud_rate: 9600

sensor:
# Voltage
- platform: template
id: voltage
name: "Voltage"
accuracy_decimals: 0
filters:
- multiply: 0.1
unit_of_measurement: "V"
icon: "mdi:sine-wave"
device_class: "Voltage"
state_class: measurement

# Current
- platform: template
id: current
name: "Current"
accuracy_decimals: 1
filters:
- multiply: 0.001
unit_of_measurement: "A"
icon: "mdi:current-ac"
device_class: "current"
state_class: measurement

# active power
- platform: template
id: power
name: "Power"
accuracy_decimals: 0
filters:
- multiply: 1
unit_of_measurement: "W"
icon: "mdi:flash"
device_class: "power"
state_class: measurement

#energy
- platform: "tuya"
id: energy
name: "Energy"
sensor_datapoint: 1
accuracy_decimals: 1
filters:
- multiply: 0.01
unit_of_measurement: "kWh"
icon: "mdi:sigma"
device_class: "energy"
state_class: measurement

switch:
- platform: "tuya"
id: "meter_power_relay"
name: "Power Switch"
switch_datapoint: 16
icon: "mdi:power"
on_turn_off:
then:
lambda: |-
id(voltage).publish_state(0);
id(current).publish_state(0);
id(power).publish_state(0);

- platform: "uart"
id: sw_tuya_query_status
data: [0x55, 0xaa, 0x00, 0x08, 0x00, 0x00, 0x07]
name: "Update values"
icon: mdi:reload

number:
- platform: "tuya"
name: "Over Voltage"
number_datapoint: 101
min_value: 250
max_value: 300
step: 1
unit_of_measurement: "V"

- platform: "tuya"
name: "Under Voltage"
number_datapoint: 102
min_value: 150
max_value: 190
step: 1
unit_of_measurement: "V"

- platform: "tuya"
name: "Current Limit"
number_datapoint: 103
min_value: 1
max_value: 63
step: 1
unit_of_measurement: "A"

- platform: "tuya"
name: "Electric Leakage"
number_datapoint: 104
min_value: 10
max_value: 100
step: 1
unit_of_measurement: "mA"

tuya:
on_datapoint_update:
- sensor_datapoint: 6
datapoint_type: raw
then:
- lambda: |-
id(voltage).publish_state((x[0]

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

xury · Answer

Thanks for the information. I just managed to upload OpenBeken for the first time. I saved wifi data and autoexec.bat to start with. I'll put the device back together tonight and let you know what happens next. I had to desolder the CB3S chip for flashing.

p.kaczmarek2 wrote:
This is a job for about 30 minutes, maybe up to 60. The next pieces go faster, because not only do we have the configuration, but also the 2MB batch allows you to program the next pieces via WiFi (without soldering).

How can you upload Openbeken without soldering? If you have dump flash from one, can you use it for others? I'm asking because in the case of, for example, Sonoff, you need to have the original backup.
And one more question: In addition to reading the data of current, voltage, energy, power, etc., the device also offers settings for leakage current, overcurrent, overvoltage, etc. Does the autoexec.bat handle all this? Do you have to set it somewhere else? With a cursory check, OpenBeken has a "billion" of options

p.kaczmarek2 · Answer

To program other devices without soldering, you need a full dump of flash memory (2MB) from a device from the same series and with the same build version. Then it's handed over to the Cutter team to add support, but that's what I can do now - just do a full 2MB read and post the dump. OpenBeken is universally written, i.e. does not know what is in the variable. The autoexec.bat quoted earlier maps only dpID 6 to the special packet type (unfortunately) Voltage/Current/Power RAW_TAC2121C_VCP, it does nothing else. To get something more out of TuyaMCU, for example: You need to map dpID 104 (knowing its Tuya type, from value - val rules) to a channel and then receive this channel in MQTT. Code: text Expand Select all Copy to clipboard startDriver TuyaMCU setChannelType 1 Voltage_div10 setChannelType 2 Current_div1000 setChannelType 3 Power setChannelType 4 TextField linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP linkTuyaMCUOutputToChannel 104 val 4 TextField will also allow you to enter this value in the GUI. Then doing channel 4 set will also set dpID 104. In general, when you map something to a channel it all works for it, i.e.: - from MQTT set publish works (setting values from HA) - from the MQTT level get publish works (receiving changes from the device) - scripts work including setChannel 5 123 (channel setting) - change handlers work, e.g. addChangeHandler Channel5 > 40 echo Channel five has a high value! The only problem is that the documentation is incomplete at the moment, so I'll help you launch it if needed. And all this is assuming that they have not changed TuyaMCU since, for example, this topic: QIACHIP Universal WIFI Ceiling Fan Light Remote Control Kit - BK7231N - CB2S Code: text Expand Select all Copy to clipboard // start MCU driver startDriver TuyaMCU // let's say that channel 1 is dpid1 - fan on/off setChannelType 1 toggle // map dpid1 to channel1, var type 1 (boolean) linkTuyaMCUOutputToChannel 1 1 1 // let's say that channel 2 is dpid9 - light on/off setChannelType 2 toggle // map dpid9 to channel2, var type 1 (boolean) linkTuyaMCUOutputToChannel 9 1 2 //channel 3 is dpid3 - fan speed setChannelType 3 LowMidHigh // map dpid3 to channel3, var type 4 (enum) linkTuyaMCUOutputToChannel 3 4 3 //dpId 17 = beep on/off setChannelType 4 toggle linkTuyaMCUOutputToChannel 17 1 4 // // //dpId 6, dataType 4-DP_TYPE_ENUM = set timer setChannelType 5 TextField linkTuyaMCUOutputToChannel 6 4 5 // // //dpId 7, dataType 2-DP_TYPE_VALUE = timer remaining setChannelType 6 ReadOnly linkTuyaMCUOutputToChannel 7 2 6 For the fryer in turn ( this subject ). Code: text Expand Select all Copy to clipboard startDriver TuyaMCU // cook on/off  setChannelType 1 Toggle setChannelLabel 1 Cook linkTuyaMCUOutputToChannel 111 bool 1  // power on/off setChannelLabel 2 Power setChannelType 2 Toggle linkTuyaMCUOutputToChannel 101 bool 2  // set temperature setChannelLabel 3 New Temperature setChannelType 3 TextField linkTuyaMCUOutputToChannel 103 val 3 // currenttemperature setChannelLabel 4 Current Temperature setChannelType 4 ReadOnly linkTuyaMCUOutputToChannel 104 val 4 // set time setChannelLabel 5 New Time setChannelType 5 TextField linkTuyaMCUOutputToChannel 105 val 5 // read time setChannelLabel 6 Current Time setChannelType 6 ReadOnly linkTuyaMCUOutputToChannel 106 val 6

xury · Answer

Thanks again for the information. I think I got the basics. It seems that in the case when the device has TuyaMCU, the wifi chip, no matter what it is, only acts as an intermediary between TuyaMCU and the network. Such a UART/TCP converter. Having a finished nodered flow, I will be able to easily transfer it to OpenBeken. I'll probably do it tonight when I get home.
One more question: Is there any alternative way to run wi-fi manager other than 5x power cycle?
For example, some script that will create a default AP after 5 minutes of no saved SSID? Or use the free gpio in CB3S to call the wi-fi manager? I would earn a microswitch, which would only reset wifi.

p.kaczmarek2 · Answer

A bit of a strange term with this WiFi manager, from what I understand you mean access point mode, such that anyone can connect to the AP and configure ... It should be noted at the outset that there are basically two modes here. - with an empty SSID field of the target network, the firmware creates an open network for configuration - with 5x power on/off, the firmware also creates an open network, but it also enters Safe Mode and does not initialize scripts and pins. This is in case some driver corrupts the device so it can be recovered Anyway: Then it will keep trying to connect. I guess you could script Ping Watchdog to open open APs in case of problems, but it's dangerous. The attacker will disconnect the router and instantly all devices in the house will be in AP mode. It may be better to use the fact that if there is no target SSID set, an open AP will open at reboot. Rather, it can be scripted. Role Btn_ScriptOnly and something like: Code: text Expand Select all Copy to clipboard // 9 means GPIO9/P9 addEventHandler OnDblClick 9 backlog SSID1 ; reboot The code above clears the target SSID name and permanently returns the device to AP mode (until someone sets the target SSID again). Alternatively, I can add a special command to the firmware on request, e.g. a command that creates an open network once. The list of moments (procedurally generated from code) is here: Added after 39 [minutes]: Update - I also add the OpenAP command, which simply opens the AP temporarily for the duration of a given session, without modifying the configuration. It'll be in release in an hour.

xury · Answer

So far I have managed to control the relay with the script from https://www.elektroda.pl/rtvforum/topic3936455-30.html#20352891

In Nodered, the current voltage values read from dpid 6 are encoded in base64 and I had to decode them.
Maybe that's why it doesn't want to work here.

p.kaczmarek2 · Answer

What do you mean with base64, I'm not sure if I understand correctly. Are the voltage, current, etc values on OpenBeken itself correct?

xury · Answer

They're just not correct: They're always null: My flow in Nodered was doing $base64decode(payload) and then: Code: JavascriptLog in, to see the code Unfortunately, I can't translate it to OpenBeken in the log i have: I expect to receive 10 bytes and here are 8 and they do not match the current voltage and power. P.S. Is there any way to see what tuyamcu sends in raw mode? Added after 19 [minutes]: This is my flow with nodered which reads values from dp id 6 and sets all other values: Code: JSONLog in, to see the code

p.kaczmarek2 · Answer

Slowly, because you can get lost. Maybe let's leave node red alone for now and let anything work on OBK?

I can't see the current/voltage/power results and there is only TuyaMCU heartbeat in the log.

Maybe something is missing though, maybe this device needs some incentive package or something.

Let's try something simpler like: 16 - on/off

Add to the configuration:


setChannelType 6 toggle
// linkTuyaMCUOutputToChannel dpId varType channelID
// map dpid16 to channel6, var type 1 (boolean)
linkTuyaMCUOutputToChannel 16 1 6

and verify that the toggle toggle on the openbeken web panel (channel 6) does indeed turn the device on/off.

Added after 4 [minutes]:

Quote:

I expect to receive 10 bytes and here are 8 and they do not match the current voltage and power.

What is in the log is just a heartbeat - it's not data. It's just a packet that is sent periodically to show that communication is still going on.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

xury · Answer

Yes relay works. Does it matter which channel I assign to?
Current setup:

Quote:
startDriver TuyaMCU
startDriver NTP
setChannelType 1 Voltage_div10
setChannelType 3 Power
setChannelType 2 Current_div1000
setChannelType 5 EnergyTotal_kWh_div100
setChannelType 6 toggle
// linkTuyaMCUOutputToChannel dpId varType channelID
// map dpid16 to channel6, var type 1 (boolean)
linkTuyaMCUOutputToChannel 16 1 6
log level 6

Added after 8 [minutes]:

And what else I managed to see in the logs when I changed the parameters to the LCD:
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 65 02 00 04 00 00 01 0E 8B
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 101, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 270
Xury - change Overvoltage to 270V
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 66 02 00 04 00 00 00 AF 2C
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 102, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 175
Xury - change Under Voltage to 175V
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 67 02 00 04 00 00 00 28 A6
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 103, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 40
Xury - Changing the current protection to 40 A from (50A)
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 68 02 00 04 00 00 00 32 B1
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 104, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 50
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 6A 01 00 01 00 7A
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId
dataType 1-DP_TYPE_BOOL and 1 data bytes

p.kaczmarek2 · Answer

Since the relay is working, basic communication is working.

Channels are like variables, they "don't know" what's in them, you can assign them to anything, but there is a limit of 64 I think, higher values are sometimes used as special codes for e.g. LED brightness level and so on.

You showed the log with the reception of part of the data, i.e. those dpId that you quoted also work correctly and can probably be mapped to channels. Now just a question - what about the remaining dpIds, do you receive anything else? Maybe leave the log open for a while and wait.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

xury · Answer

Posiłkując się tematem: Ustaliłem, że wysyłając: uartSendHex 55AA000300010407 to przestaje migać dioda wifi a wysyłając: uartSendHex 55AA0008000007 w odpowiedzi mam: Added after 37 [minutes]: I do not know if it matters, because perhaps base64 decoding is already implemented in the Tuya standard, but for me on NR it looks like this: And e.g. decoding base64 I get: 09 42 means voltage, i.e. 237.0V - there are still zeros, because the current did not flow or there was no leakage current. As I wrote, I don't know if it matters, but that's exactly what dpid 6 returns to me Added after 32 [minutes]: Ok, I got something like this: It seems that everything I wrote about base64 does not apply to data from TuyaMCU The original CB3S feed is probably responsible for the base64 caching Why can't I just show up? And even more logs:

p.kaczmarek2 · Answer

Very good job finding out that this system needs "encouragement" though, I'll have to analyze why this is happening. Anyway, you can always send any data to the UART from the script level, so there is no problem either.

I don't know anything about base64, I haven't done projects on LocalTuya, and TuyaMCU doesn't have it - the data is normally given as integers. As I wrote, I would leave NodeRed alone for now.

This is what you are looking for:


nfo:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 0E 06 00 00 0A 09 4C 00 00 00 00 00 00 00 00 7C
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 21 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 6, dataType 0-DP_TYPE_RAW and 10 data bytes

I also analyzed this packet and saw that it has an extra two bytes on the back (its length is "10 data bytes") and I'm not talking about a checksum here.

I added including this, only now you need to update Obk to the latest version from now, that is to at least 1.15.510.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

xury · Answer

Yes, I even noticed on Nodered that TuyaMCU does not send anything via dpId 6 when the relay is not turned on. In addition, the command uartSendHex 55AA000300010407 must also be sent - this probably tells the MCU that CB3S is connected to the network. So to sum up, for the voltage, current, power and leakage data to be sent, the relay (dpId 16) and (probably, because I haven't figured out the frame yet) dpId 3 must be turned on. There are 10 bytes, because probably similar to what I read from NR, we have 2 bytes - voltage value / 10, 3 bytes - current value / 1000, 3 bytes - power value and 2 bytes - leakage current value, so-called. leakage current This device works as protection against too high and too low voltage, as an overcurrent fuse and as a kind of RCD with adjustable leakage current in mA, and also with a controlled relay. Even through dpId 1 there is a kWh reading and through the other listed viewing / setting values dpId 19 is some ID number, probably for the cloud dpId 9 - I didn't figure it out, when it reads it has a value of 0 there is still a bool prepayment unless you can set how much energy you can use. I have to check it on the Tuya application, because it was about a year ago when I played with it and left it due to the inconvenience of removing the keys. OpenBeken saves the day - I avoid all kinds of clouds as much as possible. I'll update the fw after work and see what happens now. Once again, many thanks for your help. Added after 24 [minutes]: I don't know if I'm doing it right: info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 0E 06 00 00 0A 09 4C 00 00 00 00 00 00 00 00 7C Where the read data begins 09 4C - voltage the next 00 00 00 is the current value next 00 00 00 power value and the last 00 00 - the value of the leakage current 7C - checksum 55AA - header 03 - protocol version 07 - command 00 0E data length 06 -dpId 00 00 0A - I don't know?? then data and CRC at the end Added after 5 [hours] 45 [minutes]: Almost a success. After some time - sometimes 10-15 seconds, sometimes after about 30 seconds, the data stops refreshing and you have to send the command again: uartSendHex 55AA000300010407. in the logs at the moment is: After the data from dpId 6 stops flowing, the wifi diode starts flashing. Also, something else like this: Larger part of the log: Dodano po 6 [minuty]: Tak jestem pewien że po Już nie idą dane na dpId 6

p.kaczmarek2 · Answer

From the screenshots I can see that you don't have MQTT configured. However, you write that after receiving the WiFi state (or rather the answer to it), the module stops being talkative. Maybe Tuya checks the WiFi status in it and in the absence of a full connection (in our case defined as MQTT+WiFi) mutes it?

Add the following command to autoexec.bat:


tuyaMcu_defWiFiState 4

then the device will pretend to have everything connected all the time. Check it out and let me know if anything changes. Thanks to this, it will not be necessary to artificially send this "incentive package".


Gdzie odczytane dane zaczynają się 09 4C - napięcie
kolejne 00 00 00 to wartość prądu
kolejne 00 00 00 wartość mocy
i ostatnie 00 00 - wartość prądu upływu
7C - suma kontrolna

At the moment the configuration we have does not read the current leakage value, do you need to add it?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

xury · Answer

I don't care that much about reading the leakage current.
I will check this wifistate 4 feature and let you know. At the moment I added three uartSendHex, which I looked at in the Tasmota template somewhere and it works. I send via addRepeatingEvent every 10 seconds. I'm satisfied already, but I'll check if it doesn't get better.
The only thing I don't quite understand is how to send a value via MQTT to change value to the mapped channel
For example, I want to change the value in dpId 101 assigned, for example, to channel 4 via MQTT and I can't read from the documentation what the topic should be.
Through web panel works OK with TextField. The only remark how to force it to be displayed next to each other like buttons? Now every channel from the TextField is underneath.
There is also one value that TuyaMCU returns as 5-bitmap. How do I map this to a channel?
There is also a dpId value of 19 string and I wanted to display it as readonly or textfield but it is always 0
It is also not visible in the logs, although it displays information about the type and length.

p.kaczmarek2 · Answer

It would be worth knowing if WiFi state 4 helps, although with the current implementation, probably just connecting MQTT would also fix it (then WiFi state 4 sends itself).
The point here is that TuyaMCU communicates about the connection status and we assumed in the firmware that state 4 is when there is both WiFi and MQTT, and you do not have an MQTT connection now (as shown in the screenshots).
This is because some sensors want to report their status when there is an MQTT and we know that the information will be sent further. These are low-power sensors that then turn off the device.

xury wrote:

The only thing I don't quite understand is how to send a value via MQTT to change value to the mapped channel

And to receive the changes listen:


OBK_DEV_NAME/CHANNEL_INDEX/get

Replace only CHANNEL_INDEX with a number.
To request an update send an empty payload to:


OBK_DEV_NAME/CHANNEL_INDEX/get

You can also use MQTT commands to control:


cmnd/OBK_DEV_NAME/

o payload command arguments. So, for example:


cmnd/OBK_DEV_NAME/setChannel

about payload


1 25

will set channel 1 to 25.

Not all channels are automatically published by the device, you may need to enable publishing all in flags.

xury wrote:

The only remark how to force it to be displayed next to each other like buttons? Now every channel from the TextField is underneath.

The only thing you can do is create a simple HTML document with a REST interface and host it in LittleFS, then you have full control over the site and can literally do whatever the HTML allows. I will be posting a tutorial on this this month.

xury wrote:

There is also one value that TuyaMCU returns as 5-bitmap. How do I map this to a channel?

I would need to see the data of this package, what is there specifically, this type sounds quite mysterious, because it is not a bitmap? I can easily add a special channel type as needed.

xury wrote:

There is also a dpId value of 19 string and I wanted to display it as readonly or textfield but it is always 0

I don't support string yet because I haven't encountered it yet, but if you have the opportunity, you can help me and share what the package looks like with it, I'll try to come up with something.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

xury · Answer

For now, I can say that setting the MQTT broker does not help, because I already have it, only the logs were earlier.

p.kaczmarek2 wrote:
I don't support string yet because I haven't encountered it yet, but if you have the opportunity, you can help me and share what the package looks like with it, I'll try to come up with something.

On NR using local-tuya it returns text like FSE-454905995504
In the evening, when I return from work, I will send everything along with the memory dump of the original FW.
So, for example, if the name of my device is EMPDW-01, the channel number is 11 (mapped to dpid 101 - set over voltage), then I send a message under topic:
cmd/EMPDW-01//11/get - to read
cmnd/EMPDW-01/setChannel
and payload 1 260
only payload has to be as a string? With a space between the channel number and the value?
the same way will work with boolean?
e.g. cmnd/EMPDW-01/setChannel
payload 4 1 - turn on the relay
payload 4 0 - turn off the relay
or e.g. when I have a kWh meter reset mapped under the channel, etc.
payload is supposed to be 8 1

p.kaczmarek2 · Answer

Everything almost perfect, only here:


cmd/EMPDW-01//11/get - by odczytać

you added "cmd/" out of nowhere, it wasn't in what I provided. Plus you have a double slash, that's probably a typo too.

I recommend turning on listen for publishes and you'll see that "get" publishes itself as soon as the status on the device changes, so you don't even have to "encourage" as needed. The device will publish what it needs.

Yes, format as string, 1 to enable, 0 to disable, with spaces where I put them.

xury wrote:

For now, I can say that setting the MQTT broker does not help, because I already have it, only the logs were earlier.

Well, let's explore further, maybe you can help me solve this puzzle, what is missing, that you have to send uartSendHex manually, because I don't have to do it on my Blitzwolf fryer from TuyaMCU. Or maybe I would improve the algorithm so that from newer versions there would be no need to "encourage" ...

Added after 4 [hours] 58 [minutes]:

@xury could you post any picture of this device from this topic we are running here, maybe from the inside, or at least from the outside, because I want to add it to the list of known devices? https://openbekeniot.github.io/webapp/devicesList.html

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

xury · Answer

So. Pictures of the interior are on github: String message: Flash dump attached. Interestingly, I removed the line: from autoexec.bat I saved via Save, Reset SVM... and either it still works or it is no longer needed, because it is as you say.

xury · Answer

Dodam jeszcze trochę logów: Oraz mój autoexec.bat:

xury · Answer

Jeszcze co z ciekawych rzeczy w logu: DpId 9 bitmap type?? - I don't know what it's for Error:CMD:cmd RESULT NOT found - I don't know what it refers to. Interesting facts: Until it counts 0.2 kWh (dpId 1) it does not report this value. Then only during shift or on demand. I don't need to send anything via sendhex anymore. MQTT commands work great. DpId 13 the kWh balance is set - unless after which it is to turn off. Mute - dpId 105 - if it works in the cloud and if notifications are set to Alexa or Google Home, the value of 1 mutes them. Trip - dpid 106 - disables the tripping response to leakage current. tuyaMcu_sendQueryState (the same as uartSendHex 55AA0008000007 as you probably know). After sending, the values of other Dpid's are sent back (except dpid 1 You have to ask about dpid 1, because it rarely changes at low load.

p.kaczmarek2 · Answer

Thank you, that's useful information. I don't know what this bitmap type is.

@xury, there was this pull request:
https://github.com/openshwprojects/OpenBK7231T_App/pull/722
If you have time and willingness to play, you can check if it works/helps on your device. Are you sending anything 'manually' to TuyaMCU at the moment?

If you have any specific questions feel free to ask, I'll help, but for now I think it's ok?

By the way, I attach a screenshot of the device sale offer from the topic.

xury · Answer

Yes everything is ok. I'm trying to add this device to the operating database, but I'm still waiting because I see that a lot is going on in the code. After I set up Mqtt and started using it, nothing needs to be sent. I'm just wondering whether to add support for the last two bytes with the value of the leakage current. But probably other devices may have different values on these bytes. In fact, I'm not even sure what the divisor of this value is, because I didn't test leakage for fear of tripping my main RCD.
The only question I have is whether it would not be possible to attach a driver to support the DS18B20, as it is probably the most popular and smallest temperature sensor. This is not related to this topic, but it would be nice to be able to add a temperature sensor where there are many free gpios. I read somewhere that someone has already asked about it, and you probably didn't quite understand which sensor it was, confusing it with DHT11.

chabalalasmike · Answer

>>20464111How did you figure out voltage, current, and power? What data points are they?

p.kaczmarek2 · Answer

@chabalalasmike I would suggest reading you the whole topic, but in general, this meter has a compound packet data that is under single dpID and contains voltage, current and power data as single bytes stream:


linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP

OpenBeken can decode that.

I was just inspecting the packets data one by one and figured out that this data looks like voltage, current, etc, because I know what kind of voltage we expect to have in my country.

chabalalasmike · Answer

Thanks, that really helped. May we then update the database with whole configuration?

startDriver TuyaMCU
startDriver NTP
setChannelType 1 toggle
linkTuyaMCUOutputToChannel 16 1 1
setChannelType 2 Voltage_div10
setChannelType 3 Power
setChannelType 4 Current_div1000
setChannelType 5 EnergyTotal_kWh_div100
linkTuyaMCUOutputToChannel 1 0 5
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP

crash1912 · Answer

Sorry for a possible stupid question... where to put this configuration? in autoexec.bat? Just like that? Code: text Expand Select all Copy to clipboard ClearIO // clear old GPIO/channels lfs_format // clear LFS StartupCommand   // clear STARTUP stopDriver *  // kill drivers StartupCommand backlog startDriver tuyaMCU startDriver NTP setChannelType 1 toggle linkTuyaMCUOutputToChannel 16 1 1 setChannelType 2 Voltage_div10 setChannelType 3 Power setChannelType 4 Current_div1000 setChannelType 5 EnergyTotal_kWh_div100 linkTuyaMCUOutputToChannel 1 0 5 linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP And, second question: where to put this config json? ( getted from ) Code: text Expand Select all Copy to clipboard {   vendor: Tuya,   name: EAMPDW-TY63 2P 63A Leakage Over Under Voltage Protector Relay Device Switch Breaker Energy Power kWh Meter,   chip: BK7231N,   bDetailed: 0,   board: CB3S,   pins: {},   keywords: [     TuyaMCU,     DIN Rail,     Power Metering   ],   command: backlog startDriver tuyaMCU,   image:    wiki:  }

p.kaczmarek2 · Answer

Config JSON is not needed here. Just autoexec.bat.

You can just copy to autoexec.bat the config we gave you here, but please do not add anything!

The following lines should be REMOVED:


ClearIO // clear old GPIO/channels
lfs_format // clear LFS
StartupCommand ""  // clear STARTUP
stopDriver *  // kill drivers

lfs_format would format the file system and remove autoexec.bat. It looks like you copied it from the quick config script that is executed once, this will not work.

Autoexec should contain only what we pasted in this topic, nothing more.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

EAMPDW-TY63 Alternative Firmware: Access Measurement Data with OpenBeken via TuyaMCU

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary