When the change with the number of digits after the decimal point will be introduced (I am asking out of curiosity), I have a free mini switch with measurement - I can test on it
Everything is uploaded on a regular basis, the command: should be in the last build. can you test?
I try to test myself and @DeDaMrAz helps a lot lately, and I also write self-tests, but still, there can be mistakes.
piratee wrote:
Is it possible to change the time of data publication after mqtt - I can't find it?
Which data? There are commands for that, separately for Tasmota-style TELE and for regular publishes.
piratee wrote:
I noticed one more thing that after reboot the state of "channel"=1 is 0.0 instead of 1 Build on May 1 2023 06:08:19 version 1.17.77 When I turn it on and off it does 1. Restart misreads the state of the relay.
The relay is disabled by default. Are you using something like "startup value -1", i.e. remembering the previous state?
I also throw a flag that allows you to turn on energy reporting in kWh instead of Wh. You can also test it and let me know if it's ok. Today I will also be making a tool for easy testing which GPIO has what role.
I added fields for the second WiFi network, but connecting to it is not programmed yet. For now, these fields do nothing.
In general, why do you have two channels on a socket with one relay?
And yes, I'm going to check it on my LSPA9 right now.
You can't see the kWh flag because it was just uploaded, or rather you didn't update the software today.
The field for SSID2 is there, but it's not ready yet, it won't connect.
EDIT: Okay, I'm testing this with Startup 1, on my LSPA9 with a nice uptime of 27 days: EDIT2: And that's interesting, you're seriously right, the first refresh shows it wrong: I'll check it right away.
Added after 4 [minutes]:
EDIT: Oh, now I know why it didn't refresh, I'm uploading a fix and it will be correct from the next build, thanks @piratee
Only the next version, which will appear in a few minutes, will have a fix for displaying the channel with the startup value. Now it still compiles, as evidenced by the "orange ball" at commit: Our builds are done automatically online, but you have to wait a few minutes after uploading the patch to receive binary files.
If you have time, I'm uploading GPIO Doctor in the evening, which allows you to quickly test on which pins the relays are (so as not to search manually): You know what it is, right? As the device is fresh after uploading the firmware, you need to look for which GPIO is, for example, a relay, and this tool from the screen will allow you to easily click it without refreshing the page at all.
ok I have one mini diy switch because I bought it from a Chinese by mistake - I wanted to buy a 2-channel dimmer and now I have a dispute with him about the wrong description, I'll practice it but I don't know if I'll make it tonight.
PinDoctor (or what should I call it?) will require an OBK update, but it works pretty well already: Thanks to this tool, you will be able to quickly find GPIOs with a relay and a push-button and an LED (WiFi or regular), again and again testing the pins, also in the title LSPA9, as well as in any other product.
Are these other recently added things working ok? In case of problems, please report what is wrong.
I fired the version: Build on May 5 2023 10:21:44 version 1.17.104 But somehow I don't really know how to test GPIO Doctor. You have to do the settings and look what is happening or will it detect what is connected to the pin?
edit: if it is possible, is it possible to specify the offset with NTP? "2 drivers active (NTP,BL0942), total 34"
- nicely changed the units to kWh - set the precision of the results nicely
Such questions/issues. 1. Do all commands issued in the console/startup in OpenBeken work only as if in RAM - until the next restart? I'm asking because in Tasmota (yes, I know, it refers to it again, but I have dozens of devices on it and I'm used to it 😊), once a command is issued, it saves the state in memory, e.g. calibrations, NTP server address or all types of SetOptions. More than once I got caught that I issued a command in the AppGUI, and after the restart (which took place a few weeks later) I was surprised why something works differently. 2. Why is MQTT transmitted while Home Assistant Discovery does not create the appropriate entities for this data? 3. Why is the "consumption_stats" entity created? It still has an unknown state. Maybe I don't know something. 4. It would be nice if entities could be created in HA by Discovery by default (enabled in HA at the request of the admin) such as: signal strength in %, IP address, Uptime, Host
I got another (LSPA9 clone) noname socket from Aliexpress for $2.99 today. I also tried to change via CloudCutter, but again it has a different version of Tuya, which is also not supported, so probably tomorrow, I mean during the day, I will disassemble, program and then I can test "GPIO Doctor" - although in my opinion the name "GPIO Tester" is more suitable .
P.S 2 more LSPA9 clones on the way from Aliexpress Choice
VREF/PREF etc. probably doesn't exist anymore, calibration is like in Tasmot, it saves itself. But only her.
Dark Man wrote:
Such questions/issues. 1. Do all commands issued in the console/startup in OpenBeken work only as if in RAM - until the next restart?
No calibration, VoltageSet/CurrentSet, saves itself, no need to do IREF at all. The rest is not saved in flash.
Dark Man wrote:
I'm asking because in Tasmota (yes, I know, it refers to it again, but I have dozens of devices on it and I'm used to it 😊), once a command is issued, it saves the state in memory, e.g. calibrations, NTP server address or all types of SetOptions. More than once I got caught that I issued a command in the AppGUI, and after the restart (which took place a few weeks later) I was surprised why something works differently.
Indeed, not very fortunate, I'll think about it, but in general there are a lot of options and the configuration structure is quite monolithic (maybe it was better to go the key/value route but it's quite late) and it's just easier to leave it blank. Plus, we still have ours safemode what turns on after 5 failed reboots, it skips autoexec.bat and startup command, so it's kind of a feature that all drivers are configured by startup commands, because in case of problems safemode allows you to save the device - e.g. if a bad configuration would crash it ... but I know, it's not a very strong argument (you could selectively skip things anyway).
Dark Man wrote:
2. Why is MQTT transmitted while Home Assistant Discovery does not create the appropriate entities for this data?
This is probably the result of cooperation with two contributors who probably did not communicate well and Mr @iprak did not include what @valeklubomir publishes in Discovery ... I will deal with it soon, but it's good that you pay attention.
Dark Man wrote:
3. Why is the "consumption_stats" entity created? It still has an unknown state. Maybe I don't know something.
It's JSON. There's some data there. This can be enabled/disabled with the SetupEnergyStats command. Here's a screenshot of what it looks like now from the contributor:
Dark Man wrote:
4. It would be nice if you could create entities in HA by Discovery that are disabled by default (enabled in HA at the request of the admin) such as: signal strength in %, IP address, Uptime, Host
I plan to make a more configurable Discovery on Web App, because Web App is hosted on Github and takes practically nothing in Flash memory (only API takes up flash, Web App does not).
Dark Man wrote:
Today I received another (LSPA9 clone) noname outlet from Aliexpress for $2.99. I also tried to change via CloudCutter,
but again it has a different version of Tuya, which is also not supported, so probably tomorrow, I mean during the day, I will disassemble, program and then I can test "GPIO Doctor" - although in my opinion the name "GPIO Tester" is more suitable.
I'll think about the name, I'll admit that I saw your post quite late. And now there is a new solution. How to download the new flasher from here: https://github.com/openshwprojects/BK7231GUIFlashTool And before you load the 2MB backup, he can see the Tuya configuration: and get the pinout/JSON to paste into Web App:
Dark Man wrote:
2 more LSPA9 clones on the way from Aliexpress Choice
Let me know what came, I had no way to order a second one, because I think one per account (or even per IP/system, I don't know how they fingerprint, unless changing the user agent didn't help).
@piratee also see the new flasher from here: https://github.com/openshwprojects/BK7231GUIFlashTool for simple devices should be able to detect pins by itself and give their list / JSON to be copied to Web App ->Import
VREF/PREF etc. probably doesn't exist anymore, calibration is like in Tasmot, it saves itself. But only her.
I didn't add these PREF VREFs myself... - they added themselves to startup commands
p.kaczmarek2 wrote:
Dark Man wrote:
I'm asking because in Tasmota (yes, I know, it refers to it again, but I have dozens of devices on it and I'm used to it 😊), once a command is issued, it saves the state in memory, e.g. calibrations, NTP server address or all types of SetOptions. More than once I got caught that I issued a command in the AppGUI, and after the restart (which took place a few weeks later) I was surprised why something works differently.
Indeed, not very fortunate, I'll think about it, but in general there are a lot of options and the configuration structure is quite monolithic (maybe it was better to go the key/value route but it's quite late) and it's just easier to leave it blank. And in addition, we also have our safe mode which is activated after 5 failed reboots, it omits autoexec.bat and startup command, so it's kind of a feature that all drivers are configured by startup commands, because in case of problems, safe mode allows save the device - e.g. if a bad configuration would crash it... but I know, it's not a very strong argument (you could selectively skip things anyway).
I do not deny that Safe Mode is most needed. I can only write what it looked like in Tasmota - Tasmota, with incorrect configuration or bootloop, turned off individual configuration modules one by one (probably 5 stages) through the pinout until the transition to the Wifi Access Point.
p.kaczmarek2 wrote:
Dark Man wrote:
3. Why is the "consumption_stats" entity created? It still has an unknown state. Maybe I don't know something.
It's JSON. There's some data there. This can be enabled/disabled with the SetupEnergyStats command. Here's a screenshot of what it looks like now from the contributor:
1. I probably turned it on unnecessarily (encouraged by the message in the basic GUI), because I thought it was necessary to count the consumption "today", "yesterday", "total" 2. even if it has already created this entity, at least in the attributes it could put what it actually sends via MQTT, what you showed on the screen, instead of just giving the "unknown" status
p.kaczmarek2 wrote:
Dark Man wrote:
4. It would be nice if you could create entities in HA by Discovery that are disabled by default (enabled in HA at the request of the admin) such as: signal strength in %, IP address, Uptime, Host
I plan to make a more customizable Discovery on Web App because Web App ishosted on Github and takes up practically nothing in Flash memory (only API takes up flash, Web App does not).
That would definitely solve a lot of problems. Looking at how much you and your "friends" managed to do, I know that it will definitely be wisely thought out 👍
As for the new BK7231GUIFlashTool, unfortunately, with today's screenshot from the socket with CB2S, it did not manage to extract the pinout:
However, with the dump from the previous clone, it digested it and can be imported in the AppGUI There is also no option to drag the file to the program window, so that you can select the "Browse" button and select the file.
Next case. From the previously configured socket, I wanted to import a Template:
I imported it in a new socket (clone) but after the 1st pin configuration already turned out to be different after 2. it didn't import "startup command" correctly - to the new socket as startup command, it put only "backlog" and nothing else.
Below is my template from the latest clone socket (in which I had to desolder the entire CB2S module, because I couldn't program it):
Next case. One more thing just occurred to me. There is no such simple "backup config" and "restore config" system from the file as in Tasmota. In some aspect, this is solved by the Template system, because there is a pin configuration and a start command, but there is no backup of set flags, Wifi configuration, MQTT configuration, etc. (but no MAC address!) For now, it's not that problematic because I can count devices configured on Beken chips on one hand, but I'm getting started, and I have to configure everything one by one as every device. At Tasmota, I was doing a restore from a file on another device and only changing the names of channels and Topic MQTT.
Thanks for testing and comments. I can't answer everything right now, but at least some of the questions are answered below:
Dark Man wrote:
I didn't add these PREF VREFs myself... - they added themselves to startup commands
And that's interesting, it's probably left over from the device template from the old days (from the devices list), I have to hide it. After all, the list of templates has 300 devices, and this also needs to be updated and taken care of.
Dark Man wrote:
Next case. One more thing just occurred to me. There is no such simple "backup config" and "restore config" system from the file as in Tasmota. In some aspect, this is solved by the Template system, because there is a pin configuration and a start command, but there is no backup of set flags, Wifi configuration, MQTT configuration, etc. (but no MAC address!) For now, it's not that problematic because I can count devices configured on Beken chips on one hand, but I'm getting started, and I have to configure everything one by one as every device. At Tasmota, I was doing a restore from a file on another device and only changing the names of channels and Topic MQTT.
As far as I know, this there is such an option . Web App -> Flash tab. There you can download a sector dump (4096 bytes) of the OBK configuration, which contains everything except: - RF partition (MAC address) and WiFI calibration - LittleFS file system
Dark Man wrote:
As for the new BK7231GUIFlashTool, unfortunately, with today's screenshot from the socket with CB2S, it did not manage to extract the pinout:
Can you send me a binary file with it.
Dark Man wrote:
There is also no option to drag the file to the program window, so that you can select the "Browse" button and select the file.
Such things will also be, in general, after the Read operation, the import window opens by itself.
And the new version will be able to enter the OBK config on its own, together with the specified WiFi, already when flashing
Dark Man wrote:
after the 1st pin configuration already turned out to be different
I can't help it, just... sometimes they change the configuration.
Dark Man wrote:
after 2. it didn't import "startup command" correctly - to the new socket as startup command, it put only "backlog" and nothing else.
And that's very interesting, and I think I know where it came from. I have to check it out. It's certainly a valuable point, I wasn't aware that it can get lost.
Hello I uploaded the OpenBK7231N_1.17.105.rbl version because on OpenBK7231N_1.17.104.rbl in HA it did not refresh the IP address and reset the state register. After uploading the Build on Apr 6 2023 10:49:30 version via OTA, version 1.15.660 reset all settings in the Socket. Even for Build on May 3 2023 09:13:10 version 1.17.98 there is no IP and RSSI publication Info:MAIN:Time 144, idle 65766/s, free 71456, MQTT 1(1), bWifi 1, secondsWithNoPing 73, socks 3/38 POWERSAVE Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic G5/energycounter/get Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic G5/energycounter_last_hour/get Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic G5/energycounter_yesterday/get Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic G5/energycounter_today/get Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic G5/energycounter_clear_date/get
Does config save calibration data??
Can you still publish the name of the network to HA?? sta:rssi=-55,ssid=Piratee,bssid=d8:07:b6:b6:81:d2 ,channel=10,cipher_type:CCMP
I also noticed (at least on version 1.17.104) that the current measurement results are very unstable.
I am especially interested in power and voltage - for example, when connecting a regular 75W bulb, the results jump from 68W to 80W very quickly, or when the socket is turned on and nothing is connected to it, the results jump from 0W to 11.1W :-/ I guess it's the fault of the BL0937 system, which sends such data on the output, but I think that some sort of sampling algorithm should be implemented, i.e. that, for example, the system receives 10 measurements and maybe takes the average or rejects the most extreme ones and only displays in the GUI / sends by MQTT, such an averaged result. You could also run some extended calibration process, e.g. with a light bulb for 10 minutes, so that the program "learns" to reject these incorrect measurements I have many ESP8266 sockets from Tasmot that also have the BL0937 chip and the results are much more stable there, perhaps due to some algorithm.
ok I tested a bit and on Build on May 9 2023 07:20:59 version 1.17.105 it shows IP and reset date. I just had to put "#" in mqtt.yaml definition unit_of_measurement: " " now it's ok
Recently, flasher was basically developed, so there are no big firmware updates. https://github.com/openshwprojects/BK7231GUIFlashTool Flasher can now read various Tuya configurations from a 2MB batch: He can also edit the OBK configuration: Basically right now flasher can configure GPIO OBK itself while flashing, and can also enter your WiFi into the device, so you don't even need to pair via access point mode all automatically.
piratee wrote:
Can you still publish the name of the network to HA??
But do you mean just doing publish or connecting to discovery? I just added publish SSID network names for now Discovery will see you later. I think you need to finally give some configuration to this Discovery to enable additional options.
piratee wrote:
After uploading the Build on Apr 6 2023 10:49:30 version via OTA, version 1.15.660 reset all settings in the Socket.
After May 1, there was a change (extension) of the CFG structure and no version degradation is supported, only an update. But why are you downgrading?
piratee wrote:
Even for Build on May 3 2023 09:13:10 version 1.17.98 there is no IP and RSSI publication
And you have your own state published enabled? In the flags? Okay, let's check... It works for me. Unless you are talking about the fact that they are not connected to Discovery?
piratee wrote:
Does config save calibration data??
Performing VoltageSet and similar now automatically saves the configuration.
piratee wrote:
Should the alternative network work on version 1.17.106?
Unfortunately, it is not implemented yet, there are only fields, I need to dig out a second router from the garbage, I think I have an ancient TP-Link somewhere in the attic ...
piratee wrote:
ok I tested a bit and on Build on May 9 2023 07:20:59 version 1.17.105 it shows IP and reset date. I just had to put "#" in mqtt.yaml definition unit_of_measurement: " " now it's ok
I'm not sure what you mean now, as far as I know OBK doesn't generate any Yaml where is the IP/date of resetting from unit_of_measurement. What you write sounds like a setting that is already fully in your HA, except for OBK. I set unit_of_meas in Discovery only for sensors, unless some error has crept in:
The Hass Discovery upgrade is planned, but I'm not sure how to do it yet, there are several options: - just add all possible entities there as they are, for each, rigidly - or give flags like "whether to add IP entity" etc - or give the possibility of customization, e.g. by showing the generated discovery yaml to the user before sending it, along with the possibility of editing
But do you mean just doing publish or connecting to discovery? I just added publish the name of the SSID network for now, Discovery will see later. I think you need to finally give some configuration to this Discovery to enable additional options.
Yes, I mean just publish (whatever publishes Rssi , and IP )
p.kaczmarek2 wrote:
I'm not sure what you mean now, as far as I know OBK doesn't generate any Yaml where is the IP/date of resetting from unit_of_measurement. What you write sounds like a setting that is already fully in your HA, except for OBK. I set unit_of_meas in Discovery only for sensors, unless some error has crept in:
On Publish there is a register: Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic G5/energycounter_clear_date/get
p.kaczmarek2 wrote:
- or give flags like "whether to add IP entity" etc - or give the possibility of customization, e.g. by showing the generated discovery yaml to the user before sending it, along with the possibility of editing
But do you mean just doing publish or connecting to discovery? I just added publish the name of the SSID network for now, Discovery will see later. I think you need to finally give some configuration to this Discovery to enable additional options.
Yes, I mean just publish (whatever publishes Rssi , and IP )
Hmm, so finally RSSI and IP publishing works for you, or not? Maybe you don't have something enabled? look here: This is configurable via mqtt_broadcastInterval, but don't overdo it, don't set it too low. https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md Do you mean it's not in Discovery?
So, if you have any comments, feel free to give them, I will try to help, sooner or later. Today I would like to release a new version of the flasher, and then we'll see.
now it works for me to publish: RSSI, IP, SSID Only something in HA messed up that how I have the definition of a unit unit_of_measurement: " " even though I see values in MQTTExplorer, I don't see them in HA.
I am waiting for an alternative network and making copies of settings with calibration. Then there can be a DS18B20 reading
This should work for now. Just download the OBK config dump (one sector 4096 bytes): Then you can restore it in two ways: - you can use the same form to send it to the device (via Web App) and do a restart, it will overwrite everything that is in CFG - you can (in the new version of the flasher, which will be published soon) drag it to the field and from the UART level upload it to the OBK. NOTE, this config does not include: - RF calibration, i.e. WiFi and MAC calibration - otherwise it would spoil the device, calibration is per device - LittleFS file system In turn, this config contains: - BL0937/BL0942 calibration i.e. VoltageSet/CurrentSet - please do not confuse this with RF calibration! These are two different things - SSID, everything related to it, MQTT pass, host, topic, etc - short startup command - flags, etc - pins, types of channels
PS: What do you think about adding an option to Flasher to scan the entire network for devices with OBK and automatically backup their configuration to one folder? Such a dump of all OBK from the network. In the 4096 byte format, one CFG sector in the binary file.
This can be a nice option, ESPHome has a group update from Tasmota Manager, you can also do OTA Update.
The visual overlay can be done in the Web App, so that flash simply generates a script in the background at zero cost, but it's also a job for a day or two.
Added after 4 [hours] 1 [minutes]:
EDIT: Such a curiosity - uptime 73 days - it's a shame to update some devices, but I need to test something.
I recently buy two quite similar devices and flash it with OpenBeken. To flash it, I had to disolder the CB2S board from the main board. I have trouble on one of it two because I broke the pin on the main board matching with the CB2S P26 pin where the relay is normally soldered. Without this pin, I can solder it back and my relay is not working. Anybody have an idea where I could link the P26 pin on the main board to fix my problem ? It's a 5VDC relay so I imagine their is some components between this pin and the relay to convert the 3.3V of the BK to the 5V of the relay.
The discussion centers on the Tuya LSPA9 smart socket teardown and the process of flashing OpenBeken firmware on devices based on the CB2S (BK7231N) module with BL0942 or BL0937 energy metering chips. Detailed guides cover hardware disassembly, UART programming, pin configurations, and calibration commands for accurate voltage, current, and power measurements. Users report variations in internal components, such as different pinouts and energy metering chips (BL0942 vs. BL0937), requiring tailored firmware settings. The OpenBeken firmware supports features like automatic calibration data saving, MQTT integration with Home Assistant discovery, and configurable precision for telemetry data. Issues discussed include OTA update behavior, negative power measurement spikes, device stability problems with CB2S, and DNS resolution in MQTT. Solutions involve firmware updates, command-line calibration, and community-shared device templates. The project supports multiple chip platforms (BK7231T/N, W600/W601, W800/W801, BL602, XR809) and aims to provide cloud-free, customizable IoT device firmware. Users also share experiences with alternative devices like Aubess and Arlec smart plugs, including pin mappings and flashing tips. The community actively contributes to device template databases and firmware improvements. Summary generated by the language model.
from Aliexpress Choice
