Domoticz

I have the same issue. The "false" alarms can be prevented by by removing the controller from group 1, but then you will also no longer have temperature and illumination reports.... Motion and tamper however keep working.
Hope this can be solved by some experts!

@kman: I have two Domoticz installations: the first one is using the Aeon Stick Gen3 (black color and blue light), the second one is based on the Aeon Stick Gen5 (white color and multicolor light).

On both installation I'm using Domoticz v3.5877 with OZW 1.4-2228-gbce4a88-dirty, IMHO, you have to update Domoticz... but consider that updating Domoticz (and OZW that is embedded) you will probably have to exclude/include again your Gen5 nodes!!
I suffered this experience moving from Domoticz v.3.5837 to v3.5877; after the update I haven't experienced any issue on the installation based on the Gen3 controller, instead I had to exclude/reinclude the Gen5 nodes (one ZD2102 and two FGMS-001) securely included to the network based on the Gen 5 controller (the issue was the controller didn't report contact -on ZD2102- and motion -on FGMS001- status).

You can evaluate to make an image of your microSD card before to update, so if you won't be satisfied after the update you'll be able to come back quickly.

I confirm you that the FGMS001 ZWave+ nodes are associated to the controller on Groups 1, 2 and 5 and they are working properly (on both installation); in spite of Gen 5 controller, I had to associated the Gen5 nodes to the group 5 (tamper backward compatibility group, as you wrote) on the second installation too, because using the group 3 the tamper status wasn't returned (don't ask me why, please!)

About Alarm Level and Alarm Type, they are present in the device list, I've simply ignored them!
I've set and monitored these devices:

xxxx01 Temperature
xxxx03 Lux
xxxx35 Motion Sensor
xxxx28 Tamper

Bye!

Strange: I have the latest beta of Domoticz and even downloaded the latest config file for the Fibaro from OpenZwave.org but only can get the sensor to work with with group 4 and 5. And as said before if I assign group 1 to the controller I get an alarm in the log every time the sensor is triggered.
Without group 1 assigned however, I don't get Lux and temp reports.

Hi Tamagnun,
Sincere thanks for the detailed response.

>> About Alarm Level and Alarm Type, they are present in the device list, I've simply ignored them!
Thanks. But do you receive "Alarm Level" and "Alarm Type" on every Motion Detection?

>>>>> xxxx35 Motion Sensor
- 0xxxx35 in my case is "Burglar" not "Sensor". So just confirming, is this "Burglar" or "Motion Sensor" And this "Motion Sensor" you receive on Group 2? i.e. if you did not include Group 2 you don't see any Motion Detection?
- In my case just including Group 1 alone (i.e. not including Group 2, 3, 4, 5) I see with every motion detected - Burglar gets reported along with Alarm Type and Alarm level.
¬¬¬
2017-01-06 23:21:55.124 (aeon-GEN5-USB) Lighting 2 (Alarm Type)
2017-01-06 23:21:55.129 OpenZWave: Alarm Level: Secure
2017-01-06 23:21:55.129 (aeon-GEN5-USB) Lighting 2 (Alarm Level)
2017-01-06 23:21:55.133 (aeon-GEN5-USB) Lighting 2 (Burglar)
¬¬¬

hi,

my motion is working on 00 , not on 35
but i changed the xml file for the new zwave device and since then it is working on Sensor (00)
seet attachement, you need to change manufacturer_specific.xml also

just be sure you are working with the FGMS-001 from 2016, because this is the Zwave+ device
the other ones are just Zwave and are using other parameters.
the /config/manufacturer_specific.xml is using the 'old' xml file for both devices that is not correct!!

you can see if you have the Zwave device by checking the index (see attachment)
if you have ID: 0x1001
and Type: 0x0801 then it's a Zwave+ device and you need the new xml i changed

but be sure you change also you're /config/manufacturer_specific.xml
mine can be also found in attachment

Hi Ropske,
Thank you - I can confirm zwave + Fibaro Motion with ID: 0x1001 and Type: 0x0801 and I am using the new fgmszw5.xml and modified manufacture_specfic.xml file.

