Skip to content
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

Open
dduff617 opened this issue May 11, 2024 · 7 comments
Open

all-link database table view - show/hide unused anomaly #117272

dduff617 opened this issue May 11, 2024 · 7 comments
Assignees

Comments

@dduff617
Copy link

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.

@home-assistant
Copy link

Hey there @teharris1, mind taking a look at this issue as it has been labeled with an integration (insteon) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of insteon can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign insteon Removes the current integration label and assignees on the issue, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


insteon documentation
insteon source
(message by IssueLinks)

@teharris1
Copy link
Contributor

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?

@dduff617
Copy link
Author

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?

@rslick
Copy link

rslick commented May 16, 2024

The funny decimal values 8191 and 2031 are perfectly "natural" hex values, 1FFF and 7EF
Your assumption is correct, the first values of the EE memory are used to save properties etc.
Records that are deleted are just marked "empty" and will be re-used when the space is needed.
There is no garbage collection, but any new record will be placed at the spot closest to the start of EE (1FFF) that is marked empty.
Records that have never been used aren't part of the searchable database so they don't cause a delay. Each record is marked with a "highwater" mark indicating where the current end of current records is.

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.

@dduff617
Copy link
Author

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?

@rslick
Copy link

rslick commented May 17, 2024 via email

@dduff617
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants