TViewService now installs as a 64-bit program in C:\Program Files\2DI\TViewService. Earlier versions installed to C:\Program Files (x86)\2DI\TViewService; upgrading moves it for you, and your readings, alarms, users and settings stay where they are.

The installer now also adds a Windows Firewall rule so browsers on other computers can reach the dashboard. If you previously allowed TViewService through the firewall yourself, that rule pointed at the old folder and is no longer needed.

Every Excel export now opens with an Export Info sheet: an export ID, who exported it, when, the device and date range, the device's clock difference at the time, the units used, and the TViewService version. Each export is also recorded in the Audit Trail under the same ID. The sheets are read-only to prevent accidental edits, and the Device Events sheet shows reviewers by name.

A new Audit Trail page for administrators records who did what, and when: sign-ins, changes to users, devices and settings, alarm reviews, data exports and data deletions. Entries are kept for seven years and can't be edited or removed from within TView.

New passwords must be at least 10 characters; existing passwords keep working, and the Users page shows which ones are shorter. Repeated wrong passwords lock that account for a few minutes. Users are signed out after 30 minutes without activity, except the View Only role, so wall-mounted dashboards stay up. A deleted user's login ID can't be given to someone else. All of these are adjustable under System Settings.

Readings and alarm times come from each TV2's own clock, which can drift from the server's. Data Export, charts and the Alarms page now say which clock each time uses, and Data Export picks its default range and shows the difference using the device's clock, so recent readings are never left out.

Removing a device used to discard its alarms and review comments, even when you chose to keep its data. They are now kept, and come back if the device is registered again. If you choose to delete a removed device's readings, they are set aside for 30 days before being permanently deleted, so a mistake can be undone with our help.

If the service can't start after an upgrade, choosing Cancel in the installer now puts the previous version back, running, with its data. This protects upgrades from 1.0.0 onward.

A mistyped alarm limit far outside a sensor's range no longer flattens its chart. Charts now fit the readings; a limit far from them is shown at the edge of the chart with an arrow instead of stretching the scale.

Pages are grouped into Monitor, Data, Admin and System, with icons. The sidebar shows how many devices are online, and administrators see a count of sensors that have no alarms set.

Every night, TViewService saves a safety copy of each device's recorded readings. It used to keep the last ten copies, which on a large installation could take up several gigabytes. It now keeps only the most recent copy, and removes the older ones automatically when the upgraded service starts.

Your readings are still protected: each TV2 keeps its own history, and TViewService fills in from it automatically if anything is ever lost on the server.

When an administrator deletes old readings on the Data Maintenance page, the monthly log.txt files for those months are now deleted as well, so the disk space is actually freed. The preview shows how many files and how much space before you confirm.

TViewService numbers its internal records of your sensors, and that number grows every time the device configuration is saved. After enough saves it grew past a limit that earlier versions could not read. From then on the service stopped every time it tried to start, and installing an earlier or newer version failed with “service failed to start”.

This version reads those numbers correctly and starts normally. Your devices, users, settings, alarm history and recorded data are unaffected and don't need to be re-entered.

An internal change in 0.1.19 was not applied correctly when upgrading from an earlier version, which could stop anyone signing in. If you upgraded to 0.1.19 and could not log in, this is the cause, and upgrading to 0.1.20 corrects it.

No data is affected, and nothing needs to be re-entered — your devices, users, settings and alarm history are all unchanged. We have also added a check that prevents this class of mistake from reaching a release again.

When an upgrade changes how TViewService stores its settings, it now saves a copy of your settings database first. If you ever need to go back to the previous version, 2DI support can restore that copy so the older version runs again with your users, devices and alarm history intact.

A new TView mark — a thermometer inside a humidity dial — now appears at the top of the menu, on the sign-in screen, and as the icon on your browser tab, in place of the plain “TView” text.

This is the first step of a wider visual refresh to bring TView in line with the 2DI look; colours and typefaces will follow in a later update.

If the TView service was restarted while you had a browser tab open, the tab would show a “reconnecting” message and stay there, needing a manual refresh before it worked again.

The page now reloads itself once the service is back, usually within a few seconds. While it is waiting it says so, and makes clear that monitoring carries on regardless — a browser tab losing its connection does not stop the service collecting readings or sending alarm emails.

Browsers were holding on to the previous version’s stylesheet after an upgrade, so appearance changes we shipped might not have shown up for you until you happened to force a refresh. Upgrades now serve the correct stylesheet straight away.

