Dave, this particular AP is a Netgear R7800 running OpenWRT 24.10.5.
I’ve just switched its Wifi channel back from 1 (2412 MHz) to 5 (2432 MHz) which I was originally using and is less crowded, and I have enabled WMM (Wi-Fi Multimedia) which was likely causing the low/asymmetric speeds (1 Mbps vs 54 Mbps).
Also, I’ve enabled PMF (802.11w Protected Management Frames) as “optional” which should allow the device to negotiate secure management frames if it wants to, and should most likely eliminate the “reject paintext fragment” you saw in the logs.
Finally, I’ve also disabled disassoc_low_ack to prevent the AP from aggressively kicking the device off if it temporarily responds slowly.
I have been following this thread with interest, though it has been a few weeks since I’ve last looked. Two main reasons for our purchase of this door was that it operates on batteries, and that there was an available integration with home assistant. What I did not realize at the time was that local only control was not an option.
Now we have had a battery drain issue recently, and I had to solve it by using a 12v power supply on mains power. I have it plugged into a fairly stout UPS for the event of power outage, but I have not yet seen how long it will work with mains off. The first set of batteries lasted somewhere in the neighborhood of 5-7 weeks. The second set lasted only a week. The third set began showing a drain immediately, and by complete luck I found a power supply that works. Hopefully the UPS is big enough to get us through a few days of power outage if necessary.
Still very hopeful that local control can be a legitimate option soon. This is now one of two smart home items that relies on cloud control. The end goal is to have all our smart home on a separate network not connected to the web. The ESP flash and program has my interest piqued, but as of now I do not have enough experience with these micro controllers to mimic the factory functionality and have local control without a cloud. I am anxious to see a resolution for this.
ETA:
I chased a group of 6 dogs off the property yesterday morning, then two hawks around mid day. I have a button in my dashboard to disable the coop door automation so I can keep the birds inside in such cases. I used it yesterday, completely forgetting that we have the door set to open at a late afternoon time. I wish the open and close times could be split to use manual on open and an automatic mode on close, for example. We have ours set so that the door closes via the keypad as a failsafe. To do so, we must have an open time set, which obviously defeats the disable function in HA automation.
Like @pdecat, I continue to have a ‘not great’ connectivity experience with my Autodoor and Smart Fan (more so the Fan)
I have 3 APs (Netgear Orbi 860s) within range of my coop and had noticed that the Smart Fan in particular would often ‘lock on’ to a weaker AP signal and never hop back to the closer (stronger) AP.
So to test the theory, I removed an AP (what would’ve been the 2nd strongest signal) to see if the Autodoor and Fan would stay on the strongest AP signal, and if they did happen to jump to the weaker AP, there should be a very clear difference in strength that should make it clear that they need to connect to the stronger AP.
In short, I have seen increased connection reliability. Not what I would call acceptable yet, but a lot better.
I get the feeling that the Fan in particular, is (1) not handling mesh networks well, and (2) still has issue with network reconnect.
On that last point, the Autodoor does generally seem to successfully reconnect to the WiFi network if it drops off for any reason, while the Fan almost never does, necessitating a complete power off, wait 15 mins, power on, to get it back on the network.
Just for reference, my Autodoor is mains powered, and my closest Wireless AP is about 10m from the coop with no obstructions other than 4mm window glass. The Fan is inside a timber coop (3mm timber) and maybe 0.5m further away from the AP. Both devices are on current firmware (Fan v1.0.7, Autodoor v1.0.54). I run local DNS (AdGuard Home). The devices are all connecting to a dedicated 2.4GHz IoT network using Ch9 (to avoid neighbouring properties using standard default low channels) and 20/40 MHz coexistence enabled.
I’ve spent the past week working on the multi-access point handling within the Autodoor firmware - this is now being tested and validated by our internal QA team, and hopefully should be rolling out shortly. This change should ensure that when multiple access points are available, the control panel connects to the one with the best signal. It will also search for and roam to one with better signal if running on mains, and the signal strength for the current AP is low.
We will hopefully be completing the testing of this and rolling it out in the next week or two. Once we have had this in production for a little while, and not seen any issues with it, we will then look at porting the fix over to the Feeder and Fan. The fan firmware hasn’t been updated with some of the other fixes made for the Autodoor firmware yet, which is likely why you’re seeing better performance with the door than the fan. These will all be brought across together in the next update
Do you mind sharing more details about the UPS setup? Sometimes I travel for several weeks at a time, so I would have peace of mind knowing that my Omlet Door has UPS backup in the event of an outage.
I was stupid enough to connect the Smart Autodoor directly to a 14V LiFePO4 battery without a voltage converter. As a result, component IC3 on the back of the PCB burned out. Unfortunately, I can no longer read the markings on the IC.
I already contacted customer service about this, but they refused to give me any information, claiming that this knowledge is patented. That’s complete nonsense, of course.
Could someone here possibly help me and tell me what kind of IC it is?
Somehow your reply question slipped through the cracks. I simply bought a 400VA 255W UPS from Amazon, plugged it into the wall, and plugged the a/c adapter for the coop door into it.
We are on version 1.055, but our control panel keeps disconnecting from the app on an almost daily basis now and causing the four AA batteries to drain in a matter of days.
Have done multiple factory resets and restart with no luck.
Added in a WiFi extender that is around 5m away from the control panel and the control panel is the only device connected to the WiFi extender.
Any ideas how we can rectify the issues as is starting to make the door unusable. We started using the autodoor last September, but these issues started happening since March
Your best bet would be to contact our customer service team, they'll be able to run through troubleshooting with you to see if it's something they're able to help you to resolve. If they run out of ideas, they can escalate to me and I can have a deeper dive into the data from your device.
Hi Dave, my Autodoor was rock solid since v1.0.55 in May, but around 01:34 AM today (the 16th) it dropped offline and won’t stay connected, untouched. I packet-captured it at my router and I think it’s your end:
Door joins WiFi fine (strong signal, completes DHCP, static IP).
Resolves x107.omlet.co.uk via my local DNS (plain :53), connects to your server on :443 — SYN-ACK comes back fine.
Full TLS handshake completes, then a short app exchange: door sends ~660 B, your server sends ~4.7 KB, both sides ACK.
Then the door sends FIN + RST and tears the connection down (while your server is still retransmitting its last ~300 B), and it drops back to discovery mode. App shows offline.
So it’s not my RF/DNS/network (another sensor in the same coop on the same AP is 100% stable) and it’s not a server outage (your server responds with data). The door reaches you and then aborts the operational handshake at the app layer.
I’ve factory reset the door a few times already today, it once seemed fine at 11:41 AM then dropped again. Other Wifi IoT devices in the same coop connected to the same AP have no issue.
Given it ran two months on v1.0.55 and broke overnight with no changes my end: did the operational API/response change server-side 16th in a way v1.0.55 can’t handle? And is there a firmware update that addresses it? Happy to share the full pcap.
That sounds odd, thanks for the really detailed report. If you’re able to share the .pcap with me, I can dig further and see if I can work out what’s going on there. We’ve not made any changes either firmware or server side for a little while now, so odd this is happening now.
When you say it dropped back to discovery mode, was this sequence of events during the provisioning/setup process, or just in normal operation? It would be odd for it to re-enter discovery mode by itself in normal operation.
If you could send the .pcap to me, my email is (my first name)@omlet.co.uk
So per earlier posts, I have two Smart AutoDoors. Both running on mains. Both with plenty of signal strength.
Both have in recent weeks gone permanently offline. No matter how many times I power cycle them, they remain offline, with random intermittent connectivity.
One just randomly now decided to close, trapping a chicken inside. Not a time of day trigger, light trigger not in use, Home Assistant didn’t do it (it’s lost connectivity), just closed. So I power cycled them again. It then reopened. They’re possibly reacting to queued commands waiting because they are down, and yet they aren’t coming online and acknowledging they have done so… in fact they show last connectivity is yesterday.
But both remain offline in the app and Home Assistant, even though the devices themselves both say they are online at 70%+. Really frustrating how this has suddenly started being unreliable in recent weeks after per the above posts this and has been 10000000% stable since the firmware changes last year.
