BluNotify — Product Support & User Manual

Temperature monitoring and energy alerting, powered by BluLine Solutions.

Revision 2.0 · October 16, 2026

What BluNotify is

A monitoring platform whose alerts are visible in the room, not buried in a dashboard.

BluNotify turns sensor readings into something a person standing in the room can see and hear. Rather than expecting staff to watch a screen, it puts a physical indicator — a BluNotify light — in the space being monitored. The light changes colour on its own as readings arrive: by default green while everything is in range, amber when a problem is developing, red once a breach is confirmed.

A vaccine fridge that drifts warm overnight is noticed at a glance the next morning, without anyone opening a browser.

The two halves

The devices are in the field. Each one is an ESP32-based unit with an RGB light, a speaker and a relay contact, connected over Ethernet, Wi-Fi or cellular. It holds no rules of its own — it displays what it is told to display, and keeps doing so if the network drops.

The platform is this web application and the services behind it. It ingests readings, decides what each light should be showing, sends the commands, keeps the history, and gives you the screens described in this manual.

Two products, one platform

The platform hosts more than one kind of device, and the menu is organised accordingly — you will see a section per product, containing only the screens that product has.

The parts that are not about a particular kind of device — customers, users, the organization tree, device placement, sessions — are shared by both, and work the same way whichever products an install has.

Who does what

Permissions are a set of flags granted at a place in the organization — not a job title.

Older versions of BluNotify gave each login a role: you were an admin or you were a user, and that decided everything. That is no longer how it works, and the difference matters for every screen in this manual.

Today a login holds a grant: a set of permission flags, attached to one node of the organization tree. The flags say what you may do; the node says where you may do it. Someone can hold view_data over an entire chain of stores while holding manage_devices over only one of them.

The permission flags

The three populations

System administrators hold system_admin. They belong to no customer, see every customer, and are the only people who can open the Customers page, the Device Console, the Table Browser and the API Admin Console. This is BluLine staff, not customer staff.

Account admins hold everything except system_admin and reset_energy (which an administrator grants only to someone who needs it), granted at their own customer's node. Within their own organization they are in charge: they build their tree, place their devices, write their alert profiles and create their own users. Outside it they can see nothing at all.

Operators and viewers hold a narrower set — typically view_data alone, or view_data with control_lights — often granted at a single site or room rather than at the whole customer.

The two rules that constrain delegation

When you create or edit another login, the server enforces both of these, no matter what the screen offers:

1. The subset rule. You cannot grant a permission you do not hold yourself. An operator with view_data and control_lights can only ever produce another login with those same two flags, or fewer.
2. The scope rule. You cannot grant access outside the part of the organization you manage. If your grant sits on Main Clinic, every login you create sits on Main Clinic or somewhere beneath it.

Together they mean delegation can only ever narrow. There is no sequence of steps by which someone builds themselves a login more powerful than their own.

The organization tree

One tree describes every customer's sites and rooms, and answers who owns each device.

The organization tree is the backbone of the whole system. Almost every question the platform has to answer — who owns this device, who may see this reading, where should this alert go — is answered by looking at where something sits in the tree.

What the tree is made of

A node is a place: a customer, a site, a building, a room. Nodes nest as deeply as you need them to.

A customer is anchored to exactly one node, and owns everything in that node's subtree. That anchoring is what makes ownership work: there is no separate list of which devices belong to which customer, because the answer is always "the ones sitting under that customer's node".

Customers                          ← a root
├── Northside Veterinary Clinic    ← the customer's anchor node
│   ├── Main Clinic
│   │   ├── Exam Wing              ← devices live in nodes like this
│   │   └── Pharmacy
│   └── Boarding Annex
└── Harbor Point Grocery
    ├── Front of House
    └── Back of House

Staging / Inventory                ← a second root: devices with no home yet

Why ownership follows placement

A device row does not record which customer it belongs to. It records which node it sits in, and the customer is derived from that.

This has one consequence worth stating plainly, because it explains several behaviours later in this manual: moving a device between nodes is how you change its owner. There is no separate "assign to customer" action, and nothing else in the interface can transfer a device. If moving it crosses from one customer's subtree into another's, the system stops and asks you to confirm, because the sensors attached to it feed the losing customer's data and cannot follow it across.

Staging / Inventory

A device that has been provisioned but not yet placed somewhere real lands in Staging / Inventory, a root node that belongs to no customer. It is reachable by administrators, invisible to every customer, and the pool that the "place a device" flow draws from.

Removing a device from a customer sends it back here rather than leaving it attached to nothing — a device owned by nobody and reachable by nobody is a state no screen could show you.

What you see of the tree

The tree is re-rooted for whoever is looking at it. An administrator sees the whole forest, every customer side by side. A customer's own staff see their own branch presented as if it were the entire tree — they have no way to learn that other customers exist, let alone what they are called.

Signing in

What you see depends on the permissions you hold and the part of the organization you hold them at.

Sign in with the username and password you were given. If you are the first person at your organization, that came from BluLine; if you are a colleague, it came from whoever manages your users.

Your menu

The menu shows only the screens your permissions allow. A colleague's menu may be longer or shorter than yours, and that is normal — it reflects a different grant, not a fault.

If a screen you expect is missing, you do not hold the flag for it. Ask whoever manages your users.

Help, Notifications, Change Password and Sign out are not in that menu: click your name at the top right for those.

After signing in you land on Configuration — unless every device you can see is a BluEM meter, in which case you land on Energy Monitoring.

What you can see

Two limits apply at once, and both are enforced by the server rather than by the screen:

• Your flags decide what kinds of thing you may do at all.
• Your node decides where. If your grant sits on one site, the other sites in your organization are not merely hidden from you — they do not come back in the data at all.

