mySmart EMS

mySmart EMS aggregates building data from a wide range of sources and metric types, and is designed to take on new ones without reshaping the platform. It brings that data together across every site a customer manages, turns it into dashboards and alerts, and checks that it would stand up to a Green Star assessment.

It also runs the work of getting buildings connected: quoting the job, guiding engineers through the install, commissioning each device and handing the customer an app in their own brand colours.

New features, built inside the platform

Staff assemble screens from charts and widgets by dragging and resizing them. When a screen needs something the widgets can’t do, such as a bespoke dashboard for one customer or a diagnostic for the team, staff describe it to an AI assistant instead. The assistant builds it as a small standalone app, with a live preview beside the conversation. Every build is kept as a version that can be published or rolled back, and a spending limit pauses the assistant until someone raises it.

A published screen sits inside the admin console, the customer’s app or both, and looks like any built-in page. It runs with the viewer’s own sign-in, so it sees only what they can, and a new feature goes from request to a customer’s screen without waiting on a release of the platform.

Projects that file their own email

Each install is tracked as a project from proposal to on-site setup, with its contacts, contractors, devices, quotes and files in one place. Staff build and send branded quotes from it, and engineers on site use a mobile app to work through each device’s setup checklist while project managers follow along from the office. Commissioning reports confirm that every sensor is ready before the customer takes over.

The correspondence files itself. Project email, from contractor replies to site photos and documents, arrives in one shared mailbox, and the platform reads it on a schedule and files each message, with its attachments, onto the right project’s thread. Matching starts with the evidence it trusts most: a known project number in the subject or an attachment’s name, then a conversation that has already been filed, then the sender. AI reads the message only when those run out, so it is a fallback rather than a second opinion. Anything uncertain waits in an inbox for a person, and the system never creates a project by itself, because a wrong project costs far more to untangle than a message waiting for review.

AI that sets up the hardware

Every meter model reports its readings in its own way, set out in its datasheet. Rather than transcribe that by hand, staff upload the PDF and Claude proposes how the meter should be read. They refine the result by describing changes in plain words and accepting or rejecting each revision.

Once a meter is installed, an AI review checks that it is set up correctly. It reads the datasheet and the meter’s live values through its gateway, proposes a set of changes and applies them only after a person approves. It then checks the result against the device itself, proving that each setting actually took, before signing the meter off. A second assistant sets up wireless water meters through conversation, taking a new customer from no devices to readings arriving, and repairs existing setups the same way. When staff inspect a meter, AI commentary explains its live readings in plain language.

The rule is the same everywhere: the model proposes, a person approves, the device has the final word, and every step is kept in a history that can be reviewed later.

Data an assessor can trust

Green Star compliance is about whether the data behind a building’s reports can be trusted, as much as how the building performs. A meter frozen on one value is a compliance failure even when its numbers look healthy. Each compliance alarm carries the rating scheme’s own requirement code, so an auditor can follow a requirement from the rule, through every scheduled check, to the alert it raised. The checks cover every customer, and a portfolio a check could not reach is recorded as missed rather than silently skipped.

A recurring problem updates one alert instead of raising many, and alerts reach the right people by email, SMS or webhook. Customers see only the alerts meant for them.

Built to keep running

Readings arrive from cloud services, wired meters behind on-site gateways, wireless sensors and devices that push their own data. A faulty device never holds up the rest of its site, and failed collections are retried and recovered automatically. Readings are summarised into hourly and daily figures, so charts stay quick across years of history. Older detail is archived month by month, verified before it leaves the database, and can be restored. Every edit staff make is recorded in an audit log.

How it’s built

I designed and built the platform and run it in production, with most of the code written by AI coding agents working under Blint. Every change is scoped as a story and reviewed against the project’s own patterns and principles before it merges. Anything staff would notice gets a short, plain-language entry in a changelog they can read in the admin.