search

sky201503 / openhab

Automatically exported from code.google.com/p/openhab
GNU General Public License v3.0
0 stars 0 forks source link

Implement ZWave Binding #265

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
General ZWave Support

Implement binding for ZWave Controller/Device/Network support.

Original issue reported on code.google.com by bmcro...@gmail.com on 29 Apr 2013 at 12:25

GoogleCodeExporter commented 8 years ago 
Grrrr - still can't see any config - I have the following structure;

/opt/open-zwave/config/

which I copied to...

/opt/openzwave-control-panel/config
/opt/openzwave-control-panel/config/fibaro etc

I am running the control panel from..

/opt/openzwave-control-panel/

What am I missing here?!

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 10:28

GoogleCodeExporter commented 8 years ago 
Hmmm. Works for me. Did you check the exact device id's? Figaro is notorious 
for bumping device id's all the time.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 10:36

GoogleCodeExporter commented 8 years ago 
Yep - I added a new line for the latest 2x1.5kW relay as it was missing. But I 
am not getting anything recognised, not even the controller. Is it just a 
matter of copying the files over - don't need to recompile anything?

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 10:37

GoogleCodeExporter commented 8 years ago 
Found a bug which prevented the binding from enqueueing more than one differing 
messages to a wake-up queue. fix provided.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 10:43

Attachments:

GoogleCodeExporter commented 8 years ago 
No. Just read rights on the files.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 10:45

GoogleCodeExporter commented 8 years ago 
GOT IT! Had to delete the config files that the control panel had saved, they 
obviously contained bad references or something that was preventing the code 
'seeing' the new config options. Persistence is key...

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 10:49

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago

Original comment by teichsta on 16 Aug 2013 at 9:11

GoogleCodeExporter commented 8 years ago 
I've updated the wiki with the supported command classes.

Original comment by jwsp...@gmail.com on 16 Aug 2013 at 12:58

GoogleCodeExporter commented 8 years ago 
Hi,

Ben, probably this will make you more happy, cause I think a lot of people have 
different troubles with Z-Wave compatibility (though they call it an open 
standard! :-)
http://www.automatedhome.co.uk/zwave/z-wave-compatibility-guide-choosing-the-rig
ht-home-automation-devices.html

Original comment by belovic...@gmail.com on 16 Aug 2013 at 9:17

GoogleCodeExporter commented 8 years ago 
Thanks! Didn't know it existed. That will probably be useful while developing 
the binding as well.

Original comment by jwsp...@gmail.com on 16 Aug 2013 at 9:45

GoogleCodeExporter commented 8 years ago 
My pleasure! :-)

Original comment by belovic...@gmail.com on 16 Aug 2013 at 9:46

GoogleCodeExporter commented 8 years ago 
Hey Jan - been spending a lot of time with this today. Have managed to install 
a few more nodes and have a pretty solid mesh network operating now. Using 
openzwave control panel I can control all nodes no problem. However the binding 
seems to be having a little trouble. I initially had what is now Node 13 
configured as Node 11 and it was not responding. So I excluded and then 
re-included and it came back as Node 13. Now Node 13 is working fine, but Node 
12 has stopped working. Node 12 was working just fine before. So I don't think 
it is anything to do with the network itself, it seems like something is going 
wrong in the binding. But I am struggling to see where. Attached is my log 
which will hopefully shed some clues as to what is going on. I have to head out 
now so can't continue, but will try and pick this up tomorrow.

Original comment by ben.jone...@gmail.com on 17 Aug 2013 at 4:49

Attachments:

GoogleCodeExporter commented 8 years ago 
That is really weird. Node 12 is not reachable right now. It behaves like the 
battery operated device (except it never wakes up)...

Operation   CallbackID  Client timeout      Server status   Buffer

