No, on the contrary, the purpose of opening port 8080 is to be able to access the Zigbee2mqtt interface in the browser, so we want to be open on the machine’s port.
Gladys and Zigbee2mqtt communicate via MQTT
I’m not a big expert when it comes to networking, if we map another port for z2m (with an environment variable) … will everything break?
Attention, we’re just talking about the web interface here 
Nothing to do with the link between Gladys and the Zigbee2mqtt software
@jgcb00 I’ll think about it next week on how we can change that, but do you think we can release a v1 of the Gladys Unraid app without it, or does it seem really critical for the launch of the integration?
I’ll make a release next week with everything I’ve done so far:
I’m not sure I have a solution for port 8080 before this release, depending on the solution I choose it could be a small or a medium/large development. If it’s an environment variable it’s easy, if it’s in the UI it becomes a real job.
I’m wondering, because if we do this as an environment variable, it means I develop it specifically for Unraid and we will never present it to Gladys users (we never ask Gladys users to do CLI, modify the docker run, it’s the mantra n°1 of v4), if on the other hand we want this to be a setting available to all Gladys users (in a way that’s practical for everyone), then it must be in the UI, but then it’s quite significant development.
The zigbee2mqtt port is not linked to docker run, it’s in the config, a container restart and that’s all.
I would even say that it should be a parameter of the integration
Indeed, I hadn’t noticed that we were in network=host mode on this container either.
It’s not simple then as development.
Hi everyone,
I wanted to give myself some time to think.
So I considered several solutions:
- Put the container on a specific network, so it has its own IP address but as you suspected @pierre-gilles we can no longer access the USB
- Putting it in bridge mode doesn’t work and wouldn’t be of interest
So it remains 3) we keep the host, the user must be able to choose the port for all the containers we launch from the application. There are only 2 I think:
- Zigbee2Mqtt
- Mqtt
Are there others that I don’t know about?
Edit: I can’t understand why it’s so hard to retrieve the environment variable and set it at the initial docker run of zigbee2mqtt?
It’s especially the existing instances that also need to be managed and don’t have these variables 
Can’t we assign a default value if it’s not specified?
Nothing hard about that, that’s the simple version, but from what we’re saying, that’s not what we should do!
@jgcb00 I confirm that all fixes have gone to PROD for Zigbee2mqtt/MQTT, as well as compatibility with Debian 11/Ubuntu > 20.04.
I think this is a good time to release a first version of an Unraid integration
Do you need anything else to release a first version?
Hello,
Super I’ll check that out and make a merge request as soon as possible
On which port does the MQTT broker run?
1883 by default
Isn’t it eclipse-mosquitto that’s running?
From what I can see, I have:
- Zigbee2MQTT: 8080
- MQTT: 1883
- eclipse-mosquitto: 1883 and 1884
Is that correct?
Just a question, what is mosquitto used for so I can justify its installation in the documentation?
It’s an MQTT broker, okay, but what’s the difference with MQTT then?
Mqtt is a protocol, mosquitto is an « mqtt » server
Just like you have for http, Apache or nginx
ok it works thank you but then what does the MQTT container actually do if Eclipse Mosquitto is the broker?
eclipse mosquitto = mqtt
eclipse mosquitto = mqtt