MQTT Hub/Gateway

Apps
1011

This is what comes to mind, to address the above.
Need to do some testing, not decided yet…
Suggestions are welcome :slight_smile:

Options to prevent message loops:

  1. Prevent calling the /set topic, when the device state is changed from mqtt (state topic)? Make this configurable (on/off)?
  2. Keep track of the last message send to the state topic, skip duplicates if the device state did not change in between?
  3. Always check equality with rounded values if the capability type is integer or a percentage (0...100) to prevent inequality due floating point/scaling differences?
  4. …?

Additional MQTT Device improvements:

  1. Set default percentage scaling to ‘keep original’ (for newly added MQTT Devices)?
  2. If the percentage scaling is set to ‘int (0…100)’ (current default) update the capability details min & max values accordingly? Same goes for booleans and true/false vs. 'on'/'off' etc.
  3. Add ‘advanced options’ to MQTT Device configuration, when adding a new MQTT Device (percentage scaling, on/off value, etc.)?
  4. Allow these options to be configured for each capability seperately (currently per device)?
  5. OR…remove all these options from the MQTT Device completely, it overcomplicates things and can now be controlled using the value templates anyway?
  6. …?
1012

I have hit exactly the same issue on my MQTT app for Hubitat. It is very easy to get these MQTT loops. On that platform too it is not possible to determine from the resulting event what/who triggered the update eg MQTT.

So when an MQTT state update comes in from MQTT I store this as the ‘latestDevice’ and its new ‘latestState’ . I update the Hubitat device which consequently generates an event. On examination if the event comes from the ‘latestDevice’ and the state equals the ‘latestState’ I drop sending the /set back to MQTT. Otherwise I assume the device was changed within Hubitat and send the /set.

This seems to work well and requires only the latest MQTT device to be stored. I am not sure how rapid overlapped device state changes might confuse it, maybe several lastDevices should be pushed and popped. The looping is self cancelling.

The issues of rounding or even devices that when you set to say 53 but report 52 back in state is awkward and so I stored additionally the latestValue that I set the Hubitat internal device to and if that gets immediately evented as the same value I drop the /set . So a device reporting 99 in state gets updated to 100 in Hubitat but I check against the 100 (not the 99) and drop the set.

Not sure I’m doing this right either but I have almost no loops except the ones where you set 53 and it returns 52 causing a loop eventually dropping to 0.

1013

I just wanted to mention another MQTT awkwardness I encountered.

A device that supported 11 dim levels (well 10 dims and off) it needed a 0-100 value so 0,10,20 etc were valid. You could also send a /set of say 7 though and it would return a state of 10. This then appears as a state change and trapping sending another /set of 10 I never found a viable way of avoiding so I just let it do that.

1014

Version 3.5.4

MQTT Device:

  • Selected icon styling improvements
  • Prevent calling the set topic for state changes from mqtt
  • Resolved a parsing error for string messages send to topics with an output template
  • MathJS equality expression fix for comparing strings in value templates

Version 3.5.5

  • Resolved an issue for boolean handling in output templates

For version history, see: CHANGE_LOG

@Camelen Does this solve your problem?

3 Likes
1015

I will check. Hopefully this evening!

1016

From what I can tell so far everything works as it should.
There’s no extra /set values.
Since Homey doesn’t react with sending extra /set then there is no loop if I only use value*99/100 on the set template. The dim-slider jumps down once 1% as expected until I change the state template to value*100/99 as you suggested and now everything looks great.

One thing that happened before was that I got a loop on a binary switch blinking back and forth. I never really looked in to what was going on but my guess is that I changed state in HA too fast between on/off so that it got out of sync with Homey so it posted on or off to /set when the lamp had already changed state in reality which made another endless loop. But with this change it shouldn’t happen either so I’m happy.