Your organization is also presented as if it were the whole world. You have no way to see that other customers exist on the platform, and they have no way to see you.

Connection emails

Notifications, under your name at the top right, lets you choose to be emailed when a device you can see goes offline for about 20 minutes, and again when it comes back. It is off until you turn it on — see Notifications.

Changing your password

Change Password, under your name at the top right. Changing it ends every other session you have open, on every device — so a password change is also the fastest way to lock out a browser you left signed in somewhere.

Managing your organization

Building the map of your own sites and rooms, and placing your devices in it.

Your organization is the map of your own premises: sites, buildings, rooms. It decides where each device lives, and it is what scopes your colleagues' access when you create their logins.

Open Organization from the menu.

You see your own branch re-rooted — your organization is the tree as far as this screen is concerned. The two things you will not find are + Root (creating a top-level node is a BluLine operation) and any way to detach a device to nowhere; both are absent because the server would refuse them anyway.

Adding a site or room

Select the node the new one belongs under, then + Child in the detail panel. Build it the way your staff talk about the building — the names here are what everyone will navigate every day.

A structure that works for most sites:

Your organization
├── Main Site
│   ├── Kitchen
│   ├── Store Room
│   └── Pharmacy
└── Second Site
    └── ...

Depth costs nothing, and it buys you precision later: a colleague can be given access to Pharmacy alone, and alerts can be read per room rather than per building.

Renaming and moving

Rename changes the name only. Move under re-parents a node, taking its children and devices with it — useful when a site is reorganised, and safe, because everything stays inside your organization.

Placing a device

Select the node the device physically sits in, find Attach a device, filter the picker by name or ID, and attach it. The device sections appear only if you also hold manage_devices, and the picker offers the devices already somewhere in your organization.

This is also how you move a device between your own rooms: attach it to its new node and it leaves the old one. Because both nodes are yours, no transfer confirmation appears — that only happens when ownership would change hands.

There is no Remove for you: returning a device to BluLine's staging pool takes it out of your organization, which only BluLine can do. If a device is leaving your site for good, ask BluLine; if you are just moving it to another room, attach it there instead.

Deleting a node

A node has to be empty first — no devices, no child nodes, no user grants pointing at it. The screen tells you which of those is blocking, so work inwards: move the devices, then delete the children, then the node.

Managing your users

Creating logins for your own staff, each scoped to the part of the organization they work in.

If you hold manage_users, you create and manage your own colleagues' logins. You do not need to ask BluLine, and BluLine does not need to know your staff list.

Open Users from the menu.

You see only the logins belonging to your organization. The Active Sessions panel an administrator has does not appear for you.

Creating a colleague's login

+ New User, then fill in:

• Username and password — what they sign in with. Use Generate for the password and send it to them; they can change it afterwards.
• Access — which part of your organization they get. The whole thing, or one site, or one room.
• Permissions — the bundle or individual flags.

Most people need one of two things:

Reserve Account Admin for the small number of people who should be able to change your organization, your devices, your alert profiles and signals, and your users.

What Access does and does not divide

Access divides up your devices: give somebody Main Clinic and they see the lights there and in everything beneath it, and nothing beside it.

It does not divide up your sensors. Everyone you create sees every sensor your account holds, wherever they sit in your organization. That is deliberate: your device tree is yours to arrange, while sensors are grouped by BluConsole's own organizations and zones, and the two do not line up — a room in your tree has no BluConsole zone that corresponds to it.

So a person scoped to one room can still attach any of your sensors to the lights in that room. If that matters for your business, tell us and we will look at it; nobody has needed it yet, and a half-measure that hides sensors from the picker without actually preventing anything would be worse than none.

Zones still earn their keep as a way to find a sensor: the Configuration page has a Zone filter above the available-sensor list.

The two limits on what you can grant

You will notice the screen offers you fewer options than the list in this manual describes. That is the point:

1. You can only grant permissions you hold. If you do not have manage_alert_profiles, you cannot give it to anyone.
2. You can only grant access within your own scope. If your grant sits on Main Site, every login you create sits on Main Site or below it.

The server checks both when it saves, independently of what the screen offered — so these hold even if something goes wrong in the browser.

You also cannot change your own scope or your own permissions. Someone with wider access has to do that for you; if you are the most senior person at your organization, that is BluLine.

Day-to-day management

• Reset Password when someone is locked out. It also signs them out of every device immediately, which is what you want if a laptop goes missing.
• Disable when someone leaves — it stops the login working, and ends every session they have, while keeping the record of who did what.
• Limit to one active session on a login means each new sign-in ends their previous one.

Managing your devices

The Configuration screen — naming your lights, and what each control on it does.

Configuration is the screen you will open most days. It shows one light at a time, the sensors feeding it, and the recent history of what it has been doing.

Choosing a light

The Light selector at the top lists every device your grant reaches. It is searchable — type part of a name or an ID and it filters.

Beside it:

Naming a light

Type into Name and move on — it saves by itself. Use the name people in the building would use, because it is what appears in alerts and in the event history. "Walk-in Freezer" beats 9F2B54E10C7D at six in the morning.

Choosing what it shows

Alert signal, beside Disable auto-updates, picks what this light shows for each alert state. Default is the standard green, amber, red and pulsing blue; any other entry is a signal from the Alert Signals page. It saves by itself, and the light shows the new looks at its next state change, or within the hour.

Disable auto-updates

This stops the alerting system evaluating this light. It keeps showing whatever it was last told to show — either its last alert colour, or the last manual command sent to it — and stops responding to readings.

