You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Brad Red Hat <br...@redhat.com> on 2017/01/02 00:37:38 UTC
Karaf IoT
I was looking at the Kura project for future development and a move toward
IoT development. Unfortunately I have several issues with the project which
are not going to be solved by simply becoming a contributor. It made me
wonder if there's been any discussion about a similar project using
Felix/Karaf/Camel/Maven and related plugins? It isn't even that the projects
necessarily need to be competitive. Many things like driver libraries could
be shared. Since the Kura drivers should already bundles repurposing or
simply using them shouldn't be that difficult.
There are a few aspects of a Felix/Karaf/Aries that lend themselves to such
an implementation. The Karaf 4 profiles mechanics are a perfect mechanism
for creating a testable, self-contained application that can be run on a
developers machine during development and then the zip file can be moved to
whatever device one is working with and unzipped. That's about as easy an
installation as I can think of. Since that minimalist karaf 4
implementation is so small and the provisioning is static at compile time it
hits the nail on the head. When I put together a project recently and
included CXF and a number of other libraries the whole thing was about 30MB.
The PAX CDI mechanisms make wiring up beans and routes a lot easier. That
certainly could make writing applications for small devices a lot easier.
Just one simple example from the sample code:
GPIOPinConfig pinConfig = new GPIOPinConfig(
DeviceConfig.DEFAULT,
//GPIO Controller number or name
17,
//GPIO Pin number
GPIOPinConfig.DIR_INPUT_ONLY,
//Pin direction
GPIOPinConfig.MODE_INPUT_PULL_DOWN,
//Pin resistor
GPIOPinConfig.TRIGGER_BOTH_EDGES,
//Triggers
false
//initial value (for outputs)
);
GPIOPin button = (GPIOPin) DeviceManager.open(GPIOPin.class, pinConfig);
Seem to beg for OSGi services (DS or blueprint), annotations, and simple cfg
files. Something like that GPIOPin or even a GPIO connector could really be
injectable OSGi services with all the configuration tucked in the cfg or
with defaults in blueprint properties or DS annotations. Somehow I suspect
the DeviceManager is not a service factory but I didn't dig in. There were
too many parts of the project that really didn't appeal to me.
In any case, there's probably some discussion about this already.
Brad
Re: Karaf IoT
Posted by Jason Pratt <jp...@gmail.com>.
well please keep me in mind when you do sort something out. i am designing
a project now and was looking at both kura and openhab for it
On Wed, Jan 4, 2017 at 12:53 PM, Łukasz Dywicki <lu...@code-house.org> wrote:
> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is
> redundant from my Karaf (as a platform) point of view. But this all comes
> from past of project which was launched with Tycho and PDE since early
> days. There are multiple entities involved in project and it is not an easy
> task to redefine how things should be built.
>
> Initial apis of OH were quite simple and didn’t require anything strictly
> related to physical thing. Starting form OH2 and extraction of Eclipse
> SmartHome there is a seperation of concerns. OH2 bindings define Bridge and
> Things connected over it and may have Channels associated with every of
> these. At this stage it is lowest common denominator. There is no higher
> level APIs for representing pumps, boilers or sensors or alarms but from
> other hand OH is not a SCADA platform. Maybe at some point there will be
> further generalization of code which will allow bindings to gain some
> benefits? Many of bindings is pure software integration with vendor bridges
> having very little or no hardware involved at all which makes it easier to
> develop.
>
> I haven’t played with Kura so far because I didn’t need such low level
> library, but even if I would need something such that I would rather go for
> dedicated library handling specific use case instead of Kura which brings
> too much.
>
> Kind regards,
> Lukasz
> --
> Apache Karaf Committer & PMC
> Twitter: @ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
> > Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o
> godz. 19:56:
> >
> > I share most of Brad's concerns; at first I was very interested in
> OpenHAB
> > but after playing with it for a bit I began to think about designing a
> new
> > service layer and then seeing if I could fit the OpenHAB native libraries
> > to it.
> >
> > OpenHAB corroborates my "PDE considered harmful" theory; it must be
> > possible to use OSGi idioms effectively while developing in Eclipse PDE,
> > but it doesn't seem to happen in practice.
> >
> > So Brad, I am right with you and I would like to help - but I am
> seriously
> > short of time at the moment :-(
> >
> >
> >
> >
>
>
RE: Karaf IoT
Posted by Brad Johnson <br...@redhat.com>.
I agree. Hopefully I'll have some time in the future and will be able to make a convincing argument for it in the Kura group. Time being what it is...
If I make a quad helicopter or industrial valve controller, I don't want to provide configurations in consumer bundles for every possible controller board out there with intimate knowledge of the pin outs of that board. What I want is the named pin of the correct type. That means I'd have to create the properties configuration for a number of different board types but it would be limited to that single configuration file for the boards. Everything consuming from that would be at an appropriate level of abstraction that doesn't care about the board level details. The motor controller needs a GPIODigitalPWMPin of with a configurable name identifier to connect the service exported from the board to the consumer motor controller. If I have four motor controllers for my quad copter, then in like fashion I want to export the motor controllers with appropriate identifiers - "left front, left rear, right front, right rear" that my controller logic can consume. That higher level logic isn't concerned about pulse widths to the pins, just some percent power or other appropriate metric. The motor controller, doesn't care about the board level configuration details and pin outs, it simply wants to set a pulse width to a certain value. The board level configuration then has the details about what pin that pulse width is routed to. Services are exported out for higher level consumption, control signals flow down the abstractions to the lower levels.
The same level of abstraction would be true for sensors but the signals would travel up from pins to sensor controllers up to higher level logic that would know what the meaning of the sensor value is. The physical sensor sends a voltage high on a given pin, the board configuration has exported some pin as a certain type with a given name, the controller logic for the sensor references that pin and interprets it to some meaning (perhaps a level for the given sensor type), the higher level logic interprets that as "holy, sh*t there's an overpressure condition in the turbine." If the pin can't send events, then the sensor controller might poll the pin and fire events making no assumptions about what the receiving logic is about.
Those levels of abstraction would permit use of multiple board types for sensors and actuators. Standardizing those exports would permit standardizing service interfaces for different types of sensors and actuators. That would permit manufacturers of various types of sensors and actuators to create a single controller for their component that receives the appropriate pin type of a given ID and then exports a given interface for upstream use. MotorController, LED, RFIDSensor, etc. could all become standardized interfaces then that disparate manufacturers could use to provide those capabilities to their clients.
-----Original Message-----
From: chris.gray@kiffer.ltd.uk [mailto:chris.gray@kiffer.ltd.uk]
Sent: Sunday, January 15, 2017 3:21 PM
To: user@karaf.apache.org
Subject: RE: Karaf IoT
In my current project I am using the "DS multiton" pattern for GPIO pins, that is to say: I have a configuration-required component with the name "gpio.pin.factory", which registers a GpioPin service, and I have an immediate "configurator" component which reads a set of configurations from (somewhere) and feeds them to Configuration Admin with the PID "gpio.pin.factory". Some things I like about this:
- on the target the "gpio.pin.factory" component is a façade for the native library, for testing on the development host I have a completely different implementation which also calls itself "gpio.pin.factory".
- there is no need for a "GpioManager" service, any component can get a reference to a pin via DS, or even create or configure one via CM. (In fact I have a service component with this name, but it's just for convenience).
- it doesn't matter how a peripheral is connected and whether it is configured statically or discovered dynamically, consumer bundles subscribe to it in exactly the same way. For example if I added a component to support some USB-connected GPIOs, when you plugged these in they would take their place next to the built-in GPIOs.
Hm, that pretty much boils down to "what I like about OSGi and DS". :-) But I really think it is worthwhile to do things this way, with the peripherals as first-class citizens (i.e. services) and the configuration/discovery mechanism working behind the scenes, as opposed to the factory-centered approach.
> Yes, that is more along the lines of what I was thinking about. But I
> think that should happen at the Kura board bundle level. If you look
> at the list under Gpio, for example, most of those are interfaces that
> could simply be exported as services from the board's bundle itself.
> The developer would have to identify the service in whatever way is
> appropriate for the consumer bundle to pick up. Switching to another
> board would only entail changing the configuration for that particular
> boards exports.
>
> https://wiki.eclipse.org/Kura_GPIO_Support
>
> Then if I'm writing a motor controller for a device that uses PPM, I
> know that the device I'm writing that for is going to require,
> perhaps, a GpioPinPwmOutput pin. That pin would be configured at the
> board level and exported. On the Rpi it might be a certain pin number
> with certain requirements while on the BananaPi or BeagleBoard it
> might be configured in a different way. But the driver bundle I'm
> writing for my motor doesn't change and isn't aware of that so is
> decoupled from it. The only requirement it would have is for that
> type of pin exported with the correct service identifier.
>
> By contrast, my motor controller bundle will have mappings
> representing a mapping from a standard scale for motor control to the
> correct PPM values for my motor. It will also export its
> MotorControllerService with appropriate identifier for use by the application bundle.
>
> So the configuration and exports stay with the bundles that are
> concerned with the specifics of each level of abstraction.
>
>
> -----Original Message-----
> From: Scott Lewis [mailto:slewis@composent.com]
> Sent: Wednesday, January 4, 2017 8:24 PM
> To: user@karaf.apache.org
> Subject: Re: Karaf IoT
>
>
> I think this tutorial [1] describes something like what you are
> talking about wrt device abstractions and OSGi services...i.e. the
> IGPIOPinOutput services.
>
> Uses ServiceTracker, but would/does work just the same with DS. And
> for bonus...these services can easily remoted without being bound to a
> transport [2].
>
> FWIW, I agree with you that it often will/does makes sense to define
> 'OSGi service-based' device abstractions. I also believe layering of
> small/micro services...especially with DS to manage the service
> dependencies...can provide a dynamic and flexible model for IOT
> interaction.
>
> Scott
>
> [1]
> https://wiki.eclipse.org/Tutorial:_Raspberry_Pi_GPIO_with_OSGi_Service
> s
> [2]
> https://wiki.eclipse.org/Tutorial:_OSGi_Remote_Services_for_Raspberry_
> Pi_GPIO
>
>
> On 1/4/2017 4:07 PM, Brad Red Hat wrote:
>> I just wanted to follow this up with a quick comment that might not
>> have been obvious from the previous posts. I think something like a
>> GpioController is the wrong level of abstraction to be exporting as a
>> service from the board level bundles. Those exports should be
>> configured pin or device services. The only place to configure all
>> the pins/devices for a given implementation remain with the board's bundle.
>> Switch the board you are using and you simply modify the boards pin
>> configuration service exports from that board's bundle to match what
>> is required. All actuator and sensor bundles that use those pins
>> simply work without modification. All the application level bundles
>> that use the exported services from the actuators and sensors
>> continue to work as well.
>>
>> Configuration details remain consolidated at the levels which require
>> them.
>>
>> -----Original Message-----
>> From: Åukasz Dywicki [mailto:luke@code-house.org]
>> Sent: Wednesday, January 4, 2017 4:25 PM
>> To: user@karaf.apache.org
>> Subject: Re: Karaf IoT
>>
>> Brad,
>> If you have service dependant on presence of some board you can make
>> it conditional. Just use OSGi service lifecycle to deregister service
>> when device is disconnected. Service consumers should be aware of it
>> or at least should not call injected service any longer. That’s
>> perfect use case for service tracker. While GPIO will physicaly never
>> get disconnected from raspberry the connected device, i2c may go out
>> at any time. Tricky part is how to detect when device goes offline.
>> This can’t be done in general way and I think it needs to be linked
>> with device interactions (tracking link status and when it hangs) or
>> system events, but this brings us back to Kura and native libraries.
>>
>> Cheers,
>> Lukasz
>> --
>> Apache Karaf Committer & PMC
>> Twitter: @ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>>> Wiadomość napisana przez Brad Red Hat <br...@redhat.com> w dniu
>>> 4 sty 2017, o godz. 22:56:
>>>
>>> I'm still doing a bit of head scratching to figure out where I and
>>> OSGi libraries fit in the Kura scheme. Part of the problem is code
>>> samples may not be the best indicator of intended use but they are
>>> what's out there. Here's an example which doesn't fit how I think
>>> about OSGi services. If I switch the board I'm deploy to then my code is broken.
>>> If these were injected as services instead, then this device driver
>>> level bundle would be unaware of the change. Configuring it at the
>>> board bundle level also means that all configuration for pins,
>>> numbers and modes is in a single place.
>>>
>>> Well, I guess I've gone off the beaten path here and shouldn't be
>>> posting any of this to the Karaf forum as it is a tangential concern
>>> here. More to the point here is getting a Karaf deployment mechanism
>>> in place.
>>>
>>> public void activate(ComponentContext componentContext) {
>>> logger.info("Bundle {} is starting...", APP_ID); //A factory call
>>> across class loaders. Even if this is changed to inject
>>> GpioController it doesn't quite work.
>>> GpioController gpioController = GpioFactory.getInstance(); //Pins
>>> and board devices should be configured and exported as named
>>> services at the board level not in the application bundle.
>>> GpioPinDigitalMultipurpose motionSensor =
>>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01,
>>> PinMode.DIGITAL_INPUT); //Ditto
>>> GpioPinDigitalMultipurpose motionStatusLed =
>>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05,
>>> PinMode.DIGITAL_OUTPUT);
>>>
>>> ....
>>> }
>>>
>>>
>>> -----Original Message-----
>>> From: Åukasz Dywicki [mailto:luke@code-house.org]
>>> Sent: Wednesday, January 4, 2017 2:54 PM
>>> To: user@karaf.apache.org
>>> Cc: Markus Rathgeb <ma...@gmail.com>
>>> Subject: Re: Karaf IoT
>>>
>>> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is
>>> redundant from my Karaf (as a platform) point of view. But this all
>>> comes from past of project which was launched with Tycho and PDE
>>> since early days. There are multiple entities involved in project
>>> and it is not an easy task to redefine how things should be built.
>>>
>>> Initial apis of OH were quite simple and didn’t require anything
>>> strictly related to physical thing. Starting form OH2 and extraction
>>> of Eclipse SmartHome there is a seperation of concerns. OH2 bindings
>>> define Bridge and Things connected over it and may have Channels
>>> associated with every of these. At this stage it is lowest common
>>> denominator. There is no higher level APIs for representing pumps,
>>> boilers or sensors or alarms but from other hand OH is not a SCADA
>>> platform. Maybe at some point there will be further generalization
>>> of code which will allow bindings to gain some benefits? Many of
>>> bindings is pure software integration with vendor bridges having
>>> very little or no hardware involved at all which makes it easier to develop.
>>>
>>> I haven’t played with Kura so far because I didn’t need such low
>>> level library, but even if I would need something such that I would
>>> rather go for dedicated library handling specific use case instead
>>> of Kura which brings too much.
>>>
>>> Kind regards,
>>> Lukasz
>>> --
>>> Apache Karaf Committer & PMC
>>> Twitter: @ldywicki
>>> Blog: http://dywicki.pl
>>> Code-House - http://code-house.org
>>>
>>>
>>>> Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty
>>>> 2017, o godz. 19:56:
>>>>
>>>> I share most of Brad's concerns; at first I was very interested in
>>>> OpenHAB but after playing with it for a bit I began to think about
>>>> designing a new service layer and then seeing if I could fit the
>>>> OpenHAB native libraries to it.
>>>>
>>>> OpenHAB corroborates my "PDE considered harmful" theory; it must be
>>>> possible to use OSGi idioms effectively while developing in Eclipse
>>>> PDE, but it doesn't seem to happen in practice.
>>>>
>>>> So Brad, I am right with you and I would like to help - but I am
>>>> seriously short of time at the moment :-(
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
RE: Karaf IoT
Posted by ch...@kiffer.ltd.uk.
In my current project I am using the "DS multiton" pattern for GPIO pins,
that is to say: I have a configuration-required component with the name
"gpio.pin.factory", which registers a GpioPin service, and I have an
immediate "configurator" component which reads a set of configurations
from (somewhere) and feeds them to Configuration Admin with the PID
"gpio.pin.factory". Some things I like about this:
- on the target the "gpio.pin.factory" component is a faade for the
native library, for testing on the development host I have a completely
different implementation which also calls itself "gpio.pin.factory".
- there is no need for a "GpioManager" service, any component can get a
reference to a pin via DS, or even create or configure one via CM. (In
fact I have a service component with this name, but it's just for
convenience).
- it doesn't matter how a peripheral is connected and whether it is
configured statically or discovered dynamically, consumer bundles
subscribe to it in exactly the same way. For example if I added a
component to support some USB-connected GPIOs, when you plugged these in
they would take their place next to the built-in GPIOs.
Hm, that pretty much boils down to "what I like about OSGi and DS". :-)
But I really think it is worthwhile to do things this way, with the
peripherals as first-class citizens (i.e. services) and the
configuration/discovery mechanism working behind the scenes, as opposed to
the factory-centered approach.
> Yes, that is more along the lines of what I was thinking about. But I
> think that should happen at the Kura board bundle level. If you look at
> the list under Gpio, for example, most of those are interfaces that could
> simply be exported as services from the board's bundle itself. The
> developer would have to identify the service in whatever way is
> appropriate for the consumer bundle to pick up. Switching to another board
> would only entail changing the configuration for that particular boards
> exports.
>
> https://wiki.eclipse.org/Kura_GPIO_Support
>
> Then if I'm writing a motor controller for a device that uses PPM, I know
> that the device I'm writing that for is going to require, perhaps, a
> GpioPinPwmOutput pin. That pin would be configured at the board level and
> exported. On the Rpi it might be a certain pin number with certain
> requirements while on the BananaPi or BeagleBoard it might be configured
> in a different way. But the driver bundle I'm writing for my motor
> doesn't change and isn't aware of that so is decoupled from it. The only
> requirement it would have is for that type of pin exported with the
> correct service identifier.
>
> By contrast, my motor controller bundle will have mappings representing a
> mapping from a standard scale for motor control to the correct PPM values
> for my motor. It will also export its MotorControllerService with
> appropriate identifier for use by the application bundle.
>
> So the configuration and exports stay with the bundles that are concerned
> with the specifics of each level of abstraction.
>
>
> -----Original Message-----
> From: Scott Lewis [mailto:slewis@composent.com]
> Sent: Wednesday, January 4, 2017 8:24 PM
> To: user@karaf.apache.org
> Subject: Re: Karaf IoT
>
>
> I think this tutorial [1] describes something like what you are talking
> about wrt device abstractions and OSGi services...i.e. the IGPIOPinOutput
> services.
>
> Uses ServiceTracker, but would/does work just the same with DS. And for
> bonus...these services can easily remoted without being bound to a
> transport [2].
>
> FWIW, I agree with you that it often will/does makes sense to define
> 'OSGi service-based' device abstractions. I also believe layering of
> small/micro services...especially with DS to manage the service
> dependencies...can provide a dynamic and flexible model for IOT
> interaction.
>
> Scott
>
> [1]
> https://wiki.eclipse.org/Tutorial:_Raspberry_Pi_GPIO_with_OSGi_Services
> [2]
> https://wiki.eclipse.org/Tutorial:_OSGi_Remote_Services_for_Raspberry_Pi_GPIO
>
>
> On 1/4/2017 4:07 PM, Brad Red Hat wrote:
>> I just wanted to follow this up with a quick comment that might not have
>> been obvious from the previous posts. I think something like a
>> GpioController is the wrong level of abstraction to be exporting as a
>> service from the board level bundles. Those exports should be
>> configured pin or device services. The only place to configure all the
>> pins/devices for a given implementation remain with the board's bundle.
>> Switch the board you are using and you simply modify the boards pin
>> configuration service exports from that board's bundle to match what is
>> required. All actuator and sensor bundles that use those pins simply
>> work without modification. All the application level bundles that use
>> the exported services from the actuators and sensors continue to work as
>> well.
>>
>> Configuration details remain consolidated at the levels which require
>> them.
>>
>> -----Original Message-----
>> From: \u0141ukasz Dywicki [mailto:luke@code-house.org]
>> Sent: Wednesday, January 4, 2017 4:25 PM
>> To: user@karaf.apache.org
>> Subject: Re: Karaf IoT
>>
>> Brad,
>> If you have service dependant on presence of some board you can make it
>> conditional. Just use OSGi service lifecycle to deregister service when
>> device is disconnected. Service consumers should be aware of it or at
>> least should not call injected service any longer. That\u2019s perfect use
>> case for service tracker. While GPIO will physicaly never get
>> disconnected from raspberry the connected device, i2c may go out at any
>> time. Tricky part is how to detect when device goes offline. This
>> can\u2019t be done in general way and I think it needs to be linked with
>> device interactions (tracking link status and when it hangs) or system
>> events, but this brings us back to Kura and native libraries.
>>
>> Cheers,
>> Lukasz
>> --
>> Apache Karaf Committer & PMC
>> Twitter: @ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>>> Wiadomo\u015b\u0107 napisana przez Brad Red Hat <br...@redhat.com> w dniu 4
>>> sty 2017, o godz. 22:56:
>>>
>>> I'm still doing a bit of head scratching to figure out where I and OSGi
>>> libraries fit in the Kura scheme. Part of the problem is code samples
>>> may not be the best indicator of intended use but they are what's out
>>> there. Here's an example which doesn't fit how I think about OSGi
>>> services. If I switch the board I'm deploy to then my code is broken.
>>> If these were injected as services instead, then this device driver
>>> level bundle would be unaware of the change. Configuring it at the
>>> board bundle level also means that all configuration for pins, numbers
>>> and modes is in a single place.
>>>
>>> Well, I guess I've gone off the beaten path here and shouldn't be
>>> posting any of this to the Karaf forum as it is a tangential concern
>>> here. More to the point here is getting a Karaf deployment mechanism in
>>> place.
>>>
>>> public void activate(ComponentContext componentContext) {
>>> logger.info("Bundle {} is starting...", APP_ID); //A factory call
>>> across class loaders. Even if this is changed to inject GpioController
>>> it doesn't quite work.
>>> GpioController gpioController = GpioFactory.getInstance(); //Pins and
>>> board devices should be configured and exported as named services at
>>> the board level not in the application bundle.
>>> GpioPinDigitalMultipurpose motionSensor =
>>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01,
>>> PinMode.DIGITAL_INPUT); //Ditto
>>> GpioPinDigitalMultipurpose motionStatusLed =
>>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05,
>>> PinMode.DIGITAL_OUTPUT);
>>>
>>> ....
>>> }
>>>
>>>
>>> -----Original Message-----
>>> From: \u0141ukasz Dywicki [mailto:luke@code-house.org]
>>> Sent: Wednesday, January 4, 2017 2:54 PM
>>> To: user@karaf.apache.org
>>> Cc: Markus Rathgeb <ma...@gmail.com>
>>> Subject: Re: Karaf IoT
>>>
>>> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is
>>> redundant from my Karaf (as a platform) point of view. But this all
>>> comes from past of project which was launched with Tycho and PDE since
>>> early days. There are multiple entities involved in project and it is
>>> not an easy task to redefine how things should be built.
>>>
>>> Initial apis of OH were quite simple and didn\u2019t require anything
>>> strictly related to physical thing. Starting form OH2 and extraction of
>>> Eclipse SmartHome there is a seperation of concerns. OH2 bindings
>>> define Bridge and Things connected over it and may have Channels
>>> associated with every of these. At this stage it is lowest common
>>> denominator. There is no higher level APIs for representing pumps,
>>> boilers or sensors or alarms but from other hand OH is not a SCADA
>>> platform. Maybe at some point there will be further generalization of
>>> code which will allow bindings to gain some benefits? Many of bindings
>>> is pure software integration with vendor bridges having very little or
>>> no hardware involved at all which makes it easier to develop.
>>>
>>> I haven\u2019t played with Kura so far because I didn\u2019t need such low
>>> level library, but even if I would need something such that I would
>>> rather go for dedicated library handling specific use case instead of
>>> Kura which brings too much.
>>>
>>> Kind regards,
>>> Lukasz
>>> --
>>> Apache Karaf Committer & PMC
>>> Twitter: @ldywicki
>>> Blog: http://dywicki.pl
>>> Code-House - http://code-house.org
>>>
>>>
>>>> Wiadomo\u015b\u0107 napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017,
>>>> o godz. 19:56:
>>>>
>>>> I share most of Brad's concerns; at first I was very interested in
>>>> OpenHAB but after playing with it for a bit I began to think about
>>>> designing a new service layer and then seeing if I could fit the
>>>> OpenHAB native libraries to it.
>>>>
>>>> OpenHAB corroborates my "PDE considered harmful" theory; it must be
>>>> possible to use OSGi idioms effectively while developing in Eclipse
>>>> PDE, but it doesn't seem to happen in practice.
>>>>
>>>> So Brad, I am right with you and I would like to help - but I am
>>>> seriously short of time at the moment :-(
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
Yes, that is more along the lines of what I was thinking about. But I think that should happen at the Kura board bundle level. If you look at the list under Gpio, for example, most of those are interfaces that could simply be exported as services from the board's bundle itself. The developer would have to identify the service in whatever way is appropriate for the consumer bundle to pick up. Switching to another board would only entail changing the configuration for that particular boards exports.
https://wiki.eclipse.org/Kura_GPIO_Support
Then if I'm writing a motor controller for a device that uses PPM, I know that the device I'm writing that for is going to require, perhaps, a GpioPinPwmOutput pin. That pin would be configured at the board level and exported. On the Rpi it might be a certain pin number with certain requirements while on the BananaPi or BeagleBoard it might be configured in a different way. But the driver bundle I'm writing for my motor doesn't change and isn't aware of that so is decoupled from it. The only requirement it would have is for that type of pin exported with the correct service identifier.
By contrast, my motor controller bundle will have mappings representing a mapping from a standard scale for motor control to the correct PPM values for my motor. It will also export its MotorControllerService with appropriate identifier for use by the application bundle.
So the configuration and exports stay with the bundles that are concerned with the specifics of each level of abstraction.
-----Original Message-----
From: Scott Lewis [mailto:slewis@composent.com]
Sent: Wednesday, January 4, 2017 8:24 PM
To: user@karaf.apache.org
Subject: Re: Karaf IoT
I think this tutorial [1] describes something like what you are talking about wrt device abstractions and OSGi services...i.e. the IGPIOPinOutput services.
Uses ServiceTracker, but would/does work just the same with DS. And for bonus...these services can easily remoted without being bound to a transport [2].
FWIW, I agree with you that it often will/does makes sense to define
'OSGi service-based' device abstractions. I also believe layering of
small/micro services...especially with DS to manage the service dependencies...can provide a dynamic and flexible model for IOT interaction.
Scott
[1] https://wiki.eclipse.org/Tutorial:_Raspberry_Pi_GPIO_with_OSGi_Services
[2]
https://wiki.eclipse.org/Tutorial:_OSGi_Remote_Services_for_Raspberry_Pi_GPIO
On 1/4/2017 4:07 PM, Brad Red Hat wrote:
> I just wanted to follow this up with a quick comment that might not have been obvious from the previous posts. I think something like a GpioController is the wrong level of abstraction to be exporting as a service from the board level bundles. Those exports should be configured pin or device services. The only place to configure all the pins/devices for a given implementation remain with the board's bundle. Switch the board you are using and you simply modify the boards pin configuration service exports from that board's bundle to match what is required. All actuator and sensor bundles that use those pins simply work without modification. All the application level bundles that use the exported services from the actuators and sensors continue to work as well.
>
> Configuration details remain consolidated at the levels which require them.
>
> -----Original Message-----
> From: Łukasz Dywicki [mailto:luke@code-house.org]
> Sent: Wednesday, January 4, 2017 4:25 PM
> To: user@karaf.apache.org
> Subject: Re: Karaf IoT
>
> Brad,
> If you have service dependant on presence of some board you can make it conditional. Just use OSGi service lifecycle to deregister service when device is disconnected. Service consumers should be aware of it or at least should not call injected service any longer. That’s perfect use case for service tracker. While GPIO will physicaly never get disconnected from raspberry the connected device, i2c may go out at any time. Tricky part is how to detect when device goes offline. This can’t be done in general way and I think it needs to be linked with device interactions (tracking link status and when it hangs) or system events, but this brings us back to Kura and native libraries.
>
> Cheers,
> Lukasz
> --
> Apache Karaf Committer & PMC
> Twitter: @ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>> Wiadomość napisana przez Brad Red Hat <br...@redhat.com> w dniu 4 sty 2017, o godz. 22:56:
>>
>> I'm still doing a bit of head scratching to figure out where I and OSGi libraries fit in the Kura scheme. Part of the problem is code samples may not be the best indicator of intended use but they are what's out there. Here's an example which doesn't fit how I think about OSGi services. If I switch the board I'm deploy to then my code is broken. If these were injected as services instead, then this device driver level bundle would be unaware of the change. Configuring it at the board bundle level also means that all configuration for pins, numbers and modes is in a single place.
>>
>> Well, I guess I've gone off the beaten path here and shouldn't be posting any of this to the Karaf forum as it is a tangential concern here. More to the point here is getting a Karaf deployment mechanism in place.
>>
>> public void activate(ComponentContext componentContext) {
>> logger.info("Bundle {} is starting...", APP_ID); //A factory call
>> across class loaders. Even if this is changed to inject GpioController it doesn't quite work.
>> GpioController gpioController = GpioFactory.getInstance(); //Pins and
>> board devices should be configured and exported as named services at the board level not in the application bundle.
>> GpioPinDigitalMultipurpose motionSensor =
>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01, PinMode.DIGITAL_INPUT); //Ditto
>> GpioPinDigitalMultipurpose motionStatusLed =
>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05,
>> PinMode.DIGITAL_OUTPUT);
>>
>> ....
>> }
>>
>>
>> -----Original Message-----
>> From: Łukasz Dywicki [mailto:luke@code-house.org]
>> Sent: Wednesday, January 4, 2017 2:54 PM
>> To: user@karaf.apache.org
>> Cc: Markus Rathgeb <ma...@gmail.com>
>> Subject: Re: Karaf IoT
>>
>> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is redundant from my Karaf (as a platform) point of view. But this all comes from past of project which was launched with Tycho and PDE since early days. There are multiple entities involved in project and it is not an easy task to redefine how things should be built.
>>
>> Initial apis of OH were quite simple and didn’t require anything strictly related to physical thing. Starting form OH2 and extraction of Eclipse SmartHome there is a seperation of concerns. OH2 bindings define Bridge and Things connected over it and may have Channels associated with every of these. At this stage it is lowest common denominator. There is no higher level APIs for representing pumps, boilers or sensors or alarms but from other hand OH is not a SCADA platform. Maybe at some point there will be further generalization of code which will allow bindings to gain some benefits? Many of bindings is pure software integration with vendor bridges having very little or no hardware involved at all which makes it easier to develop.
>>
>> I haven’t played with Kura so far because I didn’t need such low level library, but even if I would need something such that I would rather go for dedicated library handling specific use case instead of Kura which brings too much.
>>
>> Kind regards,
>> Lukasz
>> --
>> Apache Karaf Committer & PMC
>> Twitter: @ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>>
>>> Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o godz. 19:56:
>>>
>>> I share most of Brad's concerns; at first I was very interested in
>>> OpenHAB but after playing with it for a bit I began to think about
>>> designing a new service layer and then seeing if I could fit the
>>> OpenHAB native libraries to it.
>>>
>>> OpenHAB corroborates my "PDE considered harmful" theory; it must be
>>> possible to use OSGi idioms effectively while developing in Eclipse
>>> PDE, but it doesn't seem to happen in practice.
>>>
>>> So Brad, I am right with you and I would like to help - but I am
>>> seriously short of time at the moment :-(
>>>
>>>
>>>
>>>
>>
>
Re: Karaf IoT
Posted by Scott Lewis <sl...@composent.com>.
I think this tutorial [1] describes something like what you are talking
about wrt device abstractions and OSGi services...i.e. the
IGPIOPinOutput services.
Uses ServiceTracker, but would/does work just the same with DS. And for
bonus...these services can easily remoted without being bound to a
transport [2].
FWIW, I agree with you that it often will/does makes sense to define
'OSGi service-based' device abstractions. I also believe layering of
small/micro services...especially with DS to manage the service
dependencies...can provide a dynamic and flexible model for IOT interaction.
Scott
[1] https://wiki.eclipse.org/Tutorial:_Raspberry_Pi_GPIO_with_OSGi_Services
[2]
https://wiki.eclipse.org/Tutorial:_OSGi_Remote_Services_for_Raspberry_Pi_GPIO
On 1/4/2017 4:07 PM, Brad Red Hat wrote:
> I just wanted to follow this up with a quick comment that might not have been obvious from the previous posts. I think something like a GpioController is the wrong level of abstraction to be exporting as a service from the board level bundles. Those exports should be configured pin or device services. The only place to configure all the pins/devices for a given implementation remain with the board's bundle. Switch the board you are using and you simply modify the boards pin configuration service exports from that board's bundle to match what is required. All actuator and sensor bundles that use those pins simply work without modification. All the application level bundles that use the exported services from the actuators and sensors continue to work as well.
>
> Configuration details remain consolidated at the levels which require them.
>
> -----Original Message-----
> From: \u0141ukasz Dywicki [mailto:luke@code-house.org]
> Sent: Wednesday, January 4, 2017 4:25 PM
> To: user@karaf.apache.org
> Subject: Re: Karaf IoT
>
> Brad,
> If you have service dependant on presence of some board you can make it conditional. Just use OSGi service lifecycle to deregister service when device is disconnected. Service consumers should be aware of it or at least should not call injected service any longer. That\u2019s perfect use case for service tracker. While GPIO will physicaly never get disconnected from raspberry the connected device, i2c may go out at any time. Tricky part is how to detect when device goes offline. This can\u2019t be done in general way and I think it needs to be linked with device interactions (tracking link status and when it hangs) or system events, but this brings us back to Kura and native libraries.
>
> Cheers,
> Lukasz
> --
> Apache Karaf Committer & PMC
> Twitter: @ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>> Wiadomo\u015b\u0107 napisana przez Brad Red Hat <br...@redhat.com> w dniu 4 sty 2017, o godz. 22:56:
>>
>> I'm still doing a bit of head scratching to figure out where I and OSGi libraries fit in the Kura scheme. Part of the problem is code samples may not be the best indicator of intended use but they are what's out there. Here's an example which doesn't fit how I think about OSGi services. If I switch the board I'm deploy to then my code is broken. If these were injected as services instead, then this device driver level bundle would be unaware of the change. Configuring it at the board bundle level also means that all configuration for pins, numbers and modes is in a single place.
>>
>> Well, I guess I've gone off the beaten path here and shouldn't be posting any of this to the Karaf forum as it is a tangential concern here. More to the point here is getting a Karaf deployment mechanism in place.
>>
>> public void activate(ComponentContext componentContext) {
>> logger.info("Bundle {} is starting...", APP_ID); //A factory call
>> across class loaders. Even if this is changed to inject GpioController it doesn't quite work.
>> GpioController gpioController = GpioFactory.getInstance(); //Pins and
>> board devices should be configured and exported as named services at the board level not in the application bundle.
>> GpioPinDigitalMultipurpose motionSensor =
>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01, PinMode.DIGITAL_INPUT); //Ditto
>> GpioPinDigitalMultipurpose motionStatusLed =
>> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05,
>> PinMode.DIGITAL_OUTPUT);
>>
>> ....
>> }
>>
>>
>> -----Original Message-----
>> From: \u0141ukasz Dywicki [mailto:luke@code-house.org]
>> Sent: Wednesday, January 4, 2017 2:54 PM
>> To: user@karaf.apache.org
>> Cc: Markus Rathgeb <ma...@gmail.com>
>> Subject: Re: Karaf IoT
>>
>> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is redundant from my Karaf (as a platform) point of view. But this all comes from past of project which was launched with Tycho and PDE since early days. There are multiple entities involved in project and it is not an easy task to redefine how things should be built.
>>
>> Initial apis of OH were quite simple and didn\u2019t require anything strictly related to physical thing. Starting form OH2 and extraction of Eclipse SmartHome there is a seperation of concerns. OH2 bindings define Bridge and Things connected over it and may have Channels associated with every of these. At this stage it is lowest common denominator. There is no higher level APIs for representing pumps, boilers or sensors or alarms but from other hand OH is not a SCADA platform. Maybe at some point there will be further generalization of code which will allow bindings to gain some benefits? Many of bindings is pure software integration with vendor bridges having very little or no hardware involved at all which makes it easier to develop.
>>
>> I haven\u2019t played with Kura so far because I didn\u2019t need such low level library, but even if I would need something such that I would rather go for dedicated library handling specific use case instead of Kura which brings too much.
>>
>> Kind regards,
>> Lukasz
>> --
>> Apache Karaf Committer & PMC
>> Twitter: @ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>>
>>> Wiadomo\u015b\u0107 napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o godz. 19:56:
>>>
>>> I share most of Brad's concerns; at first I was very interested in
>>> OpenHAB but after playing with it for a bit I began to think about
>>> designing a new service layer and then seeing if I could fit the
>>> OpenHAB native libraries to it.
>>>
>>> OpenHAB corroborates my "PDE considered harmful" theory; it must be
>>> possible to use OSGi idioms effectively while developing in Eclipse
>>> PDE, but it doesn't seem to happen in practice.
>>>
>>> So Brad, I am right with you and I would like to help - but I am
>>> seriously short of time at the moment :-(
>>>
>>>
>>>
>>>
>>
>
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
I just wanted to follow this up with a quick comment that might not have been obvious from the previous posts. I think something like a GpioController is the wrong level of abstraction to be exporting as a service from the board level bundles. Those exports should be configured pin or device services. The only place to configure all the pins/devices for a given implementation remain with the board's bundle. Switch the board you are using and you simply modify the boards pin configuration service exports from that board's bundle to match what is required. All actuator and sensor bundles that use those pins simply work without modification. All the application level bundles that use the exported services from the actuators and sensors continue to work as well.
Configuration details remain consolidated at the levels which require them.
-----Original Message-----
From: Łukasz Dywicki [mailto:luke@code-house.org]
Sent: Wednesday, January 4, 2017 4:25 PM
To: user@karaf.apache.org
Subject: Re: Karaf IoT
Brad,
If you have service dependant on presence of some board you can make it conditional. Just use OSGi service lifecycle to deregister service when device is disconnected. Service consumers should be aware of it or at least should not call injected service any longer. That’s perfect use case for service tracker. While GPIO will physicaly never get disconnected from raspberry the connected device, i2c may go out at any time. Tricky part is how to detect when device goes offline. This can’t be done in general way and I think it needs to be linked with device interactions (tracking link status and when it hangs) or system events, but this brings us back to Kura and native libraries.
Cheers,
Lukasz
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
> Wiadomość napisana przez Brad Red Hat <br...@redhat.com> w dniu 4 sty 2017, o godz. 22:56:
>
> I'm still doing a bit of head scratching to figure out where I and OSGi libraries fit in the Kura scheme. Part of the problem is code samples may not be the best indicator of intended use but they are what's out there. Here's an example which doesn't fit how I think about OSGi services. If I switch the board I'm deploy to then my code is broken. If these were injected as services instead, then this device driver level bundle would be unaware of the change. Configuring it at the board bundle level also means that all configuration for pins, numbers and modes is in a single place.
>
> Well, I guess I've gone off the beaten path here and shouldn't be posting any of this to the Karaf forum as it is a tangential concern here. More to the point here is getting a Karaf deployment mechanism in place.
>
> public void activate(ComponentContext componentContext) {
> logger.info("Bundle {} is starting...", APP_ID); //A factory call
> across class loaders. Even if this is changed to inject GpioController it doesn't quite work.
> GpioController gpioController = GpioFactory.getInstance(); //Pins and
> board devices should be configured and exported as named services at the board level not in the application bundle.
> GpioPinDigitalMultipurpose motionSensor =
> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01, PinMode.DIGITAL_INPUT); //Ditto
> GpioPinDigitalMultipurpose motionStatusLed =
> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05,
> PinMode.DIGITAL_OUTPUT);
>
> ....
> }
>
>
> -----Original Message-----
> From: Łukasz Dywicki [mailto:luke@code-house.org]
> Sent: Wednesday, January 4, 2017 2:54 PM
> To: user@karaf.apache.org
> Cc: Markus Rathgeb <ma...@gmail.com>
> Subject: Re: Karaf IoT
>
> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is redundant from my Karaf (as a platform) point of view. But this all comes from past of project which was launched with Tycho and PDE since early days. There are multiple entities involved in project and it is not an easy task to redefine how things should be built.
>
> Initial apis of OH were quite simple and didn’t require anything strictly related to physical thing. Starting form OH2 and extraction of Eclipse SmartHome there is a seperation of concerns. OH2 bindings define Bridge and Things connected over it and may have Channels associated with every of these. At this stage it is lowest common denominator. There is no higher level APIs for representing pumps, boilers or sensors or alarms but from other hand OH is not a SCADA platform. Maybe at some point there will be further generalization of code which will allow bindings to gain some benefits? Many of bindings is pure software integration with vendor bridges having very little or no hardware involved at all which makes it easier to develop.
>
> I haven’t played with Kura so far because I didn’t need such low level library, but even if I would need something such that I would rather go for dedicated library handling specific use case instead of Kura which brings too much.
>
> Kind regards,
> Lukasz
> --
> Apache Karaf Committer & PMC
> Twitter: @ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
>> Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o godz. 19:56:
>>
>> I share most of Brad's concerns; at first I was very interested in
>> OpenHAB but after playing with it for a bit I began to think about
>> designing a new service layer and then seeing if I could fit the
>> OpenHAB native libraries to it.
>>
>> OpenHAB corroborates my "PDE considered harmful" theory; it must be
>> possible to use OSGi idioms effectively while developing in Eclipse
>> PDE, but it doesn't seem to happen in practice.
>>
>> So Brad, I am right with you and I would like to help - but I am
>> seriously short of time at the moment :-(
>>
>>
>>
>>
>
>
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
Łukasz,
Agreed. But if you look at the design of the code those aren't services being injected into the application bundle (except the GpioController). And the code is coupled to implementation details about the board being used instead of using the service interface with configuration details being exported from the board's bundle. That means the service code is not decoupled.
In the activate section of the bundle you can see:
GpioController gpioController = GpioFactory.getInstance();
GpioPinDigitalMultipurpose motionSensor = gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01, PinMode.DIGITAL_INPUT);
Instead, I'd expect my application bundle to be receiving an injected service via blueprint or DS/SCR.
@Reference(....)
GpioPinDigitalMultipurpose motionSensor;
The motion sensor pin should be configured and exported from the board's bundle and not explicitly accessed and configured from the consumer bundle. If I switch the board I'm deploying then my consumer shouldn't break. I should change the board's bundle configuration to export the pin number and configuration details I'm using. The consumer should be unaware of that change. That's going to be especially important to any sensor or actuator implementations that simply expect the GipPin or other service to be injected.
I've used blueprint in the past so I'm more familiar with its mechanics but the idea is the same. With blueprint the proxy would be injected and with DS, I believe, the consumer bundle wouldn't be started until the correct service is ready to be injected.
-----Original Message-----
From: Łukasz Dywicki [mailto:luke@code-house.org]
Sent: Wednesday, January 4, 2017 4:25 PM
To: user@karaf.apache.org
Subject: Re: Karaf IoT
Brad,
If you have service dependant on presence of some board you can make it conditional. Just use OSGi service lifecycle to deregister service when device is disconnected. Service consumers should be aware of it or at least should not call injected service any longer. That’s perfect use case for service tracker. While GPIO will physicaly never get disconnected from raspberry the connected device, i2c may go out at any time. Tricky part is how to detect when device goes offline. This can’t be done in general way and I think it needs to be linked with device interactions (tracking link status and when it hangs) or system events, but this brings us back to Kura and native libraries.
Cheers,
Lukasz
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
> Wiadomość napisana przez Brad Red Hat <br...@redhat.com> w dniu 4 sty 2017, o godz. 22:56:
>
> I'm still doing a bit of head scratching to figure out where I and OSGi libraries fit in the Kura scheme. Part of the problem is code samples may not be the best indicator of intended use but they are what's out there. Here's an example which doesn't fit how I think about OSGi services. If I switch the board I'm deploy to then my code is broken. If these were injected as services instead, then this device driver level bundle would be unaware of the change. Configuring it at the board bundle level also means that all configuration for pins, numbers and modes is in a single place.
>
> Well, I guess I've gone off the beaten path here and shouldn't be posting any of this to the Karaf forum as it is a tangential concern here. More to the point here is getting a Karaf deployment mechanism in place.
>
> public void activate(ComponentContext componentContext) {
> logger.info("Bundle {} is starting...", APP_ID); //A factory call
> across class loaders. Even if this is changed to inject GpioController it doesn't quite work.
> GpioController gpioController = GpioFactory.getInstance(); //Pins and
> board devices should be configured and exported as named services at the board level not in the application bundle.
> GpioPinDigitalMultipurpose motionSensor =
> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01, PinMode.DIGITAL_INPUT); //Ditto
> GpioPinDigitalMultipurpose motionStatusLed =
> gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05,
> PinMode.DIGITAL_OUTPUT);
>
> ....
> }
>
>
> -----Original Message-----
> From: Łukasz Dywicki [mailto:luke@code-house.org]
> Sent: Wednesday, January 4, 2017 2:54 PM
> To: user@karaf.apache.org
> Cc: Markus Rathgeb <ma...@gmail.com>
> Subject: Re: Karaf IoT
>
> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is redundant from my Karaf (as a platform) point of view. But this all comes from past of project which was launched with Tycho and PDE since early days. There are multiple entities involved in project and it is not an easy task to redefine how things should be built.
>
> Initial apis of OH were quite simple and didn’t require anything strictly related to physical thing. Starting form OH2 and extraction of Eclipse SmartHome there is a seperation of concerns. OH2 bindings define Bridge and Things connected over it and may have Channels associated with every of these. At this stage it is lowest common denominator. There is no higher level APIs for representing pumps, boilers or sensors or alarms but from other hand OH is not a SCADA platform. Maybe at some point there will be further generalization of code which will allow bindings to gain some benefits? Many of bindings is pure software integration with vendor bridges having very little or no hardware involved at all which makes it easier to develop.
>
> I haven’t played with Kura so far because I didn’t need such low level library, but even if I would need something such that I would rather go for dedicated library handling specific use case instead of Kura which brings too much.
>
> Kind regards,
> Lukasz
> --
> Apache Karaf Committer & PMC
> Twitter: @ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
>> Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o godz. 19:56:
>>
>> I share most of Brad's concerns; at first I was very interested in
>> OpenHAB but after playing with it for a bit I began to think about
>> designing a new service layer and then seeing if I could fit the
>> OpenHAB native libraries to it.
>>
>> OpenHAB corroborates my "PDE considered harmful" theory; it must be
>> possible to use OSGi idioms effectively while developing in Eclipse
>> PDE, but it doesn't seem to happen in practice.
>>
>> So Brad, I am right with you and I would like to help - but I am
>> seriously short of time at the moment :-(
>>
>>
>>
>>
>
>
Re: Karaf IoT
Posted by Łukasz Dywicki <lu...@code-house.org>.
Brad,
If you have service dependant on presence of some board you can make it conditional. Just use OSGi service lifecycle to deregister service when device is disconnected. Service consumers should be aware of it or at least should not call injected service any longer. That’s perfect use case for service tracker. While GPIO will physicaly never get disconnected from raspberry the connected device, i2c may go out at any time. Tricky part is how to detect when device goes offline. This can’t be done in general way and I think it needs to be linked with device interactions (tracking link status and when it hangs) or system events, but this brings us back to Kura and native libraries.
Cheers,
Lukasz
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
> Wiadomość napisana przez Brad Red Hat <br...@redhat.com> w dniu 4 sty 2017, o godz. 22:56:
>
> I'm still doing a bit of head scratching to figure out where I and OSGi libraries fit in the Kura scheme. Part of the problem is code samples may not be the best indicator of intended use but they are what's out there. Here's an example which doesn't fit how I think about OSGi services. If I switch the board I'm deploy to then my code is broken. If these were injected as services instead, then this device driver level bundle would be unaware of the change. Configuring it at the board bundle level also means that all configuration for pins, numbers and modes is in a single place.
>
> Well, I guess I've gone off the beaten path here and shouldn't be posting any of this to the Karaf forum as it is a tangential concern here. More to the point here is getting a Karaf deployment mechanism in place.
>
> public void activate(ComponentContext componentContext) {
> logger.info("Bundle {} is starting...", APP_ID);
> //A factory call across class loaders. Even if this is changed to inject GpioController it doesn't quite work.
> GpioController gpioController = GpioFactory.getInstance();
> //Pins and board devices should be configured and exported as named services at the board level not in the application bundle.
> GpioPinDigitalMultipurpose motionSensor = gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01, PinMode.DIGITAL_INPUT);
> //Ditto
> GpioPinDigitalMultipurpose motionStatusLed = gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05, PinMode.DIGITAL_OUTPUT);
>
> ....
> }
>
>
> -----Original Message-----
> From: Łukasz Dywicki [mailto:luke@code-house.org]
> Sent: Wednesday, January 4, 2017 2:54 PM
> To: user@karaf.apache.org
> Cc: Markus Rathgeb <ma...@gmail.com>
> Subject: Re: Karaf IoT
>
> I am OpenHab (OH) 2 user and I I must say that whole PDE thing is redundant from my Karaf (as a platform) point of view. But this all comes from past of project which was launched with Tycho and PDE since early days. There are multiple entities involved in project and it is not an easy task to redefine how things should be built.
>
> Initial apis of OH were quite simple and didn’t require anything strictly related to physical thing. Starting form OH2 and extraction of Eclipse SmartHome there is a seperation of concerns. OH2 bindings define Bridge and Things connected over it and may have Channels associated with every of these. At this stage it is lowest common denominator. There is no higher level APIs for representing pumps, boilers or sensors or alarms but from other hand OH is not a SCADA platform. Maybe at some point there will be further generalization of code which will allow bindings to gain some benefits? Many of bindings is pure software integration with vendor bridges having very little or no hardware involved at all which makes it easier to develop.
>
> I haven’t played with Kura so far because I didn’t need such low level library, but even if I would need something such that I would rather go for dedicated library handling specific use case instead of Kura which brings too much.
>
> Kind regards,
> Lukasz
> --
> Apache Karaf Committer & PMC
> Twitter: @ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
>> Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o godz. 19:56:
>>
>> I share most of Brad's concerns; at first I was very interested in
>> OpenHAB but after playing with it for a bit I began to think about
>> designing a new service layer and then seeing if I could fit the
>> OpenHAB native libraries to it.
>>
>> OpenHAB corroborates my "PDE considered harmful" theory; it must be
>> possible to use OSGi idioms effectively while developing in Eclipse
>> PDE, but it doesn't seem to happen in practice.
>>
>> So Brad, I am right with you and I would like to help - but I am
>> seriously short of time at the moment :-(
>>
>>
>>
>>
>
>
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
I'm still doing a bit of head scratching to figure out where I and OSGi libraries fit in the Kura scheme. Part of the problem is code samples may not be the best indicator of intended use but they are what's out there. Here's an example which doesn't fit how I think about OSGi services. If I switch the board I'm deploy to then my code is broken. If these were injected as services instead, then this device driver level bundle would be unaware of the change. Configuring it at the board bundle level also means that all configuration for pins, numbers and modes is in a single place.
Well, I guess I've gone off the beaten path here and shouldn't be posting any of this to the Karaf forum as it is a tangential concern here. More to the point here is getting a Karaf deployment mechanism in place.
public void activate(ComponentContext componentContext) {
logger.info("Bundle {} is starting...", APP_ID);
//A factory call across class loaders. Even if this is changed to inject GpioController it doesn't quite work.
GpioController gpioController = GpioFactory.getInstance();
//Pins and board devices should be configured and exported as named services at the board level not in the application bundle.
GpioPinDigitalMultipurpose motionSensor = gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_01, PinMode.DIGITAL_INPUT);
//Ditto
GpioPinDigitalMultipurpose motionStatusLed = gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05, PinMode.DIGITAL_OUTPUT);
....
}
-----Original Message-----
From: Łukasz Dywicki [mailto:luke@code-house.org]
Sent: Wednesday, January 4, 2017 2:54 PM
To: user@karaf.apache.org
Cc: Markus Rathgeb <ma...@gmail.com>
Subject: Re: Karaf IoT
I am OpenHab (OH) 2 user and I I must say that whole PDE thing is redundant from my Karaf (as a platform) point of view. But this all comes from past of project which was launched with Tycho and PDE since early days. There are multiple entities involved in project and it is not an easy task to redefine how things should be built.
Initial apis of OH were quite simple and didn’t require anything strictly related to physical thing. Starting form OH2 and extraction of Eclipse SmartHome there is a seperation of concerns. OH2 bindings define Bridge and Things connected over it and may have Channels associated with every of these. At this stage it is lowest common denominator. There is no higher level APIs for representing pumps, boilers or sensors or alarms but from other hand OH is not a SCADA platform. Maybe at some point there will be further generalization of code which will allow bindings to gain some benefits? Many of bindings is pure software integration with vendor bridges having very little or no hardware involved at all which makes it easier to develop.
I haven’t played with Kura so far because I didn’t need such low level library, but even if I would need something such that I would rather go for dedicated library handling specific use case instead of Kura which brings too much.
Kind regards,
Lukasz
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
> Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o godz. 19:56:
>
> I share most of Brad's concerns; at first I was very interested in
> OpenHAB but after playing with it for a bit I began to think about
> designing a new service layer and then seeing if I could fit the
> OpenHAB native libraries to it.
>
> OpenHAB corroborates my "PDE considered harmful" theory; it must be
> possible to use OSGi idioms effectively while developing in Eclipse
> PDE, but it doesn't seem to happen in practice.
>
> So Brad, I am right with you and I would like to help - but I am
> seriously short of time at the moment :-(
>
>
>
>
Re: Karaf IoT
Posted by Łukasz Dywicki <lu...@code-house.org>.
I am OpenHab (OH) 2 user and I I must say that whole PDE thing is redundant from my Karaf (as a platform) point of view. But this all comes from past of project which was launched with Tycho and PDE since early days. There are multiple entities involved in project and it is not an easy task to redefine how things should be built.
Initial apis of OH were quite simple and didn’t require anything strictly related to physical thing. Starting form OH2 and extraction of Eclipse SmartHome there is a seperation of concerns. OH2 bindings define Bridge and Things connected over it and may have Channels associated with every of these. At this stage it is lowest common denominator. There is no higher level APIs for representing pumps, boilers or sensors or alarms but from other hand OH is not a SCADA platform. Maybe at some point there will be further generalization of code which will allow bindings to gain some benefits? Many of bindings is pure software integration with vendor bridges having very little or no hardware involved at all which makes it easier to develop.
I haven’t played with Kura so far because I didn’t need such low level library, but even if I would need something such that I would rather go for dedicated library handling specific use case instead of Kura which brings too much.
Kind regards,
Lukasz
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
> Wiadomość napisana przez chris.gray@kiffer.ltd.uk w dniu 2 sty 2017, o godz. 19:56:
>
> I share most of Brad's concerns; at first I was very interested in OpenHAB
> but after playing with it for a bit I began to think about designing a new
> service layer and then seeing if I could fit the OpenHAB native libraries
> to it.
>
> OpenHAB corroborates my "PDE considered harmful" theory; it must be
> possible to use OSGi idioms effectively while developing in Eclipse PDE,
> but it doesn't seem to happen in practice.
>
> So Brad, I am right with you and I would like to help - but I am seriously
> short of time at the moment :-(
>
>
>
>
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
Not yet…I’m trying to find out if there are existing projects that might be interested or already working on either Karaf or appropriate OSGi services for boards, sensors and actuators. It certainly is a project I’ll set up if there isn’t any interest elsewhere. Kura might not be the place for it and while Karaf/Felix is important to me, it can leverage the existing Kura bundles without necessarily being a part of that project. So I’ll definitely be involved in some Karaf deployment/implementation mechanism.
I did post on the Kura forum today asking about interest. Part of what drives this is going to be their mission statement and interest. At the very least, for the project to be useful, the board level device concerns and configurations have to be abstracted behind service and service factory interfaces for the supported boards and their devices. The sample code on the Kura project shows some abstraction levels that would be appropriate for creating sensor/actuator bundles but it needs to hew to OSGi idioms more. That obviously isn’t a Karaf specific concern but is an OSGi library concern that we all share. I really want to make sure I’m not coming off as busting on the Kura project here. It is based on Pi4j which has support for a lot of different boards.
This code sample appears to have the sort of abstraction I’d expect a sensor/actuator driver bundle to use. A developer or manufacturer interested in providing an implementation bundle for a specific sensor or actuator can inject the DS ModBus service and bind to it. It is still showing pin and register level access though which binds it to a specific board implementation as far as I can tell.
http://eclipse.github.io/kura/doc/kura-modbus-driver.html
By contrast this sample is calling across classloaders to a device manager and explicitly setting pin configuration instead of configuring it at a board level, exporting as a service, and injecting it into a consumer bundle. That configuration is board specific and should be tucked away, done solely via configuration and exported.
http://eclipse.github.io/kura/doc/kura-dio-apis.html
Those board level bundles should be exporting services and service factories that are purely set up via configuration. That permits the intermediary bundles for sensors and actuators to bind to them without configuring them. The configuration of the pins/services should be associate with the board level bundles. Moving from one board to another should be a simple matter of changing board level configuration without requiring modifications to sensor/actuator bundles and especially without changes to application level bundles that use sensor/actuator service interfaces. (Yeah, life is never that simple but it’s a good goal I think).
The injection of services like GpioPin might use LDAP filtering for export and import (or other mechanism so that pin numbers and configuration are not exposed.) Moving from board to board then is matter of configuring the board level exports to set up pins and expose them as services with via a given name.
And Karaf 4 is a spectacular way to zip an application and all its dependencies for deployment. Once some service interfaces for sensors and actuators are developed, then simulators for those could be created permitting easy development of applications on the desktop. Perhaps those would also provide reference implementations for developing tests suites against that driver manufacturers could use to determine if their sensor or actuator bundle actually complies with the standard.
Brad
From: Jason Pratt [mailto:jpratt3000@gmail.com]
Sent: Wednesday, January 4, 2017 12:05 PM
To: user@karaf.apache.org
Subject: Re: Karaf IoT
scott/brad do you guys have a repo setup for this project?
On Wed, Jan 4, 2017 at 9:39 AM, Brad Red Hat <bradjohn@redhat.com <ma...@redhat.com> > wrote:
I'll certainly look at that a bit more. My concerns about Kura project have
as much to do with the project's level of abstraction and I can bring it up
there. I did ask about their intentions with service interfaces. As I've
dug into it deeper and thought about "the vision thing", to quote a US
president, I laid out some of those thoughts.
https://enjekt.org/2017/01/04/iot-and-the-abstraction-of-things/
Because it is an Eclipse project I wasn't sure that they'd be interested in
Karaf/Felix but can check. I've heard that they have, in fact, opened a Jira
ticket about it. So they may be interested.
It isn't just about a Karaf implementation although it is certainly about
that as well. I'm also concerned about the intermediary libraries/services
that abstract developers away from low level details of pin outs in order to
make application code portable.
Obviously the intermediate level concerns really don't belong with Kura or
Karaf so I won't discuss those here. Suffice it to say I'd like to see that
intermediate set of libraries become a "sticky" place where developers and
sensor/actuator manufacturers go to add new high level device specific
bundles for use in applications.
Brad
-----Original Message-----
From: Scott Lewis [mailto:slewis@composent.com <ma...@composent.com> ]
Sent: Tuesday, January 3, 2017 9:33 PM
To: user@karaf.apache.org <ma...@karaf.apache.org>
Subject: Re: Karaf IoT
On 1/2/2017 11:35 AM, Brad Red Hat wrote:
> I certainly understand the "short of time" problem. It just happens
> that I have a bit of a window right now and would like to get into it a
bit deeper.
>
>
> Whether a Karaf/PAX/Felix implementation is more appropriate under the
> aegis of Kura or as a separate project that leverages the Kura driver
> bundles is hard to say. I guess that would depend on a couple of things.
>
> 1. How amenable they are to a more top down approach that starts with
> OSGi service mechanics and drives down to meet the driver bundles?
> 2. Does an Eclipse foundation project have any interest in an Karaf
> branch project?
The ECF project would be interested in such an effort [1]. We have been/are
distributing our impl of the OSGi Remote Services/RSA specs [2] as Karaf
features [3] and have recently been exploring using remote services for
Karaf management [4].
Also, in my interaction with some of the Kura committers it's become clear
that they are doing some prototyping of running Kura services on
Karaf [5]. I don't know whether they have release plans around that
work, but I know that it has been going on. It might be useful to
convey to them directly what your desires/criticisms are, and perhaps
contribute to that work.
Scott
[1] http://www.eclipse.org/ecf
[2]
https://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote
_Services
[3] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
[4] https://wiki.eclipse.org/Karaf_Remote_Management_with_Eclipse
[5] https://dev.eclipse.org/mhonarc/lists/kura-dev/
Re: Karaf IoT
Posted by Jason Pratt <jp...@gmail.com>.
scott/brad do you guys have a repo setup for this project?
On Wed, Jan 4, 2017 at 9:39 AM, Brad Red Hat <br...@redhat.com> wrote:
> I'll certainly look at that a bit more. My concerns about Kura project have
> as much to do with the project's level of abstraction and I can bring it up
> there. I did ask about their intentions with service interfaces. As I've
> dug into it deeper and thought about "the vision thing", to quote a US
> president, I laid out some of those thoughts.
>
> https://enjekt.org/2017/01/04/iot-and-the-abstraction-of-things/
>
> Because it is an Eclipse project I wasn't sure that they'd be interested in
> Karaf/Felix but can check. I've heard that they have, in fact, opened a
> Jira
> ticket about it. So they may be interested.
>
> It isn't just about a Karaf implementation although it is certainly about
> that as well. I'm also concerned about the intermediary libraries/services
> that abstract developers away from low level details of pin outs in order
> to
> make application code portable.
>
> Obviously the intermediate level concerns really don't belong with Kura or
> Karaf so I won't discuss those here. Suffice it to say I'd like to see
> that
> intermediate set of libraries become a "sticky" place where developers and
> sensor/actuator manufacturers go to add new high level device specific
> bundles for use in applications.
>
> Brad
>
>
> -----Original Message-----
> From: Scott Lewis [mailto:slewis@composent.com]
> Sent: Tuesday, January 3, 2017 9:33 PM
> To: user@karaf.apache.org
> Subject: Re: Karaf IoT
>
> On 1/2/2017 11:35 AM, Brad Red Hat wrote:
> > I certainly understand the "short of time" problem. It just happens
> > that I have a bit of a window right now and would like to get into it a
> bit deeper.
> >
> >
> > Whether a Karaf/PAX/Felix implementation is more appropriate under the
> > aegis of Kura or as a separate project that leverages the Kura driver
> > bundles is hard to say. I guess that would depend on a couple of things.
> >
> > 1. How amenable they are to a more top down approach that starts with
> > OSGi service mechanics and drives down to meet the driver bundles?
> > 2. Does an Eclipse foundation project have any interest in an Karaf
> > branch project?
>
> The ECF project would be interested in such an effort [1]. We have
> been/are
> distributing our impl of the OSGi Remote Services/RSA specs [2] as Karaf
> features [3] and have recently been exploring using remote services for
> Karaf management [4].
>
> Also, in my interaction with some of the Kura committers it's become clear
> that they are doing some prototyping of running Kura services on
> Karaf [5]. I don't know whether they have release plans around that
> work, but I know that it has been going on. It might be useful to
> convey to them directly what your desires/criticisms are, and perhaps
> contribute to that work.
>
> Scott
>
> [1] http://www.eclipse.org/ecf
> [2]
> https://wiki.eclipse.org/Eclipse_Communication_
> Framework_Project#OSGi_Remote
> _Services
> [3] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
> [4] https://wiki.eclipse.org/Karaf_Remote_Management_with_Eclipse
> [5] https://dev.eclipse.org/mhonarc/lists/kura-dev/
>
>
>
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
I'll certainly look at that a bit more. My concerns about Kura project have
as much to do with the project's level of abstraction and I can bring it up
there. I did ask about their intentions with service interfaces. As I've
dug into it deeper and thought about "the vision thing", to quote a US
president, I laid out some of those thoughts.
https://enjekt.org/2017/01/04/iot-and-the-abstraction-of-things/
Because it is an Eclipse project I wasn't sure that they'd be interested in
Karaf/Felix but can check. I've heard that they have, in fact, opened a Jira
ticket about it. So they may be interested.
It isn't just about a Karaf implementation although it is certainly about
that as well. I'm also concerned about the intermediary libraries/services
that abstract developers away from low level details of pin outs in order to
make application code portable.
Obviously the intermediate level concerns really don't belong with Kura or
Karaf so I won't discuss those here. Suffice it to say I'd like to see that
intermediate set of libraries become a "sticky" place where developers and
sensor/actuator manufacturers go to add new high level device specific
bundles for use in applications.
Brad
-----Original Message-----
From: Scott Lewis [mailto:slewis@composent.com]
Sent: Tuesday, January 3, 2017 9:33 PM
To: user@karaf.apache.org
Subject: Re: Karaf IoT
On 1/2/2017 11:35 AM, Brad Red Hat wrote:
> I certainly understand the "short of time" problem. It just happens
> that I have a bit of a window right now and would like to get into it a
bit deeper.
>
>
> Whether a Karaf/PAX/Felix implementation is more appropriate under the
> aegis of Kura or as a separate project that leverages the Kura driver
> bundles is hard to say. I guess that would depend on a couple of things.
>
> 1. How amenable they are to a more top down approach that starts with
> OSGi service mechanics and drives down to meet the driver bundles?
> 2. Does an Eclipse foundation project have any interest in an Karaf
> branch project?
The ECF project would be interested in such an effort [1]. We have been/are
distributing our impl of the OSGi Remote Services/RSA specs [2] as Karaf
features [3] and have recently been exploring using remote services for
Karaf management [4].
Also, in my interaction with some of the Kura committers it's become clear
that they are doing some prototyping of running Kura services on
Karaf [5]. I don't know whether they have release plans around that
work, but I know that it has been going on. It might be useful to
convey to them directly what your desires/criticisms are, and perhaps
contribute to that work.
Scott
[1] http://www.eclipse.org/ecf
[2]
https://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote
_Services
[3] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
[4] https://wiki.eclipse.org/Karaf_Remote_Management_with_Eclipse
[5] https://dev.eclipse.org/mhonarc/lists/kura-dev/
Re: Karaf IoT
Posted by Scott Lewis <sl...@composent.com>.
On 1/2/2017 11:35 AM, Brad Red Hat wrote:
> I certainly understand the "short of time" problem. It just happens that I
> have a bit of a window right now and would like to get into it a bit deeper.
>
>
> Whether a Karaf/PAX/Felix implementation is more appropriate under the aegis
> of Kura or as a separate project that leverages the Kura driver bundles is
> hard to say. I guess that would depend on a couple of things.
>
> 1. How amenable they are to a more top down approach that starts with OSGi
> service mechanics and drives down to meet the driver bundles?
> 2. Does an Eclipse foundation project have any interest in an Karaf branch
> project?
The ECF project would be interested in such an effort [1]. We have
been/are distributing our impl of the OSGi Remote Services/RSA specs [2]
as Karaf features [3] and have recently been exploring using remote
services for Karaf management [4].
Also, in my interaction with some of the Kura committers it's become
clear that they are doing some prototyping of running Kura services on
Karaf [5]. I don't know whether they have release plans around that
work, but I know that it has been going on. It might be useful to
convey to them directly what your desires/criticisms are, and perhaps
contribute to that work.
Scott
[1] http://www.eclipse.org/ecf
[2]
https://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote_Services
[3] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
[4] https://wiki.eclipse.org/Karaf_Remote_Management_with_Eclipse
[5] https://dev.eclipse.org/mhonarc/lists/kura-dev/
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
I certainly understand the "short of time" problem. It just happens that I
have a bit of a window right now and would like to get into it a bit deeper.
Whether a Karaf/PAX/Felix implementation is more appropriate under the aegis
of Kura or as a separate project that leverages the Kura driver bundles is
hard to say. I guess that would depend on a couple of things.
1. How amenable they are to a more top down approach that starts with OSGi
service mechanics and drives down to meet the driver bundles?
2. Does an Eclipse foundation project have any interest in an Karaf branch
project?
On point 1, I think Kura really does need a better service structure in
order to be a successful OSGi project. Those higher level bundles and API
interfaces should be a part of the project. What we don't want, obviously,
is something that acts more like a WAR with all the classes of every jar
file simply exported to the world from their individual bundles
On point 2, it is reasonable for Kura to swing either way. It is an Eclipse
foundation project and there isn't any particular reason they should support
other frameworks. There isn't a reason they couldn't or shouldn't either.
Part of the answer to point 2 is also how enthusiastic any particular
community is about such a project.
More thought and research is necessary since I'm just getting into it.
Brad
-----Original Message-----
From: chris.gray@kiffer.ltd.uk [mailto:chris.gray@kiffer.ltd.uk]
Sent: Monday, January 2, 2017 12:57 PM
To: user@karaf.apache.org
Subject: RE: Karaf IoT
I share most of Brad's concerns; at first I was very interested in OpenHAB
but after playing with it for a bit I began to think about designing a new
service layer and then seeing if I could fit the OpenHAB native libraries to
it.
OpenHAB corroborates my "PDE considered harmful" theory; it must be possible
to use OSGi idioms effectively while developing in Eclipse PDE, but it
doesn't seem to happen in practice.
So Brad, I am right with you and I would like to help - but I am seriously
short of time at the moment :-(
RE: Karaf IoT
Posted by ch...@kiffer.ltd.uk.
I share most of Brad's concerns; at first I was very interested in OpenHAB
but after playing with it for a bit I began to think about designing a new
service layer and then seeing if I could fit the OpenHAB native libraries
to it.
OpenHAB corroborates my "PDE considered harmful" theory; it must be
possible to use OSGi idioms effectively while developing in Eclipse PDE,
but it doesn't seem to happen in practice.
So Brad, I am right with you and I would like to help - but I am seriously
short of time at the moment :-(
RE: Karaf IoT
Posted by Brad Red Hat <br...@redhat.com>.
If I get a bit of time perhaps I'll try to create at least a skeleton/basic reference implementation for what I have in mind. While I like the idea of the Kura project I'm not thrilled with some of what I saw. I'd like to be clear that I don't think the Kura project is bad, per se, but it looks like it was built bottom up and it is heavily Eclipse based. That there are bundles with JNI bindings is fantastic and I'm very thankful that someone has done that heavy lifting. But C++ is leaking up into the Java code. I recognize that Kura is focusing on the low level necessities. So higher level abstractions like service interfaces like LED, CANBus, USB, and so on aren't practical. At least not yet. So to some extent this is about Karaf/Felix and the relevant Maven plugins but it is also about abstracting away the underlying JNI into more OSGi service focused implementation. The developers on the Kura project obviously know their sh*t when it comes to the low level board and driver code, the JNI wrapper code and the like. Kudos to them.
Kura is a great project but it simply doesn't fit the way I'm used to working with OSGi and much of it doesn't seem coded with an OSGi-centric view of the world. Having said that, the bundles they've created to hook into hardware can be leveraged in a Karaf/Felix environment easily enough. And relevant OSGi service centric implementations can be created. If Kura didn't exist I probably wouldn't even contemplate a Karaf/Felix project. Having bundles that are pre-compiled for things like CAN are marvelous. For that level of library it really doesn't matter how the OSGi bundle was created since it is simply a plain ol' OSGi bundle asset (Pooba).
I'm getting set up to work on IoT/small devices and since I've worked with Karaf/OSGi for the past 5 years it was the obvious starting point. Since I've been using Karaf and Aries I'm used to those Maven plugins. There are a number of aspects of Kura that bothered me in the hour or so I looked at the project. There isn't one single thing that was a non-starter, it was more an aggregate. So choosing any single point in the abbreviated list below isn't really germane. This isn't a complete list by any means.
--I'm not a big fan of Tycho or the Eclipse OSGi "plug-ins" (not to be confused with the Maven plugins).
--Doing Manifest first implementations are workable, of course, but I don’t find it desirable and it doesn't mesh with my preferred approach.
--While I use the Eclipse IDE I don't want to use its mechanisms and GUI for the implementation mechanics. Sure I can work around that but I'd prefer to not even start there.
--The DS examples used XML for configuration and I didn't see any examples of annotated classes. XML is a perfectly valid mechanic, of course.
--Almost all of the Java code samples use Hungarian notation. Not evil in and of itself but I do consider it a code smell. If something as fundamental as camel casing isn't being used, what is the likelihood that higher level abstractions are being used in a real Java/OSGi fashion. (I can't answer that question as I didn't dig in enough but I wasn't encouraged).
--Not surprisingly many of the calls looked low level - writing hex values. To me those should be mapped values in configuration files while the OSGi service interfaces provide more human friendly method calls.
--A lot of casting that looks like Java 1.4 without the use of generics.
--Many of the I/O libraries are third party in any case and not specifically written for the Kura project - CAN, HIDAPI, USB, for example.
--As stated previously I think the Karaf 4 profile compilation and zip makes it an ideal way to create and deploy a project.
--Ant (comfortable for someone coming from Make I'd guess). Personally I never want to go there again.
--No fluent APIs.
--No annotations used to simplify coding
--Static method calls that should be abstracted away.
--Etc.
On that last point I think the prime example I saw was the DeviceManager from J2ME be called directly to get GPIO, I2C and SPI devices. That reach across the OSGi classloaders to couple with a concrete implementation isn't in the spirit of OSGi really. At some point that DeviceManager or other mechanism must be called. But will it always be the DeviceManager from J2ME? Things like GPIO, I2C and SPI already have interfaces in the J2ME implementation. So OSGi services like GPIOConnectorService, I2CConnectorService and SPIConnectorService make a great deal of sense. A developer using those services would be unaware of the underlying mechanism.
http://docs.oracle.com/javame/8.0/api/dio/api/index.html
A great set of interfaces with a few implementation classes and factories. This is one of those cases where I think a more OSGi compliant way to do this would be to create things like the connector services mentioned above and then hide the DeviceManager in the *.internal package in the bundle. The services could be used to configure the devices or better yet, the bootstrap and configuration could use the connector service to instantiate the device interface and make it available via a service factory. The GPIO pin is a good example. Since that is already an interface the service factory could simply provide it preconfigured via injection into a developer's code.
Obviously those last points aren't specifically about Karaf/Felix or Equinox. But it is the sort of expected OSGi abstraction that I'm not really seeing. It is that OSGi service thinking that I'm not seeing in the project. I'm sure the Kura project would be amenable to some of those changes. But as I said up front, my concerns aren't about any single aspect.
Brad
-----Original Message-----
From: Markus Rathgeb [mailto:maggu2810@gmail.com]
Sent: Monday, January 2, 2017 6:03 AM
To: user@karaf.apache.org
Subject: Re: Karaf IoT
Hi,
> I'm not really an expert, but I know the openHAB project, which AFAIK
> uses Eclipse Kura, is based on Karaf.
openHAB 2 is using the Eclipse SmartHome framework.
openHAB 2 is running on Karaf.
Re: Karaf IoT
Posted by Markus Rathgeb <ma...@gmail.com>.
Hi,
> I'm not really an expert, but I know the openHAB project, which AFAIK uses
> Eclipse Kura, is based on Karaf.
openHAB 2 is using the Eclipse SmartHome framework.
openHAB 2 is running on Karaf.
Re: Karaf IoT
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Brad,
I'm not really an expert, but I know the openHAB project, which AFAIK uses
Eclipse Kura, is based on Karaf.
At least version 2.0 is. Maybe this can also be a pointer for you to look
at.
regards, Achim
2017-01-02 1:37 GMT+01:00 Brad Red Hat <br...@redhat.com>:
> I was looking at the Kura project for future development and a move toward
> IoT development. Unfortunately I have several issues with the project
> which are not going to be solved by simply becoming a contributor. It made
> me wonder if there’s been any discussion about a similar project using
> Felix/Karaf/Camel/Maven and related plugins? It isn’t even that the
> projects necessarily need to be competitive. Many things like driver
> libraries could be shared. Since the Kura drivers should already bundles
> repurposing or simply using them shouldn’t be that difficult.
>
>
>
> There are a few aspects of a Felix/Karaf/Aries that lend themselves to
> such an implementation. The Karaf 4 profiles mechanics are a perfect
> mechanism for creating a testable, self-contained application that can be
> run on a developers machine during development and then the zip file can be
> moved to whatever device one is working with and unzipped. That’s about as
> easy an installation as I can think of. Since that minimalist karaf 4
> implementation is so small and the provisioning is static at compile time
> it hits the nail on the head. When I put together a project recently and
> included CXF and a number of other libraries the whole thing was about 30MB.
>
>
>
> The PAX CDI mechanisms make wiring up beans and routes a lot easier. That
> certainly could make writing applications for small devices a lot easier.
>
>
>
> Just one simple example from the sample code:
>
>
>
> GPIOPinConfig pinConfig = new GPIOPinConfig(
>
> DeviceConfig.DEFAULT,
> //GPIO Controller number or
> name
>
> 17,
>
> //GPIO Pin number
>
> GPIOPinConfig.DIR_INPUT_ONLY,
> //Pin direction
>
> GPIOPinConfig.MODE_INPUT_PULL_DOWN,
> //Pin resistor
>
> GPIOPinConfig.TRIGGER_BOTH_EDGES,
> //Triggers
>
> false
>
> //initial value (for outputs)
>
> );
>
>
>
> GPIOPin button = (GPIOPin) DeviceManager.open(GPIOPin.class, pinConfig);
>
>
>
> Seem to beg for OSGi services (DS or blueprint), annotations, and simple
> cfg files. Something like that GPIOPin or even a GPIO connector could
> really be injectable OSGi services with all the configuration tucked in the
> cfg or with defaults in blueprint properties or DS annotations. Somehow I
> suspect the DeviceManager is not a service factory but I didn’t dig in.
> There were too many parts of the project that really didn’t appeal to me.
>
>
>
> In any case, there’s probably some discussion about this already.
>
>
>
> Brad
>
>
>
>
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master