Feedback on Home Assistant add-on

[Nerivec]

Share your feedback on running standalone WindFront with the Home Assistant add-on here!
https://github.com/Nerivec/ha-zigbee2mqtt-windfront

Tips:
https://github.com/Nerivec/zigbee2mqtt-windfront/wiki#home-assistant

[KoalaWerewolf]

@thargy, did you install the new Windfront add-on that @Nerivec has created? It is a standalone instance for serving multiple Z2M instances, linked at the top.
The configuration for this add-on includes the parameters required for your instances and it eliminates your need for a separate machine. It replaces the Z2M proxy add-on for your use-case. It should work like a charm for you. The only thing you need to set up are the two config line with urls and what you want to call them.

[thargy]

@thargy, did you install the new Windfront add-on that @Nerivec has created? It is a standalone instance for serving multiple Z2M instances, linked at the top. The configuration for this add-on includes the parameters required for your instances and it eliminates your need for a separate machine. It replaces the Z2M proxy add-on for your use-case. It should work like a charm for you. The only thing you need to set up are the two config line with urls and what you want to call them.

Thanks, I hadn't spotted that! I have now installed the new addon, and it has configured.

I access my Home Assistant via a Cloudflare tunnel, and experience the same issue as you, in that the APIs do not connect when using Home Assistant via the tunnel (even when connected on the same LAN), but it does work if I connect to HA using the local IP & port.

[Nerivec]

multiple APIs are limited to the standalone frontend only