Use it while a fridge is deliberately open for cleaning or defrosting, so it does not alarm for hours over a known event. Turn it back on afterwards.

If a device is missing

Devices appear here because of where they sit in your organization. A device you expect and cannot find is either not placed in a node your grant reaches, or has not been placed at all.

If it sits elsewhere in your organization and you hold manage_orgs and manage_devices, move it yourself from the Organization page. If you do not, ask whoever manages your organization — or BluLine if the device has not yet been handed over, since only BluLine can place a device that is not yet in your organization.

Attaching sensors

Telling a light which temperature probes it is responsible for, and which profile judges each one.

A light on its own displays nothing meaningful. It becomes useful when you attach sensors — the TDL temperature probes sitting in your fridges, freezers and rooms — so it has readings to judge.

The Configuration screen has two panels for this: Attached Sensors, which is what this light is currently watching, and Available Sensors, which is everything enrolled to your organization that is not yet on this light.

Attaching one

1. Select the light in the toolbar.
2. Find the sensor in Available Sensors. Filter by name, ID, organization or zone, or narrow the list with the Organization and Zone dropdowns.
3. Tick it — or several — and click Add Selected.

It moves to Attached Sensors and starts feeding this light immediately.

Select All, Deselect All and Invert work on whichever list you are in, which makes short work of a light with a dozen probes.

A sensor that is not in the list

Check for New Sensors asks BluNotify to re-read your organization from BluConsole instead of waiting for the hourly refresh. Use it when a probe was enrolled minutes ago. The update usually lands within a minute — the button is a request rather than an instant refresh, because BluConsole limits how often it can be asked.

If it still does not appear, one of three things is true:

• it has not been enrolled to your BluConsole organization yet — that is done in BluConsole, not here;
• it is in a BluConsole organization your account has not been linked to — which happens when a new site is enrolled upstream — in which case an administrator adds that organization to your customer record;
• your account has not been linked to any BluConsole organization at all, in which case the list says so.

Choosing the profile per sensor

Each attached sensor has a Profile column. This is the alert profile that decides what the readings from that probe mean.

This is per sensor, not per light — which matters, because one light often watches things with different tolerances. A single unit can hold a freezer probe on the Freezer profile and an ambient probe on something far looser, and each is judged by its own rules.

Leaving a sensor on (default) uses the system default profile, which is a real, editable profile rather than a special case.

Removing a sensor

Tick it in Attached Sensors and click Remove Selected. The light stops watching it immediately. The readings themselves are not deleted — only the relationship between that probe and that light.

Organizations and zones

Every available sensor shows its organization and its zone, and both columns sort — click a heading.

An organization is how BluConsole groups your sensors at the top level. Many customers have several: sites enrolled separately, a company you acquired, or sub-organizations BluConsole keeps under a parent. All of them appear in the one list. A zone is a subdivision inside an organization, usually a room, site or vehicle — and plenty of sensors have none, which is why the Zone column is sometimes blank.

Above the list are two dropdowns that narrow it. Choose an organization and the Zone dropdown narrows to that organization's zones, so the two work together. Both are always shown, even when there is little to choose: with all your sensors in one organization the first option reads All organizations (1), and when none has a zone the Zone dropdown says No zones on these sensors. Sensors with no zone are listed under (no zone).

While you are looking at every organization at once, zone names are shown as Organization — Zone: two organizations can easily both have a zone called "Freezer", and the prefix is what tells them apart. Pick an organization and the prefix goes away.

The free-text box below searches all four columns at once, which is usually faster than the dropdowns when you know part of a name.

Neither dropdown restricts anything: everybody in your account sees every one of your sensors. They are there to make a long list navigable.

Where the temperature limits come from

Not from this screen. Each sensor's acceptable range is configured in BluConsole and reaches BluNotify with the readings themselves. What you choose in BluNotify is which profile interprets a breach of that range — how many bad readings in a row it takes to advise, to warn, and how long silence means stale.

A sensor marked no limits in the Available list has not yet reported to BluNotify, so its range is not known here. You can still attach it, and it will start working the moment its first reading arrives — but until then it cannot raise a temperature alert. If it stays that way, the probe is not reporting.

Alert profiles

The rules that turn readings into an alert state — how many bad readings mean trouble, and how quickly.

A profile is the rulebook a sensor is judged by. It does not set the temperature limits — those come from BluConsole with the readings. It decides what a breach of those limits means: how many bad readings in a row before the light advises, how many before it warns, how long silence has to last before the reading is treated as stale.

Every install ships with three: Default, Freezer and Cooler. The default is a real, editable profile — not a special case — and every sensor without an explicit choice uses it.

Creating one

Click + New, give it a name and a description that says when to use it.

Rules

A profile is an ordered list of rules, evaluated top to bottom, first match wins. Each rule is one or more conditions that must all hold, and the level to assign if they do.

The metrics available to a condition:

Default level is what applies when no rule matches.

Order is everything, because the first match wins. The shipped ladder reads:

1. Fewer than 3 readings → INSUFFICENT_DATA
2. Newest reading older than 30 minutes → STALE_DATA
3. Newest reading not a breach → CLEAR
4. 3 or more consecutive breaches → WARNING
5. 2 or more consecutive breaches → ADVISORY

with a default of CLEAR. Note that rules 4 and 5 must be in that order: put the 2-breach rule first and it matches everything the 3-breach rule was meant to, and nothing ever reaches WARNING.

Test before you save

The Test this profile box takes sample metric values and tells you which level the profile assigns and which rule matched.

Try the case you are worried about: two breaches, three breaches, a sensor that went quiet an hour ago. It is far quicker than waiting for a real fridge to misbehave.

Saving, cloning and history