If anything has looked visually off since a recent upgrade, this is the likely reason, and it should now correct itself.

Saving on the System Settings page used to warn that “some changes may require a service restart”, even when none did. Email and other settings take effect immediately; the only setting that needs a restart is the web port, and that already asks you directly. Saving now simply confirms the settings were saved.

On System Status, the Idle Sleep entry is now called Sleep Prevention, which describes what it does rather than using “idle” in a way that could read as something being stopped.

While the computer running TViewService is asleep, nothing is collected and no alarms are detected or emailed. It is easy to miss, because when the machine wakes, TViewService fetches the readings it missed from your TV2s — so the data looks complete even though there was no alarm coverage for that whole period.

TViewService now asks Windows not to fall asleep on its idle timer while devices are being monitored. System Status shows an Idle Sleep entry so you can confirm it is working.

Please read this part. This only stops the automatic “go to sleep after X minutes of inactivity” timer. It does not stop sleep if someone chooses Sleep from the Start menu, if the battery runs critically low, or — most importantly — if you close the lid on a laptop. If TViewService runs on a laptop, set When I close the lid to Do nothing in Windows power options, or the machine will still sleep and you will still lose alarm coverage.

You could already add a custom note to a single TV2, which appears on that device’s alarm emails. There is now also a Global alarm email note on the System Settings page that is included on every alarm email, whichever device raised it — useful for an escalation phone number, who to call after hours, or wording your procedures require on every notification.

The global note appears at the top of the email, above the alarm details, so instructions are read first. A device’s own note still appears at the bottom. You can use either, both, or neither — leave the field empty and nothing is added, exactly as before. Limit 500 characters.

When registering a device, the network scan previously only offered the networks the TViewService computer is itself connected to. If your TV2s are on a different network segment — a separate VLAN, another building, or a dedicated instrument network — there was no way to scan for them.

The network dropdown now includes Other subnet..., where you can type a network to scan, such as 192.168.5.0/24. TViewService tells you how many addresses that covers before you start, and warns you if it is a large range that will take a while.

The only requirement is that this computer can already reach that network — if you could open a TV2’s web page in a browser on this machine, the scan can find it too. Networks larger than /16 are not accepted, to prevent a typo starting a sweep of many thousands of addresses.

Sensors that measure both temperature and humidity have been shown as a single card with both readings on one chart. You can now choose to see them as two separate cards instead, the way they used to appear.

The Temp+RH setting is at the top of the Dashboard, next to the temperature and pressure unit choices. It is your own setting — it does not change what anyone else sees — and it is remembered for next time. The collapsed view follows it as well.

Nothing changes unless you change it: existing dashboards keep the combined card. The setting only appears if you have a sensor that measures both.

On Data Export → View Chart, the red and green marks showing where alarms started and cleared now respond to the mouse. Hover one and you will see when the alarm happened, the most recent comment left when it was reviewed, and who wrote it and when — without leaving the chart to look it up on the Alarms page.

If an alarm has been reviewed more than once, the most recent comment is shown along with a note of how many earlier ones there are, so you know to open the Alarms page for the full history. An alarm that was reviewed without a comment says so, so you can tell it apart from one nobody has reviewed yet.

If alarms happened close together, their marks may sit on top of each other and be hard to hover individually — choosing a shorter date range spreads them out.

Where TViewService shows that a device’s clock differs from this computer’s — on the Dashboard and on System Status — hovering the value now explains what that difference means and, importantly, what not to do about it.

A difference is usually drift or daylight saving. Your readings and alarm times are recorded using the device’s own clock, so nothing is recorded at the wrong time. Changing a TV2’s clock can cause data loss — please see the user manual before adjusting one.

Times in TViewService emails come from two different clocks. Alarm times come from the TV2 that raised the alarm. Review times, and the time a sensor change was noticed, come from the computer running TViewService. If those clocks differ, for example across a timezone, the times in one email could disagree with no explanation.

Each time now says which clock it is from: (device clock) or (server clock). In the alarm-reviewed email, where the alarm time and review time sit on neighbouring lines, both are labelled. That matters if you keep these emails as part of your records.

Your TV2 devices keep their own clocks, and the times they record — readings and alarms alike — come from those clocks rather than from the computer running TViewService. If a device sits in a different timezone from that computer, or its clock is simply set differently, the two will not agree, and until now there was no way to see that.

