[WBR3] Feyree EV Charger teardown with adjustable charging via TuyaMCU

Teardown and OpenBeken drop in for Feyree Dynamic Load Balancing EVSE with Tuya App Function from Aliexpress Store.   Decent quality device for the price.  I purchased previous models by this vendor that worked well, so I was willing to take the risk with the TuyaMCU.  Model F-OBZ2-AC-1P32 - this model isn't visible anywhere when purchasing.
 


The goal for me was to be able to adjust the amps/power from MQTT or home assistant while EV charging is in progress. This can be done with OpenBeken.

Opening
Easy to open, with 8 screws covered by rubber seals.  There was no warranty/security seal.


Device Overview
This particular charger is 240v, 32a single phase.  It also has a secondary CT clamp on the input wiring end that can be extended to a distribution board.
It consists of two main boards, the electrical relays (black), and the logic controller (white).  The Logic controller had buttons and TFT screen on the other side.  The device is advertised with RCD type B, but if it exists, likely implemented electronically.  I have a dedicated RCD type B prior to this charger.



The EV charger is run by a GigaDevice GD32F303RCT6


RN7302 metering chip.





!!! IMPORTANT !!!
Do not attempt to tinker when plugged into mains.  I recommend removing the logic board from the mains supply and power it with isolated bench supply with 3.3v or 12v from one of the relevant VDD headers.

Do not attempt to test, flash or capture with mains power applied without all equipment being electrically isolated... isolate all equipment; isolated USB and a disconnected/isolated laptop.


WBR3 Pins
The logic board has a WBR3 Tuya chip, which was not supported by OpenBeken at the time of writing, but mostly pin compatible with others like CB3S. The now supported WBR3 flash process requires lifting the chip anyway, so replacing with a CB3S is probably still quicker if you have one around, otherwise follow the WBR3 flash process.

There is a nice looking header for accessing RX,TX, RST and GND of the WBR3, but be wary of the 12v on the VDD - Do NOT use this VDD point.  






Replacing The WBR3 with CB3S


There are only 6 pins connected to the WBR3; GND, VCC, RX, TX, RST, and EN.  EN (Pin3) has 3.3v applied for Enable (for ESP) - make sure you replace it with a chip that can handle 3.3v on PIN3, or cut the trace. I cut the trace for my purposes. 

Traces visible with the WBR3 removed:
 

I chose to replace with a CB3S pre-flashed with OpenBeken since it is mostly pin compatible and I had a few spare.  Though I destroyed a WB3S in the process - I suspect because of the 3.3v Enable pin.  I made a dirty pin header so I could quickly replace chips, Since I was capturing and testing, .  If anyone knows of a nice test frame intermediate board that could be soldered on top, let me know!



Tuya App and TuyaMCU Capture and Configuration

!!!IMPORTANT!!!
Do not attempt to flash or connect to RX/TX for capturing while on mains power without isolated power at every level.  I used a isolated inverter, isolated USB adapter, and  laptop running on battery for capturing.


Example of the parameters in in the Tuya App, and adjusting the Charge Amps.



I used the TuyaMCU Analyzer tool for capturing.

Here are some of the capture files:

and the data model JSON collected from the tuya developer:


Table of interesting dpids.  Covers the core features:

Tuya dpID	type	notes: value
10	bitmap	Fault Alarm: [err_leak,err_cp, err_temp, warn_a_uvp, warn_b_uvp,warn_c_uvp,err_a_ovp,err_b_ovp,err_c_ovp,err_ocp,err_10,err_11,err_esb,warn_for_sck,err_leak_sck,err_on]
14	enum	RW working mode: [0=charge_now, 1=charge_pct, 2=charge_energy, 3=charge_scheduled]
18	bool	RW switch: on/off
101	enum	Status: [0=not connected, 1=connected, 2=charging, 3=waiting on rfid, 4=finished, 5=wait for charging, 6=error]
102-104	val	voltage /10 - 3 id's, one for each phase, 102 Ph1
105-107	val	amps /10 - 3 id's, one for each phase, 105 Ph1
109	val	Power in kW /10
110	val	Temperature /10
112	val	Session kWh /10
113	enum	Maximum supported current: [0=maximum 16a, 1=maximum 32a]
120	str	time counter; delay timer countdown, or charge run time counter - string like: 08:00:00
114	val	RW Set Max Charge Amps when dpid 113 = 16a enum type
115	val	RW Set Max Charge Amps when dpid 113 = 32a enum type
125	val	RW Set Max Charge Amps when dpid 113 = 60a enum type
118	val	RW delay time command
122	str	delay time state - string like: D:08H
119	val	RW charge time command
121	str	charge time state: T:13H
124	enum	RW Charge Command: [0=charging,1=charging stopped, 3=waiting for delay] Response: [10=charging stopped,255=?]

