Initial commit of Bluetooth binding and Bluetooth transport bundles #3531

maggu2810 · 2017-05-29T07:42:57Z

The code base should be equal to: #551

based on the current master with all conflicts solved
cleaned up POM files
fixed license headers
Java is set to 1.8
fixed classpath
applied clean up rules
re-formatted ESH-INF XML files
renamed yeelight to yeelightblue

IMHO the code itself needs further work.

don't use printStackTrace
don't catch exceptions and ignore them
apply changes to work with the current Bluez versions
etc.

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 is a rebased version of #551 Signed-off-by: Chris Jackson <[email protected]> Signed-off-by: Markus Rathgeb <[email protected]>

Signed-off-by: Markus Rathgeb <[email protected]>

cdjackson · 2017-05-29T08:55:25Z

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.

maggu2810 · 2017-05-29T09:16:10Z

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 yeelight-wifi and yeelight-blue would make sense, so both state the transport it is using).

Should I change yeelight to yeelightblue or yeelight-blue?

cdjackson · 2017-05-29T09:19:26Z

I personally don’t mind. I used yeelightblue here, but yeelight-blue does look nicer ;).

kaikreuzer · 2017-05-29T09:28:37Z

Should I change yeelight to yeelightblue or yeelight-blue?

We so far do not use any hyphens in binding ids, so I would clearly vote for yeelightblue.

Related to: #3531 (comment) Signed-off-by: Markus Rathgeb <[email protected]>

maggu2810 · 2017-05-29T12:11:57Z

renamed yeelight to yeelightblue

Signed-off-by: Markus Rathgeb <[email protected]>

svilenvul · 2017-05-31T12:20:54Z

...n/java/org/eclipse/smarthome/binding/yeelightblue/internal/handler/YeelightThingHandler.java

+        timerTask = null;
+    }
+
+    public float[] RGBtoHSB(int r, int g, int b, float[] hsbvals) {


I understand that the purpose of this PR is to apply only the most important changes, but I just want to mention that this method seems to me redundant, as it is already implemented in ESH - see HSBType.fromRGB()

What do you think about create an issue to collect stuff that should be cleaned up?

@svilenvul Or alternatively feel free to directly commit fixes/clean-ups on a personal branch in your fork and we could pull that into this PR before it is going to be merged.

So, when do we want to create a CQ? Doesn't every change of the code base in this PR result in a delay of the initial CQ?
Wouldn't it be better to create a CQ for the initial code base and then allow us all the other changes (as long as they consists of <1k LOC) to be merged immediately without a CQ?

I wanted to at least spend an hour this week to roughly go over the code to see if it is ok to create a CQ (and thus merge as is) or if we (I) should do any changes to it upfront. In the meantime, I think it is ok for @svilenvul to work on improvements in his own branch - those can then result in a follow-up PR once this one is merged, right?

in a follow-up PR once this one is merged

Sure, I fully agree with that approach. 👍

I wanted to at least spend an hour this week to roughly go over the code to see if it is ok to create a CQ (and thus merge as is) or if we (I) should do any changes to it upfront.

Great 😉

Thanks for giving me green light to apply some changes, I have put this on my TODO list :)

I have put this on my TODO list :)

Better refrain from it for the moment - I just had a call with Chris and I will write a small summary soon; we agreed on some substantial refactoring of the code :-/

OK, I haven't read you comment below before :)

kaikreuzer · 2017-06-01T16:05:42Z

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:

It implements a discovery service that triggers general BT device discovery. Imho we should have a BTDiscoveryService with a Participant interface, similar to UPnP and mDNS.
The whole code depends on the BluetoothAdapter, its correct configuration, etc and has to handle all potential issues. I think it would be much better to model the BluetoothAdapter as a Bridge - this would easily allow adding other Bridges like the BlueGiga dongle.
Imho, we SHOULD after all have a "BLE Binding", which defines the bridge and provides the connectivity (i.e. parts what is in the transport.bluetooth.bluez) and additional bundles that then come with specific thing-types and handler implementations.

Additionally, the Yeelight binding is in a bad shape:

The binding has switch/dimmer/color channels side by side, which is wrong.
It defines channels like Temperature & Luminance, which are not reflected anywhere in the code.
Its config parameters are all device management actions, which is something we do not really officially support (and where I do not even see how they are used).
The unique ID is added as a property, although this needs to be a config parameter for the handler.

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 · 2017-06-02T15:12:25Z

I would suggest to hold off for a couple of weeks while I investigate some changes - I think Kai will write something on this later.

kaikreuzer · 2017-06-02T16:00:39Z

@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).

The "base" BLE bundle is the central one that is always required.
- It has the "ble" binding.xml
- It contains an implementation of a discovery service (which requires the presence of a BLEBridge)
- It defines a (yet to be designed) high level BLE-API interface for specific device support bundles as the current Android-like API is too low level.
BLEBridge implementations can be added as separate bundles.
- They come with a bridge-type (which defines their required configuration parameters) and an according handler implementations
- Their handlers implement the BLE-API interface.
- We can have one bundle that brings a handler that uses BlueZ over DBUS and another bundle bringing support for BlueGiga USB dongle.
Specific device support can as well be added via separate bundles.
- These bundles register a BLEDiscoveryParticipant and thus can provide DiscoveryResults for specific devices.
They define a specific thing-type and come with a specific handler implementation.
Their handlers have access to the bridge, which by definition implements the BLE-API interface, which can hence be used by those handlers.

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 :-)).
There is one issue that comes to my mind, though: All thing-types will have to reference all possible bridge-types in their XML, which is not nice. We should check whether it is possible to also allow some kind of placeholder, so that specific bundles do not need to be aware of all potential BLEBridge implementations.

