Open restauffer opened 1 month ago
We tested compiling the current yaml on mac and rpi and didn't encounter a 404 error, is it possible to take a screenshot we'll make sure to see what happens to you? The official issue looks to be still watching.
This is what occurs when attempting to use Install from within the WebUI:
If you remove or comment out the lines inside the redbox on the following image the problem does not occur.
Note https://github.com/esphome/issues/issues/5926. Other are experienceing the same prioblem.
By the way your screenshot looks like you are using the Esphome Command Line (CLI) compiler instead of the one with the WebUI inside HA. This may be why you are not seeing the problem
instead of loading external components remotely, you can also load them locally: just copy the repo into your esphome config folder (i created a subfolder external_components
).
external_components:
#- source:
# type: git
# url: https://github.com/screekworkshop/custom_components_support_for_screek_2a
# ref: main
# components: [esp32, uart]
- source:
type: local
path: external_components/custom_components_support_for_screek_2a/components
components: [esp32, uart]
@diplix Thanks for the idea. I considered this but then we would miss any updates to the external GitHub repository. Is there a way to automate regular checks/updates of a local repository?
I tried @diplix idea and installed the Git files locally and still got the same 404 error. So it seems the problem is not with getting the GIT files, it is something within the files.
Is there a way to automate regular checks/updates of a local repository?
not that i know of, but following/subscribing the repo on github at least can notify you of any updates.
I made another discovery. The "404" error only occurs when installing via the USB cable. If you use a generic yaml to flash the device and get it onto wifi, you can then use the full yaml and install it wirelessly without error.
I have sent several emails with info. Let me summarize what I have learned:
I'll try to continue writing tomorrow using the data line method to see what might be going on.It's hard to imagine the correlation this would cause from an initial consideration, since the front part of their process should be the same, pulling remote libraries, caching to a temporary compilation directory, and then finally piecing it together, making firmware, and writing firmware. The logic for generating the binary is probably very close.
In China sometimes it also causes 404 because of blocked github part of the request, but I think it might not be relevant here.
We used the local version when we burned and manufactured the original firmware ourselves. Currently one of these external dependency libraries can be phased out in the new version and is unlocking an indicator.Another one can also remove the related dependencies if you don't need the serial port logging.
I'll continue to test the direct page install tomorrow and then share our findings with. Please understand that I'm a bit behind on the esphome front as I've been debugging zigbee's low-power firmware in my spare time lately.
We tested this a few times using web-ui installed directly to f2, but it didn't trigger a 404 error either. as this video show:
https://github.com/user-attachments/assets/dea5546a-8378-486a-a75d-9bae91cc37bd
esphome verison is 2024.07
install with a fresh clean, and seems not 404 error.
https://github.com/user-attachments/assets/408a8390-d6f5-4315-b96a-2136897763ea
In the video you are choosing "Plug into the computer running Esphome Dashboard" and therefore I assume you are attaching the device via USB to the server running HA. I am using "Plug into this computer". It is not the one running HA . It is my desktop Windows 10 PC (I get same results when running in a stand-alone Raspberry PI).
I can try plugging into the PI running HA tomorrow and test similar to what you have done. I do not have access to it tonight.
I have tested with the F2 attached via USB to the Raspberry Pi running HA and it compiles and installs correctly. So we can now say the problem only exists when trying to compile/install with a USB cable on a computer not directly running HA. For most this will be an adequate workaround. For some, who don't have normal physical access to the HA computer, there would still be a problem.
I have tested with the F2 attached via USB to the Raspberry Pi running HA and it compiles and installs correctly. So we can now say the problem only exists when trying to compile/install with a USB cable on a computer not directly running HA. For most this will be an adequate workaround. For some, who don't have normal physical access to the HA computer, there would still be a problem.
Due to time constraints, we haven't been able to try to do this experiment directly on RPI. But from our brief judgement so far, this could be some sort of problem with esphome's addon in trying to download the dependency libraries.
For the time being, our recommendation would probably be to place them locally to compile.
We got a 404 error when we tried to do a download (not a direct USB burn) on the 2024.07, and I think it looks like we replicated the problem. By seeing the file, it should be there, maybe the problem is in the final renaming, which needs further investigation.
I am trying to add the F2 to the Home Assistant WebUI. I add the device as a generic and then replace the resulting YAML with that given in this repository. When I try to compile the code I get the following error: "Error: Downloading Firmware Failed: 404" By adding some comments in the YAML I can determine it cannot load
url: https://github.com/screekworkshop/custom_components_support_for_screek_1w
There is mention of this problem here: https://github.com/esphome/issues/issues/5926
but the issue was closed.