Lutron Caseta - invalid config

[a_ndy]

I’d be interested in that write up too!

My Pro hub should be here in a few days.

[wixoff]

It’s not so much a writeup, but I’ll tell you this: I couldn’t get it to work in custom_components either. So I just copy the necessary files from the github repository (the caseta-0.40 branch specifically):

jhanssen/home-assistant

… to the appropriate directories in my home-assistant installation. On my system, which uses Docker, it looks like this:

docker exec -t home-assistant mkdir /usr/src/app/homeassistant/components/caseta
docker cp /data/hd/home-assistant/casetapro/__init__.py home-assistant:/usr/src/app/homeassistant/components/caseta/__init__.py
docker cp /data/hd/home-assistant/casetapro/casetify.py home-assistant:/usr/src/app/homeassistant/components/caseta/casetify.py
docker cp /data/hd/home-assistant/casetapro/light-caseta.py home-assistant:/usr/src/app/homeassistant/components/light/caseta.py
docker cp /data/hd/home-assistant/casetapro/sensor-caseta.py home-assistant:/usr/src/app/homeassistant/components/sensor/caseta.py
docker cp /data/hd/home-assistant/casetapro/switch-caseta.py home-assistant:/usr/src/app/homeassistant/components/switch/caseta.py

You only need those five files, and I just keep them on my local system in the casetapro directory and use a script to inject them into my docker container every time I upgrade Hass. There’s no need to edit any of the files; just copying them over is enough.

Then set up your configuration.yaml per this component’s requirements. In my case again:

caseta:
  bridges:
    - host: 192.168.x.y
      devices:
        - id: 2
          type: switch
        - id: 3
          type: switch
        - id: 4
          type: switch
        - id: 5
          type: switch

You have to manually identify your on/off switches as such or everything will be treated as as a dimmer.

Finally, you need to export an integration report from the iOS app (or equivalent) and put it in your home-assistant configuration directory as caseta_192.168.x.y.json

Then off you go!

I don’t use hass.io so I don’t know what the process would be there, and I also wonder if this component will stop working at some point. It doesn’t seem to be under development currently.

But it does work perfectly now, and it does make Pico remotes visible as sensors that can be used for any purpose, so big thumbs up from me.

[bluesoc]

Thanks so much. I’ll see if I can get it working in hass.io and will post if I do.

[GervaisdeM]

@gurumitts

I found the Key in on another git hub project. I am really sorry that this happened. I liked the LEAP ssh integration as it did not require any additional files and worked with both pro and non-pro bridges.

I hope we can find an acceptable way forward.

No need to apologize. It’s not your doing…

[GervaisdeM]

I hate not being able to control my lights with HA anymore, but I really only have one automation that used Caseta. It turned off my kitchen lights when i went to bed at night…

My interim solution is as follows:

1. Create a Webhooks (formerly Maker) Applet on IFTTT.

• If → Webhooks
• then Caseta activate scene
• Looks like this: If maker Event “kitchen_lights_off”, then activate scene called Kitchen Lights Off

2. Setup IFTTT in HA
3. Update automation action:

action:
  - service: ifttt.trigger
    data: {"event":"kitchen_lights_off"}

My lights will now turn off automatically again…

Anyone else come up with anything? Also… Anyone know how IFTTT can talk to Caseta non-pro bridge? Is this something we can setup in HA?

[GervaisdeM]

Caseta non-pro workaround

Due to the Lutron Caseta non-pro hub no longer working, I made a workaround configuration to control my lights that relies heavily on IFTTT. It’s a hassle because you have to make two IFTTT applets for every light switch you have (one for on and one for off). Here is how I did it: Setup IFTTT Make a bunch of This=Webhook / That=Caseta. The names and friendly names are important. Example: [04 AM] Create some input_booleans in configuration.yaml: input_boolean: bathroom: name: bathroo…

[adamfox]

You’ve got this working on 0.53.1 or are you running a previous version of home-assistant prior to the “official” Caseta integration? I’d previously been using his branch before the proper integration but can’t get this to work on 0.53.1.

[wixoff]

Strange, because I’m currently on 0.54 and I have been using @jhn’s Caseta implementation since the early 0.4X series (not sure exactly) with no problems now or at any point in between.

[adamfox]

To anyone else looking, disregard! Was an error on my part. This is still working just fine. Thanks for the reply.

[bluesoc]

I’m still trying to get @jhn implementation to work without luck. I switched from hass.io to all in one (and tried hassbian too). I’m able to see all my lights and can turn them on once. After that I lose all control over them. Any ideas what could be wrong? Thanks for any help.

[adamfox]

where are you downloading these files to under hass.io? just set that up as a docker container to test and those files are removed each time i reload.

[bluesoc]

I gave up on hass.io. I tried putting them in custom components but that didn’t work.

[scottocs (Scott)]

I tried this in .55 on HassIO, but it’s giving me errors saying this.

[bluesoc]

Here’s the error I’m getting in hassbian and the AIO

ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform caseta
Traceback (most recent call last):
File “/srv/homeassistant/homeassistant_venv/lib/python3.5/site-packages/homeassistant/helpers/entity_component.py”, line 164, in _async_setup_platform
SLOW_SETUP_MAX_WAIT, loop=self.hass.loop)
File “/usr/lib/python3.5/asyncio/tasks.py”, line 400, in wait_for
return fut.result()
File “/usr/lib/python3.5/asyncio/futures.py”, line 293, in result
raise self._exception
File “/usr/lib/python3.5/asyncio/tasks.py”, line 239, in _step
result = coro.send(None)
File “/srv/homeassistant/homeassistant_venv/lib/python3.5/site-packages/homeassistant/components/sensor/caseta.py”, line 92, in async_setup_platform
yield from async_add_devices(devices)
TypeError: ‘NoneType’ object is not iterable

[370gt]

Hope the the support for Lutron Pro Hub comes soon!!

[gurase (Grace Mann)]

Thank you for the instructions! Just got my pro hub today, and this worked perfectly on 0.55.1. I finally have my Lutron lights back!

[benjimatt (Matthew Henry Marshall)]

my pro hub comes tomorrow. I cant wait. My main reason is using the remotes for different functions

[benjimatt (Matthew Henry Marshall)]

All done. easy enough.

bridges:
  - host: 192.168.1.37
    devices:
      - id: 2
        type: dimmer
      - id: 3
        type: switch
      - id: 4
        type: remote

[ksheumaker (Kyle)]

I just got the Pro bridge tonight to replace my non-pro, since I’m all-in on hass.io I spent some time to figure it out and make it work. Basically you need to make a few changes to the light/caseta.py sensor/caseta.py and switch/caseta.py file

Change this line:

from homeassistant.components import caseta

to:

from custom_components import caseta

and then it should work.

I repackaged the files with my changes at put them in this git repo

ksheumaker/ha-caseta-pro

Hope it helps someone else. Has anyone tried this version with serena shades?

[benjimatt (Matthew Henry Marshall)]

Oh nice!!! I currently have them in the regular components section. I’ll have to try that out