I’m not sure anyone is still following this thread, but I did a brand new binding based off the existing network binding. It does pretty much the same stuff (no speedtest, yet). It is written using Futures and Executors, etc to try to alleviate the threading and leaking issues. If anyone’s interested, I could post it somewhere.
hi, can i try this different binding, having a new phone that seems to evade detection
If the thing channel interface is the same, there is no reason not to make a PR for official integration. I have written MQTT bindings also with CompleteableFutures and the async programming model would help the binding a lot.
I’ve never done much with committing code back to a project outside of my own work. What steps do I need to take? It’s on a separate branch right now, along with a new zoneminder binding.
Right now might not be the best time. OH is in feature freeze.
If your branch is pushed to github, it’s super easy. Github will show you a very obvious greenish button link to create a PR. As long as you are on that specific branch.
Just make sure that branch only contains the network binding part and nothing else.
Make sure the code is properly formatted, and documented and the readme is still up to date.
Well, I created a new binding that I called ‘Presence’ since I thought it more closely represented what its purpose was. I borrowed a lot from the network binding and I didn’t want to break that in case other were using it, especially for the speed test which mine doesn’t do. I am also working on a new zoneminder binding, separate from the existing one because the existing one depends on a separate library that the original author published separately. I guess I should submit them on different branches and PRs?
Not at all. Network binding is all about networking, it just happens to be useful for one way to do presence detection, and for many, it’s the least reliable way to do it. For example I have 29 Network Things, 4 of which have anything to do with Presence.
I is always better, where possible, to contribute back rather than creating wholly new. But you are correct, you need to try to avoid breaking existing functionality.
I wouldn’t see why the new feature should break any existing stuff from the network binding. So as all the technologies used are very similar, it imho makes most sense to extend the network binding and make it more reliable for presence detection use cases. I’ve also left a comment here.