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 Thu, 05 Jan 2017 03:03:27 GMT
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 <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