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

Bluetooth Smart binding #2489

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@vkolotov

vkolotov commented Jul 24, 2017

Hello,

I've been working on a new binding for bluetooth devices. I hope it will be useful for the OH community. I have put around 6 months of my effort creating stable and usable binding for Bluetooth devices. This includes developing some support sub-projects, e.g.:

Due to the nature of the Bluetooth protocol, I've sent a lot of my time making it more robust and stable. I believe, I have achieved reasonable robustness of the binding. However, this is just a beginning, there is a huge-huge room for improvements and new features.

I have tested this binding on raspberry pi platform, the requirements for running this binding would be:

  • Linux based system (due to the dependency of Bluez framework)
  • Bluez v5.43 (probably newer versions are supported as well)

There is not any way to support windows environment at the moment. However, I have implemented reasonable abstraction layer in the "bluetooth manager" project in order to be able to add support for windows/MAC environments.

Here is a short description of what the binding can do:

New binding: Bluetooth Smart binding

A binding for Bluetooth devices.

Supports the following features:

  • Automatic discovery of Bluetooth adapters and devices
  • Managing Bluetooth adapters (multiple adapters supported)
  • Monitoring availability of Bluetooth devices (whether they are in range of bluetooth adapters)
  • Comprehensive support for BLE enabled (Bluetooth Smart) Bluetooth devices. Mapping Bluetooth GATT services/characteristics/fields into openhab channels.
  • Robustness in maintaining connectivity (automatic connection recovery)

This is just a short list of features the binding supports at the moment. The main goal of this project was to add support for Bluetooth GATT protocol. This would allow using BLE enabled devices as much as zigbee devices in home automation. The binding possibly supports 95% of the existing official GATT specifications (although only limited number of devices was tested). For a complete list have a look at this list: https://www.bluetooth.com/specifications/gatt/services
For example, you can add a BLE hart rate sensor to OH and see its reading as the blinding channels, e.g. like that one: https://www.dcrainmaker.com/2012/01/wahoo-fitness-blue-hr-bluetooth-low.html. Apart from the support for existing GATT specifications/devices, the binding allows adding support for custom built BLE enabled devices, this is a good alternative to create your own cheap devices/sensors like door/windows sensors, presence sensors etc (similar to zigbee sensors). A good candidate for a platform to create your own BLE sensor would be nrf51822 chip, e.g.

@kaikreuzer ^^

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Jul 24, 2017

I see that there are 16 issues related to "Signed-off-by"... I have tried to edit git history to add "Signed-off-by" bit to the messages, but due to nature of git it was not successful. Some commits are too old and this is not very easy to change commit messages for them because of a lot of changes being made by other member... I'm not sure what I can do here to fix that.

vkolotov commented Jul 24, 2017

I see that there are 16 issues related to "Signed-off-by"... I have tried to edit git history to add "Signed-off-by" bit to the messages, but due to nature of git it was not successful. Some commits are too old and this is not very easy to change commit messages for them because of a lot of changes being made by other member... I'm not sure what I can do here to fix that.

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Jul 25, 2017

Member

Hi @vkolotov, this looks like some amazing work!
It seems though that you have missed that there was substantial work on BLE (BT Smart) support over the past months by @cdjackson already - see eclipse/smarthome#3633, eclipse/smarthome#3531 and eclipse/smarthome#551.

It would be awesome if we could manage to merge your work and expertise with that existing work. I see that you are using TinyB as a lib for communication - this could probably be refactored to become a BLE bridge according to this architecture.

Could you be so kind and check if you think that your work could be contributed to the existing PRs? This would be very much appreciated!

Member

kaikreuzer commented Jul 25, 2017

Hi @vkolotov, this looks like some amazing work!
It seems though that you have missed that there was substantial work on BLE (BT Smart) support over the past months by @cdjackson already - see eclipse/smarthome#3633, eclipse/smarthome#3531 and eclipse/smarthome#551.

It would be awesome if we could manage to merge your work and expertise with that existing work. I see that you are using TinyB as a lib for communication - this could probably be refactored to become a BLE bridge according to this architecture.

Could you be so kind and check if you think that your work could be contributed to the existing PRs? This would be very much appreciated!

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Jul 25, 2017

Hi @kaikreuzer,
It is a bit sad to know that there was some work on the same component at the same time. I spent a lot of my time making it robust/flexible as much as possible (probably around 6-9 months worth of my free time).
Here is an outline of the architecture of the BluetoothSmart binding.
bluetooth-smart-binding

I had a look at the diagram you have referred to. It mostly makes sense to me. However it looks to me a bit "enterprisy"...

The thing is that, the central part of my binding is the "Bluetooth Manager" and the "GATT parser".
The Bluetooth Manger is a self-contained project (API), the main goal of that project is to make Bluetooth protocol to be robust as much as it is possible. It manages bluetooth adapters and devices in that way that it can recover their state any time, e.g. after a crash or intermittent disconnections etc (even after physically disconnection of a bluetooth adapter). The biggest challenge of that project was to smooth and streamline very unstable by its nature Bluetooth protocol.
The GATT Parser is a project (API) that knows how to deal with GATT specifications. It can automatically parse binary data from GATT characteristics into user-friendly formats, e.g. list of GATT fields with their values.

The BluetoothSmart binding is just a wrapper around those projects, in other words it is just a "view" of those two controllers/models.

vkolotov commented Jul 25, 2017

Hi @kaikreuzer,
It is a bit sad to know that there was some work on the same component at the same time. I spent a lot of my time making it robust/flexible as much as possible (probably around 6-9 months worth of my free time).
Here is an outline of the architecture of the BluetoothSmart binding.
bluetooth-smart-binding

I had a look at the diagram you have referred to. It mostly makes sense to me. However it looks to me a bit "enterprisy"...

The thing is that, the central part of my binding is the "Bluetooth Manager" and the "GATT parser".
The Bluetooth Manger is a self-contained project (API), the main goal of that project is to make Bluetooth protocol to be robust as much as it is possible. It manages bluetooth adapters and devices in that way that it can recover their state any time, e.g. after a crash or intermittent disconnections etc (even after physically disconnection of a bluetooth adapter). The biggest challenge of that project was to smooth and streamline very unstable by its nature Bluetooth protocol.
The GATT Parser is a project (API) that knows how to deal with GATT specifications. It can automatically parse binary data from GATT characteristics into user-friendly formats, e.g. list of GATT fields with their values.

