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

[insteon] Rewrite with backward compatibility #17146

Merged
merged 26 commits into from
Oct 10, 2024
Merged

Conversation

jsetton
Copy link
Contributor

@jsetton jsetton commented Jul 25, 2024

This is a rewrite of the Insteon binding adding some much needed improvements while keeping some of its core code refactored. Apart from simplifying the user experience by retrieving all the configuration directly from the device when possible, and improving the way the Insteon things are configured in MainUI, here is an exhaustive list of the changes:

  • introduced device configuration automated determination
  • converted mode-based number items to string type with descriptive states
  • added number items uom support
  • added distinct scenes and x10 device things
  • added distinct bridge things for supported hub/plm devices
  • added button event trigger channels
  • added device products configuration layer
  • added device link database support
  • added device cache storage
  • added device operating flags controls
  • added modem configuration flags controls
  • added related devices synchronization feature
  • added heartbeat timeout monitor
  • added ability to link/unlink a device to the modem
  • added ability to add missing default links
  • added link database & scene management support
  • added scene state support
  • added new i3 devices basic support
  • added ezrain sprinkler device support
  • revamped console commands with auto-completion support
  • improved discovery service
  • improved thing status

Since the configuration process was revamp, this would require existing users of the binding to reconfigure their Insteon setup.
However, backward compatibility is provided as some of the legacy code was kept with some adaptation to interface with updated core components. Existing device legacy things connected to a network legacy bridge will be migrated to the legacy-device thing type while still keeping the same ids to prevent any breakage.

@jsetton jsetton requested a review from a team as a code owner July 25, 2024 02:26
@jsetton jsetton force-pushed the insteon branch 3 times, most recently from 41db1f9 to f096ded Compare July 26, 2024 05:08
@lsiepel
Copy link
Contributor

lsiepel commented Jul 26, 2024

I thought you would wait for me to comment on the other PR, but youre going fast. I'll try to look at this and the other PR (might close that one) next week.

@jsetton jsetton force-pushed the insteon branch 2 times, most recently from 56505e5 to 70b99f3 Compare July 26, 2024 16:51
@jsetton
Copy link
Contributor Author

jsetton commented Jul 26, 2024

As I mentioned in the other PR, I wanted to make sure that the binding would be maintainable by having the legacy classes use the updated folder structure with minimal redundancy. Anyway, I think the way I structured this PR might be easier to review.

@jsetton jsetton force-pushed the insteon branch 8 times, most recently from 7dfc222 to c45173e Compare August 1, 2024 14:18
@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/insteon-binding-beta-4-1-0-5-0-0/154128/1

@lsiepel
Copy link
Contributor

lsiepel commented Aug 29, 2024

Spend some time looking at this PR. Pretty impressed by the documentation. On a high level i think this is the way forward. There also seem to be changed in the legacy part that i can't directly link as essential to integrating. They also don;t seem wrong, but with a large rewrite as this regressions are expected.
I guess you already tested and upgrade your own setup, did you share this version and/or do you have test results from others?
I'll try to complete my review soon, but 157 files.. this might take some time.

@jsetton
Copy link
Contributor Author

jsetton commented Sep 3, 2024

I guess you already tested and upgrade your own setup,

I did test the legacy code with my own setup without any issue. There are no change in behavior for existing users. As far as the new changes, I have been solely using my implementation for couple years now to test and fix any issues.

did you share this version

Yes, it is available in the marketplace as beta version.

do you have test results from others?

I have had several test results for the new changes from others over the previous PR comments and community forum posts. I have reached out to several of them asking for feedback and if possible to test the backward compatibility support.

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/insteon-binding-beta-4-1-0-5-0-0/154128/8

@lsiepel
Copy link
Contributor

lsiepel commented Sep 3, 2024

Can you try not to force push as then it is hard to review / track changes.

@jsetton
Copy link
Contributor Author

jsetton commented Sep 4, 2024

@lsiepel I did some refactoring around the transport message code improving the separation between a Msg object and the MsgDefinition object it is derived from. Let me know if you want me to push this change to this PR or wait until you finish reviewing the current changes.

@lsiepel
Copy link
Contributor

lsiepel commented Sep 5, 2024

@lsiepel I did some refactoring around the transport message code improving the separation between a Msg object and the MsgDefinition object it is derived from. Let me know if you want me to push this change to this PR or wait until you finish reviewing the current changes.

Let us first finish this PR before we do further refactoring.

Copy link
Contributor

@lsiepel lsiepel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not covered everything yet (114 / 157 files), but made some progress revieweing this PR and don't want to hold it back.

* introduced device configuration automated determination
* converted mode-based number items to string type with descriptive states
* added number items uom support
* added scenes and x10 device things
* added distinct bridge things for supported hub/plm devices
* added button event trigger channels
* added device products configuration layer
* added device link database support
* added device cache storage
* added device operating flags controls
* added modem configuration flags controls
* added related devices synchronization feature
* added heartbeat timeout monitor
* added ability to link/unlink a device to the modem
* added ability to add missing default links
* added link database & scene management support
* added scene state support
* added new i3 devices basic support
* added ezrain sprinkler device support
* revamped console commands with auto-completion support
* improved discovery service
* improved thing status

Signed-off-by: jsetton <[email protected]>
@jsetton
Copy link
Contributor Author

jsetton commented Oct 1, 2024

Sorry again about the force push, I had to rebase my changes to clear another upstream merge conflict.

All the changes I made related to your code review starts from 2f25a14.

Copy link
Contributor

@lsiepel lsiepel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the remaining files and looked back at the previous round. That was a lot to digest. Initialy my intention was to have a less integrated binding with old/new behaviour to prevent regression and make review easier. Hopefully i have not missed anything. Once these comments are finished, i strongly advice to get some more users to test this binding with the workflow of 1. use it 'as is' for one week, 2. migrate and 3. use it for another week with the new thing types.

Unfortunately it won't be in todays milestone release, but hopefully in the next to get some more test milage before the stable release around christmas.

@jsetton
Copy link
Contributor Author

jsetton commented Oct 6, 2024

I strongly advice to get some more users to test this binding with the workflow of 1. use it 'as is' for one week, 2. migrate and 3. use it for another week with the new thing types.

I had one user test both already. Another one has been focused on first testing new thing on the side and am working with him to test the migration portion.

@lsiepel
Copy link
Contributor

lsiepel commented Oct 10, 2024

Thanks for your patience and the work you put in this PR. While it is more integrated then I initially aimed for, it seems pretty clean and a lot has been done to prevent regressions.

@lsiepel lsiepel merged commit d923eb9 into openhab:main Oct 10, 2024
5 checks passed
@lsiepel lsiepel added this to the 4.3 milestone Oct 10, 2024
@jsetton jsetton deleted the insteon branch October 10, 2024 13:53
@jsetton
Copy link
Contributor Author

jsetton commented Oct 10, 2024

@lsiepel I did some refactoring around the transport message code improving the separation between a Msg object and the MsgDefinition object it is derived from.

#17537

joni1993 pushed a commit to joni1993/openhab-addons that referenced this pull request Oct 15, 2024
* [insteon] Restructure legacy code for rewrite

Signed-off-by: jsetton <[email protected]>
matchews pushed a commit to matchews/openhab-addons that referenced this pull request Oct 18, 2024
* [insteon] Restructure legacy code for rewrite

Signed-off-by: jsetton <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature for an existing add-on
Projects
None yet
3 participants