Observations about the string type dpIDs:
Cases where TuyaMCU send actual strings (not just strings to be cast as int or float) seems to be quite rare, and handling dpIDs of this type will be a challenge.

Observation about the CT Clamp:
The external CT clamp meant for import smoothing does not appear to be integrated with the TuyaMCU communications from the capture, even though the dpId data model makes reference to it.  Even so, it's not entirely clear how the CT balancing is meant to work in conjunction with the app.  For me this is not a issue, as I want to control the Amps via OpenBeken+MQTT and I'm not using the external CT clamp.  Power consumption from EV charging is tracked independently by an internal sensor.

Observations about setting amp limit on dpID 115:
Through the Tuya app and screen, the minimum is 8 amps.  However, through TuyaMCU, this can be set as low as 6amps on my EV.  However, after a session set to 6 amp and unplugging and plugging back in to start a new charge session, this resets to 20.   This value is full integer only, no floats.

OpenBeken Configuration



config json - there are no pins, just basic startup command.  The rest is in the autoexec.bat below


autoexec.bat
Below are the mappings I'm currently working through.  So far I can do what I set out to do, which is turn on the charging with dpID 124=0 and setting the charging amps with dpID 115. 

TODO / HELP!:

* String types from TuyaMCU; There does not appear to be a setChannelType compatible with linkTuyaMCUOutputToChannel [id] str [ch]. i.e. channels can't handle string types. I experimented with linkTuyaMCUOutputToChannel MQTT  which does pass the string through to MQTT, but appears to be just for testing. The strings do appear in /cm?cmnd=DP if the TuyaMCU flag 47 is used.
* mapping string descriptions to the enums
* better interface for sending the commands other than 'TextField'
* Format all the values properly... _div10 isn't available on all channel types - though, I have worked around it using the mult argument in linkTuyaMCUOutputToChannel
* home assistant configuration for RW TextFields


- Work in Progress

@p.kaczmarek2 - I'm curious how something like linkTuyaMCUOutputToChannel 120 str 20 is supposed to work with real strings (not just a string cast to int)? Is there an existing way to send the value as a string to MQTT and HTTP that I'm missing via channel types? I can't find any instances where real str types are even used aside from in topic >>20881304 

Angel0fDeath wrote:

How can I write string to channel? I tried for instance SetChannel 1 "asdasdasd". Value was 0. Channel1 was defined as textfield

That is, attempting something like the below this always results in zero in the channel
however, if I use /cm?cmnd=DP with flag 46, I can see the string in the resulting JSON.

On the other hand, if I use the linkTuya MQTT argument you created for testing , I can see the string in MQTT, but only hex under /cm?cmnd=DP

Publishing val 00:04:20 to obk_car_charger/tm/str/120 retain=0


Are tuyaMCU string types just so rare that they are not handled? I'm open to raising a pull request for the necessary changes to have tuyaMCU strings pass to MQTT and http, but it's not clear what the desired approach is to do this.  Would it be to slap in a work-around by formalising the linkTuya MQTT argument, or create a new channel type for strings?

Channels are currently integers, there is no string support yet, but we may add one in the future.
Still, it would have to be well planned and organised, so it doesn't break things.
We've never had any real usage for TuyaMCU strings, well, maybe except the RGB colors, but they are handled separately.

The TextField type currently only alows to send an integer as well.

If you have any ideas how to add string channel types, then we can look into it together. I guess we would have to keep an array of strings (with fixed size?) along with array of integers and adjust all channel functions to work possibly with strings... lot's of things can go wrong there, hopefully self testing mechanism covers most of the use cases.

