Improvements of the Z-Wave binding for the 1.4.0 version of openhab

[GoogleCodeExporter]

With the (upcoming) release of 1.3.0, it's time to think about and work on the 
next version of the Z-Wave binding. We like this as much to be a collaborative 
effort as the previous version was.

Ideas and suggestions about what to implement are welcome. In case you actually 
want to start coding, there is a list of items to work on below:

high priority:

- D make binding between command classes and items more dynamic. So that 
switches can be bound to dimmers, sensors to contacts or switches, etc.
- 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.
- 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 issue reported on code.google.com by jwsp...@gmail.com on 2 Sep 2013 at 12:45

[GoogleCodeExporter]

Hi,

@Ben:
Great to hear that the stick doesn't lose its associations. Perhaps I'll do an 
update too. But the binding tells me that my stick has the version 3. Perhaps 
this is where Jan has got his information from?

@Roher:
You can avoid your stick from getting other device names/files by using an 
'udev rule'. For that just create or add to existing file 
(/etc/udev/rules.d/60-usb-serial.rules) a rule like the following:

#zwave
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
        ATTRS{idVendor}=="ID_VENDOR_ID", ATTRS{idProduct}=="ID_MODEL_ID", ATTRS{serial}=="ID_SERIAL_SHORT", \
        SYMLINK+="zwave0", GROUP="tty", MODE="0666"

For the information you need type in the following:
"sudo udevadm info -q all -n /dev/ttyUSB2"
as ttyUSB2 as your stick file.

There you can find the "ID_VENDOR_ID", "ID_MODEL_ID" and the "ID_SERIAL_SHORT". 
Replace these IDs in the rule and save the file. Now your sitck should always 
be recocgnised as "/dev/zwave0".

Don't forget to add the following line to your start/start_debug script:
"-Dgnu.io.rxtx.SerialPorts=/dev/zwave0"
(if you are using more serial devices seperate them by using a ":" after the 
"=" and the first device.

Best,

André

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 8:01

[GoogleCodeExporter]

My logs look the same before and after the upgrade.

2013-09-13 08:15:27 DEBUG o.o.b.z.i.p.ZWaveController[:445]- Got 
MessageGetVersion response. Version = Z-Wave 2.78, Library Type = 0x01

2013-09-13 08:15:27 DEBUG o.o.b.z.i.p.ZWaveController[:585]- API Version = 3.7

Does this mean the upgrade didn't work? According to what I downloaded it 
should have updated to 3.07.

Original comment by ben.jone...@gmail.com on 18 Sep 2013 at 8:13

[GoogleCodeExporter]

Hi,

the info for my stick looks the same as yours. But I haven't upgraded yet.

"2013-09-17 11:44:03 DEBUG o.o.b.z.i.p.ZWaveController[:445]- Got 
MessageGetVersion response. Version = Z-Wave 2.78, Library Type = 0x01"

But the version shown in HABdroid/openHAB is 3.

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 8:17

[GoogleCodeExporter]

@André:
Thank you, but unfortunalely it doesn't work for me:
I've tried the same trick with the permanent symlink that udev has created 
automatically:
/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port
0

And when I put
-Dgnu.io.rxtx.SerialPorts=/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Ser
ial_Controller_D-if00-port0
into java args, and put the same string into z-wave config in openhab.cfg, the 
binding crashes when trying to open the device with the following log:
=======================================================
12:19:48.053 INFO  o.o.b.z.i.p.ZWaveController[:128] - Starting Z-Wave 
controller
12:19:48.053 INFO  o.o.b.z.i.p.ZWaveController[:627] - Connecting to serial 
port 
/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port
0
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb4ad33ee, pid=7251, tid=2396609392
#
# JRE version: 6.0_18-b18
# Java VM: OpenJDK Client VM (14.0-b16 mixed mode linux-x86 )
# Derivative: IcedTea6 1.8.13
# Distribution: Debian GNU/Linux 6.0.4 (squeeze), package 6b18-1.8.13-0+squeeze2
# Problematic frame:
#
[error occurred during error reporting (printing problematic frame), id 0xb]

# An error report file with more information is saved as:
# /opt/openhab/hs_err_pid7251.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#
Aborted
=======================================================
and creates the file hs_err_pid7251.log, which I have attached to my message.
I'll try to create my own symlink as I have described above, but I think there 
is no difference.

@JWSP:
IMHO, it is a real situation when a user can just remove the stick from his/her 
PC when OpenHAB is running. My changing port just emulates this situation. And 
it should not lead to crashing of the whole OpenHAB server. Of course, Z-Wave 
binding will stop, but OpenHAB itself should continue working.

Original comment by roher.ro...@gmail.com on 18 Sep 2013 at 8:29

Attachments:

• hs_err_pid7251.log

[GoogleCodeExporter]

I just re-ran the upgrade on my stick for 3.07 and it all completed 
successfully. However after restarting the binding I am still seeing;

2013-09-18 20:33:34 DEBUG o.o.b.z.i.p.ZWaveController[:445]- Got 
MessageGetVersion response. Version = Z-Wave 2.78, Library Type = 0x01

Will be interested to hear if anyone else has any luck with this.

Original comment by ben.jone...@gmail.com on 18 Sep 2013 at 8:35

[GoogleCodeExporter]

@Ben:
I can't test right now, but will try it this week hopefully.

@Roher:
Weird thing. I don't have any problems with my symlink. Perhaps it is because 
Jave expects a file which is located under /dev directly? I don't know whether 
it could be the problem. Perhaps it's worth to try my example? At least it 
couldn't get worse :)

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 8:45

[GoogleCodeExporter]

@André:
Yes, your solution works! I don't know what is the difference, but it works!
Thank you very much!

Original comment by roher.ro...@gmail.com on 18 Sep 2013 at 9:27

[GoogleCodeExporter]

Ben, I was just assuming that that version number was the stick software 
version number, because that is what it should report i guess.

But who knows, maybe they forgot to update this number, or it is another 
version number. If the utility says succeeded, it probably did.

Original comment by jwsp...@gmail.com on 18 Sep 2013 at 9:32

[GoogleCodeExporter]

@Roher:
Great to hear :)

