I am running MQTT Explorer on the same machine as Docker. I don't have the built-in firewall turned on. I use Eero Wi-Fi with Eero Plus turned on, and tried opening the port with TCP & UDP, but that produced no better results. I also have Homebridge and the TeslaSpeaks servers running on this machine, and I'm able to use them without an issue. Thanks for your help with this, I know it's a bit out of scope.
I think I see the problem. In the screenshot above, it shows 0.0.0.0:4000->4000/tcp for the (public, one presumes) Teslamate port, but doesn't show the 0.0.0.0 for mosquitto. Check in your docker-compose.yml file that you're actually exposing this port to the outside world?
I use the .yml file from the TeslaMate docker install instructions. I had to un-comment-out the mosquito ports, but it looks the same format as the TeslaMate ports. This is my full .yml file (with passwords redacted). Thanks again.
Summary
version: "3"
services:
teslamate:
image: teslamate/teslamate:latest
restart: always
environment:
- ENCRYPTION_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- DATABASE_USER=teslamate
- DATABASE_PASS=XXXXXXXXXXXXXXXXX
- DATABASE_NAME=teslamate
- DATABASE_HOST=database
- MQTT_HOST=mosquitto
ports:
- 4000:4000
volumes:
- ./import:/opt/app/import
cap_drop:
- all
database:
image: postgres:15
restart: always
environment:
- POSTGRES_USER=teslamate
- POSTGRES_PASSWORD=XXXXXXXXXXXXXXXXX
- POSTGRES_DB=teslamate
volumes:
- teslamate-db:/var/lib/postgresql/data
grafana:
image: teslamate/grafana:latest
restart: always
environment:
- DATABASE_USER=teslamate
- DATABASE_PASS=XXXXXXXXXXXXXXXXX
- DATABASE_NAME=teslamate
- DATABASE_HOST=database
ports:
- 3000:3000
volumes:
- teslamate-grafana-data:/var/lib/grafana
mosquitto:
image: eclipse-mosquitto:2
restart: always
command: mosquitto -c /mosquitto-no-auth.conf
ports:
- 1883:1883
volumes:
- mosquitto-conf:/mosquitto/config
- mosquitto-data:/mosquitto/data
volumes:
teslamate-db:
teslamate-grafana-data:
mosquitto-conf:
mosquitto-data:
Okay, and it looks like /mosquitto-no-auth.conf should contain the appropriate commands to allow incoming connections. What do you see if you do a docker logs teslamate-mosquitto-1 (adjusting for whatever your actual container name is)? I see something like...
1692327204: mosquitto version 2.0.16 starting
1692327204: Config loaded from /mosquitto/config/mosquitto.conf.
1692327204: Opening ipv4 listen socket on port 1883.
1692327204: Opening ipv6 listen socket on port 1883.
1692327204: mosquitto version 2.0.16 running
1692327204: New connection from 172.17.0.4:55992 on port 1883.
1692327204: New client connected from 172.17.0.4:55992 as teslamateapi-4kOT (p2, c1, k2).
1692327204: New connection from 172.17.0.1:37114 on port 1883.
1692327204: New client connected from 172.17.0.1:37114 as TWCTeslaMate (p2, c1, k30).
1692327204: New connection from 172.17.0.1:37116 on port 1883.
1692327204: New client connected from 172.17.0.1:37116 as mqttjs_1846d026 (p2, c1, k60).
1692327205: New connection from 172.17.0.1:37118 on port 1883.
1692327205: New connection from 172.17.0.1:37120 on port 1883.
1692327205: New connection from 172.17.0.5:38532 on port 1883.
1692327205: New client connected from 172.17.0.5:38532 as TESLAMATE_302E3936383 (p2, c0, k60).
1692327205: New client connected from 172.17.0.1:37118 as Arduino-01 (p2, c1, k60).
1692327205: New client connected from 172.17.0.1:37120 as teslamate/cars/ (p2, c1, k60).
It looks like I'm not getting the mqttjs connection like you have.
Summary
1692324166: mosquitto version 2.0.15 starting
1692324166: Config loaded from /mosquitto-no-auth.conf.
1692324166: Opening ipv4 listen socket on port 1883.
1692324166: Opening ipv6 listen socket on port 1883.
1692324166: mosquitto version 2.0.15 running
1692324170: New connection from 172.18.0.4:48998 on port 1883.
1692324170: New client connected from 172.18.0.4:48998 as TESLAMATE_312E7344734 (p2, c1, k60).
1692358431: mosquitto version 2.0.15 starting
1692358431: Config loaded from /mosquitto-no-auth.conf.
1692358431: Opening ipv4 listen socket on port 1883.
1692358431: Opening ipv6 listen socket on port 1883.
1692358431: mosquitto version 2.0.15 running
1692358435: New connection from 172.18.0.3:34180 on port 1883.
1692358435: New client connected from 172.18.0.3:34180 as TESLAMATE_312E7344734 (p2, c1, k60).
That's fine, I just have more clients connecting. (I think the mqttjs is from MMM-Powerwall.)
So mosquitto thinks it's listening to everyone. Those timestamps look like the container has been recently recreated -- I'd recheck some of the earlier places to see if they changed when it was recreated last night. Otherwise, I'm not sure what to check next.
EDIT: The below command apparently created another mosquitto instance in docker, so the app was connecting to that, which was not sending any data to create the devices. I have removed that and now I'm still trying to figure out why my port isn't open even though it's in my .yml file.
Soooo... after a bit of Googling, I ran docker run -it -p 1883:1883 eclipse-mosquitto:<version> mosquitto -c /mosquitto-no-auth.conf that I found here. That allowed me to connect from your device.
I feel like a dumb-dumb though, because now that I'm connected, I'm not seeing any child devices. I've hit both "Configure" and "Initialize" What am I missing?
Is it possible that you changed the compose file, but never applied the changes? That is, did you run docker-compose up -d again after updating the file to expose the ports?
1 Like
That was it. Thank you! So as you can see in the logs I'm connecting and getting data, but I'm not getting any child devices created. I've hit all the buttons again. 
1 Like
Looks like it's subscribed, but not seeing events yet. You can probably poke it along by restarting the Teslamate container, which I bet would re-publish everything.
All good now. When I re-composed TeslaMate lost its connection to Tesla, so had to re-enter the authentication keys. I have a child device now, and it looks to be updating as expected. Thanks again for all of your help!!
Glad you were able to get it going! I wouldn't expect a restart to clear your authentication token if the Teslamate container has a dedicated storage volume, but this side of things should be in good shape.
I had messed with the .yml to remove the key values when I pasted it here, so that may have reset it. I did a server reboot after that and it reconnected automatically, so should be good. Thanks!
1 Like
@mbishop - Is the app directly reading the geofence value to set present/not present as set in the driver? I'm asking because I have the geofence set as my "presence" location. Presence does change to not present when I exit the geofence, but for some reason the geofence value does not update. Odd because I would think that the app is using the geofence value to determine presence, but if the geofence value doesn't update, that wouldn't make sense.
Yes, it reads the geofence value for that. I had found a bug that wasn't handling not being in any geofence properly; that may still be in a branch. If so, I'll merge that today. If that's not it, I'll need to take a closer look.
Alright, cool, thanks. I found and commented on this issue on TeslaMate github, but I'm not sure it's related: Did not update Gefoence via MQTT although position is correct · Issue #3089 · teslamate-org/teslamate · GitHub. If the correct values are coming from MQTT, then seems it's not related.
@brad I think I had the same issue where the geofence name would only change when entering a new geofence, but not when I exited my 'home' geofence and drove through non-geofenced areas only.
My workaround was to use Node Red to publish "none" as the geofence value when Teslamate reported the geofence as null.
In the flow above the first MQTT node listens for the geofence value, the switch node only forwards messages where the geofence is null. The change node changes the message payload to "none", and then the second MQTT node publishes that payload.
@mbishop Will the update you're going to merge cause the geofence name to update
when exiting a geofence for a non-geofenced area? If so, I should be able to disable my workaround.
Yes, it now shows "unknown" if the value is null.
1 Like
@mbishop - Thanks for the geofence update and the work on the app all around. The app is working great for me. Love the real-time updates. I have my web apps running on a separate C-7 hub, so doing the real-time driving updates doesn’t seem to be a problem (65%+ of busy, but only a few % of total CPU)… but once I validate geofence is working the way I need (mainly understanding the coordinates where the geofences are activating, and determining how fast I need to go before the distortion from the subspace field causes me to pass through the geofence barrier without registering), I’ll probably disable this data.
Not urgent, but how difficult is it to add other attributes? I see that MQTT feed provides tire pressure data, and this would be great to have for level alerts. Not familiar with the app and drivers, but I’m happy to dig in and try to write the needed code.
I also park in a valet garage and automatically activate valet mode with Tesla Connect 3.0, so would be great to have that data here as well, but looks like that’s not yet exposed in TeslaMate MQTT. I did put in a request there, so may have something else for you to add at some point 
Thank you!
The driver exposes everything Teslamate made available over MQTT as of when I first wrote it. For new items, it's easy enough to pick a category and drop it in; it needs to be declared as an attribute on the child and added to the arrays of topics in the parent. If something needs a whole new category, that's slightly more involved, but not too bad.
Happy to take a PR if you want to give it a shot, or a pointer to the updated property.
Edit: I went ahead and did it. One extra step required to support unit conversions. Now off to set a Rule Machine rule to warn me if the pressure drops in the morning.... Feedback welcome on the PR before I merge it, particularly grouping it with climate.
1 Like
