Lutron Caseta Interface

[scottocs (Scott)]

I am having a problem integrating this into HassIO.

I copied the 5 files to:

/config/custom_components/caseta/__init__.py
/config/custom_components/caseta/casetify.py
/config/custom_components/light/caseta.py
/config/custom_components/sensor/caseta.py
/config/custom_components/switch/caseta.py

and the json file to:
/config/caseta_192.168.1.5.json

But then I get this error in HASS:

2017-10-26 13:07:58 ERROR (MainThread) [homeassistant.setup] Error during setup of component caseta
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/homeassistant/setup.py", line 194, in _async_setup_component
    component.setup, hass, processed_config)
  File "/usr/lib/python3.6/asyncio/futures.py", line 331, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.6/asyncio/tasks.py", line 244, in _wakeup
    future.result()
  File "/usr/lib/python3.6/asyncio/futures.py", line 244, in result
    raise self._exception
  File "/usr/lib/python3.6/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/caseta/__init__.py", line 46, in setup
    integration = json.load(conf_file)
  File "/usr/lib/python3.6/json/__init__.py", line 299, in load
    parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.6/json/decoder.py", line 357, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

[a_ndy]

I’m running HASS on docker, but used this the other day and worked for me:

Lutron Caseta - invalid config

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 Hope it helps someone else. Has anyone tried th…

[scottocs (Scott)]

I tried your version, but I get the same error. I don’t know why. I’m using HASS.io so I hope that’s not the issue.

[Syco54645 (Frank Claycomb)]

Now that the official Caseta component was broken by Lutron updating the hubs what is the plan moving forward? We should at least work on getting @jhn’s implementation for the pro hub into here.

Perhaps we can call the components caseta_leap and caseta_pro. That way if we do ever get the key people with the pro hub are free to choose which they want to use (but who in their right mind would want to lose functionality).

It is always risky integrating with a system how we did with Caseta, documented APIs are much safer as IF they change it should be a simple path forward to fix it. However I doubt they would implement a breaking change to the API without at least giving warning first.

[Radushka]

I’ve been using @jhn’s (thank you!) implementation for months with zero issues in an environment with quite a few caseta dimmers. Even using pico remotes as triggers for non-lutron devices. So for whatever it’s worth - I would welcome an official component for the pro hub.

[upsert]

I’ve setup a custom component for the PRO model if you want to try it out.

Introduced on this thread:

Lutron Caseta - invalid config

I have created a custom component lutron_caseta_pro based on jhanssen’s casetify code and other re-organization work in this thread. I’ve included: Scene support Shade support (covers in Home Assistant) Re-organized the configuration to list an array of IDs for switches and covers instead of individually configuring each device Added area names, as suggested above by @bjj Added Configurator support to paste in the Integration Report in the frontend Code cleanup and re-organization, linting e…

[MACscr]

Shouldnt the switches work with a standard 433mhz receiver (on an arduino or pi) and be able to be integrated without the bridge?

[upsert]

Nope. Lutron uses a proprietary protocol called ClearConnect. Here is the white paper if you are interested.

[marthocoo (Mark Coombes)]

Can someone give me a quick rundown of the differences in functionality between the non-pro and pro versions of the Caseta hub? Thanks!

[a_ndy]

Pico remotes show up as sensors on the Pro version using Upsert’s custom component. Can then use that to activate scenes or other stuff. I think its worth the price difference.

[upsert]

Another small difference is transition support for dimming or fading the lights. You can specify the fade or ramp time in seconds when changing a light level in Home Assistant.

The PRO hub is a little harder to find and more expensive, but I think worth it for the additional features enabled by its Telnet interface. The HA component for the non-PRO hub is also using an unofficial reverse engineered protocol that is a bit more likely to be broken by firmware updates when compared to the Telnet interface on the PRO bridge that is also used by third party integration partners.

[silfa718]

How/where do you specify the fade or ramp up time? When you call the turn on/off action?

[a_ndy]

You can specify in automations, scripts, scenes… using the transition service data variable under the Lights component.

[upsert]

Here is a demo of an automation to turn off a light with an 8 second fade to black when pressing button 1 on a 4-button pico (see the button map for the numbers):

- alias: Light Fade Demo
  id: '1516240051730'
  action:
  - data:
      entity_id: light.living_room_right_lamp
      transition: 8
    service: light.turn_off
  condition: []
  trigger:
  - entity_id: sensor.living_room_scene_pico
    platform: state
    to: '1'

This is using the custom component on a PRO bridge, otherwise the sensor will not exist and it wouldn’t work.

[silfa718]

Thanks for the detailed answer.

[marthocoo (Mark Coombes)]

My Pro Bridge arrived today… first thought: wow, that is incredibly small. Second thought… wow, that is incredibly easy to set up! Particularly copying the integration report and pasting it into the frontend. Thanks @upsert!

[2carlos (Carlos)]

I’m curious about latency/response times when controlling non-caseta devices (i.e. using a pico to control a ge dimmer/switch)

for those that have this configuration, is it perceptibly about as fast as controlling the caseta wireless dimmers? surely it’s at least faster than hacking an amazon dash button?

[marthocoo (Mark Coombes)]

My experience with the Picos is that their button presses are registered extremely quickly in HA (it feels immediate). So I’d imagine if you’re using them to trigger an automation it would fire instantly.

[raerae1616 (cajuncoding)]

I’ve linked a Pico to my Denon AVR for volume control on the wall!

I found it very responsive! You can see the sensor value update in HASS pretty quickly. I was very impressed with the responsiveness!

[2carlos (Carlos)]

@marthocoo

My experience with the Picos is that their button presses are registered extremely quickly in HA (it feels immediate). So I’d imagine if you’re using them to trigger an automation it would fire instantly.

@raerae1616

I’ve linked a Pico to my Denon AVR for volume control on the wall!

I found it very responsive! You can see the sensor value update in HASS pretty quickly. I was very impressed with the responsiveness!

Nice, Thanks for feedback, Just ordered a Pro Bridge kit with dimmer and pico remote. probably just going to use the pico remote as a nightstand control for my bedroom lights which are controlled by a ge z-wave switch. My wife and I occasionally wake each other up telling alexa to control the lights.

I wish someone made a simple z-wave remote that looks like the pico or even hue dimmer remotes. But I like the look of lutron dimmers better than ge anyways, so I guess this works out.