I am also trying to get my FGSD002 to work properly. I have defined smoke, heat, tamper, battery and temperature as items and this is what I get (without any map transformations):
Heat: CLOSE
Smoke: CLOSE
Tamper: OPEN
Battery: 100%
Temperature: -
Heat & Smoke seems to be ok with the state “CLOSE”. Have you guys mapped this to “smoke/no smoke” and “Fire/No fire”)? Battery also seems to work fine.
But I’m not sure about Tamper! Why does the sensor report “OPEN”? Is this the regular state? It makes more sense that this should also be “CLOSED” (as the sensor of course isn’t open!).
And finally Temperature: No value is reported (yet). Maybe this is because the temperature hasn’t changed more than 1 degree (as this is the configuration default). I will monitor this the next days to see, if this is the case or if there is another problem with the temperature report.
Hi,
actually I have the value CLOSE from the Tamper item, and I verified that when I open the case the value changes to OPEN.
You can change the parameter 21 about the temperature range difference reporting, just to make sure you receive the values you can set the minimum allowed 0.1 (so you have to type 1, it is multiply by 0.1).
I’ve deleted the node xml, changed parameter 21 to “1” and made a restart of Openhab. Now I also get “CLOSE” for Tamper (but haven’t tried to open the case) and the temperature is also displayed.
As I am (slowly) switching over to OH2: Has anyone this device working with OH2? I thought I simply can take the item definitions over to OH2, but only temperature and battery give me some values then. I do not get values for alarm smoke and alarm heat.
Could anybody with a working device in OH2 post his configuration? Have you made any adjustments (if the device was previously running under OH1)?
Just a comment on this - this isn’t correct. There are many parts to the Z-Wave Plus standard - some are related to low level protocols, which won’t be supported if you have an old stick. However, what is meant here relates to command class issues, and this is a software issue for the controller. In general, Z-Wave plus is handled by OH - OH1 to a lesser degree, but in the case mentioned here for the Lifeline, it’s supported well enough. The notification class isn’t well supported in OH1 though.
My focus, and the recent requests here, is for OH2 so when I test this out, it will be on OH2 (later today I expect).
Ok, so I’ve had a play with the sensor here and will tonight update the binding with new channel definitions.
I tested the SMOKE and HEAT alarms (courtesy of my fire! ).
I enabled config parameter 2 to “All notifications enabled” - without this the heat alarm didn’t work.
I believe you also need to change parameter 4 as the heat alarm doesn’t sound even though the notification came up on the UI - I wasn’t game for another test tonight - it’s not exactly a wife friendly device ;).
This is ONLY using association group 1, which should be configured automatically by the OH binding when the device initialises. This is using the notification class now - the system was previously configured to use the SENSOR_ALARM class. The NOTIFICATION class also sends other alarms which I’ve added, but not tested as they are more difficult (hardware failure, and low battery for example!).
PR is now in. To update to the latest definition, you’ll need to update the binding once it’s built, but also you will need to delete the thing, and add it back in again (no need to exclude/include from the network).
If someone has a little time, it would be nice if the database could be updated to fix some of the parameter text. I’ve fixed some, but a lot of the options for notifications are far too long, and have been truncated so are effectively wrong.
eg -:
If someone has a few minutes to make the database entry look a bit better, I’m sure it would be appreciated .
@chris: Do you know if your change has found it’s way into the binding this night? No matter what I try (bundle:update or deinstall/reinstall binding), I always get:
Sorry - I merged it, but I forgot to trigger a build as the nightly build is not automated . I’m just doing some more database updates and will do a build after that so check in an hour or so and it should be there…
As soon as I find some more spare time I will update more devices (for the notification descriptions, not for any other parameters as I sometimes don’t know what I’m doing there )
@chris: I’ve updated the binding, deleted the thing and the xml and added it again. It was found and initialized with a manual wake up. But I got some confusing log entries:
2016-12-12 21:22:13.039 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 8: setupNetworkKey useSchemeZero=false
2016-12-12 21:22:13.832 [ERROR] [curityCommandClassWithInitialization] - NODE 8: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-12-12 21:22:14.167 [ERROR] [curityCommandClassWithInitialization] - NODE 8: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-12-12 21:22:15.185 [ERROR] [curityCommandClassWithInitialization] - NODE 8: SECURITY_ERROR Invalid state! Secure inclusion has not completed and we are not in inclusion mode. Aborting
2016-12-12 21:22:17.609 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer: Retries exceeded at DYNAMIC_VALUES
2016-12-12 21:22:18.168 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Initialising Thing Node…
2016-12-12 21:22:18.365 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}
java.lang.IllegalStateException: Could not update status, because callback is missing
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus(BaseThingHandler.java:388)[103:org.eclipse.smarthome.core.thing:0.9.0.201612091054]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus(BaseThingHandler.java:415)[103:org.eclipse.smarthome.core.thing:0.9.0.201612091054]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.ZWaveIncomingEvent(ZWaveThingHandler.java:1178)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:567)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.advanceNodeStage(ZWaveNodeInitStageAdvancer.java:1117)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.handleNodeQueue(ZWaveNodeInitStageAdvancer.java:230)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.ZWaveIncomingEvent(ZWaveNodeInitStageAdvancer.java:1306)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:567)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingResponseMessage(ZWaveController.java:293)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:217)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:208)[179:org.openhab.binding.zwave:2.0.0.201612120809]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1324)[179:org.openhab.binding.zwave:2.0.0.201612120809]
2016-12-12 21:22:18.514 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Size error 1<>2 from config_11_1
2016-12-12 21:22:18.516 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Size error 1<>2 from config_12_1
2016-12-12 21:22:18.556 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Initialising Thing Node…
2016-12-12 21:22:23.142 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 2 attempts left!
2016-12-12 21:24:42.939 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Size error 1<>2 from config_11_1
2016-12-12 21:24:42.941 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Size error 1<>2 from config_12_1
2016-12-12 21:24:42.983 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Initialising Thing Node…
Some security command class messages I do not understand.
But the device seems to be ok. I get values for my defined items and I do see the “new” channels (low battery alarm, system alarm etc.).
I will leave it at that, but maybe it’s relevant for you, chris.
But I never changed this setting before. In fact, the advanced settings were always disabled.
So were does this setting come from? And in the description it’s mentioned that only entry control devices like locks will be included securely. So is this smoke sensor also an entry control device? Until now I thought that it isn’t.
And if it’s not, why does this produce error messages in the log?
I will switch over to “do not use security” and re-initialize the device again to see, if this prevents error messages in the log. But I can’t do this until this evening.
What do you mean? It’s been there a long time already.
Maybe the error isn’t anything to do with this - I don’t know as there’s only 1 line really in the log so I’m guessing - sorry.
Some of the errors aren’t related to this, but generally having the security issue can prevent the device working properly so it’s best to eliminate this first.
Of course. I wanted to say “Is this the default setting?” So that the binding has defined this during the initial setup of the stick? Because I didn’t change the setting (AFAIK…).
Anyway. I will try again this evening with no security at all.
) and no log entry in events.log was made
).
.
. I’m just doing some more database updates and will do a build after that so check in an hour or so and it should be there…
.