Merge the codebase into HA

[synthead]

Here's a hot potato! There's a lot of chatter about this, so I thought I'd open an issue so we can keep the conversation in one place.

[cajuncoding]

Seriously . . . this is one of the best components I've used for Home Assistant! It's just awesome! It allows me to use Lutron for lighting (works with amazing responsiveness, and full automation integration with other color bulbs, etc.), and also allows me to use Pico remove switches for other innovative things (e.g. I have a wall-mount pico that controls the volume of my reciever, and uses the center scene button to turn on Alexa bluetooth adapter to auto-connect with a short press, and turn it off via long press).

This very much needs to be part of HA . . . as the Caseta Pro Hub component!

[upsert]

@raerae1616 Did you implement short press and long press through HA? What did you use?

[cajuncoding]

@upsert

Yeah I implemented the logic in HA via Python Script.... Here's the snippet that enableds the short and long press. It isn't perfect, but it gets the job done easily from the Kitchen which is some 40+ ft from the reciever, and works well on those occasions that the Echo doesn't recognize my voice, or I just don't get the command right . . .

The concept I came up with was basically to loop inside the python script when the center button (2) is pressed, and keep looping for up to 3 seconds checking to ensure it is still pressed incrementally as it waits . . . and then once a fully 3 seconds elapsed while the button is still pressed it then sets the long_press variable to true, and the rest of the script can then function off the long press.

I currently only support the center button (to help keep the other buttons responsive), but a version of this could easily be made to run for any button with a short (default) or long_press state.

Hope this helps!

#Obtain status of the Pico Remote
pico_status = hass.states.get("sensor.living_room_audio_pico")
pico_state_value = int(pico_status.state)

#DEBUG Notification via Pushover
#hass.services.call("notify", "pushover", {"message": "Denon AVR Volume Switch [Pico={0}]".format(pico_state_value)})

#NOTE: On button == 1 (Full ON)
if pico_state_value == 1:
    hass.services.call("rest_command", "denonavr_volume_high")

#NOTE: Center scene button == 2 (Center Scene Button)
elif pico_state_value == 2:
    long_press = False

    #Get the current Harmony remote Activity
    current_activity = hass.states.get("sensor.htpc_remote_current_activity").state

    #If we are currently off, then Turn on "Alexa Speakers"
    if current_activity == "PowerOff":
        #When the center scene button is pressed, we check and turn on Alexa Speakers mode 
        #   if the Receiver is currently Powered Off; but not if it's already on but in a different mode.
        hass.services.call("remote", "turn_on", {
            "entity_id": "remote.htpc_remote",
            "activity": "Listen to Alexa"
        })
        #IF we just powered on the Receiver then we need to wait for it to initialize!
        #NOTE: time.sleep() param is in Seconds!
        time.sleep(5)

    else:
        long_press_secs = 3  #How many seconds is a Long Press
        wait_refresh_secs = .25 #How often do we want to check for Long Press status
        wait_total_count = long_press_secs / wait_refresh_secs
        wait_counter = 0

        #We wait and watch for a long press...but to be responsive we check our status in short intervals until we know either
        #   if the button was released (short-press/aborting a long press), or eventually the long-press threshold is exceeded...
        #NOTE: We loop in 1 second increments to provide quick response whenever the button is released (rather than wait/block for the entire time)
        #NOTE: we need to refresh from the HASS States to know if it's still pressed
        while wait_counter < wait_total_count and int(hass.states.get("sensor.living_room_audio_pico").state) == 2: 
            wait_counter = wait_counter + 1 #NOTE: += Syntax does NOT Work!
            time.sleep(wait_refresh_secs)   #NOTE: time.sleep() param is in Seconds!

        #After we're done watching for long press, initialize long_press based on how long the button was pressed.
        long_press = wait_counter >= wait_total_count

    if long_press:
        #When the center scene button is long-pressed, we will turn the entire Home Theater Off!
        hass.services.call("remote", "turn_off", { "entity_id": "remote.htpc_remote" })
    else:
        #When center button is short-pressed, we set the volume to Medium!
        hass.services.call("rest_command", "denonavr_volume_medium")

[czoog]

Agreed, this component is the backbone of my system, and I love it! Big thanks to @upsert ! Would be great if it was rolled into HA proper.

[upsert]

I am working on a proper component. I have taken the first steps and made a library for the casetify bits and started on an HA branch.

[cajuncoding]

That's Great News!

[darkmaestro3e8]

This is awesome. Thanks @upsert, I appreciate your hard work and development of the Lutron component. I've been using it flawlessly for months now and it's definitely the most reliable component I have in HA. I had the normal Caseta component break on me twice, so I bought the Pro hub and switched to your custom component and have never looked back. I'm excited to see this become a fully implemented component in HA.

[SolidOceanTrust]

Came here to say this as well. Great work and thank you very much for this awesome component

[bigkraig]

@raerae1616 I've been thinking of how to leverage that in a way that makes it compatible and simplifies the usage of pico remotes with this component.

I'm guessing there is value to leaving the pico sensor's as they are. Perhaps the best thing to do is to create a pico remote entity that mimics the functionality of the plant component. You'd configure a 'pico_remote' with the sensors from this component and could set up press/long press actions. That way you could have a pico remote sensor and a pico_remote rather than a pico remote sensor + 5 automations & long press scripts.

[cajuncoding]

@bigkraig yes I completely agree... encapsulating the functionality would eliminate custom scripting and greatly simplify things while at the same time making it more powerful and reliable (as my script relies on limited capability of synchronous timer blocking). I never looked at the plant component, but as you said there is definitely value in having the base/raw sensor as well as the abstracted remote component.

Love the idea!

[Syco54645]

I am working on a proper component. I have taken the first steps and made a library for the casetify bits and started on an HA branch.

This is fantastic news. I have not updated my HASS install for almost a year as I do not feel like messing with the docker. Once this is official I will surely update.

[nphil]

Any movement on this? Your integration works better than the default Homeassistant integration (which is also clunky to set up) for me!

[shenxn]

This is a really great integration and I've been using it for month. Since there is no news for more than a year, I'm not sure if @upsert is still working on this. There is a lot of work to do to make it an official HA component. I have some free time these days and I'm willing to help with that. I'll start by figuring out what need to be done.

[upsert]

I still have a prototype, but have not found much motivation to work on it. The custom component is pretty stable and I try to keep it that way.

Last time I worked on my prototype I was hung up on the Area Registry. It would be helpful if I could find an example of an integration that creates areas in the Area Registry and assigns them to devices. I have been mostly guessing how it should work based on the source code for HA.

[JonGilmore]

It would be helpful if I could find an example of an integration that creates areas in the Area Registry and assigns them to devices. I have been mostly guessing how it should work based on the source code for HA.

This should help you out if you're still interested in this. cdheiser is working on overhauling the lutron component to do this same thing: https://github.com/home-assistant/core/pull/36902

[upsert]

At this point the built-in integration for Lutron Caséta includes more features including Telnet and does not need any features from this custom component. A merge to the HA code base will not be attempted.