Insteon configuration panel

[kbrown01]

@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.

[GaryH (Gary Harris)]

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.

[kbrown01]

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?

[jr1 (Jr)]

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.

[teharris1]

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)

[teharris1]

@kbrown01

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.

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.

[rlfromm (Robin Fromm)]

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.

[teharris1]

@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:

June 7 2022 - Insteon Servers Back Online

This is great news from my perspective. For those who have devices that do not work exactly as expected in HA this is a good time to identify how the Insteon app controls the device. Here is what to do: Put HA Insteon mesages into debug mode by adding the following to your configuration.yaml file: logger: default: warn logs: pyinsteon.messages: debug Use the Insteon app to trigger the device to perform whatever function is not working as expected in HA. This can include performing …

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.

[teharris1]

@GaryH

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.

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…

[kbrown01]

I may be seeing this wrong but I believe I have noticed something and I am not clear how to proceed.
I have many things I changed via the Insteon Control Panel but I opened my Insteon App on Android and some (if not all) of these were missing. I know at least two or three scenes I edited did not have (ion the cloud) devices I added in HA.

I may be wrong, but I assume that the GUI on Android reflects what is in the system online and not what is in the Hub … as in it did not push an update of changed things to the online Insteon cloud. I would not even know how to do that.

[rlfromm (Robin Fromm)]

Changing default LED brightness on light switches:

This doesn’t seem work with the plug-in. So I used the insteon app to change the LED brightness to 100%, then 25% and finally 5%. The target device address is 4B.94.F9 and the log segment follows.

////////

2022-06-09 14:55:44 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b92f3, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 14:55:44 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b92f3, target: 4b41f9, flags: 0x25, cmd1: 0x19, cmd2: 0x2e
2022-06-09 14:55:44 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b9336, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 14:55:44 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b9336, target: 4b41f9, flags: 0x25, cmd1: 0x19, cmd2: 0x2e
2022-06-09 14:55:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b93e5, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 14:55:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b93e5, target: 4b41f9, flags: 0x25, cmd1: 0x19, cmd2: 0x00
2022-06-09 14:56:04 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b94f9, flags: 0x1f, cmd1: 0x20, cmd2: 0x09, user_data: 00.00.00.00.00.00.00.00.00.00.00.00.00.d7, ack: 0x06
2022-06-09 14:56:04 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b94f9, target: 4b41f9, flags: 0x2f, cmd1: 0x20, cmd2: 0x09
2022-06-09 14:56:05 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b94f9, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.07.7f.00.00.00.00.00.00.00.00.00.00.4b, ack: 0x06
2022-06-09 14:56:05 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b94f9, target: 4b41f9, flags: 0x2f, cmd1: 0x2e, cmd2: 0x00
2022-06-09 14:56:06 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b94f9, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.00.00.00.00.00.00.00.00.00.00.00.00.d1, ack: 0x06
2022-06-09 14:56:06 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b94f9, target: 4b41f9, flags: 0x2f, cmd1: 0x2e, cmd2: 0x00
2022-06-09 14:56:06 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x51, address: 4b94f9, target: 4b41f9, flags: 0x11, cmd1: 0x2e, cmd2: 0x00, user_data: 01.01.00.0a.20.20.1f.05.7f.00.00.00.00.00
2022-06-09 14:56:14 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b94f9, flags: 0x1f, cmd1: 0x20, cmd2: 0x09, user_data: 00.00.00.00.00.00.00.00.00.00.00.00.00.d7, ack: 0x06
2022-06-09 14:56:14 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b94f9, target: 4b41f9, flags: 0x2f, cmd1: 0x20, cmd2: 0x09
2022-06-09 14:56:15 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b94f9, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.07.20.00.00.00.00.00.00.00.00.00.00.aa, ack: 0x06
2022-06-09 14:56:15 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b94f9, target: 4b41f9, flags: 0x2f, cmd1: 0x2e, cmd2: 0x00
2022-06-09 14:56:16 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b94f9, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.00.00.00.00.00.00.00.00.00.00.00.00.d1, ack: 0x06
2022-06-09 14:56:16 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b94f9, target: 4b41f9, flags: 0x2f, cmd1: 0x2e, cmd2: 0x00
2022-06-09 14:56:16 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x51, address: 4b94f9, target: 4b41f9, flags: 0x11, cmd1: 0x2e, cmd2: 0x00, user_data: 01.01.00.0a.20.20.1f.05.20.00.00.00.00.00
2022-06-09 14:56:25 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b94f9, flags: 0x1f, cmd1: 0x20, cmd2: 0x09, user_data: 00.00.00.00.00.00.00.00.00.00.00.00.00.d7, ack: 0x06
2022-06-09 14:56:25 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b94f9, target: 4b41f9, flags: 0x2f, cmd1: 0x20, cmd2: 0x09
2022-06-09 14:56:27 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4e6c5a, flags: 0x00, cmd1: 0x19, cmd2: 0x00, ack: 0x15
2022-06-09 14:56:27 DEBUG (MainThread) [pyinsteon.messages] TX: b’\x02bNlZ\x00\x19\x00’
2022-06-09 14:56:27 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4e6c5a, flags: 0x00, cmd1: 0x19, cmd2: 0x00, ack: 0x15
2022-06-09 14:56:27 DEBUG (MainThread) [pyinsteon.messages] TX: b’\x02bNlZ\x00\x19\x00’
2022-06-09 14:56:28 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4e6c5a, flags: 0x00, cmd1: 0x19, cmd2: 0x00, ack: 0x06
2022-06-09 14:56:28 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4e6c5a, target: 4b41f9, flags: 0x20, cmd1: 0x02, cmd2: 0x00
2022-06-09 14:56:37 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b95e1, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 14:56:37 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b95e1, target: 4b41f9, flags: 0x25, cmd1: 0x19, cmd2: 0x00
2022-06-09 14:56:37 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b86b3, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 14:56:37 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b86b3, target: 4b41f9, flags: 0x25, cmd1: 0x19, cmd2: 0x00
2022-06-09 14:56:38 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b92f3, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09

