Some time ago, I discussed a connectivity issue with the gate camera, specifically adding an outdoor wireless AP to strengthen the signal to and from the camera. Since that post (but undocumented, mostly because I am lazy), I upgraded the antenna on that AP to the higher gain somewhat directional patch antenna.

The camera continues to disconnect randomly.

These days, however, it does not reconnect without human intervention and not before I dropped more networking dollars on attempting to address this would I realize that it is probably not actually a networking issue. More on that later, especially since I made it worse.

After just accepting that I was going to have to reconfigure the camera occasionally and tolerate it not working between the time that it goes down and the time I get around to reconfiguring it, I finally decided to drop a few bucks on the networking “solution”.

First, a bit about the power system.

The gate camera is powered by a lawn tractor type of battery, though not directly. It is connected to a Renogy Wanderer solar charge controller. This is a nice little 10 ampere PWM charge controller with a surprisingly long list of features for about $50. The whole thing is charged by a 25 watt solar panel pointing largely south.

The original gate camera was powered by a USB cord and this charge controller was originally chosen because it has a pair of USB A power outlets. I don’t know exactly what happened to it, but that power outlet died after a year or two (I suspect water intrusion) and when I replaced the charge controller, I also replaced that camera because it did not have an external antenna and I hoped that a better antenna would help the connectivity issues. The new camera can be powered either directly on 12VDC or via PoE. No PoE at the gate, so 12VDC it is.

That current gate camera is an Amcrest ASH42-W.

The Renogy Wanderer shows the occasional error code, if one bothers to look at it. I have accidentally shorted the output, resulting in a code E04. Disconnecting the battery and solar panel will reset. Code E01 means that the battery voltage ran low. Apparently there is a feature where the Wandered will shed the load to protect the battery from deep discharge. It is unclear if that is concurrent with the E01 error message, but I suspect it is. There have been times when we have had several days of stormy or cloudy weather and the battery would understandably not be kept charged. The solar panel was not as securely mounted as is needed to be and wind turned it away from the sun once. On rare occasions, we have had snow or ice obscure the panel. Any of these situations will throw an E01 on the display, but when the charger brings the battery voltage back up to a safe threshold, the power output is apparently turned back on automatically. I don’t think the E01 is cleared without some kind of manual intervention. The documentation seems to indicate that a power off restart is required, but I’ve never needed to do that. The E01 just goes away when I mess with the buttons.

One thing that this camera does (badly, in my estimation) is lose it’s WiFi configuration when it loses power. [edit: just today, I have submitted a ticket with Amcrest asking if this is normal for this model camera; I have other WiFi Amcrest cameras that don’t do that] You have to use the Amcrest app on a phone to connect to the camera, authenticate to the camera (which *does* manage to save the admin password, just not the WiFi info. Argh!) and reconnect to the WLAN. One ….. lets call it a characteristic…. of the app is that it shows the available SSIDs and a little symbol indicating the signal strength, but it shows me multiple listings of the same SSID, usually with differing signal strengths. I am guessing that this is somehow picking up the same SSID from different APs. This seems to severely complicate choosing an SSID to connect to.

Still of the (probably misguided) opinion that my camera disconnection problem is caused by poor network connectivity, I finally spring for a mesh capable AP to mount by the gate so that two APs can talk to each other, but the camera will only need to reach the few feet to the nearby AP. Oh, how naive that idea turns out to be.

The Ubiquiti AC Mesh AP is interesting in that it’s only power option is 24V PoE. I had to do a little digging to find something suitable to power it. Specifically, what it needs is a 24V passive PoE injector that is powered by 12 to 48 volts DC. There are gobs of AC powered units, but not many DC powered. In any case, I found one for $20 from Amazon. As for the AP, I generally prefer to order Ubiquiti items directly from Ubiquiti, but the $99 price was the same and Amazon had it, so I got both items next day.

Then I waited two or three days to install them.