The MQTT feature you mentioned:

does not go through the channels mechanism, so it should be able to publish strings. That "DPs list" command should also display strings, as it's channels-independent.

I think the best approach would be to just allow string channels in general and make stuff works in somewhat "javascript" manner where we don't specify variable type but language determines it itself. Then we could even do string concatenation with channels and much more..?

Added after 35 [minutes]:

PS: tuyaMcu_sendState should be able to send string to TuyaMCU with current obk version. You can send tuyaMcu_sendState via MQTT.

Hi!

Seeing how this module is now supported by openbeken, were you able to flash it and test it?

https://www.elektroda.com/rtvforum/topic4097185.html

Somewhat neater than soldering a different module I think.

Is it possible to change max supported current (not charging current) from this setup? Or is this not exposed to tuyamcu and can only be set offline from the panel?

>>21505909

are you asking if you can turn a 32a model into a 60a or 80a model via tuyamcu? Aside from the hardware clearly being scoped for the model (6mm2 cables, 32a relays, etc), it doesn't seem possible to do via tuyaMCU. I'm struggling to imagine what practical use changing the supported current might have, what would you want to achieve with this?

dpID 113 is an enum described as DeviceMaxSetA ranging from 16-80a, but it is read only. I did try sending a different enum regardless, but it didn't stick.

I can however set the charging current above 32a, and tuyamcu saves the value, but I am not able to test if it actually provides more than 32a because my vehicle doesn't support it. I suspect it may allow sending a charge current to more than the supported current, given the supported minimum amps of the device is 8 and I can set it as low as 6 (my vehicle's minimum).

Is it possible to query the number of the authorized RFID card that initiated the charge?

>>21533260

it doesn't appear the RFID functionality is fully exposed to the TuyaMCU, but I suspect you could effectively accomplish this by monitoring dpID 101 (wait_rfid) and dpID 123 for change events to count swipes in autoexec.bat or in homeassistant.

The RFID features are pretty limited though (i.e. no separate identities, authorization, billing) and the reader is a separate board. If this were my project, I personally would be more inclined hack something together to manage the RFID independently which then sends commands to the charger via openbeken/tuyaMCU.

With the recent OBK updates, you can write custom data point processing logic in Berry. The tutorial for TuyaMCU + Berry will be posted soon. For now, I've only posted a basic guide:
https://www.elektroda.com/rtvforum/topic4117238.html
Still, you can check berry self tests for more info:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/selftest/selftest_berry.c

Just please note that while Berry is able to process dpIDs in a fully scriptable manner, it still will not help with something that is not sent by TuyaMCU to us at all.

Thanks for the previous answer regarding the RFID.
Could you check how the Pilot Signal handling works?
Does the Pilot Signal stop the charging or does it hard disconnect the high current with the high voltage relays?
Is it possible to pause the charging using the Pilot Signal or does it always step up the car's charging counter? (starts a new charge)

>>21540823


There is no 'pause' state for charging in the AC IEC 61851 for this type of charger that I could find. The IEC pilot states (A-F) are mostly reflected in dpID 101, so each stop/start charge could appear on your EV, depending on how your vehicle counts charge sessions.

This charger stops the session by dropping the voltage on the pilot pins to inform the vehicle that the session is stopping, and then disconnects the AC relay (I can hear my EV relays flip before the charger relay when issuing the stop command). The charger still remains at state B: vehicle detected after issuing the stop command so charging can resume simply with issuing another start charging command on dpID101.

The current can be changed dynamically between 6-32 amps while charging, which changes the PWM on the pilot pins. This is similar to Fronius and Victron chargers.

>>21541705 My experience:
1,
If the car's onboard timer says that immediate charging is not possible
I plug in the cable and it starts charging immediately instead of waiting, then after 10 seconds the car initiates the stop of charging. In this case, the car starts charging in the set time window or remotely with its own application.
Other chargers do not force the start of immediate charging when the cable is plugged in. Other chargers display that the car is connected and waiting for the car.

2,
If I stop charging on the EVSE side, it immediately cuts off the 3-phase relay, the car only turns off later, which is not good. The car should stop the current flow first and then the charger should turn off the voltage from the cable. This is not good for the car.