[teharris1]

@rlfromm

The target device address is 4B.94.F9 and the log segment follows.

Can you provide the device model number and the device category (which I am sure is 0x01) and the subcategory. If possible also provide the firmware version.

[teharris1]

@kbrown01

I know at least two or three scenes I edited did not have (ion the cloud) devices I added in HA.

The Hub stores Scenes in two ways. First, it adds entries into the Hub’s (and the corresponding device’s) ALDB. It also keeps a human readable value for the hub in a separate location inside either the Hub or the Insteon cloud. It is unclear where that sits but it is in the same location as where the room names and other house configuration is stored. SmartLabs did not expose this information in the local interface which is why it is not usable to HA.

[rlfromm (Robin Fromm)]

Yes device types:
2477D (0x01, 0x20) Firmware: 45 Engine Version: i2cs
2477S (0x02, 0x2a) Firmware: 45 Engine Version: i2cs

[kbrown01]

@teharris1 , perfect explanation and what I suspected. To make things look in app closer to what I would have expected, the first thing I did is to delete all my rooms and removed all devices from favorites in the App. The (totally useless) Insteon app just repeats devices that are in a group … many times.

I have an Insteon scene (number 30) that I created totally in Home Assistant. Now the Cloud app is online and of course if I open the Android Insteon Cloud app, I do not see any Insteon scene with that number … it has no name and was not created in the App.

Yet it is in “insteon_devices.json” and appears in my GUI (and yours) and it works, just it does not appear in the Android Insteon App which I now understand why it does not.

[rlfromm (Robin Fromm)]

Same issue seems to apply to wall plugs: Device Address 4C.69.5C

I changed LED brightness to 100%, 50% and then 5%

2663-222 (0x02, 0x39)
Firmware: 44 Engine Version: i2cs

/////////

