Fixing Logitech CircleViews from disconnecting in HomeKit
This solution is not my own, but it is not given out enough and I think it deserves it's own place on the internet for future travelers that tear their hair out over the oft disconnected Logitech CircleView.
After some investigation, it seems the problem stems from a flaky mDNS implementation in the cams firmware. This issue is common among users, and it's often indicated by the accessory disappearing from Bonjour services or showing intermittent availability. HomeKit errs on the side of caution in these cases and calls the device unresponsive, despite it still being available.
Solution
We're going to configure an always-on linux device to replicate the accessories specifications with the lightweight avahi-utils package. If successful, HomeKit will stop deeming the device unresponsive and we'll experience greater reliability. I'm using the Raspberry Pi running OctoPrint for my Prusa Mk3, but I'm sure you could create an LXC or even ESP32 to accomplish this task.
- Install a free app like Discovery or Flame to find the credentials of your Logitech Circle View while it is available. It's most often found here when it is first turned on. Note these for later.

- Install Avahi-Utils on your always-on device
sudo apt-get install avahi-utils
- Use avahi-browse to list _hap._tcp services and identify your accessory with the frequent "no response" issue.
avahi-browse -v -t -l -r -p _hap._tcp
- Add the service to Avahi by modifying the hosts file:
sudo nano /etc/avahi/hosts
In my case it looked like this:
192.168.1.116 LogiCircleView.local
- Create a new service file, name doesn’t matter
sudo nano /etc/avahi/services/hap.service
Follow this format, but substitute your own values found in step 1
<?xml version= "1.0"?> <service-group> <name>LogiCircleView</name> <service protocol="ipv4"> <type>_hap._tcp</type> <host-name>LogiCircleView.local</host-name> <port>49152</port> <txt-record>c#=2</txt-record> <txt-record>ff=1</txt-record> <txt-record>id=10:3D:D6:B1:63:2A</txt-record> <txt-record>md=Circle View Camera</txt-record> <txt-record>pv=1.1</txt-record> <txt-record>s#=3787</txt-record> <txt-record>sf=0</txt-record> <txt-record>ci=17</txt-record> <txt-record>sh=M2Gafw==</txt-record> </service> </service-group>
- Save the file, and the new "duplicate" service will broadcast immediately. Often Discovery will fold the new one inside of the existing one, appearing as if nothing has changed. When the original service disappears, however, HomeKit seamlessly switches to the substitute service.
Since implementing this workaround, I haven't encountered a single "no response" issue with my accessory for several days. It's a simple fix that effectively resolves the connectivity problem.