Implement ZWave Binding

[GoogleCodeExporter]

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]

Yep - I am going to try this association business - so the sensor is
associated with the controller. Hoping that might make a difference.

By the way - my door sensor is now happily reporting the battery level after
your latest fix - cheers!

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

[GoogleCodeExporter]

Got everything running again. Seeing quite a few of the messages below..what 
causes these? Are they ok to see or is something not quite right?

BTW - I have associated the door sensor with the controller and I still don't 
see any ALARM frames. I have contacted the Fibaro support guys in NZ and have 
posed the question...

2013-08-20 09:55:02 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 08 00 13 09 01 00 05 1D F4
2

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

[GoogleCodeExporter]

The binding discards a message after 3 retries. So that means that sending a 
message failed to that node and that it will not try the message again. This is 
normal for a battery operated node during init with a no operation (ping) 
command. If you have it after initialization of the network, then it's not OK.

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

[GoogleCodeExporter]

That specific message is a ping to node 9 btw

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

[GoogleCodeExporter]

Ok - well that is my door sensor and was during initialisation, so should be 
fine. I will keep an eye out for these 'discards' going forward (from other 
nodes, post initialisation).

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

[GoogleCodeExporter]

Little status update. I've merged the default branch into 1.3.0-zwave to be up 
to date with the latest changes from default. Then I've updated the version 
numbering of the bundle and fixed some compile errors.

Thanks Ben for testing! I'm still hoping for more testers. Binding is running 
stable at home now for a couple of days. +40K messages a day in my 11 node 
network without errors.

Original comment by jwsp...@gmail.com on 20 Aug 2013 at 9:40

[GoogleCodeExporter]

Jan-Willem - I am still seeing some nodes getting marked 'dead' on binding 
startup. I just stopped and started openHAB and noticed node 6 failed to 
initialise (even though it has been working fine today). So I copied the log 
and restarted openHAB. This time it started up with no issues. Both logs 
attached. 

I am guessing it is something to do with timeouts but it seems like if it 
doesn't start immediately then it never gets the messages to progress the node 
initialisation sequence. When I initialise OZWCP some nodes seem to stall for a 
bit, but eventually come online and always get marked Ready.

Is the binding being a little harsh when it comes to dealing with 'slow' nodes? 
Also, is it possible that some messages are getting missed by the binding? Just 
thought of that then as a possible reason why sometimes a node fails to 
initialise.

Let me know if my logs show up anything useful!

Original comment by ben.jone...@gmail.com on 20 Aug 2013 at 9:44

Attachments:

• zwave.node6.zip

[GoogleCodeExporter]

>>I'm still hoping for more tester
Is there a quick start guide (I saw mention of a wiki page, but can't find it)?
I'm happy to do some testing - I've just bought a stick and have a large z-wave 
network connected to my MCV Vera (which I want to get rid of). I have some new 
nodes that I'll put directly on OH and can start to move some of the existing 
network over to OH.

Original comment by ch...@cd-jackson.com on 20 Aug 2013 at 9:46

[GoogleCodeExporter]

Been running the binding for about 50mins and wanted to check if there were any 
errors/warnings. Noticed a few more of these message discard errors;

2013-08-20 21:35:11 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 08 00 13 09 01 00 05 1E F7
2013-08-20 21:35:15 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 08 00 13 09 01 00 05 1F F6
2013-08-20 21:37:22 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 0D 00 13 06 06 60 0D 01 02 25 02 05 28 85
2013-08-20 21:43:14 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 0D 00 13 05 06 60 0D 01 01 25 02 05 5D F0
2013-08-20 21:57:18 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 0D 00 13 06 06 60 0D 01 02 25 02 05 D8 75
2013-08-20 22:05:21 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 0D 00 13 05 06 60 0D 01 02 25 02 05 1B B5
2013-08-20 22:15:52 WARN  o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1257]- 
Discarding message: Message: class = SendData (0x13), type = Request (0x00), 
buffer = 01 0D 00 13 06 06 60 0D 01 02 25 02 05 7A D7

I think only the first two are for node 9 (my door sensor)? Let me know if this 
is of interest and I can send you more of the log surrounding those events if 
that will help.

Original comment by ben.jone...@gmail.com on 20 Aug 2013 at 10:30

[GoogleCodeExporter]

https://code.google.com/p/openhab/wiki/ZWaveBinding

Original comment by jwsp...@gmail.com on 20 Aug 2013 at 11:07

[GoogleCodeExporter]

I've fixed a bug where the binding would not shutdown until some data was 
received on the stick (actually more a bug / omission in nrjavaserial). It's 
not worth publishing new binaries, but in case you want to start / stop the 
binding using the console, it's necessary.

Original comment by jwsp...@gmail.com on 20 Aug 2013 at 12:25

[GoogleCodeExporter]

Ben, i've analysed your logs and i've found the error: The stick sends a failed 
application update request. Probably just a coincedence, or it cannot reach the 
node... 

But the original binding never anticipated that. It's one of those todo's that 
has been there since the beginning. The binding even tells us:

TODO: Implement Application Update Request Handling of Node info request failed 
(0x81).

;-)

I will fix this.

Original comment by jwsp...@gmail.com on 20 Aug 2013 at 12:45

[GoogleCodeExporter]

Fixed it, will post binaries later. BTW, it's still strange that we get a 
failed application update event here. It means the binding pinged the node and 
it was OK, then  sends the request node info message. 1.5 seconds later (stick 
time-out value) the bindings gets a application update failed message from the 
stick. It still means that apparently some time-outs occur sometimes. 

It will not help to increase time-out values in the binding. The stick times 
out itself and actively sends a failed response.

Original comment by jwsp...@gmail.com on 20 Aug 2013 at 1:45

[GoogleCodeExporter]

Odd. So how does the binding handle this now? Re-attempt the node info request? 
I think the fact is my mesh network is not as robust as I would like. I have a 
cluster of 3 nodes down one end of the house which is where all the problems 
are occurring. Unfortunately there is nowhere to put a node in between them and 
the controller, and for the most part they work just fine. 

I will try your new binaries and keep an eye on things.

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

[GoogleCodeExporter]

Yeah. It requeues the node info request message up to 3 times and gives a 
better log message. Note the difference between resending and requeueing. 
Resending (what it did on a binding side time-out) sends the last sent message 
(regardless of content) immediately , requeueing means that other messages of 
the same or higher priority will be resent first. There are multiple messages 
queued at this stage (one for every node), so this gives the node a bit of time 
to recover.

But I think your right about a cluster of nodes that is too far away from the 
rest of your network so it won't make any difference.

Anyway, the binaries.

Original comment by jwsp...@gmail.com on 20 Aug 2013 at 11:14

Attachments:

• org.openhab.binding.zwave-1.2.1-SNAPSHOT.jar
• org.openhab.binding.zwave-1.3.0-SNAPSHOT.jar

[GoogleCodeExporter]

I wonder if these nodes are right on the 'edge' of the controller range and can 
sometimes be seen and other times can't. Therefore the controller might know 
about other routes in the mesh but if it thinks a node is directly accessible 
it will try that first, and in my case sometimes fails. Is there a way to force 
the controller to direct traffic to a specific node via another one? I.e. 
remove a dodgey path from the mesh and force it to use a relay?

Thanks for the binaries. I have cloned your repo and have it running in my dev 
IDE so will be looking to add some sensor multi level support to get the 
temperature from my door sensor.

Are you basing your command class code on the openzwave versions?

Original comment by ben.jone...@gmail.com on 20 Aug 2013 at 11:28

[GoogleCodeExporter]

Every message is transmitted with an auto reroute option. So on time-out it
would be resent arrive through other nodes anyway and it would learn this
way. No test nodes to place in between and try out if this improves the
situation?

Regarding the command classes:

I use multiple sources. There are some PDF specs floating on the net, there
is open-zwave and there is a .NET implementation. I usually cross reference
a couple to see what I can find out. Open-zwave is usually the best.

Original comment by jwsp...@gmail.com on 20 Aug 2013 at 11:36

[GoogleCodeExporter]

Ok - SENSOR_MULTILEVEL working and reading the temp from my door sensor (with a 
DS18B20 attached). I have dropped all the unit type support and have decided to 
just report the raw decimal value - since we can format the value for display 
in openHAB ourselves. This means there is no need for a 'SUPPORTED_GET' request.

