MQTT Switch - State not matching Payload

Configuration
1

Hello,

I’ve got a Clipsal C-Bus system which operates via MQTT. It will accept either ON/OFF commands, or ramp commands for dimming. For example, if I send a payload of “100,4s”, it will slowly ramp up the lights to full brightness over 4 seconds.

If I have the “payload_on” value set as “100,4” and “payload_off” set as “0,4s”, the lights dim nicely. However, my problem is that the MQTT state topic does not match the payloads - the state will show as “ON” or “OFF” still.

I see that there is a state_value_template, but I can’t figure out how to get this to look for “ON” and “OFF”, rather than the payload I send. Can anyone advise?

Cheers,
Ian

2

Hi

I use c-bus/MQTT/HA too, via cgateweb - is that what you are using also?

It may be that you are seeing this issue (which I describe in a c-bus context here). This has now been solved, as you can see from the thread, though the solution has not been released into distribution as yet.

1 Like
3

Yep, I’m using that same plugin - it’s great!

Thanks for heads up, I’ll wait for this to be merged and then swap over to using that method :). At the moment, I’m using this workaround, but it’s not ideal for getting transitions:

  - platform: mqtt_template
name: Living Room
command_topic: "cbus/write/254/56/44/ramp"
state_topic: "cbus/read/254/56/44/level"
state_template: "{%- if value| int > 0 -%} on {%- else -%} off {%- endif -%}"
brightness_template: "{ value / 100 * 255 }"
command_off_template: "0,4s"
command_on_template: >
  {%- if brightness is defined -%} 
  {{ (brightness / 255 * 100) | int }}
  {% else %} 
  100,4s
  {%- endif -%}
4

I haven’t bothered to do the transition timing (though a variant of your mqtt_template solution is referenced here, which suggests there may be code issues here also).

My yaml is just plain and simple, eg:

- platform: mqtt
name: "Bedroom - main"
state_topic: "cbus/read/254/56/18/state"
command_topic: "cbus/write/254/56/18/switch"
brightness_state_topic: "cbus/read/254/56/18/level"
brightness_command_topic: "cbus/write/254/56/18/ramp"
brightness_scale: 100
qos: 0
payload_on: "ON"
payload_off: "OFF"
optimistic: false
retain: false
on_command_type: 'BRIGHTNESS'
1 Like
6

Hi im also using Cbus with Cgateweb and Cgate.
Ive used yur code above but there is some major problem with dimming…

The Neo key input correctly adapts to any brightness changes made by Home Assistant
While Home Assistant shows brightness changes made by the Neo key input
It ignores them, and will restore brightness levels to the previous levels Home Assistant had last set
Or if Home Assistant had not set any brightness levels itself yet + - it will just pump the lights to 100%

↑ This is the behavior under HADashboard GUI with Home Assistants lights.yaml
Every time i navigate between dashboards, the lights get pumped to 100% on the first occasion should i turn the lights on and they initially appear as off even if they are on

Under the default Home Assistant GUI its worse the ON button pumps the lights to 100% everytime regardless of any dimming by either the Neo key input or Home Assistant

Neo Key Functions

  • Short Press: Idle
    Short Release: Mem Toggle 2
    Long Press: Downcycle
    Long Release: End Ramp

Bedroom Desk Lights

  • platform: mqtt
    name: Bedroom Desk Lights
    state_topic: “cbus/read/254/56/10/state”
    command_topic: “cbus/write/254/56/10/switch”
    brightness_state_topic: “cbus/read/254/56/10/level”
    brightness_command_topic: “cbus/write/254/56/10/ramp”
    brightness_scale: 100
    qos: 0
    payload_on: “ON”
    payload_off: “OFF”
    optimistic: false
    retain: false
    on_command_type: ‘brightness’

I have tried nearly every combo of retain: true, qos: 1, no payload_on all of which seem to make no difference.
Can you suggest some other settings i could try,
Thanks Dave!

7

Hi

First off - what version of HA are you using? Just want to make sure you are using one of the recent releases which solved the bug I referred to above.

Secondly - I’d suggest you have a look at what MQTT messages are being posted, see if you can work out where the issue is arising. I first came across the bug by seeing the older versions of HA posted an c-bus “on” after sending a c-bus “ramp”, thus negating the ramp. It sounds like something similar is happening to you albeit with the Neo not posting correctly maybe? See if you can track down any difference between expected and actual MQTT postings.

8

Hi thanks!
Im using Home Assistant v0.60.0

Subscribing to: mosquitto_sub -v -V mqttv311 -t “#” -u “USERNAME” -P “PASSWORD”

This is the MQTT results from the Bedroom Desk Lights .yaml

Neo Key input publishes:

Turning the light ON: (short press short release)

cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 70

Dimming the light to 30%: (long press long release)

cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 0
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 30

Turning the light OFF: (short press short release)

cbus/read/254/56/10/state OFF
cbus/read/254/56/10/level 0

Turning the light back ON: (short press short release)

cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 30

Home Assistant publishes:

Turning the light ON: (press toggle)

