![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/3221612800_1643065166_thumb.jpg)
Hello, here I will present the progress report of my work on the open firmware for BK7231T. This topic will be written in the form of a tutorial, I will present here step by step how I developed my own, cross-platform (running on Windows and BK7231T) mini HTTP server, pin configuration system via the web panel and how I connected it with MQTT and ultimately with Home Assistant. Of course I will attach here full source code for download and a Visual Studio project for those who want to play with my server under Windows.
First part of the story
This topic is a continuation of this thread:
https://www.elektroda.pl/rtvforum/topic3850712.html
Official repository
As per users requests, here is public repo:
https://github.com/openshwprojects/OpenBK7231T
Topic content
In this topic, I will present:
- how to write your own simple C-language HTTP mini-servers on Windows
- how to prepare this server to be multi-platform and run it on WB2S / BK7231T
- how to organize cleverly a pin configuration for the BK7231T in Tasmota style
- how I finally organized the pin configuration and MQTT support for my open firmware for BK7231T
- as in the case of the current version of the project, run my firmware on my own system from the BK7231T series (WB2S, WB3S, maybe others) and connect it to the Home Assistant via MQTT
Why will the server be multi-platform?
For the following reasons:
- it will allow me to efficiently create a website for the configurator and management of the BK7231T module on Windows without having this module physically, without the need to upload a firmware to it, which takes a long time, etc.
- this will allow me to use the same configurator and page in the case of another family of systems that I also intend to "open", and more specifically XR809
- to some extent it will force me to better organize the project and keep everything compiled on all platforms and emphasize the division into modules
NOTE - C and networking basics
I will try to present the topic as interestingly as I can, but for obvious reasons I have no way to explain everything line by line, and I will not explain the absolute basics of C, HTTP and TCP. In addition, in the topic I allow myself some simplifications that should not be used in the target product, such as using the dangerous strcat function (it does not check if there is room for what we copy in the target buffer).
Own HTTP server - work organization
I decided to write my own HTTP server in Visual Studio C ++ 2008 Express Edition. This is the IDE I have worked with the most and I know it quite well so the choice for me was obvious, but you can use any other C/C++ compiler.
This IDE compiles my server to Windows platform (exe) - the HTTP server in the initial phase will be created and tested on this platform.
Own HTTP server - starting point
HTTP is a protocol that operates at the TCP level (not to be confused with UDP). TCP was chosen here by the creators of HTTP due to the reliability of the transmission, and more specifically the support for retransmission of lost packets, which UDP does not offer (UDP is connectionless). So we will start with a simple TCP server written under Winsock (which is basically practically 1: 1 compatible with sockets under Linux and also those on BK7231T):
Code: c
The above code opens the listening on port 80 (we cannot have it busy on our machine - when we have, for example, Apache running, the port will be already occupied and the program will not take it over), so we can "talk to it" from a web browser (in fact, you could use any other port - you can include the destination port in the URL, but let's not complicate it).
If there is a client, the code above handles it and maintains a TCP connection with it.
We are most interested in three sections of this code.
This is where the packet is retrieved (recv blocks the program until it receives something, although it can be nonblocking on Berkeley sockets):
Code: c
Here we create the text that we will send:
Code: c
We send it here:
Code: c
Let's run the program:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/5429470400_1643037166_thumb.jpg)
You need to enter an address in your browser. You can also enter IP. Our IP (those in the LAN - type 192.168 etc.) can be found, for example, with the ipconfig command, but there is an easier way to refer to our machine. You can use the localhost address, which is 127.0.0.1:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/1912638400_1643037311_thumb.jpg)
As we can see, the server replied "This is an example reply from my server". What did it receive?
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/1370630600_1643037344_thumb.jpg)
Here we can see the content of an example GET request:
GET / HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Microsoft Edge";v="97", "Chromium";v="97"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 Edg/97.0.1072.69
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: pl,en;q=0.9,en-GB;q=0.8,en-US;q=0.7
The most important thing is the ability to navigate the pages - let's see how the package will change when we ask, for example, about the index subpage:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/4085670400_1643037564_thumb.jpg)
This time request looks like this:
GET /index HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
What about the arguments of the GET query? These are the arguments that we even see on the Electroda when we write a message, for example:
https://www.elektroda.pl/rtvforum/privmsg.php?mode=reply&p=6195972
How will our server display them?
GET /rtvforum/privmsg.php?mode=reply&p=6195972 HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
We'll parse this in a moment, but first a little tweak.
Our program displays strange characters after received packet:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/9754169200_1643037694_thumb.jpg)
This is because the package does not contain the NULL terminating character, which is a byte zero that marks the end of an ASCII string. We will add it manually:
Code: c
I added setting the next next byte (outside the packet, because we address arrays in C from 0) to 0 (NULL byte). In addition, I reduced the size of the available buffer by 1, so as not to go beyond its range.
Own HTTP server - parsing the current page
Parsing the current page, that is, extracting the target resource address on the server, I will do completely from 0. You can do it in various ways, you can copy this address to another variable (such smarter strcpy), or you can check it "in place" and only get the result true / false if it matches the given ...
But first we need to check if this is a GET query at all. For this I prepared my own function http_startsWith :
Code: c
The function sequentially compares two strings of characters, passes character by character. ++ increments the pointer by one unit (here it points to char, a byte-sized type, so one byte).
Now the package handling looks like this:
Code: c
The program will reject queries without the "GET" header. Now let's move on, let's do a function that checks if the resource address requested by the client matches the given name:
Code: c
The function works like the previous one, except that it stops the comparison when it encounters a space or question mark. This is because in the query:
https://www.elektroda.pl/rtvforum/privmsg.php?mode=reply&p=6196006
the resource (php file) address ends before the question mark, then there are GET arguments.
Let's try to use our function:
Code: c
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/8382359800_1643038460_thumb.jpg)
It works! Recognizes which page we are asking about.
Own HTTP server - argument parsing
Now it's time to somehow read in the arguments that follow the question mark in the body of the GET request. The format of the arguments is fairly simple, we have a question mark, then a variable name, an equal sign, the value of the variable and if there is anything else then the & sign and the next variable.
rtvforum/privmsg.php?mode=reply&p=6196006
We will also load this ourselves. This time, however, we will move the value of the variable to a separate buffer. In this case there is a high risk of "buffer overflow" problems and in the production version every effort should be made to prevent this from being possible, but for this demonstration I will not go into more detail. I will only add that exceeding the buffer size may even allow remote execution of malicious code in our program ...
Code: c
Here I have a function that checks the name of the argument and copies its contents to an external buffer separately. The important thing here is the handling of characters such as & and '' and the byte zero telling us that we need to stop parsing.
I'm not saying here that my approach is the best (because here I iterate all arguments in this http_getArg function call, and when I want to load 5 different arguments, I will iterate all 5 times), but on such a scale it doesn't matter.
As a demonstration of this parsing, let's make a simple calculator:
Code: c
The program above checks if both arguments are available. If so, it prints their sum (atoi converts string to integer, and sprintf converts, among others, integers to string), and if not, it shows the appropriate message:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/7492782900_1643039063_thumb.jpg)
The program works.
Of course, sending the reply by HTTP is still to be done.
Own HTTP server - sending a response
What should the server send us in response to a GET request?
It is best to find out in practice. I used Wireshark for this - a packet capture tool:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/6137094100_1643040581_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/6104054400_1643040607_thumb.jpg)
You can see that typical HTTP answer consists of two layers:
- HTTP layer
- the content of the response itself (usually html, although there may also be an image, etc., depending on the content type)
The answer can be simplified to:
HTTP/1.1 200 OK\r\n
Content-Type: text/plain\r\n
\r\n
First we have the famous code 200 OK (analogous to the 404 you probably know), and then the type of content. Then one blank line - that's important too. After that we have the answer content (eg. html text).
Let's enter it in the code:
Code: c
Of course, the Content-type can also be different (e.g. for a picture), but we don't need that here. The text/javascript format will be for Javascript files, which may also be useful in the future.
And let's prepare a helper function that initializes the HTTP header:
Code: c
And let's do some content on the HTTP page:
Code: c
Is it working?
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/6554901700_1643040775_thumb.jpg)
Our first HTML page written on our own HTTP server is up and running!
Own HTTP server - cross-platform
We moved away a bit from the WB2S / BK7231T topic, but now it's time to come back to it.
Let's think - how can we organize our server to run on Windows and WB2S at the same time?
A cut has to be made - we separate Windows stuff into one place, HTTP stuff into another.
From now on, my old main.c file (where the winsock code is) is called win_main.c and it contains:
Code: c
The HTTP_ProcessPacket function is in another file, it takes the input packet and the output buffer as arguments (yes, then you need to add a check if you are not exceeding the range).
The HTTP_ProcessPacket function is now in a new file - new_http.c:
Code: c
Of course you also need to make a header (.h, header file and be able to #include it) - but I assume we know C ...
Code: c
This feature allows us to use our server on any platform, including the BK7231T.
On the BK7231T we connect to the TCP code (just set it to listen on port 80) like this:
Code: c
For convenience, I added detection of how many fields have actually changed.
NOTE: All of the above (including switching channel / relay values) can be tested in my batch in the Windows version! You don't even have to have WB2S to develop it and work on it. Very comfortable.
Connecting the pins for BK7231
My pin configurator and the HTTP server work fully on Windows. This is possible because the pin handler associated with BK7231T is appropriately separated in the new_pins.c file:
Code: c
However, the change of the channel value itself is independent of the platform:
Code: c
Yes, one int represents the channel values - one bit equals one channel. Therefore, the limit of the number of channels is now 32.32 bits in an integer on a 32-bit platform.
Connecting the MQTT service (sending channel changes to the MQTT server)
I wrote about the MQTT itself in the first part. Here I will only show when and how information is sent that the user pressed a physical button on the casing and changed the state of the device.
This callback (pointer to function) is used for this:
Code: c
Let's see what the use of CHANNEL_SetChangeCallback looks like, already on the BK7231T side, in tuya_device.c:
Code: c
The code in the above version does not distinguish which channel has been modified, it just does MQTT publish the values of the first channel (CHANNEL_Check (1)) to the MQTT server it is connected to.
Connecting the MQTT service (receiving commands from Home Assistant)
The other way communication is carried out in an analogous way. From the MQTT you can get the command to change the channel value to another (to 1 or 0) and then we have to use CHANNEL_Set to propagate it further to the pins.
The reception of this by the MQTT looks like this:
Code: c
We have separate functions for publish (variable name) and data (its value), but at the moment I am not using it to make things more complicated. I just assume there is one channel and that is enough for simple situations.
Possibility to rigidly configure in code
The current version of the project does not support saving settings to Flash memory, so it is worth configuring everything for our device in the code. For me it looks like this:
Code: c
The settings above work fine on SmartSwitch Tuya WL-SW01_16 16A:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/8086816100_1620677696_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/7376866800_1642985473_thumb.jpg)
Connecting to the Home Assistant
Connecting to the Home Assistant is very simple. It requires modification of the configuration.yaml file, where we include, among others what MQTT publish we are listening to:
switch:
- platform: mqtt # Again, it's an MQTT device
name: "WB2S" # Choose an easy-to-recognize name
state_topic: "wb2s/get" # Topic to read the current state
command_topic: "wb2s/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
[i] NOTE: the final code in this topic requires a different MQTT name format, no longer wb2s / get but wb2s / 1 / get where 1 is the channel / relay name, details later.
Similarly, on the WB2S side, you also need to complete the information on our MQTT server and the command names, respectively:
Code: c
Code: c
Code: c
Full code in the attachment at the end of the topic.
Demonstration of operation - version with one relay
Below is a presentation of the action on the video:
[movie: cd6415ef5e] https://filmy.elektroda.pl/24_1643033014.mp4 [/ movie: cd6415ef5e]
As you can see (I hope - because there are problems with the electrode player on some browsers) Home Assistant immediately responds to pressing the physical button on the device, and the device responds immediately to clicking on the status change on the Home Assistant website. Communication is efficient and fast, it is very responsive.
The only thing missing is refreshing the device's own page, but this can be added quite easily via a JS script.
Support of multiple relays on one device
Supporting multiple relays on one device turned out to be quite simple to implement. It was possible mainly thanks to the so-called MQTT wildcards, which allow you to listen to multiple topics at the same time.
The modified subscription setting with wildcard (+ sign) looks like this:
Code: c
This code above is used to receive information about changes from Home Assistant through MQTT.
Just receiving subscriptions now requires dereferencing and saving the channel index (so far I did it in a trivial way, then it will improve):
Code: c
Wildcard (plus) is replaced with the channel index.
The announcement of the change from the WB2S / WB3S level now looks like this:
Code: c
Simply put, the channel (relay) index is also stored in the message.
For testing, I used this 4-relay driver on the WB3S:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/4080361700_1642985485_thumb.jpg)
Now also the way of defining relays in Home Assistant in configuration.yaml changes. From now on it looks like this:
switch:
- platform: mqtt # Again, it's an MQTT device
name: "WB2S" # Choose an easy-to-recognize name
state_topic: "wb2s/1/get" # Topic to read the current state
command_topic: "wb2s/1/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
- platform: mqtt # Again, it's an MQTT device
name: "WB2S2" # Choose an easy-to-recognize name
state_topic: "wb2s/2/get" # Topic to read the current state
command_topic: "wb2s/2/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
- platform: mqtt # Again, it's an MQTT device
name: "WB2S3" # Choose an easy-to-recognize name
state_topic: "wb2s/3/get" # Topic to read the current state
command_topic: "wb2s/3/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
- platform: mqtt # Again, it's an MQTT device
name: "WB2S4" # Choose an easy-to-recognize name
state_topic: "wb2s/4/get" # Topic to read the current state
command_topic: "wb2s/4/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
A few explanations:
- "wb2s" here is the proper name of the device (if we have two devices, it will have to be changed, e.g. in the code ...)
- in the name "wb2s / X / get" the X character means the channel number (relay number)
- if we have a single relay, we only use "wb2s / 1 / get" and "wb2s / 1 / set"
- payload values tell what we are sending (or receiving) to determine the state of the device, just 1 or 0 here
Result:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/2274989500_1643063827_thumb.jpg)
What does the WB2S module require to run?
I wasn't quite sure where I should put this paragraph, so I'll just leave it here.
I received from @pixelo some desoldered WB2S modules, which are as found for testing.
I checked that such a module does not require any external connections except a 3.3V power supply to work. It can also be easily programmed.
Below is a photo report from soldering / commissioning:
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/9776726900_1643064620_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/7778286000_1643064620_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/5463156500_1643064697_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/5928429900_1643064770_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/4698239900_1643064961_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/3508870800_1643064989_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/2739077800_1643065019_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/3681423200_1643065086_thumb.jpg)
![[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant [BK7231T] My HTTP server, configurator, MQTT support from Home Assistant](https://obrazki.elektroda.pl/7057488800_1643065031_thumb.jpg)
The module prepared in this way works, one UART is used for programming, the other is for receiving the log.
I do not describe the connections themselves, because I described them in the first topic of the series.
How to add support for a new device?
Below I present full instructions on how to add support for a new device from BK7231T to the current version of my project.
[This section will be updated soon because Pin Configurator is now working]
1. Download the latest version of the SDK from this topic (complete the missing toolchain in \ platforms \ bk7231t \ toolchain)
2. Complete the data in apps \ my_alpha_demo \ src \ tuya_device.c
- SSID and password in connect_to_wifi
- MQTT username and password in mqtt_connect_client_info_t
- MQTT server IP at ipaddr_aton
- optionally change the device name in MQTT packets in tuya_device.c, i.e. in "wb2s / + / set" change "wb2s" to a unique name, different for each device in your network (similarly for get)
3. Complete the pin configuration in apps \ my_alpha_demo \ src \ tuya_device.c in device_init:
Code: c
4. Compile the project "my_alpha_demo" following the instructions from here:
https://www.elektroda.pl/rtvforum/topic3850712.html
5. Upload "my_alpha_demo" according to the instructions from here:
https://www.elektroda.pl/rtvforum/topic3850712.html
6. Complete configuration.yaml from Home Assistant according to the pattern:
switch:
- platform: mqtt # Again, it's an MQTT device
name: "WB2S" # Choose an easy-to-recognize name
state_topic: "wb2s/1/get" # Topic to read the current state
command_topic: "wb2s/1/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
- platform: mqtt # Again, it's an MQTT device
name: "WB2S2" # Choose an easy-to-recognize name
state_topic: "wb2s/2/get" # Topic to read the current state
command_topic: "wb2s/2/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
- platform: mqtt # Again, it's an MQTT device
name: "WB2S3" # Choose an easy-to-recognize name
state_topic: "wb2s/3/get" # Topic to read the current state
command_topic: "wb2s/3/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
- platform: mqtt # Again, it's an MQTT device
name: "WB2S4" # Choose an easy-to-recognize name
state_topic: "wb2s/4/get" # Topic to read the current state
command_topic: "wb2s/4/set" # Topic to publish commands
qos: 1
payload_on: 0 # or "on", depending on your MQTT device
payload_off: 1 # or "off", depending on your MQTT device
retain: true # or false if you want to wait for changes
Ready!
A pin configurator is available, but it doesn't save the settings to Flash yet, so it's basically just for us to play and experiment.
Testing support on Windows
The final version of the project (the one I'm publishing here) still supports the compilation of the HTTP server and pin / relay / channel system for Windows via the Visual Studio environment - just open the myHTTP2022.vcproj project from the my_alpha_demo folder and compile. After starting it, it will put us a server on port 80 on our machine. Thanks to this, it is much easier and faster to develop the entire HTTP module from the project, test the appearance of different pages, change the division into subpages, etc.
Further development of the project
Of course, this is only an initial demo and I'm going to add soon:
- easier handling of MQTT devices (random name based on the MAC address of the device, the ability to change this name via the web)
- saving the settings to the flash memory so that you do not have to recompile the project forever
- system for resetting the device and configuring it via an open WiFi network
- XR809 support (the same HTTP code will be and the organization for two different families of microcontrollers)
- maybe I will move partially to Ajax with this HTTP panel of the page, for example to refresh the states of the buttons / relays ...
Project support
If you like the idea and initiative, you can support the project through
- testing (in some time I will create a github repository for both projects, because I'm also doing an open source batch for XR809)
- collecting information in what devices are what modules (you can send photos, etc., even in this topic. I know about the list https://templates.blakadder.com/)
- paypal donation:
https://paypal.me/openshwprojects
(There are some of these different devices and I want to test as many of them as possible, moreover, I have already put a lot of teardown at https://www.elektroda.pl/rtvforum/forum507.html, the funds will go to the purchase of more devices)
- if you have, for example, BK7231T modules that you have left after replacing with ESP12F or damaged smart devices, etc., I can accept them for testing (contact PW)
There are many more modules similar to WB2S and WB3S, each of them I intend to ultimately support.
Summary
This is how the world's first open source firmware for BK7231T really starts to take shape. From a few simple demos of UDP, TCP, HTTP and MQTT presented in the previous part, I have already managed to make the first really practical firmware, which could finally be used in a normal 'smart' home to control lighting and more (if we do not add Relay, we can read the states of "Buttons" and work on them in Home Assistant, so the door opening sensor, etc).
Another update is coming soon. If you like the initiative, let me know, I need to know how many potential users we have and what is the interest in the whole idea.
Finally, I would like to thank @strigona and @PIXELLO for giving me test modules.
Cool? Ranking DIY