The BluetoothSmart binding is just a wrapper around those projects, in other words it is just a "view" of those two controllers/models.

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Jul 25, 2017

Funny thing is that I have just noticed that your component diagram reflects my diagram, they are very similar in terms of composition of components (bindings, abstractions, protocol etc). However, it looks like your approach is missing the very important pieces/components which should be responsible for GATT specs reading and making everything robust.

vkolotov commented Jul 25, 2017

Funny thing is that I have just noticed that your component diagram reflects my diagram, they are very similar in terms of composition of components (bindings, abstractions, protocol etc). However, it looks like your approach is missing the very important pieces/components which should be responsible for GATT specs reading and making everything robust.

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Jul 25, 2017

Ah. Forgot to add that discovery feature is also implemented in the BluetoothSmart binding (for adapters and devices), to be more precise it is done through the Bluetooth Manager. The binding is just listening to the manager and adds/removes things for discovered adapters/devices.

vkolotov commented Jul 25, 2017

Ah. Forgot to add that discovery feature is also implemented in the BluetoothSmart binding (for adapters and devices), to be more precise it is done through the Bluetooth Manager. The binding is just listening to the manager and adds/removes things for discovered adapters/devices.

@davidgraeff

This comment has been minimized.

Show comment
Hide comment
@davidgraeff

davidgraeff Jul 27, 2017

Member

You should squash the commits into one:

  • git rebase -i HEAD~16
  • And select "s" for all except the first commit

And then sign the last commit with

  • git commit --amend -sS

Usually you communicate in the forum or with a WIP work in progress PR that you are working on a feature. Now there are two implementations and both parties have to agree on the final architecture first.

Member

davidgraeff commented Jul 27, 2017

You should squash the commits into one:

  • git rebase -i HEAD~16
  • And select "s" for all except the first commit

And then sign the last commit with

  • git commit --amend -sS

Usually you communicate in the forum or with a WIP work in progress PR that you are working on a feature. Now there are two implementations and both parties have to agree on the final architecture first.

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Jul 27, 2017

Member

It is a bit sad to know that there was some work on the same component at the same time.

Yes, that's really a shame for everyone :-( To avoid such situations, should we make this paragraph more prominent in some way...?

Funny thing is that I have just noticed that your component diagram reflects my diagram, they are very similar in terms of composition of components

Which is a good things as it proves that we seem to be on the right track ;-)

it looks like your approach is missing the very important pieces/components which should be responsible for GATT specs reading and making everything robust.

It wasn't meant to be complete, and I myself am not deep into BLE details - @cdjackson is the master there and probably can best judge how the GATT parsing could fit in. And as you can see, it is still work in progress, so everything is open for discussion and any help is highly appreciated.

The BluetoothSmart binding is just a wrapper around those projects

This is actually making the development and maintenance much more complicated - I very much prefer to have the sources directly in the binding, so that it is easy for everyone to debug, fix and contribute. Included binaries make the whole update & release process much more complicated. Imho, included binaries should mainly be restricted to widespread and stable libs where no regular updates are necessary and where it is clear that people use it in other contexts.

You should squash the commits into one

This is only required once we are close to a merge. In this case, I anyhow very much prefer to have the binding over at ESH, so I hope that @vkolotov and @cdjackson agree to work together on merging their work there. Even if it means a lot of effort for the start, I am convinced that it will pay off on the long run as Bluetooth will be a widely used features and the number of contributors on such a binding will also increase over time for sure. @vkolotov & @cdjackson Can we count on you to get that resolved?

Member

kaikreuzer commented Jul 27, 2017

It is a bit sad to know that there was some work on the same component at the same time.

Yes, that's really a shame for everyone :-( To avoid such situations, should we make this paragraph more prominent in some way...?

Funny thing is that I have just noticed that your component diagram reflects my diagram, they are very similar in terms of composition of components

Which is a good things as it proves that we seem to be on the right track ;-)

it looks like your approach is missing the very important pieces/components which should be responsible for GATT specs reading and making everything robust.

It wasn't meant to be complete, and I myself am not deep into BLE details - @cdjackson is the master there and probably can best judge how the GATT parsing could fit in. And as you can see, it is still work in progress, so everything is open for discussion and any help is highly appreciated.

The BluetoothSmart binding is just a wrapper around those projects

This is actually making the development and maintenance much more complicated - I very much prefer to have the sources directly in the binding, so that it is easy for everyone to debug, fix and contribute. Included binaries make the whole update & release process much more complicated. Imho, included binaries should mainly be restricted to widespread and stable libs where no regular updates are necessary and where it is clear that people use it in other contexts.

You should squash the commits into one

This is only required once we are close to a merge. In this case, I anyhow very much prefer to have the binding over at ESH, so I hope that @vkolotov and @cdjackson agree to work together on merging their work there. Even if it means a lot of effort for the start, I am convinced that it will pay off on the long run as Bluetooth will be a widely used features and the number of contributors on such a binding will also increase over time for sure. @vkolotov & @cdjackson Can we count on you to get that resolved?

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Jul 27, 2017

Hi @kaikreuzer @davidgraeff, thanks for your replies.

I am definitely keen to contribute and merge my stuff with @cdjackson binding.

Yes, that's really a shame for everyone :-( To avoid such situations, should we make this paragraph more prominent in some way...?

I'm afraid, I've started that binding before that "contribution" page was published. I can be wrong though, but anyway I have not seen that page before. However I did searched for any work being done in OH forums... I remember there was only one bluetooth binding PR which was abandoned by its author.

