ZigBee Arrival Sensor For Car

I am seeing an error. But the error is likely from the temperature measurement. I will look at it in my hub whether I am seeing this error. I don't think I see this error before. But, I will double check.

I am now seeing that the battery measurement is reported. You should see "Battery:100" on your attribute. This should be in your device detail page. Can you confirm?

I see that this log is coming in at least another packet after the bunch above. Lets monitor this. If this packet keep coming, your sensor is fine.

Now, you should be able to switch to battery by unplugging the DC power. I assume you have battery plugged in. There should be a binary input message. The power source attribute should change to battery. Or, just shake the sensor, here should be a new type of message coming in.

Just quick update. Here is the log on mine. Note the red one is the one I am looking for. This is the cluster that will report when it detect movement and change power source. Lets test this. You should be able to see this message on a fully function system.

I am not seeing any issue when the temperature measurement is handled. Have you make changes to your DTH? I am running the latest hub firmware with my Arrival Sensor in github. I do not see any exception. I have tested the DTH on past firmware as well.

2 Likes

how is this working if the car is gone for a long time ... say a month.. because i know my zigbee devices if battery dies and I dont get to them for a long time they drop off the mesh and i have to initiate a rejoin to get them back on..

just asking as it may be a potential issue with using zigbee as presence sensors.. i have had good luck with the older smarthings arrival sensor put in a case with aa batteries lasting years and never causing issues.. Too bad they are no longer made and that they didnt make a better version with the larger batteries as the coin cell version had terrible lifespan.

thanks

I think this question is for general Zigbee devices not specifically for the sensor that I make. Sorry for the long answer. I tried to understand the rejoin process a long time ago. Here is my thought about it. I got the info from this link https://www.silabs.com/documents/public/application-notes/an1233-zigbee-security.pdf. I have read it. You can skip to 3.5.1 Secured Rejoining and the next couple sections. I suppose you can take Zigbee official specification and end up with similar understanding.

In ST, there is a setting named allow "secured/unsecured" rejoin. What you are experiencing is consistent to my understanding with secure rejoin. When a Zigbee Device goes out of range for long period of time, the network key that is stored on the device could be out of date. The network key in Zigbee mesh is recommended and typically changed automatically at some interval. In secured rejoin and you have staled network key, you may need to re-pair the sensor again.

This is not true for unsecure re-join. In Zigbee, the term for unsecure rejoin is actually called trust center rejoin. When a device request a rejoin basically, it will involve the trust center to send a the current network key. :shushing_face: :shushing_face: :shushing_face: This is an easy exploit for us who run Zigbee Network especially when you run Zigbee 3.0 older stacks. The network key is transported with a know Zigbee Global trust center key. In Zigbee 3.0, it is remedy a bit since each device should have a unique transport key that is generated during the initial join process (replacing the global known trust center key).

I do not know what hubitat is setting for rejoin. If anyone know how to query and set the setting, please let me know. I suspect that hubitat allow trust center rejoin. I have a few very old sensor from different brand that is out of battery for months come back to my hubitat mesh without any issue. Therefore, I always assume it is a trust center rejoin system

So my answer is I think it is fine to use Zigbee end device (there is a different requirement about the rejoining behavior of the device itself) as presence sensor as long as the hub allow trust center rejoin. Any zigbee hub that allow trust center rejoin will not have issue with a stale device coming back.

In addition, network key rotation is not very often. I do not remember whether there are any standard. I would say for daily driven car, this is probably hard to hit.

1 Like