The installation of the AC Mesh went as Unifi stuff usually does, pretty pretty much without drama. I plugged it in to my switch in the house first to adopt it and configure it as a mesh child and the garage AP as the mesh parent. Then did a kinda quick and dirty installation at the gate, where it came right up and connected. My phone was able to connect to it immediately. Internet speed test was exactly as good as from inside the house. The mesh speed limit is something like 867 Mbps and my Verizon 5G is only good for about 250 Mbps at best, so plenty of headroom.

Now is when I began facing my first problems with this new setup.

1. The camera would not connect to the network at all. It would connect to my phone for configuration, but then would just continue to blink not connecting to any actual WLAN. This is also where the confusion borne of the multiple duplicate SSIDs makes things even worse.
2. If I turned the transmit power of the AP down to low, the camera might connect to the WLAN, but it would not connect to that AP. It connected to the garage AP, the one it usually connects to when there isn’t one 2 feet away. In related news, detailed below, my other WiFi cameras stubbornly don’t connect to the AP that makes the most sense for them either.
3. If I power down the Gate AP, connect the camera to WLAN, then power up the Gate AP, the camera still doesn’t roam to the Gate AP. By itself, this isn’t surprising because roaming is a fairly sophisticated behavior that a relatively simple network device may not exhibit.
4. Here is the biggie and the thing that finally put me on what is probably the actual issue here. I got the camera connected and the Gate AP on low power and left it overnight, hoping that maybe the camera would reconnect later and choose the better signal. Instead, I found the camera disconnected in the morning and when I started looking, I found the Gate AP to be offline. Hmmm

Hmmmm, indeed. When I went to feed the horses, I went by the gate and looked to verify what I now suspected. Sure enough, the camera and AP were both without power and the Renogy was displaying E01 and it finally got through to my thick head that, probably for this entire time, I have been running the battery down to load shed, the Renogy restores power when the battery is back to a reasonable level and a few days later, when I get around to resetting the camera, always after work when the battery has had all day to be charged back up, I haven’t been suspecting power, but network. So, lets “solve” the problem by adding more power draw to that marginal battery.

Armed with this new-to-me knowledge, I am taking a different approach. I still kinda want to solve the network problem wherein the camera will connect to the Gate AP and enjoy the better bandwidth that should provide, but I need to solve the power problem for sure.

I ordered a budget data logger with the intent to log the voltage on the old battery, specifically to see absolutely if it was actually running down overnight. I also got impatient waiting for the data logger to arrive and also bought a new battery, a deep cycle marine battery, which is arguably a much better match to the purpose than the lawn tractor battery.

Sidebar, kinda: The gate opener has run on a lawn tractor battery for years. The gate opener has been in service since about 2012 or so, , though the design lifetime of that class of battery has been a factor in having to replace it a couple of times during those years. However, the load from the gate opener on it’s battery is quite different. It spends the vast majority of it’s time drawing a few 10’s of milliamperes, then occasionally, a couple of amps for a minute to open and close the gate on demand. This tiny demand is completely within the charging power delivery of the 8 watt solar panel that was available from the gate opener manufacturer. The camera, on the other hand is a continuous 24 hour, 7 day load specified by the manufacturer only as “< 4.8W”, which should be read as “up to 4.8 watts”. In dark conditions, the camera turns on built in infrared illumination, so it makes sense that at night, when there is no solar charging happening, the camera is potentially drawing the most power that it can, probably about 4.8W. In new condition, the lawn tractor battery I had in place *should* be good for about 420 watt-hours, so with just the camera and allowing for some draw/loss in the charge controller, rounded to 5 watts, a freshly charged battery discharged to 50% should be good for 42 or so hours, but I’m getting more like 8 or less. It is apparently not running at full capacity and/or not getting fully recharged. The battery is no longer 420 watt hours and / or the 25 watt panel can’t replenish the watt hours used overnight and eventually battery runs dead enough that the charge controller has to shed the load. The battery gets a chance to catch up enough for the load shed to clear, but a day or two more of use, runs it dead again. Then I added up to 8 more watts of power draw for a wireless access point.

