Trying to get autodiscovered fans to show current state

[arrikhan]

Hi,

I’ve managed to define CBUS fans (that use a CBUS fan controller) in Home Assistant by simply including the tag “FAN”. It is discovered by Home assistant and controllable by home assistant by selecting preset modes to change the speed (low, medium, high) and can be turned off by switching the fan off.

My previous MQTT integration where I had to define the FAN entity manually, the preset_mode was viewable as a state. I am looking for a way to achieve the same with your code so I can use these entities with fan controller cards in Home Assistant, or even just determine the state before I set the fan or even use with automation based on the state.

[autoSteve]

What did your prior MQTT manual fan configuration look like?

[arrikhan]

Hi,

Using https://github.com/Nick-Adams-AU/5500SHAC-Cbus2MQTT,

MQTT config looked like this.

• name: Office Ceiling Fan (CBUS) unique_id: office_ceiling_fan_cbus state_topic: "cbus/read/254/56/48/state" command_topic: "cbus/write/254/56/48/switch" percentage_state_topic: "cbus/read/254/56/48/level" percentage_command_topic: "cbus/write/254/56/48/ramp" payload_on: "ON" payload_off: "OFF" optimistic: true

[autoSteve]

I could code a fan_perc keyword (for 'fan percentage') to give that kind of discovery instead of using the fan keyword, which would remain as a preset mode option. That work?

[autoSteve]

The commit adding 'fan_pct' should give a discovery topic to replicate what you had before (I changed this from fan_perc). Let me know how it goes @arrikhan.

Cheers.

[arrikhan]

Will test on weekend. Thanks!

[autoSteve]

Assuming all is well with this addition, @arrikhan.

[arrikhan]

Hi, firstly apologies for not coming back sooner. I was dealing with some stuff that needed my attention.

This hasn't quite achieved what I was after.

I am looking to be able to display preset mode for current state. I can see in the MQTT discovery that you're discovering the payload

Received 12:33:06 PM
QoS: 0
Payload: 86

Received 12:36:16 PM
QoS: 0
Payload: 0

When I setup a card in HA and display the attribute "preset_mode", it remains null. Ideally I want to see preset mode (low,med,high) for normal fan and percentage for fan_pct card in the attribute preset mode:

This is a typical entity card where I am trying to display attribute in addition to on/off and controls.

cards:

• type: entity state_color: true entity: fan.cbus_mqtt_254_56_23 attribute: preset_mode

