Comparing to any other addon would be the same as comparing elephants to apples…
So the differences between yours and mine I see are that first, the default networks for the inbuilt addon have a few extra ones. I just reset that to defaults and I have 4 defaults now as well (previously only 2)
Also you are changing the ports for the inbuilt addon whereas I was changing them for the community addon.
When I said that I don’t have any issues with other community addons I was only meaning regarding SSL - I have all of them set up the same way with SSL false and I was getting a socket error which you indicated was an ssl issue.
I’m on my iPad now but now I have your screenshots, I’ll try again tomorrow when I am on my computer.
Am I correct in thinking I should be able to leave the inbuilt broker at the default networks and instead only change the community-addon network ports?
Thanks again. I’ll let you know tomorrow.
Yes, I changed the “Mosquitto addon” because I use the community one and didn’t want to f**k it up for a simple test
@ludeeus - is the expected behaviour that, if a topic is published by one user, that an anonymous user cannot then see that MQTT topic? In fact only that user can see that topic?
OK got it running. I had only changed the 1883 port. Was weird int inbuilt broker was only showing 2 ports but when I reset it it went to 4. I just changed all the ports in your addon and then I could connect on 1884 to the inbuilt broker.
I subscribed to some command topics. It seems they don’t persist? If I close and then reopen web browser, the subscriptions are blank… is that correct?
I might have a bit of a go at using your broker as well now.
Thanks for your help.
OK I also set it to use the iFrame but I’m getting an insecure script error when I do that as I’m using a reverse proxy (Caddy). Assuming there’s no solution other than to trust it and then all HA is showing with a browser warning.
Hi, its working perfectly thanks!
Only I have to put broker address and topic subscribed all the time I open the webpage, not sure how to have it automatically. This is my config, I do use MOSQUITTO HASS broker set in configuration.yaml
{
“log_level”: “info”,
“certfile”: “fullchain.pem”,
“keyfile”: “privkey.pem”,
“web”: {
“enabled”: true,
“username”: “xxxxxxxx”,
“password”: “xxxxxxxxxxxxxxxxxxx”,
“ssl”: false
},
“broker”: {
“enabled”: false,
“enable_ws”: false,
“enable_mqtt”: false,
“enable_ws_ssl”: false,
“enable_mqtt_ssl”: false,
“allow_anonymous”: false
},
“mqttusers”: [
{
“username”: “”,
“password”: “”,
“readonly”: true,
“topics”: [
“#”
]
}
]
}
I am using MQTT.fx as a client for MQTT debugging. It has a very useful ‘scan’ function which lets you see what topics are available. It works on any vanilla Mosquitto installation but not with this Addon.
Seems to work now - no idea why!!!
I have no issues with it and no browser warnings
panel_iframe:
mqtt:
title: MQTT
icon: mdi:code-brackets
url: https://my-ha-domain.duckdns.org:5713/
Yes, this is expected, this tool are intended mainly for troubleshooting, during troubleshooting you want to edit those between tests.
Hi, thanks for the addon. Any extra tools like this are a really good addition
I have a small issue, I believe I know what it is but don’t know how to solve it.
Using the normal Mosquitto addon everything is fine. I disabled that, installed this one and filled in the config. All started ok but I lost all my zigbee2mqtt/sonoff entities.
The logs show they are connecting and sending fine (both from zigbee2mqtt and into this addon) but HA logs start popping errors.
Config: https://hastebin.com/apuwapavab.json
AddonLog: https://hastebin.com/wuqufabebi.py
HALog: https://hastebin.com/isavizover.sql
I think its because HA is starting before the addon?
I run HA in docker on a vanilla raspian pi3b but dont know enough about docker to get the addon starting before HA if HA is restarted.
It may be a config issue though?
The hassio_supervisor handles that.
Your addon config looks correct, and that makes sense since you can use it with other clients.
How is your homeassistant config for mqtt:
?
Ah, hadnt changed it.
Would I need to change the broker to something else or is it still technically the Mosquitto addon?
# MQTT
discovery: false
client_id : hassio
broker: core-mosquitto
username: !secret mqtt_user
password: !secret mqtt_pass
birth_message:
topic: 'hass/status'
payload: 'online'
will_message:
topic: 'hass/status'
payload: 'offline'
retain: true
Its not a dealbreaker as I can still use the webend.
OK… Mine is green until I try and connect. Then I get this:
Going into the console I see:
mqttws31.js:916 Mixed Content: The page at ‘https://subdomain.domain.duckdns.org:xxxxx/’ was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint ‘ws://ip-address:1884/mqtt’. This request has been blocked; this endpoint must be available over WSS.
and also
mqttws31.js:916 Uncaught DOMException: Failed to construct ‘WebSocket’: An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
at ClientImpl._doConnect (https://subdomain.domain.duckdns.org:xxxxx/js/mqttws31.js:916:23)
at ClientImpl.connect (https://subdomain.domain.duckdns.org:xxxxx/js/mqttws31.js:787:18)
at Client.connect (https://subdomain.domain.duckdns.org:xxxxx/js/mqttws31.js:1606:20)
at Object.connect (https://subdomain.domain.duckdns.org:xxxxx/js/app.js:69:21)
at HTMLAnchorElement.onclick (https://subdomain.domain.duckdns.org:xxxxx/:80:121)
You need to use the IP of the hassio host or addon_a0d7b954_mqtt
Well… you are trying to use a non-ssl port/socket from a ssl enabled site.
This will give you warnings, and will not work.
Presume you are referring to the local ip address I entered for the broker? What should I use instead so it will connect?
When using SSL you need to check the box for SSL, use a ssl enabled WS port (4884 is the standard) and the host needs to match the domain that the certificate was issued to.
Ok makes sense. I turned on ssl for web sockets but it won’t start because I’m not using ssl in the broker. So I don’t think I’m going to get this to work. I’ll just connect via ipaddress so it’s all good but of course it won’t work in an iframe.
a ssl port require a certificate.
i have a certificate for the subdomain.domain.duckdns.org - hence the padlock in the screenshot above. But it’s not connecting again as per screenshot above.
sure about that?