the intention being that OTA now prefers Open<chip>_<ver>_<variant>.rbl (chip + variant) based on the device’s build suffix, and falls back to Open<chip>_<ver>.rbl (generic) if no variant asset exists.
seems OK so far, but needs more testing.
let's you go from generic to variant at the moment
currently with hard-block if choosing different variant
doesn't cater for the _ALT variants though as they're not as <buildver>_ALT in /api/info
latest commit doesn't allow any variant cross-flashing
Personally I think this is too much. I think a warning would be fine, or a switch "allow change in variants".
Just imagine I realize I used the wrong variant or added a new sensor and can't change to the needed file.
Just as a possible extension, no idea if/how to realize (but my PR to include the defines in a build might be a start): The top version would be to extract the drivers per variant so the user can see/decide if the variant fits the requirements.
Personally I think this is too much. I think a warning would be fine, or a switch "allow change in variants".
Just imagine I realize I used the wrong variant or added a new sensor and can't change to the needed file.
I agree. I had imagined directing people to the other OTA option in main gui, but why make it unnecessarily hard. A warning note would be enough
Added after 1 [hours] 2 [minutes]:
Relaxed.
Warning generic->variant
Warning variant->generic
warning variant->variant
block still for wrong platform
cool. the variant OTA thing has been on my mind for a while + ESPs were not listed at all. I just hope the code is OK. I'll review code comments and do more testing/checking.
Added after 1 [hours] 4 [minutes]:
it seems LN882H only matches on file extension so will look to add filename pattern check too
Added after 2 [hours] 1 [minutes]:
LN882H wrong chipset
LN non-OTA
correct LN OTA
BL602 variant listing + accept variant OTA
warn on variant to generic
generic listing + warn on generic to variant
warn on variant to variant (future-proofing)
no warning on same to same generic
BK7238 variant listing + accept variant OTA
warn on variant to generic
generic listing + warn on generic to variant
no warning on same to same generic
wrong chipset
BK7231N variant listing + accept variant OTA
warn on variant to variant
warn on variant to generic
generic listing + warn on generic to variant
no warning on same to same generic
wrong chipset
The NOTE (warning) should be orange, not red, red is same as error. OBK is very user friendly and we should try our best to maintain it, so all error messages are clean and readable.
It was only matching on <version>_<variant>.rbl but the _ALT rbls are eg OpenBK7231T_ALT_1.18.244.rbl whereas actual variants are eg OpenBK7231N_1.18.244_hlw8112.rbl
"const" means that you won't change variable later, so it's usually preferred, unless you are reassigning value to that variable, then you use "let". Still, I don't really follow this myself, it is just improving readability of the code. Also, if you declare as const, but later try to reassign the value, it will show error in console.
The discussion centers on the development and testing of an open-source firmware project for the BK7231T microcontroller, focusing on creating a cross-platform mini HTTP server, web-based pin configuration, MQTT integration, and Home Assistant compatibility. The project includes a Visual Studio project for Windows and firmware flashing tools like Beken Writer and a Python-based uartprogram. Users report challenges with flashing devices, including issues with firmware size limits (956KB), UART converter compatibility, and power supply stability during flashing. Solutions include using specific UART adapters (e.g., FT232R, CP2102), resetting devices via the CEN pin instead of power cycling, and trimming firmware binaries. The firmware supports devices with BK7231T and BK7231N chips, with ongoing work to add PWM dimmer support, BLE, TuyaMCU protocol integration, and OTA updates. Various smart devices such as WB2S/WB3S modules, smart plugs, LED bulbs, and switches from brands like MOES, Nedis, Hama, and Calex are tested. Users share detailed hardware teardowns, pinouts, and flashing procedures. MQTT topic naming issues related to MAC address usage were identified and fixed. The project emphasizes community collaboration, with suggestions for a Discord server to enhance real-time communication. Additional tools and SDK improvements, including CMake support and BLE integration, are under development to facilitate firmware building and device support expansion. Summary generated by the language model.