Domoticz

tried it with group 1,2, and 3
secure message still there, only motion sensor, temp and lux working.

The mapping is done in the config file.

domoticz does a discovery on a node which reports the capabilities of that device.
this info is put into the zwcfg_xxxx.xml file

When you have a correct config file domiticz does a combination of what is in the config file and what capabilities are reported. this combined data is put into the zwcfg_xxxx.xml file.

you can check this behaviour and will seee there is a lot more info in the zwcfg_xxxx.xml file than that there is in the config file.

sometimes however things go wrong, capabilities are reported which do not work or capabilities in the configfiles are wrong.

The config file overrules the capabilities which are discovered.
so when discovery goes wrong you need to correct this in the config device file.
mapping commandclasses to other classes is such a thing as well as mapping endpoints.
i do not have enough knowledgde to do this mapping.

i believe the fibaro modules work 100% but openzwave can not cope with some of the functionality because they are made for the fibaro controller

recarding the secure message, my module is not included secure so this has nothing to do with it.

Bikey wrote:

Gravityz wrote:ok i understand.
update" tried mapping 48 but that made no difference but i believe this is the key to solving this"
i will do a second test with group 1,2,3 to see what happens in my situation

Interesting! Where is this re-mapping done, is that in the OZW-part or in Domoticz?
Perhaps that could also be used to read the "binary report" as is used by the new sensors instead of the "Basic Command Class" as used by the old sensor.

Di you already do a test with group 1,2,3, and if things are working do you no longer have the "alarm level secure" messages in the log?

dutchdevil83 wrote: The "alarm level secure" is a sign that your Device is included as a secure Device with encryption enabled.

I did some more testing and connected the sensor non-secure. However I then still got the "alarm level secure" messages in the log, so these messages are not meaning that the device is connected with encryption. Does anybody now to check if a device is connected with- or without encryption?

I then also tried to get it working using groups 1, 2 and 3, but if I do that I lose the motion detection. So back again to 1,4 and 5 which works, but still "alarm level secure" messages in the log on every motion detection.

Got some strange behavour while testing however: even after excluding - and removing al devices -, restarting and then including again the detector initially associated again with group 1, 4 and 5 even if these are not the default/auto-associated groups (which is only 1 according to the config). Is there anything else I should do to "clear" a sensor after it is removed? (and if so: why is that not automated...?).

the old config only associated group 1
the new config does 1(even though auto=true is not mentioned) 4 and 5(have auto=true)

Hi there!

I've just installed the new FGMS in version 6277. It was included incorrectly cause i had the old fgms.xml config.
I've upgraded the manufacturer and fgmszw5 files like Gravitiz mentioned.
I now have the device reporting "correctly" every motion detection with:

2017-02-09 23:16:57.052 OpenZWave: Alarm Level: Secure
2017-02-09 23:16:57.052 (Aeotec Z-Stick Series GEN5) Light/Switch (Alarm Type MS)
2017-02-09 23:16:57.070 (Aeotec Z-Stick Series GEN5) Light/Switch (Alarm Level MS)
2017-02-09 23:16:57.086 (Aeotec Z-Stick Series GEN5) Light/Switch (Burglar MS)
2017-02-09 23:16:57.154 (Aeotec Z-Stick Series GEN5) Light/Switch (Sensor MS)

But I don't know why the Burglar notify is there.
The Burglar and Sensor are actuating equal with every motion, On with movements, and Off after 30 seconds (default config).

The associations by default went to Groups 1,4 and 5.

Greetings!

i use the burglar as pir sensor since it always works(also when you only have group 1 active)
when you have 4 and 5 active group 4 passes the sensor through so it also reacts when burglar is detected)
If you do things with groups you can choose which one you use(sensor or burglar)
if you only use the pir sensor then use the burglar one.

the groups are mainly used to pass something to other zwave devices
with scripting(lua or blocky) you can do more

here is what i do

when the alarm is switched on and movement is noticed my camera will take a snapshot and email it to me.
tamper is nice but that means somebody is already inside messing with your sensor(eg you are to late to act, maybe sound a siren)

I recently upgraded to the latest beta and "suddenly" the "Alarm Level: Secure" messages are no longer appearing in the log. Looks like somebody solved this issue?

what version is that latest beta?

Well that was version 3.6935, but that is no longer the latest

* EDIT * Just updated to Version: 3.6959, still working fine.

ok thanks

i will try it also tomorrow
i am still on dsm 6.0(running on synology) so i need to see i need to upgrade to dsm 6.1 or not.

installed 6944 and indeed those messages are gone.

wow what an empty logfile

today i upgraded my synology to DSM 6.1
rebooted, all seems fine

now i upgraded to version 6953 and i have timeouts on al my devices
normally i only had timeouts on 1 device(11) which is a qubino device
the rest of the fibaro modules were ok.

i think something else has changed