Prizm-MeterNet — Technical Overview

01 — Philosophy

Three Principles.
One New Paradigm.

Prizm is not a new meter. It is a new theory of relativity for the utility industry — a fundamental rethink of what it means to build an information system for physical infrastructure.

I

Radical Rupture.
Information System, Not Metering.

We do not propose new meters. We do not require replacing or upgrading existing equipment. We consider ourselves part of information technology, not the energy or utility industry in the traditional sense.

The key shift: we turn any existing device — even the most "cast-iron" analog meter — into a full participant of a unified information system. We replace the outdated concepts of "meter" and "controller" with a single, all-encompassing concept: "computer."

No hardware replacement Works with any meter Information first

II

Force of Trinity.
No "Best Leg" for a Three-Legged Stool.

The fundamental law of Prizm construction is the Rule of Three. Asking "which component is best?" is the wrong question entirely. Remove one leg — the whole structure collapses.

Everything exists in threes: P0 · P1 · P2 computers — near / local / global connectivity — water / gas / electricity resources — resident / manager / supplier beneficiaries. Components only exist as triples. There is no "best" link in the chain.

3-tier nodes 3-range connectivity 3 beneficiaries

III

The Prism.
Focusing Chaos into a Single Beam.

A prism is not a triangle — it is a generative, three-dimensional object capable of unique transformations. It symbolizes our dual function:

Focus (Laser): we take the chaos of the real world — cast-iron meters, broken links, incomplete data — and focus this informational noise into one clean, accurate beam of truth.

Decompose (Rainbow): the same system shows different facets of value to different audiences from a single source.

Chaos → order One source, many views Generative system

02 — The Problem

The Traditional ASKUE Approach
Has Hit a Dead End.

Classical automated metering systems (ASKUE/AMR/AMI) were built in a different era, on principles that don't scale economically to mass retrofit and cannot deliver real-time intelligence.

🔁

Inefficient Pull Model

The server must endlessly poll every node on a schedule. This is slow, energy-hungry, overloads the network, and means each meter lives as a small "server" that gets poked by schedule — not when something actually happens.

🔒

Vendor Lock-in

Closed ecosystems require expensive proprietary hardware. Different nodes speak different dialects. Integration costs are enormous. Once you're in, switching is prohibitively expensive — by design.

🐉

Protocol Zoo

Disparate nodes using RS-485, M-Bus, RF proprietary, custom protocols — each requiring its own driver, gateway, and integration. Complex to deploy, maintain, and scale. No unified data layer.

👁️

Blind Zone: Old Meters

The old analog meter stock cannot be digitized without full, expensive replacement. In practice this means millions of residential meters remain off-system. ASKUE reaches only where new hardware was installed.

Classic ASKUE / AMR

Server polls each device on schedule (Pull model)
Proprietary protocols, closed hardware ecosystems
Requires full meter replacement to digitize old stock
No intelligence at the edge; dumb collection only
High CAPEX, long deployment timelines (6-12 months)
Single vendor dependency, no open API
One-time project revenue model for integrators

VS

Prizm-MeterNet

Devices push data only when something happens (MQTT)
Open stack: LoRa / RS-485 / Wi-Fi, JSON everywhere
Computer Vision reads any analog dial, no replacement
Edge AI at P1 & P2: anomaly detection, forecasting
60% lower CAPEX; modular from 1 apartment, same day
Open API (REST/JSON), integrates with any billing system
Recurring SaaS revenue — not one-off projects

03 — Architecture

Three-Tier Stack.
From Sensor to Cloud.

The P0-P1-P2 hierarchy mirrors your SCADA mental model (field device → concentrator → dispatch), but built on cheap, open, mass-produced components with an AI layer on top.

Nano-computer · Field tier

P0

Sensor & Vision Node

