New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
all-link database table view - show/hide unused anomaly #117272
Comments
Hey there @teharris1, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) insteon documentation |
I am not able to recreate this issue. It is also odd that a modem would have a "Partially Loaded" status. Can you try reloading the modem ALDB and also try to recreate this issue with a different device? |
thanks for your response, tom. as of today, viewing the ALDB table for my powerlinc USB PLM (insteon model 2413U), the status is now "loaded" and the there are no unused items displayed in the link table. so in other words, the bug i reported a few days ago is no longer manifesting itself in my system - it seems possible/likely to me that the display inconsistency was related to the fact that there was a read-from-device operation in progress. to provide a bit more detail and few additional curious observations... not sure whether i mentioned, but i have a pretty big installation of insteon devices. (>200 total). when viewing ALDB for my PLM, and i select "read from device", if i sort the table by record ID, i can actually watch as it updates gradually loading records with decreasing record ID values. while this may seem a triviality, to me it was very valuable, since it was a rare case when i could actually see that the insteon integration was actually doing something -- without this clue, i would otherwise have no idea whether the read-from-device operation took 5 seconds, 5 minutes, or 5 hrs. anyway, it seems to start from record 8191 (which happens to be 2^13-1), then works its way down gradually taking 5-10 minutes to completely populate. a curiosity is that it only goes down to record #2031 and never shows any records numbered below that. since it was scanning downward (in terms of record number) and always seemed to stop at 2031 (which seemed a bit arbitrary), at first i thought possibly scanning the complete table just timed out or something, so i retried a few times, but it always seemed to stop at the same value. so at this point, i'm not sure if this is a sign there is something wrong with my PLM vs. if it is just normal/expected behavior - like perhaps the first 2k records are "reserved" or something. also just a curiosity, but when i turn on "show unused" in the menu, i still see a sparse list of records with record-id values ranging from 2023 to 8191. so some obvious questions: how did the table get this way with only certain records are "present" in the table, some in-use, and some are not. can the ones that are not in-use possibly be deleted? do they automatically get garbage-collected by the system? (offhand, it looks like i currently have 50-60 records with in-use = no). is there some other operation i can perform (perhaps utilities>delete-device?) that would completely delete these records from the table? would there be any benefit to the system in terms of performance, time to load, etc. if i were to do this? |
The funny decimal values 8191 and 2031 are perfectly "natural" hex values, 1FFF and 7EF A weakness would be if you added 101 records then deleted the first 100. Searches would still read the first 100 looking for any non-empty records to see if it matched. However, a search for an empty spot would be found on the first search. |
thanks for the explanation. so now i think i understand why there are no entries shown in the table below some lower limit - for me, 2023. i also understand that there are no entries in the table above 8191. so all record numbers between 2023 and 8181 are in one of three states: 1. they show up as in use=Yes. 2. they show up as in use=No. 3. they don't show up in the table at all. you mention records being deleted and imply this is the same as being marked "empty" -- to clarify, is being deleted the same as having in-use field set to No? or does that correspond to a record that doesn't show up at all? you mention that there is a high water mark in the records table... so should i consider it a bad sign that i have a record with record number 8191 that is marked "in use"? to me that suggests that at one point my table got full (possibly when it was being managed by an earlier automation control system), pushing the mark up to 8191. i wonder - does this have any negative performance ramifications for me? is the performance impact limited to just at integration start-up? or does it impact performance of insteon in my system on an ongoing basis? |
A record can be in one of three states:
Has a database record
Had a database record
End of used database
I assume that corresponds to use = Yes use = No and doesn't show up at all
We start with an "empy" database, all full 0f zeroes (Starting at 1FFF)
When we add a record, a bit gets set indicating it is in use
Also, another bit gets set indicating it isn't the end of the database (Highwater bit)
We continue to add new records, next one goes at 1FF7 , then 1FEF...
If we later "delete" the record at 1FFF, the "in use" bit gets cleared but the highwater bit stays set indicating there may be more records below.
If your database is full up to the "end" of the memory used for the database, 7E7, with once used records that are now available for a new record, it will only affect database management and not the Insteon network.
I
…________________________________
From: dduff617 ***@***.***>
Sent: Friday, May 17, 2024 7:42 AM
To: home-assistant/core ***@***.***>
Cc: Robert Slick ***@***.***>; Comment ***@***.***>
Subject: Re: [home-assistant/core] all-link database table view - show/hide unused anomaly (Issue #117272)
You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
thanks for the explanation.
so now i think i understand why there are no entries shown in the table below some lower limit - for me, 2023. i also understand that there are no entries in the table above 8191.
so all record numbers between 2023 and 8181 are in one of three states: 1. they show up as in use=Yes. 2. they show up as in use=No. 3. they don't show up in the table at all. you mention records being deleted and imply this is the same as being marked "empty" -- to clarify, is being deleted the same as having in-use field set to No? or does that correspond to a record that doesn't show up at all?
you mention that there is a high water mark in the records table... so should i consider it a bad sign that i have a record with record number 8191 that is marked "in use"? to me that suggests that at one point my table got full (possibly when it was being managed by an earlier automation control system), pushing the mark up to 8191. i wonder - does this have any negative performance ramifications for me? is the performance impact limited to just at integration start-up? or does it impact performance of insteon in my system on an ongoing basis?
—
Reply to this email directly, view it on GitHub<#117272 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHU6YX5G4I73RCRQ2PD2BBDZCYJMLAVCNFSM6AAAAABHSF2YYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXG43DAMZVGQ>.
You are receiving this because you commented.Message ID: ***@***.***>
====================================== CONFIDENTIALITY NOTICE: This e-mail message is intended only for the person(s) or organization(s) to whom or which it is addressed and may contain information which is confidential and privileged. The unauthorized use, copying, distribution, or disclosure of this e-mail or any of its contents by anyone other than the intended recipient is unauthorized and unlawful. If you have received this e-mail in error, please notify the sender immediately and destroy all copies of this transmission. Thank you. https://www.insteon.com/
|
AHHH. i see now. what i perceived at first as a "sparse" table of records (i.e. some record #'s were present, others not), i now see is just a reflection of the record # being the starting address and each record being 8 bytes long. duh - i feel dumb for not grokking this before. thanks, @rslick. |
The problem
when viewing all-link database in insteon, there is an option to view or hide the unused records. this option is modified via the three-dots menu at the top right of the screen when viewing the all-link database table. i'm assuming the obvious meaning of "used" means that the "in use" binary attribute of the link is set to true.
i observe that when the hide-unused option is selected, there are still unused links shown in the table. this can be demonstrated easily in my configuration by simply sorting the records in the table by "in-use" and there are clearly lots of records shown with in-use value of "No".
so seems like a bug.
What version of Home Assistant Core has the issue?
core-2024.5.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Insteon
Link to integration documentation on our website
https://www.home-assistant.io/integrations/insteon
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
at the time i observe the bug as reported above, i'm viewing the ALDB for my insteon 2413 PLM, so it's a MUCH bigger table that would be displayed for most other device.
also, presently while i am reporting this bug, the status of the table (as displayed at the top) is "partially loaded" in case that might make a difference.
The text was updated successfully, but these errors were encountered: