Should this work with my let’s encrypt certificates?
Do I need certificates on my phone for using owntracks?
How can I see data in Home Assistant which should be published by owntracks?
How can I test if Home Assistant get´s informations from owntracks?
Owntracks on the phone says it entered my “home” region, but how can I see that in Home Assistant?
I think the documentation on that part is not that helpfull, at least for me.
I am wiling to improve this if I understand everything better.
Different MQTT implementations use different ports. Mosquito uses 1883, not 8883 bt default. Try opening that up on your router instead. Get Mosquitto working first, then work on other program add-ons that usr it.
@ajfriesen. Just went through this myself but as I didn’t want to open my network, I used the CloudMQTT model and connected my phone to that and then the hassio MQTT instance ‘pulls’ the location data from the cloud MQTT using the bridge method which is pretty easy to set up. Cloud MQTT allows 10 connections for free. If you’d prefer that method, I’ll post a video.
Okay,
i got MQTT working with SSL and Port forwarding. Tested it with MQTT.fx on my pc and MQTT Client for Android.
Now I have to get it working with owntracks and some automations.
@JSCSJSCS Default port for SSL is not 1883, it is 8883 which I was using. But you are right. One thing at a time.
@xbmcnut I don’t want to use another service so I just go with an open port for my raspberry pi with hassio. It works fine now.
I am just wondering: I saw some video by Bruh about setting up different users for each of his devices he was using.
But he was using a cloud service. Do you need this with the hassio provided plugin?
@ajfriesen thanks for clearing up the ports. I was wondering about that. Obviously I am not running MQTT SSL, but I want to. Keep me posted on how to implement that. I have Hass.io secured with Let’s Encrypt, but unsure how to do similar with MQTT.
Hass.io only uses one user as far as I know. The default client_ID is “HomeAssistant” under “mqtt:” in config. All your devices that publish through Home Assistant UI will have that client_id, I understand ; With sensors, either you give them a client_id or they were generated automatically. I found the client_id is not normally in the published information and sometimes, you want to know which device sent the data. In my adolescent-like code, I generate a client_id from the MAC address of the sensor’s micro-controller and the name of the sensor, and that becomes part of the topic nomenclature. That way I can test the callback to see which device published the data or which sensor and act (or not act) accordingly. In Hass.io, one must account for the fact that you can only get one status topic line and one command topic line, but you can still subscribe to many topics with wildcards (+.#). I do it like this example:
state_topic: "stat/+/garage/door2/#"
So a particular Hass.io mqtt device is listening for all status messages (from the #) for garage door2 regardless of which device/sensor (+) sent the data. But in code, if I wanted to, I could parse the data and see that “+” part of the topic is “reedsensor:00:A1:3D” or perhaps “ultrasonic:00:A1:3D”. In that way, I can tell which micro-controller published it (by the abbreviated MAC address) and from what sensor the data was derived (from the “sensorname” parts.
To use Owntracks with the internal broker a small configuration change must be made in order for the app to use MQTT protocol 3.1.1 (Protocol Level 4).
In the Owntracks preferences (Android: v1.2.3+, iOS: v9.5.1+) open Configuration Management; Find the value named mqttProtocolLevel and set the value to 4. The application will now use MQTT 3.1.1 to connect, which is compatible with the embedded broker.
yeah, i think i got it working for my testing pupose.
I am now using an unencrypted mqtt broker for further testing with a sonoff switch and a NodeMCU Chip.
For Owntracks I will setup a separate encrypted mqtt broker, when this is possible.