Ping node 10    6       Yes 1x          0x01 -> To callbackId 22    01 08 00 13 0A 01 00 05 06 EC
Ping node 10    22      Yes 1x          0x01 -> To callbackId 23    01 08 00 13 0A 01 00 05 16 FC
Ping node 10    23      Yes, Discarded      No status?          01 08 00 13 0A 01 00 05 17 FD
Ping node 12    7       No          0x01 -> To callbackId 24    01 08 00 13 0C 01 00 05 07 EB
Ping node 12    24      Yes 1x          0x01 -> To callbackId 25    01 08 00 13 0C 01 00 05 18 F4
Ping node 12    25      Yes 1x          No status?          01 08 00 13 0C 01 00 05 19 F5

I get controller responses that node 12 is unreachable. You're really sure that 
it lists as ready in open-zwave before you switch to openHAB?

I'll try and expand my network here as well and see that I can reproduce 
something, but if the controller tells me that it cannot reach node 12... it 
becomes difficult.

Original comment by jwsp...@gmail.com on 17 Aug 2013 at 8:41

GoogleCodeExporter commented 8 years ago 
If it stays in the probe stage in open-zwave as well, at least the behaviour 
would be the same.

Original comment by jwsp...@gmail.com on 17 Aug 2013 at 8:43

GoogleCodeExporter commented 8 years ago 
All nodes are definitely reporting themselves as ready in the control panel 
(see below). I just restarted openHAB again and both 12 and 13 are reporting as 
dead now. I have attached both the OZWCP and openHAB logs. Do you think it is 
something to do with my mesh network again? Attached is my topology which is 
looking pretty good. Is it possible the binding is missing some messages coming 
back because there are so many now?

One other thing - I noticed some of the log messages are not being formatted 
properly (e.g. 'Incoming command class %s (0x%02x)'). Also it might be quite 
useful to prefix all log messages with the node identifier (if applicable) a 
bit like OZWCP. Would make scanning the logs a lot easier! Just a thought.

Node Id Basic Type  Generic Type        Product Name                            Last Heard  Status
1 *LB   Static Controlr Static PC Controller    Aeon Labs Z-Stick S2                        12:00:00 
PM  Ready
2 LBR   Routing Slave   Binary Power Switch Aeon Labs Smart Energy 
Switch              off 12:00:50 PM Ready
3 LBR   Routing Slave   Binary Power Switch FIBARO System FGS221 Double Relay 
Switch 2x1,5kW  off 12:00:50 PM Ready
8 LBR   Routing Slave   Binary Power Switch FIBARO System FGS221 Double Relay 
Switch 2x1,5kW  off 12:00:50 PM Ready
9 LBR   Routing Slave   Binary Power Switch FIBARO System FGS221 Double Relay 
Switch 2x1,5kW  off 12:00:50 PM Ready
10 BR   Routing Slave   Routing Binary Sensor   FIBARO System FGK101 Door Opening 
Sensor      off 11:59:58 AM Probe1 (sleeping)
12 LBR  Routing Slave   Binary Power Switch FIBARO System FGS221 Double Relay 
Switch 2x1,5kW  off 12:00:50 PM Ready
13 LBR  Routing Slave   Binary Power Switch FIBARO System FGS221 Double Relay 
Switch 2x1,5kW  off 12:00:50 PM Ready

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 12:21

Attachments:

GoogleCodeExporter commented 8 years ago 
Hmm - just noticed something. In OZWCP both nodes 12 and 13 are reported as 
READY. However looking at the 'Information' tab for these I am seeing zero for 
the ACKED and FRAMECOUNT values, whereas for the working nodes there are plenty 
listed. So obviously something is not quite right.

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 12:36

GoogleCodeExporter commented 8 years ago 
Ok - have tried a hard reset of the controller and re-associating all devices 
and now it is just one node that is not being started up in the binding. I have 
noticed that that one node (2x1.5kW relay) is reporting two switches AND a 
sensor (readonly) in the 'Current Value' tab in OZWCP. All other nodes (of the 
same type) only report two switches. All the config looks the same so I am not 
sure why this node is reporting this extra value. And am wondering if that is 
the reason for the problem in the binding startup?

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 3:31

