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.
Are you using the same setup and version as @federic ?
Sorry - I missed this thread…
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.
1 Like
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!
I posted my logs into the other thread: Need help with Fibarro multisensor FGBS 001
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.
That would be very much appreciated! I just wrote a few lines and fixed it temporarily.
Awesome. Thanks for the reply @Chris.
@kenavn: Can you share your fix/hack? I’d love to implement.
I’m looking forward to OH2. When are y’all roughly hoping to ship?
Of course, I’d be happy to. Do you want the jar or the few lines of source code? Let me know, and I will send it over later today.
If you’d like to send both, that would be awesome. I’m curious how you made the change.
Hi Kenneth,
Can you share the jar?
I’ve got 4 FGMS-001 motion detectors (and OH1) and would love to have them working properly.
Casper
seems to be a private conversation: I get “Sorry, you don’t have access to that topic!”
Hi,
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.
Have fun with your Fibaro-eyeballs
1 Like
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…
I have the same issue with the new versions of the FGMS001. I have two older ones that work perfectly but the new one I just cannot get feedback from binary sensor (PIR). The LUX, TEMP and BATERY info works fine only the PIR is not seems to be working. I only got the LUX, TEMP and Batery to work when I added NODE1 to the Device Status group. I did not have to do that with the older models.
Below Info of the New Sensor:
Below of the OLD Sensors:
I have tried the “hacked” zwave binding but did not seems to solve the issue. Let me know if I can help in providing logfiles and compare the two devices.
Hi,
I am facing issue that my sensor FGMS 001 not updating battery correctly, i changed battery to some old battery but also i tried some battery with diferent voltage level but for all cases i am getting 100% as battery level.
Anybody faced this issue…?
Please can anyone have guesses for this…?
Thanks,
shrikant
The Fibaro battery sensors seem to be a little tricky with their battery leveling, I’ve had them stay at 100% for more than a year until they completely drained out, when that happened it went from 100% to 90% in two weeks and then stopped responding. Symptoms of low battery the week before it shut down included incorrect light readings and false triggering.
To avoid this, I now raise a warning:
rule "Battery Warning"
when
Item Motion_Battery changed
then
if (Motion_Battery.state <= 95) {
Change_Battery_Light.sendCommand(ON)
}
end
This is after testing a specific battery, of which I have a store load of, so your mileage may vary.
1 Like
Slight variation on the theme - I get two x ON and two x OFF bus events for a single motion actuation on this sensor. Seems a bit of a waste of battery. Can I suppress this?