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:sle...@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:l...@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 <bradj...@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:l...@code-house.org] >>> Sent: Wednesday, January 4, 2017 2:54 PM >>> To: user@karaf.apache.org >>> Cc: Markus Rathgeb <maggu2...@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.g...@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 :-( >>>> >>>> >>>> >>>> >>> >> > > >