I had a look and tried to build/deploy @cdjackson binding (looks like I need a BlueGiga dongle to make it working). It mostly makes sense to me. It is nicely designed and I can see reasonable level of components composition etc. However, I do see some possible issues with that approach, from the very first glance these are ( @cdjackson please correct me if I'm wrong):

  • Bluetooth dongles can connect only limited number of bluetooth devices, so multiple dongles should be supported in order to allow users to use all required bluetooth devices at the same time
  • The nature of GATT protocol (specification) is that in many cases (for many bluetooth devices) it does not require any "specific" code implementations. In other words, if a bluetooth device follows a GATT specification, then by knowing that specification it is easy to figure out what data you can access, what format of that data and how you can access that data (e.g. direct reading or through GATT notification mechanism). Same for writing data. The binding I have implemented is a "generic". It does not implement any specific algorithms or logic. Users are allowed to connect to any device, see what channels they have and use them as is. For example, If I connect a generic hart rate sensor, I can see a channel "Heart Rate" in human-readable format.
  • The nature of the bluetooth is "instability". This means that you have to be prepared to see a lot of disconnections, reconnections etc. So, the binding must be robust enough, e.g. recover its state, look after connections, restore state of bluetooth devices etc. This is a real challenge. I have addressed this in my "BluetoothManager" project.

This is actually making the development and maintenance much more complicated - I very much prefer to have the sources directly in the binding, so that it is easy for everyone to debug, fix and contribute. Included binaries make the whole update & release process much more complicated. Imho, included binaries should mainly be restricted to widespread and stable libs where no regular updates are necessary and where it is clear that people use it in other contexts.

GATT Parser and BluetothManager projects are opensource and reasonably documented (although some documentation is required for BM) and unittested (Parser - 100% coverage, BM - 60-70%). I can't say it is flawless and bugless, but I believe I achieved some good results in stability. These projects are generic enough to be used everywhere, so anyone can contribute. They are also accessible as maven dependencies from the maven central repo. I do not see any issues in integrating them into OH honestly speaking.

I was going to draw up a diagram depicting my vision of how we could merge our stuff together. I'll need to have more time for analysis. Once I have that done, would you @kaikreuzer @cdjackson be able to discuss this over the phone or in skype?

vkolotov commented Jul 27, 2017

Hi @kaikreuzer @davidgraeff, thanks for your replies.

I am definitely keen to contribute and merge my stuff with @cdjackson binding.

Yes, that's really a shame for everyone :-( To avoid such situations, should we make this paragraph more prominent in some way...?

I'm afraid, I've started that binding before that "contribution" page was published. I can be wrong though, but anyway I have not seen that page before. However I did searched for any work being done in OH forums... I remember there was only one bluetooth binding PR which was abandoned by its author.

I had a look and tried to build/deploy @cdjackson binding (looks like I need a BlueGiga dongle to make it working). It mostly makes sense to me. It is nicely designed and I can see reasonable level of components composition etc. However, I do see some possible issues with that approach, from the very first glance these are ( @cdjackson please correct me if I'm wrong):

  • Bluetooth dongles can connect only limited number of bluetooth devices, so multiple dongles should be supported in order to allow users to use all required bluetooth devices at the same time
  • The nature of GATT protocol (specification) is that in many cases (for many bluetooth devices) it does not require any "specific" code implementations. In other words, if a bluetooth device follows a GATT specification, then by knowing that specification it is easy to figure out what data you can access, what format of that data and how you can access that data (e.g. direct reading or through GATT notification mechanism). Same for writing data. The binding I have implemented is a "generic". It does not implement any specific algorithms or logic. Users are allowed to connect to any device, see what channels they have and use them as is. For example, If I connect a generic hart rate sensor, I can see a channel "Heart Rate" in human-readable format.
  • The nature of the bluetooth is "instability". This means that you have to be prepared to see a lot of disconnections, reconnections etc. So, the binding must be robust enough, e.g. recover its state, look after connections, restore state of bluetooth devices etc. This is a real challenge. I have addressed this in my "BluetoothManager" project.

This is actually making the development and maintenance much more complicated - I very much prefer to have the sources directly in the binding, so that it is easy for everyone to debug, fix and contribute. Included binaries make the whole update & release process much more complicated. Imho, included binaries should mainly be restricted to widespread and stable libs where no regular updates are necessary and where it is clear that people use it in other contexts.

GATT Parser and BluetothManager projects are opensource and reasonably documented (although some documentation is required for BM) and unittested (Parser - 100% coverage, BM - 60-70%). I can't say it is flawless and bugless, but I believe I achieved some good results in stability. These projects are generic enough to be used everywhere, so anyone can contribute. They are also accessible as maven dependencies from the maven central repo. I do not see any issues in integrating them into OH honestly speaking.

I was going to draw up a diagram depicting my vision of how we could merge our stuff together. I'll need to have more time for analysis. Once I have that done, would you @kaikreuzer @cdjackson be able to discuss this over the phone or in skype?

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Jul 27, 2017

Re GATT parsing: Just so we all know how it looks like:
image
You can see there two USB Bluetooth adapters - both on top.
nRF5x - is a custom made Bluetooth device (a door lock).
Wahoo HRM - is a generic heart rate sensor (a chest strap).

These devices were added as a result of the OH discovery service. The main thing about that is: There is absolutely NO custom java code to handle readings from those devices, e.g. all those channels you see on the screen are GATT characteristics / fields which have been automatically parsed by the GATT Parser. Write operations are supported as well.

Have a close look at the "Wahoo" device, it's got "Heart Rate Measurement/Heart Rate Measurement Value (uint8)" OH item is the readings from the device, they are updated in real time and pushed to OH via GATT notification mechanism.

And this is the discovery screen:
image

Which lists all bluetooth adapters/devices ready to be added to OH.

@kaikreuzer @cdjackson ^^

vkolotov commented Jul 27, 2017

Re GATT parsing: Just so we all know how it looks like:
image
You can see there two USB Bluetooth adapters - both on top.
nRF5x - is a custom made Bluetooth device (a door lock).
Wahoo HRM - is a generic heart rate sensor (a chest strap).

These devices were added as a result of the OH discovery service. The main thing about that is: There is absolutely NO custom java code to handle readings from those devices, e.g. all those channels you see on the screen are GATT characteristics / fields which have been automatically parsed by the GATT Parser. Write operations are supported as well.

Have a close look at the "Wahoo" device, it's got "Heart Rate Measurement/Heart Rate Measurement Value (uint8)" OH item is the readings from the device, they are updated in real time and pushed to OH via GATT notification mechanism.

And this is the discovery screen:
image

Which lists all bluetooth adapters/devices ready to be added to OH.

@kaikreuzer @cdjackson ^^

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Jul 27, 2017

In HabPanel this could be configured as this:
image

vkolotov commented Jul 27, 2017

In HabPanel this could be configured as this:
image

@cdjackson

This comment has been minimized.

Show comment
Hide comment
@cdjackson

cdjackson Jul 27, 2017

Contributor
Contributor

cdjackson commented Jul 27, 2017

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Jul 27, 2017

Member

You are awesome, guys, thanks a lot! Looking forward to the world best Bluetooth binding :-)

looks like I need a BlueGiga dongle to make it working

No, if you check the architecture diagram, BlueGiga is just the newly introduced option to be able to develop and test on anything else than Linux. Additionally, there is BlueZ over DBUS support as well. To make it work, you also need the ESH dbus transport bundle, which isn't (yet) part of the openHAB distro.

I would suggest that you look at writing a BlueZ layer.

@cdjackson What do you mean exactly here? This is already in place, isn't it?
Btw, @vkolotov's is using TinyB, which also goes through DBUS to BlueZ.

I do not see any issues in integrating them into OH honestly speaking.

If they are indeed more or less complete and stable (congrats on the test coverage 👍), I agree. There is only an issue if it is code under development, which might see regular updates and contributions by others. The Eclipse Foundation handles IP checks very thoroughly and every update of an external lib is a considerable effort for the project maintainers. For this reason, I would only say that it isn't an issue if we expect less than one update of the lib per year.

Member

kaikreuzer commented Jul 27, 2017

You are awesome, guys, thanks a lot! Looking forward to the world best Bluetooth binding :-)