Core: ESP32 Xtensa dual-core 240 MHz, 520 KB SRAM
Camera: OV2640 2MP for meter dial photography
Radio: LoRa SX1276/78 868/433 MHz, range ≤40m indoor
Protocol: LoRa packet → MQTT upstream via P1
Sensors: temp, humidity, current, PIR, reed contact, pressure
Power: 3.3V; sleep current <10 µA, battery-operated option
Flash: 4 MB; stores image buffer + config
IP65 housing option for outdoor/wet environments

Micro-computer · Edge tier

P1

Edge Concentrator

MCU: ESP32 or ARM Cortex-M/A series; Linux-capable variants
LoRa RX: SX1301 8-channel concentrator, 50–100 P0 nodes
Wired: RS-485 (Modbus RTU), 10/100 Ethernet
Wireless: Wi-Fi 802.11 b/g/n for uplink to P2
Broker: Mosquitto MQTT broker; routes P0 events upstream
Edge logic: local threshold alerts, offline buffer (16 GB SD)
Power: 5 V DC or PoE; works autonomously if P2 link drops
Covers entrance → building → neighbourhood scale

Mini-computer · Cloud/Platform tier

P2

Platform & AI Hub

Hardware: Raspberry Pi 4B (ARM Cortex-A72 quad-core, 4–8 GB RAM)
OS: Linux (Raspberry Pi OS / Ubuntu Server 22.04)
DB: PostgreSQL 14+ — unified primary data store
Backend: Python 3.10+, FastAPI; JSON REST API
OCR/CV: OpenCV 4 + custom CNN → automatic meter reading
ML: Isolation Forest, One-Class SVM, ARIMA, LSTM
Dashboard: web UI for residents, managers, suppliers
Scales to district/city via cloud (cloud-ready architecture)

Full network topology: meter → LoRa mesh → edge → cloud

Click to enlarge

3 node types P0 · P1 · P2 3 connectivity ranges LoRa (≤40 m) · LoRa Mesh (building/district) · Wi-Fi / Fiber / Ethernet (city) 4 resources Water · Gas · Electricity · Heating Scale entrance → neighbourhood → city

04 — Radio & Protocol Stack

Every Layer Engineered.
Nothing Proprietary.

The full radio and protocol stack, from the sensor node to the cloud — designed so that each layer is replaceable, open, and immune to vendor lock-in.

Layer / Link	P0 → P1 (sensor uplink)	P1 ↔ P1 (mesh routing)	P1 → P2 (aggregation)	P2 → WAN (cloud)
Physical	LoRa 868/433 MHz Sub-GHz RF, CSS modulation	LoRa Mesh Multi-hop, self-healing	RS-485 Wi-Fi Ethernet 10/100	Fiber / xPON GPRS / GSM / LTE
Range	Up to 40 m indoors through concrete; 1–5 km LOS outdoors	Building to district scale; nodes relay automatically	Local network (LAN); PoE up to 100 m on cable	Unrestricted; P2 is internet-connected
Data Rate	0.3–50 kbps (SF12 slowest, highest range; SF7 fastest)	Application-layer variable; mesh overhead modest	RS-485: 9600–115200 baud; Wi-Fi: up to 54 Mbps	Bandwidth-unlimited at platform level
Application Protocol	MQTT pub/sub upstream; sensor events only (Push)	LoRa Mesh routing layer; transparent to application	MQTT broker on P1; Modbus RTU for legacy meters	MQTT → P2; REST/JSON to external billing/SCADA
Data Format	JSON payload: device_id, resource, value, timestamp, RSSI	Forwarded JSON, unchanged	Aggregated JSON; stored in PostgreSQL	JSON REST API; webhook support
Power budget	P0 sleep: <10 µA; TX burst ~120 mA; battery years possible	P1 always-on: 5 V / 500–800 mA	P1 Ethernet: PoE 802.3af/at	P2: 5 V / 3 A (Raspberry Pi)

📡LoRa — Deep Dive