2022-06-09 16:40:11 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b91af, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 16:40:11 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b91af, target: 4b41f9, flags: 0x25, cmd1: 0x19, cmd2: 0x00
2022-06-09 16:40:43 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4c695c, flags: 0x1f, cmd1: 0x20, cmd2: 0x09, user_data: 00.00.00.00.00.00.00.00.00.00.00.00.00.d7, ack: 0x06
2022-06-09 16:40:43 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4c695c, target: 4b41f9, flags: 0x2b, cmd1: 0x20, cmd2: 0x09
2022-06-09 16:40:44 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4c695c, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.07.7f.00.00.00.00.00.00.00.00.00.00.4b, ack: 0x06
2022-06-09 16:40:44 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4c695c, target: 4b41f9, flags: 0x2b, cmd1: 0x2e, cmd2: 0x00
2022-06-09 16:40:46 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4c695c, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.00.00.00.00.00.00.00.00.00.00.00.00.d1, ack: 0x06
2022-06-09 16:40:46 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4c695c, target: 4b41f9, flags: 0x2b, cmd1: 0x2e, cmd2: 0x00
2022-06-09 16:40:46 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x51, address: 4c695c, target: 4b41f9, flags: 0x11, cmd1: 0x2e, cmd2: 0x00, user_data: 01.01.0f.df.20.20.1c.fe.7f.00.00.00.74.14
2022-06-09 16:40:46 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x51, address: 4c695c, target: 4b41f9, flags: 0x12, cmd1: 0x2e, cmd2: 0x00, user_data: 01.01.0f.df.20.20.1c.fe.7f.00.00.00.74.14
2022-06-09 16:40:55 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4c695c, flags: 0x1f, cmd1: 0x20, cmd2: 0x09, user_data: 00.00.00.00.00.00.00.00.00.00.00.00.00.d7, ack: 0x06
2022-06-09 16:40:55 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4c695c, target: 4b41f9, flags: 0x2b, cmd1: 0x20, cmd2: 0x09
2022-06-09 16:40:56 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4c695c, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.07.40.00.00.00.00.00.00.00.00.00.00.8a, ack: 0x06
2022-06-09 16:40:56 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4c695c, target: 4b41f9, flags: 0x2b, cmd1: 0x2e, cmd2: 0x00
2022-06-09 16:41:08 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4c695c, flags: 0x1f, cmd1: 0x20, cmd2: 0x09, user_data: 00.00.00.00.00.00.00.00.00.00.00.00.00.d7, ack: 0x06
2022-06-09 16:41:08 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4c695c, target: 4b41f9, flags: 0x2b, cmd1: 0x20, cmd2: 0x09
2022-06-09 16:41:08 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4c695c, flags: 0x1f, cmd1: 0x2e, cmd2: 0x00, user_data: 01.07.06.00.00.00.00.00.00.00.00.00.00.c4, ack: 0x06
2022-06-09 16:41:08 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4c695c, target: 4b41f9, flags: 0x2b, cmd1: 0x2e, cmd2: 0x00
2022-06-09 16:41:11 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b95e1, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 16:41:11 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 4b95e1, target: 4b41f9, flags: 0x21, cmd1: 0x19, cmd2: 0x00
2022-06-09 16:41:12 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 4b86b3, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2022-06-09 16:

[teharris1]

FYI, looks like a handfull of bug fixes made it into 2022.6.7 which was released last night. Here are the bugs that were addressed:

• X10 All Lights On, All Lights Off and All Units Off commands
• Service “Insteon: Load all link database”
• Loading Insteon All Link Database for modems and battery-operated devices
• Fix spelling of Target in the ALDB table
• Display hidden devices in the Insteon Panel (i.e. when using “show as…”)
• IOLink Sensor displaying proper open/closed status

[teharris1]

A couple of new changes in 2022.7.4:

1. Fixes to the thermostat responding correctly to state changes such as “fan on” vs “fan auto”, set point changes, etc.
2. Added a device logging feature to debug a single device rather than placing the entire component into debug mode. To activate this debugging option put the following in your configuration.yaml file:

logger:
  default: <default for all modules>   # Typically this should be warn
  logs:
    pyinsteon.<device address>: debug    # For example if the address is 1A.2B.3C use pyinsteon.1a2b3c

This will log all messages for the device.

3. Fixed an issue with battery operated devices responding to requests.

My next release should introduce a few more devices. These are the ones I am working on currently:

1. Locks 2458A1 and 2863-222
2. Load controllers 2477SA1 and 2477SA2

I am also going to attempt to complete the work on the EzIO modules but I am not sure I have enough time to figure that one out before the 2022.8 release candidate need to be ready.

[dbrunt (Daniel)]

Great work!

[kevin.aubertin]

Great work on the last bunch of fixes, I am espically happy with the IOLink sensor showing proper state!

Kind of off topic question, all my Insteon devices have a friendly name and entity name but the entity ID still shows domain.device_type_address. Can I rename this to match my given name? not sure if this will break anything. Obviously if I’ve used the current entity ID name in some configuration I’ll have to update it to the new name which is fine but I’ve started building more custom dashboards and using the current entity ID isn’t very meaningful.