New binding: panStamp wireless Arduino modules

This is interesting.

I googled a bit and think that what happened to you is a known problem with Java serial IO on the Raspberry Pi. The binding uses nrjavaserial which is a fork of RXTX to do serial IO. It seems that RXTX and it’s derivatives assume that your serial port will be named /dev/ttySx or /dev/ttyUSBx and simply won’t pick up (they refer to enumerate) other ports. This is annoying given that you actually pass in the name of the port you want to use!

The recommended workaround is to pass the name of the serial port to Java using a property like
-Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0

I like your solution however, it’s not like ttyS0 wil suddenly appear on the Pi since the hardware doesn’t exist.

Reference: http://angryelectron.com/rxtx-on-raspbian/

So you’ve got the comms fixed, does the binding work for you?

I’m now using udev to automatically create a symlink from /dev/ttyS0 to
/dev/ttyAMA0 and it seems to be working quite well.

It seems that the binding is working in general but unfortunately I had
some issues with my client device and couldn’t test it properly yet.

Additionally it seemed I had huge performance issues yesterday that need
further investigation. It started after getting the panstamp binding
working but not sure whether it is really related to the binding.

I will give it a new try this evening and let you know.

I’ve updated the binding based on the code review @watou did, and also included a new version of the underlying panstamp library to fix some issues reported by the panstamp lead developer.

I would appreciate it testers would try the latest build from here: https://github.com/AutoMates/openhab-panstamp-test

Ok ultil now, running since yesterday evening.

Thank you for the update! Still going?

Hi,
I wanted to test this binding and i have an RGBdriver board.
Could you give me an example of how i could use it with openhab?
I found that of the product code i have to take is 1/3, but if i try to use the switch example I get unsupported command type OnOffType.

I’ll look into this. Can you please post your item configuration?

Sure :slight_smile:

here it is:
Color RGBlevel “RGBled” { panstamp=“address=1,productCode=1/3,register=11,endpoint=‘RGBlevel’” }

I saw that the RGBdriver boards are no for sale anymore, do you know if there will be new produced for the panstamp4?

Any news on this?

Hello!

I am newbuy here. I have a Panstamp and do some automatization on the end devices, but do not have “command centre” (lagarto max is suxx for me).

At this moment I try use OpenHub as main part, but Panstamp have change Lagarto Swap to support MQTT.

And can you say rigth way - run lagarto-swap MQTT+mosquitto+OpenHUB MQTT or simply OpenHUB Panstamp Binding?

Thanks!

@Serg It depends on what you prefer. The idea is that users should be able to run openHAB with the panStamp binding and not need Lagarto.

I connect my pastamp’s to OpenHab, and last week try to write simle rules.
But have some strange errors.

I use customized Panstamp devices. First I use modifed JulianV onewire, but use much more DS18B20 (2 bytes for each).
Also I use some like Panstamp/binouts but use B.b format in xml for each switch.

In events log i see a very strange:
2016-02-16 18:20:00 - Temperature_C_PC state updated to 21.300000000000000710542735760100185871124267578125

2016-02-16 18:20:00 - Temperature_C_PC state updated to 21.70000000

I don’t understand why format is changes.
I Update every 30 sec just for testing and recive different format

I see this for all Temperature from DS1820 (as for me JulianV onewire use 2 byte format and this too long for it )

Also sometimes i recive wrong tempersture values (19 not 21), which stay correct after 5-10 sec. And after 10-20 minutes all ok (Prevision I use lagarto, and do not change any code on the end device, and in this case all tested and must be ok)

Another case - switch(relays) update.

2016-02-16 18:10:00 - Light_GF_Corridor_Point state updated to OFF
2016-02-16 18:10:00 - Heating_GF_Balkon state updated to ON
2016-02-16 18:10:00 - Light_GF_Balkon_Main state updated to OFF

But, Light_GF_Balkon_Main and Light_GF_Corridor_Point state 100% not chages.

It always update some?? switch.

2016-02-16 18:00:35 - Light_GF_Zal_Main state updated to ON
2016-02-16 18:00:35 - Light_GF_Zal_Second state updated to OFF
2016-02-16 18:00:35 - Light_GF_Kitchen_Main state updated to OFF
2016-02-16 18:00:35 - Light_GF_Corridor_Podsvetka state updated to OFF
2016-02-16 18:00:35 - Light_C_PC_Main state updated to OFF
2016-02-16 18:00:35 - Light_C_PC_Full state updated to ON
2016-02-16 18:00:35 - Light_GF_Corridor_Main state updated to OFF

Touch just one, update different. In each update I send 2 bytes (state of 16 relays, total 32 relays for one panstamp)

May be I do not clear write, sorry my English
Can explain more precision and show codes/full logs. If you need it.

@gideon, are @cddoma’s issues related to the binding or are his customized devices the root cause?

Hm, return to lagarto+MQTT?
In current way, my SD card on raspberry pi, will die after some week…

I am a relative newcomer to the Panstamp world, and have recently been trialing the SWAP + OpenHAB ecosystem. I was successfully receiving temperature values from a remote panstamp for a few days, but suddenly the values stopped making it to OpenHAB. I couldn’t get the flow of data working again, and tried a different Panstamp. This also didn’t work, but I finally worked out that the device id had changed from 97 to 112, and after an update of my .items file, I was away again. My question is, where is is the device id found? Is it a hidden id that is tied to each Panstamp? I would have thought it comes from devices.xml, or product.h, but for my device, the dev id and SWAP_PRODUCT_ID are both 1! For context, here is a quick excerpt from the OpenHAB log, showing the old and new device id…

2017-10-09 13:41:31.482 [INFO ] [ng.panstamp.internal.PanStampBinding] - TCP Debug enabled on port 3000
2017-10-09 13:41:31.563 [DEBUG] [ng.panstamp.internal.PanStampBinding] - Added device 97 to network
2017-10-09 13:41:31.564 [DEBUG] [ng.panstamp.internal.PanStampBinding] - device detected: 97
2017-10-09 13:41:31.566 [DEBUG] [ng.panstamp.internal.PanStampBinding] - addDevice(97 (59/1)
201

2017-10-11 00:04:24.582 [INFO ] [ng.panstamp.internal.PanStampBinding] - TCP Debug enabled on port 3000
2017-10-11 00:04:24.663 [DEBUG] [ng.panstamp.internal.PanStampBinding] - Added device 112 to network
2017-10-11 00:04:24.669 [DEBUG] [ng.panstamp.internal.PanStampBinding] - device detected: 112

Hi

I think you are mixing up things here.
The product ID defined in product.h defines which kind of device it is (temperature sensor, rgb board, etc) and is used in devices.xml to tell openhab how registers look like.

The figure you can see in your openhab log is the device address which is needed by modem/openhab to address the right physical device. Not 100% sure where this comes from but afair this is given by modem based on the currently free addresses in the network at first connect.

If you are exchanging physical device you need to change address in your item binding config in openhab so openhab uses new device

Thanks for the explanation Olti. I certainly didn’t expect that the modem would be generating the id from a free list, but I guess I could always just look at the code.