Build Guide Overview

flux

0:38

Assessing response options.

Based on the specs you pasted, I think your build has a reasonable chance of becoming a working bench prototype, but I would not expect it to work correctly on the first build without debugging.
My honest assessment is:
  • As a low-voltage bench prototype: probably yes, with iteration
  • As a mains-connected protection system that works reliably and safely end-to-end: not yet proven
Why I think it can work as a prototype
The docs are detailed enough to define a real build:
  • clear controller choice: Raspberry Pi 4
  • concrete ADC interface: MCP3008-I/P
  • defined current sensing approach using multi-tap CTs
  • defined voltage sensing using ZMPT101B
  • defined relay/output mapping
  • defined LCD and dashboard behavior
  • defined software module structure
  • defined burden resistor values and filter capacitors
  • defined DIP switch logic
  • defined startup, test, and service flow
That is enough to build a proof-of-concept system.
Why I do not think it is guaranteed to “just work”
There are still several risk areas.
1. The documentation is internally inconsistent
Across the versions you pasted, important things changed:
  • buzzer pin changed
  • relay pin assignments changed
  • burden resistor values changed
  • software architecture changed
  • AI implementation changed
  • relay behavior descriptions conflict in places
That usually means the design is still evolving, not frozen.
2. The software looks more like an ambitious prototype stack than a hardened product
The software includes:
  • monitoring
  • AI scoring
  • LCD
  • dashboard
  • cloud notifications
  • federated learning
  • auto-restoration
That is a lot of moving parts for a first build. The most likely outcome is:
  • hardware basics work first
  • monitoring works next
  • dashboard/LCD mostly work
  • relay logic needs debugging
  • AI thresholds and restoration logic need tuning
3. The analog sensing chain will almost certainly need calibration
Even with the specified resistor values, the current and voltage measurements will depend on:
  • exact CT characteristics
  • exact ZMPT101B module gain
  • burden resistor tolerance
  • ADC reference accuracy
  • biasing correctness
  • noise pickup from enclosure wiring
So I would expect:
  • voltage scaling adjustment
  • current scaling adjustment
  • threshold tuning
  • filtering tweaks
4. The relay side is the biggest practical uncertainty
Your latest guide uses an 8-channel relay module instead of discrete SSR drivers in the earlier version. That is much easier for prototyping, but still leaves open questions:
  • does the module reliably accept 3.3 V GPIO as HIGH?
  • does it default to the safe state at Pi boot?
  • does the wiring logic match your software assumptions?
  • are the controlled loads/contactors wired exactly as the code assumes?
That part often causes first-build problems.
5. The AI claims are much more uncertain than the hardware claims
The build can likely become a working monitoring and control prototype before it becomes a working AI cyber-physical threat detector.
I would trust these in this order:
  1. Raspberry Pi 4 boots and runs code
  2. MCP3008-I/P reads channels
  3. 16x2 character LCD with I2C backpack works
  4. LEDs and Active Piezo Buzzer 5V work
  5. relay channels switch
  6. CT/voltage readings become believable
  7. dashboard works
  8. restoration logic works
  9. AI threat detection works well
The last 2 to 3 are the least certain.
My bottom-line answer If you build it exactly as written, will it power up and do something useful?
Probably yes.
Will it immediately be a fully reliable working Volta Guard system?
Probably no.
Is it realistic as a prototype?
Yes.
Is it realistic as a first-pass production-safe electrical protection product?
No.
Best expectation to set
Expect this sequence:
  • Phase 1: hardware powers on
  • Phase 2: LCD, GPIO, relay module, and ADC communications work
  • Phase 3: voltage/current readings need calibration
  • Phase 4: dashboard and logging stabilize
  • Phase 5: relay logic and restoration behavior get debugged
  • Phase 6: AI and thresholds need tuning from real data
What I would call it today
I would call it a:
  • credible prototype design
  • not yet a proven finished prototype
  • definitely not yet a proven field-safe autonomous protection system
My recommendation
Build it in this order, and stop after each stage:
  1. Raspberry Pi 4 + software only
  2. 16x2 character LCD with I2C backpack + LEDs + Active Piezo Buzzer 5V
  3. MCP3008-I/P + fake/test analog inputs
  4. ZMPT101B and CT channels on the bench
  5. 8-channel relay module logic testing with safe loads only
  6. only then panel-side integration with an electrician
If you want, I can next give you a pass/fail prototype readiness checklist with three columns:
  • likely works
  • needs bench validation
  • high-risk / redesign recommended
Prototype checklist
Bench validation items
High-risk redesigns
11 days

Ready.

Sign up to send

To get started, talk to Flux or create a New Document.

Documents

    Documents are markdown text files which describe project goals, capture details, or even simulation outputs.

    Assets

    spst-switch-open.svg

    spst-switch-open.svg

    spst-switch-openDefault
    6x6mm switch-thumb.png

    6x6mm switch-thumb.png

    6x6mm switch-thumbThumbnail

    6x6mm micro tactile switch

    6x6mm micro tactile switch thumbnail
    Micro Tactile Switch Momentary Tact DIP Switch 2Pin 6 X 6mm Micro Touch Push Button Switch #Commonpartlibrary #switch #THT #Tactile-switch #2pin

    Properties

    Switch

    SW

    shopee.ph/20Pcs-Micro-Tactile-Switch-Momentary-Tact-DIP-Switch-2Pin-6-X-6mm-Micro-Touch-Push-Button-Switch-High-5mm-6mm-7mm-8mm-9mm-i.1018846655.22773354064?sp_atk=2b55ff5c-bbfc-4967-b7e3-adb8c93c34e2&xptdk=2b55ff5c-bbfc-4967-b7e3-adb8c93c34e2&is_from_login=true

    Pricing & Availability

    Distributor

    Qty 1

    Controls