ModulationCSS (Chirp Spread Spectrum) — resistant to interference and multipath
Frequency bandsEU 868 MHz / 433 MHz / 915 MHz (US)
Spreading FactorSF7–SF12 — higher SF = longer range, lower data rate
Bandwidth125 / 250 / 500 kHz (configurable)
SensitivityDown to -148 dBm at SF12 (exceptional penetration)
Indoor rangeUp to 40 m through reinforced concrete, stairwells
Outdoor LOS1–15 km (SF and terrain dependent)
Max payloadUp to 255 bytes per frame (SF-dependent)
Chipset (P0)Semtech SX1276 / SX1278
Concentrator (P1)Semtech SX1301 — 8 channels simultaneously
TopologyLoRa Mesh — multi-hop self-healing; no single point of failure

⚡MQTT + RS-485 — Deep Dive

MQTT BrokerMosquitto 2.x on P1 (edge) and P2 (platform)
QoS levelsQoS 0 (telemetry), QoS 1 (alerts), QoS 2 (billing events)
Topic schemaprizm/{city}/{building}/{unit}/{resource}
Retained msgsLast known value always available for new subscribers
Keep-aliveHeartbeat for device health monitoring and outage detection
RS-485 physicalDifferential pair; up to 1200 m, 32 devices per bus
RS-485 protocolModbus RTU (standard for industrial/commercial meters)
RS-485 speed9600 – 115200 baud (meter dependent)
JSON schema{"id","ts","resource","value","unit","rssi","battery"}
External APIREST JSON; webhook push; compatible with any billing/ERP/SCADA
Push vs PullEvents emitted only on change or threshold — zero polling overhead

05 — Hardware Components

Serial, Open, Replaceable.
No Proprietary Black Boxes.

Every component is a standard, mass-produced part available from multiple suppliers. No custom ASICs. No locked firmware. No vendor dependency. This is what drives the 60% CAPEX reduction.

P0 — Nanocomputer

ESP32-CAM Module

OV2640 · SX1276 · GPIO sensors

MCUESP32 Xtensa LX6 dual-core, 240 MHz

Memory520 KB SRAM + 4 MB PSRAM (JPEG buffer)

Flash4 MB onboard; OTA firmware updates

CameraOV2640 2MP, 1600×1200, JPEG compression

LoRa RadioSX1276/78, 868 MHz or 433 MHz, -148 dBm

InterfacesSPI, I2C, UART, 10× GPIO, ADC 12-bit

Sleep current<10 µA deep sleep; years on 2× AA batteries

Supply3.3 V regulated; USB-C programming

HousingIP65 option for outdoor / wet areas

Supported sensors (via GPIO / I2C / SPI)

DS18B20 temp SHT31 temp+RH INA219 current HC-SR501 PIR Reed contact BMP280 pressure MQ-2/7 gas JSN-SR04T ultrasonic

P1 — Microcomputer

Edge Concentrator Node

SX1301 · RS-485 · PoE · MQTT

MCUESP32 or ARM Cortex-A7 (Linux-capable variant)

LoRa conc.SX1301 8-channel, handles 50–100 P0 nodes

RS-485MAX485 / SN75176B; Modbus RTU master

Ethernet10/100 Mbit; PoE 802.3af/at powered

Wi-Fi802.11 b/g/n; WPA2/3; uplink to P2

Storage16 GB microSD — local event cache for offline periods

MQTTMosquitto broker; routes P0 events + Modbus polls

Power5 V DC / PoE; autonomous if P2 link drops

Scale1 unit per entrance; chain P1↔P1 for large buildings

Supported wired meter interfaces

RS-485 / Modbus RTU M-Bus (via converter) Pulse output (S0) 4–20 mA current loop 1-Wire (DS18B20) I2C industrial sensors

P2 — Minicomputer

Raspberry Pi 4B Platform

Linux · Python · PostgreSQL · AI/CV

CPUARM Cortex-A72 quad-core, 1.8 GHz 64-bit

RAM4–8 GB LPDDR4-3200

Storage32–64 GB microSD / USB3 SSD for production

NetworkGigabit Ethernet + Wi-Fi 802.11ac (dual-band)

OSLinux: Raspberry Pi OS / Ubuntu Server 22.04