System Status now shows a Device Time column with the device’s own clock, and a Clock Offset column telling you how far it is from this computer — aligned when they agree. On the Dashboard, any device whose clock differs by more than five minutes shows Device Time: 12:07 PM (+1h 00m) next to its location. Devices in step with the server show nothing, so this stays out of your way unless there is something to see.

TViewService only reports the difference — it does not change anything. A gap may be a perfectly normal timezone difference or a clock that needs attention, and only you can tell which. Do not reset a TV2’s clock simply to close a gap — changing a TV2’s clock clears the readings stored on the device. If a device’s clock does need correcting, contact 2DI support first so the stored readings can be collected beforehand.

This is the first step of a wider piece of work to make clear, everywhere in the application, which clock a displayed time came from.

The rate limit that stops a flip-flopping sensor from flooding your inbox was being applied to emails that were never actually sent. If an alarm had no subscribed recipients, the limiter still counted it as “sent” and stayed quiet for the rest of the window. The practical effect: after fixing a user’s notification settings, alarm emails could stay silent for hours afterwards for no visible reason, and the service log gave a misleading explanation. The limiter now only counts emails that genuinely go out. Sending a test email from the SMTP settings page was never affected and still is not.

The Data Maintenance page deletes old sensor readings — the logged measurements behind the charts and Data Export. It has never removed alarms, but the wording said “rows” and was easy to read as covering both. The page now says exactly what it deletes and states plainly that alarm history, including alarms you have reviewed or hidden, is unaffected. Hiding an alarm removes it from the Alarms list only; the record is kept. There is currently no feature for permanently removing old alarms; if you need one, contact 2DI support.

The Notification Preview page now opens with a list of every user who will not receive any alarm email as currently set up, and why — no devices assigned, no sensor subscriptions, no email address, or subscriptions that don’t match the devices they are allowed to see. Previously a user could look correctly configured on the Preferences page and still receive nothing, with no way to tell short of waiting for an alarm that never arrived. Useful when setting up a group of accounts: fix one, press Re-check, and watch it drop off the list.

If an alarm fires and nobody is subscribed to that sensor, the Admin Events page now shows a warning naming the device and alarm type, and pointing you at the notification settings to check. Previously this situation was recorded only in the service log file, so checking Admin Events for email problems correctly showed nothing at all — the most common cause of missing alarm emails was the one thing that page could not tell you about.

On the Alarm History page, the count on each device tile included alarms that had been hidden, while the list itself excluded them. So hiding every unreviewed alarm emptied the list but left the tile still reading “20 unreviewed”, which looked as though the hide had not saved. The tile now counts exactly what the list shows. Note that tile totals will drop for devices with a lot of previously hidden alarms — that is the corrected count, and no data has been lost.

When reviewing a batch of alarms that share the same explanation, you no longer have to open each one and retype the note. A Comment for all selected to be reviewed box now sits above the alarm list: type the note once, tick Reviewed on the alarms it applies to, and submit. Anything you typed into an individual alarm's own comment box still wins, and alarms that already carry a comment from an earlier review keep it. The comment is recorded against each alarm individually, so per-alarm history and exports are unchanged.

Marking an alarm as reviewed could appear to do nothing. On a sensor that measures more than one thing (for example a combined temperature and humidity sensor), if only one of its readings had ever gone into alarm, the service looked for those alarms in the wrong place when saving your change — so the review was discarded without any error. Affected sensors failed every time rather than occasionally, which is why retrying never helped. Reviews, comments, and hides now save correctly on all channels. This problem was present in earlier versions too, not something introduced by the recent updates.

Submitting a comment, review, or hide could quietly do nothing, so there was no way to tell whether a review had actually been recorded without refreshing the page and checking each row. Every submit now shows a confirmation of how many changes were saved, or a clear message asking you to refresh and try again if any of them could not be saved.

If adding a device fails while reading its sensor list, the service now records the full device response in its log file. If you hit this, send us the newest file from C:\ProgramData\2DI\TViewService\Logs\ and we can diagnose it directly rather than asking you to re-run the attempt and capture more information.

A sensor that repeatedly crosses in and out of its alarm threshold used to generate a fresh alarm email every time. Emails for the same sensor and alarm category are now collapsed inside a dedup window (set from System Settings, defaults on) so one misbehaving sensor can't flood the notification list.

