Open source firmware for XR809 compatible with Tasmota HTTP/Home Assistant

p.kaczmarek2 24744 30

This content has been translated

View the original version here.

Reply Cool? Ranking DIY | New topic

Notify about new articles

» | Positive voted Helpful post? (+36)

#1 23 May 2021 17:56

Hello
Here I will present a step-by-step process of writing my own open source firmware for the XR809 / XR3 WiFi module using the example of a door opening sensor. My firmware for it will be compatible with Tasmota HTTP protocol and will allow it to be used independently of the manufacturer's servers. It will also give us compatibility with Home Assistant and Tasmota Control application from Google Play. Perhaps it will be the first such open source firmware in the web for this module.
The software here will be created in C on ARM Cortex-M4F and it will be my first encounter with ARM.

What will we gain from creating open source software?
The situation here is the same as with ESP8266 and Tasmota/Domoticz vs. original manufacturer firmware. By using the open firmware, we gain:
- independence from the manufacturer's servers (e.g. if the manufacturer shuts his server down, our device will continue to work)
- no tracking and data collection from the manufacturer (some people are concerned about their privacy, some do not care)
- compatibility with other open source solutions (e.g. here it will be possible to easily connect the device to Home Assistant directly)

XR809 door sensor used
You can find more information about used XR809 / XR3 door sensor there:
https://www.elektroda.pl/rtvforum/topic3771510.html
Kit picture:

Photo inside:

XR809 is the ARM Cortex-M4F microcontroller operating at a frequency of 160MHz, offering 384KB SRAM and 2MB Flash ROM, additionally having rich peripherals, including UART, TWI, SPI, PWM, IrDA (T / R), SDIO and ADC:

The module itself is called XR, its pinout:

