I agree. Hopefully I'll have some time in the future and will be able to make a convincing argument for it in the Kura group. Time being what it is...
If I make a quad helicopter or industrial valve controller, I don't want to provide configurations in consumer bundles for every possible controller board out there with intimate knowledge of the pin outs of that board. What I want is the named pin of the correct type. That means I'd have to create the properties configuration for a number of different board types but it would be limited to that single configuration file for the boards. Everything consuming from that would be at an appropriate level of abstraction that doesn't care about the board level details. The motor controller needs a GPIODigitalPWMPin of with a configurable name identifier to connect the service exported from the board to the consumer motor controller. If I have four motor controllers for my quad copter, then in like fashion I want to export the motor controllers with appropriate identifiers - "left front, left rear, right front, right rear" that my controller logic can consume. That higher level logic isn't concerned about pulse widths to the pins, just some percent power or other appropriate metric. The motor controller, doesn't care about the board level configuration details and pin outs, it simply wants to set a pulse width to a certain value. The board level configuration then has the details about what pin that pulse width is routed to. Services are exported out for higher level consumption, control signals flow down the abstractions to the lower levels. The same level of abstraction would be true for sensors but the signals would travel up from pins to sensor controllers up to higher level logic that would know what the meaning of the sensor value is. The physical sensor sends a voltage high on a given pin, the board configuration has exported some pin as a certain type with a given name, the controller logic for the sensor references that pin and interprets it to some meaning (perhaps a level for the given sensor type), the higher level logic interprets that as "holy, sh*t there's an overpressure condition in the turbine." If the pin can't send events, then the sensor controller might poll the pin and fire events making no assumptions about what the receiving logic is about. Those levels of abstraction would permit use of multiple board types for sensors and actuators. Standardizing those exports would permit standardizing service interfaces for different types of sensors and actuators. That would permit manufacturers of various types of sensors and actuators to create a single controller for their component that receives the appropriate pin type of a given ID and then exports a given interface for upstream use. MotorController, LED, RFIDSensor, etc. could all become standardized interfaces then that disparate manufacturers could use to provide those capabilities to their clients. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Sunday, January 15, 2017 3:21 PM To: [email protected] Subject: RE: Karaf IoT 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:[email protected]] > Sent: Wednesday, January 4, 2017 8:24 PM > To: [email protected] > 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_Service > s > [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 :-( >>>> >>>> >>>> >>>> >>> >> > > >
