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]

The only "downside" to the Stella-Z seems to be that it has no manual control. 
So your Z-Wave netwprl always needs to work ;-)

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

[GoogleCodeExporter]

I can't see any problem with that...

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

[GoogleCodeExporter]

Me neither, but some people have family members that prefer knobs or some other 
form of control instead of an i-Phone.

Sometimes I have friends or family staying in my home when we're on holiday: 
"No, I don't have knobs on my convectors. But I can turn on the heating from my 
holiday address for you." ;-)

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

[GoogleCodeExporter]

I was meaning more that there won't be any issue relying on the ZWave network 
being up, now that the binding is so stable ;). But yes - I also have 
difficulty explaining to some that it is just so much easier turning on/off 
lights using a phone/tablet rather than getting up and flicking the switch...

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

[GoogleCodeExporter]

I earlier got some cheap danfoss thermostats on ebay which had a firmware which 
is not really z-wave compliant, bad luck. I just ordered some StellaZ 
thermostat as well. So I might be interested or on helping on the thermostat 
command class. 

Original comment by lars.pfa...@gmail.com on 29 Sep 2013 at 8:13

[GoogleCodeExporter]

That's what I mean. There seem to be two types of Danfoss thermostats. One is 
more or less Z-Wave compatible the other surely isn't. To make matters worse 
they seem to have used the same product no. for a Z-Wave compatible and Z-Wave 
incompatible version. The only way to tell the difference is the firmware 
version. It seemed a bit to risky ordering one of those when you cannot be sure 
that it is Z-Wave compatible.

Original comment by jwsp...@gmail.com on 29 Sep 2013 at 8:23

[GoogleCodeExporter]

Your help is more than welcome. Please take the source from my github clone, 
branch 1.4.0-zwave and add a thermostat command class. ;-)

Original comment by jwsp...@gmail.com on 29 Sep 2013 at 8:24

[GoogleCodeExporter]

Der Rocka,

I've added support for fLIRS (Frequently listening, the siren is such a device) 
devices. It's in my fork. I will try and create binaries tomorrow. I've got a 
full 100db at my fingertips now ;-) Very cool to play with, although my 
neighbours probably won't like it ;-)

Anyway the 1.4.0 binding config for my siren:

Switch Siren_Alarm          "Alarm sirene." (GF_Corridor) 
{zwave="28:command=switch_binary"}
Number Siren_Alarm_Battery "Alarm sirene batterijniveau [%d %%]" (GF_Corridor) 
{ zwave="28:command=battery" }

Original comment by jwsp...@gmail.com on 29 Sep 2013 at 9:15

[GoogleCodeExporter]

JwS - I still get the odd network issue and a node is marked as dead. The only 
problem is that even tho the binding reports the node as dead in the log, it 
doesn't set the 'dead' flag in the code - or the 'command=INFO,item=DEAD' 
binding is never updated.

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

[GoogleCodeExporter]

Great and thanks JwS. Can't wait to try the new binaries.
The problem, that the fibaro double switch stops working after few days goes 
on. But I hadn't time yet to have a look at the logs, but I will do it.
The door sensor works pretty well.

I have thermostats myself and am using them over a year now, but I am using 
them with the control panel of Danfoss. They are working really good. I've 
heard of the problem with the inoperability but read that those which came with 
the official zwave sign on the box should work in most cases with other 
standard controller. I've looked at mine and they have this sign on the box. 
But as I said I didn't testet them without the original controller.

Best,
André

Original comment by DerRo...@gmail.com on 30 Sep 2013 at 8:42

[GoogleCodeExporter]

Ben,

Do you have the log?

Original comment by jwsp...@gmail.com on 30 Sep 2013 at 1:59

[GoogleCodeExporter]

