Common Components library / extension / plugin

[basil-dsouza]

Hey guys,

I just discovered pi4j V2 last week and was really impressed by it. The level of documentation, the quality and structure of the code and the thought put into the architecture (especially separating out the components that were there in v1) were all of a very high quality. Seemed more like an enterprise quality product in my opinion.

Most of my background is in Java (more than 2 decades of it) and after trying to implement my Pi projects in python or JavaScript for so long, this was a breath of fresh air.

I have a question though, all those components that you removed from v1, seem to have been implemented in the crowpi sample repo. However many of those components are pretty standard, and it would be handy to have these in a proper library that can be plugged in. Or at the very least as a generically named additional project that can be added as a maven dependency.

Is this something you've already given a thought to? I haven't read your implementation in detail, but I was planning on writing several of these components for my robot project anyways. My bandwidth for hobby projects is quite low, but if any of my work helps, then am happy to share that back for addition to the work you've done.

The main work, as I see it, is to structure most of your existing components such that it isn't directly associated with crow pi or an "example" project. So essentially moving "components" to a top level package, and cleaning out any crow pi related stuff. Then the remaining crow pi code could include the new component project as the dependency.

[FDelporte]

Thanks for your kind words!!

Removal of the components was decided to make V2 of Pi4J focus on the GPIO interfaces themselves. Maintaining all the extra code for all types of components made the library heavy to maintain and test. But because of the modular approach, there is the possibility to create providers for one or more components.

How this can be done, is part of an ongoing issue at this moment: #138

@savageautomate has created a prototype project https://github.com/savageautomate/pi4j-plugin-microchip

If you want to contribute such a component provider, we could do this as a new repository within the Pi4J project, or refer to a project within your GitHub account.

As the CrowPi examples were created within the FNHW University, they focus on usability within their teaching projects, but they are very extensible and adaptable. The goal is still to translate their German documentation and add it to the Pi4J website. Hopefully soon...

Looking forward to your contributions!
Frank

[basil-dsouza]

I agree with your point about not wanting to keep them in the same repo as the core code for maintainability reasons. However, I haven't yet understood how to provider interface works. Based on what I've seen, it seems like you look up a provider and then pass the "config" object to it to instantiate the device (as described here: https://raw.githubusercontent.com/Pi4J/pi4j-v2/master/assets/draw.io/pi4j-v2-architecture.jpg).

While this makes sense for lower level items (like different GPIO extenders, special kind of pins, etc), I feel there needs to be a higher level layer / framework that allows you to build components that use existing pins or other higher level components. For example, If I was to build a "Motor", with one forward and backward (and perhaps an enable pin), then all I need is those 2 pins. No need to actually register it as a "motor-provider" or something. Taking that thought further, if I want to then build a "Robot", all I need is 2 Motors, don't even need to know which pins it is using. I tried writing something like this today, which went well for Motor and Robot, but soon as I got into the sensors I got stuck in analysis paralysis. Hopefully I get out of that soon and can share some more code samples.

MotorFactory:

@RequiredArgsConstructor
public class MotorFactory {
    private final Context context;
    private static PwmType DEFAULT_PWM_TYPE = PwmType.SOFTWARE;
    private static String DEFAULT_PROVIDER = "pigpio-pwm";

    public Motor newMotor(String motorId, int forwardPin, int backwardPin) {
        return new Motor(createPin("forward-" + motorId, forwardPin),
                createPin("backward-" + motorId, backwardPin));
    }

    private Pwm createPin(String motorId, int pin) {
        var pwmPinConfig = Pwm.newConfigBuilder(context)
                .id("motor-pin-" + motorId)
                .name("Motor Pin - " + motorId)
                .address(pin)
                .pwmType(DEFAULT_PWM_TYPE)
                .shutdown(0)
                .initial(0)
                .provider(DEFAULT_PROVIDER).build();

        return context.create(pwmPinConfig);
    }
}

Motor:

@RequiredArgsConstructor
public class Motor {
    private final Pwm forwardPin;
    private final Pwm backwardPin;
    private static final double MAX_SPEED = 1.0;
    private static final double MIN_SPEED = 0.0;

    public void forward(){
        forward(MAX_SPEED);
    }

    public void forward(double speed){
        //TODO: Verify range
        forwardPin.on(speed * 100.00);
        backwardPin.off();
    }
    public void backward(){
        backward(MAX_SPEED);
    }

    public void backward(double speed){
        //TODO: Verify range
        backwardPin.on(speed * 100.00);
        forwardPin.off();
    }

    public void stop(){
        forwardPin.off();
        backwardPin.off();
    }
}

[savageautomate]

@basil-dsouza

The concept of higher level object abstractions such as MOTOR, LIGHT, RELAY, SWITCH and the like were part of the components and devices API in Pi4J v1.3 and earlier.

• API classes: https://github.com/Pi4J/pi4j-v1/tree/release/1.3/pi4j-device/src/main/java/com/pi4j
• LCD Example: https://github.com/Pi4J/pi4j-v1/blob/release/1.3/pi4j-example/src/main/java/LcdExample.java

We decided not to carry these forward in Pi4J V1.4 & V2 as there did not seem to be many people using these and they were largely incomplete. The main driving factor was to narrow focus for what Pi4J was intended to accomplish and deliver a more maintainable and updated version of Pi4J. I still think the concept of higher level abstraction objects/APIs are a good idea, but they probably belong in a separate subproject and not part of the Pi4J core framework.

I'm not sure the project maintainers (@FDelporte , @eitch, @savageautomate ) have the bandwidth to take this effort on at this time as there are still parts of the core APIs and framework that need to be completed. Perhaps if you are interested you could take the old Pi4J v1 component and device codebase and create a new standalone project porting it over to Pi4J V2 APIs.

Thanks, Robert