@Jan:
Perhaps it is the number of the zwave protocol which the stick uses?

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 9:39

[GoogleCodeExporter]

The serial api version number is returned from serial_api_get_capabilities and 
reports 3.7 in the case of Ben.

Z-Wave version numbers is a mess ;-)

Original comment by jwsp...@gmail.com on 18 Sep 2013 at 10:39

[GoogleCodeExporter]

Yep - as long as my lights turn on when they are supposed to I am happy!

Original comment by ben.jone...@gmail.com on 18 Sep 2013 at 11:36

[GoogleCodeExporter]

fully agree :)

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 11:41

[GoogleCodeExporter]

So what is next JwS? Everything is running pretty sweet on my setup now. I have 
some dimmer modules arriving tomorrow which I will install soon (once I get the 
new wall switch modules). 

I now don't have any polling since all state changes (manual) are being handled 
by the binding - which means a much more manageable log file! I am getting next 
to no errors or warnings apart from the odd timeout etc. Initialisation is 
pretty solid, I occaisionally get a few errors which usually go away after a 
restart. 

I am very happy with the state of the binding as it stands - so thanks very 
much for all your help! This thing is definitely ready for prime time.

For reference - I have a Aeotec USB Z-Stick, 1 x Aeotec Micro Smart Energy 
Switch, 5 x Fibaro 2x1.5kW relays, 1 x Door Sensor (with temp sensor), and 1 x 
Universal Sensor (with temp sensor).

Original comment by ben.jone...@gmail.com on 18 Sep 2013 at 11:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@Jan:
where did you buy the greenwave (schuko) power bar? I searched the web but 
found nothing. But the device sounds very interesting.

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 12:34

[GoogleCodeExporter]

Actually I got it from somebody who was testing the hardware for one of the 
energy companies in the Netherlands. They offer these devices with proprietary 
controllers, but they are just regular Z-Wave devices.

Nuon has a webshop that sells them, but I doubt to foreigners. 
http://www.nuonenergiewinkel.nl/7591/smart-plug-6-voor-nuon-e-manager

Original comment by jwsp...@gmail.com on 18 Sep 2013 at 1:31

[GoogleCodeExporter]

Hi,

