Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.73%. Comparing base (2b881cf) to head (19b38cb).

@@            Coverage Diff             @@
##           master    #1566      +/-   ##
==========================================
+ Coverage   92.70%   92.73%   +0.02%     
==========================================
  Files         156      157       +1     
  Lines        9602     9630      +28     
  Branches      974      976       +2     
==========================================
+ Hits         8902     8930      +28     
  Misses        499      499              
  Partials      201      201              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@rytilahti Let me know your thoughts here. I finally found someone who could help get the correct commands and modules so I could set it up. I created this module based on the older iot modules but with the same barebones functionality as the newer smart homekit module.

Unfortunately, I have not been able to test its functionality because I don't have an older iot device with homekit.

Looks like the test coverage is failing, as we have no fixture containing this data. Do you have a fixture file from a real device that has this module? It would be great to add it to our collection!

I don't, how would I be able to use my branch to get one? I don't have a device but I could get the user that has one to test with my branch, if that's possible?

I messaged the user with the instructions for pulling my repo with the updated code so they can get us a fixture, will let you know. Then I can update everything.

Okay, awesome! I usually use the github cli tool to fetch a PR (e.g., gh pr checkout 1566) & then just use the regular dumping script. Let me know how it goes!

@rytilahti ok, got the fixture, added it and updated everything here. Let me know if you need anything else.

Nice, can be merged as soon as the tests pass!

@rytilahti ok, everything looks good except the codecov checks.

@rytilahti Will we be able to get a new release published after this? I'm hoping to get this implemented into my plugin, but would need a published version in Homebridge.

I am around tomorrow to cut a release if that helps

That would be fantastic. Good to hear from you and glad you're doing ok!

Looks like the code paths are not covered for some reason, I can try to take a look and fix it if I find some time tomorrow.

As for the next release, I would like to include a fix to one issue that's been pending on my todo. I will try to handle that and create a release probably by the end of the next week.

Ok, sounds good. I have some MAC Address inclusion and exclusion features in the plugin that are used for right now so next week should be fine. I appreciate both of your hard work.

@ZeliardM I added a commit fixing the initialization and the tests. There were several issues, but now your user should be able to see the feature getting initialized correctly.

The commit adds homekit module for all iot devices, but I don't think it should be an issue. In any case, it would be a good idea to test this PR against devices that do not support the module. @sdb9696 what do you think about this approach?

Btw, for future PRs, it's a good idea to use feature branches instead of master in your own repository, just in case :-)

I gotcha. Yea, I will take that approach in the future. Thanks.

I can test it against iot devices without HomeKit as I have several. And with child devices. What would I be looking for?

Yeah, just try the cli tool against your devices to see that everything is still working as expected. If you enable debug logging with --debug, you should also see that it tried to query the new module, but reports that it is not supported.

iotstrip.py does not call the super for the modules from IoTDevice so it will need to be added manually there. But everything for my plugs is working great. I see it called, but it comes up as not supported and moves on, no errors or hiccups. I can push out a commit for the iotstrip if you would like?

I pushed changes for adding the HomeKit module to the iotstrip devices as well as the rest of the code coverages for the testing of the module. I made changes so that when checking against the fixtures that if the data wasn't in the fixture it was skipped or said that it didn't exist instead of force adding the data to the fake protocol.

Had to fix the docstring checks. The way the module and tests are now for coverage, they actually test against the existing fixture files instead of blindly adding data to the fake protocol. This allowed for coverage tests of not actually having any data in the setup_info_get but therefore causes the homekit_setup_code to not be in the features. Fixed that and modified the docstring with an ellipsis to handle if devices have the code or not, but the homekit module is still always added as default, but the code may or may not be added as a feature, if that makes sense. Is this ok done this way?

Ok, coverage looks good, everything is still working for iot devices on my end that don't have homekit, it just flags it as not supported and moves on. The module being added is fine since every device could have it and there's no real way to test from the discovery of the older iot devices if they have homekit before adding the module and we add the module and just have it flagged as not supported, works for me. If y'all are good?

@rytilahti @sdb9696 I wanted to check and see if things were still progressing for this to be released?