looks like I need a BlueGiga dongle to make it working

No, if you check the architecture diagram, BlueGiga is just the newly introduced option to be able to develop and test on anything else than Linux. Additionally, there is BlueZ over DBUS support as well. To make it work, you also need the ESH dbus transport bundle, which isn't (yet) part of the openHAB distro.

I would suggest that you look at writing a BlueZ layer.

@cdjackson What do you mean exactly here? This is already in place, isn't it?
Btw, @vkolotov's is using TinyB, which also goes through DBUS to BlueZ.

I do not see any issues in integrating them into OH honestly speaking.

If they are indeed more or less complete and stable (congrats on the test coverage 👍), I agree. There is only an issue if it is code under development, which might see regular updates and contributions by others. The Eclipse Foundation handles IP checks very thoroughly and every update of an external lib is a considerable effort for the project maintainers. For this reason, I would only say that it isn't an issue if we expect less than one update of the lib per year.

@cdjackson

This comment has been minimized.

Show comment
Hide comment
@cdjackson

cdjackson Jul 27, 2017

Contributor

I would suggest that you look at writing a BlueZ layer.

@cdjackson What do you mean exactly here? This is already in place, isn't it?

No - not for the latest API. By this, I mean that we would still need to implement the layer that handles the 'dongle' (transport) interface. This should link to BlueZ through DBus which I would guess is what this binding does (but I've not had time to look at the code). So we'd need an implementation of the BleBridgeApi for BlueZ.

Contributor

cdjackson commented Jul 27, 2017

I would suggest that you look at writing a BlueZ layer.

@cdjackson What do you mean exactly here? This is already in place, isn't it?

No - not for the latest API. By this, I mean that we would still need to implement the layer that handles the 'dongle' (transport) interface. This should link to BlueZ through DBus which I would guess is what this binding does (but I've not had time to look at the code). So we'd need an implementation of the BleBridgeApi for BlueZ.

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Jul 28, 2017

Member

No - not for the latest API.

Hm, ok - I completely missed that your latest PR dropped that feature (which was one of the major developments of your previous work...)

This should link to BlueZ through DBus which I would guess is what this binding does

Be careful: What we need in ESH is what you had implemented: DBus access either through IP or alternatively through JNI.
This binding here uses the Intel TinyB library, which comes with its own JNI way to access BlueZ through DBUS. This could be used as another BleBridgeApi implementation, but I would very much hope that you can port your previous work to the new architecture.

Member

kaikreuzer commented Jul 28, 2017

No - not for the latest API.

Hm, ok - I completely missed that your latest PR dropped that feature (which was one of the major developments of your previous work...)

This should link to BlueZ through DBus which I would guess is what this binding does

Be careful: What we need in ESH is what you had implemented: DBus access either through IP or alternatively through JNI.
This binding here uses the Intel TinyB library, which comes with its own JNI way to access BlueZ through DBUS. This could be used as another BleBridgeApi implementation, but I would very much hope that you can port your previous work to the new architecture.

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Aug 3, 2017

Hi @kaikreuzer @cdjackson, I have been thinking about how we can merge our work. Here is what I can propose.

I believe it is definitely possible to merge our efforts, however some modifications are required.

Here is what I think might be our KPIs:

  1. Flexibility in using different transports, e.g. serial port, DBus or any other (like tinyb).
  2. Extensibility in adding new supported devices (new OH addons), e.g. different sensors and other hardware.
  3. Robustness. Due to the nature of the Bluetooth protocol, we will have to make our bindings stable enough so that people could use it. This is the biggest challenge from my perspective.
  4. Comprehensive support for Bluetooth GATT specifications. This is a very powerfull feature which would allow users:
    • add any device which conforms GATT specification whithout developing any new binding
    • add custom made devices by only specifying a path to custom defined GATT specification for a device

Before I get down to some OH details, one more time I'd like to explain some important components I have already implemented.

  1. Bluetooth URL
    bluetooth url

This is a very useful component which allows us to identify any BT resource. It is similar to @cdjackson
BluetoothAddress, but it also supports locating BT adapters, services, characteristics and GATT fields. Even if multiple adapters are used, the URL can precisely identify resource of a BT device. That class is reasonably documented, so take a look at the comments in the file for more info.

Please note that "protocol" part is not yet implemented.

The Bluetooth URL can help us to address Flexibility and Extensibility KPIs.

  1. Transport abstraction layer
    transport abstraction layer

This is an API which is supposed to provide an abstraction layer between hardware and OpenHab. The API provides common interfaces for BT adapter, device, GATT service, GATT characteristic. It also supports plugging in different implementations for different transport types, such us serial port transport or BDus transport. In order to do so, a new transport layer must implement a limited number (actually only 4 interfaces, an example here) of interfaces.

This abstraction layer can help us to address Flexibility and partially Robustness.

As a first step, I would leave TinyB transport as a main transport for linux based set-ups, however I agree that this should be converted to be using native DBus adapter. I can even suggest a good candidate for this work - hypfvieh. I had a chat with David a couple of months ago, he might be interested in this.

  1. Bluetooth Manager
    bluetooth manager

It is a set of APIs and processes which are responsible for robustness of the system. The central part of it is "Governors" (examples and more info BluetoothGovernor, AdapterGovernor, DeviceGovernor and BluetoothManager). These are components which define lifecycle of BT objects and contain logic for error recovery. They are similar to the transport APIs, but yet different because they are active components, i.e. they implement some logic for each of BT objects (adapter, device, characteristic) that make the system more robust and enable the system to recover from unexpected situations such as disconnections and power outages.

Apart from making the system more stable, the Governors are designed in a such way that they can be used externally, in other words it is another abstraction layer which hides some specifics/difficulties of the BT protocol behind user-friendly APIs.

Obviously the Bluetooth Manager is supposed to help us with Robustness and Extensibility KPIs.

  1. GATT Parser

It is a component which can translate BT raw data into user-friendly format. In short, it reads GATT specifications (xml files) and converts raw data into map of: Field name -> value. Works both ways, e.g. raw data -> fields (read operation) and fields -> raw data (write operation). All complex logic related to bit operations, type conversions, validations etc are hidden in this component. More info here.

This component will allow us to create "generic" OH handlers which can work with any devices that conform GATT specifications OR users can supply their own implementations for GATT specs in XML files to add their own custom made devices.

Now... back to our idea to merge our work. Here is what I can propose:
openhab bluetooth

As you can see that diagram reflects the diagram you pointed out earlier. It is quite similar. There are bundles to add transport, bluetooth binding APIs and some specific binding for a particular device (YeeLightBlue).

The only significant difference is the way how transport is plugged in to OH. In contrast to @cdjackson implementation, the transport implementations are plugged in to Bluetooth Manager via well defined transport APIs. It is different to the approach where the transport is actually an implementation for OH Bridge interface. In my proposition, there is not bridges at all. All adapters are components similar to BT devices which can be discovered, controlled and recovered from error by the BluetoothManager. We could possibly make adapters to be bridges as well, but I can't see any point in doing so.

Another difference is that all OH handlers are supposed to work with the "Governors API" which provides/separates handler specific logic from dealing with BT protocol nasties.

Please note that on the diagram green colour means that it is already implemented (well to certain extend that it can be thought that it is implemented), blue and red colours - something we need to develop/merge. In my mind, the blue components can be implemented/merged by @cdjackson and the red components by me. Of course we all need to put some effort in polishing the green components, however I promise to take the main responsibility in supporting the green stuff.

That's it.

Please let me know what you think. I'm happy to discuss this over the phone or in skype.

Looking forward to seeing your comments.

vkolotov commented Aug 3, 2017

Hi @kaikreuzer @cdjackson, I have been thinking about how we can merge our work. Here is what I can propose.

I believe it is definitely possible to merge our efforts, however some modifications are required.

Here is what I think might be our KPIs:

  1. Flexibility in using different transports, e.g. serial port, DBus or any other (like tinyb).
  2. Extensibility in adding new supported devices (new OH addons), e.g. different sensors and other hardware.
  3. Robustness. Due to the nature of the Bluetooth protocol, we will have to make our bindings stable enough so that people could use it. This is the biggest challenge from my perspective.
  4. Comprehensive support for Bluetooth GATT specifications. This is a very powerfull feature which would allow users:
    • add any device which conforms GATT specification whithout developing any new binding
    • add custom made devices by only specifying a path to custom defined GATT specification for a device

Before I get down to some OH details, one more time I'd like to explain some important components I have already implemented.

  1. Bluetooth URL
    bluetooth url

This is a very useful component which allows us to identify any BT resource. It is similar to @cdjackson
BluetoothAddress, but it also supports locating BT adapters, services, characteristics and GATT fields. Even if multiple adapters are used, the URL can precisely identify resource of a BT device. That class is reasonably documented, so take a look at the comments in the file for more info.

Please note that "protocol" part is not yet implemented.

The Bluetooth URL can help us to address Flexibility and Extensibility KPIs.

  1. Transport abstraction layer
    transport abstraction layer

This is an API which is supposed to provide an abstraction layer between hardware and OpenHab. The API provides common interfaces for BT adapter, device, GATT service, GATT characteristic. It also supports plugging in different implementations for different transport types, such us serial port transport or BDus transport. In order to do so, a new transport layer must implement a limited number (actually only 4 interfaces, an example here) of interfaces.

This abstraction layer can help us to address Flexibility and partially Robustness.

As a first step, I would leave TinyB transport as a main transport for linux based set-ups, however I agree that this should be converted to be using native DBus adapter. I can even suggest a good candidate for this work - hypfvieh. I had a chat with David a couple of months ago, he might be interested in this.

  1. Bluetooth Manager
    bluetooth manager

It is a set of APIs and processes which are responsible for robustness of the system. The central part of it is "Governors" (examples and more info BluetoothGovernor, AdapterGovernor, DeviceGovernor and BluetoothManager). These are components which define lifecycle of BT objects and contain logic for error recovery. They are similar to the transport APIs, but yet different because they are active components, i.e. they implement some logic for each of BT objects (adapter, device, characteristic) that make the system more robust and enable the system to recover from unexpected situations such as disconnections and power outages.

Apart from making the system more stable, the Governors are designed in a such way that they can be used externally, in other words it is another abstraction layer which hides some specifics/difficulties of the BT protocol behind user-friendly APIs.

Obviously the Bluetooth Manager is supposed to help us with Robustness and Extensibility KPIs.

  1. GATT Parser

It is a component which can translate BT raw data into user-friendly format. In short, it reads GATT specifications (xml files) and converts raw data into map of: Field name -> value. Works both ways, e.g. raw data -> fields (read operation) and fields -> raw data (write operation). All complex logic related to bit operations, type conversions, validations etc are hidden in this component. More info here.

This component will allow us to create "generic" OH handlers which can work with any devices that conform GATT specifications OR users can supply their own implementations for GATT specs in XML files to add their own custom made devices.

Now... back to our idea to merge our work. Here is what I can propose:
openhab bluetooth

As you can see that diagram reflects the diagram you pointed out earlier. It is quite similar. There are bundles to add transport, bluetooth binding APIs and some specific binding for a particular device (YeeLightBlue).

The only significant difference is the way how transport is plugged in to OH. In contrast to @cdjackson implementation, the transport implementations are plugged in to Bluetooth Manager via well defined transport APIs. It is different to the approach where the transport is actually an implementation for OH Bridge interface. In my proposition, there is not bridges at all. All adapters are components similar to BT devices which can be discovered, controlled and recovered from error by the BluetoothManager. We could possibly make adapters to be bridges as well, but I can't see any point in doing so.

Another difference is that all OH handlers are supposed to work with the "Governors API" which provides/separates handler specific logic from dealing with BT protocol nasties.

Please note that on the diagram green colour means that it is already implemented (well to certain extend that it can be thought that it is implemented), blue and red colours - something we need to develop/merge. In my mind, the blue components can be implemented/merged by @cdjackson and the red components by me. Of course we all need to put some effort in polishing the green components, however I promise to take the main responsibility in supporting the green stuff.

That's it.

Please let me know what you think. I'm happy to discuss this over the phone or in skype.

Looking forward to seeing your comments.

[bluetoothsmart] WIP: initial contribution
Signed-off-by: Vlad Kolotov <vkolotov@gmail.com>

@vkolotov vkolotov changed the title from New binding: Bluetooth Smart binding to Bluetooth Smart binding Aug 4, 2017

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Aug 7, 2017

Member

Many thanks @vkolotov, sounds all very reasonable to me - imho the direction looks good and thus I will leave it to you and @cdjackson to figure out the details.

Just two questions that came up in my mind when reading your suggestion:

  1. How/where is the "Bluetooth URL" meant to be used? If it is just somewhere in the internals, I don't see a problem with it. It it bubbles up into the "concrete device bindings", I think it breaks the abstraction as the URL contains the concrete transport, etc., while a binding should not need to know, which transport is actually used (and it should actually be possible to reconfigure a "BLE thing" to use another transport without having to change anything else.

  2. Adapters as bridges: The main benefit to model them as bridges is that you can expose them to the user (through configuration or in the UI): If a dongle is plugged in, the user will see a discovery result and can decide whether he wants to use it or not. He can trigger discovery on it and he sees which of his BT devices are connected through which bridge. Also the bridge has a unique id which serves as an abstraction for the transport layer by being part of the Thing UID of the device (see also question 1). So my question would be: Why should the transports NOT be modelled as bridges?

Member

kaikreuzer commented Aug 7, 2017

Many thanks @vkolotov, sounds all very reasonable to me - imho the direction looks good and thus I will leave it to you and @cdjackson to figure out the details.

Just two questions that came up in my mind when reading your suggestion:

  1. How/where is the "Bluetooth URL" meant to be used? If it is just somewhere in the internals, I don't see a problem with it. It it bubbles up into the "concrete device bindings", I think it breaks the abstraction as the URL contains the concrete transport, etc., while a binding should not need to know, which transport is actually used (and it should actually be possible to reconfigure a "BLE thing" to use another transport without having to change anything else.

  2. Adapters as bridges: The main benefit to model them as bridges is that you can expose them to the user (through configuration or in the UI): If a dongle is plugged in, the user will see a discovery result and can decide whether he wants to use it or not. He can trigger discovery on it and he sees which of his BT devices are connected through which bridge. Also the bridge has a unique id which serves as an abstraction for the transport layer by being part of the Thing UID of the device (see also question 1). So my question would be: Why should the transports NOT be modelled as bridges?

@cdjackson

This comment has been minimized.

Show comment
Hide comment
@cdjackson

cdjackson Aug 7, 2017

Contributor

In general I'm not unhappy with the proposed approach and I'm happy to let @vkolotov take the lead on this and I'll pull in the BlueGiga implemenetation. I tried to look over the governer implementation, but the implementation classes that I looked at had no comments/docs (other than at class level in some cases) so it was a bit hard to work through.

Regarding bridges - I also agree with Kai - I would expect adaptors to be exposed to the user as bridges. I don't think that your assumption that these can be discovered and managed internally is valid. This might be fine for BlueZ/Tinyb where there is handling at system level, but if we look at other adaptors (eg BlueGiga) - these are serial ports so I think there needs to be user interaction at this level. Automatically polling all serial devices on a system looking for a specific type of dongle is (IMHO) a bad idea as a) it could block other services trying to use the serial port, and b) it might send data to a device that could cause other problems.

I think it's important to ensure we have a good interface for bindings to directly interact with the device rather than using the GATT parser since from what I've seen so far, the standard GATT services have been of limited use for HA devices (or maybe I've just picked the wrong devices).

So, I'm happy if you want to take the lead on this if you have the time to get it running ;) .

Contributor

cdjackson commented Aug 7, 2017

In general I'm not unhappy with the proposed approach and I'm happy to let @vkolotov take the lead on this and I'll pull in the BlueGiga implemenetation. I tried to look over the governer implementation, but the implementation classes that I looked at had no comments/docs (other than at class level in some cases) so it was a bit hard to work through.

Regarding bridges - I also agree with Kai - I would expect adaptors to be exposed to the user as bridges. I don't think that your assumption that these can be discovered and managed internally is valid. This might be fine for BlueZ/Tinyb where there is handling at system level, but if we look at other adaptors (eg BlueGiga) - these are serial ports so I think there needs to be user interaction at this level. Automatically polling all serial devices on a system looking for a specific type of dongle is (IMHO) a bad idea as a) it could block other services trying to use the serial port, and b) it might send data to a device that could cause other problems.

I think it's important to ensure we have a good interface for bindings to directly interact with the device rather than using the GATT parser since from what I've seen so far, the standard GATT services have been of limited use for HA devices (or maybe I've just picked the wrong devices).

So, I'm happy if you want to take the lead on this if you have the time to get it running ;) .

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Aug 8, 2017

Hi guys, thank you for your feedback. I'm happy to take responsibilities as I'm really keen to make that done as it took for me already more than 6 months.

How/where is the "Bluetooth URL" meant to be used?

That's a good question. I assumed that the "protocol" part can be used to precisely identify transport that a device belongs to, however I do see that we actually can identify type of the transport by looking at an adapter address (MAC). I'll try to develop that idea further, we might not need protocol part at all.

Adapters as bridges

I do not have anything against that. I actually did not know that bridges could appear in the discovery list. Do they appear on the dashboard in paperUI after they have been added as bridges @kaikreuzer ?

I'll pull in the BlueGiga implemenetation

I have also ordered BLED112 adapter, it might help me to understand how serial transport works @cdjackson. I had a look at your project for Bluegiga adapter, it is looking very good.

I tried to look over the governer implementation

I'm trying to tidy it up at the moment, will try to add more comments and unittests.

ensure we have a good interface for bindings to directly interact with the device rather than using the GATT parser

@cdjackson Ah sorry, it was not probably clear... the Gatt Parser is not compulsory, the main interface is the Governors API. The Gatt parser may be used if it is needed. However, I believe we could make it so that developers can feed their own GATT XML files to the Gatt Parser so that it can automatically parse "unknown" characteristics. I believe that feature is very powerful, as it gives the ability to "describe" any BLE device with XML files so that device automatically becomes "known" and can be used as a generic BLE device. In other words, if a bluetooth device is a BLE device, than it can be "described" with custom GATT specification in XML files. That feature would be very useful for some users who build their own custom BLE devices, nowadays it is very easy to do so.

I believe we are more or less on the same page. Here is what I propose as next steps. Let me do some experiments and POC for the proposed architecture. I'm sure it will identify several issues (like inability to discover USB dongles in Windows or incompatibility between transports). I'll let you know how that goes.

vkolotov commented Aug 8, 2017

Hi guys, thank you for your feedback. I'm happy to take responsibilities as I'm really keen to make that done as it took for me already more than 6 months.

How/where is the "Bluetooth URL" meant to be used?

That's a good question. I assumed that the "protocol" part can be used to precisely identify transport that a device belongs to, however I do see that we actually can identify type of the transport by looking at an adapter address (MAC). I'll try to develop that idea further, we might not need protocol part at all.

Adapters as bridges

I do not have anything against that. I actually did not know that bridges could appear in the discovery list. Do they appear on the dashboard in paperUI after they have been added as bridges @kaikreuzer ?

I'll pull in the BlueGiga implemenetation

I have also ordered BLED112 adapter, it might help me to understand how serial transport works @cdjackson. I had a look at your project for Bluegiga adapter, it is looking very good.

I tried to look over the governer implementation

I'm trying to tidy it up at the moment, will try to add more comments and unittests.

ensure we have a good interface for bindings to directly interact with the device rather than using the GATT parser

@cdjackson Ah sorry, it was not probably clear... the Gatt Parser is not compulsory, the main interface is the Governors API. The Gatt parser may be used if it is needed. However, I believe we could make it so that developers can feed their own GATT XML files to the Gatt Parser so that it can automatically parse "unknown" characteristics. I believe that feature is very powerful, as it gives the ability to "describe" any BLE device with XML files so that device automatically becomes "known" and can be used as a generic BLE device. In other words, if a bluetooth device is a BLE device, than it can be "described" with custom GATT specification in XML files. That feature would be very useful for some users who build their own custom BLE devices, nowadays it is very easy to do so.

I believe we are more or less on the same page. Here is what I propose as next steps. Let me do some experiments and POC for the proposed architecture. I'm sure it will identify several issues (like inability to discover USB dongles in Windows or incompatibility between transports). I'll let you know how that goes.

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Aug 9, 2017

Member

Hey @vkolotov, many thanks for taking the lead on this! I am looking forward to see your progress :-)

I'd suggest to do further discussions on eclipse/smarthome#3633 or rather on a new PR at ESH that you can create with a WIP version of the merged codebase.

Just a few final comments here:

however I do see that we actually can identify type of the transport by looking at an adapter address (MAC). I'll try to develop that idea further, we might not need protocol part at all.

My goal would be to not have any transport/adapter specific info in there (and a MAC is specific as well). My point is that the UID of a BLE "Thing" should be just the normal ESH UID scheme: <bindingId>:[<thingtype>]:<bridgeUID>:<ID of device, e.g. its MAC>. It must not matter whether bridgeUID refers to a BlueGiga dongle or to BlueZ via DBUS transport. It should even be possible to replace the bridge by another one.

Do they appear on the dashboard in paperUI after they have been added as bridges

Yes, they appear on the list of "Things". See e.g. the Philips Hue bridge and others.

like inability to discover USB dongles in Windows

Note that discoverability is not mandatory for "Bridges". Check @cdjackson's work on Z-Wave and ZigBee: Both work with USB dongles and in both cases there is no auto-discovery, but the user chooses "add thing" in the Paper UI, selects the dongle type and sets the serial port it is connected to. That is also the main reason why we will need such bridges for BLE as well.

Member

kaikreuzer commented Aug 9, 2017

Hey @vkolotov, many thanks for taking the lead on this! I am looking forward to see your progress :-)

I'd suggest to do further discussions on eclipse/smarthome#3633 or rather on a new PR at ESH that you can create with a WIP version of the merged codebase.

Just a few final comments here:

however I do see that we actually can identify type of the transport by looking at an adapter address (MAC). I'll try to develop that idea further, we might not need protocol part at all.

My goal would be to not have any transport/adapter specific info in there (and a MAC is specific as well). My point is that the UID of a BLE "Thing" should be just the normal ESH UID scheme: <bindingId>:[<thingtype>]:<bridgeUID>:<ID of device, e.g. its MAC>. It must not matter whether bridgeUID refers to a BlueGiga dongle or to BlueZ via DBUS transport. It should even be possible to replace the bridge by another one.

Do they appear on the dashboard in paperUI after they have been added as bridges

Yes, they appear on the list of "Things". See e.g. the Philips Hue bridge and others.

like inability to discover USB dongles in Windows

Note that discoverability is not mandatory for "Bridges". Check @cdjackson's work on Z-Wave and ZigBee: Both work with USB dongles and in both cases there is no auto-discovery, but the user chooses "add thing" in the Paper UI, selects the dongle type and sets the serial port it is connected to. That is also the main reason why we will need such bridges for BLE as well.

@vkolotov

This comment has been minimized.

Show comment
Hide comment
@vkolotov

vkolotov Aug 9, 2017

Hi @kaikreuzer @cdjackson, thanks for your feedback.

Just wondering. Is there any particular reason to do this in ESH? Honestly speaking, I missed that part/time when everyone started to migrate from OH to ESH. What was the reason for this? :)
I see there is some significant work done on the ESH PR, I will try to merge what I can. However, I probably feel more comfortable in creating a new PR which would contain a merging result if you are ok with that @kaikreuzer @cdjackson ? I'll try to transfer everything I can find, e.g. github comments & documentation, and the code of course. One thing we need to decide is the naming convention. What would be the name of our bindings? I used in this PR "BluetoothSmart", @cdjackson uses "ble" (this implies for java package names as well). I don't mind using "ble", what are your preferences?

My point is that the UID of a BLE "Thing" should be just the normal ESH UID scheme: :[]::<ID of device, e.g. its MAC>

I got that, that was in the idea to use adapter MAC address to identify transport. In fact, the binding in this PR uses exactly this approach. I was thinking about if we could support two different transports in the same time, e.g. DBus + TinyB, or any other combination (future proofing).

vkolotov commented Aug 9, 2017

Hi @kaikreuzer @cdjackson, thanks for your feedback.

Just wondering. Is there any particular reason to do this in ESH? Honestly speaking, I missed that part/time when everyone started to migrate from OH to ESH. What was the reason for this? :)
I see there is some significant work done on the ESH PR, I will try to merge what I can. However, I probably feel more comfortable in creating a new PR which would contain a merging result if you are ok with that @kaikreuzer @cdjackson ? I'll try to transfer everything I can find, e.g. github comments & documentation, and the code of course. One thing we need to decide is the naming convention. What would be the name of our bindings? I used in this PR "BluetoothSmart", @cdjackson uses "ble" (this implies for java package names as well). I don't mind using "ble", what are your preferences?