Admins can now be emailed when a sensor's serial number changes on a known port (typical swap), when a sensor gets moved between ports on a TV2, and when a sensor is physically unplugged (the server now surfaces this as an alarm even though the TV2 itself doesn't flag the unplug reliably). Opt-in per user from the Preferences page.

A new page under Admin shows a rolling history of operational events an admin should see without opening log files: failed alarm-email sends, device offline transitions, sensor swaps and unplugs, out-of-range readings that got filtered as implausible, prune / re-sync actions. Recent activity at a glance.

If the configured Data Path for the server database becomes unreachable (offline network share, missing drive), the affected devices now show a red banner on the Dashboard explaining what's wrong and linking to System Settings. Polling for those devices quietly skips writing samples until the situation is fixed; correcting the Data Path retries the storage init without a service restart.

A Temp+RH combo probe now shows as one card with both readings side by side and a shared chart — temperature scaled on the left axis and humidity on the right — instead of two separate cards. Collapsed device tiles combine the pair the same way. Regular single-channel sensors look the same as before.

A new "Data Maintenance" page under Admin lets an administrator trim old sample rows off a device, mostly to keep the on-server database tidy. A safety cutoff of 30 days prevents this action from touching recent data. Preview shows what would be deleted before you commit; each prune is written to the Admin Events log for later reference. Note: because the TV2 itself keeps a history buffer on-device, some pruned samples may be re-downloaded on the next catchup cycle.

On the Data Maintenance page, a per-device Re-sync button pulls every sample the TV2 still has in its on-device storage and merges it into the server database. Useful when investigating missing chart data or after a bug fix that changed how samples are stored. Runs in the background — normal polling keeps going.

Adding a new sensor to a TV2 used to sign every user with notifications enabled up for its alarm emails automatically. Now new sensors start silent — each user opts in per sensor and per category from the Preferences page if they want emails from it. Existing subscriptions to sensors you already had are preserved.

The Reviewed column used to require hovering to see the ack time. Now the time and the reviewer's name are visible on the row so you can scan the list without hovering.

The alarm's End Time column now marks "(TV2 ack)" next to the timestamp when a cycle ended because someone pressed the acknowledge button on the device (as opposed to the reading returning to normal on its own). Same tag appears in the Data Export Device Events sheet.

Occasionally, one device would show no Registered-on date on the Devices page after re-adding it. The date now gets stamped consistently for every registration.

The alarm-count on the summary tile now matches the count you see after clicking into the device (previously the tile counted individual event rows and the page counted cycles).

When a sensor stays out of range long enough, the TV2 firmware treats the excursion as several back-to-back alarm events every few minutes. Previously each of those would show up as a separate row on the Alarms page. They now fold into a single cycle so the compliance officer sees one incident with one start time and one end time. The underlying audit log in the database still records every event the TV2 reported.

Some sensor alarms don't have a matching end event recorded on the TV2 hardware (a firmware limitation). Those used to sit marked "in progress" indefinitely. The Alarms page and Data Export now check the sensor's current state — if the sensor isn't currently alarming, the older row shows "ended (unknown)" instead. Only the alarm whose sensor is actually still in an alarm state stays "in progress".

On both the Alarms page and the Data Export "Device Events" worksheet, the alarm start and its matching end are now grouped into a single row with start time, end time, and duration. Reviewing an alarm cycle no longer means scrolling past two separate rows and mentally connecting them — the whole lifecycle is visible at a glance. Alarms still in progress show "in progress" in the end column. The full raw event history is preserved in the database.

After upgrading you may see a small number of older alarms marked "in progress" or "ended (unknown)". Those are cases where the matching end event never made it into the database (typically because the service was offline when the sensor recovered). The old view hid that by showing them as unrelated rows; the new view is honest about it. If it's noisy, a database reset clears the visible artifacts.

A new "Ack" column on the Preferences sensor list lets you subscribe to review notifications: when another user marks an alarm as reviewed on a sensor you're subscribed to, you get an email with the reviewer's name, the review time, and the reviewer comment. Handy for a compliance officer or supervisor who wants to see who's actioning alarms without having to log in and check. On by default (uncheck the Ack box next to any sensor to opt out); the user who did the acknowledging is never emailed about their own action.

New user role between View Only and Admin. Reviewers can mark alarms as reviewed and add reviewer comments, but they can't hide alarms, register or edit devices, or reach any admin settings. Useful for a compliance officer or supervisor who needs to sign off on alarms without full admin rights.

