Hassio-zigbee2mqtt: zigbee2mqtt-edge does not seem to track the dev branch (unable to update)

Created on 14 Jan 2020  Ā·  14Comments  Ā·  Source: danielwelch/hassio-zigbee2mqtt

zigbee2mqtt add-on version (if edge, please report commit hash): edge, #2451d536f2c9e446d396df55c9493f256ab9352e

Starting zigbee2mqtt version 1.8.0-dev (commit #2451d536f2c9e446d396df55c9493f256ab9352e)

Operating environment (HassOS, Virtual Machine, Device/platform running Hass.io): ODROID XU4 running Ubuntu 18.04.3 LTS with latest Hassio 195

Description of problem:
I was not able to update the edge version to the latest version of the dev branch. It still seems to point to the 1.8.0 release. I also tried uninstalling both addons, removed the repos from the addon store, re-added and re-installed them without luck. Note that I am sure that it does not reflect the current dev branch as I tested it with a separate Z2M instance that I explicitly cloned from the git repo because I was about testing a feature (of Zigbee2Mqtt Assistant) that required a certain commit from the dev branch. And even after reinstalled/removing addons/repos, I was not able to get a version running, containing that commit.

Also note that re-installing and removing/re-adding the addons/repos was successful without any errors/warnings/whatsoever.

Any ideas what could be wrong here?

Your entire configuration from the frontend (with sensitive fields redacted):
n/a (probably irrelevant here)

See also https://github.com/danielwelch/hassio-zigbee2mqtt/issues/43 which made me believe that it should track the dev branch ...

Most helpful comment

@sti0 correct, still no luck. The fix described in the Travis docs won’t work directly for docker commands. Tried another workaround I found online but that doesn’t seem to work either. I’ll keep trying.

All 14 comments

I have the same problem since days. zigbee-herdsman and the converters are not up to date
image

My system is latest hassio running on an Raspberry Pi 4. I migrated Z2M from an Raspberry Pi 3 some weeks ago. On the RP3 the uninstall and reinstall of the edge addon works. On RP4 it seems to pull the same image every time. Maybe a cache problem?

I uninstalled the edge addon and reinstalled it several times. I even deleted the repo and added it back in. I got everytime an old dev branch. That is really frustrating...

@sti0 You can always install the portainer add-in and install the Z2M container directly... but it would not be maintained by HASS.IO.

The edge builds have been erroring in Travis for some time. After looking at the logs, it looks like it’s just timing out during a long build step, which has happened in the past but not consistently like this. Travis has a way to fix/mitigate this... I’ll have to update the Travis file. I’ll push a quick fix and see if that helps.

I suppose the quick fix wasn't successful (build error shown at github)? Reinstalled the edge addon and still the old version.

Did this even effect the main addon? v1.9 is out.

@sti0 You can always install the portainer add-in and install the Z2M container directly... but it would not be maintained by HASS.IO.

This works like a charm. THanks for the hint.

For others whom like to use this solution as a workaround: Please note that you can't mount the /share/zigbee2mqtt folder directly. Instead you have to mount /mnt/data/supervisor/share/zigbee2mqtt

@sti0 correct, still no luck. The fix described in the Travis docs won’t work directly for docker commands. Tried another workaround I found online but that doesn’t seem to work either. I’ll keep trying.

Thanks for your efforts!

Would you mind making the Z2M v1.9.0 a release in this addon as well? šŸ™ˆ

@CodeFinder2 yes, I’ll merge that update. However, the build for that version probably will also error because of this problem until it’s fixed.

Thanks for your efforts @danielwelch - I'm also keen to get 1.9.0 as it fixes a critical bug in my setup!

Ok, the latest fix seems to be working. The build/push is underway. I've also restarted builds for all pending pull requests, so will plan to merge these after the CI checks pass.

The main problem now is that, of course, build times are really long. In the short term, I'm probably going to just eliminate the first CI job, which just builds the images without pushing them to ensure they build correctly. The images have to be rebuilt in the second job anyway, and won't push if that step fails, so it's just redundant and adds build time (used to add a number of minutes, now apparently adds up to an hour).

Ultimately, I'd still like to get off of the deprecated hassio-buildenv that this project uses for building/distributing docker images. There is a newer hassio-builder, but it's not as well documented and I'll have to experiment with it before switching over. I also don't really have a reason to believe it will be faster, but I'll have to look into it more and probably try it out and see.

@danielwelch You should try to switch to github actions and build all architecture in parallel instead of one after the other.

@carldebilly the architectures are currently built in parallel using the associated option to do so in hassio-buildenv. But yeah, there are better ways to do this, whether on travis, circleci, or github actions (that parallelism is not specific to github actions). The hassio-buildenv and new hassio-builder are complicated under the hood, but simplify things on my end. I'd be totally for replacing the current build system with a method that doesn't rely on either of these tools, as I think it'd just be easier to reason about and troubleshoot. The "community" add-on build process is a nice example, although more complicated than probably necessary for this project alone.

By the way, I've seen that the releases of the addon do not include the recent releases (1.7, 1.8) and changelogs. Is this also related to this issue?

@CodeFinder2 Basically, the build system no longer relies on git tags. I had been manually tagging the relevant commits and drafting releases as I made them, but I wasn’t the one to merge some of those updates, so they weren’t tagged and given release notes. As discussed in another issue, I’d like to move to a ā€œtag dependentā€ build system for the stable version, with better enforcement of the release notes / change log

Was this page helpful?
0 / 5 - 0 ratings

Related issues

knutasund picture knutasund  Ā·  11Comments

SPEC1AL1ST picture SPEC1AL1ST  Ā·  12Comments

hutchx86 picture hutchx86  Ā·  5Comments

talondnb picture talondnb  Ā·  10Comments

highground88 picture highground88  Ā·  7Comments