Save stores the profile and bumps its version. Clone copies it as a starting point — the usual way to build a variant is to clone the closest existing profile and adjust it, rather than starting from nothing.

Revision history lists previous versions, so a change that turns out to be wrong can be understood and undone.

Delete removes a profile no sensor is using. One still in use is refused, and the screen says by how many sensors — move them to another profile first. (A system administrator may delete it anyway; those sensors then fall back to the default.) The default profile itself cannot be deleted.

Applying it

A profile does nothing until a sensor is set to use it. That happens on the Configuration screen, in the Profile column of the Attached Sensors panel — see the previous chapter.

Alert signals

What a light shows for each alert state — the default looks, and how to give a light its own.

An alert profile decides which state a light is in. An alert signal decides what the light shows in that state.

Every light starts on the default signal:

No or bad data covers the four states in which the temperature cannot be judged — no sensors attached, too few readings, readings gone stale, or a state that could not be determined — and they share one look.

Creating one

Open BluNotify › Alert Signals and click + New. A new signal starts with the default's looks; change the entries you want to be different, give it a name, and Save.

Each entry takes any effect the light can show: solid, pulse, chase, toggle, BluChase, and the then solid versions, which animate for a set time and then hold a colour — once, or again every Repeat every (s) seconds. The Payload line under each entry is the command the light will receive. A value the light would refuse is flagged under its entry, and the signal cannot be saved until it is fixed. No period may be shorter than 0.1 seconds.

Giving a light its signal

On the Configuration screen, pick the light and choose its Alert signal (see Managing your devices).

Default puts it back on the default signal. A light whose signal was chosen by an API partner shows Managed elsewhere, and keeps that signal until you pick another.

When a change shows

A light shows a new signal, or an edit to its signal, at its next state change, or within the hour at the latest. An animated then solid look is not restarted by that hourly pass unless the look itself has changed.

Who can do what

• Anyone with view_data can see the signals.
• Creating, editing and deleting your account's own signals needs manage_alert_signals, which is part of the Account Admin bundle.
• Choosing a light's signal needs manage_devices, like naming the light.
• The default signal and global signals (made by BluLine) are read-only for customers.

Deleting one

A signal can be deleted while lights are showing it: they go back to the default signal. The confirmation says how many lights that is.

Moving a light to another customer

When an administrator transfers a light to another customer, its signal goes back to the default along with its sensors. A move within your own organization keeps it.

Administrators can edit the default signal — everything except its name, and it cannot be deleted — which changes every light without a signal of its own within the hour. Signals an administrator creates are global: every customer can choose them.

Event history

The audit trail of every state change, and why each one happened.

The Events panel at the bottom of the Configuration screen records every time a light changed state, and why.

Each row gives you the time, which light, the change (from which state to which) and the reason — which sensor drove it, and what about that sensor's readings triggered the rule.

Filter by light, state or reason to narrow it. Clicking a row opens the full detail, including the metric values as they stood at the moment the rule matched.

That detail is a snapshot: it is written when the state changes and is not updated while the light stays in that state. So clicking a light's most recent event also shows Now at the top — what the light is evaluating to at this moment, how many of its sensors are in each state, and which sensors are holding it where it is. Below that, under When this changed, is the original snapshot. A light that went to Not enough data yet when new sensors were attached, for example, keeps listing every sensor in its snapshot as having no readings; Now shows which of them are still short.

Reading a sequence

Events are most useful read as a run rather than one at a time. A typical excursion looks like:

14:02   Front Display Cooler   CLEAR → ADVISORY   rose above 8.0 °C
14:17   Front Display Cooler   ADVISORY → WARNING breached on 3 consecutive readings
17:42   Front Display Cooler   WARNING → CLEAR    back within range

That tells you the door was open for about three and a half hours, that the system noticed within a quarter of an hour, and that it resolved without anyone's intervention.

A STALE_DATA entry means the readings stopped arriving, not that the temperature was wrong — the probe, its hub or the network went quiet. It is a different problem with a different fix, and it is worth learning to spot the difference at a glance.

What events are for

Three things, mostly:

• Proving the cold chain. An auditor asking whether anything went out of range last month is asking for exactly this list.
• Explaining an alert. Somebody says the light was red this morning; the history says when, for how long, and which probe.
• Tuning your profiles. A light that flickers between ADVISORY and CLEAR all day is telling you its profile is too sensitive for where it sits.

Retention

Events are kept indefinitely — they are small, and they are the record. The underlying temperature readings are kept hot for 14 days and archived after that, so an event from three months ago still reads correctly even though the individual readings behind it have been moved to long-term storage.

Manual control

Driving a light and its sound by hand — and what that does to the automation.

Sometimes you need to drive a light directly: to prove a unit works during a walkthrough, to find which physical box a name refers to, or to silence something while a known problem is dealt with.

Open a light's control page from Control Light ↗ on the Configuration screen, or by scanning the device's QR code with a phone.

What the controls do

Light — Green, Amber, Red, Off. Sets the display directly.

Visual notification — Active or Off. Whether the unit uses its attention- getting visual pattern.

Audible notification — an alert tone, or a spoken alert in English, French or German, or Off.

The page has no relay control: the unit's dry relay contact is not driven from manual control.

Every press sends the command immediately, without reloading the page, and the last command line under the header records what was sent and when — useful when several people have access to the same unit.

What happens next

A manual command sets the light now. It does not stop the automation: at the light's next state change, or on the hourly pass at the latest, the automation sets the light back to what its readings say, overwriting what you sent.

That is usually what you want for a quick test. It is not what you want if you are trying to hold a light in a particular state.

