is the fibaro flood sensor
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/127
in the binding?
it keeps getting discovered as Unknown
Can you provide the type/id for your device so I can check?
you probably mean something else then fgfs 101 ?
where can I get that from?
Yes.
What does the device get called? Does is print some numbers in brackets after the Unknown (eg “Unknown (0000:1111:2222::3.33)”. If not, there should be something similar logged in the log, or you can post the XML file that (hopefully) is generated and I can get it from there.
both no
just unknown … no xml
happens to a buddy of mine aswell with the most current binding version
Ok - what about looking in the log then? It should be printed there (or just email me the log that captures the initialisation).
did send you a log with a full oh2 startup
I have just installed the new stuff, and while I got some exception during startup, it all seams to be good now after a couple of restarts. However, my ST812 Flood Sensor still comes up as “unknown” I’m afraid.
Here’s the exceptions that I got. (For reference, I don’t have these after some restarts)
java.lang.NullPointerException
at org.openhab.binding.zwave.internal.protocol.serialmessage.ZWaveCommandProcessor.checkTransactionComplete(ZWaveCommandProcessor.java:70)
at org.openhab.binding.zwave.internal.protocol.serialmessage.GetVersionMessageClass.handleResponse(GetVersionMessageClass.java:44)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingResponseMessage(ZWaveController.java:270)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:207)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:199)
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1073)
openhab> java.lang.ArrayIndexOutOfBoundsException: 6
at org.openhab.binding.zwave.internal.protocol.SerialMessage.getMessagePayloadByte(SerialMessage.java:332)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAssociationCommandClass.processAssociationReport(ZWaveAssociationCommandClass.java:123)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAssociationCommandClass.handleApplicationCommandRequest(ZWaveAssociationCommandClass.java:99)
at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest(ApplicationCommandMessageClass.java:114)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:232)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:204)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:199)
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1073)
java.lang.ArrayIndexOutOfBoundsException: 6
at org.openhab.binding.zwave.internal.protocol.SerialMessage.getMessagePayloadByte(SerialMessage.java:332)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAssociationCommandClass.processAssociationReport(ZWaveAssociationCommandClass.java:123)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveAssociationCommandClass.handleApplicationCommandRequest(ZWaveAssociationCommandClass.java:99)
at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest(ApplicationCommandMessageClass.java:114)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:232)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:204)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:199)
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1073)
java.lang.ArrayIndexOutOfBoundsException: 8
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveCommandClass.extractValue(ZWaveCommandClass.java:305)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveConfigurationCommandClass.processConfigurationReport(ZWaveConfigurationCommandClass.java:113)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveConfigurationCommandClass.handleApplicationCommandRequest(ZWaveConfigurationCommandClass.java:81)
at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest(ApplicationCommandMessageClass.java:114)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:232)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:204)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:199)
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1073)I have the FTS101 identified alright in my set-up.
Z-Wave Node 26: FGFS101 Flood Sensor
The exceptions indicate some sort of corrupted frame - that’s all I can tell. I’ll add some better handling of exceptions while processing command class frames…
Regarding the ST812, please try tomorrows binding and let’s see if it helps. I have a suspicion that due to startup sequencing, the database might not be 100% complete in all cases and that might be the cause of this issue. If it’s not working tomorrow, then let me know and I’ll take another look.
btw … I tested a bit with readback config.
also after many days and many manual wakeups for none of the devices I tested this habmin ever showed the correct config parameters. I can tell for sure as e.g. the Z110 Dlink does show door open/close by blinking shortly when a specific parameter is set.
habmin did show that parameter was set although it wasn’t.
Thanks, but I really need to see logs, otherwise there’s no way to know what’s going on.
I’ve already explained that ESH works differently to OH1 where I handled this issue better than I can in OH2. For battery devices especially therefore, as explained previously, it won’t really be possible to make them read the same.
Doing a little inclusions today…
It happened twice that the stick did not go back to normal but stayed permanently inclusion.
It keeps blinking forever and also log doesn’t say it stops inclusion.
This additionally seems to affect 1 of 2 zw100 sensors. Also indicating permanent wakeup with a solid green light.
Is it possible to provide the logs please?
had log on INFO.
next time on DEBUG I see this I will send you the log.
if log on INFO makes sense I did a copy of it… let me know .
But the messages about the end of inclusion are all DEBUG messages as far as I can see, so this would explain why you see no log entry when it completes!
I have a Aeotec Z-stick connected to RPi. DMESG gives following output:
[ 1794.288232] usb 1-1.3.2: cp210x converter now attached to ttyUSB1
I installed Z-Wave Serial Connector using PaperUI then searched network but could not find Z-Stick so I added the thing manually using PaperUI. Log reports the following saying that Port ttyUSB1 does not exist.
20:56:34.549 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'zwave:serial_zstick:c0773197' has been added.
20:56:34.812 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:c0773197' changed from UNINITIALIZED to INITIALIZING
20:56:34.913 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:c0773197' changed from INITIALIZING to ONLINE
20:56:34.926 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port 'ttyUSB1'
20:56:35.501 [INFO ] [smarthome.event.ItemAddedEvent ] - Item 'zwave_serial_zstick_c0773197' has been added.
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0
20:56:35.912 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:c0773197' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Serial Error: Port ttyUSB1 does not exist
20:56:36.004 [INFO ] [rthome.event.ItemThingLinkAddedEvent] - Link 'zwave_serial_zstick_c0773197-zwave:serial_zstick:c0773197' has been added.Upon restart this morning, I got the following exception (I think I had it yesterday as well). I guess it might be deliberate and known, but I figure I should report it anyways.
I don’t have any encrypted zwave devices in my system.
07:28:54.176 [ERROR] [mmandclass.ZWaveSecurityCommandClass] - Error parsing zwave:networkKey
java.lang.IllegalArgumentException: Empty key
at javax.crypto.spec.SecretKeySpec.<init>(SecretKeySpec.java:96)[:1.8.0_71]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.setRealNetworkKey(ZWaveSecurityCommandClass.java:1012)[170:org.openhab.binding.zwave:2.0.0.201603190202]
at org.openhab.binding.zwave.handler.ZWaveControllerHandler.initializeNetwork(ZWaveControllerHandler.java:109)[170:org.openhab.binding.zwave:2.0.0.201603190202]
at org.openhab.binding.zwave.handler.ZWaveSerialHandler.initialize(ZWaveSerialHandler.java:96)[170:org.openhab.binding.zwave:2.0.0.201603190202]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7$1.call(ThingManager.java:644)[94:org.eclipse.smarthome.core.thing:0.8.0.201603141848]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7$1.call(ThingManager.java:1)[94:org.eclipse.smarthome.core.thing:0.8.0.201603141848]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:170)[88:org.eclipse.smarthome.core:0.8.0.201603141848]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_74]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_74]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_74]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_74]I have my gen5 z-stick as /dev/ttyACM0. Maybe your distro does not recognize it…
Normally COM ports in linux are in the following format -: /dev/tty/ttyUSB1 :- the last part can change dramatically, but you don’t have the correct format it seems.