ZigBee Arrival Sensor For Car

It has been pretty straightforward for me on a couple of Nissans and a Chevy truck. To be on the safe side, you can unplug the red (+) connector on the battery. You could do it at the same time as when you change the battery to combine both events… But you may want to confirm that you have a switched « outlet » before you do this. It is not always clear which are switched and which are always on.

The most difficult part I find is passing the cable in the frame of the car by removing some of the inside panels. I’m always afraid I’ll break something, but never did…

1 Like

Animated GIF

1 Like

@mbishop, I just check in a change for DTH in my github. In the configure method, I started the timer when the presence attribute is set to present.

I think click configure after DTH change is the recommended step. It would make sense to start the timer there vs in refresh.

2 Likes

Hello Everyone,

I have a couple information that may be beneficial for us.

First, I am aware that some of us here use Zigbee2MQTT to handle our ZIgBee devices. I just want to let you know the incoming release for Z2M will include Arrival Sensor converter. If I am not mistaken, it should be release after 1.25.1.

What this mean is you can pair Arrival Sensor to Z2M natively. You just can start pairing in Z2M. The Arrival Sensor should be discovered and the driver will be automatically paired.

The second information is I discover that Z2M has a little quirk that may be beneficial for Arrival Sensor use case. Z2M with TI ZIgBee stack is capable to duplicate a ZIgBee Coordinator to a different physical stick. Z2M is able to replace a broken stick with a new one without re-pairing. This technique can be used to duplicate information of one coordinator into another.

Knowing the above, what is the benefit for us? Some us may have multiple location with its own separate home automation. Perhaps, we have home and office HA system. Wouldn't it be nice if Arrival Sensor can be paired to both locations? The Arrival Sensor can hop from one location to another seamlessly without needing to be re-paired. We can track whether our car is in either location. While near those locations, we can setup automation to help protect the car.

This is an early test. I have a video to demonstrate how it work. I apologize that the video is a bit longer than I wanted. I am sorry if you seen fragments of your non preferable hub in the video. Those are my test environment. My intention is to share a knowledge of what is possible. It is not my intention to open a discussion about one hub versus another. Z2M is a HA neutral Zigbee eco system which we can use with Hubitat through MQTT.

I will make separate post on how I am able to duplicate ZigBee Coordinator in 2 Z2M system.

2 Likes

Iman - this is brilliant! I wish I could make use of it!!

1 Like

Thanks @aaiyar. I am going to share how I am setting mine up in Z2M. Let me gather those information and post it here. I will definitely share the information so that the idea can be tested to those who are interested in such scenario.

2 Likes

***NOTE: The following information is not a mandatory to use Arrival Sensor with Hubitat. Arrival Sensor can be paired directly to Hubitat without Zigbee2MQTT. This post is intended for those who have hubitat at multiple location and need the Arrival Sensor move automatically between locations. This is more of an experimental configuration which may be beneficial for some of us ***

I will not cover how I pair my Arrival Sensor to Zigbee2MQTT. It should be very trivial especially once the converter for Arrival Sensor will be built in to the Z2M. We will be skipping to the point where you have 2 Z2M hub at different locations and one of them as Arrival Sensor has already paired.

WARNING: I would not make a duplicate coordinator to existing Z2M mesh. The ZigBee mesh where you duplicate the coordinator will need to re-pair its existing devices if you do so. I would start with a fresh Z2M mesh on the destination. I am giving this warning for convenience. I want to make sure that you don’t get to position where your have a lot of device paired and need pairing again

The above steps do not create a duplicate ZigBee environment. Each Z2M can have different devices paired to it. However, each hub will have the same ZigBee coordinator.

There are 3 files in Z2M that we need to edit.

  1. the configuration.yaml of both Z2M mesh have to have the following information circled the same. Please note the network key will be unique on your system. My network key is just a test. You do not need to copy mine exactly. You just have to have the same key on both of Z2M mesh.

  1. You can make make a copy of your coordinator_backup.json to your Z2M instance where you intent to make a duplicate Z2M coordinator. I am not sure whether this is a necessary step. I just think that I want to make sure that I make sure that I make as much copy as possible.

  2. In the database.db file where you pair the Arrival Sensor, you will see something like the following entries. Please make a copy so that both Z2M have the same entries with the exception the id. You should adjust the entries so that they are not conflicting with your other devices.

  1. You also need to make a copy of the Arrival Sensor information in configuration.yaml.

image

  1. TI stick is capable to copy a mac address to a device. Depending on TI CC25XX or C26XX, you may need use TI Flash or Flash2 to copy the mac address of the source coordinator stick to the destination. I only tested mine with CC2652P. I have SONOFF USB 3.0 plus dongle to test with.