To hold it, use Disable auto-updates on the Configuration screen. With that set, the automation stops evaluating this light and keeps republishing the last command it was given — which, after you have driven it by hand, is your command. The light stays where you put it until you turn auto-updates back on.

Finding a physical unit

The reliable way to work out which box on the wall is "Vaccine Fridge": open its control page and press Red, then walk until you find the red one. Press Green afterwards, or leave it: the automation puts it back within the hour.

Energy Monitoring

Reading a BluEM meter — how much energy a circuit used, what it is drawing, and what the supply feeding it looks like.

If your organization has BluEM energy meters, the Energy Monitoring screen shows what they have measured. It appears in the menu only if your login can see at least one meter — and if meters are all your login can see, it is the screen you land on when you sign in.

How a meter reports

A BluEM meter reads the circuit about once a second and, every reporting interval (15 minutes unless your installer set another), stores a summary of that interval: the average, the lowest and the highest of each quantity, and its lifetime energy counter. It keeps those summaries on the device until the server confirms it has them, so a lost connection delays the history — it does not lose it.

Everything in the charts and every kWh figure comes from those interval records.

Choosing a meter and a window

The Meter picker lists your meters. The window selector — 6 hours up to a year — decides how much history is drawn. On a short window each point is one interval; on a long one each point is the average of several intervals, weighted by how long each lasted, and the chart heading says which.

Zooming in

To look closely at part of the history, drag sideways across any chart. Every chart on the page zooms to the stretch you selected, and the server re-reads it in finer detail, so a day's worth of hourly averages becomes interval-by-interval once you zoom into an afternoon. A bar in the Meter card then shows what is on screen, with ← Back to return to the previous view (you can zoom in several times and step back out) and Reset to return to the selected window. A selection shorter than ten minutes is widened to ten.

For an exact range, choose Custom… in the window list: enter a From and a To in your own local time and press Apply. The range must run forwards, span at least ten minutes and at most a year; the page says so if it does not. Choosing one of the preset windows again leaves the custom range.

While you are zoomed in or on a custom range the page stops refreshing itself, so the picture does not move under you; Reset starts the refresh again.

Energy used

The Used tile is the energy the circuit consumed over the window, in kWh, and the column chart shows it interval by interval. It is worked out from the meter's own lifetime counter: each interval's consumption is the rise in that counter since the interval before.

If the counter was reset during the window (a deliberate reset, or a replaced meter), the interval after the reset counts from zero rather than going negative, and the tile says the counter was reset.

The badges

Under the tiles, small badges appear only when something needs saying:

Latest interval

The Latest interval card is the newest record the meter has sent: the average voltage, current, power, frequency and power factor over that interval, when it ended and how long it ran. It is as fresh as the last interval to close.

• Get data now opens a small dialog with two choices:
  • Live reading (the default) asks the meter what it reads at this moment. The answer appears in the card within a few seconds: volts, amps, watts, power factor and frequency, whether the meter answered, and how long the answer took. It is shown on the page only. Nothing is stored and the interval in progress is not touched, so you can use it as often as you like — for example to check a new installation. One meter can be asked once every ten seconds.
  • Close the interval now and send it asks the meter to finish the interval in progress and send its record straight away. The card and the charts update a few seconds later, and the record is marked closed early. The next interval starts now. Use it when you want the last few minutes on record, not as a way to refresh the page.
• If the meter is offline, the page says so at once and sends nothing.

• Meter counter is the meter's lifetime energy total, in kWh.

Power & Current

Each solid line is the interval average. The Min/max button under the chart adds two dotted lines around each series — the lowest and highest reading inside the same interval — so a short spike that the average smooths away is still visible. On this chart they start out hidden (four dotted lines over two solid ones is a lot to read); press the button to show them. Hover for the values.

Click Power or Current in the legend to hide that line and read the other on its own scale; a hidden series is struck through in the legend, and its axis disappears with it. Click again to bring it back. The browser remembers which lines and whether min/max are shown, per chart, for the next time you open the page.

Power and Current share one chart on two scales — watts up the left, amps up the right. They are the same event measured two ways, and the chart exists so you can read both at one instant. The vertical distance between the two lines is not a quantity; what is real is the two lines changing shape relative to each other: current climbing while power does not is falling power factor, which is charted below.

Supply Quality

These describe the supply feeding the circuit rather than the load drawing on it, each with its in-interval lowest and highest as dotted lines around the average. Here the dotted lines are shown to start with; each chart's Min/max button hides them, and the browser remembers the choice.

Voltage is drawn on a band around the middle of its own readings rather than from zero, so a steady supply draws flat and a sag pushes the band's edges apart.

Frequency is set by the grid, not by anything on your circuit, and holds within a fraction of a hertz of nominal.

Power factor is how much of the current is doing useful work, on a fixed 0 to 1 scale. It is charted only for intervals in which something drew at least 5 W; with nothing drawing there is no ratio to measure.

What to look for

Energy report

The Energy report card at the bottom of the page sums up one meter over a period of whole days — a month's bill, a week's trial of a new machine, or a single day. Choose a From and To date (they start as the first of this month through today), optionally type your electricity Rate in $/kWh, and press Generate. The report appears in the card:

• the total kWh for the period, with an estimated cost beside it when you entered a rate — the cost follows the rate as you type it, and the rate is never stored or sent anywhere;
• a day-by-day chart and table: kWh (and cost) per day, how much of each day the meter covered, and notes for a day the counter was reset, a day that follows a gap in the meter's records (its first surviving interval carries the energy used since the last one before the gap, so the note says where that energy starts — possibly on an earlier day, or before the period), today (so far) and days with no data;
• power & supply: the peak power and the interval it fell in, the average power over the period, voltage average and range, frequency range, and the average power factor (over intervals drawing at least 5 W);
• data completeness: intervals recorded against the number expected, the share of the period's time that was measured, and counts of missing, quarantined, no-known-time, meter-silent and closed-early intervals, and counter resets.

