Pi4J / pi4j-v1

DEPRECATED Java I/O library for Raspberry Pi (GPIO, I2C, SPI, UART)
http://www.pi4j.com
Apache License 2.0
1.3k stars 446 forks source link

add server mode #11

Open teichsta opened 11 years ago

teichsta commented 11 years ago

first of all, thanks for this great work, Robert et al!

It would be great if pi4j would offer kind of server mode to query the raspi resources from other devices in the network.

When understanding the RasPi as an Multiinterface-Gateway it would do a great job in the homeautomation area. But in that case there will be multiple RasPi's available in the network (at the heating, at the main switch board, etc.). So each of them should be queryable with an e.g. lightweight REST-Interface.

Integrationsplatforms like openHAB (www.openhab.org) could than query all available RasPi's and compute their values in rules, graphs, etc.

What do you think?

kermitas commented 11 years ago

That's why I asked Robert about something like TcpGpioProvider at RaspberryPi forum, please see Robets response http://www.raspberrypi.org/phpBB3/viewtopic.php?p=225213#p225213 .

It would be great if Pi4J will be developed as two layer system (almost headless server and client).

I have wrote REST monitoring server (RPi + usb webcam, V4L4J library) using Jetty + Jersey + Jackson. Works good on RaspberryPi (of course we all know RPi's USB problems, but speaking of Java and J+J+J - this works good).

This what you wrote ("..query the raspi resources..") for Arduino is called Firmata (http://firmata.org/). You can also wrote your own functions (C, C++) and connect them to firmata, then execute/query them from outside world.

savageautomate commented 11 years ago

I have not gotten very far on it, but I did start an OSGi service implementation where I planned on exposing GPIO control via OSGi services. In this framework any other OSGi bundle could be created to make GPIO externally accessible via TCP / REST / SOAP / etc. I did load Apache Karaf on the Pi and was using that as my OSGi container. A bit slow to load but seemed to work well once up and running.

Running as an OSGi service and running the container as a server, Pi4J would be a "service" running on the system that other applications could consume.

teichsta commented 11 years ago

Hi Robert,

we could use openHAB as OSGi-"Runtime" (Kai - founder of openHAB.org - came up with this idea yesterday)! All we have to do is to create a so called "binding" which binds hardware to the openHAB event bus which should be no big deal because we have PI4J ;-). The complete architecture is meant for use cases like this. A REST-binding is also in place already.

Admittedly the current runtime (based on eclipse equinox) is not (yet) optimized for embedded systems like the RasPi. But we have quite a few users running their openHAB instance on a RasPi already. Probably we have to create a new assembly which doesn't contain all the UI stuff which won't be necessary for the "remote" nodes. One (openHAB)-Node in the network would then run the complete openHAB-HA-Stack.

What do you think?

Cheers,

Thomas E.-E.

savageautomate commented 11 years ago

Interesting. I need to do some reading on openHAB and learn more about it.
The pi4j-service is just a plain OSGi bundle and should run under any OSGi container.

doit4fun commented 11 years ago

hi guys, I want to build the same tihing except that I want to crate a client-webservice applicaton that integrates the GPIO and sends de values to a webservice (SOAP or REST haven't decided yet). The difficult part was done (project Pi4j). I wonder if I can make a webservice client (with the current JDK 1.7 not embeded one) that sends data to a webservice (running separately, bulilt in java) present local on Raspberry.

What opinion have on this?

valdar commented 11 years ago

Hi, making a webservice client in most cases is making an http call. I bet you can find a lot of java library that can run on Pi to accomplish this task.

doit4fun commented 11 years ago

youp this is true, but if I'm using SOA protocol based then I need to send XML format and for this I need to do a client, maybe with JAX WS? but don't know if the JDK 1.7 is abel to do this. I know that JAX comes by default starting with JDK 1.6. I don't know about the JDK 1.7 SE that comes for raspberry

doit4fun commented 11 years ago

and another thing... I've seen that are 2 versions of JDK, one SE and one embeded. If I'm going to use the embedded one then probabby I'm not going to have the acces cu webservice library or is it available?

The thing is that the project PI4J allowed me to use the simple Java 1.7 SE. By the way( tks a lot) Don't know if JDK Embeded has libraries for webservice or for GUI applications

Does anyone know the differences?

michaeljquinn commented 11 years ago

JDK embedded does not support JNI, which u need for wiring and serial

FDelporte commented 5 years ago

FYI, started experiment with Spring and REST, see https://github.com/FDelporte/pi4j/blob/develop/2.0.service/pi4j-service/src/main/java/com/pi4j/service/rest/Pins.java

Absolutely no idea yet if this will work, but is a nice experiment for myself at this point ;-)

valdar commented 5 years ago

Why not using something like https://www.eclipse.org/kura/ which runs on Apache Karaf and already install on raspberry?

FDelporte commented 5 years ago

Well, I don't know Kura and want to experiment with Spring, so that's the main raison ;-) As it is a fork we can see were this leads to or just dump it later when I'm done experimenting...

savageautomate commented 5 years ago

I believe we intend to tackle this in version 2. As for if a Kura integration, REST service, or whatever API layer is most suitable, I'm not sure yet. I do like the idea of a pi4j micro service layer that provides access to the raw I/O and optionally exposes that over the network for remote development purposes as well as remote GUI apps, etc. Whatever we end up with will need to be fairly simple and lightweight and will need to accommodate near real time events and messaging for things like GPIO state changes, serial data events, etc. I was initially thinking some form of basic TCP socket or websocket API layer as the raw communications layer for this microservice API. Perhaps also a REST API layer for basic queries as well.