What will be descibed here?
Let's first create a short write-up of tasks that we will have to complete in order to create our own firmware for XR809.
Organizational tasks:
- preparation of the hardware connection necessary to upload the firmware (in case of XR809 an UART adapter is enough)
- preparation of the software that uploads the firmware from the computer to the chip (for XR809, it's called phoenixMC.exe)
- preparation of toolchain (compiler) and XR809 SDK
Tasks to be implemented in code:
- our firmware must offer a simple website (both for configuration and for Tasmota HTTP)
- our firmware must be able to read the state of the button and door opening sensor
- our firmware must offer pairing and RESET functions (we must be able to somehow enter our WiFi credentials once)

Tasmota HTTP protocol
All Tasmota HTTP can be visualized with one GET request sent via HTTP from the client (here: phone from Tasmota Control or machine with Home Assistant) to the server (our XR809 device).
GET query:

Quote:

GET /cm?cmnd=status HTTP/1.1
Host: 192.168.0.110
User-Agent: HomeAssistant/2020.12.1 aiohttp/3.7.1 Python/3.8
Accept: */*
Accept-Encoding: gzip, deflate

Sample answer:

Quote:

HTTP/1.1 200 OK
Content-type: application/json

{"Status":{"Module":0,"DeviceName":"Tasmota","FriendlyName":["Tasmota","Tasmota2","Tasmota3","Tasmota4"],"Topic":"tasmota_EC3F8F","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0},"StatusFWR":{"Version":"0.1(pic18f)","BuildDateTime":"2020-11-07T11:57:45","Boot":6,"Core":"0","SDK":"0","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"367/699"},"StatusNET":{"Hostname":"tasmota_EC3F8F-8079","IPAddress":"192.168.0.50","Gateway":"192.168.0.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.0.1","Mac":"5C:CF:7F:EC:3F:8F","Webserver":2,"WifiConfig":4,"WifiPower":17.0},"StatusSNS":{"Time":"2021-01-10T19:27:53","DS18B20":{ "Temperature":16},"TempUnit":"C"},"StatusSTS":{"Time":"2021-01-10T19:27:54","Uptime":"0T00:41:19","UptimeSec":2479,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":37,"MqttCount":0,"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","Wifi":{"AP":1,"SSId":"5G_FULL_POWER","BSSId":"30:B5:C2:5D:70:72","Channel":9,"RSSI":98,"Signal":-51,"LinkCount":1,"Downtime":"0T00:00:03"}}}

This answer is in JSON format.
This is a necessary minimum which allows you to read the status of the device. The state of the device is in two places:
- Power ": 0 - here the 0 is a bit-coded state of successive relays (or buttons). The number is written as decimal.
- "POWER1": "OFF", "POWER2": "OFF", "POWER3": "OFF", "POWER4": "OFF", -the relays/states are here repeated, but in a readable format. The number of states is automatically determined from the table ["Tasmota", "Tasmota2", "Tasmota3", "Tasmota4"] .

Protocol details:
https://tasmota.github.io/docs/Commands/

Setup of the work environment - Cygwin
Cygwin is necessary if we want to be able to compile XR809 firmware on Windows. Cygwin is an environment that mimics the Linux command prompt. It is needed here because the makefile from the XR809 SDK uses Linux commands like cp to copy the results of libraries compilation to a given folder. That's the only reason why Cygwin is necessary.
We can download Cygwin from here:
https://cygwin.com/install.html
During installation, after choosing to install from the network (Download) and the server from which we want to download packages, we have to select the components that we need:

We need search tthe list and mark here make .
After installing Cygwin, run the bat file:

This is how we get a Linux command line on Windows:

This is just like Linux terminal, the navigation is the same, except that when we want to go to disk partition D, for example, we type "cd d:" and it works, it just creates an artificial path /cygdrive/d

Setup of the work environment - ARM toolchain
The toolchain needed is gcc-arm-none-eabi-4_9-2015q2-20150609.
You can download it here:
https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q2-update
I chose the version for Windows and unpacked it to disk, while correcting the path so that there were no spaces (they might confuse stuff a bit, you have to remember about the quotes ...).
In the end, the toolchain path for me came out like this: In: /GNU/4.9.2015q2/bin

Preparation of the work environment - XR809 SDK from Git
We download the XR809 SDK from git, here:
https://github.com/XradioTech/XR809SDK/
You can do it by just by clicking "Download Zip" here:

Or you can download it via Git, you can use the command line or graphical interface, here I'm using Sourcetree:

After extracting/downloading, we need to update one file, gcc.mk .
We need to enter the cygwin path to the toolchain there:

Code: bash
Log in, to see the code

Here we are using Cygwin path, i.e. access to the disk via /cygdrive/ .

XR809 SDK content from Git
The SDK package is divided into shared libraries and separate examples.
Shared libraries are in a folder /src/ .
Larger examples are at /project/, smaller examples are at /project/example/, for example:

Build process
Firmware build for XR809 (and similar) is done in two steps. First, we compile the shared libraries, this folder:
XR809SDK/src/
Then we compile the selected project, for example:
XR809SDK/project/at_demo/
Compilation consists 4 commands.
Step 1.1:
In the directory /cygdrive/w/GIT/XR809SDK/ src we do make.

Step 1.2:
In the /cygdrive/w/GIT/XR809SDK/src folder, we run make install.
NOTE: this step requires linux cp command (copying files), so we run it in Cygwin. Windows doesn't have a Linux "cp" command in cmd, it does have its own (you could change the make build script to use Windows command set, but it's easier to use Cygwin).

Step 2.1:
In the /cygdrive/w/GIT/XR809SDK/project/at_demo/gcc folder (or in the project folder we selected), make:

Step 2.2:
In the same folder - make image:

This command will use mkImage.exe to generate xr_system.img (which we will then upload to XR809 via UART).
Result:

Simplify the build process
This step is not required, but I think that build process is too complicated and uses too many steps.
Let's simplify it and create a Bash script that will do it all with one command.
It's a linux script, but in cygwin it will of course work.

Code: bash
Log in, to see the code

If we get some errors related to \r (carriage return), it means that we wrote it with Windows line endings standard (\r \n) and we need to convert it to unix line ending. This can be easily done in, for example, Notepad 2:

Hardware connection
XR809 is programmed via UART just like ESP8266.
So let's prepare the cheapest dongle, USB TO TTL HW-597 (jumper set 3.3V logical levels):

In addition, according to the catalog note:

datasheet wrote:

During firmware burning, both PB02 and PB03 need to be connected to a low level. When the module works properly, PB02 and PB03 cannot be connected to a low level

For this pin EN - otherwise RESET - (to be able to reset the system). The board is battery powered.
So the connections made:

Burning the XR809 firmware
The compiled firmware is in file xr_system.img , this can be found in XR809SDK\project\at_demo\image\xr809 .
Now we need to use the programmer software, phoenixMC.exe
This program requires that the UART port is not in use, so remember to close the port in Realterm or whatever terminal we are using.
This phoenixMC.exe has chinese interface, but I figured out how to use it.
Here are the steps on the GUI (we open the generated img file):

On the hardware side:
1. connect RESET to ground
2. connect PB02 and PB03 to ground
3. disconnect RESET from ground (it can be in the air)
In other words, while booting, PB02 and PB03 must be on ground to enter programming mode.

datasheet wrote:

During firmware burning, both PB02 and PB03 need to be connected to a low level. When the module works properly, PB02 and PB03 cannot be connected to a low level

Then click Burn:

It should start uploading the firmware:

Upload ready:

Then we start XR normally, that is:
On the hardware side:
1. connect RESET to ground
2. disconnect PB02 or PB03 to ground
3. disconnect RESET from ground (it can be in the air)

Let's try running the XR809 AT firmware
We already know how to compile and upload the firmware. So we can upload the AT firmware (after its compilation, its binary files are not on the repo).
Now we should be able to execute commands via UART. The default baud is 115200.
Let's check the command AT + S.HELP (remembering CR LF, line feed and carriage return):

AT works.
Now let's try the command AT + S.SCAN .

The module sees the WiFi network. We are able to communicate with him.

Creating our own AT command for XR809
Well, let's start with something easy. We will add our own command to AT project. This command will connect XR809 to our WiFi. Of course, the final version of our firmware will not be using AT, but it's worth doing something like this just to check if everything is working correctly.
Commands are in at_command.c :

Here is a simple C table of command names, pointers to functions that handle them and short descriptions of these commands (for generating Help).
I used Notepad2 to edit the code (throughout the topic).
I added new command at the end:

Full function code (remember to add #include):

Code: c
Log in, to see the code

This command will connect XR809 to our WiFi.
Does our command work?

We can find out about the success of the process from the router logs.

In addition, it is worth checking if this is the MAC address that XR has (in AT there is a command to know it) and whether the ping command sees it (and ceases to see when we disconnect the power).

The first HTTP server
After a brief look at the SDK, you can see that the HTTP server library is ready to use.
Is in src\net\shttpd-1.42 .
The HTTP server demo is also ready, here: src\net\shttpd-1.42\examples\web_server_demo.c
Let's try to run it. Server setup will be called from command we added earlier. Of course you have to add #include etc, but surprisingly the files were already compiled (a bit strange that they compile web_server_demo.c for the shared library..):

Code: c
Log in, to see the code

After uploading the firmware and executing the command, the server works:

By the way, you can see that it was a server for a related chip, XR871, not for the XR809 I am using here, but I guess they are basically the same.
We will use this server as a base for Tasmota HTTP support.

Implementation of GET packet handler
After a brief analysis of the code from the XR809SDK\src\net\shttpd-1.42\examples\web_server_demo.c you can easily see how the GET request handling for a given URL is added:

Code: c
Log in, to see the code

You just have to provide the path and a handler function pointer.
So it's time to use shttpd_register_uri and add support GET /cm?cmnd=status HTTP/1.1 .
shttpd_register_uri takes as arguments a pointer to context (ctx), a URI path, and a pointer to a function.
To create my function, I copied and changed set_ap_info :

Code: c
Log in, to see the code

GET registration:

Code: c
Log in, to see the code

The result in the console after sending a GET:

There is still some kind of issue with parsing GET arguments, but we will fix it later.
The result in the browser:

And now the best part - it is now already compatible with Tasmota Control from Google Play.
https://play.google.com/store/apps/details?id=de.grings_software.TasmotaControl&hl=pl&gl=US
After adding device by IP, the result in Tasmota Control:

Of course, all these data are placeholders, i.e. everything is hardcoded.

Parsing of GET parameters
For a moment I was wondering why GET parsing is not working for me. This function is responsible for him:
(void) shttpd_get_var ("cmnd", arg-> in.buf, arg-> in.len, value, sizeof (value));
For POST it worked.
But the implementation of the function is self-explanatory.

Code: c
Log in, to see the code

arg->in.buf is an argument text buffer for POST, not GET.
For a GET, it needs to be given a string of GET arguments, like this:
(void) shttpd_get_var ("cmnd", query_string, strlen (query_string), value, sizeof (value));
After this change for the query GET /cm?cmnd=status we get:

This way we can extract the values of the GET arguments.

Reading the door status
Now it's to consider how can we read the door status from this sensor:

This sensor responds to the magnet, the magnet makes the contacts touch. In my opinion, it is enough to read the pin in digital mode.
I found examples of digital IO pins handling in XR809SDK/project/example/gpio/main.c

Code: c
Log in, to see the code

So I pasted them into the fragment of code I was testing and I also added a test-only request "tst" in the query string to check if the sensor detects something.

Code: c
Log in, to see the code

Door state display (only to check if it works, will be removed in next version):

Code: c
Log in, to see the code

And now, after uploading our firmware, it's time to check if door sensor works.
Test care - "Door closed":

Test care - "Open doors":

It works - it's time to integrate it with Tasmota HTTP.

The first signs of functionality
I cleaned up the code a bit and also connected the button from the board as the second input. Below is the code for generating the response to the Tasmota HTTP query (code specially written quite clearly, it could be done better and shorter, but less readable for beginners):

Code: c
Log in, to see the code

Result in Tasmota Control:

With active sensor ("closed door"):

With the button pressed:

So everything works.
The history in the UART console shows how often Tasmota Control polls the XR for the status:

Reset to AP mode - button on the HTML page
At the moment, my WiFi SSID and password are hardcoded into the firmware. I will now try to fix it.
It should be possible to enter WiFi data on the XR809 page.
First, I will add a website button to change XR809 wifi into an open Access Point.
The XR website is at src/net/shttpd-1.42/examples/source.h.

"Reset AP" button added:

We also need to add GET query support, just as before, this time for path /reset_ap:

And the function to handle it:

Code: c
Log in, to see the code

(I note right away that it would be better to wait 1 second in the main loop and then change the network state, because in the current version we will not get a response to this GET because the XR809 will disconnect immediately)
After pressing the button, we lose contact with the module and its WiFi network appears:

After connecting to this network, at IP address 192.168.51.1, we can reconfigure the module:

Here is our password and SSID (you still have to make the field to be of the password type, but it's not a problem, it's an HTML issue):

(actually I did not create an open AP here, but an AP with a known SSID and password, but it's the same. You could also add randomization of this "12345" in the SSID so that it includes the MAC for example)

Reset to AP mode - physical tactile switch on the PCB
Now we need to create something similiar to well know physical button reset process for smart devices.
We will make that pressing the on-board button for 5 seconds resets the device to the default AP (XR creates a WiFi network itself), so that we can then connect to it and configure it with data about our router.
We need to somehow check if the button is pressed for 5 seconds.
I decided to use the HTTP event polling loop, calling shttpd_poll blocks for 1 second, so just about right:

Code: c
Log in, to see the code

After my changes:

Code: c
Log in, to see the code

This works, but I suspect there's a minor bug here - shttpd_poll doesn't always block for 1000ms, it might block execution for shorter time if a packet arrives.
In the next version, I might change this XR's button library that handles debouncing and things like this by itself:

Code: c
Log in, to see the code

Details in project/example/button/main.c

Adding ability to control the on-board LED
Now let's try to share the on-board LED with Home Assistant via Tasmota HTTP. This way you would be able to control it any way you want.
It's not really necessary, as the device used here is a door sensor, but I think it can be interesting and useful to show how such thing is done.
The diode is connected here:

So we need to setup LED GPIO, PA12, in output mode:

Code: c
Log in, to see the code

Since we want to see its status through Tasmota HTTP, we need to add it to Tasmota HTTP status packet, for example as "Power3". It needs to be included in the "relays" state array:

Code: c
Log in, to see the code

In the code above, g_gpio_led, str_state3 and "Tasmota3" has been added.
And if we want to be able to control it, we also need to handle the package GET /cm?cmnd=Power1%20Off HTTP/1.1.
"Powers" are indexed from 1 (not from 0), states can be On or Off.
My parsing code for this (very prelimary, without any buffer overflow checks, etc):

Code: c
Log in, to see the code

And now, finally, we can blink this LED - via Tasmota HTTP:

One minor fix - the status pack short reply
I will not describe it in detail, because this part is purely within the knowledge of the C language in general, and not with XR809, but unfortunately we still have to be compatible with the short Tasmota HTTP response format, i.e. when asked:

Quote:

GET /cm?cmnd=POWER1 HTTP/1.1
Host: 192.168.0.110
User-Agent: HomeAssistant/2020.12.1 aiohttp/3.7.1 Python/3.8
Accept: */*
Accept-Encoding: gzip, deflate

We must answer:

Quote:

HTTP/1.1 200 OK
Content-type: application/json

{"POWER1":"OFF"}

(at this point, the program responds to this packet with the entire device status description)
See below for fixed version (and this version is finally compatible with Home Assistant):

Code: c
Log in, to see the code

Fixed IP
Due to the way Tasmota HTTP works (our device is a server, and we ask for its status), a fixed IP will be useful here. To make things simple, I did it by reserving the IP address for the MAC address on the router:

This could also be done via a specific host name and DNS.

Final test with Home Assistant
Finally, I tested the module from Home Assistant using the Tasmota HTTP support Python scripts described here:
https://www.elektroda.pl/rtvforum/topic3789324.html
that is the updated version of this plugin, HTTAS by JiriKursky:
https://github.com/JiriKursky/httas
ATTENTION - for the moment httas version from Github will not work with newer Home Assistant versions . This is due to a change in the way coroutines are handled. You will get an error: " ValueError: Coroutine not allowed to be passed to HassJob . "
Therefore, I recommend downloading my corrected version:
httas-fixe...210306.zip Download (6.91 kB)Points: 0.5 for user

In /config/configuration.yaml I set up the device location:

Code: yaml
Log in, to see the code

Then you need to reboot Home Assistant. In my case, it immediately detected XR809 after booting up:

"MyRel1" here is the door open state, "MyRel2" is the button state, "MyRel3" is the LED state.
The status of the LED can be changed from the Home Assistant. The other fields are read-only.
Short demonstration:

Automations in Home Assistant
My firmware allows us to do automations in the Home Assistant, for example, opening the door will turn on the LED (in its place you can put any HA compatible device):

Code: yaml
Log in, to see the code

switch.socket is the path to the entity previously set in /config/configuration.yaml

Increased sensor responsiveness
In the case of the door opening sensor, the reaction time of HA to a change in door state can be further decreased. This is done in the configuration, just add scan_interval (value in seconds):

If you get an error:

Quote:

Logger: homeassistant.components.hassio
Source: components / hassio / __ init__.py:420
Integration: Hass.io (documentation, issues)
First occurred: 11:53:21 (1 occurrences)
Last logged: 11:53:21

Invalid config for [switch.httas]: value must be at least 3 for dictionary value @ data ['switches'] ['socket'] ['scan_interval']. Got 1. (See?, Line?).

then you can reduce the minimum value in custom_components/httas/switch.py:

I think that the 1 second refresh interval even for the door status is sufficient.

Problems encountered
While exploring the XR809, I ran into one, rather unusual, problem. It cost me over an hour of time.
While working on our WiFi configuration system for the board (the RESET button creating an Access Point with a known password) I saw that suddenly the board resets (returns to main ()) when I want to create an AP or connect to an existing one.
The same result had the inclusion of the WiFi network scan - everything reset the board.
What do you think was the reason for this?
Spoiler answer:

Spoiler:

It turned out that during the work, the batteries were a bit too discharged and with their low level, the XR809 resets when WiFi activity starts. I fixed the problem by replacing the batteries with new ones.

The popularity of the XR809
Finally, I would like to make one small, final remark, because I know that not everyone could fully understand my intentions. Of course, I know that the XR809 and related ones are not very popular right now and there is much more ESP8266 devices, etc, but I wanted to show the general method of open firmware creation for an unknown chip. I also know there are some other chips, like WB2S or WB3S and I am also going to try figure them out soon.

For the user - how to use my XR809 firmware
My XR809 firmware described here is in a very early development version, but still it's functional.
So here's a short guide on how to use it.
1. Load my xr_system.img via UART to XR809 (from the project /at_demo/image/xr809/directory)
2. Press the button for more than 5 seconds
3. connect to xr-123etc wifi network, password 12345678
4. open 192.168.51.1, enter the SSID and password of our WiFi there on HTML page
5. Add MAC XR809 IP reservation on the DHCP settings of WiFi router (so IP won't change during some network outage or something)
6. In Home Assistant, add the Tasmota HTTP plugin (httas by JiriKursky, in case of any issues, use my fixed version with "coroutines" problem solved)
7. in Home Assistant, add the IP and configuration for our device in configuration.yaml

Further plans
At the moment, I plan to look at the purchased LCD thermometer / hygrometer, which also houses the XR809:

Then I will probably improve the code presented here a bit. Now it is a bit messy, and perhaps it could be crashed by some buffer overflow (when user sends malicious data). And you probably need to add save() call to save the WiFi configuration to the memory in case of removing the battery, but this is not a problem, because at_demo from the SDK has an example save function.

Summary
The firmware developed here has made my XR809 sensor completely independent from the manufacturer's servers and allows me to use it directly with the Home Assistant. Writing this software was basically like assembling it from ready-made components, because everything required was already in SDK, including the HTTP server. The amount of free time and the number of devices with XR809 (XR1, XR2?, XR3) will determine the continuation of the project.
The latest version of my code (entire modified SDK) is attached to this post, but please remember that version is before major rewrite and contains bad coding practises.

Attachments:

XR809SDK-updated-for-tasmota20210523-fx2.zip Download (24.27 MB) Punkty: 2 for the user

XR809_PIN_Multiplexing.pdf Download (79.24 KB)

XR809_Product_Brief_V1.0.pdf Download (500.05 KB)

XR809_Datasheet_V1.1.pdf Download (1.72 MB)

XR1 Module Datasheet_Tuya Smart_Docs.pdf Download (555.72 KB)

Cool? Ranking DIY
About Author
p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Offline

Joined: 26 Dec 2014

Posts: 5843

Help: 279

Posts rating: 5827

Points: 52838
p.kaczmarek2 wrote 5843 posts with rating 5827, helped 279 times. Been with us since 2014 year.
#2 23 May 2021 19:48

chemik_16 chemik_16

Level 25

» | Helpful post? (0)

#2 23 May 2021 19:48

Well now it's still a port for BK7231 and you are a famous man
#3 23 May 2021 20:19

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
» | Topic author Helpful post? (+1)

#3 23 May 2021 20:19

So WB2S, WB3S?
SDK for them is also on the network, I already have a flasher:

We'll see how it goes. As long as you have all the "puzzles" you need, it will also do.

PS: but do not confuse Tasmota HTTP with MQTT, I did Tasmota HTTP in the topic above, I did not implement MQTT, although you could also easily use the SDK for XR809.

Attachments:

bk_writer1.60-20210523.zip Download (302.2 KB)

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

chemik_16 chemik_16

Level 25

» | Helpful post? (0)

#4 23 May 2021 22:38

there is a whole set for 2 years, but no one has touched it, everyone is soldering these modules to esp.
https://github.com/bekencorp/bk7231_alios_sdk

systems installed in all cheap smart tuyas, such as sockets with current measurement (~ PLN 25) or switches.
#5 28 May 2021 03:08

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#5 28 May 2021 03:08

chemik_16 wrote:
Well now it's still a port for BK7231 and you are a famous man

The chances of the Bk7231 have increased significantly recently.

It looks like I can read (and upload?) The batch to him now:

I can compile some TUYA batch (although I haven't tested it):

And the batch zz bk7231_alios_sdk:

I also managed to eavesdrop on the debug output from WB2S (although it's rather a curiosity, unless this key ...)

Code: c
Log in, to see the code

But from what I can see there are two ways of programming - via UART and via SPI.

Does anyone have any WB2Sy desoldered?

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

varguit varguit

Level 2

Helpful post? (0)

#6 05 Jun 2021 23:38

Hi @p.kaczmarek2, first of all congrats for this great job.
I need help with the firmware uploading process, I'm using an old PL2303 USB to TTL (checked with the check tool and OK).
When starting the upload I get an error saying "Checking the 1 block error!"

Before uploading, I did the EN pin reset, but I don't know if the XR3 chip is in programming mode or not because led stops blinking after disconnecting RESET from ground.
It's my first time doing this and I'm not sure if everything is in position, I had to switch Rx and TX because otherwise I get synch failed error.

I have tried many different settings, baud rate, Rx/Tx switch, resets, etc... but the better I can get is what you can see on the photo.
Have someone any idea ?

Thanks.
#7 07 Jun 2021 16:26

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#7 07 Jun 2021 16:26

varguit wrote:
I had to switch Rx and TX because otherwise I get synch failed error.

Amazingly you are right.
In my diagram, RX and TX are swapped.
So here we connect RX to RX, and TX to TX. The producer has a strange convention on the descriptive layer.

varguit wrote:

Before uploading, I did the EN pin reset, but I don't know if the XR3 chip is in programming mode or not because led stops blinking after disconnecting RESET from ground.

are you sure you are doing?

p.kaczmarek2 wrote:
1.Reset connect to ground
2. connect PB02 and PB03 to ground
3.Disconnect RESET from ground (it can be disconnected)

?

Does your USB to TTL converter work at 3.3V logic levels? Did you check the connections with a multimeter?

You can also check if the RX / TX pins are connected somewhere on the board from your device. Maybe something of it interferes with programming? TX / RX lines busy?
I had such a case before, one smart switch on the TX line (or RX, I don't remember) used for the button, there was a pull up resistor on it that interfered with the programming. I had to unsolder it.
EDIT: I probably described it here: https://www.elektroda.pl/rtvforum/topic3749207.html

What exactly model do you have for this smart device with the XR809? I will be happy to buy them and check if I can program them

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

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#8 08 Jun 2021 16:14

Update. Good news - I found a fourth device with the XR3.
(by the way, it's interesting that people usually avoid smart devices that are not based on ESP, and that's what I'm looking for)

It looks like a remake of the door opening sensor that I already know. There will be no problem with his support.

So, at the moment the list of devices on the XR3 includes:
1. Smart Wifi Door Window Sensor Burglar Security Alarm For Alexa Google Tuya

2. LCD thermometer

3. Unknown PIR device from varguit user

varguit wrote:

4. Tuya Smart APP Wifi Smart Water Leakage Alarm Smart Home Mobile Phone Remote Sensor

If anyone knows more devices based on XR809, please let me know.

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

varguit varguit

Level 2

Helpful post? (0)

#9 09 Jun 2021 13:39

Hi.

Quote:
are you sure you're following:
p.kaczmarek2 wrote:
1. connect RESET to ground
2. connect PB02 and PB03 to ground
3. disconnect RESET from ground (it can be in the air)

?

is your usb to ttl convert in 3.3V mode? Have you checked all connections with multimeter?

Yes, I'm grounding RESET and PB02,PB03, and then releasing RESET.
If I do a reset without PB02 and PB03 to ground I can see the device rebooting, but if both PB02 and PB03 are conected to ground, Reset makes nothing in my device.
My usb to ttl has only two power pins, one for 5V and another one for 3.3V, my multimeter measures 3,4V aprox.

Quote:
Can you tell me the exact model of your smart device and where have you bought it? I am willing to buy it as well, so I can make a teardown and try programming it myself.

Of course, that would be very helpful, I would send you one if you were in Spain . It's a TUYA PIR device bought from Aliexpress at 8€ aprox
Here's the link:
Link

I'm gonna read your other topics to see if I can find where's my problem but my electronic acknowledge is very limited....
Thanks for your answer.
#10 20 Jun 2021 10:28

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#10 20 Jun 2021 10:28

EDIT: I checked the voltages and the XR809 supposedly works on 5V, so it should be ok (it works on 3.3V too)

so maybe it's not the UART voltage level that is the problem here

The information about the PIR sensor on the XR809 is very useful. I ordered it and the package has already arrived:

I'll try to program it soon.

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

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#11 23 Jun 2021 19:40

Today I tested programming and reading the firmware of the @varguit user device.
Everything works fine.
I can upload firmware:

Here are my connections. I used the same wire colors as @varguit. I just didn't have a battery, so I powered it all with 3.3V LDO.

WiFi from XR809 appears without a problem:

Reading the (factory) firmware also works:

I also made OCR of the characters from the program's gui and translated them into English:
?? \ - Read?

?? - Write?

?? - continuous

? ? ? ? - by translate to "Eliminate wedge", but that's probably about the size of the buffer

I can load both Flash and Configuration:

Sometimes I got "read payload data error", but after a few tries everything was fine

The loaded firmware can be opened in Notepad ++, of course most of them are not readable, but the text constants in ASCII format can be read. I wonder if IDA PRO would decompile it, I have to try it sometime.

We can also see the original names of the files with the source code there:

I attach firmware dumps (before the first pairing)
memory_A_0...200000.zip Download (459.76 kB) flash_A_0x...000000.zip Download (7.4 MB)

PS: @varguit, haven't you tried choosing a lower speed here?

PS2: Did you pair your device before ripping firmware? Maybe some update broke something?
PS3: maybe you have too low voltage, are you using new batteries?

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

__Maciek__ __Maciek__

Level 20

» | Helpful post? (0)

#12 25 Jun 2021 22:57

A bit offtop - but it was already touched

@ p.kaczmarek2 WB2S recently came to me with FK-PW802 sockets from a well-known auction site .. I try to figure out the examples from freertos (there is also RTT to choose from .. but due to the creators of a lot of bushes - although probably less than for AliOS)

https://github.com/bekencorp/bdk_freertos

Have you had a compilation problem? I haven't written for freertos before, this sdk layout is a bit strange for me .. but I'm trying to figure it out and go through the first compilation.
Did you check their forum? There are links to the documentation and forum, but I feel that some Chinese firewall is blocking ...
#13 26 Jun 2021 03:54

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
» | Topic author Helpful post? (0)

#13 26 Jun 2021 03:54

As for WB2S, I have made some attempts and it looks promising, but time was short. It was about a month ago, but I'll describe more or less what I know here.

I know 2 possibilities.

1. tuya-iotos-embeded-sdk-wifi-ble-bk7231t-master
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t
I managed to compile under Cygwin, everything is needed for the repo, but of course the basic configuration independence is required (I don't remember what I changed but it's simple):

compilation result:

It can be uploaded via UART using BK Writer:

Unfortunately, these SDKs contain examples that are probably a bit closely related to the Tuya environment:
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/blob/master/apps/template_demo/src/tuya_device.c
And I don't know how much it could be maneuvered there.

2. bk7231_alios_sdk
https://github.com/bekencorp/bk7231_alios_sdk/
It's a bit more fun with the configuration, you have to be able to install the Python you need and then execute a few commands, but the compilation also works:

... but BK programming is not successful, because alios SDK expects that we will have an ST-Link / V2 programmer and that it will upload the batch through it.

in addition, the batches generated by these two methods are of different formats, one is probably a full flash image, and the other is just a section loaded by the bootloader by uart

Actually, I have this programmer, but I did not have time to solder the cables where needed (and if ST link was needed, it is not a perfect solution):

A collection of WB2S and related links (collected a month ago):
https://mitxela.com/forum/topic/beken-bk3231/2
github.com/ct-Open-Source/tuya-convert/issues/884
https://fccid.io/2AMV5-SK509W2SN/User-Manual/15-SK509-W-2S-N-UserMan-US-r1-4836910.pdf
https://github.com/bekencorp/bk3633_mesh_sdk
https://fcc.report/FCC-ID/2ANDL-WB2S/4580213.pdf
https://developer.tuya.com/cn/docs/iot/wb2s-module-datasheet?id=K9ghecl7kc479
https://www.programmersought.com/article/54836791463/
https://developer.tuya.com/en/docs/iot/burn-and-authorize-wb-series-modules?id=Ka78f4pttsytd
oem_bk7231s_light_UA_2.9.5.bin
BK7231T pdf
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/blob/5e28e1f9a1a9d88425f3fd4b658e895a8ee7b83b/apps/bk7231t_light_pwm_demo/system/system/
https://www.programmersought.com/article/73156790997/

Didn't try what you gave, https://github.com/bekencorp/bdk_freertos. Plus I see it came out 24 days ago and I tried about 30 days ago. Something new.
But it looks promising at first glance, and there are concrete examples. If you know something more about it, write it, because I will probably try with this particular repository soon

And if some links do not work for you, give it here or at PW I will check it

Attachments:

BK72XX_SDK_User_Manual-3.0.3.pdf Download (705.04 KB)

Flash Firmware to and Authorize WB Series Modules_Tuya Smart_Documentation (1).pdf Download (841.57 KB)

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

__Maciek__ __Maciek__

Level 20

» | Helpful post? (0)

#14 26 Jun 2021 23:11

A bit of clicking and the RTOS is compiled .. for bk7231u .. .. I do not know how compatible it is with bk7231d ... or what he called BK7231T - initially there is a different version of BT4.0 vs 4.2 ..

The code also shows that there may be differences in DMA .. but they approached inconsistently and BK7231 throws dma warnings and errors with gpio.c
(in the header file there is a condition that the definition that causes the problem does not apply to bk7231, and in C they have already omitted.) although it applies to pins not used in WB2S so maybe it is not important) maybe there is something on the forum .. .. page bbs.bekencorp.com:8191 is not responding ..

- [Hardware Docs] (http://bbs.bekencorp.com:8191/forum.php?mod=forumdisplay&fid=57) - Download all kinds of hardware documents

I am in the code / I will throw some examples of bk7231u on WB2S and see what will come out of it.
#15 27 Jun 2021 00:58

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#15 27 Jun 2021 00:58

You mean GPIO_SD1_DMA_MODULE?

A google search for this leads to:
https://code.aliyun.com/MXCHIP_FAE/feiyan_sdk_for_alios/blob/38eaaa3a8e75920ec050d3d2984e7fa0ad6cf30b/platform/mcu/bk7231s/beken/driver/gpio/gpio.h

https://code.aliyun.com/MXCHIP_FAE/feiyan_sdk_for_alios/tree/38eaaa3a8e75920ec050d3d2984e7fa0ad6cf30b/platform/mcu

Here they have bk7231, bk7231s and bk7231u. And they are separate. On the other hand, in the rtos repo, it looks like they linked these SDKs together using a preprocessor and something went wrong.

This link does not open for me, but I will try to get a Chinese IP

By the way, how did you solve the missing application.h path?

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

__Maciek__ __Maciek__

Level 20

» | Helpful post? (0)

#16 28 Jun 2021 07:37

Hhmmm ... I compile without any errors in the original configuration for bk7231u. - clean repo project of course. (60K batch without bootloader)

(maybe toolchain ..? I was a bit troubled with this .. different versions ... ended up on 5.4_2016q3.) in the code different suggested versions were given .. but for freertos9 it was this period. I was also rummaging around the compilation switches - I turned off errors from the warnings - but eventually I went back to what it was.

Another thing - I noticed that there are different descriptions of WB2S modules .. and on the thuya website - there is already BT4.2 - so maybe it's this version ..bk7231u.

As for the application .. I tried to compile an example with a demo yesterday .. but here zonk always comes out the same ... during compilation it changes the data in the config file .. but I have to look at what and how (this file is not present in the repo / so the folder must be created in the compilation process - that's why it changes .. so I wonder .. where to configure what is to compile.?)

I need to find more time for this ...
#17 28 Jun 2021 12:34

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#17 28 Jun 2021 12:34

__Maciek__ wrote:
(maybe toolchain ..? did a little bit of a goof with this .. different versions ... ended up on 5.4_2016q3.)

How the toolchain version would influence the presence / path of the header ...

__Maciek__ wrote:
I turned off errors from the warnings

and I confirm this, the first thing I had to do

__Maciek__ wrote:
Hhmmm ... I compile without any errors in the original configuration for bk7231u. - clean repo project of course. (60K batch without bootloader).

I think I know why it was.
They have quite a mess there.
I uncommented in application.mk / entered the path to toolchain / home / tester / gcc-arm-none-eabi-4_9-2015q1 / bin / and thought it was ok because it compiles:

and it compiled, but it turned out that the same was given a second time in generate_sys_config.h:

and you also have to manually set the path there ... because the headers will not be generated without it.
Ultimately, however, I set the path through the environment variable:
export FREERTOS_EXEC_PATH = / home / tester / gcc-arm-none-eabi-4_9-2015q2 / bin

And it works, but in general it shouldn't be that they set the same variable in two places

Well, I also compile:

__Maciek__ wrote:

but here zonk always the batch comes out the same ... when compiling it changes my config

Config just generates generate_sys_config.h. And they actually copy it.

Open it and you can, for example, change it to 1 here:

__Maciek__ wrote:

I need to find more time for this ...

exactly, I also try to do normal projects during longer builds, and additionally with rtoos and related ones, I have not used ARM before (as I wrote in the first post)

I see that they have something in the repo regarding MQTT, probably rpzyda, for XR809 I also plan to run MQTT normally

Now I have to find how, according to the art, attach the files with C code to the compilation demo, because I do not see demo_start:

Of course, it is known that you could enter it into the makefile normally, but I have the impression that they have some system based on scripts
EDIT: ok, you know, here it is set:

Here you choose which demo you compile. Do as I wrote and you will have everything you need to pre-test if it works on WB2S

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

varguit varguit

Level 2

Helpful post? (0)

#18 29 Jun 2021 11:27

Hi there.

First of all, thanks for buying the same sensor and test it.
After many trials and errors I still can't flash it.

Following your information, I also tried reading original firmware first and it works, I get exactly the same result as in the image below:

I can save the original image, so, I'm pretty sure everything is right on the connections and communications part but it looks like something is wrong when checking the first block. I also tried to remake the xr_system.img, but still no succes. Maybe I have to buy a different UART (mine is very old and windows 10 drivers are not supported)

PS: right now I am not sure if it works, but have you tried setting lower speed here?
Yes, I've tried with different speeds, from 9600 to the maximum, always getting the same error.

PS2: have you paired your device with Tuya before flashing it? as far as I know it should not matter, it's not like tuya-convert, but... I didn't pair mine here. I only paired the door sensor from the first post with tuya before flashing, not the PIR sensor now.
Yes, it was paired, but I've deleted from the SmartLife app as well. I hope this is not the reason.

PS3: have you tried new batteries?[/quote]
Right now, I'm powering it from an arduino, directly to the battery contacts, as you do.
#19 12 Aug 2021 06:02

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#19 12 Aug 2021 06:02

@varguit , I just accidentally experienced similiar issue to yours. It happens every time when I try to flash XR809 with MCP2221 USB to UART converter, no matter what baud setting I set. I get random errors, sometimes 'synchron error', sometimes 'baud rate set error', and sometimes error while programming first block. On the other hand, it works smoothly if I just connect my TX/RX to USB to TTL HW 597 converter and leave everything else unchanged.
It seems that your UART must be fast enough to do the job, please try USB to TTL HW 597, it's cheap to buy online.
PS: I will try MCP2221A soon (MCP2221 works supposedly up to 115200 and MCP2221A to 460800)

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

joxumac joxumac

Level 1

Helpful post? (0)

#20 27 Aug 2021 13:29

Good morning, I have in my possession a Mini Smart Switch, which has inside a WB2S (BK231T) and I am trying to flash it to integrate it with home assistant without going through Tuya or Smart Life servers.

I have read the post and the attached documents and the progress with respect to this chip seems incredible to me.

Currently, I have been able to read the output of the chip by connecting the VBAT pins to 3.3V; GND to GND, 2RX and 2TX to TX and RX of my USB-TTL respectively. By setting a serial terminal at 115200 baud I am able to read what the chip prints to the terminal.

However, making only that connection I am not able to dump the flash memory to my pc (some users got it, how?). As I see comparing with the XR809 you have to have the PB02 and PB03 pins to GND, but those pins do not exist in the WB2S connection.

Do you have any idea how I can continue? (I have USB-TTL, ST-LINK v2, Arduinos, ESP and other components to carry out tests that need or see useful for the community and research)
(Attached table of pins according to your website )

Dodano po 2 [godziny] 24 [minuty]:

After carrying out more tests, making the same connection as before but this time connecting to 1RX and 1TX instead of the second line (2RX and 2TX), the BKWriter 1.60 software performs an empty memory dump (.bin) (to 115200 baud). If I open a serial terminal (at 115200 baud) the following appears (it is as if the baud were not correctly selected ??). I still can't make a backup of the original flash :'(
#21 14 Sep 2021 20:29

mihsu81 mihsu81

Level 2

Helpful post? (0)

#21 14 Sep 2021 20:29

@joxumac Keep the baud rate at 115200 in Device manager, but in Beken Writer you have to set it at 921600 when reading or writing.

Another thing to keep in mind is which IC is used by the USB-TTL. I could read and write just fine with a CH340G IC, but couldn't with a FTDI FT231X IC. In fact the "USB to TTL HW 597" mentioned as working by @p.kaczmarek2 has a CH340G IC.
Flashing is done on 1RX and 1TX and UAR debugging (serial output) on 2RX and 2TX.

And finally, the device must be powered off when you press the Read Flash or Write Flash buttons. Switch it on immediately after.

Now i have to see if i can compile the FreeRTOS mentioned by @__Maciek__ and @p.kaczmarek2 .
#22 15 Sep 2021 11:22

mihsu81 mihsu81

Level 2
Helpful post? (0)

#22 15 Sep 2021 11:22

Didn't manage to get any further than @__Maciek__ and @p.kaczmarek2 .

make bk7231 throws general_dma compile errors:

beken378/driver/general_dma/general_dma.c:37:15: error: 'gdma_get_dma_en' defined but not used [-Werror=unused-function]
static UINT32 gdma_get_dma_en(UINT32 channel)
^
beken378/driver/general_dma/general_dma.c:193:15: error: 'gdma_get_transfer_length' defined but not used [-Werror=unused-function]
static UINT32 gdma_get_transfer_length(UINT32 channel)
^
beken378/driver/general_dma/general_dma.c:371:13: error: 'gdma_enable_interrupt' defined but not used [-Werror=unused-function]
static void gdma_enable_interrupt(void)
^
beken378/driver/general_dma/general_dma.c:436:12: error: 'gdma_get_received_len' defined but not used [-Werror=unused-function]
static int gdma_get_received_len(UINT32 channel)
^
cc1: all warnings being treated as errors
make[1]: *** [application.mk:376: out/./beken378/driver/general_dma/general_dma.o] Error 1

And if you ignore the errors with make -i bk7231 looks like more drivers also fail to compile.

I've compiled and flashed the binary for bk7231n but the only thing i'm getting from serial is the below output repeated maybe 10 time per second:

V:BK7231S_1.0.5
CPSR:000000D3
R0:00000000
R1:00DFFEFC
R2:00802000
R3:F1CCFFFF
R4:00010000
R13:0043F7C8
R14(LR):0000BCBC
ST:BEDEAD01
J 0x10000

Which is strange because my WB2S has BK7231TQN32 and on Tuya's site it's listed as a BK7231T. On the other hand Beken doesn't have a BK7231T on their site but does have a BK7231S. Link

I guess I'll have to do more digging as time permits.

Update1:
Looks like this is the start-up message, so i guess the bk7231n firmware doesn't work.

Update2:
I've compiled the freely available documentation from Link after using a Chinese VPN .
Unfortunately for Link you'd need to register with a company account.
And gcc-arm-none-eabi-5_4-2016q3-20160926 is the correct toolchain as assumed by @__Maciek__. It's listed in Link.

In the attached files they also mention how to set up the tool chain in order to be properly recognized by make:
$ sudo mkdir -p /usr/local/share/toolchain/
$ tar xf gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2 -C /usr/local/share/toolchain/
Add the following environment to ~/.bashrc if you are using bash or ~/.zshrc if you are using zsh.
export RTT_EXEC_PATH=/usr/local/share/toolchain/gcc-arm-none-eabi-5_4-2016q3/bin
export FREERTOS_EXEC_PATH=/usr/local/share/toolchain/gcc-arm-none-eabi-5_4-2016q3/bin/[/u]

Attachments:

BK7231T COB Hardware Design Guideline_Tuya Smart_Documentation.pdf Download (6.07 MB)

BK72XX_SDK_User_Manual-3.0.3.pdf Download (705.04 KB)

BK7231 Documentation.docx Download (1.48 MB)
#23 23 Sep 2021 19:21

mihsu81 mihsu81

Level 2

Helpful post? (0)

#23 23 Sep 2021 19:21

Update 3:
Looks like the bekencorp/bdk_freertos repo Link is a dead end because it is not really configured for the SOC bk7231.
I managed to get around the compiling errors by adding #if (CFG_SOC_NAME != SOC_BK7231) in a bout 10 .c files based on what was actually defined in the .h files.
But i got stuck at the linking stage because the libraries for bk7231 are missing (libcal_bk7231.a, librwnx_bk7231.a, libsupplicant_bk7231.a) and i cannot compile them because the source files are missing and i cannot find the correct versions anywhere on github or gitee (libs or source files).
So i tried again compiling for the bk7231u. Based on some side testing with the tuya repo for bk7231t Link i realized that the boot loops are caused by the fact that the WB2S has an encrypted bootloader.
I encrypted beken7231u.bin from /out using encrypt v0.3.1 from the tuya repo (tools folder) using the passcodes from the tuya build script: encrypt beken7231u.bin 510fb093 a3cbeadc 5993a17e c7adeb03 10000.
And packaged it with beken_packager using the encrypted bootloader from tuya's repo bootloader_enc.bin.
I flashed beken7231u_enc_uart_2M.1220.bin and it boots now but not even the Hello World demo seems to run.
So i gave up on it for now.

Update 4:
I found on gitee a repo for RT Thread OS Link and decided to give it a shot.
You have to make sure you have python 2.7 and scons 3.1.2 because they're using scons instead of make.
You can configure which options/samples/packages are used by editing rtconfig.h
The resulting file rtthread.bin has to be again encrypted and packaged with the encrypted bootloader from tuya. and flashed with bk_writer.
The firmware boots, displays the finsh prompt but doesn't accept any input because it looks like the tshell thread and main thread get suspended immediately.
I'd be really grateful for some help in solving this last bit. RTTOS seems really promising as it also has MQTT, Webserver, etc.

#24 27 Sep 2021 08:56

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

#24 27 Sep 2021 08:56

Hey, sorry for the late reply. I just somehow didn't receive any notifications from this topic (again).

I'm not sure if I have managed to get more than you, I never made any packaging by hand, nor encoding.

I will just dump my current progress here in case that someone finds it useful.

Programming setup for WB2S:, RX and TX used for flashing, 2RX and 2TX used for debugging.

separate power supply.

COM5 is for programming in this case:

I can flash in this setup, but before flashing i must disconnect power (orange USB on my setup)

Tested firmware: bdk_freertos-release-v3.0:

it stucks in a boot loop:

Nothing from this repo works for me.

Tested firmware tuya-iotos-embeded-sdk-wifi-ble-bk7231t-master:
the exact file: template_demo_UA_1.0.0.bin
Build process:

Quote:

### Compile

The compile project is in the apps directory, you can quickly compile, burn, and run the process through `template_demo`. Use the following command in the root directory to compile:
``` bash
$ sh build_app.sh apps/template_demo template_demo 1.0.0
```
apps/template_demo: compile project path

template_demo: compile project name

My test line added to code:

Result:


        
V:BK7231S_1.0.5

CPSR:000000D3

R0:E56F05AF

R1:AC3E48E8

R2:6A7FBF7C

R3:5333FCE4

R4:CB643E15

R13:ABF7DBA7

R14(LR):B8FE67F7

ST:6CF21514

J 0x10000

prvHeapInit-start addr:0x41f4a0, size:133984
[01-01 18:12:15 TUYA Info][mqc_app.c:175] mqc app init ...
[01-01 18:12:15 TUYA Info][sf_mqc_cb.c:42] register mqc app callback
[01-01 18:12:15 TUYA Debug][mqc_app.c:118] mq_pro:5 mqc_handler_cnt:1
[01-01 18:12:15 TUYA Debug][mqc_app.c:118] mq_pro:31 mqc_handler_cnt:2
[01-01 18:12:15 TUYA Debug][uni_thread.c:215] Thread:sys_timer Exec Start. Set to Running Status
[01-01 18:12:15 TUYA Debug][log_seq.c:732] read from uf. max:0 first:0 last:0
[01-01 18:12:15 TUYA Debug][svc_online_log.c:288] svc online log init success
[01-01 18:12:15 TUYA Err][tuya_ws_db.c:314] kvs_read fails gw_bi -1
[01-01 18:12:15 TUYA Err][ws_db_gw.c:111] gw base read fails -935
[01-01 18:12:15 TUYA Debug][tuya_bt_sdk.c:89] ty bt cmmod register finish 1
[01-01 18:12:15 TUYA Debug][tuya_ble_api.c:301] ble sdk inited
!!!!!!!!!!tuya_bt_port_init
[01-01 18:12:15 TUYA Debug][tuya_ble_api.c:337] ble sdk re_inited
[01-01 18:12:15 TUYA Notice][tuya_bt_sdk.c:130] ty bt sdk init success finish
[01-01 18:12:15 TUYA Debug][tuya_device.c:259] < TUYA IOT SDK V:1.0.2 BS:40.00_PT:2.2_LAN:3.3_CAD:1.0.2_CD:1.0.0 >
< BUILD AT:2020_09_25_17_24_52 BY embed FOR ty_iot_wf_bt_sdk_bk AT bk7231t >
IOT DEFS < WIFI_GW:1 DEBUG:1 KV_FILE:0 SHUTDOWN_MODE:0 LITTL[01-01 18:12:15 TUYA Debug][tuya_device.c:260] template_demo:1.0.0
[01-01 18:12:15 TUYA Notice][tuya_device.c:261] firmware compiled at Sep 27 2021 07:47:11
[01-01 18:12:15 TUYA Notice][tuya_device.c:262] Hello, is this really working? Let's compile and check!
bk_rst:0 tuya_rst:0[01-01 18:12:15 TUYA Notice][tuya_device.c:263] system reset reason:[(null)]
[01-01 18:12:15 TUYA Debug][tuya_ws_db.c:438] init fs. Path: (null) 
[01-01 18:12:15 TUYA Notice][simple_flash.c:432] key_addr: 0x1ee000   block_sz 4096
[01-01 18:12:15 TUYA Notice][simple_flash.c:500] get key:
0xcb 0x4e 0x3e 0xa4 0x0 0x30 0x9d 0xab 0x65 0x6d 0x8d 0xbf 0xe4 0xb9 0x3f 0x35 
[01-01 18:12:15 TUYA Notice][tuya_main.c:311] **********[template_demo] [1.0.0] compiled at Sep 27 2021 07:47:10**********
[01-01 18:12:15 TUYA Debug][uni_thread[bk]tx_txdesc_flush
.c:215] Thread:cmmod Exec Start. Set to Running Status
[rx_iq]rx_amp_err_rd: 0x042
[rx_iq]rx_phase_err_rd: 0xfffffe01
[rx_iq]rx_ty2_rd: 0x095
*********** finally result **********
gtx_dcorMod            : 0x8
gtx_dcorPA             : 0xa
gtx_pre_gain           : 0x0
gtx_i_dc_comp          : 0x1fe
gtx_q_dc_comp          : 0x20d
gtx_i_gain_comp        : 0x3f4
gtx_q_gain_comp        : 0x3ff
gtx_ifilter_corner over: 0x11
gtx_qfilter_corner over: 0x11
gtx_phase_comp         : 0x20f
gtx_phase_ty2          : 0x200
gbias_after_cal        : 0x16
gav_tssi               : 0x22
g_rx_dc_gain_tab 0 over: 0x80788078
g_rx_dc_gain_tab 1 over: 0x80788078
g_rx_dc_gain_tab 2 over: 0x84788478
g_rx_dc_gain_tab 3 over: 0x94708c74
g_rx_dc_gain_tab 4 over: 0x94729472
g_rx_dc_gain_tab 5 over: 0x92709272
g_rx_dc_gain_tab 6 over: 0x93709270
g_rx_dc_gain_tab 7 over: 0x94719371
grx_amp_err_wr         : 0x226
grx_phase_err_wr       : 0x2dc
**************************************
ble use fit!
temp in flash is:250
lpf_i & q in flash is:17, 17
xtal in flash is:21
-----pwr_gain:12, g_idx:12, shift_b:0, shift_g:0
-----[pwr_gain]12
Initializing TCP/IP stack
[01-01 18:12:15 TUYA Notice][tuya_main.c:337] have actived over 15 min, not enter mf_init
[01-01 18:12:15 TUYA Notice][tuya_main.c:341] mf_init succ
[01-01 18:12:15 TUYA Debug][tuya_main.c:347] gwcm_mode 3
[01-01 18:12:15 TUYA Debug][tuya_main.c:349] low_power select
[01-01 18:12:15 TUYA Notice][tuya_main.c:109] have actived over 15 min, not enter mf_init
[01-01 18:12:15 TUYA Debug][tuya_main.c:354] no tuya_mdev_test1!
[01-01 18:12:15 TUYA Debug][tuya_svc_upgrade.c:736] tuya svc upgrade init success!
[01-01 18:12:15 TUYA Debug][gw_intf.c:7294] timer ID:13
[01-01 18:12:15 TUYA Debug][ws_db_gw.c:114] gw base read success
[01-01 18:12:15 TUYA Debug][tuya_tls.c:212] tls register constant 523e15a047ae3b9c KPkcZjoF5ZQblDhOmleZdgnCDxe83lM2 eWnxk86A7TeYIAwm2hwMcOm5finBANYlB9r5u
[01-01 18:12:15 TUYA Debug][tuya_tls.c:177] tls_ca_cnt:0 and parse:0
[01-01 18:12:15 TUYA Notice][gw_intf.c:3671] serial_no:d4a65130368a
[01-01 18:12:15 TUYA Debug][ws_db_gw.c:242] gw_wsm read success
[01-01 18:12:15 TUYA Notice][gw_intf.c:3706] gw_cntl.gw_wsm.stat:2
[01-01 18:12:15 TUYA Notice][gw_intf.c:3709] gw_cntl.gw_wsm.nc_tp:3
[01-01 18:12:15 TUYA Notice][gw_intf.c:3710] gw_cntl.gw_wsm.md:0
[01-01 18:12:15 TUYA Debug][uni_network.c:264] unm_set_dns_cache_priority ->0

[01-01 18:12:15 TUYA Debug][ws_db_gw.c:387] gw_di read success
[01-01 18:12:15 TUYA Debug][gw_intf.c:3455] gw_ctrl_init_stride from flash: 0.
[01-01 18:12:15 TUYA Debug][gw_intf.c:3480] gw_ctrl_init_stride: version no changed.
[01-01 18:12:15 TUYA Notice][gw_intf.c:3754] gw_cntl.gw_if.abi:0 input:0
[01-01 18:12:15 TUYA Notice][gw_intf.c:3755] gw_cntl.gw_if.product_key:rg2urjcogbu14wci, input:rg2urjcogbu14wci
[01-01 18:12:15 TUYA Notice][gw_intf.c:3756] gw_cntl.gw_if.tp:0, input:0
[01-01 18:12:15 TUYA Debug][ws_db_gw.c:513] gw_ai read success
[01-01 18:12:15 TUYA Debug][uni_network.c:273] unm_set_dns_region 2

[01-01 18:12:15 TUYA Debug][iot_httpc.c:1242] cache dns [http://a.tuyaeu.com/d.json]<->[58267675]
[01-01 18:12:15 TUYA Debug][iot_httpc.c:1252] cache dns [https://a3.tuyaeu.com/d.json]<->[314833289]
[01-01 18:12:15 TUYA Debug][iot_httpc.c:1258] cache dns [m2.tuyaeu.com:1883]<->[597437044]
[01-01 18:12:15 TUYA Debug][iot_httpc.c:1268] cache dns [m2.tuyaeu.com:8886]<->[597437044]
[01-01 18:12:15 TUYA Debug][ws_db_dev.c:228] schema 000002zixe read success
[01-01 18:12:15 TUYA Debug][gw_intf.c:4020] dev bfc8682d112f0a2066a6rp bind schema [{"mode":"rw","property":{"type":"bool"},"id":1,"type":"obj"},{"mode":"rw","property":{"type":"bool"},"id":7,"type":"obj"},{"mode":"rw","property":{"min":0,"max":86400,"sc[01-01 18:12:16 TUYA Debug][gw_intf.c:4423] Bind Dev Attach Success bfc8682d112f0a2066a6rp 1
[01-01 18:12:16 TUYA Debug][gw_intf.c:3950] enter success_proc
[01-01 18:12:16 TUYA Info][gw_mqc_cb.c:475] register mqc app callback
[01-01 18:12:16 TUYA Debug][mqc_app.c:118] mq_pro:11 mqc_handler_cnt:3
[01-01 18:12:16 TUYA Debug][mqc_app.c:118] mq_pro:22 mqc_handler_cnt:4
[01-01 18:12:16 TUYA Debug][mqc_app.c:118] mq_pro:41 mqc_handler_cnt:5
[01-01 18:12:16 TUYA Debug][mqc_app.c:118] mq_pro:100 mqc_handler_cnt:6
[01-01 18:12:16 TUYA Debug][mqc_app.c:118] mq_pro:51 mqc_handler_cnt:7
[01-01 18:12:16 TUYA Notice][tuya_bt_sdk.c:148] ty bt update product:rg2urjcogbu14wci 0
[01-01 18:12:16 TUYA Debug][tuya_ble_api.c:152] update product_id type:0 rg2urjcogbu14wci 523e15a047ae3b9c KPkcZjoF5ZQblDhOmleZdgnCDxe83lM2
[01-01 18:12:16 TUYA Debug][gw_intf.c:3267] --------------nc_tp:3, md:0
[01-01 18:12:16 TUYA Debug][tuya_iot_wifi_api.c:479] register wifi network monitor. interval:1
[01-01 18:12:16 TUYA Debug][app_agent.c:288] TUYA Mode, start TUYA thread to listen Lan
[01-01 18:12:16 TUYA Debug][app_agent.c:318] cmmod register finish 1
[01-01 18:12:16 TUYA Debug][gw_intf.c:977] gw_wsm stat:2
[01-01 18:12:16 TUYA Notice][tuya_device.c:278] status_changed_cb is status:3
[01-01 18:12:16 TUYA Notice][tuya_bt_sdk.c:157] ty bt update localkey
[01-01 18:12:16 TUYA Debug][tuya_ble_api.c:162] update login key len:6
[01-01 18:12:16 TUYA Info][mqc_app.c:215] mqc app start ...
[01-01 18:12:16 TUYA Debug][mqc_app.c:296] MQTT Protocol URL:m2.tuyaeu.com:8886 Port:8886
[01-01 18:12:16 TUYA Debug][mqc_app.c:319] TLS in not disable. disable mqtt time check
[01-01 18:12:16 TUYA Debug][mqc_app.c:131] TLS Mode is NOT TLS_DISABLE:2 .set username = gwid
[01-01 18:12:16 TUYA Debug][mqtt_client.c:266] subcribe_topic:smart/device/in/bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][mqtt_client.c:267] client_id:bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][mqtt_client.c:268] user_name:bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][mqtt_client.c:269] passwd:9da78c4eb100a69c
[01-01 18:12:16 TUYA Debug][mqtt_client.c:300] domain<0> m2.tuyaeu.com:8886 HAVE PORT
[01-01 18:12:16 TUYA Debug][mqtt_client.c:303] PARSE m2.tuyaeu.com:8886
[01-01 18:12:16 TUYA Debug][mqtt_client.c:331] wakeup_domain_tbl<0> m2.tuyaeu.com:1883 HAVE PORT
[01-01 18:12:16 TUYA Debug][mqtt_client.c:334] PARSE m2.tuyaeu.com:1883
[01-01 18:12:16 TUYA Debug][mqc_app.c:382] mqtt send topic:smart/device/out/bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][mqc_app.c:384] mqtt-media send topic:d/m/o/bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][tuya_svc_timer_task.c:150] read timer:{"lastFetchTime":0,fast_connect
"cnt":0}
[01-01 18:12:16 TUYA Debug][log_seq.c:462] [svc_timer_task] seq: 3,ldt:3,ls_stat:0, 1
[01-[bk]tx_txdesc_flush
bssid 30-b5-c2-5d-70-72
security2cipher 2 2 16 16 security=5
cipher2security 2 2 16 16
enter low level!
mac d4:a6:51:30:36:8a
leave low level!
0 low level!
[01-01 18:12:16 TUYA Debug][mqc_app.c:118] mq_pro:15 mqc_handler_cnt:9
[01-01 18:12:16 TUYA Debug][tuya_svc_upgrade.c:778] tuya svc upgrade active success!
[01-01 18:12:16 TUYA Debug][svc_online_log.c:212] mqtt log topic init log/realtime/bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][svc_online_log.c:213] mqtt log topic init log/log_seq/bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][svc_online_log.c:214] mqtt log topic init log/runstat/bfc8682d112f0a2066a6rp
[01-01 18:12:16 TUYA Debug][mqc_app.c:118] mq_pro:55 mqc_handler_cnt:10
[01-01 18:12:16 TUYA Debug][svc_online_log.c:310] svc online log active success
[01-01 18:12:16 TUYA Debug][astro_timer.c:122] update time delay 113s
!!!!!!!!!!tuya_bt_reset_adv
[01-01 01:00:01 TUYA Notice][tuya_ble_api.c:398] ble adv && resp changed
[01-01 01:00:01 TUYA Debug][uni_thread.c:215] Thread:gapm_cmp_evt_handler opewk_th-0 Exec Start. Setration = 0x1, status =  to Running Status
0x0[01-01 01:00:01 TUYA De d:lpc_task Exec Start.bug][uni_thread.c:215]  Set to Running Status
Thread:lpc_task Exec St
gapm_cmp_evt_handler art. Set to Running Statussid:MY_WIFI_NAME, 1
ht in scan
scan_start_req_handler
o
STACK Is
[01-01 01:00:01 TUYAN1:00:01 TUYA Debug][ap Debug][app_agent.c:575p_agent.c:575] begint to] begint to execute __l execute __lpc_task
blpc_task
e create new d[01-01 01:00:01 TUYA DebUYA Debug][uni_thread.bug][uni_thread.c:215] c:215] Thread:mq_cntl_tThread:mq_cntl_task Exeask Exec Start. Set to Rc Start. Set to Runningunning Status
ble_env- Status
[01-01 01:00:0>:00:01 TUYA Debug][mqt1 TUYA Debug][mqtt_cliet_client.c:1271] __mq_cnt.c:1271] __mq_ctrl_tatrl_task start
gapm_cmpsk start
_evt_handler operation = 0x1b, status = 0x0 
CREATE DB SUCCESS
[01-01 01:00:01 TUYA Debug][tuya_ble_api.c:267] rev ble event 3
!!!!!!!!!!tuya_bt_reset_adv
[01-01 01:00:01 TUYA Notice][tuya_ble_api.c:398] ble adv && resp changed
!!!!!!!!!!tuya_before_netcfg_cb
appm start advertising
found scan rst rssi -49 > -50
found scan rst rssi -51 < -50
dis ht_support
me_set_ps_disable:840 0 0 0 383793 874896
sm_auth_send:1
sm_auth_handler
ht NOT in assoc req
sm_assoc_rsp_handler
rc_init: station_id=0 format_mod=0 pre_type=0 short_gi=392521 max_bw=875407
rc_init: nss_max=0 mcs_max=0 r_idx_min=255 r_idx_max=392563 no_samples=875474
__l2_packet_send: ret 0
__l2_packet_send: ret 0
sta_mgmt_add_key
ctrl_port_hdl:1
me_set_ps_disable:840 0 0 0 383793 874896

configuring interface mlan (with DHCP client)
new ie: 0 : 44 4c 49 4e 4b 5f 46 61 73 74 4e 65 74 
new ie: 1 : 82 84 8b 96 c 12 18 24 
new ie: 3 : b 
new ie: 30 : 1 0 0 f ac 4 1 0 0 f ac 4 1 0 0 f ac 2 0 0 
new ie: 2d : ef 11 1b ff ff 0 0 0 0 0 0 0 0 0 0 80 0 0 0 0 0 0 0 0 0 0 

[01-01 01:00:02 TUYA Debug][tuya_main.c:217] wifi netstat changed to:5  -->>
[01-01 01:00:02 TUYA Debug][tuya_main.c:264] wifi netstat changed to:5  <<--
[01-01 01:00:02 TUYA Debug][tuya_iot_wifi_api.c:447] wifi netstat changed to:5  -->>
[01-01 01:00:02 TUYA Notice][tuya_device.c:442] wf_nw_status_cb,wifi_status:5
[01-01 01:00:02 TUYA Debug][tuya_iot_wifi_api.c:450] wifi netstat changed to:5  <<--
do td cur_t:261--last:idx:13,t:250 -- new:idx:14,t:262 
--0xc:08, shift_b:0, shift_g:0, X:2

It's a lot of text, but I notice two things.
1. somehow this device still remembers my SSID of AP, despite being flashed several times. It must be somewhere else in the memory
2. the test line I added in C code is here:

So far only https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t works for me, but sadly, it seems to be a pretty limited environment. Still, it's something we can work with, at least try to compare the compilation process here with different SDKs

If you wanto to check, here is a firmware that created log above with my insreted line "[01-01 18:12:15 TUYA Notice][tuya_device.c:262] Hello, is this really working? Let's compile and check!"
template_d...Printf.zip Download (923.46 kB)

UPDATE.

i tried injecting a timer into the template and it works as well.
Here is my code + my version of device_init:

I just copied some stuff from the LED example.
https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/blob/master/platforms/bk7231t/bk7231t_os/beken378/app/led/app_led.c
Here is a result:

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

#25 27 Sep 2021 10:50

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#25 27 Sep 2021 10:50

UDPATE 2:
Here's my first blink LED demo for WB2S:

My code (inserted into tuya_device.c):
Code: c
Log in, to see the code

I am also attaching whole template_demo from tuya-iotos-embeded-sdk-wifi-ble-bk7231t, which I build on Windows with Cygwin.

My experimental LED blinking resides in apps\template_demo\src\tuya_device.c, while the generated binaries are in apps\template_demo\output\1.0.0.

Btw: the RED led seems to be the relay as well, I can hear the faint clicking, it's faint because I am powering the board with 5V while it seems to be using 12V for relay, so there is not enough power for relay to work.
Most of smart device relays are 5V-powered, but this one here is pretty beefy and requires whole 12V.
template_d...210927.zip Download (9.83 MB)

UPDATE 3.
I have managed to get UDP stuff working. It's pretty easy to do with all these examples.

As you can clearly see
1. the WB2S is running an UDP listen server on port 55000,
2. the C# client sends UDP string "Is anybody there?"
3. the WB2S receives the string and prints it to UART
4. the WB2S sends back reply "Hello reply 2",
5. The C# code receives it and prints it to console

I have used C# as UDP sender, here is C# code:
Code: csharp
Log in, to see the code

and BK as server (obv), same WB2S module as before, here is code:
Code: c
Log in, to see the code

I must admit that I kinda lucked out with having WB2S already connected to my WiFi. I didn't write the code for that so far, it was just that this WB2S module was paired with my router while I tested it with Tuya before flashing it, and module still remembers it. My router sees this WB2S as "wlan0", a very confusing name.

[/syntax]

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

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#26 27 Sep 2021 19:03

I've came back from the dinner and decide to play around WB2S a bit more.

UPDATE 4 - WB2S MQTT Send/publish seems to be working now
Sorry for the post below post, but I think the progress is big enough to justify it.

I have managed to get MQTT working - at least partially.
See the Wireshark screenshots below:

Wireshark is able to recognize MQTT packets and decode MQ Telemtry Transport Protocol contents.

As you can see, WB2S is doing MQTT publish with topic "pub_topic" and value "PubSubHubLubJub".

And here is the code used to publish:
Code: c
Log in, to see the code

I call it from my timer, which I mentioned in previous post.
Here:
Code: c
Log in, to see the code

I think you'd do the same for any kind of movement or temperature sensor. Just do the readout and publish results.

Of course, you need also to initialize the MQTT client. Here is my init code, altough creditentials might be messed up.
Code: c
Log in, to see the code

You also need to setup mqtt_connect_client_info_t and of course include library and fix little linker issue. It's too long to explain in detail now, but when I get it fully working I will write a guide.

But here is a readme from used MQTT library (it's already in SDK):
mqtt_cli..t.txt Download (5.24 kB)
As you can see, I have used MQTT module from lwip-2.0.2 library. Please be aware that there is also a second MQTT module which seems to be present only as precompiled library, and you will have to manually add MQTT.c to make list, enable certain #defines and rename mqtt_disconnect to mqtt_disconnect_my2 (because two libraries have function with the same name, apparently..), see screenshots:

I will try to do a Home Assistant compatibility demo soon, but I am low on free time so I am testing with C# TCP server so far.
Code included below:
Code: csharp
Log in, to see the code

PS: I don't know if you're aware of it, but lwip-2.0.3 library is also present in XR809 sdk by XRadioTech, so getting it to work would get us MQTT support for BOTH xr809 and wb2s devices

UPDATE 5 (final one) - WB2S MQTT compatibility with Home Assistant

It took longer than I expected, there were some unforeseen issues.

It turned out that MQTT user/password fields are not supported by lwip-2.0.2, in spite of their presence in mqtt_connect_client_info_t !!

See, the struct definition:
Code: c
Log in, to see the code

My initialization code (which obv didn't work at first):
Code: c
Log in, to see the code

When investigating the problem, I made a comparison of MQTT connect packet sent by MQTT Explorer (nice windows tool!) and WB2S, and look:

(don't worry, this password is used only for my testing instance of HA)

Compare carefully both images. The WB2S version is missing user/pass fields!
It's just because they are not handled at all in mqtt.c:
Code: c
Log in, to see the code

Those flags:
MQTT_CONNECT_FLAG_USERNAME = 1 << 7,
MQTT_CONNECT_FLAG_PASSWORD = 1 << 6,
are not set at all!

so I have added support for them:
Code: c
Log in, to see the code

Then I decided to use JSON format to encapsulate my data and try to simulate a temperature sensor.
Here is how I built MQTT publish content:
Code: c
Log in, to see the code

The sin here is just to make the graph more interesting so I can see if it really works well.

Finally, I added the MQTT yaml to HA config, and voila:

Btw, I observed two strange things:
1. Home Assistant gives me no indication whasteover when it receives MQTT packet without user/pass information, nothing at all in my log, even with 'debug mode'
2. Even extra 0 (null terminating character) at the end of json string can break HA

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

tlessosk8 tlessosk8

Level 1

Helpful post? (0)

#27 22 Nov 2021 15:24

Hey did you thought about bringing it to a github repo, so I could somehow falsh this to my XR809. If you need help and If I can help I´m happy to .
#28 30 Nov 2021 00:46

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

#28 30 Nov 2021 00:46

Hello @tlessosk8 , it's nice to see more and more people here.
Sorry for the late reply, but don't worry, the project is definitely NOT dead!

I was just busy with doing the same for WB2S module, here is the polish version, English version is coming soon:
https://www.elektroda.pl/rtvforum/viewtopic.php?p=19736807#19736807

As per your question, I will try to make github repo soon.
PS: I think that my current WB2S experience with MQTT can be easily applied to XR809, so MQTT support for my XR firmware is also coming soon!

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

strigona strigona

Level 2

Helpful post? (0)

#29 30 Nov 2021 01:18

Hey, I only just stumbled across this forum when searching for information on SOC BK7231T that is the brains of the Prime Wire Smart Outlets (CCWFIO232PK). Do you think it'll be possible to build a Home Assistant compatible firmeware for BK7231T?

I'm a software developer, but primarily on web/systems level and doing have a lot of experience on embedded devices. The smart plugs I have are easy to open up (3 screws) and the PCB is fairly accessible, though I don't think I'll have fun soldering on wires:

Long story short, is there anything I can do to help with development?
#30 30 Nov 2021 01:59

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

#30 30 Nov 2021 01:59

Hello @strigona, it's nice to see you here on Elektroda.

I think there is a good chance of supporting CCWFIO232PK in the future. It depends mostly on the bootloader presence in BK7231T chip.
If present bootloader is similiar to one used here https://www.elektroda.pl/rtvforum/topic3850712.html , then most of the basic work is already done and with current SDK and my examples. You could easily modify my MQTT demo to get basic MQTT/Home Assistant switch support working, but right now most of miscellaneous work is mostly done by placeholders, for example, WiFi creds are hardcoded.
If bootloader is missing or it's different, then most likely you'd have to use ST-link with bk7231_alios_sdk but I haven't tried it yet. Or just use ST-link to read WB2S chip bootloader and put it in your CCWFIO232PK and then use my WB2S tutorial. Also haven't tried it. First I need to get my hands on the module you're showing.

The first thing I'd suggest you to do in this specific case it to check whether BKwriter 1.60 is able to read flash from UART. Just like I described here:
https://www.elektroda.pl/rtvforum/topic3850712.html
just use "Read flash" button.
This will allow us to determine if your chip has the same bootloader as WB2S module.

NOTE: don't get discouraged by seeing read BK firmware contents looking like a random binary garbage. It seems that some kind of encryption is done on whole .bin file. This is good, thanks to that WiFi creds are not longer plain text. Because you know - they WERE plain text on ESP modules and one was able to easily read them out from their memory...

strigona wrote:
Long story short, is there anything I can do to help with development?

I will create a list for all the readers.

If you want to help:
1. Report here (or preferrably in WB2S topic, because this one is XR809) all WB2S/BK7231T and similiar devices (with information where to buy them, I need them for testing)
2. You can try yourself following my steps from here https://www.elektroda.pl/rtvforum/topic3850712.html (topic will be translated soon to English) and report back here results
3. Remember that you can support me on paypal https://paypal.me/openshwprojects so I can buy more devices for testing. I am going to support really lots of them.
4. Soon I will also create a github repo, where you could create pull request and patches. Right now you'll have to wait, also I need to get more familiar with more advanced git concepts, I have mostly used SVN in the past.
5. Of course just sharing this thread somewhere where more people can see it will also help.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600 and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects
Create an account, log in and become active in a forum and ads will not appear. You will receive points by participating in discussions.
Join this discussion.

Log in with Google

Reply Cool? Ranking DIY | New topic

Notify about new articles