The days are calendar days in your browser's time zone, which the report names, and each interval counts toward the day that holds most of it. A period may be up to a year long and may not start after today; a period that includes today is judged on the hours that have happened so far. The report is drawn on screen only, does not refresh itself, and is cleared when you choose another meter.

Resetting the energy counter

Some logins — normally only your system administrator — have a red Reset energy counter… button. It zeroes the meter's lifetime energy total, which cannot be undone; you are asked to type the meter's ID to confirm, and the screen then waits for the meter to report that it has done it. The history already stored is kept, and consumption is counted from the reset onwards.

Retention

Interval records are kept indefinitely, so the window picker reaches back a full year.

Alert states

The states a light can be in, and what each one shows by default.

Each light displays one of the following states at any given time. The descriptions below are the rules of the system (default) profile as shipped, based on how many of the three most recent measurements are outside the configured temperature range (min_temp_c – max_temp_c from BluConsole). A custom alert profile can change when each state is raised, and an alert signal what each state shows; neither changes what the states mean. The looks below are the default signal's, which every light shows until it is given a signal of its own.

• CLEAR – Solid Green — The most recent measurement is within the acceptable temperature range. All is well.
• ADVISORY – Solid Amber — The 2 most recent measurements are both outside the acceptable range. The temperature has been out of range long enough to warrant attention, but has not yet reached the sustained breach threshold.
• WARNING – Solid Red — All 3 of the 3 most recent measurements are outside the acceptable range. This represents a confirmed, sustained temperature breach requiring immediate action.
• INSUFFICIENT DATA / STALE DATA / NO SENSORS – Blue Pulse — The system cannot make a definitive determination. Possible causes: fewer than 3 measurements have been recorded, the most recent measurement is older than 30 minutes (sensor may be offline), or no TDL sensors are assigned to this light.

State Evaluation Detail

The conditions below are those of the system (default) profile as shipped (rules are checked top to bottom in profile order). The light output is the default signal's; a light with its own alert signal shows that signal's instead:

Breach detection logic

How a temperature reading becomes an alert state.

The BluNotify Connector is a background service that runs continuously. Measurements stream in from BluConsole over RabbitMQ as they are reported (with an automatic REST-polling fallback if the stream goes quiet). Every 2 minutes the connector re-evaluates every TDL assigned to a BluNotify light — whether or not new data arrived, so a silent sensor is noticed on schedule — and commands the light to display the appropriate alert colour. Each sensor is evaluated using its assigned alert profile.

Thresholds and timing

Where the temperature limits come from and how often they are evaluated.

Temperature Thresholds

Minimum and maximum acceptable temperatures are defined in BluConsole and fetched automatically. A measurement is considered a breach if:

• temperature < min_temp_c (too cold), or
• temperature > max_temp_c (too warm).

Both low and high excursions are treated equally – either triggers the advisory/warning progression. To change the thresholds, update them in the BluConsole portal; BluNotify picks up the new values at the next sync cycle.

Timing Summary

Design intent – graduated response The two-stage alert progression (ADVISORY then WARNING) is intentional. A single out-of-range reading may be transient (door briefly opened, sensor warm-up). ADVISORY signals "watch this" while WARNING signals "act now." This reduces false alarms while still ensuring that a sustained breach is unmistakably visible.

Notifications

What the system sends when a light changes state — and what it deliberately does not.

The light is the alert

Read this first. BluNotify does not send you an email, text message or push notification when a sensor goes out of range. The alert is the device: the light changes colour, and the chime sounds if one is configured. That is by design for this release, not an outstanding fault.

A device shows its state continuously and updates within a couple of minutes of a reading changing it, so a unit placed where people actually walk past it is the notification. Placement matters more than it would in a system that also emailed you: a device in a back room nobody visits is a device whose alerts nobody sees.

The Events screen keeps the full history of every state change, with the readings that drove it, so nothing is lost if the light was not seen at the time — see Events.

Customer-facing alert notifications (email, and per-account routing rules) are planned; they are deliberately not part of this release rather than missing from it.

What the system does send

Device offline / back online — only if you ask

Click your name at the top right, choose Notifications, and tick Email me when my devices go offline or come back online. It is off until you turn it on, and nobody can turn it on for you. Once it is on, you get an email when a device you can see:

• goes offline and stays offline for about 20 minutes. Brief drops are not reported: a device that loses its connection and is back a few minutes later never emails you, although the device lists show it offline while it is.
• comes back online after one of those emails.

BluEM energy meters are not covered: no connection email is sent for them.

Changes that happen together — a site losing power, say — arrive as one email listing every device. The email goes to the address on your login; if the Notifications window says your login has none, ask your administrator to add one.

Daily health report

This goes to the system administrator list configured at deployment — the people who run the platform, not the people who own a device.

A platform health report at 4:00 AM ET daily: server resources, database and broker status, ingestion heartbeats, archival bookkeeping, endpoint and certificate checks, and per-service error counts.

Note that both of the above are about the platform and its devices — "this unit stopped talking to us" — not about temperatures. A sensor reading out of range never produces an email.

Light and sound effects

The effect vocabulary a light understands.

Primary Light (Light 1)

Visual Notification Overlay (Light 2)

The secondary light channel provides an attention-getting overlay effect that can run simultaneously with the primary colour. It does not replace the primary light state.

Sound / Buzzer

Relay / Contact Output