Another Notes.

  1. We must use the same ZigBee stick (perhaps only compatible with z-stack/TI stacks only). I use Sonoff USB 3.0 plus dongle on my hubs. I further recommend that the stick must be from the same model. CC2652X stick is probably not going to be compatible with CC253X.
  2. Each Z2M must not be within reception of each other.
  3. Each Z2M is its own independent instance. There is no sharing resources between hub. You will need to configure the automation independently from each other. It is only the sensor can joint on to the Z2M that is within its range.

How are we going to bring the Arrival Sensor to our Hubitat? I make a set of App and DTH to make bring the the arrival sensor using MQTT to our hubitat. Z2M does not have automation capability. Hubitat is on the other hand is very strong with automation. We can bring the 2 worlds together using MQTT. It would look like just arrival sensor paired directly in Hubitat.

This is the same Arrival Sensor paired on Z2M. If you can see the mac address, you can compare it here.

Here are some of the thing we can do.

If you have 2 sets of Hubitat at different locations, you can setup a pair of local Hubitat + Z2M. As the car is near one of the location, its presence will be detect by the respective location system. You may setup any automation you like on each location.

Another possible scenario is using a cloud. In this case, you have a Hubitat as a master controller where you intended to track where your car is.

3 Likes

Just to set the record straight for anyone that follows me: my dead car battery was definitely not caused by this awesome device. The problem was an old battery, which I've since replaced.

Has anybody successfully printed the case? Neither Iman nor I are 3D printing experts, but I figured how hard could it be. :smile: I took the two "small" STL files to my local library and they got the below error when importing boxplastic_bottom and boxplastic_top into their slicing software (Cura). Anybody have ideas or suggestions?

Screen Shot 2022-06-09 at 5.13.05 PM

1 Like

Files are fine.
I just put them through Prusa slicer. I did rotate the files to put them on their flat side.
Printing them now on my Prusa MK3S.

2 Likes

Not sure why, but second attempt worked.

2 Likes

@mluck Thank you for your clarification and bringing this up here for all of us. I am glad a new battery solve the issue as expected. This will help all of us with a Note in the case similar issue happen to someone else.

1 Like

@iharyadi, one of my car sensors has been acting weirdly. Presence not reliable, in particular.

I decided to factory reset the device using your instructions, which worked great. And then I re-added to my hub. Also no problem. Despite this, the odd behavior continued unchanged.

I compared this device to my 3 other car sensors to see if anything is different and, sure enough, in the device details screen, under Data, I see this:
Screen Shot 2022-06-29 at 9.29.40 PM

I even factory reset the device a couple more times and re-added to the hub--I still get the above data. The selected device handler is "Arrival Sensor HA" and I hit configure just in case, even though it's always recognized as "Arrival Sensor HA" when joined.

All my other devices (the ones that work) differ in that the model is "tagv1" not "tagv4", and the manufacturer is " KMPCIL". Any ideas about what could be going on here? Thanks in advance.....

@mluck

One of the issue with the presence is the sensor lost its parent momentarily. It will attempt to rejoin the network and take a longer than usual. This is why I provide different timeout values. I personally set my timeout to 7 minutes. In my home, this is more than enough. In some other home, I have read timeout at 10 minutes.

You only need to play around with the timeout on battery. The car is most likely be on its own power while it leave the house. At that point, the timeout on dc is the one going to be used. What is your timeout value on battery?

I send you a couple times. One of the sensor may be the older batch. Originally, I make the same model id with ST arrival sensor so that we use built in driver in all platforms. However, I decided that the sensor is much more capable than ST sensor. I think it is better to have its own model id to be used with its own DTH. I will be happy to exchange the sensor for you if you prefer the newer batch if you are willing to cover the shipping.

Thanks
Iman

1 Like

I left the timeouts at their defaults--7 mins for battery and 1 minute for DC. I have a fairly dense zigbee mesh in my garage because I thought (??) it would make the car sensors faster to be recognized upon return to the home, and I thought they wouldn't lose connection so easily. Maybe I'm wrong about that.

Let me try to extend the timeout on the battery....I agree that short timeouts are more important for DC. Thanks for the offer to exchange the older sensor. Let me try to play with the timeouts first.

Still a great sensor! I don't know how you do it!!!

1 Like

I have 3 repeating devices in my garage. My timeouts are 2 minutes on dc and 10 minutes on battery.

The sensor has worked perfectly.

1 Like

super helpful data point. Won't the 2 minute timeout affect the timeliness of the sensor reporting departed? Or am I misinterpreting the concept of a timeout?

It will. But:

  1. I use this sensor as an arrival sensor to open the garage door.
  2. My departure relies on an owntracks geofence.

Just the presence attribute, or will it also affect the timeliness of powerSource? I ask because I use the AC event to open the garage door.

Both. In my use, the hub will still think the powersource is dc because my car will be out of range to indicate it has switched to battery when that 2 minute timeout is over.

I think I'm missing something. With my timeouts set to one minute and seven minutes, if I turn on my car, my garage opens in under a second, as soon as it sees the AC event. How do I reconcile this with the timeout settings?