Can I make a suggestion to the event handling framework? Should we leave it to 
the command classes to determine what 'State' is sent back to the listeners?

Then in my case I can build a DecimalType to return the multi sensor value. The 
alarm can return an OpenClosedType, and a binary sensor an OnOffType. 

Currently you are expecting a string to be passed back the parsing takes place 
in ZWaveActiveBinding when the event listener receives the event.

I would suggest the ZWaveEvent takes a State object instead of Object. This 
decouples the state handling from the framework, into the command classes 
themselves.

Off to bed - will continue with this tomorrow and check in my changes so you 
can have a look and make sure it meets your very high standard!!

Thanks again for all your help!

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 11:33

[GoogleCodeExporter]

I'd suggest adding the supported_GET to the initialization, similar to e.g. 
sensor_alarm. Then we can process the value in the command class and always 
return the correct value. It's easier for end users.

I've left the z-wave event handling for now, It was there from the beginning. I 
think though that the Z-Wave events were an idea of Victor to decouple openhab 
from the Z-Wave API... E.g. the command classes should just report their value 
(hence the object (or string in the beginning) and not an openhab state boject. 
I feel that adding an openhab state object to the controller or command classes 
would add an unneccessary dependency to openhab and actually couples the zwave 
API / controller to openhab.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 12:01

[GoogleCodeExporter]

Great work BTW ;-)

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 12:01

[GoogleCodeExporter]

In the spirit of this great open source project and in the wake of an imminent 
1.3 release, I've created something of a post 1.3 to-do list for the binding 
ordered by priority.

For somebody wanting to implement something, I've included expected difficulty 
from E being easy, to DD as most dificult. I realise that I can remove 
SENSOR_MULTILEVEL from the list shortly.

Question is whether we create separate issues or that we keep track of the TODO 
in one issue. The list is below:

high priority:

- M initialize / read binding values in the DYNAMIC node stage during binding 
initialization.
- M Make polling a binding action, so that it is configurable from the items 
file. Default should be no polling.
- D Implement associations node stage to read associations. These can be used 
to query associated nodes for their status, in case the associated nodes do not 
report themselves directly (don't know if this is neccessary).
- M Implement some form of serialization to save / cache the configuration of 
the binding to speed up initialization.
- E Implement the SWITCH_TOGGLE_BINARY command class.
- E Implement the SWITCH_TOGGLE_MULTILEVEL command class.
- M Implement SENSOR_MULTILEVEL command class.
- M Implement METER command class.
- E Implement THERMOSTAT_MODE command class. 
- E Implement THERMOSTAT_SETPOINT command class.
- E Implement BASIC_WINDOW_COVERING command class.
- E Implement DOOR_LOCK command class.
- E Implement ALARM command class.
- E Implement LOCK command class.
- M Implement MULTI_CMD command class. Used to group multiple commands 
together. Useful for Battery operated devices to empty the wake-up queue into 
one
command at once.
- E Implement SIMPLE_AV_CONTROL command class.
- DD Implement SECURITY Little information. Would require changes to 
encapsulation, secure key storage in openhab. Not much information. Very useful 
for locks though. One of the weaker points of Z-Wave that security was an 
afterthought.

normal priority:

- M Make binding actions for alarm types, so that binding can be done on a 
specific alarm. Remove alarm values from the binding again then, to make it 
stateless.
- D Handle adding nodes to the network / removing nodes from the network.
- D Control node configuration parameters using a binding. (Requires changing 
binding item string format to add parameter number or something).
- DD Implement neighbors node stage. Request node neighbors and update return 
routes based on the neighbour list and rtt values.
- M Implement the APPLICATION_STATUS command class. Handle incoming rejected 
and busy signals.
- D Implement the SWITCH_ALL command class. handle incoming switch all commands 
and implement sending. Some discussion on what to do on those incoming signals 
and when to send would be neccesary.
- D Implement the SCENE_ACTIVATION command class. Some discussion on how to map 
scenes onto the openhab bus and vice versa would be neccessary.
- E Implement METER_PULSE command class.
- M Implement CLIMATE_CONTROL_SCHEDULE class. Requires some discussing about 
how to map / handle scheduling capabilities to open-zwave.
- D Implement SCHEDULE_ENTRY_LOCK command class. Limited info on the command 
class. Would probably require the a device, commercial software to control it, 
and serial monitoring software.
- E Implement POWERLEVEL command class. Setting this too low, will make 
communication unreliable!
- E Implement PROTECTION command class.
- E Implement NODE_NAMING command class. Would require discussion on how to 
implement: e.q. use item name, or just report or free settable.
- E Implement CLOCK command class.
- E Implement HAIL command class. Some devices use a HAIL to the controller to 
ask for polling.
- E Implement INDICATOR command class.
- E Implement PROPRIETARY command class. Would require discussion on how to 
define properietary payloads... in item string? as files?
- E Implement LANGUAGE command class.
- E Implement TIME command class.
- E Implement GEOGRAPHIC_LOCATION command class.
- D Implement COMPOSITE command class. Variation on Multi_Instance. Requires 
some changes to initialization and encapsulation etc.
- E Implement ENERGY_PRODUCTION command class.
- E Implement MANUFACTURER_PROPRIETARY command class. Would require discussion 
on how to define properietary payloads... in item string? as files?
- E Implement SCREEN_MD command class.
- E Implement SCREEN_ATTRIBUTES command class.
- E Implement SILENCE_ALARM command class.

low priority:

- E Make a reporting binding action for the node stage, create separate 
reporting binding actions for sleeping / dead.
- D Handle endpoints in multi-channel nodes that can be added /removed 
dynamically. 
- DD Handle the situation where the stick is not the primary controller. This 
can be in networks with another (commercial) controller system. In this case 
enabling the controller to be a SUC is advisable.
- DD implement bridging and virtual nodes. This allows items on the bus to 
become virtual nodes and use Z-Wave associations or Z-Wave scenes to use items 
on another bus directly in Z-Wave.
- D Separate the Z-Wave part from the binding part and make it a separate open 
source library like open-zwave.
- D Implement the CHIMNEY_FAN command class. Have not been able to find a 
device or documentation / code about it. Should be easy once found.
- D Implement MTP_WINDOW_COVERING command class.  Limited info on the command 
class. Would probably require the a device, commercial software to control it, 
and serial monitoring software.
- E Implement IP_CONFIGURATION command class. Only for reporting or also to set 
ip adresses?
- E Implement AV_CONTENT_DIRECTORY_MD command class.
- E Implement AV_RENDERER_STATUS command class.
- E Implement AV_CONTENT_SEARCH_MD command class.
- E Implement AV_TAGGING_MD(0x99,"AV_TAGGING_MD",null),
- D Implement TIME_PARAMETERS command class. Have not found any information.
- D Implement METER_TBL_MONITOR command class to read complex meters.
- D Implement THERMOSTAT_HEATING command class. Have not found any information.
- E Implement THERMOSTAT_OPERATING_STATE command class.
- E Implement THERMOSTAT_FAN_MODE command class.
- E Implement THERMOSTAT_FAN_STATE command class.
- D Implement THERMOSTAT_SETBACK command class. Have not found any information.
- D Implement DOOR_LOCK_LOGGING command class. Have not found any information.

ongoing:

- E Complete the list of device classes. This involves scanning software / 
documents for the required info or coming along an unknown device class on a 
device.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 12:09

[GoogleCodeExporter]

Regarding sensor multi-level. I see that it is a little bit more difficult than 
that ;-). Version 5 and up support multiple sensor types on a single command 
class. We'd need to expand the binding actions or something or extend the 
binding string to indicate the requested sensor type in case there are more 
than one sensor type. 

We also have the same problem with sensor_alarm. I don't really like expanding 
the enumeration of binding actions with all the alarm types and sensor types 
out there. Have to think about that.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 12:37

[GoogleCodeExporter]

Ben, you got me thinking on the event object value and the conversion of them 
to OpenHAB stages.  I've looked at the homematic binding for inspiration and 
the more I think about it, the more I feel that it should be something like 
this:

1) All command classes should be stateless. This means no values will be stored 
in the command class.
2) Command classes return ZWave events. Command classes return raw Z-Wave 
values in the event.
3) The binding looks up a converter based on both the Item type (Dimmer, 
Contact, Switch) and the command class (Switch, Dimmer, Basic, Whatever)
4) The converter provides a conversion between raw Z-Wave value and a State.

