The only channel I have available is ‘dimmer’. Which is what I am binding the item to.
That is fine. Due to type inheritance, you can send it an OnOff type, or a dimmer type and it will act accordingly.
Yep, that is how it worked before I upgraded to OH2. Ever since it will not Dim only turn on and off. If I set the dimmer to 1% then the fan runs at 100%.
So, this is an issue.
Please provide the debug log showing the problem so I can take a look.
I think I’ve hit another problem that looks to have been added in a recent version of the binding (sorry I can’t be sure which version). I am currently using 2.3.0.201804022210, and I saw the problem with at least the previous version.
I have several Fibaro FGS-212 relays, however for latest one I included I am unable to link any items to it. All the ones I included previously are working well.
Whenever I switch the S1 input I get the following in the following in the log. The device, a fan in this case works as expected.
09-Apr-2018 21:24:51.483 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 86: resetResendCount initComplete=true isDead=false
09-Apr-2018 21:24:51.483 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 86: Incoming command class COMMAND_CLASS_MULTI_CHANNEL, endpoint 0
09-Apr-2018 21:24:51.483 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 86: SECURITY not supported
09-Apr-2018 21:24:51.483 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Received COMMAND_CLASS_MULTI_CHANNEL V2 MULTI_CHANNEL_CAPABILITY_REPORT
09-Apr-2018 21:24:51.483 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Process Multi-channel capability Report
09-Apr-2018 21:24:51.483 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoints are the same device class = true
09-Apr-2018 21:24:51.483 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoint Id = 1
09-Apr-2018 21:24:51.483 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoints is dynamic = false
09-Apr-2018 21:24:51.483 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Basic = BASIC_TYPE_ROUTING_SLAVE 0x4
09-Apr-2018 21:24:51.483 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Generic = GENERIC_TYPE_SWITCH_BINARY 0x10
09-Apr-2018 21:24:51.483 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Specific = SPECIFIC_TYPE_POWER_SWITCH_BINARY 0x1
09-Apr-2018 21:24:51.484 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Command class COMMAND_CLASS_BASIC, endpoint 1 created
09-Apr-2018 21:24:51.484 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Unknown command class 0x1
09-Apr-2018 21:24:51.484 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Creating new instance of command class COMMAND_CLASS_SWITCH_BINARY
09-Apr-2018 21:24:51.484 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Command class COMMAND_CLASS_SWITCH_BINARY, endpoint 1 created
09-Apr-2018 21:24:51.484 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoint 1: Adding command class COMMAND_CLASS_SWITCH_BINARY.
09-Apr-2018 21:24:51.484 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Version = 1, version set. Enabling extra functionality.
09-Apr-2018 21:24:51.484 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoint Id = 2
09-Apr-2018 21:24:51.484 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoints is dynamic = false
09-Apr-2018 21:24:51.484 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Basic = BASIC_TYPE_ROUTING_SLAVE 0x4
09-Apr-2018 21:24:51.484 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Generic = GENERIC_TYPE_SWITCH_BINARY 0x10
09-Apr-2018 21:24:51.484 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Specific = SPECIFIC_TYPE_POWER_SWITCH_BINARY 0x1
09-Apr-2018 21:24:51.484 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Command class COMMAND_CLASS_BASIC, endpoint 2 created
09-Apr-2018 21:24:51.484 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Unknown command class 0x1
09-Apr-2018 21:24:51.485 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Creating new instance of command class COMMAND_CLASS_SWITCH_BINARY
09-Apr-2018 21:24:51.485 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Command class COMMAND_CLASS_SWITCH_BINARY, endpoint 2 created
09-Apr-2018 21:24:51.485 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoint 2: Adding command class COMMAND_CLASS_SWITCH_BINARY.
09-Apr-2018 21:24:51.485 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 86: Version = 1, version set. Enabling extra functionality.
09-Apr-2018 21:24:51.485 [ERROR] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 86: Endpoint 3 not found. Cannot set command classes.
I am also seeing this with a Fibaro FGS-221.
Thanks,
Steve.
My BE468 doesn’t have an alarm_raw channel on it. Is that something that can be added somehow or does the lock just not have it? (which would be a huge bummer) As luck would have it, I scored an open box BE469 at the hardware store last week for like 1/2 off! So, I can’t wait to try out your suggestion. Thanks!
Yes, I believe the BE468 would support it, but the database has just not been updated to include that channel. It would probably be best for someone to configure it’s channels to be similar to the BE469. The only difference I am aware of between the BE468 and BE469 is that the BE468 does not have the Alert, Tamper, and Forced Entry alarms.
OK, I created an account on cd-jackson.com and put in a ticket for access to modify the device database and I read through the Database Guide some. Assuming I get access and update the device online, how do get OH2 to update it locally?
Alternatively, is it possible to drop this XML file somewhere on the file system, modify it, and have it override the online data?
Thanks!
I’ve updated your access…
You need to update to the latest binding once the updates are approved and migrated into the binding. If you’re running the snapshot runtime, then just uninstall and re-install the binding using PaperUI.
Your updates would likely be included in the next build of the binding.
That is the XML for this device that is found inside the binding. The binding needs to be updated with this file, which will include the new channel. I had some time tonight and updated your device in the database, but @chris will need to approve this change since it will require people currently using this device to change their setups. The database is exported and merged into master and the development branch almost weekly, but if you buy Chris a pint (scroll to the bottom) it might get done sooner. 
1 Like
Following up on Fibaro Relay hiccup I am seeing. I’ve now had chance to check the behaviour of a device which was included a while ago (an FGS-222) and it seems to be doing the same thing with respect to the Unknown command class 0x1 etc mentioned earlier.
Does anybody have any suggestions on what to check / information required next?
Thanks,
Steve.
@ Chris: I have completely reinstalled my Raspberry 3 and then added your zwave secure binding. Unfortunately, the problem still exists. Any plans to solve this issue in the next time?
I need your z-wave binding with security.
I’ve had this same issue. Not sure when it started, but if I make my changes and then click “Show Less”, I can then save. This also saves the changes I made. See if that works for you.
Yes, it’s happening for me too: can’t save. I’ve been using HABmin to save changes as a workaround.
Awesome! Thanks Scott!
One thing I’ve noticed, at least with the aeotec z-stick series 5 that I’ve got, is that trying to exclude these locks (by entering the digits) from HABmin exclusion mode with the stick plugged in doesn’t seem to work. I’ve found that unplugging the z-stick, taking it to the lock then excluding it with the button to work reliably. It also took me quite a while to understand that you have to do the inclusion via PaperUI in order for security to work. Do you think it would be appropriate to put something about this in the inclusion/exclusion section of the device pages?
I have not had issues with doing inclusion and exclusion through Habmin, and even did some (non-secure) inclusions a few days ago. I rarely touch PaperUI unless I want to copy/paste the Channel information into an .items file. It’s my understanding that PaperUI and Habmin both start discovery by calling the REST API. There’s always a chance there’s a bug, but I’m doubtful.
Please note that HABmin is not a workaround but the recommended way to configure zwave devices.
Where is the advantage of using Habmin instead of PaperUI when configuring Zwave devices? And why is this the case?
And do I have the newest zwave binding if I installed the snapshot version of openhab? Or do I need to install the jar from the first post?
It’s VERY hard to try and track issues in this thread - please open an issue and I’ll take a look.
1 Like
The big issue I have with PaperUI is it will send ALL configuration when you update anything. Since the binding doesn’t know if you want to only send updates, or if you want to send any specific parameter, it sends everything. This means it generates a lot of parameters.