Lutron Caseta Interface

[upsert]

I’m not sure which sqlite you are looking at, but apart from the new RA2 Select Picos I mentioned above, the only other 4-button Picos for the Smart Bridge are listed as:

• PJ2-4B-GXX-X21
• PJ2-4B-GXX-X01
• PJ2-4B-GXX-X31

And I think it is not a matter of the messages on the telnet interface as I think it won’t pair with the bridge at all. If it can’t be added to the bridge, it won’t be visible anywhere in the system on the telnet interface or otherwise.

This question has also been raised before in the Lutron forums.

The ultimate test would be to buy one from somewhere with a good return policy and try it out. I am skeptical it will pair, but would be interested to hear the results if you try it.

[jsb]

Did you check the database on the bridge itself, or is this from documentation?

BTW I sent you a PM on AVS Forum.

[upsert]

It’s from the bridge firmware. Version 05.02.04f000, 19 October 2017.

If you ever want to know your firmware version, run Bonjour Browser and look for the entry for Lutron Status.

[grahamr]

Bonjour Browser is a wicked resource - I never thought to check for caseta in there - I have my device blocked down to FW 5.02.04f000 so it shouldn’t update without me knowing now.

[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!