Actually scenes are totally possible with the regular hub. My first attempt at this on ST was with a standard hub and I was able to get scenes working. I should say that you could trigger them…I am not 100% certain if the status would work, but it very well may. What I mean is if you trigger a scene to say turn a light to 70% but then change it manually to 100%, I am not certain if either hub reports that the scene is now “off”. I will have to look at that. I am getting my feet wet and hopefully can jump in very soon.
Welcome @njschwartz ! I too am poking around in pylutron and contributing a bit of code. Hopefully working my way up to contribute to Home Assistant.
For the Pro bridge support using Telnet, one thing that needs some thought is a good way to reconcile the LIP server integration IDs with the device IDs from the LEAP interface. Unfortunately they are not the same and I discovered this after removing and adding a device from my bridge. It looks like in your code you treated them as the same?
I have not discovered any method in the LEAP server that lists both the device ID and the LIP Integration ID at the same time. ReadRequest on /device will get you device IDs and ReadRequest on /server/2/id will get you LIP server integration IDs, but not both. The only crossover is the name, so I think the name must be used to correlate the device IDs. From what I can tell the app forces you to use different names for every device, so I think the solution will work. I would be interested to know if you encountered this issue and if so, how you tackled it.
Hey @upsert that is great to hear. I am sure between us all we can get this to be an even greater integration!
So in my original attempt using python you are right that the LEAP and LIP ID’s were sometimes different which caused problems for some people. I am pretty certain they are actually supposed to be the same and for whatever reason they get out of sync. I need to go back and look, but if I remember correctly, the LEAP “zone” is what really mattered. I would think we could easily save both LEAP and LIP Id’s into the device object anyway and go from there. I need to play around with it because I honestly cannot remember what ID was what between the two servers. 
Scenes are already supported in Home Assistant so I assume @benjimatt is talking about just the status of a scene. This is like the LED lights on the scene buttons on a RadioRA 2 keypad. The LED next to the button illuminates if every device controlled by the scene is at the preset level defined in the scene and the LED goes off if any level is different.
In theory it is completely possible on both non-PRO and PRO hubs as every scene has a preset assignment and one could examine every zone level in the preset and compare it to the current level. That being said I’m not sure how efficient it would be to check up to 100 scenes every single time a level changes on any zone. And you would need to make a binary sensor in Home Assistant for every scene so it could have an on/off state.
1 Like
Yea I think you are right on that. There must be some sort of notification somewhere that a scene is still active I am just not sure how Lutron does it. If we can find it that would be the simplest way, but if not, like you said adding it in is still certainly possible but far more of a pain.
The new RA2 Select product line looks interesting.
http://www.lutron.com/en-US/Products/Pages/WholeHomeSystems/RA2Select/Overview.aspx
http://www.lutron.com/en-US/Company-Info/Pages/News/Media-PressCenter/PressReleases/PressReleaseDetail.aspx?prid=742
For anyone seeking RA2 style dimmers, a fan control and a 100 device limit, the RA2 Select looks to fit the bill. The hub hardware looks identical to the Smart Bridge but in black plastic. I expect the differences are only in firmware and likely means it will be easy to integrate with Home Assistant.
They also promise a new Caseta app update. Being able to organize by rooms would be nice. Update: Caseta & RA2 Select app 5.0.1 is now available.
Any word if RA2 Select will be supported by the already existing Homeassistant integrations? Looking at RA2 Select for a new build but want to ensure it will work with HASS.
1 Like
Hi,
Same question for RA2 Select - will it support LEAP & LIP integration as is?
On another note, I’m trying to figure out if the PJ2-4B-GWH-L41 (4-button Pico, 4 group toggle) will pair to the Smart Bridge Pro. Lutron’s official answer is that it won’t work since it is intended for QS systems, but I thought all PJ2-4B Picos reacted the same and only the key labeling was different. Anyone try this or have insider info on how these actually operate?
All I want is to pair that specific remote model so I can monitor the keypresses using LIP and define automations based on that; I do not wish to use it as an actual light control.
I have a couple 4-button Picos, the ones with on, off, up, and down buttons. They work fine.
So what I have are not 4-group toggles, but I honestly would be surprised if the hardware under the button graphics was any different. And the Smart Bridge Pro integration (the unofficial one that still works, from @jhn) doesn’t really care what the labels on the remotes are; it just sets up sensors that have different values for different button presses.
No promises, but I suspect it will work.
I would avoid PJ2-4B-GWH-L41 as it is the only Pico specifically marked as incompatible with Caseta and RadioRA 2. There is a database on the Caseta hub that controls which hardware is accepted, so it is a controlled list of device models.
I have two 4-button scene controllers PJ2-4B-GWH-L31 and they pair fine with the Caseta hub. They have a light bulb icon instead of numbers and by default, function like four favorite buttons plus on off button. You can even press and hold to program the levels after you add them to a set of lights in the app. With appropriate integration in Home Assistant (currently an unofficial one as mentioned), they can function as triggers for automations. Optionally you can remove any lights from the Pico in the Lutron app and then it would solely be a home automation trigger.
RA2 Select should be supported by the same integrations as Caseta Bridge PRO and have both LIP and LEAP interfaces. I know the Lutron app has a bunch of assets in it for contractor info and other pages specific to RA2 Select so I think the differences are all in software. The proof will be when someone acquires a unit and tests it.
I forgot to mention RA2 Select will have three new 4-button scene controllers and two new 2-button scene controllers. They are:
- PJ2-4B-GWH-P01 Living Room (Bright/Entertain/Movie/Off)
- PJ2-4B-GWH-P02 Kitchen (Bright/Cooking/Dining/Off)
- PJ2-4B-GWH-P03 Any room relax (Bright/Entertain/Relax/Off)
- PJ2-2B-GWH-P01 Home/Away (Home/Away)
- PJ2-2B-GWH-P02 Bedside (Alert/Goodnight)
These are all available from the Lutron dealer that is supposed to be installing RA2 Select and will have pre-defined engravings. They should all be supported by Home Assistant as they use the existing LEAP device names for Pico remotes.
You can find the Picos listed on some distributor pages like here and here.
Another thing that may not be supported out of the gate is the fan speed controller RRD-2ANF. It operates like a dimmer on the LIP server interface (0%=off, 1-25%=Low etc), but it will have a different LEAP device name and should be integrated in Home Assistant as a fan component (wow, terrible component docs!). So some more development required to support that.
2 Likes
Regarding the PJ2-4B-GWH-L41, that’s the thing - I was under the impression that the Pico only reported itself as a PJ2-4B and the rest of the letters were only cosmetic (colour & key labels). Looking at the DeviceInfo & SupportedDevices tables in the sqlite database, I see definitions of Picos but not specific models.
I’m pretty sure all 4B Picos report the same keypresses: Components 8 through 11 for keys 1 to 4. So I should get a ~DEVICE message still… right?
upsert, are you seeing a specific device type in the whitelist (assuming you’ve checked it out)?
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.
Did you check the database on the bridge itself, or is this from documentation?
BTW I sent you a PM on AVS Forum.
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.
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.
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)I’m running HASS on docker, but used this the other day and worked for me:
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.
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.
2 Likes