Fitting IP cameras to replace the expensive Amazon Blink toys

I've had several Blink cameras over the past 5 years to keep an eye on various properties and alert me to unexpected rovers. Initially this setup was used to keep an eye on my late mother's home while it remained unoccupied ahead of being sold. Then I installed them at our property following the theft of some ladders from outside the workshop (where arguably I shouldn't have left them) and then finally I installed a set at my mother in laws to keep an eye on comings and goings. She's moved out now, so I have no further need for them

The Blink system is functional but pretty basic and has some unwanted features:

• Connection is by wifi, so can be rather patchy and may throttle the bandwidth.
• The video clips are held on the Amazon cloud. While this means it's easy to access from anywhere on the internet, you have to pay for their service - currently £80 a year.
• Although you can choose to operate the system without using their cloud service (storing clips to a local USB storage device), it makes accessing them remotely rather painful.
• The cameras are battery powered and need lithium AA batteries which aren't cheap.
• Being battery powered, you can only see clips that have been triggered by the camera's inbuilt motion detection. There's no possibility of continuously streamed video.
• Recently, Blink have been offering a basic "AI" enhancement that does some rudimentary identification of moving subjects. Of course this would cost you extra dosh on top of the basic £80 subscription, taking you up to £150 a year - per site.
• Being a closed, proprietary system, you have very limited ability to modify or enhance the capabilities of the system.

So, one of the benefits of installing Home Assistant is the option to integrate IP cameras into the existing setup. And specifically for these devices, there are some pretty powerful extensions that enable AI-assisted identification of subjects / objects in the field of view, such as the Frigate Network Video Recorder (NVR).

My Raspberry Pi 5 is powerful enough for most of the tasks I expect of it, otherwise I'd need to have fitted an actual PC. However, the AI object detection function is quite intensive and would most likely overcome the RPi, so I've added a Coral USB accelerator TPU that offloads that burden. It just plugs in to a USB3 port on the RPi and like most of these Home Assistant extensions, the installation is very quick and seamless.

Firstly, I've installed an Empiretech IPC-T28IR-AS-S3 3.6mm dome camera which requires a PoE connection for power and comms. This has excellent low light sensitivity and good HD 8MP resolution (3840 × 2160). I've fitted it with its own 128GB microSD, so it has its own storage on top of the NVR system.

The mounting base houses a waterproof ethernet connection and a (redundant) power jack.

The cable has a polythene outer coat for outdoor use. I blasted a hole through the wall next to the fibre cable. Looks almost decent by my standards:

I've got Claude Code installed in the RPi itself, which is dead handy - I can literally just ask it to install stuff and it will do so, with CLI instructions I'd never stand a hope in hell of understanding, sent directly to the various peripherals, then set up the various options within Home Assistant and Frigate (in this case) to customise it to my liking and situation. It sorted out this camera config in no time, rotating the video to account for the orientation of my setup and turning off black and white night vision.

As for the Blink doorbell, it uses the same infrastructure - with the added feature of a door chime of course. It can take its power from an existing traditional (24Vac?) bell circuit but relies on wifi for the video feed. 

I've replaced it with a Reolink PoE doorbell, which means I need to run another ethernet cable from the front door to the Home Assistant system under the stairs. I connected the bell supply to it, so it may continue to work even if the Frigate system goes down.

This has a 5MP (2K) sensor, microphone and speaker, if you like that sort of thing. Although Reolink offer an app, this device integrates nicely into Frigate / HA, so once set up in the Reolink app, everything is handled by Frigate. And of course, the resident Claude Code agent actually does most of the work - my kind of setup!

The view from up there is pretty good. And the low light sensitivity is good enough that it doesn't need to revert to black and white night vision, largely due to the street light directly outside our house.

On the face of it, the doorbell doesn't show a lot more than the dome camera but it's there for a different reason and has lower resolution.

I've set boundaries for the main camera. The object detection is within the camera software (rather than Frigate) and seems to determine where people's feet are and use that to determine if they are within the boundary. It seems to work OK now, ignoring pedestrians and traffic on the road and pavement outside our driveway.

I've enabled facial recognition in Frigate, so now it will begin to build up a collection of recognised faces and objects as they are encountered. I will then be able to go in later on and name them. Then I will be able to set alerts eg when The Domestic Manager has returned home, a stranger is on the driveway or the neighbour's cat has come into our front garden. This object recognition is done by Frigate using the power and might of the Coral TPU.

Bench testing the TIG button torch controller - there's life in it!

Finally, after about a week of feeling shit, the balance between moping about with a snotty / stuffy head cold on the one hand and moping about doing nothing has shifted to the point where I just need to get on and do something, anything, before I lose the plot. 

I've been looking forward to testing this TIG button control for the Arc Captain TIG welder and it looks as if today's the day. It's tempting just to fit it to the torch, plug it in and see if it works. However, it would be a good idea to test it out on the bench first. It's quite possible that it won't so well on the torch with the HF start circuit active and/or the arc running, in which case, it would be good to know if/that the basic circuit itself actually works as intended beforehand.

So, out with the bench PSU and a DVM:

This is the smaller of the 2 PSRs I got from Amazon, which claims to be good for 3g - 500g 

First signs are encouraging. Pressing the PSR pad causes the LED to light up and the THRESH pot changes the level at which this occurs. Similarly, applying a fixed load (weight) to the PSR and twiddling the SENS pot varies the output voltage. So, on the face of it we have a functioning circuit. Of course, that may change when there's a welder arcing away in the background - but one step at a time etc.

If anything, the required pressure feels a bit excessive but I'm still needing to design a housing for the circuit and some form of finger pad that will apply the pressure to the PSR element. I may finesse the circuit values 

This is the circuit that does the gain control and level shifting:

But for now, I think I'm in the right ballpark, so I'll leave it for now.

The main ball ache is the fact that the TIG welder doesn't actually respond to inputs from the torch or pedal controls. I've been communicating with the Arc Captain team for some weeks now but so far I'm far from seeing any glimpse of a cigar. Will I be able to get a replacement out of them? I'd like to be able to control the arc from the torch as it is - but also how am I to prove out this TIG button if the welder doesn't take any notice of the input?

I may need to establish whether the TIG button circuit continues to behave when it's fitted to the torch body and the arc (and HF) are active. That must be quite a test for any torch-mounted circuit on a good day.

So, as a first test, I seem to be seeing signs of success. Let's see what happens next, when I install it on the machine and fire up the arc....

PCBA production at JLCPCB - unboxing the delivered samples

Friday 23rd - production started:

Nice thing about JLCPCB (and presumably PCBway) is that you can follow your job as it progresses through the manufacturing steps. By Sunday, the PCB seemed to be pretty much complete:

And the PCBA assembly looking primed and waiting for the PCBs to arrive:

Finally on Sunday evening, the PCBs were sent out:

By Monday evening, the PCBA assembly was done and dusted:

And I could see the shipment had been started:

Ordered 10pm @ 21st Oct, expected 30th Oct by end of day ie 9 days from placing the order - including full PCBA assembly.

Friday 30th update:

Arrived yesterday early afternoon, around 2pm. That's actually a shade under 8 days from placing the order and receiving them through the door - not bad, considering that includes PCB fab, compt procurement and PCBA assembly. 

Excitement builds...

A little bubblewrap sausage....

....containing 5 little PCBAs

They look about right.

I need to craft up a plastic cover that also implements the PSR sensor but at least it plugs in and fits within the cavity:

Here are its cousins, the ones without feelings. I increased the board outline but stayed within the torch cavity dimensions:

I'm dying to test the functions, to see if it works OK. But I also feel as if I'm dying from a nasty dose of man flu. Currently enjoying profound deafness in left ear, wonderful rhinitis and seem to be flirting with a loss of voice. This may need to wait another day or two. I have a few jobs to do such as painting internal woodwork, fitting outdoor IP cameras (up ladders) and running some Cat6 cables but they aren't about to happen quite yet.....

Cat 6 cable faff-on

Terminating ethernet cables isn't fun at the best of times in my experience but when you need to run a long cable outside, starting from a reel of bulk cable, there's not a lot of choice - unless you plan to buy a standard (long) length and coil the excess somewhere. And even then, unless you want to blast a massive hole in the wall, you'd need to terminate at least one end of the cable after routing it.

I'm hoping to receive an IP cam in around a week from now. This is powered over ethernet (PoE), so needs a cable to run from the router room under the stairs, along the outside wall and up to the planned position above the front door, where it can spot callers and sneakers entering through the front gates.

So, I have a reel of Cat 6 (shielded UTP) that claims to be good for outdoor use. Not sure what the outer covering is but it could be polythene or PVC. The black colour probably gives it some UV resistance, although time will tell on that front.

Recently I had another partial tidyup in the garage /workshop area. The main result of that isn't a noticeable increase in tidiness or clear workspace. However, I recall tidying away the ethernet crimp tool and cable tester. There's only so long I can be arsed to search high and low for it, so I had to get another one. This one actually looks a bit better than the mislaid one, so some good may come from it.

But of course, it isn't obvious that this is going to make the task of threading the individual wires through the shells themselves any easier, which is where the challenge generally lies. 

It seems to me that I may as well terminate the end of the reel, ready for the camera when it arrives. And in fact I may as well terminate both ends - I can then have a choice of 2. Or I have a spare if I screw one up, more likely.

First problem - this cable is too large to fit through the cable relief shell. Perhaps this is due to the cable being allegedly suitable for outdoor use. Not certain I need this in the first place but I may as well have a go at bodging it on before dismissing it.

The cable OD is around 7.3mm. So reaming it out with a 7.3mm drill might help.

It just about goes on here. You need to do this before crimping the shell on, obvs.

This is the trickly bit. The normal advice is to strip back 20mm but that makes poking all 8 wires into the correct holes almost impossible. Instead, I found that stripping back 30-40mm gave me more of a fighting chance. This way, it's a lot easier to start the bare copper wires, rather than hope for all 8 of them to magic their way into the correct positions in the shell. The excess gets cut off by the tool when it crimps the shell. These shells are called "pass through", since they allow the individual wires to, well, pass right through like this.

Like this. Although The Stupid Fat Bloke forgot to push the cable relief into the shell before crimping. Doh. If you don't do that, you might as well cut it off unless you want to start all over again. I cut the relief off.

Have another go, this time at the other end of the reel:

So this one has the cable relief fitted as recommended. I'm not sure that's of any use anyway, as this will be a static installation and the connection will be sealed inside a little junction box within the camera mount. 

Let's call it practice for when I run the cable into the house and have to terminate it for real. 

It would be handy at this stage to use the cable tester but, given that it was sitting coiled up on my bench, it was simple enough to beep it through. Hopefully the tester will get itself found within the coming week or so. If not, I'll just have to be very careful to get the wires into the shell correctly and ultimately find out if the camera likes what it is connected up with.

Oven temperature logger up and running

The MAX31856 thermocouple breakout board (shield / hat / cape??) thing arrived to day. Or more accurately, a MAX31855 board arrived, as the tossers behind that particular Amazon storefront can't describe their product correctly. NVM, the difference isn't an issue in this situation:

The thermocouple is a K type, so that's OK. and I'm measuring the temperature of a domestic oven, so the reduced resolution really isn't a problem. And the 50/60Hz filtering isn't going to be an issue I don't expect. So apart from requiring a slightly different firmware in the ESP32, it's not much of a change. You can get Claude to reflash the ESP32 over wifi if you need to change the firmware.

Let's connect up the MAX with the ESP32. Here's the wiring table:

Here are the 2 boards. I'm just going to use a breadboard, so positioning the MAX board upside down with the pins downwards orientates it in a similar way to how it will be in the implementation. 

That worked, as did the Home Assistant dashboard. With the original 1 minute updates and the broad limits for the Y axis, the resolution is bit crude. There's clearly some cycling going on. That's perhaps not a surprise, as the temperature controllers in these things are hysteretic with a fairly low switching frequency. It has little impact on the average temperature and saves the relay contacts.

But the MAX can acquire and report at 10Hz, so I can find a middle ground between 1 minute and 100ms, like once per 10 seconds. I switched in the middle of this record and now we can see the oscillatory nature of the temperature "control" as a result of the on-off control scheme. 

The cycle time is just shy of 2 minutes at this condition. Obvs I had to ask Claude (now living within the Home Assistant annals of the Raspberry Pi) to capture some values and report. This is with the oven set to 180C and the thermocouple near the front, next to the door. Obvs if I placed it right next to the fan heating element, it would read a higher temp. The cycle time seems to be around 110 seconds, which will be dependent on the rate of heat loss (ie kW lost through the insulation) and will increase as the set temp is raised.

And here's what happens when the temperature is turned down from 180C to 130C:

And sure enough, the cycle time increases to something like 3-4 minutes. There's a lot of residual heat stored in the oven and the casserole. I expect it will be a bit shorter once the system has found a longer term equilibrium.

Now we just have to keep an eye on things over the next few days and weeks. This uncertainty over the temperature control needs to be resolved before we go near it with an expensive turkey in 2 months' time....

Finishing off the PCBA package and placing the order with JLCPCB

Well that's all done and dusted now, design-wise. 

Here's some detail:

Part of the costed BOM:

Placement review:

Assembly cost breakdown:

Where you could cut cost:

• Extended-part fees ($15.45): the biggest lever. Each of the 5 Extended types costs $3.09. Only the 10 µF capacitor has a cheap Basic swap, and it's X5R, which your X7R rule excludes, so I've kept all five.
• JLCONE desktop app: JLCPCB advertises $1–20 off per order through it.
• Quantity: going above 5 boards adds mostly parts cost; the setup, stencil and part fees are one-off.

I've kept it as-is, although there's a $9 discount coupon that was applied before payment, taking it down to $81.70. That could have been $66 if I'd buggered about with the extended parts - but I have a life to live and can't be arsed to mess about any further.

So, despite having to eat, drink, bake (stollen), diagnose (oven), code (ESP32 oven monitor), watch telly, write blog notes, take a crap, drink loads of tea etc, I've gone from tasking Adom AI to placing an order for 5 assembled PCBAs in the space of one afternoon/ evening. 

Claude tells me that the breakdown of time looks like this:

We started at 15:43 UK time today (14:43 UTC, Wednesday 21 October), when you pasted the brief. It's now 21:42, so about 6 hours of elapsed time.

My own working time was about 3½ hours (206 minutes, by AI Flow's run ledger). The rest was gaps of 15 minutes or more, mostly while you were away or reviewing, which the ledger leaves out.

That figure is approximate in both directions:

• Possible overcount: I didn't mark each of your follow-up messages in the ledger, and it shows a few open "follow-up" rows that may slightly overlap.
• Undercount: this last stretch (the quote, the order and the coupons) came after its last entry, and isn't included.

Roughly where the time went:

Phase	Approx. time
Circuit design, sensor analysis, part selection with live LCSC stock, schematic rev A	30 min
Your answers: ratiometric output, PhotoMOS, outline and fingers (revs B and C)	25 min
Layout: placement, routing, ground plane, silkscreen, DRC	1½ h
Simulation (found and fixed the difference-amp error), Fields current/thermal	40 min
JLCPCB export, footprint fixes, quote and order set-up	45 min

You'd have to say that's actually pretty impressive. Let's place the order once it's been reviewed (by someone at JLCPCB) and then see what turns up here - ETA around a week to my door. I can observe the progress as they pass through the manufacturing system, which is pretty impressive.

22:55 - order placed $81.70 / £61 for 5 fully assembled PCBAs (with flying probe ICT) including carriage and tax/duty....

Remote oven temperature logger using ESP32 and Home Assistant using ESPHome

Yes, the oven seems to be playing up. Luckily it's just gone out of (5 year) warranty, so it's down to me to diagnose and fix it. It cost £400 5 years ago, so is close to worthless ie it would grieve my Scottish-bloodied Yorkshireness to pay for a Samsung "engineer" to come out a fix it, apart from being a writeoff from a financial point of view.

So although I've currently got a process (PID) controller and K type thermocouple monitoring the temperature, this only gives me live readings, by eye, when I'm in the kitchen. Obvs it would be more helpful to be able to monitor the temperature remotely and log it against time. So, a remote sensor connected to Home Assistant might sound like the right solution.

I've got a variety of ESP32 modules, mainly C3 and S3 flavours. These have USB-C for power and both wifi and Bluetooth, so I can simply(?) power them up and connect them into Home Assistant. Then I can create a record of the temperature against time.

I found a couple of ESP32-S3-Zero (thumbnail size), so I'll use one of them. To acquire the temperature, I can connect a MAX31856 breakout board ("shield"?) using SPI and 

	MAX31855 (ADA269)	MAX31856 (ADA3263)
Thermocouple types	K only	K, J, N, R, S, T, E, B
Resolution	0.25°C	~0.008°C
Mains noise filter	No	Yes, selectable 50/60 Hz
Configuration	None, read-only	Thermocouple type, filter, fault thresholds
SPI wiring	3 data wires (MISO, CLK, CS)	4 data wires (adds MOSI)

I've got an clone of the Adafruit ADA3263 coming tomorrow, so let's get the ESP32 bit set up in anticipation.

There's a rather handy open source project that converts a YAML config into a compiled firmware and flashes it onto the ESP32 - ESPHome. There's also an integration for it in Home Assistant. Once you've flashed the ESP32, it shows up as "new device discovered" and you can then use it as a sensor in Home Assistant like any other HA sensor.

This is pretty tasty - no need to bugger about with Arduino IDE, Espressif-IDE or Visual Code Studio / Claude Code. It configures your YAML from dialog prompts (unless you are some sort of power user), then does the rest. You don't even need to edit the YAML code to show the SSID, password etc for your wifi network. Nice.

To customise the YAML for temperature logging, I got Claude to come up with the required added content:

esp32:

  board: esp32-s3-devkitc-1

  flash_size: 4MB

  framework:

    type: esp-idf

captive_portal:

spi:

  clk_pin: GPIO4

  miso_pin: GPIO5

  mosi_pin: GPIO6

sensor:

  - platform: max31856

    name: "Oven Temperature"

    cs_pin: GPIO7

    mains_filter: 50Hz

    update_interval: 10s

  - platform: wifi_signal

    name: "Oven Monitor WiFi Signal"

    update_interval: 60s

As ever, I had to keep the boot button pressed while plugging the EP32-S3 into the USB port for it to be recognised. Then it flashed ok and started running.

Unplugging it and powering it up from any USB-C supply gets it up and running, connected to HA over wifi. Of course, without the thermocouple board connected up, it reports a constant 0C.

In HA, I want a dashboard that shows the oven temp, so I went over to the embedded Claude agent within HA (ie living on the Raspberry Pi) and asked:

"i've just added oven-monitor. i want to use it to log oven temperature every minute and show the trend on a graph. range 20-250c, timescale - the last 20 mins. the thermocouple isn't connected yet but i will get it tomorrow. set this up so it's ready and working."

And here it is:

Looks good to me. I can mess with the axis limits later. 

Right, now wait for the board to arrive tomorrow. Then connect it up:

MAX31856	S3-Zero
VIN	3V3
GND	GND
SCK	GPIO4
SDO	GPIO5
SDI	GPIO6
CS	GPIO7

Avoid GPIO0 (boot button), GPIO21 (the onboard RGB LED) and GPIO19/20 (USB).

TIG torch PCBA kicked off in Adom AI....

Plenty of distractions at the moment - this year's Xmas cake, Xmas puddie and stollen weren't going to bake themselves. And the Samsung dual oven is now a month past its 5 year warranty, so losing control of the temperature was rather concerning and cost me my Xmas cake, so needed fixing. It appears to be an intermittent issue (it resolved itself before I could reach for the tools), so will need to be kept an eye on - or in my case a thermocouple and process controller (aka display).

With that now behind for the moment and without any more messing about, let's get started.

And we're off....

Let's see what he/she/it comes up with.

Various Claude questions:

I've built the edge fingers in KiCad on your DXF outline. Please check the drawing above before I start placement.

• Drawing: C:\Users\murra\adom-lib\tig-psr\outline-fingers.png
• KiCad preview board: ...\tig-psr\kicad\outline-preview.kicad_pcb

Fingers as built:

• Count, pitch and width: 5 fingers at 2.0 mm pitch, 1.3 mm wide, leaving 0.7 mm gaps.
• Length: 6.2 mm, from 0.3 mm in from the board edge to 0.5 mm short of the step out to the full 20.5 mm body.
• Edge clearances: 0.3 mm to the mating edge (JLCPCB's copper-to-routed-edge minimum). The outer fingers sit 0.35 mm from the tab's sides.
• Finish: HASL, solder mask open over the fingers, no solder paste.

Please confirm:

1. Finger length: I assumed 6.2 mm, filling the tab, since you didn't give a length. Is that right?
2. Sides: fingers on the top only? Copies on the bottom would contact either face of the socket, but they add bottom-side copper.
3. Pin order: the question marks in the drawing are my provisional order, 1 = +5V through 5 = GND, counting from the top as you look at the component side. What order does the welder's socket use?
4. Relay: TLP172A PhotoMOS (my recommendation), SIP-1A05 reed, or keep the HFD4/3? The board is small (772 mm²), so the 4 × 7 mm SMD PhotoMOS helps the fit a lot.
5. PSR: where does the sensor's tail land, at what pin spacing, and on which edge? Its two crimped pins look like about 2.5 mm pitch.
6. Corners: square as drawn, or rounded?

• The TLP172A opto SSR sounds like a reasonable suggestion. I know from my measurements and partial reverse engineering that the current and voltage needed to control the welder are very low. It's not actuating a remote relay inside the machine - at least not on mine.
• The PSR will be off-board, connected via 2 through holes, with pitch shown in the datasheet provided. I will incorporate it into the plastic  cover component. NB: Omit it from the sourcing BOM.
• Rounded PCB corners would be fine.
• NB: the fingers make contact on the "bottom" side of the PCBA but might as well use both sides.
• HASL will be fine for the fingers. Proper gold plating is not needed and even ENIG (basically anti-tarnish, nothing more) is unnecessary and would cost extra.

I'm going to need a 3D model of the final PCBA so that I can create the cover that will close the torch handle when this is fitted. For this I'm going to have to recreate the current torch handle in Fusion. And while the near-clone I acquired from Ali Express is very similar, the 2 control assemblies are not quite interchangeable so I will have to fiddle about with the final design so that it is compatible with both handles. At least the PCBs are almost identical in outline ie interchangeable (that's A Good Thing).

Here's a first cut of the schematic:

Doesn't look too silly. As before, the "reference" voltage is taken from the supply, as there's no deadly accuracy required and ultimately it's a ratiometric controller - most are simply potentiometers. Lots of HF and low pass filtering, which is good. I expect the expensive compts will be the SSR and the quad opamp, possibly the mini pots.

• The TLV9104 opamps are normally around £1 each, as these are low power, rail-to-rail devices. 
• The TLP172A opto SSRs are also around £1 each
• The Bourns pots are around £1.50 each
• ...doubtless I've missed something really expensive?

Top side copper and courtyard:

Bottom side copper (no compts fitted there):

The silk screen is a mess but there hasn't been any attempt to clean it up yet

And the 3D PCB view (with the silk screen turned off!). The SSR doesn't yet have a 3D footprint, so is missing (top left):

It's coming along. Claude says:

The schematic, the PCB editor and the 3D viewer are all open in KiCad on your PC. The project is in C:\Users\murra\adom-lib\tig-psr\kicad\.

This is a work-in-progress layout and is not ready to fabricate yet:

• Routing: every signal is connected and the board is clean against JLCPCB's 2-layer rules apart from silkscreen. KiCad's status bar shows 5 unrouted items, all ground. Bottom-side tracks split the GND plane into a few islands that the stitching vias don't yet join. Fixing that is next, by keeping more signals off the bottom layer.
• Silkscreen: not done yet. The value text overlapping parts and the edge in the 2D view will be cleaned up to JLCPCB minimums, with reference designators only.
• 3D: U2 (the TLP172A) shows no body because its footprint has no 3D model. I'll fix that.

Changes since rev C (I'll send you a revised schematic PDF with the layout):

• 0402 passives: most resistors and small capacitors are now 0402, all JLCPCB Basic parts. 0603 didn't fit the 42 × 20.5 mm board, which held 53 of the 72 parts.
  • Values changed to match what's stocked: the difference amp is 22 k / 47 k with 220 nF (gain 2.14 and a 15 Hz pole, trimmed out by RV1), hysteresis is 22 k / 1 M, and the excitation divider is 47 k / 12 k.
• Fingers: double-sided per your note, with each top/bottom pair joined by a plated hole at the inner end. The GND pour is kept off the finger tab.
• Test pads: 10 dedicated 0.8 mm pads for GND, +5V, VREF, VM, PSR, V1, AMP_OUT, VTH, CMP_OUT and SSR_K. Every other net can be probed at an exposed top-side component pad, which your "bare track / test point" note allows.
• Indicator LED: now driven from the comparator output through 470 Ω. That freed routing space next to the PhotoMOS.
• Net names: DRAIN, GATE and VOUT_INT are now SSR_K, Q1_G and AMP_OUT. AI Flow's router treats nets named like MOSFET or power nets differently, and its saved plans had been dropping DRAIN and VOUT_INT.

The layout follows your concept: fingers on the left, the PhotoMOS by fingers 1–2, supply input by fingers 4–5, the op-amp in the middle, both trimmers and the PSR pads at the narrow end.

Next steps?

The next steps, in order:

1. Ground plane. Fix the five unrouted GND items by keeping signals off the bottom layer, so the bottom stays an almost unbroken plane, which matters near the arc. Then 0 unrouted and a clean DRC against the JLCPCB rules.
2. Layout review. Check the key loops by eye: the sensor input path to U1, op-amp decoupling, the supply filter at fingers 4–5, and keeping the enable traces and their filter away from the analogue nets.
3. 3D models. Add the missing PhotoMOS (U2) body and check every part sits correctly in KiCad's 3D view.
4. Silkscreen. Top side only, at JLCPCB's minimum text size: reference designators, trimmer labels (SENS / THRESH with a direction arrow), finger names, test-pad names, and a board title.
5. Schematic and BOM refresh. A new schematic PDF with the 0402 values, a test-point map, and a BOM rechecked against live LCSC stock.
6. Simulation. A quick SPICE check of the analogue chain on the final values: linearity, threshold, hysteresis, and the 4.5–5.5 V supply range.
7. Manufacturing files.
   • Gerbers and drill files.
   • The JLCPCB BOM and pick-and-place file, with each part's rotation checked against JLCPCB's footprints. The PSR, edge fingers and test pads stay out of both files.
   • A final DRC on the exported set.
8. Your review. You get the board in KiCad plus a summary before anything goes to JLCPCB. I'd also run their online DFM check and placement preview, but uploading and ordering need your JLCPCB login and your go-ahead.

I'll start on the ground plane now unless you want to change anything first.

And within 10 mins or so, those final actions have been completed, resulting in this update. Silk screen tidied up, SSR 3D model showing:

I've run out of tokens for now. It rests in 2 hours, so just time to eat....