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

Integration is local_push but manifest says local_polling #10

Open
kongo09 opened this issue Dec 9, 2021 · 8 comments
Open

Integration is local_push but manifest says local_polling #10

kongo09 opened this issue Dec 9, 2021 · 8 comments

Comments

@kongo09
Copy link
Contributor

kongo09 commented Dec 9, 2021

As far as I understand, the integration registers a callback URL in the bridge and processes the callbacks. Shouldn't that classify the integration as local_push instead of local_polling as it is stated in the manifest right now?

@alexdelprete
Copy link
Contributor

alexdelprete commented Dec 9, 2021

It does both. I don't know if they can both be specified in the manifest.

@kongo09
Copy link
Contributor Author

kongo09 commented Dec 9, 2021

If it does both, I'm inclined to advocate for local_push as this reflects the real-time nature of the integration. I would expect that most integrations that are local_push can also poll if they see the need.

@alexdelprete
Copy link
Contributor

I would put them both, separated by a comma. Maybe it works but it's not documented. Worth a try...

@kongo09
Copy link
Contributor Author

kongo09 commented Dec 9, 2021

After reading https://www.home-assistant.io/blog/2016/02/12/classifying-the-internet-of-things/#classifiers it is clear to me that an integration that is notified by the device about a state change is classified as local_push. Ideally, these devices (and integrations) still allow polling, so that state is available, e.g., after Home Assistant startup.

@alexdelprete
Copy link
Contributor

I already read that document many times, and the reverse could also be stated: the two categories are not mutually exclusive, and one does not contain the other. nuki_ng offers direct communication with the device through push AND polling.

But really, I don't think it's so important to require a long discussion, it's up to @kvj to decide.

The real issue is that you can you choose only one, but I don't know if that's even true, if it is, HA devs should change that and allow multiple choices.

@kvj
Copy link
Owner

kvj commented Dec 10, 2021

Strictly speaking, as the component supports Web API endpoints, it should be cloud_polling. But, as this value is not dynamic and doesn't change anything, it doesn't matter which value to use

@alexdelprete
Copy link
Contributor

Correct. It should be possible to have a list vs choosing only one. And I agree it doesn't really matter. It changes a small icon on the upper right of the integration box in the integration list...

@kongo09
Copy link
Contributor Author

kongo09 commented Dec 10, 2021

All fair, maybe we should just close this. I guess I was coming a bit from a marketing perspective, especially in comparison to the default Nuki integration which cannot do push at all and the HA documentation which calls push the best of the best.

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

3 participants