Hello all!
About two weeks ago I've checked out jswp clone (the last version which was on 
google-code before migrating to github).
Especially thanks for full MultiSensor support, as now I use all sensors of my 
AEON LABS 4-in-1 Multisensor.
And I want to say that the binding works very stable in general.
But I have the same problem as Der Rocka, with another device:
TKBHOME TZ66D (http://www.pepper1.net/zwavedb/device/341).
About an hour or two after I start the binding, it becomes dead. Status polling 
(BinarySwitchGet) and sending commands (BinarySwitchSet) stop working. Even 
incoming status reports (my controller is in "Tap right paddle twice" (#3) 
association group) from the device do not reach the binding (or the controller, 
I don't know). The device itself works definitely, because:
1) It sends commands to other associated devices, and they always react (for 
example, I have another switch associated with "Tap right paddle once" (#2) 
group, and it always switches on/off when I tap the right paddle once).
2) The diode indicating network activity flashes when I tap the right paddle 
twice.
3) The device receives commands and reports statuses from/to OZWCP.
I will provide logs tomorrow, but it is a very strange problem.

I am waiting for three similar devices arriving me this Wednesday. The devices 
are the dimmers:
 - two TKBHOME TZ65D (http://www.pepper1.net/zwavedb/device/343);
 - one TKBHOME TZ65S (http://www.pepper1.net/zwavedb/device/424).
So, I will install them and test, probably this weekend.

By the way, I also have a Fibaro Double Switch and it works perfectly, and 
never was dead in my network.

Original comment by roher.ro...@gmail.com on 30 Sep 2013 at 2:07

[GoogleCodeExporter]

By the way, as now I have complete development environment setup, I have access 
to the code. I've seen that "BasicSet" to the Controller is always treated as 
"BasicReport". I want to implement so that it will be a default behaviour, but 
if I put something like "5:1:command=basic_set" in the item configuration, this 
item (for example, a Switch) will react only on "BasicSet", sent from the node 
5:1 to the controller. I will explain why I need it:
The TKBHOME TZ66D (and other TZ.. I think) always sends "BasicSet" to the 
devices associated with it.
As I've mentioned previously, my controller is in the "Tap right paddle twice" 
group.
Assuming the problem from the previous post is solved (the device is not DEAD), 
I double-click the right paddle of my switch. It doesn't change the load 
connected to the switch (cause the left paddle is responsible for it), the 
switch only sends "BasicSet" to the controller. I want, for, example, to 
activate "Nobody at home" mode by this event, but now our binding treats it as 
"BasicReport", and just sets the "Light_Hall", for example, to ON (or OFF).
But if I implement this command, and make a configuration like this:
Switch Light_Hall     "Light in Hall"  (Hall)    
{zwave="5:1:command=switch_binary"}
Switch Nobody_At_Home "Nobody at Home" (Service) 
{zwave="5:1:command=basic_set"},
after I double-click the right paddle of my switch, the "Nobody_At_Home" will 
be set to ON (or OFF), depending on the value, and "Light_Hall" will not be 
touched.

Do you support this idea?
Or maybe you have some counter-arguments, or maybe another proposal of 
configuration string?
Let's discuss it ))

Original comment by roher.ro...@gmail.com on 30 Sep 2013 at 3:46

[GoogleCodeExporter]

It should already work that way. Normally you'd have to specifically add 
respond_to_basic=true to a binding string to have it accept the basic command 
class in addition to the one specified.

Your binding string should look like the strings below:

Switch Light_Hall     "Light in Hall"  (Hall)    
{zwave="5:1:command=switch_binary"}
Switch Nobody_At_Home "Nobody at Home" (Service) {zwave="5:1:command=basic"}

Original comment by jwsp...@gmail.com on 30 Sep 2013 at 4:54

[GoogleCodeExporter]

make sure not to toggle Nobody_At_Home from the openhab interface though as 
this would probably toggle the Light_Hall switch.

Original comment by jwsp...@gmail.com on 30 Sep 2013 at 4:56

[GoogleCodeExporter]

Thanks, I didn't think about it.
But in my case I can separate switch_binary and basic classes.
And what if the device doesn't support switch_binary class?
Then we obviously cannot do like this:
Switch Light_Hall     "Light in Hall"  (Hall)    {zwave="5:1:command=basic"}
Switch Nobody_At_Home "Nobody at Home" (Service) {zwave="5:1:command=basic"}
because they will be identical from binding point of view.

But maybe you are right, and it's not worth spending time -- I cannot remember 
any device that supports ONLY basic command class.

And about toggle - I may dislpay it as Text instead of Switch in the UI, and 
nobody will be able to toggle it (except exlicit set from XMPP or OSGI Console).

Original comment by roher.ro...@gmail.com on 30 Sep 2013 at 5:21

[GoogleCodeExporter]

Unfortunately not JwS - sorry - if/when it happens again I will copy the log 
across from my prod machine and send you a copy.

Original comment by ben.jone...@gmail.com on 30 Sep 2013 at 7:12

[GoogleCodeExporter]

Roher,

A device will either support multi instance / endpoint support or multiple 
command classes on the same node for different functions on a node. The latest 
version of the binding supports both. With the same command class on the same 
node there is no way to differentiate anymore.

JwS

Original comment by jwsp...@gmail.com on 30 Sep 2013 at 9:29

[GoogleCodeExporter]

Yeap - that's exactly what I wanted to say, so there's no need for additional 
implementation about this point.

Original comment by roher.ro...@gmail.com on 1 Oct 2013 at 5:10

[GoogleCodeExporter]

Hmm... I've added a new device to my network, an everspring SF812 smoke sensor. 
It made me realize that one of my assumptions (and of open-zwave) is incorrect: 
I assumed that every non (frequently) listening device would automatically have 
a wake-up class. Now it appears that this is not the case. This device never 
wakes up. It only sends packets when an alarm is triggered or the battery is 
almost empty.

What's even worse is that it supports configuration / adjustment only during 
the first 15 minutes that it is included in the network. Then it simply isn't 
reachable anymore until it is triggered.

Now after a restart of openHAB there is no way of communicating with it 
anymore. So that means: No state info (not on the battery, nor on the state of 
the sensor). To make sure that it still works as expected, the only way to get 
it to do something is to hit the test button.

It will also stay in the initializing state forever after a restart.

I have to think a bit about how we are going to deal with these devices.

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 8:29

[GoogleCodeExporter]

Almost like you need the ability to manually define/initialise some nodes. Not 
sure how that would work, but it could be incorporated into your idea of 
persisting device configs? 

Original comment by ben.jone...@gmail.com on 1 Oct 2013 at 8:45

[GoogleCodeExporter]

I was thinking along the same line indeed.

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 9:09

[GoogleCodeExporter]

Oh...what does Everspring say about it?

A choice could be to add a config-String that says that the item won't 
communicate in a "normal" way. So that no communication is needed.
What steps are done during the initialization process? Could some be done as 
generell configurations for those devices? Like no communication is good 
communication for those devices?

Best,
André

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 9:09

[GoogleCodeExporter]

I've more or less solved it I guess. Based on the protocol information (that 
comes from the controller EEPROM) for the node, we already construct the 
command classes based on the device class. It seems that my smoke sensor does 
not support additional command classes on top of the mandatory by the device 
class, or versions of command classes > 1. 

This means that the node info is complete after the protocol information. No 
need to query the device.

In addition to this I've added support to add a command class based on a 
received message, in addition to the protocol info and the received Node 
information frame. This way command classes that somehow are not (yet) 
initialized based on the latter two, will be added based on a received message. 

As I promised binaries (for 1.3.1), here they are, including this adjustment.

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 10:08

[GoogleCodeExporter]

Hello! As promised, sending the logs of my zwave binding (after today restart).
As you can see, node 7 (my TKBHOME switch) stays alive for about 20 minutes 
after the start, and then becomes dead.

And could you please also look why my node 18 is marked as DEAD at 
initialization stage? In general it works ok, the binding receives updates from 
the device and changes the item's values, but the following items never change, 
they always stay uninitialized (I think it is because node is initially marked 
as DEAD):
Switch Multi_Sensor_Balcony_Dead   "Multi Sensor Balcony Status"                
   (Balcony_DevInfo)   
{zwave="18:1:command=info,item=dead,refresh_interval=600"}
String Multi_Sensor_Balcony_Update "Multi Sensor Balcony Update Time: 
[%1$td.%1$tm.%1$tY %1$tT]"   (Balcony_DevInfo)   
{zwave="18:1:command=info,item=last_update,refresh_interval=600"}

Original comment by roher.ro...@gmail.com on 1 Oct 2013 at 10:44

Attachments:

• zwave_binding.log

[GoogleCodeExporter]

Great! Are those binaries with the changes in the zwave binding string 
(addition of "command=")?

The process you described getting the command classes of such an item sounds 
good to me!

Thank you.

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 11:12

[GoogleCodeExporter]

It seems that the multi sensor sends a listening flag... but it isn't. So we 
get time-outs and eventually we report it dead, instead of using the wake-up 
queue.

Is it powered or does it use batteries?

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 11:13

[GoogleCodeExporter]

DerRocka, Yeah, it uses the new binding string format.

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 11:14

[GoogleCodeExporter]

OK, I've seen in the pepper DB that the next version of the multi-sensor will 
correctly report the listening flag. So I guess I can add a workaround to the 
binding to override it and set it to false. 

Only thing I'm not sure about is how it behaves if it's connected to an USB 
power source. When it stops sending wake-up intervals then, we have a problem 
and then the listening bit should be dependent on the power situation (USB 
powered versus battery powered).

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 11:26

[GoogleCodeExporter]

so...testing right now :)

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 11:26

[GoogleCodeExporter]

It can be both - either battery-powered or usb-powered. If usb-powered it is 
listening.

The device should be excluded from the network and then re-included, if the 
power is switched from batteries to usb and vica-versa.

In my configuration it is constantly powered from usb, so in term of z-wave it 
is mains-powered, so we should not use the wake-up queue, as the device never 
sleeps.

Original comment by roher.ro...@gmail.com on 1 Oct 2013 at 11:28

[GoogleCodeExporter]

Oh, I've just answered your question without knowing it :)

Original comment by roher.ro...@gmail.com on 1 Oct 2013 at 11:29

[GoogleCodeExporter]

Hi,
how is the syntax for all the info things.
Above you wrote:
String ZwaveStatsACK "Number of Acknowledgments [%s]" (gZwaveStats) 
{zwave="1:command=info,item=ack"}
But I won't get ack,can,nodeid,homeid etc. all other seem to work just fine. 
And I get the battery status of my Everspring siren (yeah... :) )
But the siren itself I can't test right now, because if I would turn it on I 
can't hear it because of the ca. 25km distance to my home :-D

