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:[email protected]]
Sent: Wednesday, January 4, 2017 4:25 PM
To: [email protected]
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 <[email protected]> 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:[email protected]]
Sent: Wednesday, January 4, 2017 2:54 PM
To: [email protected]
Cc: Markus Rathgeb <[email protected]>
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 [email protected] 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 :-(
