Open swamplynx opened 1 year ago
In the designer, if you go to the Menu Bar - Reports > Integration Can you export that as a PDF using the export button at the top right?
I've partly mis-understood. I thought you mean the entities were literally showing up with "lutron_home" and "lutron_area" in the names. You just mean that its prefixing all your entities with "maple_tree_manor".
On my system, by Base areas "Basement, Upstairs and Main Floor" have a parent_id of null (None), and in your diagnostic txt file, each of your areas "main floor, upstairs, basement" etc are listing area 3 "Maple Tree manor" as the parent.
"areas": {
"3": {
"id": "3",
"name": "662 Hillsdale",
"parent_id": null
},
"91": {
"id": "91",
"name": "Equipment Room",
"parent_id": "898"
},
"822": {
"id": "822",
"name": "Bedroom",
"parent_id": "898"
},
"898": {
"id": "898",
"name": "Basement",
"parent_id": null
},
"910": {
"id": "910",
"name": "Rec Room",
"parent_id": "898"
},
"1024": {
"id": "1024",
"name": "Main Floor",
"parent_id": null
},
"1036": {
"id": "1036",
"name": "Family Room",
"parent_id": "1024"
},
"1205": {
"id": "1205",
"name": "Hallway",
"parent_id": "1024"
}
}
Time to do some digging
Interesting. The main difference I see between our two configs is I don't have any "sub-areas" i.e. children of child areas, whereas you do. I wonder if the way Lutron does it, is a child area only has a parent one level up, which in my case is the home/project.
I'll test that.. back shortly
Bizarre:
"2700": {
"id": "2700",
"name": "Test Area",
"parent_id": "3"
},
"2770": {
"id": "2770",
"name": "tree1",
"parent_id": null
},
"2794": {
"id": "2794",
"name": "tree3",
"parent_id": "2770"
}
You are correct, it only shows 1 level of parent child relationship. "Test Area" linked to the Project Level "Tree 1" has no parent id assigned "Tree 2" skipped completely "Tree 3" has a parent of "Tree 1"
Thanks!! I'll do some work on this problem this evening.
Not sure if this would be valid in every case since Lutron's logic seems in consistent, but one potential solution would be to skip the prefix if the area id = 3, which seems to be what they used at least in both our deployments. No idea if that is consistent though.
Try using this for your custom_component: https://github.com/danaues/lutron_caseta
Or, just edit your /config/custom_component/lutron_caseta/init.py file: Line 287 change:
if parent_area is not None:
to this:
if parent_area is not None and parent_area != "3":
does it fix the problem?
Not sure if this would be valid in every case since Lutron's logic seems in consistent, but one potential solution would be to skip the prefix if the area id = 3, which seems to be what they used at least in both our deployments. No idea if that is consistent though.
Exactly what I was thinking. I'll have to set a constant like BASE_PROJECT_AREA = 3 , or something and add a condition for that in the final fix.
@cbw for your HWQSX system is the base project area (root) set to area_id 3?
I'll test that. I already renamed everything so I'll need to create a new dummy device.
That did the trick. Updated the code and restarted HA core. Added a Pico in Designer. It no longer appends the house/project name, just the Lutron area name and it also automatically match the HA area name of the same name when the new entity was discovered.
I"ve created PR's in pylutron_caseta and Home Assistant to address this issue.
Turns out, the strange behaviour was due to the way we are discovering parent areas within pylutron-caseta.
Turns out, Caseta uses area 3 all the time, and it isn't the root area.
The updates re-establish the parent/child relationship for all areas right up to the root, regardless of whether or not they contain devices.
Then we just ignore the top level area (root for Caseta, Home/Project Name for HWQSX/RA3), and we're good!
@danaues yep, the root area on my QSX system (result of /area/rootarea
) is 3.
When importing new devices, the HA integration prefixes the Lutron Home / Project Name on every device. config_entry-lutron_caseta-7b8e32d6f44b9ea9c4d9f0311b96d37c.json.txt