I think you are right. I'll search for others.

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 1:42

[GoogleCodeExporter]

I have this feeling that they partner with OEMs to try and sell their stuff. 
This makes it probably harder to get them.

Original comment by jwsp...@gmail.com on 18 Sep 2013 at 1:50

[GoogleCodeExporter]

@Ben:

Well, I have a smoke alarm, a sirene, thermostats and a multi-sensors waiting 
to be installed. They probably have command classes that we don't support yet.

I was thinking about implementing Security and CRC_16 as well. I have devices 
now that support these command classes.

Finally I'm thinking of implementing the "optimize network" functionality 
similar to e.g. homeseer (request neighbor updates, remove return routes, 
assign return routes, rinse, repeat). 

Original comment by jwsp...@gmail.com on 18 Sep 2013 at 2:37

[GoogleCodeExporter]

Great to here. I'm waiting for my new devices, a siren and a window/door 
contact to arrive and of course to be installed. :)

Original comment by DerRo...@gmail.com on 18 Sep 2013 at 2:41

[GoogleCodeExporter]

Yeah I think the next thing I really want is a ZWave door lock, would round off 
my home security automation nicely. So I would put a big vote in for 
security/lock etc support. Do you have a lock ready for testing?

The network optimisation stuff sounds very useful too - it is a bit of a pain 
having to stop everything, run OZWCP to update routes etc, then cross fingers 
and toes that the binding will start again!

Original comment by ben.jone...@gmail.com on 18 Sep 2013 at 8:45

[GoogleCodeExporter]

JwS - think I still have one more small issue with the node stage 
initialisation stuff. My door sensor (node 9) sometimes fails to initialise 
properly. It still receives and process basic reports ok (i.e. door 
opening/closing) and the battery reports are coming through ok, but the 
temperature readings are failing.

Attached are the logs if you would be so kind as to have a look with your well 
trained eye! I have had a look and it seems the node doesn't quite initialise 
the multi instance command class for some reason.

I will keep digging but you seem to spot issues in these logs far quicker than 
I am ever able to do!

Many thanks,
Ben

Original comment by ben.jone...@gmail.com on 19 Sep 2013 at 8:11

Attachments:

• zwave.zip

[GoogleCodeExporter]

I think the issue might be in ZWaveWakeUpCommandClass, line 185. Looking in the 
logs for node 9 it wakes up and gets to the MANU_SPECIFIC stage where it sends 
off version requests for both the WAKE_UP and MULTI_INSTANCE classes (line 
4339).

It only receives a response to the first of these version requests (line 4410) 
but doesn't get the second response until line 9237. In between that time the 
node wakes up  (line 6777) and I believe during this wake-up phase the node 
stage is being advanced.

Then when the node tries to process the second VERSION message it ignores it 
since the node has been advanced past that stage.

Hope this helps!

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

[GoogleCodeExporter]

Hi,
my new devices arrived: An Everspring Indoor Siren 
(http://products.z-wavealliance.org/products/273) and a Vision Door Sensor 
(http://products.z-wavealliance.org/products/702). But right now im not able to 
use them with the 1.3.0 binding. My items are like:

Switch Alarm_Sirene "Alarm-Sirene" { zwave="3:1" }
Number Alarm_Sirene_Battery "Alarm-Sirene Batterie [%s]" (gZwaveStats)   { 
zwave="3:1:battery_level" }
Contact Tuer_Sensor "Tür Sensor [%s]" { zwave="6" }
Number Tuer_Snsor_Battery "Tür Sensor Batterie [%s]" (gZwaveStats)   { 
zwave="6:1:battery_level" }

Or should I try your new binding where I can state the command_class I want to 
use?

Can someone guide me to the right direction? In ozwcp all looks very good. 
Besides that I have 4 nodes but my last one does have no. 6, because for 
testing I added and removed it from my network. But now I have node 1, 2, 3 and 
6. Looks weird.

Best, André

Original comment by DerRo...@gmail.com on 20 Sep 2013 at 11:19

[GoogleCodeExporter]

Could you send me your log please?

Original comment by jwsp...@gmail.com on 20 Sep 2013 at 12:28

[GoogleCodeExporter]

Yes of course :)
forgotten.

Original comment by DerRo...@gmail.com on 20 Sep 2013 at 12:53

Attachments:

• zwave.log

[GoogleCodeExporter]

Node 6 is actually OK. The door sensor. The only issue is that it's wake-up 
interval is set to 3600 seconds and it takes two cycles to initialize, so it 
will probably take 2 hours before it starts working. You could shorten the 
interval to 5 minutes at the expense of battery life. Once the binding supports 
restoring the node info from config, this is not necessary anymore.

Now node 3 is a flirs device and currently we don't support flirs devices yet, 
but as I have the same alarm, it probably will not take too long.

Original comment by jwsp...@gmail.com on 20 Sep 2013 at 1:31

[GoogleCodeExporter]

Ah. Didn't know that. I noticed the 3600 seconds in ozwcp, but thought it would 
be a good value.

For the flirs device I could and should update to the new binding. But I will 
wait for it :)