In addition the same converters are used for the return route.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 7:22

[GoogleCodeExporter]

I'll start working on that, it seems one of the more important things of the 
post 1.3 era.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 7:37

[GoogleCodeExporter]

I see your point re. decoupling the API from openHAB - fair enough. I see an 
issue with the multi sensor however. If we do handle the sensor type and keep 
track of the enum (handling the changing versions etc) we will end up with a 
string value being returned for this value - e.g. '17.23 C' for a temperature 
sensor. This is a nice looking string and easy to read, however it is not very 
useful for our openHAB rules etc - where you might want to graph the temp, set 
rules based on min/max temps etc.

Would it not be better to just return a decimal value from this command class? 
And throw away the sensor/unit type information? Although, just reading your 
last idea about the command value converter, I guess we could have a 
specialised converter which takes the string returned from the multi sensor, 
and strips the trailing unit string?

(BTW - great work with the list of TODOs - looks like we have our work cut out 
for us! I would argue we need separate issues for these (or at least groups of 
them) as this issue is getting rather long!)

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 8:13

[GoogleCodeExporter]

Yeah, and I wasn't clear about what I meant... I think we should use precision 
and scale, but indeed leave unit's to the formatting layer. You probably did 
that already like this.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 8:16

[GoogleCodeExporter]

So without units we can do away with the sensor type enums altogether. Although 
I guess we need them for version > 5 to handle multiple types in a single 
command class? We could just do the matching on the raw code returned from the 
sensor - which we report in a nice log message so a user can 'see' what they 
need to specify in the binding config? This eliminates the need for any enums 
to be maintained and keeps the command class code nice and simple.

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

[GoogleCodeExporter]

there is no raw code... there is a bitmap returned in the SupportedGet command, 
so we need the enumeration anyway. The bit position corresponds to a value in 
the enumeration. But this is >4 (>=5) anyway.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 8:22

[GoogleCodeExporter]

And yes, it supports multiple values for a single command class. Joy, joy.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 8:23

[GoogleCodeExporter]

When the report message comes in the sensor type is byte 1 of the payload. I 
was meaning we just dump that number in the logs somehow and someone can use 
that to update their binding config to filter a particular sensor type. That or 
they just look up the code from the docs etc. I.e. temperature = 1 so the 
binding config could be { zwave="9:1:1" }. Not sure what we gain by keeping 
track of the type enum if we are not going to be using it for formatting the 
sensor value (but I am probably missing something...). 

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 8:26

[GoogleCodeExporter]

That's actually true. Getting the supported sensor types and using an 
enumeration will prevent incorrect messages being sent to the node, because you 
can filter out poll requests for a non existing sensor I guess, and you could 
refer to the sensor types by name in the binding string but that's it.

If you want, stick to version 1 of the command. This is just the GET command 
and the report command and only supports single sensors.

The binding provider needs to be adapted anyway, because both for this one and 
sensor alarm the item string format needs to be changed to support sensor types 
and alarm types.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 8:49

[GoogleCodeExporter]

I am still seeing some strange startup issues. Anytime I use OZWCP things are 
fine, but intermittently the binding doesn't quite get things right. I have 
been trying to read the logs but there is so much going on I must admit I 
struggle a bit at times (is it worth downgrading some of the debugging to TRACE 
logging?).

Attached is a log which shows that Node 5 (a 2x1.5kW relay the same as nodes 4, 
6, 7, 8) failing to identify itself as a multi instance switch. Therefore I end 
up with only one of the end points working.

If I stop and start the binding it will usually come back just fine. Other 
times another node will be in this state, or dead altogether. 

I know this is most likely due to my network and the fact some nodes are just 
on the edge of the controller range, but things don't seem to be improving. I 
am wondering what OZWCP does differently to allow these nodes to eventually 
come up. It just seems the binding is very sensitive to network delays and 
(possible) re-routing which I think is going to cause problems for a lot of 
people once this goes out to the masses - as I am sure my type of network is 
fair from uncommon!

BTW - just restarted the binding and Node 5 is fine.

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 8:52

Attachments:

• zwave.zip

[GoogleCodeExporter]

Application update request, Node Info Request Failed again. It's the stick 
saying node 5 cannot be reached for it's node information frame.

