-
Notifications
You must be signed in to change notification settings - Fork 130
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
Insteon: Add Support for ALDB_Delta #74
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add basic code for storing and saving the ALDB_Delta. ALDB_Delta and related functions are most related to the ALDB object not the device object. Moving and rewriting code from initial ALDB_Delta branch.
Alter Scan All Links so that when the first argument passed is true, devices which are unchanged will be skipped
also fix a typo
Add framework to catch status_request responses that were requested by query aldb delta
Moved the callback contained in the last _on_peek method to the is_info_request routine of the device. Setting the ALDB_Delta will only be done at the completion of a scan, so the aldb success callback can be used.
Made a mess out of the _get_next_linkscan sub, but it works.
Changes made to ALDB_i1 Add_link so it will prevent any adding of a link from any voice command. The code looks like crap, references and callbacks stacked on top of references and callbacks. What a mess. Should be able to do the same thing for update and delete using the same method.
Copied logic from add_link Also fixed a stupid error in _get_next_linkscan, but code is still a horrible mess, which is my fault. And it still has problems.
Setup foundation for skipping aldb_delta check if link table health is bad
Requesting a status is unnecessary if we already know we are out-of-sync
Stupid mistake. Fix typos in Delete_Link which used a callback to add_link or referenced adding a link. Fix logic in delete_link and add_link to make sure that an out of sync device is not altered.
Assume that the device link database won't change in less than 2 seconds This is in anticipation of syncing multiple links to the same device in sequence. This way we only check the ALDB_Delta at the start of the sync process.
Call peek of the address altered by add_address to confirm that it was accurately poked in. Required to enable a scan_one action in _on_peek which reads one address then queries the aldb_delta. Sync links can now sequentially add links while keeping the aldb databases and the aldb_delta in sync.
Copying the concept used in add_link
When scan all links, MH ALDB database is cleared. But for scan_one which only scans a single address, we don't dump the ALDB database. So the fact that an aldbkey already exists does not make it a duplicate, we could be scanning the same address again. It is only a duplicate if the addresses are different.
Since we skip peeking anything but the ALDB_Flag. We need to have a call to query_aldb if called for scan_one only. Fix #2
The ALDB_Delta gets reset to 00 when devices lose power. The ALDB_Delta also gets reset to 00 when the devices are factory reset. Since we can't distinguish between these two states, we never allow the ALDB_delta to stay at 00. If a devices loses power, the ALDB_delta will change and a full scan will be conducted. At the conclusion of the scan we attempt to query and store the aldb_delta. If the aldb_delta is 00 we find the first empty address on the device. We then peek the aldb_flag(the first byte) of this address We then poke the same value back into the device. We use an empty address to decrease the potential harm from writing an incorrect byte if something goes wrong We then scan this address, being empty, the scan should end after the first byte We then query the ALDB_delta which should now be 01 since we "wrote" a single byte. The value increases even though the data didn't change. I reverted the previous commit as I was headed down the wrong path. Solves #3
Checks whether Aldb_delta is insync prior to updating flags. If insync, resyncs aldb_delta after update_flags, if out of sync, update flats is still permitted to run, but no subsequent update of aldb_delta is made afterwards. There is no potential for update_flags to overwrite a link entry, so it shouldn't fail if out of sync. Partially fixes #5 Need to make a similar patch for update_local.
Similar to prior commit for Update_Flags. Completes the fix for #5
Similar logic to add and delete links. This completes everything necessary for sync_links to work. This may be the last major thing needed for aldb_delta to work
This was pulled into Michael's i2_support and will be merged into master shortly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All Insteon Devices have an ALDB_Delta that increments every time its memory is changed. This branch uses the ALDB_Delta value to determine whether any changes have been made to the device since MH last inspected the device.
This branch uses this information to do the following:
Caveats:
My experiences with this have been very good so far.
I am waiting to merge the branch until it is merged with i2cs support, which will require making some changes to I2CS.