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

Remove service runtime #42

Closed
stefano055415 opened this issue May 7, 2021 · 15 comments
Closed

Remove service runtime #42

stefano055415 opened this issue May 7, 2021 · 15 comments

Comments

@stefano055415
Copy link

I have an accessory with N services, is it possible to remove one more at runtime?

@shahpiyushv
Copy link
Collaborator

@stefano055415 , an API can be provided for that, but we haven't done so, since there wasn't any need for that. What's your use case?

@stefano055415
Copy link
Author

I have a device that can be used as an outlet or as a switch, and can be configured at runtime, so when I change from switch to outlet, i would like to update the accessory on homekit

@shahpiyushv
Copy link
Collaborator

Better to set something in NVS and just reboot and set appropriate services? Even the category identifier can be correctly updated between HAP_CID_SWITCH/HAP_CID_OUTLET then.

Or implement accessory as a bridge and add/remove a switch/outlet as a bridged accessory as applicable?

@stefano055415
Copy link
Author

I tried to save and reboot, but on homekit it doesn't work anymore

If I update a service, from switch to outlet and reboot, hap duplicates the services and they are unreachable

If I restart without changing the services everything works fine

@shahpiyushv
Copy link
Collaborator

@stefano055415 , Can you try calling hap_update_config_number() after you reboot into the firmware wherein the services have changed? Did you try the bridge option?

@stefano055415
Copy link
Author

I have try to call hap_update_config_number() but not working
I don’t try bridge, because we have other devices like lock that can not be included as bridge

@stefano055415
Copy link
Author

Ok I found the problem.
On the function:
hap_acc_t * hap_acc_create (hap_acc_cfg_t * acc_cfg)
next_iid is fixed at 1

if I change the service from switch to outlet and reboot it doesn't work.
but if I increase the next_iid = 100, for example, and reboot everything works fine.

is it possible to implement this fix in the next update?
Thank you

@shahpiyushv
Copy link
Collaborator

@stefano055415 , I will check and add support as appropriate. For the time being, even though they could be cumbersome to use, can you check if hap_char_set_iid() and hap_char_set_iid() suit your purpose? These have to be called for every service/characteristic though, to set some hard-coded value for them.

@stefano055415
Copy link
Author

ok thanks I try to see if so I can solve for the moment.

if you want as soon as you are able to introduce this new function, I would be happy to be able to test it

@shahpiyushv
Copy link
Collaborator

@stefano055415 , can you apply this next_iid_patch.txt and see if the hap_acc_set_next_iid() API serves your purpose?

@stefano055415
Copy link
Author

with this patch, everything seems to work.

I just made a small change

void hap_acc_set_next_iid (hap_acc_t * ha, uint32_t next_iid)
{
if (ha) {
((__hap_acc_t *) ha) -> next_iid = ((__hap_acc_t *) ha) -> next_iid + next_iid;
}
}

every time I make a change (from switch to outlet for example), I increase a value and save it in nvs.
on next reboot I use this value to keep the iids unchanged

accessory = hap_acc_create(&cfg);
hap_acc_set_next_iid(accessory, nvs_read_config_version());

@shahpiyushv
Copy link
Collaborator

@stefano055415 Changing the API as above would be too use case specific and non deterministic. Setting a fixed value for next_iid would suit even those use cases wherein services may have changed across fw upgrades, but the iid values need to be retained as per HAP requirements. Since value of next_iid after calling hap_acc_create() would be the same each time, wouldn't it be convenient if you manage that offset in your app, instead of doing it inside the API?

@stefano055415
Copy link
Author

ok I understand, however for my needs it is fine.
I call the function N times and it works.

I have another problem with apple tests.

Schermata 2021-05-14 alle 09 24 28

Could you help me?

@shahpiyushv
Copy link
Collaborator

@stefano055415 , are you working on a commercial HomeKit product? If yes, as indicated in the README, please get in touch with us here to get access to the MFi variant of the SDK. The above tests would pass with that.

Moreover, please also get your use case confirmed from Apple. I am not sure if they would allow this runtime service change.

@stefano055415
Copy link
Author

ok thanks, I proceeded to make the request.

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

No branches or pull requests

2 participants