I use that motion sensor with Contact FibEye1_Motion_C "Motion [%s]" { zwave="3:command=sensor_binary" }
and it’s working fine.
State of contact opens when movement is detected and closes when config parameter 6 “Motion Alarm Cancellation Delay” has passed by (default is 30 seconds).
I don’t use the tamper alarm, but the other sensors are working fine with:
Number FibEye1_Lux "Lux: [%.2f Lux]" { zwave="3:command=sensor_multilevel,sensor_type=3" }
Number FibEye1_Temp "Temp: [%.1f °C]" { zwave="3:command=sensor_multilevel,sensor_type=1" }
Number FibEye1_Battery "Battery Motion Sensor: [%d %%]" { zwave="3:command=BATTERY" }
I’m also experiencing this exact problem with a new model Fibaro sensor. I believe it’s this newly updated model that is having a problem with the binding because so many of the forum posters have it working properly without having to do any hacks. I spent about 8 hours debugging this!
I think you are right, @anxman - I have also spent hours on this and found that the messages are non-standard and not parsed right in OH. There are custom bytes in the last parts of the messages that need to be mapped into a value if the binding is to work with this version of the unit.
I think @chris is aware of the problem with customised parsers for these “creative” messages from Fibaro, as there is already one class in the source code reflecting custom implementations for a Fibaro product…
The best solution would possibly be to extend the configuration system to be able to map in custom bytes in the messages. I could absolutely contribute with the code for this, but I have just started fiddling with OH, so it would possibly take a few days to “get up to speed”… Any thoughts, @chris ?
Edit: on second thought; all versions this far shows “4”. If it’s not possible to differentiate on unit version, then the mapping to a custom byte must be done in the item definition string, and not in config… I guess…
Thanks - that is nearly the same setup as I am using. But I don’t know the relevance of “application version, protocol version”. And mine has the class “GARAGE_DOOR” or something like that, I do not remember right now. I guess I will try out re-adding in the association group 1 later on today, and see what happens. Thanks.
No - this won’t help - the root endpoint is the default.
Just a minor note that this can cause problems - I would suggest just using the controller update (group 3) group. If you put it in two groups, I’m pretty sure you will get two messages. While this isn’t a problem, it can upset some people…
Please can you provide a logfile so I can see what the problem is?
Hmmm - I’m not sure about that. The command classes should be compliant in order to get zwave certification. I know not all devices are perfect, but I’ve never found the need to have to map custom bytes into a message. I would not be keen to see hacks like this in the code.
Maybe when you talk about ‘creative messages from Fibaro’ you mean their custom command classes - this is a different story of course, but the normal sensor command class should not be broken.
Don’t worry about this - it’s just a name and it needs to be corrected, but it doesn’t make any difference.
It looks like this is simply a command class version issue. We are currently in the process of updating the event command class in OH2 to support the new notifications.
Thanks, Yes I mean the custom command classes, and yes I totally see your point in avoiding dirty hacks in the code. I still think I will have to make a shortcut on this one though, either hack-wise or a more classy version to defend my investment in these 3 Fibaro eyeballs Just until OH2 goes stable. Thanks again!
It’s definitely not a item change to CONTACT nor is it an endpoint issue. I’ve tried every permutation. Also, I’ve adjusted every configuration imaginable so it’s not those either (and unpaired, repaired with OH, etc etc). I’m having the same issue as kenavn.
Yeah, I’m happy to help contribute code to fix this. I don’t have a lot of experience in custom code for OH but if someone can walk me through it, I’m happy to start experimenting.
Once this is resolved in OH2, I’ll look to backport this to OH1. The problem is that the whole concept changed in the way this command class works - it’s no longer just an alarm class, it’s now a ‘notification’ class sow we’ll need to look at how that links in to OH1 concepts.
You can download the jar from here. Just replace the standard zwave jar in the addons folder with this one.
The modified class can be found here. It is just a hack. What it does is that it checks for the case general alarm, value 0, and the correct fibaro node type. If all matches it extracts a new value, offset + 6 or 7. From the raw message, that seems to be a valid discriminator.
The result is that these device versions return an alarm with the value 8 on activation. And then 0 on deactivation. I have other older devices of the same type, and those run through the normal happy-path returning normal values.
Be aware that Fibaro uses a lot of different device IDs, so you may have to debug and change the values in the source code if the jar does not do its job…
Just until OH2 goes stable. Thanks again!