GoogleCodeExporter commented 8 years ago 
More digging and I have noticed that when I close and re-initialise OZWCP the 
troublesome node gets stuck in DYNAMIC for quite a long time (4 mins or so) 
before eventually flicking through to READY. I am guessing this is why the 
binding is timing out? I don't really understand the Z-Wave lifecycle so not 
sure what it is doing, but am still trying to work out why this node has the 
extra SENSOR value. This delay also seems to hold up the rest of the nodes 
moving through to READY. 

More scanning of the OZWCP logs is showing the below. For some reason this node 
has the SensorBinaryCmd_Get request, which none of the other nodes have. This 
request is what is timing out - as the controller tries 3 times, each time 
timing out. 

Currently trying to figure out why that request is being send for a 2x1.5kW 
relay switch...

2013-08-18 15:36:48.798 Node005, Query Stage Complete (Session)
2013-08-18 15:36:48.798 Node005, AdvanceQueries queryPending=0 queryRetries=0 
queryStage=Dynamic live=1
2013-08-18 15:36:48.798 Node005, QueryStage_Dynamic
2013-08-18 15:36:48.798 Node005, Queuing (Send) MultiChannel Encapsulated 
(instance=1): BasicCmd_Get (Node=5): 0x01, 0x0d, 0x00, 0x13, 0x05, 0x06, 0x60, 
0x0d, 0x01, 0x01, 0x20, 0x02, 0x25, 0x42, 0xca
2013-08-18 15:36:48.798 Node005, Queuing (Send) MultiChannel Encapsulated 
(instance=2): BasicCmd_Get (Node=5): 0x01, 0x0d, 0x00, 0x13, 0x05, 0x06, 0x60, 
0x0d, 0x01, 0x02, 0x20, 0x02, 0x25, 0x43, 0xc8
2013-08-18 15:36:48.798 Node005, Queuing (Send) MultiChannel Encapsulated 
(instance=1): SwitchBinaryCmd_Get (Node=5): 0x01, 0x0d, 0x00, 0x13, 0x05, 0x06, 
0x60, 0x0d, 0x01, 0x01, 0x25, 0x02, 0x25, 0x44, 0xc9
2013-08-18 15:36:48.798 Node005, Queuing (Send) MultiChannel Encapsulated 
(instance=2): SwitchBinaryCmd_Get (Node=5): 0x01, 0x0d, 0x00, 0x13, 0x05, 0x06, 
0x60, 0x0d, 0x01, 0x02, 0x25, 0x02, 0x25, 0x45, 0xcb
2013-08-18 15:36:48.798 Node005, Queuing (Send) SensorBinaryCmd_Get (Node=5): 
0x01, 0x09, 0x00, 0x13, 0x05, 0x02, 0x30, 0x02, 0x25, 0x46, 0xb3
2013-08-18 15:36:48.798 Node005, Queuing (Query) Query Stage Complete (Dynamic)

then a bit later...

2013-08-18 15:54:10.711 Node005, Sending (Send) message (Attempt 3, Callback 
ID=0xa3, Expected Reply=0x04) - SensorBinaryCmd_Get (Node=5): 0x01, 0x09, 0x00, 
0x13, 0x05, 0x02, 0x30, 0x02, 0x25, 0xa3, 0x56
2013-08-18 15:54:10.711 Notification: Notification home 0161d418 node 5 Timeout
2013-08-18 15:54:10.716 Node005,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2013-08-18 15:54:10.716 Node005,   ZW_SEND_DATA delivered to Z-Wave stack
2013-08-18 15:54:10.751 Node005,   Received: 0x01, 0x05, 0x00, 0x13, 0xa3, 
0x00, 0x4a
2013-08-18 15:54:10.751 Node005,   ZW_SEND_DATA Request with callback ID 0xa3 
received (expected 0xa3)
2013-08-18 15:54:10.751 Node005, Request RTT 39 Average Request RTT 48
2013-08-18 15:54:50.711 Node005, ERROR: Dropping command, expected response not 
received after 3 attempt(s)
2013-08-18 15:54:50.711 Node005, Removing current message
2013-08-18 15:54:50.711 Notification: Notification home 0161d418 node 5 Timeout

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 5:00

