Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Initial commit of Bluetooth binding and Bluetooth transport bundles #3531
The code base should be equal to: #551
IMHO the code itself needs further work.
BUT it should be enough to create a CQ and merge it, so further improvements could be done using a central place and code base.
We should ensure that someone is working (again) on that cleanup.
This was referenced
May 29, 2017
I agree - it would be good to get this merged. I’m currently working on an alternative transport (i.e. not dbus) using the BlueGiga BLED112 dongle which should be usable universally. I’m not 100% how much work it is at the moment but I’ve written an interface to the dongle which is working and I think it’s doable without huge work. At the moment I’m trying to avoid changing the common transport bundle but if I succeed in getting this working then it will be much easier for me to look at this as I won’t need a linux machine. One comment on this - the yeelight bundle I think conflicts with another bundle in OH2 for the wifi version. I refactored the bundle here to be yeelightblue - it might pay to think about that before this gets merged.
I created #3533 for the failed integration build.
@cdjackson I don't care if the openHAB binding changes its name to yeelightwifi or we change the ESH binding to yeelightblue (perhaps
Should I change yeelight to yeelightblue or yeelight-blue?
Having had a closer look at the code, I am not really too keen to merge it as is anymore.
Especially the Yeelight binding shows that there are huge issues in the architecture:
Additionally, the Yeelight binding is in a bad shape:
I tried to refactor the binding, but ended up with hardly any code left in place. As the binding isn't much code anyhow, I would suggest to completely remove it from the PR, so that it does not accidentally serve as a template for others.
For the other two transport bundles, I would create a CQ then, unless @cdjackson has again time for helping on that code, so that we could discuss potential refactorings wrt the BlueGiga dongle.
@cdjackson I tried to put our discussion in a diagram:
The general scheme is that we should not think of the "BLE Binding" to be a single bundle, but rather a feature (i.e. a set of bundles, not all of which need to be installed).
This should all nicely fit into the current framework architecture (actually, the binding API had been designed specifically in a way to support that, so I think it is time to actually use it that way :-)).
Chris, does that match our conversation? Do you have anything to add?