Power5 V / 3 A USB-C; ~7 W typical load

GPIO40-pin; direct RS-485 / I2C / SPI if local wired

CloudCloud-ready: same stack runs on VM/VPS for scale-out

Import sub.100% — Raspberry Pi + ESP32 fully localisable

Platform software components

PostgreSQL 14+ Python 3.10+ FastAPI / Flask OpenCV 4 scikit-learn TensorFlow/Keras Mosquitto MQTT Redis + Celery

06 — Software Stack & AI

Open Stack. No Proprietary Lock.
AI as a Working Layer, Not Hype.

Python, PostgreSQL, JSON — proven, auditable technologies that are cheaper than proprietary alternatives and integrate in 3× less time. AI is a practical working layer: OCR reads meters, ML detects leaks, LSTM forecasts load.

P0 Firmware Layer

MicroPython / Arduino / C++

Lightweight firmware on ESP32. Wakes on event or timer, captures camera frame, runs pre-processing, serialises to JSON, transmits via LoRa, returns to deep sleep. Boot-to-TX in <500 ms.

MicroPython 1.21Arduino coreFreeRTOS

ESP32-Camera Driver

Native esp32-camera driver; captures JPEG at configurable resolution; PSRAM-backed frame buffer for 2MP images without overflowing main RAM.

LoRa Radio Stack (sx126x / RadioLib)

Open-source RadioLib library; configures SF, BW, CR, frequency; handles ACK at application level for critical events (QoS-like on LoRa).

RadioLib 6.xLoRa Mesh routing

P1 Edge Middleware

Mosquitto MQTT Broker

Local broker receives P0 LoRa events (via LoRa→MQTT bridge), bridges to upstream P2. Supports QoS 0/1/2, retained messages, access control lists. Persists queue on SD card if P2 unreachable.

MQTT 5.0Mosquitto 2.x

Modbus RTU Master

Polls wired RS-485 meters on configurable schedule; translates Modbus registers to JSON events; publishes to MQTT topic hierarchy. Supports standard meter register maps (IEC 62056, DLMS/COSEM).

Edge Logic Engine

Configurable threshold rules (e.g., "if flow > X for > Y minutes → alert"). Operates independently of P2 — local alerts even when offline. Rule definitions pushed from P2 as JSON config.

SQLite local cacheOTA config updates

P2 AI / ML Layer — Practical Intelligence, Not Decoration

Computer Vision

Meter OCR

OpenCV 4 + Custom CNN

Photographs analog dial faces (ESP32-CAM at P0), extracts digit regions, runs trained classifier. Reads any meter without hardware modification. Accuracy >99% on trained meter types after calibration.

Anomaly Detection

Leak & Fault Detector

Isolation Forest · One-Class SVM

Trained on historical consumption profiles per unit. Flags statistically anomalous readings in real time (water pipe leak, gas leakage, electricity theft, meter fault). No labeled fault data required.

Load Forecasting

Short & Mid-Term Forecast

ARIMA (short) · LSTM (medium)

ARIMA for next-24h peak prediction (statistical, fast). LSTM for multi-week patterns (seasonal + behavioral). Enables proactive grid balancing and fair tariff design for utility companies.

Platform Analytics

Billing & Insights Engine

Python · PostgreSQL · FastAPI

Validates raw readings (physics-sanity check), enriches with tariff tables, generates billing events via REST/JSON API. Separate views for resident, manager, and utility — same data, different lenses.

07 — Application Cases

Beyond Utility Metering.
The Platform is Universal.

The same three-tier P0-P1-P2 infrastructure handles any scenario requiring distributed sensing, wireless telemetry, edge processing and cloud analytics — far beyond traditional utility accounting.

🏢

Utilities · Residential · Commercial

Unified Utility Metering

P0 nodes on water, gas, electricity and heat meters — all resources in one system. Computer Vision reads any existing dial without replacement. Single dashboard for resident, management company, and supplier. Automatic billing-ready data via JSON API.

