The “short” answer is if you watch the first video, the distance is approximately 2 to 3 house away from my house as the car is moving in the video.
If you are interested on long answer, here they are.
From what I observe during my testing, the speed of the car impact the range. If the car is parked, the sensor will connect as far as 5 houses way from mine. If I drive above 30 miles per hour pass my house, it may not detect the sensor at all. I do not know this for a fact as I live in a community. I do not want to test this scenario.
Antenna is also play a role. The antenna pictured has 3dbi gain. If I fit it with longer antenna, it will make the range further. I do not have number on what the range differences between 3dbi vs 9dbi antenna. This is less important than the next point.
Lastly, the car and our house is in a way a Faraday cage. The car is extreme case of this because of the steel and glass around it. If you really want to extend the range this is the biggest thing to tackle. One thing I do is to get an external antenna like this for my mini cooper.
I test with having one of my Zigbee repeater outdoor. Our house is a Faraday cage as well. I have wooden house which is not bad. But, concrete and steel garage door does not help with the range.
Please be warn though, I personally required myself to be able to see my house before the garage door is open. I do not want to have my garage door opened when I am 10 houses away. I don’t think we want to over extend the range as well.
I am testing the above out of curiosity. At the end of the day, I did not overthink it. I just go with what I have and put the sensor in my car. My Zigbee network detect the sensor when I am coming home from 2 to 3 house away. I am happy.
I like your project.
Are you going to publish your schematic and firmware?
I was thinking about creating something similar - ZigBee arrival sensor for the keychain.
It looks like you are using the E18 chip, was it difficult to implement the zigbee protocol?
I have not decide whether I would make the schematic and firmware available. This is just a hobby project. At one point, once I have it refined, I will give it a consideration.
The E18 is one of older zigbee MCU. The difficulty working with such MCU is relative. If you have a lot of embedded development experience, it shouldn’t be a problem.
@Hedda, thank you for your suggestions. I will look into CC1352P or CC2652P. I can’t promise anything. Today, based on what I know about them is that they are more expensive than the CC2530+CC2952 combo. The cost may not be significant for major manufacturer but perhaps not for me (a hobbyist).
I will keep you and everyone updated here. I have a batch of 10 board ordered with some improvement. In this batch, I have the board assembled by PCB manufactures to test their capability to source the components and its assembly quality.
CC2652 and CC1352 radio modules from RF-star/RFSTAR and Ebyte only cost ~$6-14 per unit if you order a few from Aliexpress (they will obviously cost even less if instead import more via Alibaba). Ex:
So my guess is their higher cost should not increase the overall BOM for the finished product by more than ~$2-5 if switch to using new CC2652P instead of using old CC2530+CC2952 combo radio module.
I think their significant benefits over older the now obsolete CC2530/CC2531 clearly outweigh their higher cost for any new products. Especially when considering CC2530/CC2531 only supports Zigbee 1.2 and are close to end-of-life so have not gotten new SDK with security updates for many years now.
The benefits of CC2652 and CC1352 is not only faster MCU with more flash storage and more RAM but much better power management and Zigbee 3.0 support, and of course they keep getting updated SDK.
Since CC2530/CC2531 are obsolete and deprecated as in “no longer recommend” for new products which means that risk is there won’t be long-life firmware with security and bug-fixes via upstream/SDK.
This firmware for DIY end devices or routers is exceptional, I highly recommend. I’ve only used it with CC253x devices, but I understand he supports the CC2652 family as well. There are not as many development board options for the CC2652 device as for the CC253x devices. I’ve had good success with CC253x both on battery and mains powered, and they are very low cost and available today. Do get a couple and CC debugger all for well under USD 50 and experiment with what kind of I/O and sensors you can bring into your zigbee Home Automation environment.
I’ve only used this firmware with devices attached to my zigbee2mqtt setup. This firmware is very well supported by the zigbee2mqtt folks. I have yet to see if the integration is as good with the firmware attached to a ZHA or Hue zigbee setup.
IMHO, for end devices and routers, I did not think the CC253x is going to be obsolete for a very long time, they just work and are solid. The basic CPU in them is going on 30 years already and shows no sign of not being used in many IOT and IIOT applications. For coordinators, I agree the CC253x is at end of life, just too underpowered.
@Hedda, I am sure newer TI mcu is superior compared to the aging CC2530+CC2952. This is obvious.
Specific to this arrival sensor, It is an end device. @dproffer make a really good point that as end device, cc2530 is still very capable. Developing an end device is different from developing a Zigbee coordinator or a router. For this project, I am leaning to stick with CC2530 at start. It check all the box for this project at this moment. I will always have my eye on CC2652 for the future of this project or my other projects.
In regard to the firmware, I have no doubt that PTVO is a good firmware. However, my goal is to have more refine firmware specific for an arrival sensor. One of the many examples why I would like to have my own firmware is that I am using dual power supply (battery and DC). I would like to advantage that I can be more aggressive when the sensor is powered with DC. This is hard to do with a general purpose firmware. Just FYI, There are many things that I am able to optimize with specific firmware.
Maybe you shared this is your post and I missed it, I apologize if so. What toolchain do you use to develop your CC253x apps? I though the TI supplied tools were rather pricey.
Taking nothing away from your very nice solution. Why I find the PTVO firmware so amazing is that literally in an hour and for 20 dollars you can have a GPIO, analog, PWM or I2C device on your zigbee2mqtt network controlling something and/or receiving data.
Like you, the author of PTVO firmware is very good CC253x software developer.
Thanks for sharing your project, I hope it gets folks doing more zigbee hacking with Home Assistant and zigbee2mqtt. These are useful tools to have in your home automation quiver. It is very nice to be ‘all local’ if at all possible.
I just received V2.0 boards. I am quite happy with the result. They are assembled by a contract manufactures. The build should be much better that what I can do with my home equipment.
Here are some pictures of the batch with a few boxes options.
Here is 3D printed box. I use it for my sensor that I fit a microwave radar. If you are new to the thread, the arrival sensor has optional microwave radar support to help detect human near the car. I use it to help secure my car that is parked on my driveway.
I have shipped all requested Arrival Sensor. If you need a tracking numbers please let me know on a PM. For US members, I would expect to have the sensor delivered this coming week.
I do not have any sensor from the previous batch. However, I have started the process to have a new batch made. I should have availability in 4 weeks approximately. I will update everyone here with the progress.
Awesome project, doing something similar, but with phone presence detection.
FWIW, IMHO, The only thing I would change with yours is, instead of having Alexa reply with “Garage door is closed” when you make the request, the response should be something like “Sure thing”, “Will Do”, “etc…”, then using a energy monitoring plug (for garage door opener), once the state changes to a certain level (amps/watts used increases), Alexa should announce “Garage door is closing”, and then once the door is actually closed (door sensor status)+plug (amps/watts used decreases), only then Alexa should announce “Garage door is closed”, hope that makes sense, and even better if they will enable follow-up mode in the mobile app.
That would be cool. I would need to sharpen my Alexa skills. Right now, Alexa is using a standard lock/unlock prompt from their garage door delivery service.
I have already done so for my alexa at home. My garage door has already have announcement for opening, opened, closing and etc. I just do not want to send it to the car. I would have to find out how to send those tts to the alexa device that request to close the garage door.
