Multisensor 6 motion detection

[Manish Kumar Thakur 2]

I'm having one multisensor 6 there motion sensor is not detecting . Is there any command is there to poll the data and is anyone is suffering from same problem like I'm facing.

[petergebruers 1,261]

Check parameters.

 

Parameter 4, mine is set at value 5 meaning:

 

Enable/disable the function of motion sensor.
Value=0, disable.
Value=1, enable, the current PIR sensitivity level=1. (minimum level)

Value=2, enable, the current PIR sensitivity level=2.
Value=3, enable, the current PIR sensitivity level=3.
Value=4, enable, the current PIR sensitivity level=4.
Value=5, enable, the current PIR sensitivity level=5. (maximum level)

 

Parameter 5, mine is at 1:

 

Which command would be sent when the motion sensor triggered.

Value=1, send Basic Set CC.
Value=2, send Sensor Binary Report CC.

 

Also check if controller (node id 1) is in lifeline group (association group 1). Without association, the device does not know where to send reports.

 

Note to other forum users, the topic starter is not using a HomeCenter controller...

[Manish Kumar Thakur 2]

Hello Peter,

First of all, I'm thankful that you are giving a reply to all of my questions but i'm getting only FF in my serial terminal it indicates means sensor in On right. then where we'll get the data. I'm getting wakeup notification and data is this 01 18 00 13 15 00 00 02 00 7E 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 9C. Can you please help in that matter.what is that 7E 7F 7F 7F 7F.

[petergebruers 1,261]

I am having a lunch break. I'll try to decode that for you after the break.

[petergebruers 1,261]

Interesting... I can decode the first part:

 

01 Start Of Frame

18 Length = 24 bytes follow (makes sense)

00 frame type REQUEST (good)

13 FUNC_ID_ZW_SEND_DATA

 

So the first 4 bytes make sense to me.

 

Explanation of FUNC_ID_ZW_SEND_DATA see:

 

INS13954-Instruction-Z-Wave-500-Series-Appl-Programmers-Guide-v6_81_0x.pdf

 

4.3.3.1 ZW_SendData

 

4.3.3.1.7 Serial API function prototypes

HOST->ZW: REQ | 0x13 | nodeID | dataLength | pData[ ] | txOptions | funcID

ZW->HOST: RES | 0x13 | RetVal

If either (funcID == 0) OR (RetVal == FALSE) -> no callback

If (funcID != 0) AND (RetVal == TRUE) then callback returns with: ZW->HOST: REQ | 0x13 | funcID | txStatus

 

So I expect a node Id, then data length... But this is where my understanding of the packet fails.

 

Because Node ID would be 0X15, which is possible, but then data length would be 0

 

If I assume the Node ID is missing in that hexadecimal stream...

15 Length of payload = 21 bytes, that is possible, and this would be the data:

 

00 00 02 00 7E 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 9C

 

That looks like a raw packet, or an encapsulated packet. I know almost nothing about "encapsulation". That 7E stuff might be a "home id". It looks vaguely familiar though... Maybe it has to do with Z-Wave routing?

 

Can you capture that data with a Zniffer?

 

Does a similar packet appear 4 times in a row, separated by 1.5 seconds? In that case the device is retrying because it did not get an ACK.

 

If a device sends data to the controller, your controller has to confirm reception by sending:

 

ACK = 0x06 # /* Acknowledge successfull frame reception */

 

 

[Manish Kumar Thakur 2]

Thanks, sir for your answer. I got acknowledgment also with that but I sent the data which came from there. but you said that assuming node id is missing but in that frame 02 is node id anyway I got that basic Idea how data is framing into that. If you know any further details please share me.      Thanks once again for your reply.. one more question is there that  vibration will come as notification alarm do we get any data there or values like 0x00 and 0xFF.

Edited January 18, 2019 by Manish Kumar Thakur

[petergebruers 1,261]

2 hours ago, Manish Kumar Thakur said:

but in that frame 02 is node id anyway I got that basic Idea how data is framing into that.

I've tried to match the bytes to the kind of frames that I know, but I cannot find any match. This is probably because I don' know all possible frames

 