My point is that the UID of a BLE "Thing" should be just the normal ESH UID scheme: :[]::<ID of device, e.g. its MAC>

I got that, that was in the idea to use adapter MAC address to identify transport. In fact, the binding in this PR uses exactly this approach. I was thinking about if we could support two different transports in the same time, e.g. DBus + TinyB, or any other combination (future proofing).

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Aug 10, 2017

Member

I missed that part/time when everyone started to migrate from OH to ESH. What was the reason for this? :)

Check out my (3 year old) blog post.

Having the code at ESH increases its reach as it is not only possible to use with openHAB, but also with other ESH-based solutions. Chris' work was actually originating from non-openHAB use cases. The benefit for everyone is that there will be more people using it and thus also more people contributing fixes and enhancements to it.

However, I probably feel more comfortable in creating a new PR which would contain a merging result if you are ok with that @kaikreuzer @cdjackson ?

Yes, absolutely, this is what I suggested above anyhow. Creating a new PR, you will have control over pushing new commits to it and thus actively working on it.

I don't mind using "ble", what are your preferences?

Good and valid question. You are right that Bluetooth Smart is the marketing term, while BLE is rather technical. But I just found some interesting information in the Bluetooth Brand Guide:

the Bluetooth SIG will phase out all use of the Bluetooth Smart and Bluetooth Smart Ready marks in 2016.
[...] we ask that all licensees [...] cease use of the Bluetooth Smart and Bluetooth Smart Ready marks on or before 1 January 2017 and revert to using the Bluetooth word mark