cbus/write/254/56/10/ramp 100
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 100

Dimming the light to 30%: (-)

cbus/write/254/56/10/ramp 89
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 89
cbus/write/254/56/10/ramp 78
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 78
cbus/write/254/56/10/ramp 67
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 67
cbus/write/254/56/10/ramp 56
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 56
cbus/write/254/56/10/ramp 45
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 45
cbus/write/254/56/10/ramp 34
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 34
cbus/write/254/56/10/ramp 23
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 23

Turning the light OFF: (press toggle)

cbus/write/254/56/10/switch OFF
cbus/read/254/56/10/state OFF
cbus/read/254/56/10/level 0

Turning the light back ON: (press toggle)

cbus/write/254/56/10/ramp 23
cbus/read/254/56/10/state ON
cbus/read/254/56/10/level 23

9

Nothing immediately obvious wrong with that. Though I am a little surprised by the last one - I would have not expected it to retain the brightness level.

Which of those actions that you have detailed produces unexpected behaviour of either the light or the HA interface?

1 Like
12

The Neo key input set the brightness level to 30 before it turned the light OFF.
But Home Assistant pumped the brightness to 100 when it turned the light back ON.

Not shown in the example,
But if Home Assistant sets the brightness level to 70 and then turns the light OFF.
The Neo key input will turn the light back on to 70.

CBUS remembers the last brightness value regardless of who adjusts it.

While the Home Assistant GUI visually displays brightness adjustments made by the NEO key input
The Home Assistant ON/OFF button only remembers brightness values adjusted by Home Assistant.

The other issue in HADasboard which i think is the same issue,
Any interruption will cause Home Assistant to forget brightness
Even if i only use Home Assistant to set the brightness levels
If I navigate to a different dashboard and come back,
The correct brightness value is shown on the dashboard
But if i turn the light OFF and then back on it will be pumped to 100%

Example using HADashboard buttons

5088×1200 589 KB

Example using NEO key inputs

5088×1200 531 KB

I only learned what Home Assistant and Ubuntu was 1 week ago
So i still do not properly understand MQTT
Any further suggestions appreciated!

13

Since I use neither HADashboard nor Neo switches, I am not sure I can help very much here.

But it seems to me that the behaviour of HA is as expected - from an OFF position a change to ON (as opposed to a setting of BRIGHTNESS to 70) should move to 100%. HA is not really designed to retain previous state information. (So I think your “Wrong” example is right, and your “Right” example is wrong behaviour!)

That’s why I was surprised that the last ON toggle in your MQTT output above showed “cbus/write/254/56/10/ramp 23” - I can see no way that HA could/should have retained that 23 value.

Of course, it may be that the Neo switch does retain the brightness info, which my more basic c-bus switches do not. And that may be why we expect different behaviour.

You may want to raise a query with the code developer for the HA MQTT module ) or the cgateweb developer.

15

Hi,
In the first Example: using HADashboard buttons
Step 1: The light is turned ON and manually dimmed to 50%
Step 2: The light is turned OFF
Step 3: The light is turned back ON ( automatically goes to 50%) :heavy_check_mark:

It seems I must dim the light first ( + or - )
At least 1 time immediately before i turn the light OFF and back ON
For Home assistant to turn the light ON at the correct brightness level

I need a way to publish the brightness level to Home Assistant before it turns the light ON
Without manually dimming ( + or - ) the light first :confused:

Ill ask the Cgateweb developer maybe he will know a way. Thanks!

16

You may want to look at the help entry for MQTT Light - especially the on_command_type part, if you want the MQTT ON command to be sent before the brightness level

17

I have found one combination that semi works!
Home Assistant know obeys the last brightness level in the default HA GUI as well as in HADashboards even if i change dashboards it never pumps the brightness to 100% if a previous brightness has been set.

I had to change:

brightness_state_topic: “cbus/read/254/56/10/level”

to

brightness_state_topic: “cbus/write/254/56/10/ramp”

and use both:

brightness_command_topic: “cbus/read/254/56/10/level”
brightness_command_topic: “cbus/write/254/56/10/ramp”

the problem now is the old code:

brightness_state_topic: “cbus/read/254/56/10/level”

Seems to be the command that synced the NEO key input to Home Assistant
But was also the command that was pumping the lights to 100%
Without it the NEO key input and Home Assistant work independently of one another with regard to brightness. ON and OFF are still synced tho.
I prefer this to Home Assistant pumping the lights to 100%
But there must be a combination or order of commands that can sync both devices and not have Home Assistant pump the lights to 100%.

This is the code I have atm:

  • platform: mqtt
    name: Bedroom 3 Desk Lights
    state_topic: “cbus/read/254/56/10/state”
    command_topic: “cbus/write/254/56/10/switch”
    brightness_state_topic: “cbus/write/254/56/10/ramp”
    brightness_command_topic: “cbus/read/254/56/10/level”
    brightness_command_topic: “cbus/write/254/56/10/ramp”
    payload_on: “ON”
    payload_off: “OFF”
    brightness_scale: 100
    on_command_type: ‘brightness’
    qos: 2