Detect the platform (type of Raspberry Pi if applicable) Pi4J is executed on

[dmfrey]

I'd like to create a Spring Boot Condition to detect if the code is running on a real pi. Does the Platform hierarchy allow you to detect what is present?

I'd like to do this so that RaspberryPi context doesn't automatically get registered when the platform is not found.

This will also help with testing when I can override with the MockContext.

[FDelporte]

A "dirty approach" is to catch an error when initializing the context because that will fail when not on Raspberry Pi.

On the other hand, that is exactly what I imagined to do with https://github.com/Pi4J/raspberry-pi-info, detect the board type / version to be able to provide extra info regarding pin layout etc.

[dmfrey]

@FDelporte I think I can play with this. I'd like to wrap it in a SpringBootCondition and then create an @ConditionalOnRaspberryPiPlatform (or something similar to the @ConditionalOnCloudPlatform) in the spring-cloud project.

[FDelporte]

FYI @dmfrey that library is still work in progress, it's also the basis for https://api.pi4j.com/web/, a Spring+Vaadin application, sources in https://github.com/Pi4J/raspberry-pi-info-service

[dmfrey]

@FDelporte I'd be happy to help with writing some spring boot autoconfiguration

[dmfrey]

So the question would be what's the most appropriate way to detect that the code is running on a particular platform?

[FDelporte]

In SDKMAN I extended this part :

https://github.com/sdkman/sdkman-cli/blob/448d3c00eb9aad422a524612d7e580745dcab735/src/main/bash/sdkman-init.sh#L42

to detect which processor type, can be a good starting point to do something similar

      armv6l)
        echo "LinuxARM32SF"
        ;;
      armv7l)
        echo "LinuxARM32HF"
        ;;
      armv8l)
        echo "LinuxARM32HF"
        ;;
      aarch64)
        echo "LinuxARM64"

more info on https://foojay.io/today/installing-java-with-sdkman-on-raspberry-pi/

[dmfrey]

@FDelporte it sounds like I could use the os.arch environment property to drive this out. I'll build an autoconfiguration library around this.

Ultimately, I see this as a way to establish the Pi4J Context and exposing that to the Spring context.

[FDelporte]

Could you make this as generic as possible? Then indeed, we could integrate it into the project itself, and you could build a spring context on top of that.

[MBOIX]

@dmfrey I use Ktor and Pi4J in the same app, and Kodein as dependency injection. This code works fine and allows me to use an implementation of Pi4J in a case of the code running on the Pi, if not it's the mock implement which is used.

fun Application.rpiModule() = rpiModule(
    DI {
        when (System.getProperty("os.name")) {
            "Linux" -> bind<Platform>() with singleton { PlatformPi4J() }
            else -> bind<Platform>() with singleton { PlatformMock() }
        }
    }
)

I think it's adaptable easily with spring boot ;)

[eitch]

We now have a solution for this:

BoardInfoHelper.runningOnRaspberryPi()

And thus on a non-rpi, native libraries aren't loaded anymore.