The manual control page has no relay buttons. The relay contact itself (logical "1" closed, "0" open) can be used to trigger external systems, alarms, or door locks; it is driven from the administrators' Effect Designer or through the partner API.

Persistence of Manual Commands

All manual commands are published to the MQTT broker with the retained flag set. This means the broker stores the last command for each channel and replays it to the device whenever the device connects or reconnects. The light will therefore return to its last manually commanded state after a power cycle or network outage – until the automated connector overwrites it on the next sync (or until the device is disabled, which prevents automatic overwrites).

Device overview

What the physical unit is and what is inside it.

The BluNotify physical device is a compact, wall- or surface-mountable indicator unit. It connects to the BluNotify MQTT broker over a local Ethernet or cellular (GSM) network connection and renders alert states as coloured light, audio chimes, and/or dry-contact relay output.

Outputs

Network Connectivity

Firmware details

What the LEDs mean, how the device fails over, and how to recover one by hand.

This section documents observable firmware behaviour useful to installers, support staff, and system administrators: what the device's LEDs mean at every stage of operation, how it manages and recovers its network connection, and what you can do with the unit in your hands when it cannot reach the platform at all.

Boot Sequence & LED States

When a BluNotify device is powered on it passes through several internal states before it is ready to display alert colours. The LED pattern visible during each stage is described below.

Startup LED Pattern Quick Reference

Detailed Boot Sequence

1. Hardware initialisation. LED drivers, relay, audio amplifier, and network interfaces start up.
2. State restore. The firmware checks for a previously saved effect state in non-volatile memory. If a state is found (e.g., after a soft reboot or power cycle), the device immediately resumes displaying that exact effect — including resuming animated effects such as pulses at the phase they were at before the reboot. No boot LED sequence is shown.
3. Boot sequence (first boot only). If no saved state is found, the device plays the 4-colour Bluline chase LED pattern and optionally plays a boot audio chime.
4. Network connection. The device connects using its configured interface (Ethernet, Wi-Fi, or GSM/cellular). See Network & Failover for fallback behaviour.
5. Credentials. The device derives its MQTT password from the root secret held in its eFuse. A unit that was never provisioned has no usable credential and cannot get past this step — it does not request one over the network. The LED continues to show the boot chase pattern.
6. MQTT connection. The device connects to the MQTT broker. The broker immediately replays any retained commands, so the device returns to its last server-commanded state without waiting for the next connector sync cycle.
7. Telemetry published. The device sends a telem/conn message containing its firmware version, IP address or cellular details, and signal strength. The platform shows it as connected from its first message; a "back online" email goes only to people who turned on connection emails, and only after an "offline" one (see Notifications).
8. Normal operation. The device enters its main loop: executing light/sound/relay commands as they arrive and responding to heartbeat pings from the server.

Tip – expected boot time On GSM (the default), the device typically completes boot and connects within 60–90 seconds while the cellular modem registers on the network. On Ethernet or Wi-Fi, connection is usually established within 15–20 seconds. If the device shows the boot chase pattern for longer than 3 minutes, check network connectivity and consult the Network & Failover section.

Network & Failover

The device's active network interface is controlled by the connectionMode setting. The default is GSM/cellular. Ethernet and Wi-Fi can be configured as the primary interface where a wired or wireless connection is preferred; if either fails, the device automatically falls back to GSM.

Automatic Failover

Every device carries a cellular modem, so a broken local network never strands it:

• Wi-Fi or Ethernet → cellular. If a boot's first connection on Wi-Fi or Ethernet has no MQTT session after 5 minutes — the network never came up, or the server never answered — the device switches to cellular for the rest of that boot. The switch is not saved: after 60 minutes on cellular the device restarts and tries its own interface again. A device whose Wi-Fi is gone for good is therefore offline about 5 minutes in every hour, and stays reachable the rest of the time, so its Wi-Fi details can be corrected remotely.
• Cellular: private VPN → public endpoint. Cellular devices connect through the 1NCE private network by default (gsmEndpoint = vpn). If the server never answers on that path at the start of a boot, the device uses the encrypted public endpoint for the rest of that boot and returns to the private path after 6 hours, or at the next restart.
• No connection at all. The device restarts and tries again. After four failed attempts in a row it waits before each new attempt — 1 minute, then 2, 4, 8 and 16, and at most 30 minutes — so a device in a coverage gap does not get its SIM suspended by the carrier. It reconnects on its own once coverage returns.

Note – GSM SIM card GSM-equipped devices use a 1NCE IoT SIM card preconfigured for the APN iot.1nce.net (the built-in 1NCE APNs are used if a wrong APN is configured). The SIM must be active.

Switching Network Interfaces Remotely

A device that is still online can be moved between interfaces without a site visit. An administrator does this from the Device Console's Settings tab: change connectionMode to eth, wifi or gsm — setting the Wi-Fi SSID and password first if moving to Wi-Fi — and then reboot the device from the Lifecycle tab. The new interface takes effect on that reboot.

⚠️ Getting this wrong strands the device. A unit told to use a network it cannot reach has no way back over the air. Recovering it means the configuration portal — someone physically present with the unit. When in doubt, leave it on GSM.

IP Address Configuration

By default all interfaces use DHCP. Static IP addressing is available for Ethernet and Wi-Fi connections. Static IP settings are stored in non-volatile memory and persist across reboots. To revert to DHCP, clear the static IP setting.

Watchdog & Auto-Recovery

The firmware includes a stale-connection watchdog that monitors the time since the last MQTT message was received. This protects against silent network failures where the device appears connected but is actually receiving no traffic.