It is. Frontend needs to be aware of the URLs on its own (can't rely on Z2M providing the data since it needs that data to connect to Z2M itself). We may be able to provide a "additional API URLs" via configuration.yaml in the future, but that is different from current setup and only WindFront would support it (breaking support for original frontend, which is not desired at this time).
But most importantly, the standalone design provides a protection against the primary Z2M instance (per your description) going offline and blocking access to other instances (since it would stop serving the frontend for all if for e.g. the adapter disconnects or you take it down for maintenance). The standalone instance is a simple nginx server, so, as long as the below infrastructure is solid, there is little chance of it ever going offline.

Standalone allows using whatever means you want to host the frontend (which was requested several times), baremetal, docker, or like KoalaWerewolf mentioned, the new HA add-on of this discussion (brand new, currently in testing). It also allows to turn off the UI serving from within Z2M instances completely to free up some resources.

Note: .env is not something Z2M uses.

[Nerivec]

See above for the standalone question.

For the tunneled use, it is indeed a problem at the moment. I will have to take a closer look at how we can handle this.
The HA add-on configures nginx (to fit HA's ingress requirements) but the current plain Docker container does not, uses the defaults of nginx:alpine-slim.
If you have any suggestions, don't hesitate.

[francisp2]

Stand-alone docker is working behind the linux.io swag container, HA add-on is starting, but can't find/load the Zigbee2MQTT instances.

[Nerivec]

Can you provide more details on the configuration and setup and what you mean by "can't find/load"?
Did you check the instructions here? https://github.com/Nerivec/zigbee2mqtt-windfront/wiki#standalone-serving-with-multi-zigbee2mqtt-support

[francisp2]

Stand-alone docker : green

Home assistant Add-on : red

same with
https://z2m.mydomain.com/api,https://z2mmydomain.com/api,https://huis.mydomain.com/45df7312_zigbee2mqtt/api
or
z2m.mydomain.com/api,z2m2.mydomain.com/api,huis.mydomain.com/45df7312_zigbee2mqtt/api

Found the problem

10.0.0.63:8080/api,10.0.0.50:8080/api,10.0.0.52.:8123/45df7312_zigbee2mqtt/api

First 2 work, will need to search for the 3rd one.

[Nerivec]

The API URLs are likely not pointing to endpoints that the HA machine/add-on can access. This is going to be very specific to your setup. You can check the browser's console (F12 in most browsers) for the WebSocket error, it will be logged there.

If wanting to include a Zigbee2MQTT add-on instance from the same Home Assistant machine, be sure to get the correct ingress URL used by Home Assistant.

[francisp2]

Got the Zigbee2MQTT add-on to work too.

Open the front-end port

and using
10.0.0.63:8080/api,10.0.0.50:8080/api,10.0.0.52:8099/api

[ams2990]

This took quite a bit of fiddling to get working. Problems I encountered:

• It wasn't clear to me that the "websocket port" was the same as Z2M's "Frontend tcp-listen port"
• I expected the URL to start with ws://.
• Non-standalone Windfront uses a WS url like .../api/hassio_ingress/..., and I wasn't able to make that work from the addon.
• The add-on container isn't querying my network's DNS server (even though HA itself is), so only IP addresses worked.

[Nerivec]

About 2., the examples all show without the protocol, but I'll make that's more explicit in the docs. The protocol is not wanted here, since the frontend adapts to each scenario's requirements.

About the HA ingress stuff, it is quite messy to deal with for sure. I have to see with the HA team if we can maybe make this easier to retrieve. It was not the main purpose of the add-on (access Z2M instances outside the HA machine), but since it appears possible from the few reports I got... I have to investigate some more, see about adding docs.

Fixing the DNS resolver is already on my todo list 😉

[Nerivec]

Quick update on the API URL to use to get to the Z2M instance from within the same HA machine:
https://github.com/Nerivec/zigbee2mqtt-windfront/wiki#home-assistant
You should be able to use the add-on hostname to keep things simple (that name is universal - based on the add-on repository):

• 45df7312-zigbee2mqtt:8099/api
• 45df7312-zigbee2mqtt-edge:8099/api

This should require no other configuration.

[ams2990]

Not working for me. My normal connection API URL string is

192.168.6.51:8490/api,192.168.6.51:8491/api,192.168.6.51:8492/api

where 192.168.6.51 is my HA IP. I updated to the latest edge and used the following:

520c3f7f_zigbee2mqtt-a:8490/api,520c3f7f_zigbee2mqtt-b:8491/api,520c3f7f_zigbee2mqtt-c:8492/api

But when I open edge, I have no open connections.

[thargy]

Do you mean it works with 45df7312-zigbee2mqtt:8099/api (for release add-on) but not 45df7312-zigbee2mqtt-edge:8099/api (for edge add-on)?

Yes, exactly. I quadruple checked that I used the right API for the right add-on, the edge API didn't work for me on the edge add-on 🤷🏻‍♂️.

screenshots

Note: if using a non-official repo, you will have a different hostname (should be easy to check though, it's displayed in the add-on Info tab).

[Nerivec]

520c3f7f_zigbee2mqtt-a:8490/api,520c3f7f_zigbee2mqtt-b:8491/api,520c3f7f_zigbee2mqtt-c:8492/api

@ams2990 If using custom repositories, make sure to use the exact hostname displayed in each add-on Info tab and check the ports, default is always 8099 (this is directly accessing the Z2M add-on on the HA machine). If customized beyond that, you may have to find the "right way".

@thargy about the "non-official repo", I meant Z2M, not WindFront. This is the hostname displayed in the Z2M add-on Info tab. The WindFront add-on/version does not matter here.

[thargy]

@thargy about the "non-official repo", I meant Z2M, not WindFront. This is the hostname displayed in the Z2M add-on Info tab. The WindFront add-on/version does not matter here.

🤦🏻‍♂️

Ermmmmmm... I was tired 😬

Yes it works great 👍

[ams2990]

Ah hah, I got it, thanks! I made two mistakes:

1. I had noticed the per-repo hex string in the URL (e.g. https://homeassistant/hassio/addon/520c3f7f_zigbee2mqtt-a/config) but didn't notice that your example had a hyphen, not an underscore (45df7312-zigbee2mqtt:8099/api).
2. I was using the configured frontend port, not the 8099 default.

After fixing both of those, the new URL scheme works. Thanks!