Thanks for your help!

Original comment by DerRo...@gmail.com on 20 Sep 2013 at 1:45

[GoogleCodeExporter]

3600 seconds is a good value if your network is stable and you don't restart 
openHAB very often. If you're like me, play a lot with your setup, then i'd 
reduce it and stock up on some batteries ;-)

Original comment by jwsp...@gmail.com on 20 Sep 2013 at 2:55

[GoogleCodeExporter]

There is another option: usually a button sequence will keep the node awake for 
15 minutes or so to allow this kind of initialization. So you could activate 
your node before starting openhab.

Original comment by jwsp...@gmail.com on 20 Sep 2013 at 2:56

[GoogleCodeExporter]

Battery stock is fine :)

You are right. I really often restart my openHAB, because of playing with the 
setup.

Original comment by DerRo...@gmail.com on 20 Sep 2013 at 3:03

[GoogleCodeExporter]

Hi,

I've got a question concerning my door sensor. Perhaps it is a general zwave 
network question.

I noticed that the value of the status in ozwcp of the integrated reed contact 
only updates the times the device wakes up. Nevertheless the value of "Last 
Heard" updates every time I move the magnet from or to the device. But then I 
cannot see the sensor value being updated.

Isn't it enough to include the device to the network? Do I have to do more?

Thanks.

Best, André

Original comment by DerRo...@gmail.com on 21 Sep 2013 at 4:39

[GoogleCodeExporter]

Sounds like it is fine. You might need to enable basic report handling as my 
FIBARO door sensor only sends BASIC reports. See the WIKI for details on how to 
configure that. But the device will send reports before it is properly 
initialised so it will be obvious it is working right away.

Original comment by ben.jone...@gmail.com on 21 Sep 2013 at 8:30

[GoogleCodeExporter]

JwS - did you see my comment #123? Think there is something not quite right but 
I am not certain of the best way to fix it. Is it as simple as removing the 
nodeAdvance() call in the WakeUp class?

Original comment by ben.jone...@gmail.com on 21 Sep 2013 at 8:32

[GoogleCodeExporter]

Thank you Ben. You guided me in the right direction. I changed my item from 
"contact" to "switch" and now my rule works pretty well :)
For testing I added a new item which uses basic reports and it reports on every 
change "0x04". What is weird is when I have a look in the lock I see the states 
OPEN and CLOSED too. Well, now everything seems to work fine.
Does anybody know whether I can remove groups which I added for playing in 
ozwcp without removing the whole device?

Original comment by DerRo...@gmail.com on 21 Sep 2013 at 9:48

[GoogleCodeExporter]

Ben, I'll try and look at it soon. Pretty busy with my day job ;-)

Original comment by jwsp...@gmail.com on 24 Sep 2013 at 9:02

[GoogleCodeExporter]

I hear ya mate!

Original comment by ben.jone...@gmail.com on 24 Sep 2013 at 9:11

[GoogleCodeExporter]

Ben, I think i've fixed #123. It's in my github clone.

Original comment by jwsp...@gmail.com on 27 Sep 2013 at 6:17

[GoogleCodeExporter]

BTW, I've deleted the google code clone. All code with history is in my github 
repository.

Original comment by jwsp...@gmail.com on 27 Sep 2013 at 6:18

[GoogleCodeExporter]

DerRocka,

