Aotec multisensor 6 motion sensor not working with OH2

Setup, Configuration and Use Runtime
, ,
1

Hi,

Just noticed that the motion sensor of this sensor never gets triggered in OH2 (other sensors work OK). The sensor shows up in Habmin in channels as a binary sensor, and it also shows that it is linked to the appropriate contact item.

If I trigger the sensor I get a few lines in the logs, but nothing else:

18:53:17.098 [INFO ] [marthome.event.ConfigStatusInfoEvent] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@15edd29
18:53:17.098 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘zwave:device:83fcde36:node3’ has been updated.
18:53:17.350 [INFO ] [marthome.event.ConfigStatusInfoEvent] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@159f819
18:53:17.350 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘zwave:device:83fcde36:node3’ has been updated.

2

Please can you provide the debug log - clearly something is being received…

3

hi Chris,

there is not much else in the debug logs:

20:01:28.199 [INFO ] [me.event.ThingStatusInfoChangedEvent] - ‘zwave:device:83fcde36:node3’ changed from ONLINE: WAIT to ONLINE
20:01:28.352 [INFO ] [marthome.event.ConfigStatusInfoEvent] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@bd77cb
20:01:28.353 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘zwave:device:83fcde36:node3’ has been updated.
20:01:28.648 [INFO ] [marthome.event.ConfigStatusInfoEvent] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@1b59698
20:01:28.650 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘zwave:device:83fcde36:node3’ has been updated.

4

Just figured out that it does not work with Contact type items, but works if I change the type to Switch

5

It’s hard to believe there’s nothing being produced by debug. Is debug actually enabled? I’m guessing not as there’s currently only INFO entries…

If this really is all there is, then we’re not receiving any messages, so there’s something fundimentally broken.

6

sorry, you’re right, it was not enabled, here is what I get when the motion sensor triggered:

2016-04-03 20:25:18.867 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2016-04-03 20:25:18.868 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class BASIC
2016-04-03 20:25:18.869 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 3: Received Basic Request
2016-04-03 20:25:18.870 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 3: Basic Set sent to the controller will be processed as Basic Report
2016-04-03 20:25:18.872 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 3: Basic report, value = 0xFF
2016-04-03 20:25:18.875 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-04-03 20:25:18.876 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2016-04-03 20:25:18.878 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Config updated
2016-04-03 20:25:19.174 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2016-04-03 20:25:19.176 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class ALARM
2016-04-03 20:25:19.179 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 3: Received Alarm Request
2016-04-03 20:25:19.182 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 3: Process Alarm Report, V3, length 13
2016-04-03 20:25:19.183 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 3: Alarm report - 0 = 0, sensor=0, event=8, status=255
2016-04-03 20:25:19.184 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 3: Alarm Type = General (0)
2016-04-03 20:25:19.186 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2016-04-03 20:25:19.187 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0
2016-04-03 20:25:19.188 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Config updated
2016-04-03 20:25:19.317 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: No converter set for state zwave:device:83fcde36:node3:alarm_general
7

so looks like it is triggering alarm_general. but shouldn’t it trigger sensor_binary?

8

Maybe there’s a configuration option? This is what the device is sending, so the binding is processing it ok in that respect.

I’d really like to see the data from the debug file though if possible - I think this has been filtered on the node number?

@xsnrg any comment - you have this working right? If not, let’s take a look at sorting it…

9

Yes, I have it working fairly well I think. Check option 5, which is which type of event to send. I have mine set to send sensor binary. Check parameter 101 as well. You may have this working already from the sounds of it, but to get all values for the multi part of the device, set this value to 241, and set the interval to report to something that works for your setup. My device is on mains power, so I have the auto-send set to 60 seconds which works well with rrd for graphing. If you are running on battery, you may want to set it to 3600 (1 hr) or something to conserve battery.

10

@xsnrg thanks for the reply.

do you know what the difference is between binary report and basic set in option 5?

11

I am no z-wave expert, but my understanding is the Basic set is just that. It is the basic command class that all devices support, and is limited to get/set. Sensor binary is a more specific class that just reports two states from the sensor. Open/Closed is an example. Depending on the device they can be used almost interchangeably. For no particular reason, I have had better luck with my devices when I use the more specific command classes, in this case sensor binary vs basic. @chris can go into much more depth than I if you want to know more.

12

Yes, it just selects which command class to use. Using BASIC is more compatible with different devices, since everything supports it. The ALARM provides more information, but is also more complex in that different devices send different data which can make compatability more difficult.

BASIC is generally supported by all devices, so with this setting you can send the alarm to turn on lights etc directly from the device.

13

@xsnrg @chris thanks for the explanation.

I tried both last night, seems the binary_sensor channel in the binding picks up both. I think the reason why it did not work before because it seems to be getting ON/OFF rather than OPEN/CLOSE, so a contact item just not picking up that signal (which worked in OH1), changing to switch item type solved the problem.

14

Hi @jamborta, I have upgraded my OH2 to the latest version of OH2 & Zwave addon (20160516) and I have the similar issue with my three FIBARO FGMS001 Motion Sensors ! If the type of this items is defined to “Contact” (in .items file), OH2 doesn’t display the value of motion detection. But if the type is defined to “Switch”, all is right (Basic UI, rules).

Is it normal ? @chris @xsnrg

N.B: my item configuration:

Switch Detector6_Movement “Mouvement [%s]” (groupDetecteurEntree, groupPresence) { channel = “zwave:device:e663edc3:node6:sensor_binary” }

15

This is how it works for me as well. They are motion triggered switches, there is no contact, so it seems to make sense in this respect.

16

Basically, you can’t change the item type yourself - you must use the ones defined by the binding. This is a shortcoming of OH2 - the binding has no knowledge of the items, so it defines the types and the items need to respect this. I know this doesn’t always suit, so it might mean we need to add extra channel types.

17

Ok but in this case, the item should be invalidated during the items loading and doesn’t display in UI. Currently, we have no warning/message to inform an invalid item configuration. Am i wrong ?

18

No - you’re right, but this isn’t something the binding can do. As I said, the binding doesn’t know anything about items.

19

I am agree with you :slight_smile: This item validation control should be processed by ESH.
@Kai : what do you think about that ?