karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Red Hat" <bradj...@redhat.com>
Subject RE: Karaf IoT
Date Wed, 04 Jan 2017 21:56:36 GMT
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,
	GpioPinDigitalMultipurpose motionStatusLed = gpioController.provisionDigitalMultipurposePin(RaspiPin.GPIO_05,


-----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 <maggu2810@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,
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 :-(

View raw message