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

Last Entry Can be Used #255

Merged
merged 9 commits into from
Dec 18, 2020
Merged

Last Entry Can be Used #255

merged 9 commits into from
Dec 18, 2020

Conversation

krkeegan
Copy link
Collaborator

Fix the database object to reflect the possibility that the last entry may not be an unused entry.

If the last entry is used, when adding entries to new memory locations, add an additional blank unused entry so that the last entry is unused.

Not exactly what the original issue was opened about, but this was the result of the review.

Closes #250

The notes in the device db contain the following:

 The last entry in the database.  Devices show an unused, null (all
 zeros) marked with the LAST bit set in the db.  From the docs this
 shouldn't be required - the LAST bit can be a usable entry but it
 doesn't appear to work.

Which suggests that having the last entry be a usable one doesn't
work.  But some of the errors in TD22057#231 suggest that maybe
duplicating entries no longer works.

This instead sets the last entry to all 0x00s which is what a
factory reset entry looks like.  I have hopes that this may
solve generic NAK errors on new devices when adding entries using
a new address.
Insteon devices always keep the last memory location as unused
and all 0x00s.  However, it looks like ISY may use the last
location.  Our code also didn't treat the last_loc as unused
even when it was marked as so.

Now, the last_loc is only put in the unused array if it is unused.
This means that to write to an existing mem_loc we need >1 unused
address.

To bring an ISY database into alignment with how we use it
if the last loc is used, we do 3 things.
1. Change the last_loc flag on the current last entry to false
2. Write the new entry in the slot just below #1 marked as
used and not last
3. Write a new all 0x00 entry marked unused and last below #2

Finally rearrange how we write new entrys so that:
1. Write the new entry in the slot currently marked as last
2. Write a new all 0x00 entry marked unused and last below #2

This could mean that if things fail before #2 happens a bunch
of bizarre old links may reappear, but I think this is extremely
unlikely, and organizing it this way enables the ISY fix to be
done in only 3 database writes.
@krkeegan krkeegan linked an issue Dec 15, 2020 that may be closed by this pull request
@krkeegan krkeegan merged commit 0ddef77 into TD22057:dev Dec 18, 2020
@krkeegan krkeegan deleted the Fix_250 branch December 18, 2020 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Do we really need to Write two Entries when Adding a New Entry?
1 participant