💡

Municipal · Energy · Smart City

Smart Street Lighting

P0 on every luminaire: current sensor (lamp health), optional PIR (adaptive dimming). P1 controls a block. P2 provides city-map dashboard with proactive fault detection and GPS-precise repair orders. 30–50% energy saving via adaptive control.

🌊

Municipal · Emergency Management

Drainage & Flood Prevention

P0 with ultrasonic level sensors in drainage wells; LoRa signal penetrates underground. P1 acts as edge server computing flood risk index. P2 triggers SMS to emergency services and automatic pump activation via API — before the flood, not after.

🌾

Agriculture · Food Security · Government

Smart Field (Agro-IoT)

P0 with soil moisture, temperature and light sensors (1 per hectare). Battery + LoRa critical for large fields without power. P2 aggregates thousands of fields for a holding or Ministry of Agriculture yield forecasting at regional level.

🌲

Ecology · Forestry · Emergency Services

Forest Fire & Logging Detection

P0 with temperature/smoke and acoustic sensors mounted in trees. P1 on watchtowers filters false alarms (thunder, gunshots). P2 sends GPS-precise alerts to emergency services. LoRa Mesh covers hundreds of thousands of hectares with no existing infrastructure.

🏗️

Infrastructure · Roads · Government

Bridge & Road Monitoring

P0 with accelerometers and deformation sensors on bridges and overpasses. P1 continuously processes vibration data, identifies abnormal deformations (metal/concrete fatigue). P2 schedules condition-based maintenance — not calendar-based — preventing disasters.

08 — Prizm vs Classic ASKUE

A Complete Paradigm Shift,
Parameter by Parameter.

This is not a product comparison — it is a comparison of two fundamentally different paradigms. One optimised for the past; one designed for the next decade.

Parameter	Classic ASKUE / AMR / AMI	Prizm-MeterNet
Hardware (CAPEX)	Proprietary, vendor-specific hardware. Expensive per-unit cost. No standard component supply.	Serial standard parts: ESP32 (~$5), Raspberry Pi (~$70). 60% lower CAPEX vs cable/proprietary alternatives.
Data collection model	Pull — server polls every device on a fixed schedule. Slow, network-intensive, high energy drain on devices.	Push — devices emit events on change or threshold. Near-zero network overhead. Battery life measured in years.
Protocol stack	Closed, proprietary protocols (M-Bus, custom RF, IEC 62056 walled). Vendor lock-in by design.	Open: LoRa / RS-485 / Modbus RTU / Wi-Fi / MQTT / JSON. Any integrator can work with the stack.
Legacy meter integration	Requires physical meter replacement to digitise old analog stock. High cost, regulatory complexity, long timelines.	Computer Vision (ESP32-CAM + CNN) reads any existing analog dial automatically. No meter replacement.
Edge intelligence	None. Meters are dumb collection points. All logic centralised. No offline capability.	P1 runs local threshold rules and MQTT broker autonomously. Works without P2 link. P2 adds full ML analytics.
AI / Analytics	Absent or bolt-on afterthought. No anomaly detection. No forecasting. Manual report generation.	Native: Isolation Forest (leak detection), ARIMA/LSTM (load forecast), Computer Vision (OCR), per-unit profiles.
Scalability path	Complex, expensive re-engineering per scale-up. Each new building requires new integration project.	Modular: start with 1 entrance, grow to city. Same architecture. Marginal cost per added node is low.
Integration with external systems	Requires custom adapters, proprietary SDKs, months of integration work per billing/ERP system.	REST JSON API out of the box. Webhook support. Integrates with any billing/SCADA/ERP in 3× less time.
Vendor dependency	Complete lock-in. Hardware, firmware, cloud, support — all from one vendor.	Zero vendor lock-in. Open-source stack. Any developer can extend or replace any layer.
Revenue model (for integrators)	One-time project revenue. Long sales cycles. Margins squeezed by hardware costs.	Stage 1: integration + hardware (covers costs). Stage 2: recurring SaaS subscription for platform + analytics.

