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”.
@GaryH, thanks and yes I knew that and that is exactly why I posted … I was wondering if the phantom entries could be leading to issues … not really over the Group 17,18, 20 thing BUT these also exist in Group 0 and 1. As you can see below, tghe device 1E.48.2E (which was likely the old PLM) has no Device Name and yet entries in Group 0 and still in use. I have also been marking several others as not in use the way you have without issue but wanted to be sure that the Group 0,1 and possibly 5,6,7,8 for my 6 button devices should also be handled the same way.
It would certainly clean things up a bit considering it is like 70 devices … so 0,1 and group entries pointing to a non-existent old PLM is a boatload of garbage entries.
For example, this one device has “phantom” entries for Group 0 (twice), as well as 3,4,5,6.
That is six entries for one device. In analyzing “insteon_devices.json” I get 182 entries that point at that non-existent device that have not yet been marked as not in_use whose group number is greater than 10: Using “jq” playground and doing this:
{ groups: [ .[0].“address” as $modemaddress | .[] | .“address” as $device_address | select(.“address” != $modemaddress) | .aldb | .[] | .target=“1e482e”| { group: .“group”, in_use: .“in_use”, device_address: $device_address, target: .“target”, controller: .“controller”, brightness: .“data1”, ramp_rate: .“data2”, button: .“data3”} ] | sort_by(.group) | map(select(.“group” > 10)) }
If I change that to remove the group number restriction, I get well over 500. That is over 500 phantom entries.
A thought for confirmation by others that likely know more:
Any controller type device will send messages onto the mesh to responders in its ALDB when activated (i.e. when a ToggleLink switch is pushed). These messages will go to real and phantom devices, meaning lots of phantom devices will cause lots of needless mesh traffic.
This may not matter, or it could potentially slow things down. Perhaps a good reason to deactivate the phantom links.
Who knows? Not sure but they are busy keeping us jumping through hoops because if you look at your modem, it is back online. Who knows what that means yet?
Not sure what’s going on… Insteon Servers are back… I have a green light on my hub.
I am able to open the Insteon app and login.
If you needed to edit an Insteon Scene or Schedule, now maybe your chance. I am in Central US and its 9am Central Time.
If you are a Hub user and have features of a device that are not working correclty the app back online represents an opportunity to capture how the device works under the hood. Please see my post here:
June 7 2022 - Insteon Servers Back Online - Hardware - Home Assistant Community (home-assistant.io)
Most likely the ISY uses these groups for something. If that is the case, it would be specific to how the ISY developers decided to number a scene. Let me know what the device type is (CAT and SUBCAT). Marking them as in_use: false in the ALDB is sufficient but also know they pose no harm either so leaving them alone is fine too.
I’m taking advantage of the revival of the Insteon servers by removing the hub schedules and making device changes such as ramp times and default led brightness settings. I’m also setting up some new mini-remote scenes too. But I’m still using HA to manage all automation and controls from Alexa.
@rlfromm If the config such as ramp rates and LED brightness are not properly supported in HA Insteon Panel, please follow the directions in this post:
This way I can update the code for that specific device to enable that capability going forward. We don’t know when the Insteon app will go down again.
This is true for controller records, but not for responder records. When a controller’s state is changed manually (eg. turn a switch on / off), the device will send a broadcast message that the state has changed. It will then send a clean up message to all target devices that it sees as responders (i.e. it has a controller record for) in order to ensure each responder saw the state change. However, the impact is probably minimal anyway. If you have an old modem (PLM or Hub) that you removed from the network these records are dormant in your devices and do not harm the performance of the device or create excess traffic. I prefer to keep my ALDB’s clean of unused records because it makes it easier for me to keep track of the linkages between devices. But then again, I have 4 active modems for development that are linked to most of my devices so…
