Not getting protocol error message is already a positive result. I’d keep that version while trying to make other things to work. Then when everything works it would be a good time to figure out the way to separate the password.
In case anyone else runs into this: apparently the max number of characters for the mqtt password for garadget is 31, and it will silently truncate to 31 if you put in something longer–which prevents the garadget client from connecting to an mqtt server expecting the full password (lots of “Socket error on client” errors in the mosquitto server log).
Are there any plans to expand garadget mqtt support? I’d like to use ssl with certs from letsencrypt on my mqtt server, but I don’t see any way for garadget (connecting to IP only, only authenticating via username/password) to support that configuration as it currently stands.
Seems like perhaps the sample brightness-updating automation isn’t valid anymore. We have to use time_pattern now:
- alias: 'Update Garage Brightness'
trigger:
- platform: time_pattern
minutes: '/2'
action:
service: mqtt.publish
data:
topic: "garadget/Home/command"
payload: "get-status"icon_template doesn’t work anymore either but I added device_class: 'garage' to the cover for the same icon effect
1 Like
I also had to change value_template for the cover to fix the above unknown-state bug. I got it to show an open state when it’s anything but closed, making the icon the open state when the door reports being partway through as ‘opening’ and ‘closing’
value_template: >-
{% if value_json.status == 'closed' %}
closed
{% else %}
open
{% endif %}
I’m using MQTT-only but I’m not sure if that’s required to make this work.
1 Like
Just wanted to let you all know that I open sourced the Garadget integration for Homebridge, using MQTT project. Everything was especially easy to code up thanks to the great work of the team over at Garadget! Keep up the excellent work!
2 Likes
Thank you for the shoutout in your code. I didnt even know this was going on.
1 Like
I have moved my garadget in Home Assistant to MQTT. Every thing seems to work except the following automation. I can execute the automation manually and the door closes but the door does not close 10 minutes after it opens. When I view the status I see it go from closed to open. Any help would be appreciated.
- id: ‘1521918378249’
alias: Close Garage Door
trigger:- entity_id: cover.homegarage
for: 0.10.00
from: closed
platform: state
to: open
condition: []
action: - data:
entity_id: cover.homegarage
entity_id: cover.homegarage
service: cover.close_cover
- entity_id: cover.homegarage
Dennis,
I would suggest testing your automation with some other trigger/action and shorter delay - something that you can quickly and repeatedly reproduce. Say a light that turns off after in 10 seconds after you turned it on. Depending on how it goes you’ll know if the issue is related to automation or Garadget’s MQTT connection.
I am not sure if its the reason why some people are having issues with Home Assistant, I am also having issues, I can control the door but not get the status so i was listening on garadget/# in the dev tools and noticed that even though I changed the topic from “Garage Door” to “GarageDoor” - i really hate using spaces in anything code related so i removed the space. I am thinking maybe the people who have success left the default topic and the ones with issues changed it perhaps?
But I am getting this:
As you can see garadget is using the old topic and the new one and i suspect that is why things arent working properly.
I am going to try and factory reset the garadget and then leave it set to Garage Door with the space and see if that fixes my issues.
EDIT: Yes, i only have 1 garadget at my house.
now i have 3 different topics Gararge, Garage Door and GarageDoor and to make things worse one of them is accurate the other is showing the door always open. Not sure what is going on.
The old topics are likely cached in the broker with the state in last message that was retained. Resetting the broker should remove dead topics.
I deleted all the retained messages using mqtt explorer and still even though my Garadget is set to topic of “Garage” its still giving the status as “Garage Door” topic. I should point out “Garage Door” is the “name” of my Garadget (the first field you set in the app). I am guessing that is where that is coming from.
I tried to reset the Garadget so that the topic was “Garage Door” but it doesnt let me, I guess due to the space.
I am going to try and re-name my garadget to “garage” to match my mqtt topic and see if that fixes the different mqtt topics.
thanks is that a bug or inteded behavior? Wouldnt that mean its ignoring the topic you set during the config?
This appears to be the case for me also. Although it did register that topic name with MQTT broker it doesn’t seem to publish anything to it…if that makes sense. Using MQTT explorer I was able to see both names. The “device name” as a topic along with the name I set in firmware as “topic”. However only the device name responds.
I had some issues with this myself. What appears to have worked it out for me was to use MQTT explorer to send a json payload of {"nme":"Garage"} to the topic garadget/Garage Door/set-config
Also make sure the name of the door in the web interface and the app is set to “Garage” and reset the wifi / mqtt settings using the topic name “Garage” (I dunno if that makes a difference but that’s what I did and it seems to have corrected the issue of using the old device name). I think what really did it though was the first step of sending the json payload.
This page claims when you reboot it will be overwritten with the one saved in the cloud via apps but so far nothing has changed for me even after rebooting.
Thanks I will try that, currently I am working around the issue like this:
cover:
- platform: mqtt
name: “Garage Door”
command_topic: “garadget/Garage/command”
state_topic: “garadget/Garage Door/status”
value_template: ‘{{ value_json.status }}’
payload_open: “open”
payload_close: “close”
payload_stop: “stop”
sensor:
-
platform: mqtt
name: ‘Garage Door’
state_topic: ‘garadget/Garage Door/status’
value_template: ‘{{ value_json.status }}’ -
platform: mqtt
name: ‘Garage Brightness’
state_topic: ‘garadget/Garage Door/status’
unit_of_measurement: ‘%’
value_template: ‘{{ value_json.bright }}’
my topic is set to “Garage”. what is interesting is it wont let you save Garage Door as the topic name (due to the space) and it wouldnt take GarageDoor either (not sure why). With the topic set to Garage its still using the incorrect topic of Garage Door AND the correct topic of Garage as shown in my working config.
I think I figured out how the configuration works. At least this is what I did.
When you go to the Garadget device and press the “M” button for about 3 seconds until the LED starts blinking dark blue, and then you connect to the Garadget device (connect to WiFi access point PHOTON-XXXX and open browser to http://192.168.0.1) the entry you make for “Device Topic ID:” is what ends up being used in the MQTT topic. So do not use any spaces in that “Device Topic ID”. I used something like “garage5”. Now, in Home Assistant, when I want to issue an MQTT command to cause the device to open the garage door, the command format is “garage/garage5/command” and the payload is “open”.
Then, in your configuration.yaml file in Home Assistant, you can give it a name that has a space, like this:
cover:
- platform: mqtt
name: garage door 5
command_topic: “garadget/garage5/command”
state_topic: “garadget/garage5/status”
payload_open: “open”
payload_close: “close”
If you do that in the configuration.yaml file, Home Assistant will create an entity named “garage door 5” and it will have the entity ID of “cover.garage_door_5”, but you still issue MQTT commands using the topic “garadget/garage5/command” with no spaces.
OT but i just want to say, i really wish i had 5 garage doors 
1 Like