Blog @ SIB Visions » RaspberryPi

JVx application on embedded devices

rjahn — Thu, 19 Feb 2015 15:58:41 +0000

In the last weeks, we did many experiments with JVx on Raspberry Pi, especially using a Pi as server for JVx applications. Our vision was that the business logic could run on a Pi without Java application server like Tomcat or Jetty. Our example application was a simple sensor recorder. We read temperature data and stored the read data into a JavaDB (on the same device). We knew that Jetty and Tomcat worked on a Pi but it was not necessary to run an application server without web content.

We tried different implementations:

Fun
A recorder class that saved data directly in the JavaDB. A good old Java application with one DBStorage because plain JDBC was painful.
Because JVx can do that
A simple recorder client with embedded JVx server. The client was a simple class with a DirectServerConnection. The server saved retrieved temperature data in the JavaDB.
Production
The same simple recorder client but the server run standalone. The DirectServerConnection was replaced with a Netconnection.

The first implementation was for fun only and not relevant for our tests. Our Pi should be a server that measures data and allows accessing data from JavaDB (for charts). Some real client applications could use the temperature server for integrating temperature data. The same application could use other Sensor data from different RasPis (measuring lux, webcam, ...) - a RasPi (sensor) network.

The big problem was that JVx server didn't work without an application server. It worked embedded and via http, but we didn't have a plain socket implementation. It wasn't a JVx problem because the server component was ready for socket connections but we didn't have a Socket server. We made some experiments with vert.x and the result was a nice socket server. We also used JVx with vert.x Http server. Both implementations are available on GitHub. It worked like a charm but we didn't like the library dependencies. We already had a socket server API for our product VisionX, but it wasn't decoupled. Now it is!

We used the VisionX socket API and merged it in our applications library. After some modifications and bugfixes, in JVx, it's now possible to use it without additional dependencies. It's a simple socket server for JVx server component. We've used this server to run VisionX and had no problems. VisionX is a huge JVx application and if VisionX works, all other JVx applications will work.

It's very simple to use the the socket server:

NetServer server = new NetServer("servername", 556);

server.start();

The server has a main method and you can use it without additional coding. Simply set the system properties server.hostname, server.port.

To open a connection, simply call:

IConnection con =new NetConnection("servername", 556);
MasterConnection appcon = new MasterConnection(con);

appcon.setApplicationName("tempsensor");

appcon.setUserName("user");

appcon.setPassword("password");

appcon.open();

Not really rocket-science and just works!

The only problem was the server name and port configuration, for every client. Not really cool in a "sensor network". So we started a simple Broadcaster. It's a simple class that checks the network for existing servers. It's easy to use on client-side:

List<ConnectInfo> liConInfo = Broadcaster.search("MyAPP");

and the server side isn't too complex:

Broadcaster broadcaster = new Broadcaster();

broadcaster.setServerPort(556);

broadcaster.setIdentifier("MyAPP");

broadcaster.start();

The result contains a list of available hostnames and ports for the first found server. It's still space for a better solution, but I think that's the reason why vert.x uses hazelcast.

To cut a long story short: It's now possible to use complete JVx applications without Java application server, especially on embedded devices like RaspberryPi.

Sure, it's still recommended to use an application server if your device serves web content or a whole web application e.g. with JVx' vaadin UI (see IoT: Window shutter control).

RaspberryPi + 1-wire + i2c + camera and kernel pain

rjahn — Mon, 26 Jan 2015 13:01:58 +0000

Our last research project was real fun: Build a Webcam with temp and light sensor to do some home/office automation.

We took a RaspberryPi model B, temp sensor (DS18B20) and light sensor (TSL45315).

The temp sensor had a 1-wire interface and the Internet had many tutorials to connect the sensor to a RasPi. It should be a trivial job, if you read the tutorials and it should be ready in max. 10 minutes. Should!

The theory wasn't the reality and the tutorials didn't cover our environment, because we had a new Raspbian ISO with kernel 3.16 and 3.18 some hours later.

We tried to connect the sensor as described (with and without pullup resistor, with parasite power and without) but it wasn't detected. It was horrible because the driver was loaded without problems and logged a simple success message.
We didn't find information about the problem because we didn't see an error. It simply did nothing and the filesystem didn't contain the relevant files and directories. Our /sys/bus/w1/devices directory was clean and empty. After some hours error searching, without any ideas we tried an older Raspbian image with kernel 3.6 and our sensor worked out-of-the-box without modifications. We saw additional log information from the 1-wire module which we didn't have with our 3.18 kernel. So we knew that something has changed in the kernel or kernel config...

But we weren't happy because the whole thing should work with an up-to-date setup. After we knew that the kernel caused our problems, we tried to find a solution and found: http://www.raspberrypi.org/forums/viewtopic.php?t=97216&p=676793 (first posting on 2nd page). There was a hint about the device tree. With this information, we found: https://github.com/raspberrypi/documentation/blob/master/configuration/device-tree.md

We disabled the device-tree by adding device_tree= to our config.txt and everything worked after a reboot, with our 3.18 kernel. So far so good.

It also worked with device_tree_overlay=overlays/w1-gpio-overlay.dtb. This option was our preferred one because it didn't disable the device_tree.

After our temp sensor worked without problems we connected the Raspicam and made some tests. Everything worked without problems. The last piece of our project was the light sensor. It was a littly bit tricky to use the sensor with our Pi because the source code example wasn't available for Java/Pi4J, but here it is:

I2CBus bus = I2CFactory.getInstance(I2CBus.BUS_1);
I2CDevice device = bus.getDevice(0x29);
device.write((byte)(0x80 | 0x0A));
byte[] byData = new byte[1];

device.read(byData, 0, 1);
System.out.println(byData[0]);
System.out.println("Power on...");
device.write((byte)(0x80 | 0x00));

device.write((byte)0x03);
System.out.println("Config...");
device.write((byte)(0x80 | 0x01));

device.write((byte)0x00);   //M=1, T=400ms

//device.write((byte)0x01);   //M=2, T=200ms

//device.write((byte)0x02);   //M=4, T=100ms
byData = new byte[2];
while (true)

{

    device.write((byte)(0x80 | 0x04));

    device.read(byData, 0, 2);

    int l = byData[0] & 0xFF;

    int h = byData[1] & 0xFF;

    int lux = (h << 8) | (l << 0);

    lux *= 1;   //M1

    //lux *= 2;   //M2

    //lux *= 4;   //M4

    System.out.println(lux);

    Thread.sleep(1000);

}

We compared the output with an Arduino board and the values were "the same".

It wasn't possible to use the light sensor without required modules. We simply added device_tree_param=i2c1=on to our config.txt and I2C worked. You should install

sudo apt-get install i2c-tools

to verify connected sensors, via:

i2cdetect -y 1

After we thought that everything will work, we put all pieces together: temp sensor, cam, light sensor.
During development, we didn't use all parts together - only the relevant sensor, to rule out errors.

Everything worked fine after starting the Pi, but the cam stopped capturing after some minutes... frustrating.
So again we tried to find an error without detailed information and without logs. We thought it might be a module loading problem and found some hints: https://github.com/raspberrypi/linux/issues/435. But nothing worked for us. The only working solution was: disable the device tree

The whole system is up and running for some days and there we no problems.

We currently don't know what's the problem with the device tree or what we should configure to avoid problems, but if you have similar problems, this posting could help. If you have a working solution with the device tree... leave a comment

Rolladen steuern mit Pi

mhandsteiner — Wed, 12 Jun 2013 08:23:13 +0000

Im aktuellen JavaAktuell wurde ein Artikel über die Ansteuerung von Rolläden mittels Raspberry Pi veröffentlicht. Bei JavaAktuell handelt es sich um ein Magazin des iJUG (Interessenverbund der Java User Groups). Das Magazin richtet sich an Java Entwickler und die Artikel werden von Anwendern, die spezialisten in Ihrem Gebiet sind, verfasst.

Wer die aktuelle Ausgabe noch nicht in seinen Händen hält, kann hier schon mal in den Artikel reinlesen.