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 22:52:56 GMT
Ł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 <bradjohn@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 <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,
> 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 :-(
>> 
>> 
>> 
>> 
> 
> 



Mime
View raw message