The Serial Data Frame is OK, that is sure because:

 

01 Start Of Frame

18 Length = 24 bytes follow (makes sense)

00 frame type REQUEST (good)

13 FUNC_ID_ZW_SEND_DATA

(... some data bytes)

9C = Frame Check Sum

 

The frame length and the FSC byte are OK, so it certainly is a valid serial API packet.

 

Long shot... I think data frames starting with "00" are system related but I don't know what it means. That is probably a lack of knowledge on my behalf.

 

I am not at home and I cannot test it, but I think reports of motion would be of type "FUNC_ID_APPLICATION_COMMAND_HANDLER" and that CC would be "Basic" or "Sensor", based on parameter 5 (see first post).

 

2 hours ago, Manish Kumar Thakur said:

vibration will come as notification alarm do we get any data there or values like 0x00 and 0xFF.

Interesting question, I don't know... I even forgot it has a tamper alarm! 

 

When I'm home, I'll "shake" it and sniff the network 

 

[Manish Kumar Thakur 2]

Thanks sir for your reply

[petergebruers 1,261]

5 hours ago, Manish Kumar Thakur said:

Thanks sir for your reply

I'm still learning, but I try to help whenever I can.

 

You can show your appreciation by occasionally clicking on a like or thanks button on one of my posts. I am 100% end user and earn no money with this.

 

23 hours ago, Manish Kumar Thakur said:

I'm getting wakeup notification and data is this 01 18 00 13 15 00 00 02 00 7E 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 9C. Can you please help in that matter.what is that 7E 7F 7F 7F 7F.

 

Hi! I've got it! I knew I had seen this kind of data somewhere...

 

You received: 01 18 00 13 15 00 00 02 00 7E 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 9C

 

It is not a command class and it is not a raw packet either. It is a *callback function.

 

It is discribed in:

INS13954-Instruction-Z-Wave-500-Series-Appl-Programmers-Guide-v6_81_0x.pdf

 

Under "4.3.3.1 ZW_SendData", "Callback function Parameters" page 96

 

And then under "SerialAPI targets supporting IMA"

 

The Devkit 6.60.00 adds a txStatusReport structure to the ZW_SendData callback parameter and this have been introduced into the IMA supporting SerialAPI targets by extending the number of parameters in the ZW_SendData callback parameter list.

 

ZW->HOST: REQ | 0x13 | funcID | txStatus | wTransmitTicksMSB | wTransmitTicksLSB | bRepeaters | rssi_values.incoming[0] | rssi_values.incoming[1] | rssi_values.incoming[2] | rssi_values.incoming[3] | rssi_values.incoming[4] | bACKChannelNo | bLastTxChannelNo | bRouteSchemeState | repeater0 | repeater1 | repeater2 | repeater3 | routespeed | bRouteTries | bLastFailedLink.from | bLastFailedLink.to

 

So let's apply that to the data you've got:

 

01 Start Of Frame

18 Length = 24 bytes follow (makes sense)

00 frame type REQUEST (good)

13 FUNC_ID_ZW_SEND_DATA

15 funcID -> this nmber refers to the func ID you transmitted in the FUNC_ID_ZW_SEND_DATA packet you sent before this one arrived. It is an identifier to distinguis results form API calls.

00 txStatus

 

The txStatus codes can be found in the SDK in SDK_v6_81_01/Z-Wave/include/ZW_transport_api.h

 

/* Transmit complete codes */

#define TRANSMIT_COMPLETE_OK 0x00

#define TRANSMIT_COMPLETE_NO_ACK 0x01 /* retransmission error */

#define TRANSMIT_COMPLETE_FAIL 0x02 /* transmit error */

#define TRANSMIT_ROUTING_NOT_IDLE 0x03 /* transmit error */

 

So this packet means the previous transmission (probably to your MS6 sensor) was OK

 

00 wTransmitTicksMSB

02 wTransmitTicksLSB

 

Together this forms TransmitTicks and a tick is 10 ms. So it took 20 ms to send data to the MS6 and get ACK. This indicates it is in direct range. 20 ms is good.

 