I haven't had any updates on the sensor since 10:18. It's still on the mesh though... Temp is still way off (again be easier if the offset was in F instead of C for myself as I don't use Celcius)... Shock is reactive as well...

image

and

image

dev:16302022-05-11 10:18:18.373 am infoparse [raw:6893010001082000201E, dni:6893, endpoint:01, cluster:0001, size:08, attrId:0020, encoding:20, command:0A, value:1E, clusterInt:1, attrInt:32]

dev:16302022-05-11 10:18:17.863 am infoparse [raw:6893010001082000201E, dni:6893, endpoint:01, cluster:0001, size:08, attrId:0020, encoding:20, command:0A, value:1E, clusterInt:1, attrInt:32]

dev:16302022-05-11 10:18:16.782 am infoparse [raw:6893010001082000201E, dni:6893, endpoint:01, cluster:0001, size:08, attrId:0020, encoding:20, command:0A, value:1E, clusterInt:1, attrInt:32]

dev:16302022-05-11 10:18:15.196 am infoparse [raw:6893010001082000201E, dni:6893, endpoint:01, cluster:0001, size:08, attrId:0020, encoding:20, command:0A, value:1E, clusterInt:1, attrInt:32]

dev:16302022-05-11 10:18:15.107 am infodevice recovered from lost of parent at 2022-05-11 10:18:15

dev:16302022-05-11 10:18:15.103 am infoparse [raw:catchall: 0000 0013 00 00 0040 00 6893 00 00 0000 00 00 049368EBB7AB1B004B120080, profileId:0000, clusterId:0013, clusterInt:19, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:6893, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[04, 93, 68, EB, B7, AB, 1B, 00, 4B, 12, 00, 80]]

dev:16302022-05-11 10:18:07.877 am infoparse [raw:6893010001082000201E, dni:6893, endpoint:01, cluster:0001, size:08, attrId:0020, encoding:20, command:0A, value:1E, clusterInt:1, attrInt:32]

@rlithgow1, You do have error on your update temperature measurement. Did you change the code? If you like to adjust the temperature in F, I will work on updating the DTH at some point.

I do not remember but someone else asking about temperature is being off. This is my answer to the questions. Short answer is YES temperature can be way off.

Nope, don't touch code. :slight_smile: Using your current driver from the repository. :slight_smile: And please, do not get me wrong. I am not complaining what so ever. Just trying to help work out bugs :slight_smile: I think this is going to be a great product and I hope you make a fortune my friend. What about doing a version with a female mini usb?

1 Like

I am good. I appreciate your feedback. It is real life experience. I would like to address those that can be addressed by the arrival sensor. I make the sensor for myself to use in my home too. I want to fix any potential issue that I have not seen myself.

This is a hobby pets project for me. I would not mind if this take off. I really appreciate this community and the help I got from all of you. I hope to make something that is useful of all of us.

I suppose I can make some with female connector. Wouldn't you need a cable to plug into USB port? I pick the USB-A male port to avoid cable if possible. 2 out of 3 of my car does not need cable. I have access to the port with good clearance from the surrounding. But, if a device with female micro USB is beneficial for us, I am open to make some with that connector. Perhaps, if I have some space on the board, I can make board with both connector. I will update you.

3 Likes

A lot of cars here don't have a readily accessable usb port and those that do, most times it's recessed so a cable is necessary. I know I could just add a usb a extension cable but I think a micro usb port on an enclosure looks more aesthetically pleasing then seeing a thumb drive style look... (Another reason I like the small antenna) It's too bad you could figure out a way to make the aluminum case into an antenna in and of itself. Now that would be cool... (I don't know if that'd even be possible)

1 Like

If you do consider using a female USB connector, please use USB-C and nothing else. They are more robust than Mini-USB, they are the future of charging ports because of the higher currents they can support, many new cars are coming out with USB-C only and most in the very near future.

5 Likes

I should have said usb C I didn't even think of that...

2 Likes

@rlithgow1
What zigbee channel are you using and what channel is your home wifi on?

I have found zigbee channel 21 to work the best for me I also moved my wifi channel away from channel 21. Unfortunately if your neighbor's wifi is close enough they can also cause interference.
If you have a Xbee3 pro you can scan your network for interference and determine the best channels.
I have not had any issues this this Arrival sensor in my car but any device could be faulty or fail.

My wifi is good. Since my last reset and re pair it seems to have stabilized. At this point I'll defer to @iharyadi @aaiyar that I wasn't fully paired on zigbee (which given the strength of my mesh is weird but hey). Thank you though!

2 Likes

I think it is not an issue with interference. It help when you have a perfect (lab quality) radio space. But, I think the issue is the middle router may randomly get overwhelmed during the paring process.

Zigbee router (ZR) repeat packets in store and forward mode. It take a packet and stored it on behalf of the "Sleepy" Zigbee End Device(ZED). Then, forward it to the ZED when ZED wakes up. The storage could get fill up during the paring. Keep in mind that ZR may also a resource constrained devices.

Once paired, typical packets exchange is smaller. Even a resource constrained ZR would be able to do its job.

I remember there is a suggestion to pair your zigbee near by a HUB (typically Zigbee Coordinator). This is a good suggestion as long as the ZC is not full to avoid the store and forward the packets needed during pairing process.

1 Like

This used to be an issue with many bulbs. They were RAM-limited.

2 Likes

I'm trying to get this sensor up and running, and I'm having trouble with the initial pairing. When I connect the sensor to USB (just desk-testing for now), the red light comes on and stays steady. I've tried doing the ~5 second button-hold when connecting power. I don't see any LED change from that, but I don't know if I'm supposed to. (It would be helpful to have something like three blinks on reset, five blinks on pairing, etc.)

I have two different Hubitat hubs, and neither of them sees anything when they go into pairing mode. I'm assuming it's not the hubs, since one of them has other Zigbee devices and neither one can pair with the sensor.

You do have an antenna actually screwed on to it right? So holding the button then letting go after 5 seconds resets it. Then you start zigbee pair on Hubitat. If you don't have an antenna screwed on then it won't pair (I figured that out when I didn't have one on)

Yes, I have the antenna attached. Though you make me think I should swipe the antenna off a Wi-Fi card and see if the antenna is the issue....

Couldn't hurt!

Interesting.... It paired successfully after a reset with a different antenna. After swapping back to the original antenna, it still seems to be publishing events.

Though I note I only have four properties shown, similar to @rlithgow1; I'm not seeing shock appear. Might be worth resetting again.

Edit: After re-pairing, shock is showing up.