André

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 11:50

[GoogleCodeExporter]

Or am I just to impatient? :)

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 11:53

[GoogleCodeExporter]

DerRo, it was a mistype in the example.
I've also tried this, but it didn't work for me.
After that I've changed item type from String to Number, and everything works.
So, put 'Number ZWaveStatsACK bla-bla-bla...' in your item config file.

Original comment by roher.ro...@gmail.com on 1 Oct 2013 at 11:53

[GoogleCodeExporter]

It used to be string types, but ben changed them to ints...

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 11:55

[GoogleCodeExporter]

DerRocka, i've found it. I've implemented the decoding of 
Sensor_Multilevel_Supported_GET incorrectly. I will fix this.

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 11:56

[GoogleCodeExporter]

oh...yes. So too impatient :)
should have made more thoughts about it. But it is easier to ask. So thanks and 
sorry, becaus I read that recently again :)

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 12:00

[GoogleCodeExporter]

Could it be possible to get to the highest range of int with some numbers in 
error cases perhaps? So that an exception is thrown? Or couldn't it be?
If the first case (string) was casted from int it makes no difference though.

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 12:04

[GoogleCodeExporter]

And the new binding with Sensor_Multilevel_Supported_GET fixed. Could you test 
it DerRocka?

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 12:31

[GoogleCodeExporter]