The only difference i can imagine is that ozwcp gets this info from cache 
instead of the node, and that is why you don't see this issue with ozwcp.

I don't think that both caching node information or extending time-out values 
for the controller is something for 1.3.0. These are fairly big changes. And 
you still end up with an unreliable network.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 9:00

[GoogleCodeExporter]

Just confirmed on my network that ozwcp does not send queries for this node 
stage. So it caches the info. That's why ozwcp always passes this node stage.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 9:05

[GoogleCodeExporter]

See the attached log file of open-zwave for my network. You get the No Op 
frames from the ping (probe1) node stage. These are pings of ozwcp to test for 
dead nodes, that's what we do too. Next is the manufacturer specific and node 
information query stage. But these do not result in messages to the stick... 
nothing is sent or queued. Only notifications are generated about added about 
added values.. And then there is an "essential queries complete" for a node, 
quite impressive without a single message sent. 

This can only be explained by caching or storing the node info.

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

Attachments:

• [ozwcp log.txt](https://storage.googleapis.com/google-code-attachments/openhab/issue-265/comment-235/ozwcp log.txt)

[GoogleCodeExporter]

Ok - good to know. I am going to try things with the USB stick in a powered hub 
and move it around my server cupboard to see if I can improve its performance!

I am about to push my changes for the multi level sensor. Have a look if you 
get a chance - any feedback welcome!

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 9:16

[GoogleCodeExporter]

That's what I did ;-) My stick is hanging on a usb hub, away from the case.

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

[GoogleCodeExporter]

Already seems better!

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 9:20

[GoogleCodeExporter]

I am trying to build a local version of the binding which includes the new 
multi level sensor. I have been running in the IDE quite happily, but my dev 
machine is a different computer than my home server so I want to test in a 
'real world' environment.

In the past (for previous binding development) I have just run 'mvn clean 
install' in the binding directory in the source tree. I just tried that for the 
ZWave binding and got an error;

"The method setProperlyConfigured(boolean) is undefined for the type 
ZWaveActiveBinding."

I am very new to maven and mercurial (am used to ant and svn) so I am guessing 
the maven build script is pointing to an old version of openHAB or something? 
Any ideas how to resolve this?

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 9:33

[GoogleCodeExporter]

the dependencies are resolved incorrectly then. The solution is to add the 
Z-Wave binding to the pom.xml file in the binding folder and run mvn clean 
install from the root directory... takes a while...

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 9:35

[GoogleCodeExporter]

Many thanks - have just kicked that off. I have pushed the multi level sensor 
changes to my clone so feel free to merge them into yours if you think it is 
worthy ;). Actually, wait till I have finished this build and let me test in my 
live environment...

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 9:44

[GoogleCodeExporter]

Thanks, I will. Any specific reason why you threw away one constructor on the 
serialInterfaceException? I think we could loose a couple and keep only the 
called one, or keep them there.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 9:47

[GoogleCodeExporter]

Yeah - it wasn't compiling with that extra one in there. I meant to ask you
about that. Might have been something to do with my dependencies? But that
was one a fresh pull from your clone so a bit odd. 

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 9:49

[GoogleCodeExporter]

My bad, it's a 1.7 constructor... I will fix this.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 9:51

[GoogleCodeExporter]

Thanks ;-)

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 9:52

[GoogleCodeExporter]

I think you are still in a fair amount of credit when it comes to 'thanks'!

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 9:54

[GoogleCodeExporter]

Hehehe, but the last java I've written was in university so I'm a bit 
struggling here. You'll probably catch me on some other dumb mistakes (or 
Thomas or Kay on review for that matter).

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 9:57

[GoogleCodeExporter]

Ha - are you serious? What you have done with this binding is nothing short of 
phenomenal!

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

[GoogleCodeExporter]

Ok - I am now getting temp updates from my door sensor - stoked!! Sorry to be a 
pain, but I am trying to figure out how to merge my clone with your latest 
changes. How do you do this with hg?

Original comment by ben.jone...@gmail.com on 21 Aug 2013 at 10:56

[GoogleCodeExporter]

pull from my clone... merge...

But maybe wait till i've merged your code.. Doing that now.

Original comment by jwsp...@gmail.com on 21 Aug 2013 at 11:02