Admins can now scope each non-admin user to a chosen subset of devices. Grant devices from the Edit User dialog on the Users page. The user's Dashboard, Alarms, Data Export, and history charts only show TV2s they've been granted access to; they also stop receiving alarm emails for devices removed from their access list. Admins always see everything.

New button next to Last Day / 7 Days / 30 Days for pulling the most recent hour of data without setting start/end manually.

Comments were saving correctly and appearing in the Excel export, but the Alarms page was showing them as blank when the page reloaded. Comments now show up on the Alarms page as expected.

The vertical alarm-event markers on the small dashboard mini- chart could drift left or right relative to the reading line whenever a device missed a poll cycle. Both are now positioned on the same real time axis so they stay lined up.

A new Preferences page (formerly Notifications) lets you set Temperature and Pressure to Follow device, which matches each sensor's display to whatever unit that TV2 is set to show on its own screen. Useful for sites that use Fahrenheit on some devices and Celsius on others — each dashboard card, history chart, alarm row, Excel export column, and alarm email reads in the unit its own device is configured for. You can still force everything to a single unit (°F, °C, inH2O, or hPa) if you prefer a unified view. Data Export has its own unit dropdowns so you can override the app-wide setting per export. The admin sidebar has been renamed from "Settings" to "System Settings" so it's easier to tell it apart from your personal Preferences.

Adding a new sensor used to make its history chart look stuck at the same temperature for a few minutes after it appeared. The chart now leaves a brief gap until the device finishes telling us about the sensor, then fills in real readings. The "Syncing" badge stays on through the gap so it's clear the device is still catching up.

If you opened a history chart while the device was still catching up, the chart sometimes stayed a few minutes behind even after sync finished. It now updates on its own as soon as sync is done.

Clicking 1, 7, or 30 days on a dashboard card used to remember the time you originally opened the dashboard. If you came back later and clicked it, the chart could end on the old time instead of right now. It always anchors to the present now.

A missing sample-fetch path meant that four new readings had to accumulate on the hardware before we would sync them to the server, leaving history charts up to four sample periods behind the device. New readings are now pulled as soon as they land, and opening a chart also nudges the system to check for anything new right away.

On combination temperature + humidity sensors, humidity alarms on the Alarms page were showing the temperature channel's threshold instead of the humidity threshold, and the humidity reading was being run through a Celsius-to-Fahrenheit conversion by mistake. Humidity now shows the correct threshold and no conversion is applied to the reading.

A newly-added "Needs power-cycle" flag could get applied to a device that was genuinely offline. A fix was implemented to distinguish between a fully offline device and one that is only partially responding, so only the partially-responding case gets flagged as needing a reboot.

The history of prior comments on an alarm now lists newest first on the Alarms page and in the Device Events sheet of the data export. Reading down walks backward through time toward the original entry.

Each alarm row on the Alarms page can now be expanded to add a short reviewer comment (up to 256 characters). Every change is saved into an audit history under the alarm so prior comments are never lost. A new optional setting on the Server Config page can require a comment when acknowledging an alarm — useful for customers whose alarm log feeds a regulatory review. The data export's Device Events sheet now includes columns for the reviewer, the comment, and when it was reviewed, with the prior comments listed beneath each alarm.

Alarm emails used to be sent with every recipient hidden on BCC and the sender's own address showing in the To field. Each recipient now sees their own address in the To header instead.

The Restart Service button on the Server Config page sometimes left the service stopped instead of restarted. It now reliably starts the service back up after stopping it.

A TV2 whose firmware has stopped responding (but whose network connection is still alive) used to look the same as any other offline device on the Dashboard. Those devices now show a red "Needs power-cycle" badge so the operator knows to walk over and reboot the TV2.

The Edit Device page has a new optional note field (up to 500 characters) that gets appended to alarm emails sent for that TV2. Useful for site-specific contact info or location reminders.

A new admin page lets you pick a device (and optionally a sensor or alarm category) and see exactly which users would currently receive an email if that alarm fired right now, including who is skipped and why.

After acknowledging or hiding alarms, the Submit button now appears in a fixed bar at the bottom of the page with a live count of how many changes are pending. No more scrolling back to the top to find it.

Opening a history chart used to freeze it at the moment of load. The chart now slides forward in the background so new readings appear without a manual reload, while charts opened from Data Export still honor your chosen start/end window.

The tooltip near the right edge of the 30-day chart sometimes missed the most recent reading. It now always surfaces the latest sample.