Sounds to me as if we were best off to simply use "bluetooth" as a binding ID (leaving us with the question what we will do if we want to support Bluetooth Classic one day, but maybe this could have some common ground).

Member

kaikreuzer commented Aug 10, 2017

I missed that part/time when everyone started to migrate from OH to ESH. What was the reason for this? :)

Check out my (3 year old) blog post.

Having the code at ESH increases its reach as it is not only possible to use with openHAB, but also with other ESH-based solutions. Chris' work was actually originating from non-openHAB use cases. The benefit for everyone is that there will be more people using it and thus also more people contributing fixes and enhancements to it.

However, I probably feel more comfortable in creating a new PR which would contain a merging result if you are ok with that @kaikreuzer @cdjackson ?

Yes, absolutely, this is what I suggested above anyhow. Creating a new PR, you will have control over pushing new commits to it and thus actively working on it.

I don't mind using "ble", what are your preferences?

Good and valid question. You are right that Bluetooth Smart is the marketing term, while BLE is rather technical. But I just found some interesting information in the Bluetooth Brand Guide:

the Bluetooth SIG will phase out all use of the Bluetooth Smart and Bluetooth Smart Ready marks in 2016.
[...] we ask that all licensees [...] cease use of the Bluetooth Smart and Bluetooth Smart Ready marks on or before 1 January 2017 and revert to using the Bluetooth word mark