This is the entity state `

Entity | State | Attributes -- | -- | -- fan.cbus_mqtt_254_56_23Ceiling Fan Living Room | off | preset_modes: low, medium, high **preset_mode: null** friendly_name: Ceiling Fan Living Room supported_features: 8

[autoSteve]

One. Year. Later...

Oops. I do so apologise, @arrikhan. March 2023 was nuts, and then you scrolled off the screen...

I re-read your comment about five times, and did some Googling for preset_mode. I might need this spelled out in more words to achieve what you want to achieve by using MQTT discovery.

I have committed a minor tweak to the preset_mode_value_template in MQTT discovery. Does that help at all? Basically I forgot to cast the value as a number before comparison.

[autoSteve]

And had an invalid preset value of 'OFF', not 'off'...

[arrikhan]

Ok I have made a couple of changes.

1. Updated my firmware on SHAC5500 to 1.15.0 (from 1.11.0)
2. Replaced MQTT send receive script
3. Replaced MQTT hearbeat script
4. Replaced MQTT with MQTT Final script

Am now receiving error ...

* string: Error firmware > 1.15.0: Event script 'MQTT final' is set to execute during ramping. Turn this off. Not starting.

I can't see where to turn it off as this is the job of the FINAL script? Or have I misunderstood this?

I have installed the MQTT (not the FINAL one) script and it starts up with the warning about using the FINAL script

Also, I have found that I have to keep the original filename for MQTT and MQTT Final as the send receive it looking for this.

PS: No stress about missing my previous notes.. we all get caught up :)

[arrikhan]

Tested fans briefly.

Preset states are now changing as expected.

When the fan is turned off however, the state is not set to 'off', it retains the last state so when displaying in HA is shows low, medium, high ... even when the fan is off. To me it would make sense to set the state to off also?

[autoSteve]

The event script must be called either 'MQTT' or 'MQTT final'. These are not case sensitive, but must be called these names. If both are present, then the script will automatically disable the one it doesn't want based on AC firmware version.

If you click on the event script name then its properties will be displayed. The setting for execute during ramping is in there. Firmware >1.6.0 and <1.15.0 it did not matter what this check box was set to. Scripts ALWAYS executed during ramping. They now don't if the check box is cleared. (Which is the default, so anyone upgrading to 1.15.0+ might get some surprises!

Good to hear the preset state is now updating for you. And I see the same thing for 'off' with the preset remaining where it was. The preset_mode_status_template for discovery is set by the script and includes a value for 'off', so I don't fully understand why HA doesn't show off. However, it may be useful to see this previous preset state. If you simply switch the fan on it should return to the prior preset state, so seeing this might be actually handy! This may be where the HA developers heads are at.

'{% if value | float == 0 %} off {% elif value | float == 86 %} low {% elif value | float == 170 %} medium {% elif value | float == 255 %} high {% endif %}'

[autoSteve]

This is interesting.

I configured MQTT send receive to set up preset modes of 'off', 'low', 'medium' and 'high', and the preset of 'off' still doesn't show. ~Must be by design...~

Here's what the discovery topic now looks like for me:

{
"ic":"mdi:ceiling-fan",
"dev":{"ids":"Hutch Sweep Fan","mdl":"CBus","sa":"Hutch","mf":"Schneider Electric","name":"Sweep Fan"},
"pl_on":"ON",
"pl_off":"OFF",
"uniq_id":"cbus_mqtt_253_56_119",
"obj_id":"cbus_mqtt_253_56_119",
"stat_t":"cbus\/read\/253\/56\/119\/state",
"cmd_t":"cbus\/write\/253\/56\/119\/ramp",
"pr_modes":["off","low","medium","high"],
"pr_mode_cmd_tpl":"{% if value == \"off\" %} 0 {% if value == \"low\" %} 86 {% elif value == \"medium\" %} 170 {% elif value == \"high\" %} 255 {% endif %}",
"pr_mode_val_tpl":"{% if value | float == 0 %} off {% elif value | float == 86 %} low {% elif value | float == 170 %} medium {% elif value | float == 255 %} high {% endif %}",
"name":"",
"pr_mode_cmd_t":"cbus\/write\/253\/56\/119\/ramp",
"pr_mode_stat_t":"cbus\/read\/253\/56\/119\/level",
"avty_t":"cbus\/status"
}

[autoSteve]

And I had an issue that was throwing an error in the HA log. Fixed just now.

[autoSteve]

I must be having a really bad day, @arrikhan. Check the latest commit. This adds 'off' to the list of presets, which I believe is exactly what you want.

I noticed a syntax error (in bold, should be elif)... "pr_mode_cmd_tpl":"{% if value == \"off\" %} 0 {% if value == \"low\" %} 86 {% elif

Do let me know if you still can't get 'MQTT final' working with 1.15.0.

[autoSteve]

And could I also get you to test the fan_pct keyword, please, @arrikhan? fan_pct was always really busted. It now shows on/off for the device in lovelace, and in the card detail a slider with off:0/low:1/medium:2/high:3. Or it should...

When using fan_pct the preset_state does not get updated by default. To do so, add the keyword 'preset' along with fan_pct, which will also show the presets in the card, and update preset_state.

[arrikhan]

On a side note, I've doubled all my devices in HA again through upgrading the scripts... was there an easy way to clean this up?

[autoSteve]

Try a simple HA restart? If that doesn't get rid of the duplicates, then deleting / reinstalling the MQTT integration would be a quick way to delete all the associated devices and entities. Then restart MQTT send receive after reinstall of the integration to rediscover the good devices.

[autoSteve]

This situation of duplicates interests me, @arrikhan, because upgrade. This should not happen, but has happened to me in the past. The MQTT discovery devices should all be created with a unique_id that Home Assistant uses to identify them. This should not have changed since the very early versions of MQTT send receive...

Lately I have changed to publishing cbus/read/0 and write/0 instead of network 254, but this would have only have left some orphan read/ write/ topics that would not have harmed anything. No difference in discovery.

I did introduce a change for #15 to cope with a breaking change in 2024/2 of Home Assistant, but that dealt with naming, devices and entities, and not the unique ID.

A head scratcher.

I wonder if killing all homeassistant/ CBus-related discovery topics on restart would help?

[autoSteve]

Should duplicates happen ever again, @arrikhan, then further info would be most helpful for just one of those duplicates. Feel free to raise a separate issue.

Click MQTT info, and expand the discovery topic of each duplicate...

[arrikhan]

I have tested fan_pct and preset and it works perfectly in HA and subsequently Homekit integration to HA (required!).

For reference, there has been a change in HA some time ago to preset_modes. Homekit uses attributes "speed_list" to combine preset speeds under one slider in Home App. Presenting HA integration to Homekit of CBUS fans with preset_modes results in separate buttons for each speed making a mess of things (not your fault, seems to be HA roadmap).

By supplying percent attributes from your integration (fan_pct, preset) with an entity customisation adding speed_list (see below example), homekit can see and use a fan slider on one button (after hiding the other buttons manually)

fan.cbus_mqtt_254_56_23:
  speed_list: ["off", "low", "medium", "high"]

see: https://community.home-assistant.io/t/solved-ifan03-with-home-assistant-and-homekit-speed-presets-as-5-switches/422179/14