An anecdote that happened is that I added a “Turned on” capability. The trouble here is that while the set topic accepts true/false the state topic will always show 0-99 where 0 means off.
So I had to set the template to not(not(value) :sweat_smile: It works great, maybe there’s a better way to do it but it shows on/off as it should. (Not saying that this is something for you to do anything about of course).

1017

@Camelen Sounds good!

FYI: This is one of my MQTT Device configs for a light controlled by HA.

{
  "onoff": {
    "capability": "onoff",
    "stateTopic": "homeassistant_state/light/light_office/state",
    "setTopic": "homeassistant_state/light/light_office/set",
    "valueTemplate": "value == 'on'",
    "outputTemplate": "value ? 'on' : 'off'",
    "displayName": "Turned on"
  },
  "dim": {
    "capability": "dim",
    "stateTopic": "homeassistant_state/light/light_office/brightness",
    "setTopic": "homeassistant_state/light/light_office/set_bri",
    "valueTemplate": "round((value / 255) * 100)",
    "outputTemplate": "round((value / 100) * 255)",
    "displayName": "Brightness"
  }
}

For HA Discovery config:

{
  "uniq_id": "mqtt_light_office",
  "name": "Office light",
  "pl_off": "off",
  "pl_on": "on",
  "bri_stat_t": "homeassistant_state/light/light_office/brightness",
  "bri_cmd_t": "homeassistant_state/light/light_office/set_bri",
  "state_topic": "homeassistant_state/light/light_office/state",
  "command_topic": "homeassistant_state/light/light_office/set"
}

Working on:
image

image
image670×775 17.9 KB
image
image470×728 8.29 KB
image
image463×729 22.1 KB
image
image472×727 31.5 KB

3 Likes
1018

Version 3.6.0 (test channel / beta branch)

  • Home Assistant Discovery device driver
  • Renamed setTopic to commandTopic
  • Fixed topic configuration for MQTT Devices created from discovery
  • Improved discovery topic subscription
  • Removed success popup when a new device is added from discovery

HOW TO?

STEP 1: Enable the Home Assistant MQTT statestream

mqtt_statestream:
  base_topic: homeassistant/statestream
  publish_attributes: true
  publish_timestamps: false
  exclude:
    domains:
      - zwave

STEP 2: Create a new Automation with BluePrint: MQTT State Stream to MQTT Discovery

STEP 3: Import your lights, switches, sensors & binary_sensors from auto discovery (see screenshots from previous post)

1019

Is it possible to add blinds too?

1020

Not yet…therefore the BluePrint needs to be extended.
Covers are on the list. They are already implemented the other way around (Homey => HA), so it won’t be that hard to add them.

1 Like
1021

Currently working on the grouping of entities (capabilities) per device, if provided in the HA config.

1022

Excuse my ignorance but what is the difference between those two? Covers and blinds. When I read a bit I indeed noticed covers being available for exposure to mqtt. They seem to support everything I need; open, close, stop.

1023

There is only a HA mqtt device for covers?

see: MQTT Cover - Home Assistant

1024

@Martijn_Hoogenbosch Do you have an example HA mqtt device config for your blind?

1025

This is what I found too. That’s why I thought I might not get it. But I only saw ‘cover’, and figured this is probably what I need.

1026

Not yet, I’m installing now

What I currently have is the Home Assistant app installed, have created scripts for UP, DOWN and STOP for every blind and imported those to Homey (the app doesn’t support blinds directly) and have created flows to bind the virtual device buttons to those scipts.

1027

@Martijn_Hoogenbosch The auto discovery creates MQTT Devices based on the provided /config info.
So you could first try to manually add an MQTT Device?

1028

Version 3.6.1 (test channel / beta branch )

Home Assistant auto discovery device driver:

  • group entities/capabilities per device
  • allow optional device_id in discovery topic
  • retain HomeAssistant config topics
  • customize capability display names
  • added default capabilities for sensor types: text, numeric & binary
  • improved HA entity to capability matching

image
image467×727 20.1 KB

2 Likes
1029

Were you be able to do something about the fan speed issue I had in this new version too; @HarriedeGroot ?
Or will you be in the future perhaps?

1030

Nope, HA mqtt fans are not implemented yet.