I really should put the old battery back in and log the battery for a week or two to verify this theory, which is a thought that is out of sequence here and will make more sense after the next couple of paragraphs. Sorry. Editor’s prerogative.

I installed the new battery last night. With the Gate AP operational, I could not get the camera to connect and I got fed up with trying, so I left them as is overnight.

The datalogger was delivered late last night, about 9PM (Amazon… amiright?). I was already comfy and didn’t bother fetching the box. So, of course, it started raining in the predawn hours. The box was soaked to disintegration by morning, but the logger was fine.

It’s a Triplett VDL48. Cute little thing. Kinda weird in a couple of ways. The manual is close to useless. It took some research to determine that you must use their proprietary app to set the logging parameters, apparently each time it’s used. It does nothing particularly useful right out of the box. However, once I knew that I needed the software to make it go, it was a pretty simple matter to set it up. I set it to log in 10 second increments, started it logging then braved the rain to attach it to the battery.

UGH! I bought a new battery box for the new battery, one with room for the battery and both the Renogy and the PoE injector. Battery boxes are designed to vent hydrogen and batteries themselves are largely waterproof. So the tiny vents molded into the lid of the battery box are normally not a problem, but I have electronic equipment inside my battery box and I discovered that it was getting wet in the rain from these vents. I had discovered this previously in the other battery box and had addressed them with a piece of plastic and epoxy. Today, and needed something more expedient, so I grabbed a slightly nasty towel and a roll of electrical tape from the garage and returned to the gate. I dried off the vent area and used two hastily ripped strips of tape to cover each vent area, as well as at least partly patting the Renogy dry. It was directly under one of the vents. I do have a spare, just in case.

So, as of about 4:30 or so this afternoon, the battery voltage is logging to the Triplett toy. It was 12.37 volts when connected. Also, with the rainy weather, the Renogy reported the PV voltage (photovoltaic; the solar panel input) at 10.something, so less than required to actively charge the battery. It would be awesome to have a two channel logger. I don’t care enough to buy two at this point. It’s 9:50 PM as I edit this paragraph and the Gate AP is still up, so the battery has not run down to load shed in the rainy dark.

Earlier, I mentioned an irritation that I also need to address. This is a problem that has come up with several devices in my network. In short, there are a number of WiFi devices that insist on connecting to APs that are not only not nearby but are often the least nearby AP that they could possibly select.

I have a AcuRite weather station. The sensor unit outside communicates with the indoor unit via 420-something MHz RF, but the indoor unit does WiFi and via WiFi, can connect to the Weather Underground network to post my collected weather details online. This WiFi happens to be using an Espressif ESP32 MCU, which for reasons I can only guess at, won’t connect to AP in the ceiling of the room it is *in*, a mere 10-12 feet away, but rather it will connect only to the AP in a hallway on the other side of the house, where it enjoys one of the weakest received signals in the house.

Similarly, I have another WiFi camera, a different model than than the Gate Camera, but the same Amcrest brand. It is deployed in our barn, set to monitor the water trough for the horses. It is about 30 feet from the AP that is in my workshop in the barn. Instead, it will only connect to an AP in the house, about 80 feet away and through a number of walls.

I have two EPS8266 based homebrew temperature sensors in the garage. One has a probe stuck through the wall to the outside. The other has an internal temperature sensor, but also a counter input that reads a water flow meter. Both of these are 10-20 feet from the Garage AP. On connects only the the Hallway AP in the house, which is at least arguably equal linear distance, though with several extra walls and lots of furniture for interference. The other is literally 10 feet beneath the Garage AP, but connects instead to the Kitchen AP.

All of these exasperating devices at least have one thing in common in that they are less sophisticated network devices, at least as compared to smart phones, laptop computers, etc. They may be making their choice based on the lowest numeric MAC address or some other equally arbitrary but mathematically simple calculation.

Thus far, no amount of Googling has revealed a solution to this particular problem.