Yes, mine’s running fine since I installed your Aug12th binding 2 days ago and yes, with holdoff-enabled versions before I got ‘queue full’ after 24hrs at most. What do you mean by ‘merge holdoff’ now - isn’t that already in there ?
At the moment it’s not merged into the development branch - it’s still part of this PR -:
Yes things look very good, no issues performance wise . As for the threads, I went ahead and installed the most recent version with thread naming , there definitely is a pattern with nodes above a certain number getting stuck during the heal phase , just hopped on a plane but as soon as I have a ssh connection I will post another thread dump and log file.
Updating the binding resolved the Scene Number issue with the firmware version 3.5 Fibaro dimmer.
The bit I don’t understand is that the new “thing” (with version 3.5 firmware) always had the “Scene Number” channel even before I installed the updated binding. My expectation would be if this was missing from the database for the version 3.5 firmware then it should be entirely missing as a channel?
Hi.
I’m having a deja vu moment here, need someone (@chris?) to help me remember. I know I’ve had this problem before and discussed it somewhere (might be in this thread thousands of posts up or somewhere completely different).
I’m trying to include some new nodes. When I start the inclusion I just get “Z-Wave network inclusion failed” within seconds and nothing gets included at all. I’ve put a short debug log here but I don’t think it says much useful.
I’m on Debian 8, running a current snapshot (Build #1330) of OH and latest version (2.4.0.201808142206) of this binding.
Here’s a link to my issue that documents it. The channel has always been available, but this firmware did not announce the class so the binding did not use it in mapping items. chris ‘forced’ it to know that class.
Hi, I just noticed a strange thing while using the development zwave binding. I have a bunch of Fibaro dimmers. If I send the command 99 to a dimmer. The light then changes to 100, without me giving any command. The log is as follows:
2018-08-16 20:28:08.821 [ome.event.ItemCommandEvent] - Item 'Hal_Dimmer' received command 99
2018-08-16 20:28:08.840 [vent.ItemStateChangedEvent] - Hal_Dimmer changed from 0 to 99
2018-08-16 20:28:09.884 [vent.ItemStateChangedEvent] - Hal_Dimmer changed from 99 to 100
It seems that this is releated to z-wave. If I send the command 99 to a Hue dimmer, it just changes to 99 and doesn’t change to 100.
ZWave protocol doesn’t have the concept of 100, so to avoid even more confusion, the ZWave binding always sets the value to 100 if you set to 99 - it’s normal.
Hi Chris,
Thanks for the quick reply. That at least explains it. I thought I was going crazy. I will rewrite my rule to accomodate for this.
Other than this, your current binding works great on my 30+ nodes network.
Thanks for your work
1 Like
Hi again. I gave up and just included by just stopping the binding, unplugging the z-stick and using the physical button on it. Included just fine, but now after waiting +12 hours and doing numerous wakeup attempts it still shows as “Unknown Device”. When I push the wake up button I get the following in my log:
2018-08-16 18:36:09.743 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 04 11 06 56 01 84 07 CC 39 C5
2018-08-16 18:36:09.783 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=17, callback=4, payload=04 11 06 56 01 84 07 CC 39
2018-08-16 18:36:09.831 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=17, callback=4, payload=04 11 06 56 01 84 07 CC 39
2018-08-16 18:36:09.854 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=17, callback=4, payload=04 11 06 56 01 84 07 CC 39
2018-08-16 18:36:09.875 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 892: [WAIT_DATA] priority=Controller, requiresResponse=true, callback: 0
2018-08-16 18:36:09.893 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 17: Application Command Request (ALIVE:REQUEST_NIF)
2018-08-16 18:36:09.908 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: Decapsulating COMMAND_CLASS_CRC_16_ENCAP
2018-08-16 18:36:09.922 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: COMMAND_CLASS_CRC_16_ENCAP not found
2018-08-16 18:36:09.936 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
Any idea what it means?
It likely means that the device doesn’t report CRC_16 in the list of command classes in the NIF. What version of the binding are you using? A recent one, or something older? I’d suggest to try with the latest at the top of this thread so we understand what you are using (if you’re not already of course).
Yep, I’m using the one from this thread:
180 │ Active │ 80 │ 2.4.0.201808142206 │ ZWave Binding
1 Like
Ok, thanks. I’ll have a look at this later. I thought that I’d reverted a change that we made a while ago that would have explained this, but maybe not.
1 Like
Hi Chris,
Thank you for your work on this! Here’s my question . . .
Running OH2.3 on Synology with the included zWave binding your built.
Can I run the new zWave 2.4 binding on a OH2.3 install?
I understand the installation procedure you have posted but not sure about the version difference in case there are includes needed from the core of the OH2.4 core or not?
Best, Jay
No issues here after about 4 days. Looking good, thanks!
1 Like
Yes - this should be fine.
Cheers
Chris
So, I did remember correctly, and the general code to add unknown classes was re-added into the binding already… This is a special case that wasn’t handled since it’s an encapsulation class - I’ve just modified the code to make this more consistent and I’ll update the binding at some point later today with this fix.
1 Like
Just to note that the 14 August binding is working perfectly for me - all the previous versions with hold-off had been buggy and locked up after 24 hours or so.
Thank you!
Dan
Thanks Dan. This is now merged into the master development binding.
For me, I think this is the last outstanding issue before merging this into master - if there are significant outstanding issues that people have, please shout.
3 Likes
Did you change anything? Just tried the 2.4.0.201808182253 binding and I still get COMMAND_CLASS_CRC_16_ENCAP not found.