Closed GoogleCodeExporter closed 9 years ago
My damn email replies never seem to work when they come from my phone! I
replied that I totally agree with the idea of a WIKI page, and would be happy
to contribute my binding config to help out. This is rapidly becoming quite a
complicated binding (but extremely powerful!) so beginners will need all the
help they can get.
Original comment by ben.jone...@gmail.com
on 12 Sep 2013 at 9:36
It ain't much but I just pushed a support for the HAIL command class to my
clone
(https://code.google.com/r/benjones12-zwave2/source/detail?r=62b4b305dc0fe06fa24
1c2fbab124fd77eede70a&name=1.4.0-zwave). It is untested as I don't have any
devices that 'hail' but it is pretty simple so should be ok I think.
Original comment by ben.jone...@gmail.com
on 12 Sep 2013 at 10:28
I don't have any devices either. I'll merge it this weekend.
Original comment by jwsp...@gmail.com
on 12 Sep 2013 at 7:03
JwS - I am seeing an odd error sometimes during initialisation. Every so often
one of my double relay switches fails to properly initialise its end points (in
ZWaveMultiInstanceCommandClass.initEndpoints()) because it receives a version=0
(see line 1720 of the attached log).
Because the binding just ignores this error/warning and continues, the second
end point of that node is never initialised. I was wondering if this sort of
thing happens, could we force the binding to re-request that phase of the
initialisation sequence? Since we know at this point it is a multi-instance
device, we should keep trying until the end points are successfully initialised?
Original comment by ben.jone...@gmail.com
on 12 Sep 2013 at 9:06
Sorry - forget the log.
Original comment by ben.jone...@gmail.com
on 12 Sep 2013 at 9:07
Attachments:
Hey JwS - found another potential bug I think. In
ZWaveController.handleIdentifyNodeResponse() you add all mandatory device
classes - which is a static list. However when you process the end point
capabilities of a multi-instance device
(ZWaveMultiInstanceCommandClass.handleMultiChannelCapabilityReportResponse())
you don't check this mandatory list and just add command classes based on what
the device reports.
I can imagine that is probably fine for most devices but my Fibaro Universal
Sensor is only reporting back SENSOR_BINARY and SENSOR_ALARM classes, i.e. no
BASIC, but when the sensor is tripped it is sending BASIC reports. Go figure!
This is all working ok but I am seeing warning messages in my log whenever the
sensor is tripped stating that BASIC is not implemented for endpoint 'n' and
that it is falling back to the main node.
I think we should be adding the mandatory command classes during end point
initialisation of multi instance devices, like we do the for main node.
Let me know what you think.
Original comment by ben.jone...@gmail.com
on 13 Sep 2013 at 2:35
Just been playing around with the INFO stuff for the controller (node 1). Can I
make a suggestion to return Integers for all the stat counts? This will make it
easier to write rules in openHAB to check for high numbers of NAKs/CANs etc.
Easy enough to convert to strings in the item definitions when displaying in
the sitemaps.
Original comment by ben.jone...@gmail.com
on 13 Sep 2013 at 3:56
JwS - would you rather I just made these changes and flicked you an email to
let you know to look in my clone, so you can merge in the changes to your
clone? Or is it easier to just drop a note here (as I have been doing) and save
you having to do any merging? I am happy to do either.
Original comment by ben.jone...@gmail.com
on 13 Sep 2013 at 4:10
Just drop a note in this topic, then the rest of the world knows what's going
on ;-)
Yeah, I thought about changing the report items and passing them through the
converter logic, so that you can do all sorts of cool stuff with it, and I left
it for now, can't do all at the same time ;-)
Original comment by jwsp...@gmail.com
on 13 Sep 2013 at 6:24
I think it's a bit more subtle that just adding the mandatory command classes
for the endpoints. I can't find anything about that in the spec and my
multi-channel devices all report the mandatory command classes for their device
class on their endpoints (as opposed to the mandatory command classes on the
node, because that is listed in the specs).
Open-Zwave just adds a basic command class, I think to cover for the situation
you are describing. Fibaro really loves their basic reporting, and I think that
is a bit "off spec" as well.
The relevant code in open-zwave is below, i think we should just add basic
there as well, if the node supports it:
// If we support the BASIC command class and it is mapped to a command class
// assigned to this end point, make sure the BASIC command class is also associated
// with this end point.
if( basic != NULL && basic->GetMapping() == commandClassId )
{
basic->SetInstance( i );
if( m_endPointMap != MultiInstanceMapAll || i != 1 )
{
basic->SetEndPoint( i, endPoint );
}
}
Original comment by jwsp...@gmail.com
on 13 Sep 2013 at 6:28
I've fixed the basic "bug". It's in my clone.
Original comment by jwsp...@gmail.com
on 13 Sep 2013 at 6:38
Nice - looks good JwS. Just noticed a potential bug in
ZWaveNode.resolveCommandClass(). After line 415 you should be testing for a
null return value I think. Otherwise you will get a null reference exception in
line 418 if null is returned.
Original comment by ben.jone...@gmail.com
on 13 Sep 2013 at 9:21
I have just pushed a change to ZWaveBinarySwitchCommandClass so it handles
SWITCH_BINARY_SET in much the same way you handle BASIC_SET - i.e. treat it as
a SWITCH_BINARY_REPORT. My Aeon Labs Micro Smart Energy Switch returns a
SWITCH_BINARY_SET and a BASIC_REPORT when the switch is activated by the
binding and I was getting warnings in my logs. Seems to be working fine in my
network now.
Original comment by ben.jone...@gmail.com
on 13 Sep 2013 at 11:58
There seems to be a lot of creativity involved in interpreting the specs ;-)
I'll have a look at it and merge it. Thanks!
Original comment by jwsp...@gmail.com
on 14 Sep 2013 at 10:23
found another issue... The binding didn't refresh the values when the items
file got reloaded. Fixed that one as well.
Original comment by jwsp...@gmail.com
on 14 Sep 2013 at 11:57
Did you see my comment #54? I haven't noticed that issue much recently but do
you think it is worth adding some handling to allow the binding to recover from
receiving version=0 for a multi instance node? Would you rather I added new
'issues' for these things or just do it via this one?
AFAIK the only outstanding things are this, the default handling of BASIC
reports and using state converters for the info reports.
Think it is really starting to look very stable now. Great job!
Original comment by ben.jone...@gmail.com
on 14 Sep 2013 at 6:57
Just pushed some changes to my clone so the ZWave info stuff is now using the
state converters. I now have rules setup to alert me if a node dies. Merge with
your main branch if you are happy with it :).
Original comment by ben.jone...@gmail.com
on 15 Sep 2013 at 3:06
Oops I completely forgot to tell you that #54 is fixed.
https://code.google.com/r/jwspuij-zwave/source/detail?r=8b751a4496f940aee70acb4c
df9da036948acb10&name=1.4.0-zwave#
Original comment by jwsp...@gmail.com
on 15 Sep 2013 at 7:22
Ah sweet. Thanks!
Original comment by ben.jone...@gmail.com
on 15 Sep 2013 at 8:38
For those of you interested in running a beta version, I've included the binary
below.
For those of you interested, the configuration part for the Fibaro FGWPE/F-101
is below:
Switch Coffee_Kitchen_Switch "Koffiemachine" (GF_Cellar)
{zwave="18:command=switch_binary"}
Number Coffee_Kitchen_Power "Koffiemachine actueel verbruik [%.1f W]"
(GF_Cellar) { zwave="18:command=sensor_multilevel" }
Number Coffee_Kitchen_Energy "Koffiemachine totaal verbruik [%.2f KWh]"
(GF_Cellar) { zwave="18:command=meter" }
What is immediately obvious is that a command class is specified (besides the
node ID) because this device has only one endpoint, but multiple different
command classes.
There have been more changes to the binding format, but in general the binding
format is: (brackets indicate optional values)
<node id>[:<endpoint id>][:<argument1>=<value1>[,<argument2>=<value2>]]
Some more examples are:
String ZwaveStatsSOF "Number Start of Frames[%s]" (gZwaveStats)
{zwave="1:command=info,item=sof"}
String ZwaveStatsACK "Number of Acknowledgments [%s]" (gZwaveStats)
{zwave="1:command=info,item=ack"}
String ZwaveStatsCAN "Number of CAN [%s]" (gZwaveStats)
{zwave="1:command=info,item=can"}
Contact Door_Living_Switch "Schuifdeur sensor [MAP(nl.map):%s]" (GF_Living)
{zwave="25:command=sensor_binary, respond_to_basic=true"}
Number Door_Living_Sensor_Battery "Schuifdeur sensor batterijniveau [%d %%]"
(GF_Living) { zwave="25:command=battery" }
Dimmer Light_Toilet_Dimmer "Toilet Dimmer [%d %%]" (GF_Toilet)
{zwave="10:1:restore_last_value=true"}
Switch Mech_Vent "Mechanische ventilatie middel." (GF_Kitchen) {zwave="11:1"}
Switch Mech_Vent_High "Mechanische ventilatie hoog." (GF_Kitchen)
{zwave="11:2"}
Some general binding options are:
command=xxxx this binds this item to a specific command class
refresh_interval=xxx this is a polling interval in seconds. Default the binding
does not poll.
respond_to_basic=true this indicates that the item should respond to basic
reports, sent out by some fibaro sensors.
Original comment by jwsp...@gmail.com
on 16 Sep 2013 at 6:31
Attachments:
JwS - I am still seeing the issue in #54 sporadically. When the version number
0 is received for the MULTI_INSTANCE class, only the first end point is
initialised. I only get this error every now and again, but could we add some
handling to the binding so it retries if it receives version = 0 for a multi
instance device (or any device?)?
2013-09-17 08:11:22 DEBUG o.o.b.z.i.p.ZWaveController[:192]- Application
Command Request from Node 5
2013-09-17 08:11:22 DEBUG o.o.b.z.i.p.ZWaveController[:210]- Incoming command
class MANUFACTURER_SPECIFIC (0x72)
2013-09-17 08:11:22 DEBUG
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:82]- Received Manufacture
Specific Information for Node ID = 5
2013-09-17 08:11:22 DEBUG
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:99]- Node 5 Manufacturer
ID = 0x010f
2013-09-17 08:11:22 DEBUG
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:100]- Node 5 Device Type =
0x0200
2013-09-17 08:11:22 DEBUG
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:101]- Node 5 Device ID =
0x300a
2013-09-17 08:11:22 WARN o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:534]-
Unknown version 0 for command class MULTI_INSTANCE (0x60)
Original comment by ben.jone...@gmail.com
on 16 Sep 2013 at 8:32
There was no 0 version received. 0 is the default value if no version info is
received. I'll have to have another look into the log to see why the binding
continues without all the version info. I'll look at it tomorrow.
Original comment by jwsp...@gmail.com
on 16 Sep 2013 at 8:59
Ok - I think I have tracked this down. If you look in the log I posted in
comment #55 you will see that for node 6 the binding received TWO node info
messages (lines 1607 and 1663). The first message causes the node stage to
advance and the version request is sent, however the second message arrives
immediately afterwards and advances the node stage again. This happens before
the version response comes back and thus we get the bug where the multi
instance command class is told to initialise its end points, before the version
response has been processed.
I am not sure of the best way to fix this. Whether you change the node advance
stuff to be more explicit, so when advancing you pass what the next stage
should be. Or if you add some validation to ignore certain initialisation
messages (i.e. node info responses) if they have already been processed.
I will leave it with you to decide!
PS - did you see my changes for the info command state conversion stuff? I am
using this on a local version of my binding but don't want to lose it if/when I
upgrade to your latest code.
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 1:09
It's a very crappy problem. I've tried ignoring the double messages, but they
do not have a callback ID (sadly). Simple detection gave problems with wake-up
devices, because they restart their init sequence on wake-up and then double
messages will happen.
I was thinking about adding the stage to advance to too.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 6:54
Sounds like you are on top of what is happening. Not sure there is much I can
add to help? I have noticed another strange initialisation error this evening
(see log below for node 7). It receives a VERSION (0x86) message with command
class MULTI_CMD (0x8f) and version = 0. The checksum seems to be ok so I don't
think it is a scrambled packet, but I have never seen one of these before (that
I can recall). Any ideas?
The other thing is the node is marked DEAD by the binding (in the logs) but I
don't think the 'dead' property on the ZWaveNode object is being updated. I
only noticed this as I am now displaying the node info properties in my sitemap
(with rules to alert me if a node dies) and this didn't update.
2013-09-17 19:26:08 DEBUG
o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1133]- Message = 01 0A 00 04 00
07 04 86 14 8F 00 EF
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:146]- Creating new
SerialMessage from buffer = 01 0A 00 04 00 07 04 86 14 8F 00 EF
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:150]- Message checksum
calculated = 0xEF, received = 0xEF
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:163]- Message Node ID = 255
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:164]- Message payload = 00
07 04 86 14 8F 00
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:145]- Incoming message
to process
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:238]- Assembled message
buffer = 01 0A 00 04 00 07 04 86 14 8F 00 EF
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:146]- Message: class =
ApplicationCommandHandler (0x04), type = Request (0x00), buffer = 01 0A 00 04
00 07 04 86 14 8F 00 EF
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:166]- Message type =
REQUEST
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:192]- Application
Command Request from Node 7
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:210]- Incoming command
class VERSION (0x86)
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:86]- Received
Version Request for Node ID = 7
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:110]- Process
Version Command Class Report
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:120]- Node 7
Requested Command Class = MULTI_CMD (0x8f)
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:121]- Node 7
Version = 0
2013-09-17 19:26:08 ERROR o.o.b.z.i.p.c.ZWaveVersionCommandClass[:128]-
Unsupported command class MULTI_CMD (0x8f)
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 8:14
Firmware bug? Sometimes one of my nodes sends illegal command class values in
the node info frame... Packet, including checksum is OK, but the CC values
don't match at all...
Multi_CMD is not supported by the binding, so it would never ask for it's
version...
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 8:33
I don't know what has changed (haven't changed my binding in the last few days)
but I can't get the binding to start without these duplicate node info
messages. 2-3 nodes every time fail to start properly. And it was all going so
well!
Just saw your last comment. I think something has gone a bit haywire in my
controller. Trying a soft reset via OZWCP...
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 8:34
Or a network collision. An avarage of 1 in 256 collided packets will end up
with a garbled packed with the right checksum on a collision.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 8:35
Nah something has gone wrong with the controller. I am seeing loads of Out Of
Frame Flow warnings (sending NAKs) even after a soft reset. A hard reset will
wipe all associations correct? Don't really want to do that! Might try
disconnecting the stick for a minute and retrying...
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 8:37
I was thinking of implementing deleting and assigning return routes and doing a
round at a scheduled time (at night or something, every night) to make sure
that all return routes will stay in a healthy condition.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 8:38
Dont hard reset ;-)
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 8:38
Yep - made that mistake before! Not sure what happened but after unplugging and
reconnecting the Out Of Frame Flow errors have stopped. Now just having to
rebuild the mesh network. God knows why this all went tits up!
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 8:57
I merged your changes and also realized that there were no state Converters for
decimal to on/off open/closed items. Added those as well.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 9:20
Knock wood, but since I've added a greenwave power bar at a difficult spot in
my living room, the binding has been rock solid for over a week now. No init
errors or problems whatsoever, although I keep switching the stick (virtually
through ser2net) from my dev environment to my server daily.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 9:22
Yeah mine has been rock solid up until today as well. Was initialising every
time, with just the occaisional error (duplicate node info). God knows what
went wrong this evening but I am still unable to get it going...
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 9:23
I think I have fixed it - and I think I know what it was...I have never done a
Node Neighbour Update on Node 1 (i.e. the controller) via OZWCP. As a result I
think the controller has always thought it could 'see' all my nodes (probably
from when each node was included).
However after trying just about everything else this evening I managed to send
a Neighbour Update request to Node 1 and all of a sudden it is only reporting
as being able to 'see' a few nodes. What this means I think, is that the
controller is now not blindly trying to send messages to nodes it thinks it can
see, but which are out of range. It is now using the mesh network properly and
routing messages to these nodes through other nodes that are visible to the
controller.
I think I might have solved all my timeout issues with this breakthru - fingers
crossed!!! The binding has started up smoothly with no warnings or errors or
timeouts, which is the first time I have seen this ever!
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 10:05
BTW - I think implementing a schedule to delete and assign return routes could
be useful - as long as it was optional - i.e. could be disabled. I get the
feeling once a network is setup correctly you probably don't want to be messing
with it much - and nodes should hardly ever move.
Did you find that bug with a node not updating the isDead() property?
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 10:11
Great I fixed the advance node stage, in case that happens again. I'll commit
shortly.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 10:27
Have not been able to look at it yet. Have to "kill" a node, and since
everything is pretty much connected or built in right now, I was thinking about
installing a new one and test with that one. I'll do that tomorrow. Don't have
time today.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 10:29
Cheers mate - a very frustrating evening has brightened up considerably! Time
for bed now.
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 10:29
Fixed the advancing node stage bug. It's in my clone.
BTW, what's the firmware of your stick? Aeon labs provides updates and it might
pay off to update the FW.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 10:44
I'm happy to announce that i've updated the METER command class to support
version up until version 3. Now I can read all power and energy values from my
greenwave (shuko) power bar. For €50 you get a 6 socket energy/power
measuring switchable power bar. Not a bad deal!
config:
Switch Switch_Powerbar_Subwoofer "Subwoofer" (GF_Living)
{zwave="26:1:command=switch_binary"}
Switch Switch_Powerbar_Reiceiver "Versterker" (GF_Living)
{zwave="26:2:command=switch_binary"}
Switch Switch_Powerbar_DVD "DVD" (GF_Living)
{zwave="26:3:command=switch_binary"}
Switch Switch_Powerbar_TV "Televisie" (GF_Living)
{zwave="26:4:command=switch_binary"}
Switch Switch_Powerbar_Xbox "XBOX-360" (GF_Living)
{zwave="26:5:command=switch_binary"}
Switch Switch_Powerbar_PC "Mediacenter" (GF_Living)
{zwave="26:6:command=switch_binary"}
Number Power_Powerbar_Subwoofer "Subwoofer actueel verbruik [%.1f W]"
(GF_Living) {zwave="26:1:command=meter,meter_scale=E_W"}
Number Power_Powerbar_Reiceiver "Versterker actueel verbruik [%.1f W]"
(GF_Living) {zwave="26:2:command=meter,meter_scale=E_W"}
Number Power_Powerbar_DVD "DVD actueel verbruik [%.1f W]" (GF_Living)
{zwave="26:3:command=meter,meter_scale=E_W"}
Number Power_Powerbar_TV "Televisie actueel verbruik [%.1f W]" (GF_Living)
{zwave="26:4:command=meter,meter_scale=E_W"}
Number Power_Powerbar_Xbox "XBOX-360 actueel verbruik [%.1f W]" (GF_Living)
{zwave="26:5:command=meter,meter_scale=E_W"}
Number Power_Powerbar_PC "Mediacenter actueel verbruik [%.1f W]" (GF_Living)
{zwave="26:6:command=meter,meter_scale=E_W"}
Number Energy_Powerbar_Subwoofer "Subwoofer totaal verbruik [%.2f KWh]"
(GF_Living) {zwave="26:1:command=meter,meter_scale=E_KWh"}
Number Energy_Powerbar_Reiceiver "Versterker totaal verbruik [%.2f KWh]"
(GF_Living) {zwave="26:2:command=meter,meter_scale=E_KWh"}
Number Energy_Powerbar_DVD "DVD totaal verbruik [%.2f KWh]" (GF_Living)
{zwave="26:3:command=meter,meter_scale=E_KWh"}
Number Energy_Powerbar_TV "Televisie totaal verbruik [%.2f KWh]" (GF_Living)
{zwave="26:4:command=meter,meter_scale=E_KWh"}
Number Energy_Powerbar_Xbox "XBOX-360 totaal verbruik [%.2f KWh]" (GF_Living)
{zwave="26:5:command=meter,meter_scale=E_KWh"}
Number Energy_Powerbar_PC "Mediacenter totaal verbruik [%.2f KWh]" (GF_Living)
{zwave="26:6:command=meter,meter_scale=E_KWh"}
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 3:49
Hmm Ben, i would not update to the latest version. There is something seriously
wrong with the node stage advancing now...
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 5:13
Hi JWSP!
I happily report that your binding (version 1.3.0) works very stable with my
network for a couple of days.
The only problem left is that periodically my serial adapter changes its port
and becomes /dev/ttyUSB1 instead of /dev/ttyUSB0, and the whole OpenHAB
crashes. :( But it occurs not so often.
And if you have implemented the scales for METER command class - could you
please implement the same thing for SENSOR_MULTILEVEL?
Original comment by roher.ro...@gmail.com
on 17 Sep 2013 at 5:16
No there is not. I had the same issues as you. Re-requesting neighbor info
helped.
Original comment by jwsp...@gmail.com
on 17 Sep 2013 at 5:40
Sweet - so ok to update to your latest codeset? The meter changes look good, I
have been noticing my one meter returning differing values depending on whether
the switch is on or not - this should resolve that nicely!
Original comment by ben.jone...@gmail.com
on 17 Sep 2013 at 8:18
FYI - just updated the firmware in my USB stick to v3.07. I couldn't figure out
how to determine what version it had originally but the upgrade went through
ok. Things seem to be fine afterwards - thankfully it didn't lose any
associations!
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 12:17
Tried your latest code - the meter stuff is working great - good job. Will keep
an eye out for any issues with the node advance stuff as well.
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 1:18
You had version 2.78
Original comment by jwsp...@gmail.com
on 18 Sep 2013 at 5:46
How can you tell? I checked the OZWCP logs before and after the upgrade and I
thought they were both reporting a Zwave serial version of 2.78.
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 6:37
Original issue reported on code.google.com by
jwsp...@gmail.com
on 2 Sep 2013 at 12:45