GoogleCodeExporter commented 8 years ago 
I'll have a look at your logs. BTW, I've expanded my network to 11 nodes 
without issues, so I don't think the number of messages is the problem.

Original comment by jwsp...@gmail.com on 18 Aug 2013 at 8:07

GoogleCodeExporter commented 8 years ago 
I have been trying to figure it out all day and just now I have managed to 
start the binding with every node starting up ok. Not really sure what I did 
differently but I think it had to do with using OZWCP to get everything in a 
stable state, which includes waiting for Node005 to finish trying to get the 
sensor binary status (still can't work out why that is happening) and then 
starting openHAB. Seems to be ok now, just restarted openHAB twice and all 
nodes came up both times.

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 8:10

GoogleCodeExporter commented 8 years ago 
I also haven't been able to get my door sensor to send the generic alarm 
command. It will only send basic commands regardless of what I set for param 5. 
I tested using OZWCP and looking at the raw messages and if set to 
BASIC/GENERIC/SMOKE or any other, the command class coming back is always 0x20. 
So for now I am just using a Switch item for my front door. Not a big problem, 
but I am wondering if it is another firmware issue from Fibaro.

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 8:20

GoogleCodeExporter commented 8 years ago 
:-)  as the controller and nodes learn it probably will only get more
stable. Good news !

Original comment by jwsp...@gmail.com on 18 Aug 2013 at 8:46

GoogleCodeExporter commented 8 years ago 
More progress...I had to restart openHAB again as I changed some other config. 
This time Node 4 has failed to start. I have noticed the Fibaro switches are 
pretty good at sending state change messages when I manually flick the switches 
so I was hoping I could prod the binding into life by flicking the switches on 
the dead node.

What I found was switch 1 would update openHAB quite happily, even though the 
node was marked as dead. However switch 2 would not update. And after these 
messages came back to openHAB the node was still being treated as dead - i.e. 
updating the switches in openHAB was not having any effect.

Let me know if you want me to stop posting details on here! Just hoping you 
might be able to see something in the logs which will explain what is going on!

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 9:02

Attachments:

GoogleCodeExporter commented 8 years ago 
That currently does not work. When a node is not reachable, the command classes 
are not initialized, so the message does not arrive. I could continue 
initialization on receiving a message of course. It still does not explain why 
it fails so much. I'll have a look at the timeout values of the stick and see 
whether open-zwave sets the timeout values and what they are. Sometimes 
messages in your network take up to 1.7 seconds for a round trip. This is very 
close to the 2s time-out.

Original comment by jwsp...@gmail.com on 18 Aug 2013 at 9:49

GoogleCodeExporter commented 8 years ago 
The weirdest thing to me is the binary sensor being reported by one of my 
2x1.5kW relay switches (FGS221). This is causing all sorts of delay when 
initialising via OZWCP. I can't for the life of me see why that is happening, 
and couldn't find any mention of it in any forums. I will contact the Fibaro 
supplier here in NZ tomorrow and see if he has any ideas.

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 9:58

GoogleCodeExporter commented 8 years ago 
I have the same switch... It just reports BASIC + 2 switches in open-zwave.

Library Version: 3  
Protocol Version: 3.42  
Application Version: 2.01

Basic: 0
Switch: Off     
Switch: Off

Original comment by jwsp...@gmail.com on 18 Aug 2013 at 10:55

GoogleCodeExporter commented 8 years ago 
Yep - that is exactly what I see for the other 4 switches of this type. It is 
just the one that has this extra binary sensor being reported. Weird. Any ideas 
about how to do a factory reset on one of these switches? I have tried 
everything else I can think of!

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 8:25

