Open elreydetodo opened 2 years ago
Hi @elreydetodo, Sorry for the delayed response. Let me try some initial things to get QSX supported, then I can work with you on figuring out some debug ability in the logs with your supervised setup. I'm using the HASSIO, but I'm sure we can figure it out.
Chiming in here as well – would love to help work on QSX support, and have a test QSX processor set up to test against. I'm setting up another HASS instance to test with this afternoon.
Is the ra3
branch of danaues/pylutron-caseta
the best place to send PRs?
I have QSX set up with lots of different device types.... Palladiom Keypads, Seetouch hybrid, Ecosystem loads, DMX loads, closed contact loads, shades, wireless dimmers, picos and See touch QS wired keypads. Id be willing to help out if need be. Running HASS OS in a VM
Hey @lsdave,
@cbw has been working on adding QSX Support, and has an open PR here: https://github.com/gurumitts/pylutron-caseta/pull/106
@lsdave if you could run a few LEAP commands for me, that would be really helpful. All my testing has been with a test processor without any of the devices addressed (my system doesn't get installed for another couple months), so I can't tell which devices return serial numbers or not.
You can mask out your actual serial numbers if you don't want to share those, I just need to see what the structure of the returned data looks like when the devices are addressed.
Can send the commands if you're open to help. Thanks!
@lsdave if you could run a few LEAP commands for me, that would be really helpful. All my testing has been with a test processor without any of the devices addressed (my system doesn't get installed for another couple months), so I can't tell which devices return serial numbers or not.
You can mask out your actual serial numbers if you don't want to share those, I just need to see what the structure of the returned data looks like when the devices are addressed.
Can send the commands if you're open to help. Thanks!
@cbw Yeah, just let me know what commands you want me to run and i can do it tonight. I also have a couple of the appliance switches and wireless occupancy sensors.
@lsdave awesome, thank you! Here's a rundown of the process (apologize if this is either too low-level or too high-level, if any of this is unclear or you need any help, just give me a shout):
# grab my branch with QSX support
git clone git@github.com:cbw/pylutron-caseta.git
cd pylutron-caseta
# need Python version >= 3.8.0, so whatever version you have >= that should be ok, I tested on 3.9.12
pyenv local 3.9.12
# make a virtual environment so you don't clutter up your machine's Python setup
python3 -m venv pylutron
source pylutron/bin/activate
# install the module and its dependencies
pip3 install -e .
pip3 install click xdg zeroconf
# pair with the processor, you'll need to press the button on the processor to complete the pairing process
lap-pair [processor IP address]
# recommend installing "jq" for pretty'fying JSON output if you don't have it
# gather a list of all your zones (assumes jq is installed, remove that pipe if not)
leap -v [processor IP address]/area | jq > zones.json
# from that list, choose some area IDs that have a good selection of devices (keypad types, shades, etc.)
# gather this data for each zone ID:
leap -v [processor IP address]/area/[area ID] | jq >> area[areaID].json
leap -v [processor IP address]/area/[area ID]/associatedzone | jq >> area[areaID].json
leap -v [processor IP address]/area/804/associatedcontrolstation | jq >> area[areaID].json
# if you look at that last one, you'll see for each keypad there's a "Device" section that includes a link to the device ID. For each keypad, run:
leap -v [processor IP address]/device/[deviceID] | jq >> keypad[deviceID].json
leap -v [processor IP address]/device/[deviceID]/buttongroup/expanded | jq >> keypad[deviceID].json
# if you have any shade groups, if you could run this for one them as well:
leap -v [processor IP address]/zone/[shadegroup Zone ID] | jq >> shades.json
(edited - duh, there's no private messaging here. If you don't want to post the output publicly, you can message me at ceebeedub on Reddit or we can figure out some way that doesn't involve me posting my email address to be harvested by spambots ;) )
The ra3 branch appears to be nearing support for the QSX processor used by modern HomeWorks QS systems. Can we see about improving the branch to pick up whatever compatibility pieces are missing?
I have a QSX processor, so I can provide output samples, test code, and submit PRs as needed. I'll need some help getting pointers on debugging this, as I'm new to trying this stuff out with the library.
I tried running the
lap-pair
command from a venv on my local machine (I rebased the branch off gurumitts/pylutron-caseta). For some reason I'm getting a "No route to host" exception though, even though I'm on the same network as the QSX processor and I can ping it. I get the same error trying to pair with my RA2 Select bridge, so I think it may be some sort of venv sandbox issue, but I have no idea how to debug this.Ultimately I'm trying to use this in Home Assistant (Supervised, on a Pi) with the Lutron Caseta component. I've managed to build the branch locally, transfer it to my Pi, install it within the homeassistant docker container with pip, restarted. I get an unknown error when I try to pair with the processor. My concern is that I don't know where to get any of the log output from the attempt, and I'm not sure how to increase the log level. My system log has no indication of the attempt at all, and I don't see anything about turning the log level up in the Home Assistant UI config. I see a file on my Pi named
config.json
which seems to have a logging level indicated. Can I change that to "trace" and restart?