Cancel in-progress transition in Caseta / use middle button on pico remote bonus ZHA example

Third party integrations
1

I’ve been using the Caseta Pico remotes along with some information that I’ve found on the forums to mimic the functionality of Pico remotes to control Zigbee lights through ZHA. I’ve been using stephack’s pico blueprint along with the reccommendations from KennethLavrsen to stop the transition using bri_inc=0 and this implementation. I then read the brightness state through another manual command. I’m using zha_toolkit to implement that functionality to make finding the ieee easer.

I then use a read command to read back the brightness value. I also found that if I didn’t cancel the transition before turning the lights back on, if the light is currently in a transition state, it will turn the light back off, so I added the cancel command again before turning lights on if I press the on button. I spent a while getting it right, so here is the example code for doing it with the blueprint and ZHA-toolkit with the device id’s replaced in case you’re interested.

alias: Office Pico
description: ""
use_blueprint:
  path: stephack/core-pico.yaml
  input:
    pico_remote: 00000000000000000000000000000000
    up_raise:
      - service: light.turn_on
        data:
          brightness: 255
          transition: >-
            {{(((255-states.light.office_closet.attributes.brightness|default(0))/255)*4.9)+0.1}}
        target:
          device_id: 00000000000000000000000000000000
          entity_id: light.office_closet
    up_raise_release:
      - service: zha_toolkit.execute
        data:
          ieee: light.office_closet
          cluster: 8
          endpoint: 10
          cmd: 3
          command: zcl_cmd
      - service: zha_toolkit.attr_read
        data:
          cluster: 8
          endpoint: 10
          ieee: light.office_closet
          attribute: 0
          state_id: light.office_closet
          state_attr: brightness
    bottom_off_release:
      - service: zha_toolkit.execute
        data:
          ieee: light.office_closet
          cluster: 8
          endpoint: 10
          cmd: 3
          command: zcl_cmd
      - service: light.turn_off
        data:
          transition: 2
        target:
          device_id: 00000000000000000000000000000000
          entity_id: light.office_closet
    down_lower:
      - if:
          - condition: not
            conditions:
              - condition: device
                type: is_off
                device_id: 00000000000000000000000000000000
                entity_id: light.office_closet
                domain: light
        then:
          - service: light.turn_on
            data:
              brightness: 4
              transition: >-
                {{((states.light.office_closet.attributes.brightness|default(0)/255)*5)+0.1}}
            target:
              device_id: 00000000000000000000000000000000
              entity_id: light.office_closet
    down_lower_release:
      - service: zha_toolkit.execute
        data:
          ieee: light.office_closet
          cluster: 8
          endpoint: 10
          cmd: 3
          command: zcl_cmd
      - service: zha_toolkit.attr_read
        data:
          cluster: 8
          endpoint: 10
          ieee: light.office_closet
          attribute: 0
          state_id: light.office_closet
          state_attr: brightness
    top_on_release:
      - service: zha_toolkit.execute
        data:
          ieee: light.office_closet
          cluster: 8
          endpoint: 10
          cmd: 3
          command: zcl_cmd
      - service: light.turn_on
        data:
          brightness: 255
        target:
          device_id: 00000000000000000000000000000000
          entity_id: light.office_closet

This works really well to mimic the normal operation of a pico remote through sending all of the manual ZHA commands. That said, if I wanted to do the same thing with an actual caseta dimmer (pico to caseta dimmer without using middle button in order to use that button to trigger effects), I’m not sure how I would do that. I want to be able to use the middle button of my caseta switch to trigger automations, but I don’t know that there is a similar method for cancelling transitions and manually reading the brightness state through the caseta integration. I’d imagine that it must technically be possible as this seems to be how Caseta would be doing it, but I’m not sure how it would be done practically or if the proper features are exposed.

Thanks!

2

Nice toolkit tricks. If I ever move back to ZHA, toolkit may be the reason.

I don’t think there’s anything really analogous for the Caseta integration.

If you want to control the dimming via automations, you’ll probably to use one of HA looping constructs.

If you want special functionality only for the favorite button, leave the pico paired directly to the switch(es), and just listen for the favorite button event. You still need a lutron native default favorite setting for the button, but the automation can ultimately override the default.

3

I think that makes sense. I played around with it a bit, and it looks like the brightness state saved to the favorite button isn’t applied until the button gets un-pressed. I’m thinking that maybe I could save the current brightness state on a press and then call the stored brightness when the button is released and add a condition to keep the light off if I press it while it’s off.

Do you know how to store a state or a variable across restarts of an automation? I see that I could use an input_number, but it seems that I would need to add it to my configuration.yaml. Is that correct, and is there a way that I could store it without adding something outside my current automation?

4

Sounds about right. Be aware there could be some bouncing as the light moves to the favorite preset and then to the automation setting.

An input helper is the sanctioned way to store a value across restarts. You don’t have to use yaml to define a helper, they are available in the UI.

If you’re a yaml guy, then look at Packages to keep your Automation and helper definitions in the same block of code.

5

You’re 100% correct about it bouncing. I used the following along with a pico_press_brightness input number helper:

- id: '1662056646869'
  alias: Middle Button Override
  description: ""
  use_blueprint:
    path: stephack/core-pico.yaml
    input:
      pico_remote: 00000000000000000000000000000000
      middle_stop_release:
        - if:
            - condition: device
              type: is_off
              device_id: 00000000000000000000000000000000
              entity_id: light.office_main_lights
              domain: light
          then:
            - service: light.turn_off
              data: {}
              target:
                entity_id: light.office_main_lights
          else:
            - service: light.turn_on
              data:
                brightness: "{{states('input_number.pico_press_brightness') | int}}"
              target:
                entity_id: light.office_main_lights
      middle_stop:
        - service: input_number.set_value
          data:
            value: >-
              {{(states.light.office_main_lights.attributes.brightness|int)|default(0)}}
          target:
            entity_id: input_number.pico_press_brightness

Using this, the lights dim to about 60% from 100% before getting set back to 100%. It technically works,but it’s certainly not seamless.

I’m pretty new to Home Assistant in general (less than a month), but I’m familiar with Python and C, etc. I’ll check out Packages when I have more time. You say if you’re a yaml guy. Is that as opposed to using the visual interface, or are there other ways of programming home assistant as well? I like the way that templates look, but it seems like that’s only available in the templates section.

6

All you can do is set the favorite preset to the “most likely” level to avoid as much bounce as possible.

One option may be to look for a double click. Clicking “on” you expect it to go to 100%, so a double click to “on” could arguably mean you expect it to go to 100% before adjusting, or the reverse for “off”.

Yeah, just yaml or UI for me.

I refuse to let myself look any deeper with HA. My wife may never see me if I allow myself to go down the “real code” rabbit hole.

7

That makes sense. Thanks!

I did some digging and found the Lutron Integration Protocol document. It turns out that you should be able to to do the same things in their integration. If you look on page 8, command 2 is start raising, command 3 is start lowering, and command 4 is stop raise/lower. Given that, we would just need a way to expose that functionality to Home Assistant.

That said, there is no guarantee that you’d get the same results with the leap protocol in the Caseta system, but it may work.

8

Anything is possible with enough time. At first glance, a hacs caseta-tools using the underlyng pylutron-caseta lib is probably doable, just as ZHA-tools uses the zigpy lib.

It piques my curiosity, but as stated, I’ve sworn off going down the code rabbit hole with HA.