GoogleCodeExporter commented 8 years ago 
I'd say that it is an open-zwave error and that you should throw away the cache 
files...

Original comment by jwsp...@gmail.com on 18 Aug 2013 at 9:08

GoogleCodeExporter commented 8 years ago 
Worth a try, how do I do that?

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 9:11

GoogleCodeExporter commented 8 years ago 
I meant the saved config files. You've deleted them before to get the nodes 
recognized.

Original comment by jwsp...@gmail.com on 18 Aug 2013 at 9:17

GoogleCodeExporter commented 8 years ago 
Yep - figured that might be what you meant. Just deleted them and 
re-initialising the network. Seems to have come back ok now - thanks for the 
tip!

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 9:28

GoogleCodeExporter commented 8 years ago 
I have been doing some reading and I think the Fibaro door sensor is only 
designed to send the ALARM frames (based on Parameter 5) to associations. Does 
that sound plausible? Since I don't have any associations in my network - 
everything flows through openHAB - I never see these 'typed' frames - only the 
BASIC ones. Can you associate a device with the controller? Would this mean I 
would receive both a BASIC and ALARM frame?

Original comment by ben.jone...@gmail.com on 18 Aug 2013 at 10:15

GoogleCodeExporter commented 8 years ago 
I have a suggestion Jan-Willem - I have noticed the Fibaro relays are very 
reliable at sending out state updates when a switch is manually changed. 
However the Aeontec switch  does not. Therefore would it be useful to allow 
item configurations to specify whether they need to be polled by the binding? 
This would remove a lot of traffic for large networks and simplify things.

Not sure if this is simple to implement in your binding, but thought I would 
log it in here as a potential enhancement.

Original comment by ben.jone...@gmail.com on 19 Aug 2013 at 2:43

GoogleCodeExporter commented 8 years ago 
Bug: My door sensor is not reporting the battery level. I can see the request 
being made and put on the wake up queue, but when the binding attempts to send 
the request when the sensor wakes up, the message times out. It looks like it 
re-queues the request but this then times out again until the sensor goes back 
to sleep. The sensor is working in that opening/closing the door is updating 
openHAB. But the battery level is never reported.

Original comment by ben.jone...@gmail.com on 19 Aug 2013 at 3:45

GoogleCodeExporter commented 8 years ago 
Forgot to attach my log...

Original comment by ben.jone...@gmail.com on 19 Aug 2013 at 4:06

Attachments:

GoogleCodeExporter commented 8 years ago 
Yes you can associate devices with the controller and in fact it sometimes is 
necessary to get reliable status updates from a device so try that.

I will make polling a binding action so that we can specify it for every item, 
but after 1.3. The values of the nodes will have to be polled on init in the 
dynamic query stage, or we don't have any values when the binding starts.

I'll have a look at the logs for the battery level.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 6:03

GoogleCodeExporter commented 8 years ago 
Ben, I've decided not to mess with the time-out values in this version of the 
binding. It needs a certain software version of the controller (>= 4) to 
support this. The supported stick functions are returned in a bitmap in 
SerialAPIGetCapabilities, but we don't handle that yet. If I include setting 
time-outs now, it would only work for sticks >= version 4 and that seriously 
limits usability.

So the next version of the binding will feature handling of the API 
capabilities function to check which functions are supported. If the function 
is supported, then we can override the time-out value in the config file or 
something.

Can you live with that?

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 8:02

GoogleCodeExporter commented 8 years ago 
I think I've found the bug with the battery level. Your node is a multi channel 
node. I encapsulate the message, but it should not, it should send it to the 
node. I will fix this.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 8:08

GoogleCodeExporter commented 8 years ago 
Ah that makes sense. I noticed the encapsulated message but didn't really 
follow why it was there. Sounds like it wasn't actually needed!

As for the timeouts, was that related to this issue as well? I.e. were you 
thinking I needed to increase my timeouts in order to get the battery level 
report back? Or is this for something else?

