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…
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.
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
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.
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.
Yes device types:
2477D (0x01, 0x20) Firmware: 45 Engine Version: i2cs
2477S (0x02, 0x2a) Firmware: 45 Engine Version: i2cs
@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.
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:
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:
A couple of new changes in 2022.7.4:
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.
My next release should introduce a few more devices. These are the ones I am working on currently:
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.
Great work!