Chris, does that match our conversation? Do you have anything to add?
If you have time to work on such refactorings, I would suggest to leave this PR open (after all) for now.
As @svilenvul is also eagerly waiting to get his hands into BLE, please let us discuss how the work could be possibly shared. Could e.g. @svilenvul already start with creating the suggested bundle structure?

cdjackson · 2017-06-02T16:09:57Z

Yes - I think that reflects our conversation. I have started already to implement this and would hope to have something in a week or so with any luck - we can discuss more then as I have a feeling there may be a few issues that might pop up ;)

kaikreuzer · 2017-07-24T14:10:51Z

If I am not mistaken, this is superseded by #3633 - unless anyone does not agree with the suggested refactoring of the architecture.

maggu2810 added 5 commits May 29, 2017 08:43

Initial commit of Bluetooth binding and Bluetooth transport bundles

90ef2b6

This is a rebased version of #551 Signed-off-by: Chris Jackson <[email protected]> Signed-off-by: Markus Rathgeb <[email protected]>

fix POM files and remove obsolete header text file

6b7a9b3

Signed-off-by: Markus Rathgeb <[email protected]>

bluetooth: fix license headers

cee5b27

Signed-off-by: Markus Rathgeb <[email protected]>

bluetooth: use Java 1.8

b047e2b

Signed-off-by: Markus Rathgeb <[email protected]>

bluetooth: fix classpath

b091cf4

Signed-off-by: Markus Rathgeb <[email protected]>

This was referenced May 29, 2017

Initial commit of Bluetooth binding and Bluetooth transport bundles #551

Closed

[WIP] add bluetooth transport and BLE binding #2670

Closed

maggu2810 added 2 commits May 29, 2017 09:52

bluetooth: run clean up rules

1f1d2dc

Signed-off-by: Markus Rathgeb <[email protected]>

bluetooth: format ESH-INF XML files

c646ce8

Signed-off-by: Markus Rathgeb <[email protected]>

rename yeelight to yeelightblue

91f6306

Related to: #3531 (comment) Signed-off-by: Markus Rathgeb <[email protected]>

fix version in manifest

c70e159

Signed-off-by: Markus Rathgeb <[email protected]>

svilenvul reviewed May 31, 2017

View reviewed changes

cdjackson mentioned this pull request Jun 10, 2017

WIP: Initial commit of BLE bundles (BLE, BlueGiga, YeeLightBlue) #3633

Closed

kaikreuzer closed this Jul 24, 2017

This was referenced Jul 25, 2017

Bluetooth Smart binding openhab/openhab-addons#2489

Closed

[WIP] [miflora] binding initial contribution openhab/openhab-addons#2491

Closed

vkolotov mentioned this pull request Aug 22, 2017

[bluetooth] WIP: Merging BluetoothSmart and Ble Bindings #4112

Closed

maggu2810 deleted the bt-for-esh branch August 30, 2017 11:17

kaikreuzer mentioned this pull request Nov 14, 2017

[WIP] Bluetooth Binding #4535

Closed

kaikreuzer mentioned this pull request Jan 31, 2018

Initial contribution of the generic Bluetooth binding with BlueZ support #4997

Merged

kaikreuzer mentioned this pull request Jan 31, 2018

Allow "abstract" references to bridge type ids for thing types #5010

Open

hsudbrock mentioned this pull request Apr 11, 2018

Static thing definitions openhab/org.openhab.binding.zigbee#169

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial commit of Bluetooth binding and Bluetooth transport bundles #3531

Initial commit of Bluetooth binding and Bluetooth transport bundles #3531

maggu2810 commented May 29, 2017 •

edited

Loading

cdjackson commented May 29, 2017 via email

maggu2810 commented May 29, 2017

cdjackson commented May 29, 2017 via email

kaikreuzer commented May 29, 2017

maggu2810 commented May 29, 2017

svilenvul May 31, 2017

maggu2810 May 31, 2017

kaikreuzer May 31, 2017

maggu2810 May 31, 2017

kaikreuzer May 31, 2017

maggu2810 May 31, 2017

svilenvul Jun 2, 2017

kaikreuzer Jun 2, 2017

svilenvul Jun 2, 2017

kaikreuzer commented Jun 1, 2017

cdjackson commented Jun 2, 2017 via email

kaikreuzer commented Jun 2, 2017

cdjackson commented Jun 2, 2017 via email

kaikreuzer commented Jul 24, 2017

Initial commit of Bluetooth binding and Bluetooth transport bundles #3531

Initial commit of Bluetooth binding and Bluetooth transport bundles #3531

Conversation

maggu2810 commented May 29, 2017 • edited Loading

cdjackson commented May 29, 2017 via email

maggu2810 commented May 29, 2017

cdjackson commented May 29, 2017 via email

kaikreuzer commented May 29, 2017

maggu2810 commented May 29, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaikreuzer commented Jun 1, 2017

cdjackson commented Jun 2, 2017 via email

kaikreuzer commented Jun 2, 2017

cdjackson commented Jun 2, 2017 via email

kaikreuzer commented Jul 24, 2017

maggu2810 commented May 29, 2017 •

edited

Loading