Change default folder for ha-addon and fix docker dependencies #5
Conversation
|
The command to build and push the image is: docker buildx build --build-arg BASEIMGTYPE=hassio --build-arg BUILD_VERSION=latest --file docker/Dockerfile --platform linux/amd64 --target hassio --tag ghcr.io/felipecrs/libretuya-esphome-hassio-amd64:latest --push .Of course you can adjust it to your own GitHub user name. But, for testing https://github.com/felipecrs/libretuya-esphome-hass-addon is configured to pull from an image in my repo. After you publish your image, like |
|
If you want to test, just add https://github.com/felipecrs/libretuya-esphome-hass-addon to your HA Addon Store and install it. It should work. |
|
I will transfer the repo to you also. |
|
I'm facing some issues. When I try to build a binary from ESPHome, it complains about some missing binaries, like: arm-none-eabi-g++, cc1plus Is there a list of OS packages which are required by libretuya? |
|
Actually, I think I found them:
|
|
We don't need to use GCC system-wide. PlatformIO should pull the toolchain from PIO registry, and use that instead of any other. On "host" Debian/Windows/Ubuntu/etc. you don't need any GCC in your PATH, and PIO chooses one automatically. Can you post any error logs that indicate the requirement of GCC? |
|
There's also a release workflow here, which I think we can tweak to run on each push to |
felipecrs
changed the title
|
I was able to compile a binary just fine by adding these two dependencies. Without
|
|
Oh, and yes, it will be displayed as an update for end users just like the ESPHome addon or any other addon does. Users can choose whether to update it or not. |
|
Small demo: chrome_3XfFQCJcPG.mp4 |
This looks interesting! I am getting an error with Pi4 (HAOS 64) |
|
Oh, I did not publish ARM docker images, so you can only test it with amd64. I'm using an Intel J4125 (amd64). |
|
But this is something the automated workflow will handle. |
|
Also building on ARM64 / ARM v7 is broken in libretuya libretiny-eu/libretiny#48 |
|
The file rlx8711B-symbol-v02-img2_xip1_4M_cpp.ld seems to be missing from the add-on. libretuya:
board: generic-rtl8710bx-4mb-980k
framework:
version: devEdit: Adding compilation logs. |
Chances are that this is due to the same reason why some dependencies were missing for me. |
@felipecrs @kuba2k2 I've realized there was typo in realtek-ambz-4mb-980k.json and I've created a PR libretiny-eu/libretiny#56 (comment) to correct it. |
Are you sure about it? Have you tried with a system that hasn't these libraries? |
|
@felipecrs I've tried without them on a docker image without these 2 dependencies, and it worked (Windows 11 host, docker image build with arch amd64) |
|
Maybe they are only needed for building the boarding I'm building them: wr2e. I'll try again though. |
|
PS: I've made a PR in your fork, that enables aarch64 to use binaries compiled for armhf, so we can compile LT (Beken chips at least) on docker images without any changes. Can you review it and maybe build the docker image for aarch64 ? :) |
|
Oh, didn't tried to compile a RTL chip so far, but for Beken ones, it works without those libraries, I will check for RTL too |
|
Just tried here, same issue, even using the latest git version of libretuya. |
Fix docker image for arm64 CPUs
|
PR created here: felipecrs#2 |
|
Tested here, worked for me too! |
Fixed building for RTL on x64
|
Pushed and updated all the three variants, which can be installed through https://github.com/kuba2k2/libretuya-esphome-hass-addon. |
|
They range from 300MB to 350MB. Quite light! |
|
Do I understand correctly, that the docker images don't contain LT itself, they're rather configured to use LT in platformio? But they do contain esphome source, right? |
|
I still don't get it why GCC ARM is required during building. Ltchiptool is a pure Python package which doesn't need the C compiler, and compiling LT is done using PlatformIO which manages its toolchains. |
|
@kuba2k2 The GCC ARM is required on ARMv7 only to build ltchiptool because it depends on pycryptodomex , and when the wheels are builded for pycryptodomex they fail because of missing gcc-arm-linux-gnueabihf , on aarch64 and amd64 there was no issue building pycryptodomex And yes, the docker contains only the esphome application installed, everything is pulled via platformio, including the esp8266 / esp32 sdks/frameworks etc. It also contains some of the libraries used in esp just to be cached locally |
|
So it's because of crypto.. I wonder if there are wheels for pycryptodome instead of pycryptodomex.. Anyway, we can make it an optional dependency of ltchiptool, because currently it's only needed for packaging Beken OTA images (UG, not UF2). Since the images have a field specifying the encryption type, it should be possible to disable it entirely and the bootloader shouldn't complain. |
|
FYI, I've transferred the ESPHome HA Addon to the LT organization on GitHub. |
Did that today, ltchiptool is now pure-Python so Docker building shouldn't require crypto. |
|
BTW this is the command to build aarch64: binfmt is needed, so: (this is for my own reference as well). |
|
Are you planning to keep it up to date? It is really useful. |
|
Ran into the same thing using Full long in textFWIW, image is running on a Pi based with an aarch64 user space. |
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions. |
|
This is no longer needed. @kuba2k2 I would recommend you archive this repo. |
|
This is still a repo for development of LibreTiny in ESPHome. It's not actively maintained, but will certainly be used if there are any changes required to ESPHome's support for LibreTiny. |
|
Ok ok. Thanks. |
Refs libretiny-eu/libretiny#54