Bottom line for integrators and partners: Classic ASKUE earns once on expensive hardware. Prizm earns continuously on data and analytics. Low barrier to entry via cheap serial components. High switching cost once embedded via unified SaaS interface and trained ML models. We win on entry price; we retain on intelligence.

09 — Traction & Roadmap

Not a Concept.
A Running, Revenue-Generating Business.

We are not selling an idea. We are scaling proven unit economics across new geographies.

$120K

Confirmed 2025 Revenue · Product deployed and running

10K

Apartments connected on a single Prizm system

$250K

Private investment raised · R&D phase completed

3×

Faster integration with billing systems vs ASKUE (open JSON API)

Stage 1 — Current

Belarus Base + R&D Complete

Platform deployed. Confirmed revenue from live installations. Core team of 4 (ideology, software, hardware engineering, marketing/product). $250K private investment spent on foundational R&D. Ready for scale.

Stage 2 — Active

CIS Expansion + Serbia Entry

Scaling to Russia/CIS market (10,000-apartment project in progress). Serbia as a strategic beachhead for the Balkans and EU-adjacent markets — modular Digital Twin architecture adapts to any national standard seamlessly.

Stage 3 — Target

SaaS Revenue + Regional Scale

Transition from one-off integration revenue to recurring platform SaaS subscription. Grow ML model accuracy with scale (data flywheel moat). Target: region-wide utility modernisation tenders. Smart Money partner sought.

10 — Partnership: Serbia

You've Run Serbia's Grids and
Waterworks for 30 Years.

This is the layer that was missing. Let's own the Serbian utility modernisation market together.

🏛️

Your 30+ years of domain authority — EKC secondary regulation (Serbia / Montenegro / Macedonia), Vodovod Kruševac, Čačak, Kotor, Banjaluka, Pristina; industrial SCADA; measuring instrument production with Mihajlo Pupin Institute.

⚡

Your local relationships — trusted integrator with major utilities, water companies, and industrial clients across Serbia and the Western Balkans region.

🧠

Prizm's cheap AI telemetry layer — the retrofit tier that classical SCADA never reached economically: mass residential, LoRa mesh, computer vision, open JSON API, 60% lower CAPEX.

📈

Prizm's SaaS model — recurring platform revenue replaces one-off project income. ML data flywheel creates compounding competitive advantage over time.

⟹ Joint modernisation tenders — won together. Recurring SaaS. Regional scale.

Your proven references that open doors

EKC Belgrade — secondary regulation of Serbia / Montenegro / Macedonia power systems
Vodovod Kruševac — water utility SCADA
Vodovod Čačak — water supply system
Vodovod Kotor — water utility monitoring
Vodovod Banjaluka — regional water supply
Vodovod Pristina (Batlava) — SCADA system
Dispečerski centar JUGEL — secondary regulation
TE Kakanj blok IV — data acquisition and monitoring
Measuring instruments: level, flow, humidity, wind — multiple utilities

Next step: a 30-minute call
+ one pilot zone in Serbia.

Full technical deck, live demo, and unit economics model available on request. We are ready to deploy pilot zones "here and now" — no long R&D required.

Vitaly Nikulenko Product & Partnerships — Prizm-MeterNet
nikulenka@gmail.com

From a zoo of protocolsto a single beam of data.

Three Principles.One New Paradigm.

The Traditional ASKUE ApproachHas Hit a Dead End.

Three-Tier Stack.From Sensor to Cloud.

Every Layer Engineered.Nothing Proprietary.

Serial, Open, Replaceable.No Proprietary Black Boxes.

Open Stack. No Proprietary Lock.AI as a Working Layer, Not Hype.

Beyond Utility Metering.The Platform is Universal.

A Complete Paradigm Shift,Parameter by Parameter.

Not a Concept.A Running, Revenue-Generating Business.

You've Run Serbia's Grids andWaterworks for 30 Years.

From a zoo of protocols
to a single beam of data.