Sorry, I meant Roher... Also your node 7 seems to be a genuine routing problem. 
It tries 3 times to send a message. Could you try moving it closer or adding a 
node in between. You could also try the open-zwave control panel to assign 
different return routes to the node (also see the discussion in 261 for some 
tips)

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 12:36

[GoogleCodeExporter]

hi,

I'll replace it anyway. Yes I tried it and battery status of the sirene seems 
to work just fine. But I will try the sound this evening.

Right now I am testing different info strings for the nodeid, homeid, routing 
etc. How are the zwave strings for those?
Changing the Strings to Numbers for the ACKs, CANs etc. works fine.

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 12:50

[GoogleCodeExporter]

Emm, and these binaries are compatible with 1.4.0-SNAPHOT openhab? Because now 
I am using that one, compiled from your clone.

About node 7 - I've also thought about the routing issue, but:
1) Why then does it work for 20-30 minutes everytime after I start the binding?
2) I already have two nodes between this node and the controller, and I also 
have a node farther from the controller than this one, and it works without any 
issues.
I've already tried to update neighbours list and assign return routes for all 
my devices a week ago, but the situation didn't change.
Doesn't all this seem strange?

Maybe it's worth trying to exclude this node from my network and include it 
again?

Original comment by roher.ro...@gmail.com on 1 Oct 2013 at 1:07

[GoogleCodeExporter]

btw. where can I find your github clone? And do I have to be logged in? Never 
used it before. But perhaps some question (e.g. nodeid etc.) can be answered 
throug a look at your code.

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 2:38

[GoogleCodeExporter]

https://github.com/jspuij/openhab

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 3:02

[GoogleCodeExporter]

No, 1.4.0 can be compiled from my clone, that's also up to date.

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 3:03

[GoogleCodeExporter]

Hi JwS,

unfortnately the Everspring siren can't be switched on with the following line 
and the switch item in my sitemap:

Switch Alarm_Sirene "Alarm-Sirene" <siren-on>      (gAlarmSystem)  { 
zwave="3:command=switch_binary" }

Any ideas? The battery info is working really well.

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 4:36

[GoogleCodeExporter]

Could you provide the log. I have the same binding string and it works pretty 
well. It can take up to 2 seconds to switch on though, because it's not always 
listening.

Original comment by jwsp...@gmail.com on 1 Oct 2013 at 5:18

[GoogleCodeExporter]

Hi,
yes of course. Last 5000 lines with several restarts. The siren is Node 3.

how is your line for getting the homeid of your controller? The other devices 
seem to work really well.

Thank you!

Original comment by DerRo...@gmail.com on 1 Oct 2013 at 5:47

Attachments:

• zwave.log