I've started working on the Siren. I have it myself as well. Turned it on 
today, 100db is quite loud ;-)

Anyway, I first have to clean up some classes because they got over a 1000 
lines, but i'll try and finish it this weekend.

Original comment by jwsp...@gmail.com on 27 Sep 2013 at 8:19

[GoogleCodeExporter]

Great to hear. You are right...100db are quite loud. First I had it less loud 
but I thought this couldn't be heard 1 or 2 floors up or down, so I left it at 
100 db :-)

I would love to help you programming, but I haven't set up the development 
environment yet and fear that I don't understand enough of the ZWave protocol 
internals to be a really good help at the moment.

Thank you anyway :-)

Original comment by DerRo...@gmail.com on 27 Sep 2013 at 11:02

[GoogleCodeExporter]

JwS - thanks for fixing that issue - I am trying to figure out how to pull your 
changes so I can compile and test. I gotta say, this GitHub is taking some 
getting used to!

Original comment by ben.jone...@gmail.com on 28 Sep 2013 at 9:15

[GoogleCodeExporter]

Hi,

I have some question, remarks:

- I got an exception where most information where lost:
2013-09-27 09:17:55 INFO  o.o.b.z.i.p.ZWaveController[:627]- Connecting to 
serial port /dev/ttyAMA0
2013-09-27 09:17:56 ERROR o.o.b.z.i.p.ZWaveController[:642]- null

According to the debugger / code it is NoSuchPortException where no other 
information are attached. For that case a more detailed information somewhere 
would be nice. I havent been able to find the SerialInterfaceException somehow. 
A symlink of /dev/ttyAMA0 to a ttyS80 interface worked fine as workaround. 

- Is the "Eurotronic StellaZ" Thermostat supported via the basic command class? 
Do you have experience with other thermostats?

Thanks!

Lars  

Original comment by lars.pfa...@gmail.com on 28 Sep 2013 at 3:04

[GoogleCodeExporter]

Hi Lars,

I believe I had that null exception when I forgot to add the line for the 
symlink in the startup script. Did you add that? 

André

Original comment by DerRo...@gmail.com on 28 Sep 2013 at 4:09

[GoogleCodeExporter]

Yep check the wiki for instructions about how to configure openhab to recognise 
symlinks. The io library used doesn't support symlinks directly.

Original comment by ben.jone...@gmail.com on 28 Sep 2013 at 7:38

[GoogleCodeExporter]

Hi,

@André: yes, the link will is created at boot time.
@Ben: AMA0 is not a symlink and the (on boot created) symlink works out of the 
box. So no need for a wiki reading session ;)

But I would like to point out my main question: Has someone experience with 
zwave thermostats? Since the thermostat setpoint device class appears under a 
"high priority" feature for 1.4 I would assume that there must be someone 
telling me which thermostats should work. The only 2 thermostats I can find so 
far is the danfoss 014G0012 and the Eurotronic StellaZ.

Lars

Original comment by lars.pfa...@gmail.com on 29 Sep 2013 at 12:36

[GoogleCodeExporter]

Apologies Lars - did look closely enough at your logs. As for the thermostat 
device, I don't think this has been implemented yet. JwS and I have only been 
adding support for devices we own and can test. If you get your hands on a 
thermostat then perhaps you could have a go at developing the command class 
support for it?

Original comment by ben.jone...@gmail.com on 29 Sep 2013 at 7:17

[GoogleCodeExporter]

Actually I ordered the StellaZ, so expect support for it soon. I think it will 
work with the basic command class as well for setting temperatures. Don't 
expect reading the  measured temperature though.

I ordered the StellaZ instead of the Danfoss because it fits nicely on my jaga 
convectors (no adapter needed) and I heard some horrible stories about Danfoss 
and Z-Wave compatibility.

Original comment by jwsp...@gmail.com on 29 Sep 2013 at 7:21

[GoogleCodeExporter]

Reading temperature will be supported once we support the thermostat* command 
classes.

Original comment by jwsp...@gmail.com on 29 Sep 2013 at 7:22

[GoogleCodeExporter]

Great stuff - looking forward to seeing the ZWave family growing ;).

Original comment by ben.jone...@gmail.com on 29 Sep 2013 at 7:22