I build systems where software meets electricity.

My work sits at the intersection of three worlds that rarely talk to each other: production-grade web engineering, embedded firmware, and renewable energy. A typical week involves shipping a Laravel API in the morning, flashing an ESP32 that reports inverter registers over MQTT in the afternoon, and tuning a forecasting model that decides when the battery should charge.

I care about the unglamorous parts — reconnect logic, watchdogs, migrations that run cleanly at 3 AM, dashboards that stay honest when the grid drops. Hardware is unforgiving, and that discipline has made my web code considerably better.

What I actually do, day to day

• Design and ship Laravel / PHP back-ends with clean domain boundaries, queues, events and typed REST APIs.
• Write ESP32 / Arduino firmware with OTA updates, deep sleep and captive-portal provisioning.
• Bridge hybrid inverters and BMS units into Home Assistant over Modbus/RS485 → MQTT with auto-discovery.
• Build realtime dashboards — energy, trading, telemetry — with Vue and Tailwind on top of WebSockets.
• Automate everything else with Python, Docker, Linux and CI.
• Apply AI where it earns its keep: forecasting, anomaly detection and assistants wired into real devices.

I am a problem solver first. The stack is a means, not an identity.

A protocol bridge that turns a hybrid solar inverter into a well-behaved citizen of your smart home. It speaks Modbus RTU over RS485 to the inverter, normalises the register soup into meaningful entities, and republishes everything to MQTT with Home Assistant auto-discovery.

Features

• Register maps for common hybrid inverter families, versioned as data not code
• Home Assistant MQTT auto-discovery — devices appear with correct units and classes
• Write support for work mode, charge current and time-of-use windows
• Resilient serial layer: CRC validation, backoff, watchdog, hot re-enumeration
• Prometheus endpoint plus InfluxDB line-protocol output
• Runs as a container on a Pi or as a systemd unit on any Linux box

Tech stack

One screen that answers the only question that matters: where is my energy going right now, and what should happen next? Live production, consumption, battery state and tariff windows, with an optimiser that schedules loads around the cheapest and greenest hours.

Features

• Sub-second live tiles driven by WebSockets, no polling
• Battery scheduler that respects tariffs, forecast yield and depth-of-discharge limits
• Yield forecasting from historical output plus weather input
• Anomaly alerts for string underperformance, cell drift and inverter faults
• Multi-site support with per-site roles and export-ready reports
• Mobile-first layout that stays legible on a phone in bright sun

Tech stack

A curated set of Home Assistant packages, blueprints and Lovelace views for homes that generate their own power. Opinionated defaults, documented entities, and no YAML archaeology required.

Features

• Drop-in packages for solar, battery, EV charging and water heating
• Blueprints for load shifting, surplus diversion and grid-outage behaviour
• Lovelace dashboards tuned for tablets, phones and wall panels
• ESPHome device definitions for the sensors that feed it
• Every automation ships with a written explanation of its trigger logic

Tech stack

A trading workstation for people who prefer evidence over vibes. Streaming market data, a strategy sandbox with honest backtests, and a risk engine that can veto an order before it ever reaches the exchange.

Features

• Normalised WebSocket feeds with automatic reconnect and gap backfill
• Event-driven backtester that replays the same code path as live execution
• Position sizing, exposure caps and kill-switch rules enforced server-side
• Portfolio analytics: drawdown, Sharpe, win rate, per-strategy attribution
• Alerting into MQTT and mobile push, reusing the same bus as the IoT stack

Tech stack

A multi-tenant CRM built for solar installers: leads, site surveys, quotations with live component pricing, installation scheduling and post-install monitoring — all in the same place the technician already works.

Features

• Tenant isolation at the query layer with per-tenant storage and backups
• Quotation builder that prices real BOMs and exports branded PDFs
• Job scheduling with technician calendars and route grouping
• Commissioning checklists that attach photos and meter readings
• Immutable audit trail on every record that touches money
• Webhooks and a documented REST API for downstream tooling

Tech stack

ESP32 firmware for field sensor nodes that have to survive on a battery, a flaky Wi-Fi link and no physical access. Provisioning happens through a captive portal; updates arrive over the air; failures recover themselves.

Features

• Captive-portal provisioning — no credentials baked into the binary
• Signed OTA updates with automatic rollback on boot failure
• Deep-sleep duty cycling with RTC-preserved state
• Store-and-forward buffer so nothing is lost during outages
• Modular sensor drivers: environment, current clamp, pulse meter, contact
• MQTT last-will and birth messages for accurate presence tracking

Tech stack

Most of what I learn came from other people's repositories, so a meaningful share of my work goes back out under permissive licences.

What I publish

• Protocol bridges and register maps — the tedious reverse engineering that nobody should have to repeat
• Home Assistant packages and ESPHome definitions for real hardware
• Reusable Laravel and Tailwind building blocks pulled out of client work
• Grafana dashboards and Docker stacks that work on a Raspberry Pi

How I maintain

• Semantic versioning with a written changelog
• Issue templates that ask for firmware version, hardware revision and logs
• CI on every pull request — lint, tests, container build
• A SECURITY.md on anything that touches a network
• Answers within a few days, even if the answer is "not planned"

• Tariff-aware battery scheduler — turning a forecast plus a tariff plan into an hour-by-hour charge/discharge plan, with a dry-run mode so it can be audited before it touches a relay.
• Fleet console — one place to see every deployed node, its firmware version, signal strength and last heartbeat.
• Signed OTA channels — stable, beta and canary rings with automatic rollback on a failed boot.
• Neon component kit — extracting the dashboard UI into reusable Blade and Vue components so every project stops re-inventing the card.

• CAN-bus BMS support — moving beyond RS485 for battery packs that speak CAN.
• Three-phase metering — per-phase current clamps with proper power-factor handling.
• Edge inference — running a small fault-classification model directly on the gateway so alerts survive an internet outage.
• Documentation overhaul — every repository getting a real quick-start, an architecture note and a troubleshooting page.

• My first "production incident" was a relay clicking every two seconds at 3 AM because of a missing hysteresis check. I now write hysteresis first.
• I debug hardware with an oscilloscope and software with printf. Both are correct choices, and I will defend that.
• The most valuable file in my energy stack is a YAML register map, not a single line of application code.
• I have re-flashed a device from a rooftop in monsoon rain. Twice.
• Every dashboard I build gets tested on a phone in direct sunlight before it is considered finished.
• I keep a physical notebook for protocol captures. Paper never loses its connection.

• Favourite debugging tool: a second person to explain the bug to.
• Preferred deployment window: when the sun is high and the batteries are full.
• Coffee is instrumentation, not a personality.
• I read datasheets end to end. The interesting part is always in a footnote.
• The best commit message I ever wrote was six words long and saved a colleague four hours a year later.
• I will always choose a boring, well-documented protocol over a clever one.

Everything I open-source is free and stays free. If something here saved you a weekend of reverse engineering, the most useful things you can do are:

• Star the repository you found helpful — it is the signal that decides what I maintain next.
• Open a good issue. Firmware version, hardware revision, a log excerpt and what you expected. That is a gift.
• Send a register map. Every new inverter or BMS you document helps someone with the same hardware next month.
• Write about it. A blog post or forum answer reaches people that a README never will.
• Hire me for the hard part. Sponsored work on shared infrastructure benefits every user of the project.