Excited to try your code, were you able to get the detailed guide completed?
@kevin.aubertin ā¦ as with all testing I hit a snag and it took some time to unravel. After re-reading @teharris1 posts on the structure in the ALDB and also through testing with another user, it is clear that my ALDB has different (likely ignored) entries for data1, data2, data3 for the modemās ALDB. Why? I have no idea, it is merely what mine has I guess. Mine has values where @teharris1 example shows these as 0,0,0 for the modem. In mine, it was 100% match that my data1 was the button in the target device and based on that incorrect assumption I built the code. In working with another user to walk through, their results were not right which led me to find this issue.
I have now had to rewrite that to go after specific device ALDB and the data3 attribute to figure out which button/outlet is the target. So I am probably a few days out to make it solid.
1 Like
So where I am now is a sensor that restructures the data like the screen below. As you can see, a JSON of Insteon groups with responders and controllers. These have switches so I now have everything ā the group, all devices by address in the group, the button/outlet (for multi-button or multi-outlet devices)
This can be put into attribute of a template sensor to be used to at least see an easy visual of what is in a group and to test it.
Thanks for the update and time invested into this solution.
Is there a table/formula showing the mapping between ramp rate value and timing in the ALDB data field?
@teharris1 ā¦ I am still struggling with the example and wonder why I have things like this:
"7655": {
"memory": 7655,
"in_use": true,
"controller": true,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 30,
"target": "1fa8f1",
"data1": 1,
"data2": 42,
"data3": 66
},
Obviously that is a record in the hub ALDB. Why does it have data1, data2, data3?
This process has also helped me considerably in troubleshooting.
For instance, I would run insteon.scene_on for scene 21.
This scene had 14 devices,
All of them turn on. Great start>
But in Home Assistant, 8 of them showed state is on. 4 were off.
So digging into the control panel to the device(s) that were off for that group, everyone of them had data1 = 0. Setting this to 255 and writing to the device fixed it. I am now working through all of these.
It leads me to believe that the Insteon people ignored data1 as ā0ā and just assumed 255 if you said turn it āonā. There are so many other things in the JSON written out I do not get. WIsh I understood it better.
As I delve deeper into this I realize that this is NOT an āInsteon Control Panelā.
It is an āInsteon Configuration Panelā and @teharris1 should consider renaming it.
Yes you can āconfigureā what is in what groups and such ā¦ but in no way can you āControlā things ā¦ like turn scenes on/off or even see (without diving deep) what exactly is in a scene.
Don;t get me wrong. It is a greatly needed ā¦ BUT ā¦ it is only used to āconfigureā things, not ācontrolā things.
I agree since you can only configure Insteon device settingsā¦
my ALDB has different (likely ignored) entries for data1, data2, data3 for the modemās ALDB
Data 1, 2 and 3 in the modem have no impact. They are documentation only. Typically they are
Data1: device category
Data2: device subcategory
Data3: firmware version
They have no effect on the link or scene behavior.
There is an issue with loading the modem ALDB where the user interface looks like it does not load. It does in fact load but the UI never updates. Wait 2 minutes and refresh the browser. It will display. Working on a fix.
FYI, this same issue exists for all battery operated devices. However battery operated devices do not load until the device wakes up.
Iāve met with some limited success to get the micro on/off module 2443-222 to show properties. I am working on modifying pyinsteon to detect the module properly. I am now able to get it to read the properties, Iāve just got to check that it is right for this module. right now Iām testing from command line not from within HA.
in device_types/ ipdb.py, the line product(0x02, 0x2F, None, āMicro On/Offā, ā2443-222ā, SwitchedLightingControl) by default is set to not associate a handler, by adding _Micro at the last parameter and then a few modifications to export SwitchedLightingControl_Micro, the properties are read.
I see that SwitchedLightingControl_Micro is present in device_types/switched_lighting_control.py, but not exported and therefore not used (yet). I am guessing the code hasnāt been tested yet. similarly I suspect that the 2442-222 micro dimmer module will also not show properties due to Product(0x01, 0x35, None, āMicro Dimmerā, ā2442-222ā, DimmableLightingControl) in ipdb.py. however dimmable_lighting_control.py has no code for that micro module. i donāt currently have a micro dimmer installed to test but it will probably be close to the on/off module.
@teharris1 could you comment?
@teharris1 this is likely not the place to ask this but Iām not sure where else to post Insteon related issues. All of a sudden HA isnāt controlling any of my Insteon devices I see the following in my logs
2022-05-30 17:08:21 ERROR (MainThread) [pyinsteon.protocol.http_reader_writer] An client error occurred: Cannot connect to host 10.0.0.81:25105 ssl:default [Connect call failed (ā10.0.0.81ā, 25105)]
I just restarted the hub and I donāt see any recent errors in the logs, but still cannot control Insteon from HA? Is there a more detailed log that I can review/post?
And this just appeared
Logger: pyinsteon.protocol.http_reader_writer
Source: /usr/local/lib/python3.9/site-packages/pyinsteon/protocol/http_reader_writer.py:79
First occurred: 8:16:43 PM (1 occurrences)
Last logged: 8:16:43 PM
Client error: (<class āaiohttp.client_exceptions.ClientOSErrorā>) [Errno 104] Connection reset by peer
@kbrown01 Loved the idea of the group explorer! I tried to extract the bits of code from the various posts, but just canāt seem to get it fully working.
At one point I did have the Scene Devices populating, but for the life of me, I could not get the Insteon Group Explorer dropdown to show/populate. I used the Developer Tools-Template area to test the templates and they appeared to have data, but after multiple restarts it never all came together.
Are you any further along the way to posting the latest version of your configuration?
First read through this and try the latest. Then I am happy to help!
It is possible that the old version was not updating because the state was just fixed to "OKā. Now it grabs {{ now() }} as the state to detect state changes.
Another little helper I have set up for now is a sensor that is a map of friendly Insteon group names to their Insteon group number. In a template sensor I have:
# Sensor for group names
- name: insteon_group_names
state: "{{ 'OK' }}"
attributes:
Arrival: 21
Kitchen: 26
Pergola: 28
Backyard: 30
Deck: 31
Panic: 39
Steps: 51
Christmas: 53
Couch: 54
Dining: 55
This allows me to select the group number with a template:
{{ state_attr('sensor.insteon_group_names','Arrival') }}
Which returns the number ā21ā in my example. This I use in insteon_scene_on so I can more easily understand what I am turning on.
I think this is the right place to ask this, but for changing keypad LED brightness (preferably based on Sun sensor) can we do that with just the entity now? I see where i can change in the config panel but I believe i have to download it to the device everytime i change it? How would (can we) use that in an automation?
Question for @teharris1 or anyone else that may want to field it ā¦ one observation I have made is that I have many, many entries in āinsteon_devices.jsonā and the Insteon Control panel that reference three specific groups ā group 17, 18 and 20 (many also exist in group 0 and group 1).
In looking at these entries in the control panel, I note that the āTarget Device Nameā is blank and the Target Address is to a device that does not exist in my network.
Now, my assumption is that these entries were entries from long ago when i had a PLM and ISY setup and I will bet that the target address is that PLM. I assume these things got ported over to my hub when I added a hub and were never āremovedā nor marked as āin_useā false.
Do you think that is the case?
I would note that I have worked with two other people who had similar setups and they also have almost the same thing ā and the groups seem to always be 17 and 18 and 20.
I also have many phantom entries in both my Hub ALDB and device ALDBs. Many point to an old hub that died and was replaced long ago.
Iāve been marking these as āNot in useā with no problems, which also removes them from the active ALDB view.
You probably know that groups 0 and 1 are used for basic communication to devices from the hub. You can lose device communication with the hub if marked ānot in useā.