I am very happy with the state of the binding currently, you have done a 
fantastic job. I am focusing on getting my network nice and stable and to then 
start ironing out the finer points. I.e. my door sensor has a temperature 
sensor built in so I want to get the values from that back to openhab. I also 
have one of the Fibaro universal sensors which I hope to install and test soon.

I still can't seem to get the alarm reports back, I am stuck with basic 
messages currently which isn't the end of the world, but I would like the door 
sensor to act as a contact.

Original comment by ben.jone...@gmail.com on 19 Aug 2013 at 9:28

GoogleCodeExporter commented 8 years ago 
The timeouts were actually related to the fact that sometimes in your network, 
messages seem to take 1.7 seconds (or more, as you have timeouts as well). It's 
possible to set the timeout values for the serial interface, so that way I can 
make it possible to extend the time-out value. 

It also provides a nice deterministic way to set a default value of 1.5 seconds 
on the stick. This is the default specified by Zensys, but manufacturers of 
sticks can change the default. The time-out in the binding is now set to a 
fixed value of 2 seconds. I'd like to set the time-out value of the stick 
deterministically and add 500ms to the binding time-out. This way the stick 
will mostly reply the time-out status of a message. If the binding time-outs, I 
know the stick did not process the message at all.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 10:07

GoogleCodeExporter commented 8 years ago 
Are you still seeing timeouts in my logs? I thought the only timeouts were due 
to the incorrect command class being used for the battery level requests? I 
have your clone locally but am having trouble getting it to compile in the IDE. 
I will try a clean maven build tomorrow to see if that works. I would really 
like to get my hands dirty on some of this code! I presume you base most of 
your development on the OpenZWave libraries for each command class?

Original comment by ben.jone...@gmail.com on 19 Aug 2013 at 10:22

GoogleCodeExporter commented 8 years ago 
I actually have not looked at your latest log, so maybe it's OK now ;-)

Using the instructions on https://code.google.com/p/openhab/wiki/IDESetup it 
should work. Combining maven and the IDE in the same source tree is not a very 
good idea.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 10:46

GoogleCodeExporter commented 8 years ago 
I've fixed the bug where all command classes were encapsulated on a 
multi-endpoint node (instead of only the command classes bound to an endpoint).

I've also fixed the log entries you mentioned, and I've fixed a bug which made 
the send process try twice instead of three times.

I will provide binaries later.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 11:15

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
And the binaries.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 3:58

Attachments:

GoogleCodeExporter commented 8 years ago 
Yep - I have a development environment working for the default branch but when 
I tried your clone there were some issues when generating the second to last 
step (in the code gen stuff). I will get it sorted.

I will try your new binaries today, hopefully that resolves the battery issue. 
I am still seeing nodes die unfortunately. Everything was running fine last 
night then when I went to go to bed one of the nodes failed to respond to my 
'all lights off' scene event.

Will do some digging this morning and let you know what I find.

Original comment by ben.jone...@gmail.com on 19 Aug 2013 at 8:16

GoogleCodeExporter commented 8 years ago 
Regarding parameter 5 on the door sensor. You need to wait for the wake-up 
event in open-zwave before it's actually set. The command gets queued like 
everything else. Look in the log to make sure it woke up and open-zwave 
processed the queue.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 9:09

GoogleCodeExporter commented 8 years ago 
Yep - I have checked that. The parameter is definitely getting set, when I
refresh the control panel UI and reload the configuration tab the value is
set. I have also managed to set other parameters (like the alarm broadcast -
13 I think) which worked - i.e. when the sensor was tripped it broadcast the
alarm frame and all my switches started flashing!

Original comment by ben.jone...@gmail.com on 19 Aug 2013 at 9:11

GoogleCodeExporter commented 8 years ago 
Firmware bug then maybe :-)  anyway there is a workaround now. In the next 
version of the binding I'm thinking of data conversions so you can bind to 
either contact or switch anyway.

Original comment by jwsp...@gmail.com on 19 Aug 2013 at 9:14