So you went the http approach. Why not the MQTT broker approach? The intro tells the MQTT approach has some advantages and I’m trying to figure those out atm.
Learning the protocol and apps 
But for now I don’t need more, don’t need a broker. However, would also like to know how that works… Step by step…
The advantages of MQTT
- not using Athom cloud
- MQTT is a energy friendly protocol
- MQTT has persistence
- Other applications besides homey can subscribe to the locations messages also.
- you can see the location of other house hold members in the owntracks app on your phone
- you can push way points from homey to connected phones (to sync the fences)
The last two points will also be possible for https in the future (showing the location already is available)
Thanks. That might be an addition for the original post. Firing up ssh to the raspberry 
Is it working for you now?
Yeah. Added to the first post and tweaked it a bit more.
I was skimming community and the old forum to decide whether I should use my raspberry or my NAS. Cons of the raspberry: extra wear and tear on my SD card, cons of the NAS: it might have slow responses when it is in sleep mode. I opted for the NAS… Installed, created users (homey, me and the misses) with passwords, disallowed anonymous access, tested with a
/usr/local/mosquitto/bin/mosquitto_pub -h its.my.public.ip -u gerard -P strongpassword -t /sensor1 -m test -d
It’s seems to be hunky-dory, now on with configuring the phoney and the homey…
You can also try the Homey broker app
Ow, yes. There’s an MQTT broker for the homey as well, cons of that: load on the homey. So… in my opinion that was not an option, but for those of us reading this without either a NAS or raspberry, you could get it to work that way as well. Everything for a working ‘Loacation and presense’ (ow, you just edited the title?)
yeah adjusted it to match the name change of the app
Load is pretty decent of the broker on homey
I’m using the CloudMQTT for free and this is also working fine. what is the advantage of using the MQTT Broker on Homey?
Not much…
Just that it is running in your own home (and as such perhaps a bit more secure).
On the negative side is that you have to expose homey to the internet so you can connect from the outside.
Besides that its fun to make and see that it works
1 Like
Yes!! I had to add the 150 to the Homey App, I left it blank. I now see that all the problems I had where in the start post, so in the end was just one big rtfm. So a big mea culpa from my side, I’ll just do a walk of shame around the block an let Homey send notifications about it 
1 Like
I have checked the first and second option, did somewhere read that.
so: Check for double enter events and check for double leave events are checked in my config.
I’m now wondering if it is needed? because both our configs are working.
They are tweaks. If you get multiple notifications for enter or leave events, then you can set them. I only gave the enter events set.
Double events can occur due to GPS drif.
I’m glad I got it working, most of my flows rely on presence and I could not get it to work with my new phone. For now I’m happy with http, maybe in the future I’ll try it with MQTT broker once there’s a guide to follow. Took a brief look at CloudMqtt, but found the guide not n00b proof.
I managed to install the MQTT broker on my Synology NAS. I run LetsEncrypt for a valid certificate. For those that like to know: Control Panel -> Security -> Go to certificate tab -> add the letsencrypt certificate for your public hostname that is pointing to your NAS. That certificate can be used in the mosquitto configuration as well. For those trying to figure that out, the relevant settings are:
cafile /etc/ssl/certs/DST_Root_CA_X3.pem
certfile /usr/syno/etc/certificate/system/default/fullchain.pem
keyfile /usr/syno/etc/certificate/system/default/privkey.pem
You also need to add read rights to these files (chmod a+r fullchain.pem privkey.pem). I can live with the fact that this means my private certificate is readable for everyone with an account on this NAS. A more elegant way would be to add access to just the mosquitto daemon.
The documentation is stressing left and right to set “use_identity_as_username false”, but you don’t want that for a situation where you have a valid certificate. It is intended for a situation where you have a manually installed certificate on your phone that is also providing ‘credentials’, i.e.: having (and using) that particular certificate allows a valid TLS encrypted login. If you make the mistake to set this use_identity_as_username to false, you will get CONNACK errors telling your username or password is not correct. Which is a valid error message, albeit not very helpful remedying the error.
My only worry is that my Synology autoupdates the certificate every 3 months so I keep a valid shortlived LetsEncrypt certificate. I reckon I will run into problems since I expect the broker will not pick up on the on the fly updates to that certificate. So, I think I need to work out a script that is restarting the mosquitto service after an automated certificate update.
My next step would be to actually use the owntrack updates in flows. I disallowed the homey app access to Location data on my phone (and save battery that way) but I obviously would like to update the presence awareness in the Homey sphere (pun intended). What would be an appropriate way to do that? Should I update the status of the already available (but flakey) Presence facility from homey with ‘mark user as away’ leaving a geofence, or should I run flows with a dedicated variable ignoring this build in facility?
1 Like
How do you find out the external ip of a device where you can’t use Google to tell you? 
nmap on your raspberry or ‘fing’ on your iPhone, and Android has similar tools.
Also for a Nas?
