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?
Oh, that’s weird. The last time I posted, I was getting motion sensor actuation but not temperature or LUX updates. Since I updated from OH 1.7 to OH 1.8.3, I am getting temperature and Lux but not always motion (although I did see it fleetingly but it went away without me understanding what I did to it). My items config reads as follows (I’m not bothered about Lux which is why it doesn’t appear)
Number TempKitchen “Temp: [%.1f °C]” { zwave=“5:command=sensor_multilevel,sensor_type=1” ,refresh_interval=3600"}
Number BatteryKitchen “Battery Motion Sensor: [%d %%]” { zwave=“5:command=BATTERY”,refresh_interval=86400" }
Contact Kitchen “Motion [%s]” {zwave=“5:command=sensor_binary”}
I have tried the motion as a contact type and a switch type (and I got updates from each, with OPEN/CLOSED when it was a contact and ON/OFF when it was a switch [until it stopped doing anything] and I have tried command=sensor_binary and command= BASIC.
I have config parameter 8 as ‘PIR sensor always active’
Can anyone suggest what I’ve messed up on?
Many thanks
Tim
No, compared to my working config:
Number FibEye1_Lux "Lux MotSens: [%.2f Lux]" { zwave="3:command=sensor_multilevel,sensor_type=3" }
Number FibEye1_Temp "Temp MotSens: [%.1f °C]" { zwave="3:command=sensor_multilevel,sensor_type=1" }
Contact FibEye1_Motion_C "Motion Hallway up [%s]" { zwave="3:command=sensor_binary"}
Number FibEye1_Battery "Motion Sensor: [%d %%]" { zwave="3:command=BATTERY" }
I managed to make some progress by excluding the sensor from the z-wave controller and then including it again. It seemed happier second time around (for example, more of the configuration parameters were automatically populated). However, it is still not as I expect and wondered if anyone could give me some further insight.
Aside: I am observing that the motion sensor uses the ALARM command class (which, reading the forums is not uncommon). If my items file uses the BASIC command class or the sensor_binary command class, nothing is reported in the openhab console.
If I configure the item as a switch, it will report OFF and if I configure the item as a Contact it will report CLOSED (as expected) but it only ever reports OFF/CLOSED and not ON/OPEN. My previous motion sensors have been the Everspring SP103 which reported ON when motion was first detected, then further ON’s if the movement continued, followed by an OFF when motion ceased. But the FGMS seems to be reporting OFF/CLOSED when motion is first detected, further OFF/CLOSED if motion continues and (I think) a final OFF/CLOSED when motion has ceased. I find it hard to believe that this is as intended.
Any ideas?
Do you have the following configuration parameters set?
…but, as I think I said in my post, I don’t get anything on the BASIC command class - motion sensors actuations seem to come in on the ALARM command class.
Quite honestly I have no idea what’s wrong then, this was working fine on my setup before I migrated to OH2 and I don’t think there have been changes to OH1 FGMS-001 since then. And since the item in question was set for me as…
Contact HR_MS_Motion "Motion Detected [%s]" {zwave="4:command=sensor_binary"}
… It might be a fault with your device. The only difference in setup is I left all to default. It appears you have set everything to the most extreme sensitivity, which isn’t recommended in the manual.
Yeah, it’s a teaser. I have seen some mention that the very latest FGMS sensors behave differently to the previous batch. I have two (which I would like to think rules out a faulty one) and I only just bought them, so I think they are pretty recent. I know I have gone to a non-recommended sensitivity (just trying things to be honest) and will revert. Thanks for taking the time to respond anyway.
When running OH 1.8.3 in debug, I only receive ALARM messages and only ever with value of 0
Ah, hold on, I think I may have been guilty of an ID-ten-T error (for the uninitiated ID10T)
I downloaded http://manuals.fibaro.com/content/manuals/en/FGMS-001/FGMS-001-EN-T-v2.0.pdf and saw this
The Motion Sensor provides the association of four groups:
1st association group – “Lifeline” reports the device status and allows
for assigning single device only (main controller by default).
2nd association group – “Motion” is assigned to the motion sensor
- sends motion detection and alarm cancellation frames to the associated
devices.
3rd association group – “Tamper” is assigned to the tamper - sends
tamper alarm and alarm cancellation frames to the associated devices.
4th association group – “Motion BC” is assigned to the motion sensor - sends motion detection and alarm cancellation frames to the
associated devices. Provides backward compatibility with controllers
not supporting Z-Wave+ protocol.
5th association group – “Tamper BC” is assigned to the tamper -
sends tamper alarm and alarm cancellation frames to the associated
devices. Provides backward compatibility with controllers not supporting
Z-Wave+ protocol.
- BASIC command class configuration
This parameter determines the command frames sent to 2nd association group (assigned to PIR sensor).
I don’t know whether I rushed it before or just wasn’t concentrating or whether the config was just not read correctly but I’d never spotted the multiple association groups before. I had linked association group 1 with node 1 and this meant that some info (but not all info) was passed to the controller.
Once I put node 1 into the Motion (DUR) association group, BASIC command class messages started to come through and they did have both ON and OFF. I am still seeing two ONs and two OFFs so will continue to investigate.
Hope I haven’t buggered up temperature now
Sorry to have wasted everyone’s time and hope this update helps someone following.
1 Like
Yepp, it does. The older FGMS001 (mine is firmware version 2.6) have only three association groups …
I know it’s a little bit old topic but I’m having issues getting any data from this sensor.
Even trying to remove from the coordinator fails.
See log
2018-01-25 07:49:28.636 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: listening == false, frequentlyListening == false, awake == false
2018-01-25 07:49:28.638 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Node not awake!
2018-01-25 07:49:28.640 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: listening == false, frequentlyListening == false, awake == false
2018-01-25 07:49:28.642 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Node not awake!
2018-01-25 07:49:28.644 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: listening == false, frequentlyListening == false, awake == false
2018-01-25 07:49:28.647 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Node not awake!
2018-01-25 07:49:28.649 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: listening == false, frequentlyListening == false, awake == false
2018-01-25 07:49:28.651 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Node not awake!
2018-01-25 07:49:28.653 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: listening == false, frequentlyListening == false, awake == false
2018-01-25 07:49:28.655 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Node not awake!
2018-01-25 07:49:28.657 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 6: listening == false, frequentlyListening == false, awake == false
2018-01-25 07:49:28.659 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 6: Node not awake!
2018-01-25 07:49:28.668 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 06 00 61 06 01 24 BB
2018-01-25 07:49:28.673 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 3010: Transaction Start type RemoveFailedNodeID
2018-01-25 07:49:28.697 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=RemoveFailedNodeID[97], type=Response[1], dest=255, callback=0, payload=08
2018-01-25 07:49:28.700 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=RemoveFailedNodeID[97], type=Response[1], dest=255, callback=0, payload=08
2018-01-25 07:49:28.715 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=RemoveFailedNodeID[97], type=Response[1], dest=255, callback=0, payload=08
2018-01-25 07:49:28.721 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=RemoveFailedNodeID[97], type=Response[1], dest=255, callback=0, payload=08
2018-01-25 07:49:28.724 [DEBUG] [message.RemoveFailedNodeMessageClass] - Got RemoveFailedNode response.
2018-01-25 07:49:28.725 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 6: Remove failed node failed as node not found
2018-01-25 07:49:28.759 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:80c3afd9:node6’ has been updated.
Anything I can do?
Thanks