@danabw https://www.amazon.com/gp/product/B076SGTMFS/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
1 Like
That's even smaller! Teeny-tiny. 
Says "3 meters" for range?
The one I started w/was this:
I use these 3dBi antennas on a couple other zigbee devices. They're similar to the one that @danabw showed in his photo.
At the other end of the spectrum, before I got Sonoff zigbee dongles as routers, I repurposed this 14 dBi directional WiFi antenna, connected directly to the coordinator and facing downwards from the attic, to blast zigbee through my two-storey home. It worked pretty well.
3 Likes
Could also use one of these: https://www.l-com.com/wireless-antenna-24-ghz-15-dbi-omnidirectional-antenna-n-female-connector?utm_campaign=PMax%20Shop%20Antennas&keyword=&gclid=CjwKCAjw2OiaBhBSEiwAh2ZSP5hunOZNsuN9RDuMUhuGCd6naPuKoKEaeQX3EzaDNxqic1nAMHvI6hoCBLIQAvD_BwE
It's a cool 41" long so it can also pull double duty as a lightening rod.
3 Likes
Is this the sonoff dongle you mentioned? I’m asking because it’s listed as a gateway not a repeater so not 100% certain.
That's the newer version, the "E," I used the "P" (Plus) version. Both have to be flashed with different firmware to be used as a repeater.
Information on both and flashing below:
1 Like
@iharyadi - I'm having some issues w/my hub picking up that the presence sensor is on DC when I pull into my driveway. My Rule requires that the sensor is on DC to run. I tested tonight and when I came home the garage door didn't open, and logs indicate that the sensor either wasn't reporting it's on DC when it became present, or Rule Machine isn't seeing it for some reason.
Rule:
I'm using a Custom Attribute in the rule to access the powerSource attribute.
Could this be an issue w/the sensor reporting presence earlier than reporting powerSource, so the rule starts on the presence change but then stops when powerSource is saying battery, or ? Appreciate any suggestions.
Maybe someone else can test using powerSource in their rule and confirm if it works for them? Maybe something odd on my end.
Hi @danabw, This is strange. You should not need an event for the powersource. When you leave the house with the car running, the powersource attribute of the sensor should be on DC. Would you be able to have a help at the house to confirm that the powersource attribute for the car should be on DC.
I personally pay attention to this attribute while I am home. All my car, that has left the house, has the power source in DC.
When you comes back, since the attribute is still in DC regardless whether there is a reporting of the power, the rule should run since the attribute for power source us in DC.
My suspicion is probably there is an issue when the car is started. Would it be possible that the power source event is missing when you started the car? I would check on this. It is very rare that this notification is missing on a good Zigbee network.
1 Like
EDIT, added 11/3/2002: To kill the suspense, it turned out that the real issue was a bad USB extension I was using the car. As soon as I replaced the USB extension the disconnects disappeared.
Thanks!
Looks like departing before dc powerSource is reported appears to be the issue. Checked sensor device events from our departure date\time and the sensor did not get a powerSource change to dc before we left, the last powerSource reading was battery. We must have started up and left quickly. So when we returned it was still on battery when presence changed and the rule didn't run. That make sense?
I just went out and started the car and idled for 15s, and dc power was registered in the device events, so that's long enough.
It's late so I'll test more tomorrow... Try 15s down to 5s, and see if there is an obvious cut-off point.
@danabw, The power source attribute change is instant in my home. I personally never have to wait 5 seconds to see the power source change.
If you use USB cable, please check the cable. If you have a shorter or higher quality(thicker cable), please give them a try. It is one area to check.
The second area to check is whether the sensor get dropped out of the network too frequently. You can enable the log on the device. Watch for message that say "device recovered from lost of parent ". If you have too many of them, it indicate the connection to the mesh is not good. Let me give some idea what too many is. Zigbee (wireless protocol) is not perfect. Therefore, If your device recover once or less than 10 times a day, that would still make sense. I personally see this message probably once a week. But, if you are seeing this once every 30 minutes, this is not an ideal situation. In this case, we should find a way to reduce it. Perhaps, optimizing the zigbee repeater location or trying out different antenna.
In any case, power source change status is instant in my observation. You do not have to wait for it.
2 Likes
Thanks for the details...I've just gotten back after being gone all day and things worked perfectly, garage door opened right up. When I left this morning I started and left immediately, I did not wait at all. So something odd about yesterday when it didn't work due to power source status.
I'll enable logs and check for the issues you note.
From 4pm on the 26 until 4pm 31st (today) I have 109 "device recovered from lost of parent" events in the logs.
So that's five days, so about 20 a day. So seems likely it's a zigbee mesh issue.
WHen I've checked the sensor usually is connected to a SonOff USB dongle, or to a Tuya USB repeater. Currently SonOff:
Thinking I'll move the SonOff closer to the garage. Currently we're parking in front of the garage while we work through some changes to furniture in the house. Garage is serving as the storage/staging location. So the signal is going through two walls, two refrigerators, and a dual-wall steel garage door to get to the cars.
1 Like
Checked my logs again a bit later and I was getting lost parent messages every second at one point! Clearly something funky about the connection of the sensor to my mesh. My other sensor was/is fine, not getting the crazy disconnect messages. I moved the Sonoff into the garage (which necessitated an unplug/re-plug) and waited a bit and things have settled down, the crazy lost parent messages stopped. I expect things should be OK now.
1 Like
Thank you @danabw to bring this up. I want to add a note for everyone in the community. ZigBee device is designed to recover from lost connection. It is not required for Arrival Sensor to run in "perfect ZigBee home". Arrival Sensor will leave the mesh and comes back. Sometime, it will reconnect to a less than ideal repeater when it come back. Eventually, it will reconnected to the best repeater. During this time, Arrival sensor may be dropped and reconnect a few times. Arrival Sensor has relaxed timeout during battery operation to minimize the presence false positive problem during this time.
However, when the device dropped so often (a couple times or more in a hour) for hours or continuously, it is not normal. When the device take long time to recover, It also a sign of something not normal.
@danabw, I just want to make sure that you do not hunting down and try to make a perfect ZigBee home. If you do have a perfect ZigBee mesh, it is great. Loosing a few connection and eventually reconnect to the best repeater is what it is intended to do. In my home, I can see my Arrival Sensor hop from one router to another probably once a week on my rarely driven car. I see more often when the Arrival Sensor just arrive. But, in my home, It is unlikely I am seeing the lost a couple times in an hour.
1 Like
Thanks for the info and context, appreciate it.
In the end, it appears it was a bad USB extension cable that was causing the problems. I haven't had a single disconnect since I did a reset and re-join of the sensor, and changed the USB cable. I think the cable was the real problem.
2 Likes
@iharyadi - I had another instance today when the garage door didn't open when I came home. Same sensor as was having problems before (which were identified at the time to be due to a bad USB extension cable) driving continuous lost parent issues for the sensor.
This appears to be similar, but I've enabled logging for the sensor and am not seeing any lost parent logs.
The rule failed to run because the sensor was still being seen by the rule as being on battery power - logs from my rule below.
To help w/troubleshooting, I was wondering if you can update your driver so that powerSource is included in the device Events page - that way I can see/confirm when powerSource is being set vs. when the rule runs and figure out how to make things more reliable. It has been almost perfect, this is the first failure of the rule in a week.
Temperature, shock, and presence events are currently reported on the device Events page, but powerSource events are not reported.
In your log file, there should be a line that look like below.
parse [raw:7B3201000F106F00180155001001, dni:7B32, endpoint:01, cluster:000F, size:10, attrId:006F, encoding:18, command:0A, value:01, clusterInt:15, attrInt:111, additionalAttrs:[[value:01, encoding:10, attrId:0055, consumedBytes:4, attrInt:85]]]
I would search for attrId:0055. This attribute will tell us the state of the power source on the first bit value:01,. An odd numbers will indicate the sensor is in DC. An even number indicate the sensor in Battery Power.
During the time that you start the car, please look for attrId:0055. A line should be there reporting an odd value.
1 Like
Thanks for the quick reply to me, an obvious problem child. 
So regarding below, (my car is on battery now) the "consumedBytes: 4" indicates on battery since an even number.
I'll do a couple checks. The last time I checked the powerSource status when starting the car, it changed immediately, lightning fast from Battery to DC when I started the car.
I'll open a log window w/my phone in the car and connected to my hub and re-confirm.
Regarding my request to add powerSource to the device Events - is that something you'd be able to do, or don't want to for a particular reason?
@danabw, the consume byte is not the thing we want to track. It is the "value:01". It indicates the current value of attributes 0x55.
I don't quite understand this request. I would be happy to modify the driver if I can. As written, the power source should be in the device event. There should be a line that show the new power source state when they change. Are you not seeing this on your hubs?
Here is what I have on one of my car. Please let me know if below is not what you are looking for.
Intesting...my last powerSource change was two days ago.
I have no powerSource changes since then, so that's why I was thinking they weren't in the Events list. I was only looking at today's events when we left and then returned home. We left at 1:02pm and returned at 1:22pm and there was no powerSource entry in the log. Presence was updated, but not powerSource.
My wife took the car to work yesterday and we got these entries, which did include powerSource changes that were absent in our departure/return today (above).
I've had no "loss of parent" events for the sensor since 11/02 when I changed the USB extension cable:
