So, I’ll paste my own mqtt configurations for lights, thermostat and blinds. I am assuming you already know your way with yaml and the config.yaml file. I’ve enclosed in < >
what the fields that should be filled with your own ave installation:
-
<MAC ADDRESS>
: I think it’s that mac address of the ave server; you can find it easily listening for any event on the mqtt integration and trying to switch on and off something; it’s the same for every device;
-
<id>
: it’s the id that ave assign to each device in your installation; as above, you can sniff the id by switching on and off the relevant device in your installation;
-
<unique_id>
: the HASS unique id for the device; must be lowercase and without any space
-
<friendly name>
: the name that will be shown on HASS interface; it can be aby string you like
NOTE! the mqtt integration will let you to set the retain policy: NEVER SET RETAIN TO TRUE!.
if you set retain to true, the mqtt server will remember the last imparted instruction, and republish it whenever the server get disconnected/reconnected (which happes quite often), therefore you can have some “ghost” commands fired randomly in inconvenient time (like in the middle of the night, scaring me a lot!). Just let retain to false and never be bothered back.
Lights (switches):
lights are pretty straightforward, just a simple on/off command. In the eye of HASS, this are really switches more than lights.
switch:
- platform: mqtt
unique_id: <unique_id>
name: "<friendly name>"
state_topic: "/<MAC ADDRESS>/devices/lights/<id>/state"
command_topic: "/<MAC ADDRESS>/devices/lights/<id>/state"
payload_on: "1"
payload_off: "0"
optimistic: false
qos: 0
icon: hass:lightbulb # comment out if you want simple switch icon instead of the lightbulb
Thermostat (climate)
thermostat are quite basic: they will constantly publish current temperature, you can read and set the target temp, and you can turn it on and off.
You can’t change the schedule like in the ave app, but with these tool you can set up one of your own with HASS if you like.
climate:
- platform: mqtt
unique_id: <unique_id>
name: "<friendly name>"
modes:
- 'off'
- 'heat'
current_temperature_topic: "/<MAC ADDRESS>/devices/thermostats/<id>/current_temp"
temperature_command_topic: "/<MAC ADDRESS>/devices/thermostats/<id>/target_temp"
temperature_state_topic: "/<MAC ADDRESS>/devices/thermostats/<id>/target_temp"
power_command_topic: "/<MAC ADDRESS>/devices/thermostats/<id>/state"
payload_on: 1
payload_off: 0
qos: 0
Scene
you can even turn on the scene programmed in the ave server. (I am using this less and less though)
scene:
- platform: mqtt
unique_id: <unique_id>
name: "<friendly name>"
command_topic: /<MAC ADDRESS>/devices/scenes/<id>/request
payload_on: RUN
qos: 0
retain: false
Covers
And now I present you my pride and joy!
Covers are tricky to do with mqtt because the topic to set the state of the blind is the same one where to read the current state. So if you want to query the state of the blind, you are really issuing a command to the device. Also the ave server won’t update the state of the blind until it has complete the cycle (if you send open command, the ave server will report the cover is closed until it is fully opened and you hear the physical switch goin off; same in the other direction).
Furthermore, the ave server only support two states: 0 (closed) or 1 (open), but in reality the cover will be in intermediate state (opening and closing) and also you can decide to stop it halfway.
Combine all of this together and you get false commands and “stuttering” of the blind. I strongly suspect that’s the reason you can’t control a cover with google home or alexa.
So, how you can control a device with only two possible states with the HASS cover integration which support 4 different states (5 if you count the stop halfway command)?
Here comes the trick: ave server will only care for the first character of the message payload published on the state topic, so you can have different messages for the different states as long you reseverved the first character to either be a 1 or 0 so that ave server can handle it; HASS will instead read the rest of the message and set the cover state accordingly. I’ve used three payload command (0-OPEN
, 0-STOPPED
, 1-CLOSE
), and five different states:
-
state_open: 0
(will be pulished by the ave server when cover is fully open)
state_opening: 0-OPEN
state_stopped: 0-STOP
state_closing: 1-CLOSE
-
state_closed: 1
(will be pulished by the ave server when cover is fully closed)
cover:
- platform: mqtt
unique_id: <unique_id>
name: "<friendly name>"
state_topic: "/<MAC ADDRESS>/devices/blinds/<id>/state"
command_topic: "/<MAC ADDRESS>/devices/blinds/<id>/state"
position_topic: "/<MAC ADDRESS>/devices/blinds/<id>/state"
payload_open: "1-OPEN"
payload_close: "0-CLOSE"
payload_stop: "0-STOP"
state_open: "1"
state_closed: "0"
qos: 0
device_class: shutter
state_opening: "1-OPEN"
state_closing: "0-CLOSE"
state_stopped: "0-STOP"
optimistic: true
position_template: >- # with this you can differentiate the state when the cover is stopped halfway
{% if (value == '0') %} # the cover is fully closed (0%)
0
{% elif (value == '1') %} # the cover is fully open (100%)
100
{% else %} # any other position will be report at 50% (halfway)
50
{% endif %}
Conclusion
That’s all I was able to to do with the mqtt integration, and that’s more than I could ever do with the ave app or with alexa/google. Have a look if this can be helpful with your installation.
I also have an economizer device in the ave system, but for that you can’t use mqtt; you need the REST integration.