Closed GoogleCodeExporter closed 8 years ago
Original comment by teichsta
on 22 Feb 2013 at 8:42
Original comment by teichsta
on 7 May 2013 at 3:48
Original comment by teichsta
on 7 May 2013 at 8:06
reference for PiFace is: http://www.savagehomeautomation.com/piface
Original comment by teichsta
on 7 May 2013 at 8:07
I have made a start on this. I am taking the approach of running a simple
Python script on the Pi based on https://github.com/thomasmacpherson/piface. In
particular the pfion module which runs a simple UDP listener.
I then intend to build a binding which will post UDB packets across the wire
from openHAB to read and update states on the PiFace board.
I would also like to extend the pfion module to poll the PiFace pins and
asynchronously send state update messages back to openHAB so we have true
bi-directional communications.
As a result I don't intend to use the Pi4J libraries at all. I tried installing
them and running the examples but I could not get the 'input' side of things
working. I was able to turn on LEDs but couldn't read the input pins. So I
decided to move back to the Python modules which seem to work fine for me.
Original comment by ben.jone...@gmail.com
on 14 May 2013 at 8:39
I have just pushed the first version of the PiFace binding. In order to use
this binding you need to install the pfio/pfion python libraries on your
Raspberry Pi (instructions here https://github.com/thomasmacpherson/piface).
I have written two python scripts which also need to be installed on your
Raspberry Pi - one is a UDP server/listener which the binding sends commands
to, and the second is a monitor script which polls the PiFace pins for changes
and broadcasts UDP messages when a change is detected - this gives the binding
bi-direction/asynchronous messaging.
The two scripts are attached. They should be started as follows;
>python piface_listener.py 15432 &
>python piface_monitor.py 15433 &
Where 15432 and 15433 should match the ports defined in your config file (see
below).
To configure the binding you need to add the following to your openhab.cfg file
(where <pifaceid> is any string that you use to link your items to a particular
PiFace - i.e. it should support multiple devices);
piface:<pifaceid>.host=<pifaceipaddress>
piface:<pifaceid>.listenerport=15432
piface:<pifaceid>.monitorport=15433
And then setup your items as;
Switch OutPin0 "Output Pin 0" <light> (PiFace) {
piface="<pifaceid>:OUT:0" }
The idea is you can create items for any of the 8 input and/or output pins. You
can only send commands to output pins - for obvious reasons.
I have this running on my openHAB server with a single PiFace board. I can turn
on/off any of the output pins via the openHAB UI, and any changes to the input
pins are updated in the openHAB UI. I haven't actually hooked anything useful
up to it yet...that is the next job!
A few things TODO;
1. I had some code to read the states of all pins when the binding starts up
and update any linked items. However the binding seems to startup well before
the item list is initialised. Is there a way to hook into when the items are
loaded so I can run this initial pin state request? Means that when openHab is
started we can automatically retrieve the state of all pins since they might
not all be OFF.
2. Somehow bundle up the Raspberry Pi python scripts so the installation is not
such a manual process. I guess I could build an SD card image and upload this?
Original comment by ben.jone...@gmail.com
on 19 May 2013 at 3:42
Attachments:
Here is a list of instructions for configuring the Raspberry Pi for the PiFace
binding.
Original comment by ben.jone...@gmail.com
on 19 May 2013 at 10:39
Attachments:
[deleted comment]
[deleted comment]
[deleted comment]
Original comment by kai.openhab
on 2 Jul 2013 at 4:49
I have abstracted out UdpServer.py which is used to interface with this
binding. This script takes a call back which allows various IO methods to
receive commands from openHAB via the binding. I have written two servers, the
original PiFace one and a new raw GPIO one. This allows you to run the script
on a vanilla Raspberry Pi with devices connected to the GPIO pins directly.
This interface is very simple, just an id + value, so ideally suited to simple
IO interfaces. It may well be useful for other devices other than the Raspberry
Pi, and as such might be better named something else?
Original comment by ben.jone...@gmail.com
on 23 Jul 2013 at 9:42
Attachments:
Ben, are there any further enhancements that are probably not checked in? I am
going to start the review today or tomorrow … Regards, Thomas E.-E.
Original comment by teichsta
on 7 Aug 2013 at 1:45
Nope - I think it is all in there. There are the extra python scripts which you
need to run on the Pi itself (attached to this item) which is not ideal for a
simple 'deployment' but I wasn't sure how to build a deployable python package.
I would like to make a couple of changes, in particular to get the binding to
request the current state of the IO pins when starting up. The code is all
there I just need to enable and test it. From memory there were some issues
surrounding the startup sequence when I first tried this so that might be
resolved after the changes to the startup routine in openHAB.
Original comment by ben.jone...@gmail.com
on 7 Aug 2013 at 8:13
[deleted comment]
Thomas - I have updated the python scripts which run on the Pi to make them a
bit easier to install/run. Attached is the latest version including
instructions, a startup script. The client/server threads are now started from
the one script making it a bit easier to deploy.
Original comment by ben.jone...@gmail.com
on 11 Aug 2013 at 12:13
Attachments:
Ok - sorry to keep changing things but I have just pushed some final changes to
the binding (to support pin numbers greater than 15!). I have been trying to
get the binding to request the current state of any input pins so the openHAB
bus can be updated, but I am having real trouble trying to figure out when I
should be running this code. It is in there, and commented out, if you want to
have a look. Attached is the latest version of the python/init scripts. I will
leave it for now until you have reviewed it.
Original comment by ben.jone...@gmail.com
on 11 Aug 2013 at 6:04
Attachments:
Original comment by kai.openhab
on 11 Aug 2013 at 7:31
Hi Ben,
thank you very much for this contribution. Please find below my review comments:
# general
* please a wiki page that should also contain the installation howto for the
PiFace Nodes
# Py-Scripts
* please check in the scripts in a folder like "scripts". By default these
scripts should not be included in the binary build of the bundle (see
build.properties) for details.
# PiFaceBinding
* please organize imports
* L79 please rename member according to PiFaceBinding.PiFaceConfig (see below)
* L81 remove empty constructor
* L88 activating the MonitorThread should be done at the end of updated().
Better extract the call into its own method (something like connectAll()) which
could be called explicitly.
* L99-101 extract code into its own method (something like disconnectAll())
which could than be called explicitly.
* L104-133 you could extract initialisation into its own InitializerThread (see
DatapointInitializer in KNXBinding). In addition to DPInit you could feed new
items through bindingChanged() or allBindingsChanged() and restart the
Initializer accordingly. Keep in mind that bindingChanged() is also called when
item has been removed.
* L299 please call the connectAll() method rather than activate() (see comment
L88)
# PiFaceBinding.PiFaceConfig
* please rename PiFaceConfig to something like PiFaceNode
* please rename id to pifaceId for the sake of consistency
# PiFaceBinding.MonitorThread
* please extract MonitorThread to its own class and rename something like "Node
or PiMonitorThread" (according to the PiFaceConfig)
# PiFaceCommand
* please add javadoc, author, version
* please add a short description for each command (or at least provide a link
where one could find a description)
* some of the constants like UNKNOWN and READ_OUT_CMD seem to be unused. Could
they be removed?
* this class seem to be a perfect candidate for an enumeration
# Pin
* please add javadoc, author, version
* since the name Pin is quite ambiguous (it could also mean Personal
Identification Number) could you rename it to something like e.g. GpioPin?
# PinType
* please add javadoc, author, version
* please rename enum according to Pin
Best,
Thomas E.-E.
Original comment by teichsta
on 28 Aug 2013 at 8:10
Thomas - thanks for the detailed feedback!
I will try and get this done by the end of the week, as I am away the entire
following week on holiday.
Original comment by ben.jone...@gmail.com
on 28 Aug 2013 at 9:55
Ok - have completed everything on your list apart from the WIKI page.
https://code.google.com/r/benjones12-latitude/source/detail?r=7d431510e43e44fe9f
c03faf3700f270beccc9f8
Let me know of any further changes you want.
Original comment by ben.jone...@gmail.com
on 29 Aug 2013 at 1:58
And WIKI page done!
Original comment by ben.jone...@gmail.com
on 29 Aug 2013 at 2:21
Merged the binding into default (see
http://code.google.com/p/openhab/source/detail?r=922cf661dfae3b25c2c79fc54c3ce8c
dc701533e).
Thanks Ben for this cool contribution!
A sidenote regarding Wiki-Page: it would be really great to have a section
"demo" where a complete (item) configuration and probably an appropriate rule
is shown. A killer would be to have a short video like at Nikobus or
opensprinkler.
Cheers,
Thomas E.-E.
Original comment by teichsta
on 29 Aug 2013 at 10:03
I have added a complete set of example items/rules which will hopefully guide
people in the right direction. Unfortunately there is not much to show in terms
of a video since all the devices are located away from my Pi and thus a video
wouldn't be all that impressive!
Original comment by ben.jone...@gmail.com
on 29 Aug 2013 at 8:45
WOW that's great!
Thanks for enhancing the Wiki-Page! Will name it as good example to others :-)
Original comment by teichsta
on 29 Aug 2013 at 8:50
Original issue reported on code.google.com by
bjoern.m...@googlemail.com
on 4 Dec 2012 at 3:17