What to do if a device shows a persistent blue pulse A blue pulse that does not clear within 5–10 minutes after the platform is confirmed healthy indicates the device has lost its MQTT connection; the device reconnects by itself (see Automatic Failover above), so a quiet server alone never makes it restart. If the device has been blue-pulsing for more than an hour and does not recover, check physical network connectivity and consider issuing a manual reboot command from the admin dashboard.

Physical Recovery Controls

Everything above happens on its own. These are the things you can do with the unit in your hands and no network at all — the only recovery path when a device cannot reach the platform.

The boot-held button ladder

Hold the button while powering the device on and keep holding. The action is chosen by how long you hold it, and the LED tells you which rung you are on before it commits.

⚠️ The 5-second hold wipes credentials. A wiped device cannot rejoin the platform until it is reconfigured — it does not re-provision itself, and its eFuse root secret is not what gets erased, so nothing is lost permanently, but the unit is offline until someone sets it up again. Release the button before 5 seconds if you only meant to open the configuration portal.

Let go the moment the LED shows the rung you want. If you overshoot, keep holding past the next rung rather than releasing on the one you did not intend.

Forcing the cellular link

On a running device, holding the button forces the unit onto its cellular (GSM) interface regardless of what connectionMode says. This is for a site where the wired or Wi-Fi network is the thing that is broken: it gets the device talking again without a laptop, a portal, or a visit to the network cupboard. The device returns to its configured interface on the next reboot.

When to reach for which

Hardware Overview

Firmware compatibility Always use firmware binaries built specifically for this device. Flashing a binary compiled for a different hardware variant will result in incorrect pin assignments and device malfunction.

Sessions and security

How sign-ins are tracked, how they end, and how access is revoked.

Sessions

Signing in creates a session, stored server-side and tracked by a cookie. A person may be signed in from several places at once — a workstation, a phone, a tablet in the store room — and each is its own session.

That is the default because it matches how people actually work. Where it is not wanted, Limit to one active session on a login makes each new sign-in end that person's previous one.

Sessions expire on their own eight hours after sign-in, whether or not they are in use; activity does not extend them.

Ending sessions

Changing a password ending every other session is deliberate: it makes a password change a complete answer to "I left myself signed in somewhere", rather than a partial one.

Administrators can see every current session on the Active Sessions panel of the Users page — who is signed in, from how many places, and when each was last active.

Ending a session removes it from that panel entirely, which is why that panel is not a record. The Sign-In History panel below it — also administrators only — is: every attempt, successful or failed, with the address it came from, kept for a year. It is the place to look after the fact, and the only place a failed attempt is visible at all.

How permissions are enforced

Three things are true of every check, and they are worth knowing because they explain behaviour you will otherwise find surprising:

The server decides, not the browser. Menu entries and buttons are hidden according to your flags as a convenience, but every page and every API call re-checks independently. A URL typed by hand, an old bookmark or a link from a colleague cannot get you into something your grant does not cover.

Checks happen per request, not per session. A revoked permission takes effect on the next page load, not when the cookie eventually expires. Removing someone's access is immediate in practice.

Scope is applied in the data layer. When a screen shows you nothing outside your part of the organization, that is not filtering after the fact — the rows were never returned. There is no request that produces another customer's data for a login not entitled to it.

Passwords

Passwords are stored hashed, never in a recoverable form. Nobody — including BluLine — can read an existing password; a lost one is reset, not retrieved.

The Generate button on the user dialogs produces a strong random password. Use it, and send the result to the person through whatever channel you would send any other credential.

Transport

All traffic is over HTTPS. Device traffic to the broker is over TLS. Session cookies are marked secure and are not readable by page scripts.

Data flow

A reading’s path from sensor to light, end to end.

 ───────────────────────────────────────────────────────────
 │        BluConsole Cloud (RabbitMQ + REST API v1)        │
 │  (TDL sensor data: temperature, RSSI, battery, GPS)     │
 ───────────────────────────┬───────────────────────────────
                            │  Measurement stream (RabbitMQ,
                            │  with HTTP-polling fallback)
                            ▼
 ───────────────────────────────────────────────────────────
 │     BluNotify ingestion + Connector (background svcs)    │
 │  1. Store measurements in PostgreSQL as they arrive     │
 │  2. Every 2 min: evaluate each assigned TDL against     │
 │     its alert profile (CLEAR / ADVISORY / WARNING / …)  │
 │  3. Publish light command to MQTT broker                │
 ───────────────────────────┬───────────────────────────────
                            │  MQTT publish (cmd/light1)
                            ▼
 ───────────────────────────────────────────────────────────
 │           MQTT Broker (device.blunotify.com)             │
 │  Eclipse Mosquitto — stores retained commands            │
 ───────────────────────────┬───────────────────────────────
                            │  MQTT subscribe
                            ▼
 ───────────────────────────────────────────────────────────
 │           Physical BluNotify Device                      │
 │  Receives command → changes LED colour / plays sound    │
 │  Publishes sysresp/ pings and telem/conn on connect     │
 ───────────────────────────────────────────────────────────

 ───────────────────────────────────────────────────────────
 │       Device Maintenance Service (fleet recorder)        │
 │  Records device messages → online / offline at once     │
 │  Pings every device every 10 min (25-min backstop)      │
 │  Emails opted-in users after 20 min offline             │
 ───────────────────────────────────────────────────────────

 ───────────────────────────────────────────────────────────
 │         App Server (app.blunotify.com)                   │
 │  Admin & user dashboards · REST API · manual control    │
 │  Reads/writes PostgreSQL · publishes to MQTT broker     │
 ───────────────────────────────────────────────────────────

Configuration reference

The settings that govern a running install.

Glossary

BluNotify Product Support Manual  ·  BluLine Solutions  ·  © 2026  ·  Revision 2.0