Have you included the groups 1, 2 & 5? ---or ---- 1, 4, 5 ?

Do you see AL, AT and Burglar on every motion detection?

thanks.

hi kman,
i just tested this with a motion and those are the indexes that have changed:

33 :alarm type
32 :alarm level
00 :sensor
35 :burglar

mine are grouped to 1(lifeline) /2(motion) / 4(motion(bc))

i don't know what the alarm type and alarm level are actually and what they mean, i just ignore them for the moment
i cant find anything about them for now

my motion & temperature & lux are working, so i'm happy

ropske wrote:hi kman,
i just tested this with a motion and those are the indexes that have changed:

33 :alarm type
32 :alarm level
00 :sensor
35 :burglar

mine are grouped to 1(lifeline) /2(motion) / 4(motion(bc))

That is exactly what I have as well, which happens already when you assign the lifeline to the controller.
The probleem with that is, that with each motion you will also get a "Secure alarm level" in the log as well (I even don't know what that means).
If you only use group 4 and 5, motion and tamper work as expected but you lose temp and Lux.

I wonder if some of the experts can tell I this can be solved by changing the OpenZwave configs, or that this is a bug in the source of Domoticz?

(adding to Bikey's comments)

@ropske - Thanks for the details. Some quick questions:

1. Are you using "Aeon Zstick Gen5 USB"?

2. Assuming it is yes to the above question. Please confirm with just "Group 1 & Group 2" -- and NOT Group 4, so please after removing GROUP 4 can you confirm if you receive "00:Sensor" when motion is detected?

thanks again.

@kman: I confirm you that Alarm Type (id 0000xx33) and Alarm Level (id 0000xx32) are updated also (simply I have ignored them) when motion detected at the same time of Burglar (id 0000xx35), I have renamed it and I use it to monitor the motion, sorry but I hadn't understood you're talking about the Sensor (id 0000xx00) device.
I will try, but I'm confident you're right: it's required to associated the Group 4 (motion bc) to have Sensor device reporting the motion status.

Summarizing:

Group 1: reports temperature, lux, alarm type, alarm level, burglar (I think this device is update for motion AND tampering, isn't it?)
Group 2: officially is for MOTION ZW+, but useless in Domoticz/OZW
Group 3: officially is for TAMPER ZW+, but useless in Domoticz/OZW
Group 4: reports motion on Sensor device (0000xx00)
Group 5: reports tamper of Tamper device (0000xx28)

Finally, best association is Group 1, 4 and 5, AT, AL and Burglar have to be ignored (or Group 1 can be left unassociated, losing temperature and lux reports, not good for me).

Are the guys agreeing with this summary?

Sensor device is labelled as Unknow with Gen3 controller (I don't remember if Burglar and Tamper too, I have renamed them and I prefer to avoid to exclude/include again the node), whilst AT and AL are properly labelled.
All labels are correct with Gen5 controller.

IMHO, OZW supports many Gen5 devices, but something is not fully managed, so the group 2 and 3 are useless with OZW... but I'm too ignorant and I can be wrong!

[UPDATE]
Test completed (with Gen3 controller, the network based on Gen5 controller is 60km far -parent's house-, I'll check on Thursday): with the association to Group 1, 4 e 5 it is possible to read temperature, lux, AT, AL e Burglar (device xx35, it returns tamper or motion update, without distinction), Sensor (device xx00) and Tamper (xx28).

Sensor is better than than Burglar because returns ONLY the motion sensor status, it is not affected by the tamper signal.

Thank you kman, without your detailed request I'll have probably continued to use the burglar as motion sensor... in addition, with FGMS0001 Gen3 (older) the motion status is logged on device xx00, so now both (Gen3 and Gen5 nodes) are working in the same way.

[UPDATE II]
AT and AL log every motion/tamper update as OFF, Burglar goes ON and after 30 sec (default setting) returns to OFF.
IMHO, AT and AL in ZW+ specifications are not ON/OFF devices but they return discrete values that wolud require to be managed...

@Tamagnun: your results match up exactly with mine.
If group 1 is associated with the controller AT and AL and Burglar (xx35) are triggered with every motion/tamper update, resulting in "OFF" signals only.

"General" (xx28) goes on ON after a Tamper, the return to Off can be controlled by the parameter "22. Tamper - alarm cancellation delay: (seconds)".

If only we could get rid of the Alarm Level and Alarm Type triggers and the resulting "OpenZWave: Alarm Level: Secure" messages in the log, it would be Ok.

Again, I hope that this can perhaps be solved by the code in Domoticz that handles the AL/AT triggers? (@Gizmocuz, are you reading this?).

@Tamagnun: thank you so much for the confirmation - yes indeed your summary matches mine.

It's nice to have this confirmation - at least we know now, that irrespective of Domoticz & OZW version - that the issues with Fibaro Motion V3.2 are reproducible/consistent.

The concern is the confidence in using Fibaro Motion v3.2 with Aeon_ZStick_GEN5_USB - and it's compatibility with OZW. Nothing to say, there couldn't be other issues - within this forum there many other issues reported against Fibaro Motion v3.2 - such as continuously On, or abruptly stopping to detect motion after a few days.

Question is how to progress from here(which you can't till you know where the problem is):
- why does the Burglar get triggered with every motion? ( -- Or can someone confirm if that is by design?)
- No motion detected in Group2 inspite of using a GEN5 controller ( --@Tamagnun: will nice to have your confirmation following your visit on Thursday. Thanks. ) --- would be good to know if anyone has tried with any other GEN5 controllers? ---- this may rule out any fw issues with Aeon-Gen5-USB (but it shouldn't the whole idea of Zwave Plus Certification, means they must be compatible!)
- Simultaneous triggering of AL, AT, Burglar with every motion detection --- these additional 3 events for every motion is quite serious as it hogs up air bandwidth, potentially can lead to missed motion events 255 or 0, especially when there is a multi-person movement around a property.

Theoretically speaking -- issues could exist in Controller, Motion Sensor or OZW; with Controller & Motion Sensor being Zwave Plus Certified, and, our ability to act on this being only within OZW - it may be nice if we could have this raised within OZW forum. But Of course as Bikey suggests, any help Gizmocuz could provide will be very helpful!

¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬

While these issues with Fibaro Motion v3.2 get addressed - I am looking forward to purchase some other Multisensor (motion, temp, lux) which works well with Aeon-Zstick-Gen5-USB - any suggestions?

Tamagnun wrote:@kman: I confirm you that Alarm Type (id 0000xx33) and Alarm Level (id 0000xx32) are updated also (simply I have ignored them) when motion detected at the same time of Burglar (id 0000xx35), I have renamed it and I use it to monitor the motion, sorry but I hadn't understood you're talking about the Sensor (id 0000xx00) device.
I will try, but I'm confident you're right: it's required to associated the Group 4 (motion bc) to have Sensor device reporting the motion status.

Summarizing:

Group 1: reports temperature, lux, alarm type, alarm level, burglar (I think this device is update for motion AND tampering, isn't it?)
Group 2: officially is for MOTION ZW+, but useless in Domoticz/OZW
Group 3: officially is for TAMPER ZW+, but useless in Domoticz/OZW
Group 4: reports motion on Sensor device (0000xx00)
Group 5: reports tamper of Tamper device (0000xx28)

Finally, best association is Group 1, 4 and 5, AT, AL and Burglar have to be ignored (or Group 1 can be left unassociated, losing temperature and lux reports, not good for me).

Are the guys agreeing with this summary?

Sensor device is labelled as Unknow with Gen3 controller (I don't remember if Burglar and Tamper too, I have renamed them and I prefer to avoid to exclude/include again the node), whilst AT and AL are properly labelled.
All labels are correct with Gen5 controller.

IMHO, OZW supports many Gen5 devices, but something is not fully managed, so the group 2 and 3 are useless with OZW... but I'm too ignorant and I can be wrong!

[UPDATE]
Test completed (with Gen3 controller, the network based on Gen5 controller is 60km far -parent's house-, I'll check on Thursday): with the association to Group 1, 4 e 5 it is possible to read temperature, lux, AT, AL e Burglar (device xx35, it returns tamper or motion update, without distinction), Sensor (device xx00) and Tamper (xx28).

Sensor is better than than Burglar because returns ONLY the motion sensor status, it is not affected by the tamper signal.

Thank you kman, without your detailed request I'll have probably continued to use the burglar as motion sensor... in addition, with FGMS0001 Gen3 (older) the motion status is logged on device xx00, so now both (Gen3 and Gen5 nodes) are working in the same way.

[UPDATE II]
AT and AL log every motion/tamper update as OFF, Burglar goes ON and after 30 sec (default setting) returns to OFF.
IMHO, AT and AL in ZW+ specifications are not ON/OFF devices but they return discrete values that wolud require to be managed...

Code: Select all

Nome: Alarm Level
2017-01-07 21:25:15	Off
2017-01-07 21:22:36	Off
2017-01-07 21:22:06	Off
2017-01-07 21:20:49	Off
2017-01-07 21:20:13	Off
2017-01-07 21:19:44	Off
2017-01-07 21:19:43	Off
2017-01-07 21:19:43	Off
2017-01-07 21:15:36	Off
2017-01-07 21:15:36	Off
2017-01-07 21:15:35	Off
2017-01-07 21:15:06	Off
2017-01-07 21:06:53	Off
2017-01-07 21:06:53	Off
2017-01-07 21:06:23	Off

Code: Select all

Nome: Burglar
2017-01-07 21:20:13	Off
2017-01-07 21:19:44	On
2017-01-07 21:20:13	Off
2017-01-07 21:19:44	On
2017-01-07 21:15:35	Off
2017-01-07 21:15:06	On

Hi Tamagnun,
Any luck with trying with GEN5 controller? i.e. by only including the controller "only" to Group 2, do you see any Sensor value?

thanks.

Bikey wrote:I have the same issue. The "false" alarms can be prevented by by removing the controller from group 1, but then you will also no longer have temperature and illumination reports.... Motion and tamper however keep working.
Hope this can be solved by some experts!

Hi Bikey,
What's your version of domoticz and OZW?

thanks.

Of the two issues:
Issue 1. AL,AT, B - reporting at the same time as that of motion
Issue 2. No motion reported under Group2 with GEN5 controller.
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬

I have made some progress on this issue w.r.t issue 2 .

See if you can also see this:-
1. Have the controller included only to group 2. No other groups included.
2. have debug logs enabled.
3. Now on motion, you will see the OZW_log.txt reporting motion against fibaro motion node, but the domoticz does not show any motion.

It looks more like domoticz needs a correction. So, in this sense, it will be interesting to know if Tamagnun, also sees this issue, as he is already on v3.5877 (latest domoticz version.)


FYI: I have used the config from "https://github.com/OpenZWave/open-zwave" download the zip of master. Then under ../open-zwave-master/config/fibaro/fgmszw5.xml

kman wrote:

Bikey wrote:I have the same issue. The "false" alarms can be prevented by by removing the controller from group 1, but then you will also no longer have temperature and illumination reports.... Motion and tamper however keep working.
Hope this can be solved by some experts!

Hi Bikey,
What's your version of domoticz and OZW?

thanks.

Hi, I have Domoticz version: 3.6304 with OpenZwave Version: 1.4-2279-g7c8c27d-dirty.

I have also downloaded and used the latest beta-sources (openzwave-1.4.2320) from OpenZWave.org, which already includes the configuration file for the FGMS-0001 Gen5 (Device 0x1001 and Type 0x0801) motion sensor.

I'm using this in combination with a Zwave.me GEN5 USB stick.

I'm not so much interested in getting the motion reported in Group 2 as it already works with Group 4 (although unexplainably), but really would like the sensor to work fully with Temp and Lux reporting (so without removing it from the life line Group 1) without the Alarm Level reports in the log.