I tried and failed to get the add on to work with the hub, although I didn’t spend much time on it. I had a play around with it and got the certificate and CA uploaded and the logs showed it was listening on the the right port, but there wasn’t a successful connection.
In the end I created a new Mosquitto docker container on the same host as pethub local. Configure that as per the setup instructions and then add this to the config file:
connection homeassistant
address [IP address]:1883
remote_username [username]
remote_password [password]
topic pethub/# out 0
topic pethub/# in 0
topic homeassistant/# out 0
This syncs everything in the relevant topics over to the ha add-on and back. It seems to work flawlessly and I’ve not noticed any latency. It’s a bit of a workaround but it will do for now.
Perhaps that could be a feature? It could be incorporated into the main pethublocal stack and be configured by the setup script.
I’m trying to understand the use case here @flyize and @eviltom you are both using the Home Assistant blue which includes the Mosquitto MQTT Broker but it requires authentication.
The issue is the Hub is hard coded to only support Certificate based authentication over TLS on port 8883 which comes back via the /api/credentials call.
The python pethublocal stack can connect to any broker over 1883 but it also needs to listen on 80 and 443 for the initial boot of the hub to be the webserver for the /api/credentials call.
And as above after both I set the QOS to 1 as the hub expects all messages to be QOS = 1 so it might be worth setting.
I haven’t seen how the blue is setup as the fact it has authentication is what is the problem for the Hub.
I would have assumed having these lines in the broker config should have meant that anonymous auth was enabled for this port.
per_listener_settings true
allow_anonymous true
But if the config for the HA MQTT Broker is overriding this it that seems odd. Will download the HA Blue image and have a poke through it to see. Edit: Seems like there is a HAOS version of the ODroid C2 image, which I have a few here as it is my preferred hardware so will try loading it on and see how it all hangs together.
If it matters, I’m not using Blue (which I think is the dedicated hardware?). I’m running a Supervised HA install with the Mosquitto add-on. Either way, yes it requires authentication.
Ok, now I understand the issue. Have had a look at the Mosquitto add-on rather than the MQTT Integration which is what I thought everyone was using.
The HA Mosquitto add-on doesn’t have any support for allow_anonymous true in their build script. So even if I added the correct settings for the CA Cert + public and private key it still expects a username and password to authenticate to MQTT which the hub doesn’t support in the 2.43 firmware from my various attempts.
This is the mosquitto.conf that gets created in the add on docker container.
And the init script would need to be updated to support allow_anonymous true on the 8883 port.
So I think the @eviltom approach is correct, and then update port 8883 on the main Mosquitto addon to not listen on 8883, and then map through 8883 to the “PetHubLocal-Mosquitto” add-on.
I haven’t really checked out add-ons before but it does look like an excellent way to deliver the whole PetHubLocal stack so if time permits I will just build everything into an add-on, or perhaps two addons one for MQTT just for port 8883, and another for the main PetHubLocal python app.
Just to clarify - I believe a Home Assistant add-on is effectively just a way of running a docker within a managed Home Assistant OS install. So the HA MQTT add-on is just an MQTT broker running on the same hardware as HA itself, but in a separate process. The HA MQTT integration runs in HA itself so that it can publish and subscribe to whichever MQTT broker you configure it for, either the one running in the add-on or a separate one on say an unRAID server like I have.
From the HA MQTT add-on documentation, it looks like the configuration file can be accessed via SMB so the process for making changes to it should be similar whether using the add-on or a separate broker. Combining this with the idea of configuring separate MQTT listeners within a single broker, should mean that PetHubLocal can run with a single local MQTT broker (so no bridging needed), and that broker can either be the HA add-on one or a separate one.
As far as I’m aware, the software is the standard supervised arrangement just repackaged for the ODroid. I’ve not noticed any operational difference with the Pi images at any rate.
When I tried, pethub local connected to the add on and created the auto-discovery topics just fine, although I needed to add a username and password to the configuration.
There are some input fields on the add-on config screen and I added the the paths for the key files and the CA file, and the entry for the additional port. @user_id_for_q , you are right, there’s a SMB share on the HA host called ‘share’ and in that I created ‘mosquitto/certs’ to emulate the path for the existing certificate.
I understand (but could be wrong) that the contents of folders in the ‘share’ folder is merged with the contents of the corresponding folder in the filesystem.
I initially just added a separate config file in this folder with the additional config lines, hoping they would just get merged in but I think it’s fussy about the order the config happens, or maybe duplicate config lines, and wouldn’t boot so I moved everything into the add-on config screen.
After a reboot the add on reported it was listening on both ports and I could see the hub attempting to connect in the add-on logs at the appropriate port, but being rejected, either because of some error in my config or because it’s not presenting a username and password.
As I was impatient at the time I just spun up a new docker on unraid and configured that with the certificate etc, just to prove everything else was working. It was easier to configure that as required rather than the add-on as most of the more advanced configuration is (deliberately) hidden away from the 95% of users who will never need to touch it. I intended to come back and have another go at the HA addon but then found the documentation for setting up a bridge between two brokers and went with that.
I hadn’t considered the possibility of a HA addon for Pethublocal, I was just thinking that a pre-configured instance of Mosquitto in the pethublocal docker stack with just your existing mqtt broker address needing configuration, which would make it a neat turn-key setup. But I like the addon idea.
I’d probably go with the single add-on because if the existing Mosquitto add-on can’t support the hub’s needs, then your’re always going to need the ‘PetHubLocal-Mosquitto’ add-on anyway.
Had a busy day today but was looking into the add on process and it looks very straightforward as a docker image. So if time permits I will setup something as an add on with both mosquitto and PetHubLocal in one place, then have the username & password for surepetcare and the whole stack should deploy in one go.
The only thing that would be needed is changing the tls port to something other than 8883 on the standard MQTT add on and setup a MQTT user/pass for the PHL MQTT to connect to the main one.
So @flyize and @eviltom I have built an addon and it all seems to work for me™ as creating an addon turned out to be easier than I expected. Few little issues getting my head around how the init system works with HomeAssistant but the docker container was easy to setup as I already had most of that sorted.
It assumes you are using the core_mosquitto MQTT Broker included in HAOS / Supervisor.
Then you need to change two things in the core_mosquitto configuration
Add a new local user for the PetHubLocal broker to be able to authenticate to the core broker by adding the following under the Logins section:
- username: pethublocal
password: pethublocal
Update the TLS port from 8883 to anything else like 8882 so then the PetHubLocal Broker can listen for the Hub.
Then you will see that it has 3 ports listening. 80/443/8883 for the 3 ports the hub needs.
Lastly configure the PetHubLocal addon to have your SurePetCare username / email address and password then when the Addon starts it pulls down everything and puts it all onto the share share under /pethublocal so you can map a drive to it if you have Samba enabled and see all the config files.
Also just be patient for the install to complete, as it takes about 7 mins on my ODroid C2 running HAOS to download and build the docker container as it’s deploying the standard HA Docker image then apk installing the necessary OS packages then pip installing the python packages and all that takes time depending on how fast your host is.
Haven’t really tested it too extensively but it all seemed to work for me.
All set up and working well. Very easy to set up. I copied an pasted my existing config file across so it just started working.
One small problem I encountered: When you first install the core_mosquitto addon you are instructed to setup a new user in home assistant (not in the addon) to use for authentication. I guess the addon imports the user authentication when it boots.
I found that by adding
- username: pethublocal
password: pethublocal
to the core_mosquitto config page that the import of existing user info didn’t happen and ‘pethublocal’ became the only valid username and password. Every other mqtt client could no longer connect.
I fixed this by adding in my previous username and password under the pethublocal entry, so now both work again.
The percentage is possible but a little complicated due not all batteries being equal so just because you reach a voltage number doesn’t mean it stops.
In regards to connecting back to the surepet cloud. No. I have completely cut the surepet cloud off and everything is pointing locally. Technically I could route the messages there too as we do have the certificate and password needed to authenticate to AWS but then it gets even more complicated as what should I do with command messages the cloud sends if the state is different to the local state.
It’s something I can add in the future but I do have plenty more features I want to add such as easy curfew modifications as the home assistant UI doesn’t have easy to use time pickers so that sort of functionality will go into the http webserver UI on port 80.
The battery voltage does get reported. I remember ages ago I did find the JavaScript where surepet determine the 4 bars.
I’ll find that and also create two variables with an upper and lower bounds default values for each device so then it can be calculated but depending on the batteries and environmental conditions.
The voltage or percentage hasn’t impacted me too much as my pet door is always unlocked and when the whole unit dies I get reported of that fact as you will see the device goes offline as I update the Availability state for it. So then I just replace the batteries when I get home, or these days I am always home.
Ahhh, my concern would be that the batteries die while I’m on vacation and then the cats that aren’t litter trained can’t get outside. That’s bad.
More importantly, it seems mine isn’t working. If I ping hub.api.surehub.io, I get my local server. If I browse to that URL, I get the Pet Hub Local page. I made sure to manually set DNS for HA to the poisoned DNS servers. Yet, a cat just went outside and the only place I see the status update is in the SurePet app. Nothing in MQTT.
edit: I forgot to restart HA after the DNS update. I bet that’s it. Will check later.