00 bRepeaters the packet did not use any repeaters, your MS6 has a direct connection.

 

7E rssi_values.incoming[0]

7F rssi_values.incoming[1]

7F rssi_values.incoming[2]

7F rssi_values.incoming[3]

7F rssi_values.incoming[4]

 

That is a list of RSSI values from or to the device and the repeaters.

 

ZW_transport_api.h:

 

#define RSSI_NOT_AVAILABLE 127 /* RSSI measurement not available */ == 0x7F

#define RSSI_MAX_POWER_SATURATED 126 /* Receiver saturated. RSSI too high to measure precisely. */ == 0x7E

#define RSSI_BELOW_SENSITIVITY 125 /* No signal detected. The RSSI is too low to measure precisely. */ == 0x7D

#define RSSI_RESERVED_START 11 /* All values above and including RSSI_RESERVED_START are reserved,

except those defined above. */

RSSI = 2s complement in dBm

 

So your MS6 reports 7E == RSSI_MAX_POWER_SATURATED which means it is very close (too close) to the controller.

 

Since the MS6 has a direct connection, there are no repeater RSSI and thay all report RSSI_NOT_AVAILABLE

 

00 bACKChannelNo = Channel ack was received on, not sure what it means, "frequency" or "rate". Might be country-dependent, I do not know

00 bLastTxChannelNo

03 bRouteSchemeState

 

The meaning of that byte is in the doc or can be found in the header file:

 

typedef enum _E_ROUTING_SCHEME_

{

ROUTINGSCHEME_IDLE = 0,

ROUTINGSCHEME_DIRECT = 1,

ROUTINGSCHEME_CACHED_ROUTE_SR = 2,

ROUTINGSCHEME_CACHED_ROUTE = 3,

ROUTINGSCHEME_CACHED_ROUTE_NLWR = 4,

ROUTINGSCHEME_ROUTE = 5,

ROUTINGSCHEME_RESORT_DIRECT = 6,

ROUTINGSCHEME_RESORT_EXPLORE = 7

} E_ROUTING_SCHEME;

 

So this packet used "ROUTINGSCHEME_CACHED_ROUTE". I would have expected ROUTINGSCHEME_DIRECT but that was just a wild guess. I haven't tried with any other device yet so I really have no reference point. I guess this flag means "let the controller or the device do the routing based on cached information". But this is just a guess.

 

00 repeater0

00 repeater1

00 repeater2

00 repeater3

 

There are no repeaters, so they are all 0x00

 

03 routespeed

 

De definition of the speed constants is in SDK_v6_81_01/Z-Wave/include/ZW_controller_api.h

 

/* Z-Wave RF speed definitions */

#define ZW_RF_SPEED_NONE 0x0000

#define ZW_RF_SPEED_9600 0x0001

#define ZW_RF_SPEED_40K 0x0002

#define ZW_RF_SPEED_100K 0x0003

 

This means your MS6 exchanged data at 100 kbit/second, which is to be expected because controller and device are Z-Wave Plus.

 

01 bRouteTries

00 bLastFailedLink.from

00 bLastFailedLink.from

 

No retries were done so no failure stats I guess...

 

9C Checksum of serial api packet (matches the data)

 

21 hours ago, Manish Kumar Thakur said:

vibration will come as notification alarm do we get any data there or values like 0x00 and 0xFF.

I'll try to sniff the MS6 today.

[Manish Kumar Thakur 2]

Hi Peter,

very thanks but I got the vibration data values. I will just come as 0x00 is not triggered and  0xFF is triggered as a notification report V3 command class 

Notification command class is 0x71 and command is 0x05 in that data values will be 0x00 0r 0xFF

[petergebruers 1,261]

OK, so it is always "cc notification" for tamper, good to know!

Can I ask what you are doing? Building your own controller? I'm primarily doing this "for fun and pleasure" and getting a better understanding of Z-Wave!

[Manish Kumar Thakur 2]

I'm using my custom CC3200 a WiFi soc(which is completely custom and our team made as small as possible) as a gateway. so that device will act as a gateway and that can be connected to the internet also.