My new sensors are recognized, but it seems that no messages are received from them. I enabled TRACE logging for z-wave binding and I do not see any messages from that nodes. Do you think it could be hardware compatibility issue? I’m using UZB1 USB stick. Can I check anything else?
Thank you.
No - this is unlikely.
I would suspect that either hte associations aren’t set, and/or the sensors aren’t enabled. Check that association group 3 is configured to report to the controller, and also that the various sensors are enabled since I think they are disabled by default other than motion.
Hi,
I also have a Fibaro FGMS-001 with a RaZberry and it shows up with status green (Node 2) in minHab.
Just for a test purpose I would like to read out the temperature.
This is my item configuration:
Number Temp "Temperature: [%.1f °C]" <temperature> { zwave="2:command=sensor_multilevel,sensor_type=1" }
Unfortunately I get these errors in the log when I try to read out the data on my sitemap:
2016-04-17 19:40:21.679 [INFO ] [rialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2016-04-17 19:40:21.682 [INFO ] [rialApiGetInitDataMessageClass] - # Nodes = 2
2016-04-17 19:40:21.685 [INFO ] [rialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
2016-04-17 19:41:19.389 [WARN ] [.o.b.z.i.p.c.ZWaveCommandClass] - NODE 2: Unsupported command class MULTI_INSTANCE_ASSOCIATION
2016-04-17 19:44:28.867 [ERROR] [ZWaveMultiInstanceCommandClass] - NODE 2: Endpoint 2 not found. Cannot set command classes.
2016-04-17 19:44:29.435 [ERROR] [ZWaveMultiInstanceCommandClass] - NODE 2: Endpoint 1 not found. Cannot set command classes.
2016-04-17 19:44:59.936 [ERROR] [ZWaveMultiInstanceCommandClass] - NODE 2: Endpoint 1 not found. Cannot set command classes.
2016-04-17 20:10:47.914 [ERROR] [.s.container.ContainerResponse] - The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NullPointerException: null
at org.openhab.binding.zwave.internal.config.ZWaveConfiguration.getConfiguration(ZWaveConfiguration.java:127)
ZWave binding is version 1.8.2
What is missing here?
I use this:
{ zwave="11:0:command=sensor_multilevel,sensor_type=1" }
So, I think you are missing the zero.
Hi, did any of you guys find a good way of getting those values from the FGMS-001?
I have a version 4, with the controller (Z-stick gen 5 Aotec) associated in group 3.
On movement detection the logs shows a incoming z-wave message with class ALARM and type GENERIC with value = 0. No problems binding to that, but the problem is that after 30 secs without movement another identical message shows up to “cancel” that state, setting the value (once more) to 0. So… It’s impossible to find out when there is movement or not as all values are 0.
Tamper alerts are communicated the same way. Here is a couple of examples, first a activation of a movement alarm:
2016-04-24 22:08:53.496 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 21 09 71 05 00 00 00 FF 07 08 00
Then a deactivation of the previous alarm (after my configured 30 secs):
2016-04-24 22:09:24.248 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 21 0A 71 05 00 00 00 FF 07 00 01 08
And then the last case of tamper alarm, also communicated as the ALARM class:
2016-04-24 20:42:50.231 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 21 09 71 05 00 00 00 FF 07 03 00
The last one there is bound with a sensor_alarm type, which works ok. But again, the different alarms are impossible to differentiate. I’ve tried using other association groups as well with no luck.
As an addition, I guess the interesting stuff lies in the last three/four bytes there, but I dunno how to reach those values… I could ofcourse “hack” it, but to do it properly I guess there needs to be made some config mappings for these non-standard Fibaro implementations…
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" }
These are my configuration parameters:
My FGMS001 is only associated to the controller in “Association Groups”>“Device Status” and “Controller updates”
Might help you.
Continuing the discussion from Fibaro FGMS-001 how to get sensor data:
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.
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.
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.