Sounds to me as if we were best off to simply use "bluetooth" as a binding ID (leaving us with the question what we will do if we want to support Bluetooth Classic one day, but maybe this could have some common ground).

[bluetoothsmart] WIP: preparing for the big merge with the parallel PR
Signed-off-by: Vlad Kolotov <vkolotov@gmail.com>
@martinvw

This comment has been minimized.

Show comment
Hide comment
@martinvw

martinvw Sep 7, 2017

Member

@vkolotov should this be marked WIP or should it be reviewed or closed? I assume it's moving towards smarthome?

Member

martinvw commented Sep 7, 2017

@vkolotov should this be marked WIP or should it be reviewed or closed? I assume it's moving towards smarthome?

@kaikreuzer

This comment has been minimized.

Show comment
Hide comment
@kaikreuzer

kaikreuzer Sep 7, 2017

Member

It has already moved, see eclipse/smarthome#4112.

Member

kaikreuzer commented Sep 7, 2017

It has already moved, see eclipse/smarthome#4112.

@kaikreuzer kaikreuzer closed this Sep 7, 2017

@openhab-bot

This comment has been minimized.

Show comment
Hide comment
@openhab-bot

openhab-bot Oct 8, 2017

Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh-is-now-profeffionsl-like-eclipse-ide-framework/34914/1

Collaborator

openhab-bot commented Oct 8, 2017

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh-is-now-profeffionsl-like-eclipse-ide-framework/34914/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment