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
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.
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
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.
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
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?