I personally concern setting the timer with less than 1 minute. The sensor is configured to receive a packet every 20 seconds during dc mode. Please think of a packet as a heartbeat that indicate the sensor is present.
Having 1 minute timeout means that the hub would have to miss 3 packets/heartbeats before marking it not present. Using smaller timeout say 21 seconds, a single packet lost would mark the sensor not present. It could cause false positive if we make the presence status based on missing one packet.
Things are more complicated since there are other mode and packets. I use a simple example above to explain as best I can on why 1 minute is chosen as minimum timeout.
I believe @Mariano_Colmenarejo shared his code. If you want to be more aggressive, I would check out his code and make the timeout shorter. In any case, I would not go for less than 20 seconds for the timeout.
I appreciate the explanation. Honestly wouldn’t know what I was looking at as far as the code is concerned. Just a follow up question, could the interval between packets being sent be decreased? I’m aware that would most likely be detrimental to battery life.
Indeed I think it could lead to false detections of non-presence.
I’ll tell you how it works in case you want to modify the code and try it.
The presence event is emitted as soon as the first acceleration, movement, battery, temperature or power source message arrives.
At the same time, the presence emission time is stored in a variable and is updated with each message received.
To detect non-presence, a 30sec timer is used that:
check what power is currently being used to set the corresponding wait time selected in preferences.
compares the time of the last presence event issued with the waiting time established for the current power supply.
If it is equal to or greater than the waiting time, then the event not present is emitted.
The “dcPresenceCheck” preference is defined as an integer type and can no longer be changed to number (decimals) without forcing all users to uninstall and reinstall the sensor.
Therefore, the only thing that could be done without creating a problem for other users is to lower the minimum limit to 0 minutes.
This would be equivalent to the non-presence being emitted between 0 and 30 sec after the last presence event.
I think that you would need the routine to close the door to be with “If it is not present for x seconds” then close the door
The 30 sec timer could also be lowered, but the workload on the hub would increase somewhat.
Think if you think it can work for you and give it a try.
The hub may work a little bit more at higher frequency check. The sensor itself will not send packet at faster interval without changing the ZigBee reporting configuration for the battery power. It would not use more power without modifying this configuration.
There should be power reporting that is configured to report 20 seconds currently. This is the main heartbeat that I mentioned. It can be modified to report at faster frequency up to once every 1 seconds. If you really want to look into this, I would have to dig into the code where the driver does the configuration. Please let me know. Making the reporting faster will help you to modify what the presence check to be faster as suggested by Mariano_Colmenarejo.
However, a sensor that report at higher frequency may flood your ZigBee network while the sensor is powered on DC if you consider doing this. It is up to you whether you want to explore all this possibility. From my testing, the current configuration is the most balance that I think is safe to use. But, you do have have the option to tweak it if you have the time and willing to spend time and take some risk.
I want to let everyone know that I do not have any Arrival Sensor from the last batch. I have started to look into making improvements for a new butch in the event that I will make a new batch.
During this process of making a revision, I found an unfortunate error on the battery protection wiring on the current batch. Although the sensor is fully functional, the battery protection is important to make sure that the battery is used properly. There is a risk of damage to the battery during usage. Using damaged battery could cause fatal accident. I have not heard any issue on the field at this point. However, I want to make sure that I disclose the issue so that everyone can take action. If you decided not to use the sensor as one of the solution, I would be happy to refund your payment for the cost of the sensor. Please send me an PM.
I will correct this error if I decided to run a new batch. I have not committed to make a new batch at this moment.
I am aware that from the feedback that some of us including myself is excited about the sensor and its potential. It would have been a painful to loose the functionality. Again, I offer to refund your cost of the sensor if you decided not to use it. But, If you sill want to continue to use the sensor, to minimize the risk, you can use a protected battery. A protected battery contain the protection circuity in the battery itself. This configuration is not something that I have designed for. I cannot for sure that it will eliminate any risk with this configuration. If you like to have more information, please feel free to PM me.
I am just a like a hobbyist who want to make improvement to our smart home. I make some sensor to share with the community because I feel that it would improve our experience. I would like to apologize for this unintentional mistake.
Just FYI, this is a hobby project under development. I make small quantities for my self to use and develop. In doing so, I have left with more sensors than I can use. I share the sensor with the community because it could be beneficial for others in the community. In turn, the interested community member can turn this as “Do it yourself” project.
I build this sensor for my own use with safety in mind. To the best of my knowledge, I have build the sensor by minimizing any issue that I am aware. However, with any product there is always a risk. When I know a mistake has been made, I communicate it to the user in the community.
@Awestun, thank you for your helpful thought about liability.
I want to make sure that I use this opportunity to let everyone know that the use of this sensor is at your own risk".
If for any reason for any user who use my sensor believe otherwise, I would be happy to offer refund. You can stop using the sensor.
I apologize if this warning sound harsh. It is not my intention to do so. I just want to make sure to clear any miss understanding about this topic. I am aware that many user of my sensor, this and others, what you are getting into. I sincerely appreciate and grateful for your support.
Both of my sensors are reporting not present when they should be present. Going to the control page for devices in the Andriod app displays a pop up stating “This device hasn’t updated all of it’s status information yet. Check again later.”
Not using batteries at all. Have the sensors plugged into switched USB where power is off when ignition is off. Start vehicles and garage door opens, manually close them, and then when I return presence is normally detected about halfway up my drive to reopen doors. I just thought it strange they both stopped functioning right around the same time. I’ll keep trying to get them reconnected, maybe a hub reboot for starters.