New binding: panStamp wireless Arduino modules

Hi guys

I have written a binding for the panStamp wireless Arduino modules.

For those who don’t know panStamp, they are very light weight wireless Arduino modules which use a protocol called “SWAP” to communicate. The panStamp radios run Arduino sketches, and can plug into a variety of pre-built carrier boards, or can be installed into custom projects. Their website has more information

I have submitted pull request #3187 for this, and have added a wiki page too. I’ve tested the binding against openHAB 1.7.x and with the openHAB 2 compatibility mode as well.

1 Like

Waiting for this to be ready :grinning:
Is that stable already, are there known problems ?

I run the binding on 1.7.x and it is quite stable and I am not aware of any problems.

1 Like

@gideon, could you make a test build of your JAR available to download for @bzaharie and others, for testing and feedback? The CI system for building pull requests is not currently running I don’t think.

I have a repository with a binary build and example configurations here
It should contain anything anybody needs to test the binding, including a bit of documentation :slight_smile:

1 Like

Have you had a chance to try this new binding, Bogdan? If so, does a good exercise of it seem to work for you?

Nope, I’ll let you know as soon I get the time to use this binding as I want to setup another openhab instance in order not to alter my running system


Works ok with binouts2 until now. I’ll check next days with the sensors.
Do you save somewhere the network, like python apps save swapnet.json ?

Not currently.

You really want that if you have auto-discovery and auto-configuration. While the panStamp/SWAP architecture allow for that, openHAB 1.x doesn’t really. So in the end you end up hard-configuring an endpoint with address, register and endpoint name and the only thing you can save state for is the product code register.

I do not really need that, I was asking that to see if I still need the setup of python tools in the future or I can rely on your binding only.
So I’ll stick on tools from Daniel for configuring network and others.
Anyway, thanks again for implementing this binding !
I’ll do some more tests following days

You can of course use Daniel’s tools for network configuration. But if you’re using the panStamp binding, there is another option:

The panStamp binding provides an optional feature to allow the user to configure or debug the panStamp network using a GUI tool while openHAB manages the network (and therefore owns the serial port). This option is enabled by providing the panstamp:debug.port configuration parameter. Doing this has the upside of being able to change panStamp configurations without stopping openHAB or without using a separate panStick.

The GUI tool can also run stand-alone (without openHAB) via a serial port. The GUI tool can be found on GitHub.

Yes, it does work, great !

Some problems I saw until now (Win 8.1 x64):

  1. When running it for the first time from exe file the dialogue “Add network…” does not appear with apparently no error, but running it from console there is an exception thrown because rxtxSerial.dll is not available. I installed that and could go further

  2. Initially the same add network wizard gives an error that it cannot connect to the server - tried that several times with no success. I did try to connect to that debug port with a raw tcp client, I could do that. After closing my raw connection also the wizard could connect

Both of these errors are strange.

  1. It should not be looking for rxtxSerial.dll. The exe includes a pre-packaged copy of nrjavaserial and should load libNRJavaSerial.dll from the jar.

  2. Makes no sense at all

I saw later that on openhab console there was an exception thrown continuously until I closed it. Unfortunately I have no log for that, but was something coming out from panstamp binding.

I’ll post the exception log here if I get it again

Here it is. Comes into opehnab console after I close the GUI Connection reset
at Source) ~[na:1.8.0_51]
at Source) ~[na:1.8.0_51]
at sun.nio.cs.StreamDecoder.readBytes(Unknown Source) ~[na:1.8.0_51]
at sun.nio.cs.StreamDecoder.implRead(Unknown Source) ~[na:1.8.0_51]
at Source) ~[na:1.8.0_51]
at Source) ~[na:1.8.0_51]
at Source) ~[na:1.8.0_51]
at Source) ~[na:1.8.0_51]
at Source) ~[na:1.8.0_51]
at me.legrange.swap.tcp.TcpTransport$ ~[na:na]
2015-10-05 23:51:31.329 [ERROR] [legrange.swap.tcp.TcpTransport] - null

Happens also when trying to connect from the same machine or a different machine

When running the client from the sme machine where rxtxSerial.dll was never installed, this problem does not appear. Only the exception at exit is still there.


I’m glad to see that there is finally a binding supporting panstamps in openhab. Thanks for the effort there.

I’m running openhab 1.7.1 on a raspberry pi which also has a shield for raspberry pi connected to it to act as a modem in a panstamp network.

Unfortunately I get the following error in openhab log when using your binding:
07:23:37.526 [DEBUG] [o.b.p.internal.PanStampBinding:248 ] - startNetwork()
07:23:37.554 [INFO ] [ :333 ] - static CommPortIdentifier:getPortIdentifiers()
07:23:37.585 [INFO ] [ :355 ] - RXTXCommDriver:initialize(), osName: Linux
07:23:37.599 [INFO ] [ :466 ] - scanning device directory /dev/ for ports of type 1
07:23:37.639 [ERROR] [o.b.p.internal.PanStampBinding:267 ] - Error reading modem settings for serial network on /dev/ttyAMA0: Could not find serial port ‘/dev/ttyAMA0’

Did I configure something wrongly?

Unfortunately I don’t have a free panstamp to give it a try with panstick connected to USB.

Thanks & Regards,

Does your openhab user belong to the dialout group?

sudo usermod -a -G dialout openhab

A normal “apt-get” install of openHAB runtime on Raspberry Pi should run as the openhab user, which will need permissions to access the serial port. Adding the openhab user to the dialout group usually achieves this.

Yes it belongs to dialout group. Double checked that.

I’m logged in as user openhab most of the time and I’m also able to run swapdmt from the python tools.

UPDATE: I created a symlink called /dev/ttyS0 which points to /dev/ttyAMA0 and error is gone.
Any idea why it depends on the name or did I find a bug?