Unlocking the Human Telemetry Layer for Safer Industrial Operations
What if we could track human health & safety conditions as precisely as we do with machines, and take immediate actions to protect our greatest asset, our people? Many industrial organizations still lack visibility into real-time human conditions, even as worker safety and operational risk remain major investment priorities. One of the most important operational signals has largely remained outside the industrial data estate: the human telemetry. VOORMI and Microsoft have joined forces to fill this gap in understanding real human conditions. Through the Mij™ platform, VOORMI brings human telemetry into Azure IoT, enabling enterprises to integrate worker conditions such as heat stress and fatigue into the same operational architecture already used for machines and industrial systems. VOORMI, SWNR’s performance apparel brand, is among the first to bring this technology into garments designed for real industrial field conditions. This integration brings their proprietary wearable technology directly into high-impact worker safety and field operations scenarios. The partnership helps establish a new telemetry layer for industrial operations, allowing human, machine, and environmental signals to converge and drive safer operations, real-time awareness, and adaptive AI workflows. Bringing the Human Signal into Industrial AI with Azure Industrial organizations increasingly recognize that many safety, productivity, and operational challenges occur at the intersection of people and machines. Workers operate in high-heat environments, hazardous conditions, remote sites, and physically demanding field scenarios where situational awareness matters in real time. Historically, worker telemetry has remained fragmented across proprietary wearable platforms and disconnected safety systems, creating governance and operational challenges for enterprise IT and OT teams. Mij™ is designed differently, integrating directly into customer-controlled Azure environments through Azure IoT Operations running at the edge or Azure IoT Hub in the cloud rather than introducing another isolated platform. Running intelligence at the edge enables virtual safety agents and operational workflows to execute closer to the worker, supporting low-latency responses, local interaction with OT systems, and operational resilience even in disconnected or bandwidth-constrained environments. This gives enterprises flexibility to support real-time worker safety responses at the edge while also enabling long-term analytics, reporting, and operational intelligence through Microsoft Fabric. Telemetry from garment-integrated sensors flows through edge gateways into Azure services including Azure IoT Operations, Azure Data Explorer, Azure Managed Grafana, and Microsoft Fabric. The result is a unified operational environment where worker telemetry can live beside machine, site, and environmental data under the customer’s existing identity, security, governance, and analytics model. The vision is simple and transformative: make human telemetry a trusted, first-class industrial data source. Azure Digital Operations as the Intelligence Layer The reference architecture demonstrates how Azure IoT Operations can serve as a scalable operational intelligence layer for worker safety and connected operations scenarios across manufacturing, energy, and field environments. Mij™-enabled garments broadcast Bluetooth Low Energy (BLE) telemetry that can be processed locally through edge gateways and routed into Azure IoT Operations using MQTT and dataflows. Data is then operationalized through Azure Data Explorer and visualized using Azure Managed Grafana dashboards for field operations, worker safety, fleet health, gateway monitoring, and operational readiness scenarios. Telemetry can also be made available to Foundry Local-hosted GenAI agents to support real-time, context aware safety guidance, such as prompting workers operating in high-heat conditions to hydrate or seek cooler environments. While Mij™-enabled garments are the initial implementation, the edge device-to-cloud architecture creates a broader onboarding point for additional wearable, sensor, and field telemetry scenarios over time. This allows enterprises to bring more human and operational signals into a unified Azure-native operational environment. The architecture also supports flexible ingestion patterns for environments where dedicated edge gateways are not practical. Using Microsoft Entra External ID, Azure Container Apps, and Azure IoT Hub, telemetry can securely flow into Azure services without exposing operational infrastructure credentials to client devices. This pattern aligns with the broader Azure adaptive cloud approach: enabling customers to run distributed edge-native services on Arc-enabled Kubernetes infrastructure while maintaining centralized security, governance, and analytics capabilities across the enterprise. Depending on customer architecture preferences, telemetry can be processed through Azure IoT Operations at the edge or ingested directly through Azure IoT Hub for cloud-first analytics and downstream processing in services such as Microsoft Fabric. Edge processing also enables real-time sensor fusion across worker telemetry, ambient environmental conditions, machine parameters, and site-level operational signals, supporting faster safety interventions and more context-aware operational decisions. This gives enterprises flexibility in how they balance edge processing, operational responsiveness, governance and privacy requirements. Enabling the Next Generation of Industrial Workflows The long-term opportunity extends well beyond visualization dashboards. As worker telemetry becomes part of the operational fabric, enterprises can begin building more adaptive and intelligent workflows across worker safety, field readiness, incident response, compliance, environmental monitoring, and industrial AI systems. Human telemetry can provide critical real-time context that complements machine and environmental signals enabling more responsive operations and eventually more autonomous decision-support experiences. By bringing human telemetry into enterprise AI and analytics workflows, organizations can build more adaptive operational systems that improve worker safety, situational awareness, and real-time decision making at scale. This partnership reflects a broader industry shift: industrial transformation is no longer only about connected machines. It is about connected operations where people, equipment, environments, and AI systems participate in a shared operational intelligence layer. With SWNR’s Mij™platform and Azure IoT Operations, Microsoft and VOORMI are helping unlock that future. Learn more: Mij™ product page: https://swnrtechnologies.com/pages/mij Learn more about Azure IoT Operations: Documentation & Getting Started See what’s new with Azure IoT Hub: Preview Documentation To get started with a pilot, contact: pilots@swnrtechnologies.com
Smaller updates, faster downloads with delta updates in Azure Device Update for IoT Hub
Keeping IoT fleets secure and up to date shouldn't mean shipping the full software image to every device, every time. With delta updates in Azure Device Update for IoT Hub, fleet operators can send only what has changed between versions, reducing download size, bandwidth use, and download time on most networks. In our demo below, an incremental change produced a delta ~97% smaller than the full image — a glimpse of what's possible for small, incremental changes. The timing matters. Security patch cadence keeps rising as Common Vulnerabilities and Exposures (CVEs) accumulate, more fleets (like smart meters and remote agricultural sensors) are running over metered networks such as cellular and satellite, and deployments are crossing scales where every megabyte per device adds up. At that point, full-image rollouts stop being a minor inefficiency and become a real cost and reliability problem. As part of a broader Azure IoT investment in more efficient edge-to-cloud data delivery, the new Device Update reference implementation agent 1.3.0 provides delta updates as a starting point that customers can build, validate, and integrate into their own environments. In this post, we'll walk through what delta updates are, how they work, and what else is new in 1.3.0 — including expanded Linux platform support to build on Debian 13 and Ubuntu 24.04, and new device-side visibility for tighter update control and coordination with device operations. Improving over-the-air (OTA) efficiency with delta updates When deploying OTA updates across a fleet, update size directly affects how quickly and efficiently updates move through the system. Traditional full image updates require every device to download the entire software image, even when only a small portion has changed. As deployments scale, this increases bandwidth usage and delivery overhead. Delta updates take a more efficient approach. Rather than transferring a full image each time, devices download a smaller delta artifact and reconstruct the target version locally, reducing the amount of data transferred across the fleet. By sending only what's changed between versions, delta updates improve efficiency in three ways: Less data on the network. Smaller payloads consume less bandwidth per device, and the savings multiply across large fleets. Faster downloads. Smaller artifacts reduce the time each device spends downloading the update, especially on variable or constrained networks. Lower delivery overhead at scale. With less data per rollout, teams can deliver updates more flexibly across large fleets, reducing the need to stagger deployments for bandwidth caps or capacity windows. This approach works particularly well for frequent, incremental changes such as bug fixes or small feature updates. For larger updates where most of the image has changed, or on devices with limited processing capacity, using a full image update may be more practical. How delta updates work Delta updates fit into the same Device Update deployment model you already use for full image updates. What changes is how update content is delivered and applied on the device. When you import an update into Device Update, you include both the full target update and one or more delta artifacts as part of the same update. When that update is deployed, the Device Update agent on each device picks the right path: If a compatible delta is available, the device downloads the delta, reconstructs the full target update locally, and installs it through the standard update workflow. If no compatible delta is available, the device falls back to downloading and installing the full target update. For details on integrating delta updates into your update workflow, see Deploy delta updates to devices. It guides you through generating delta artifacts on your build machine using the DiffGen reference tool, or as part of your image build process, and setting up the right components on the device to apply them. See the impact: Delta updates in action The following demo shows what a typical incremental change looks like with delta updates: a single-file change between image versions produces a 7 MB delta against a 240 MB full image — roughly a 97% reduction in data transferred for that scenario. Across 10,000 devices, that’s about ~2.3 TB less data crossing your network in a single rollout. Savings may vary depending on how much the versions have changed and how quickly the device can rebuild the full image locally, but they compound quickly at fleet scale. For example, a utility company patching firmware across hundreds of thousands of cellular-connected smart meters, or an agricultural operator updating remote field sensors over satellite links, sees carrier data costs drop significantly during each rollout. To bring this to life, the demo below shows what’s possible with delta updates — generating, deploying, and applying them on a Raspberry Pi device using Device Update for IoT Hub. Beyond delta updates: What’s new in the 1.3.0 reference implementation The 1.3.0 reference implementation also includes improvements that strengthen device-side coordination and expand Linux platform support. Coordinate updates with device workloads On many devices, updates run while the device is doing other work, such as handling sensor data, running a local UI, or managing background tasks. Without visibility into update status, device software can trigger conflicting operations or let battery-powered devices enter sleep mid-update. The 1.3.0 reference implementation helps your device software work alongside the update process rather than against it — coordinating with active updates, keeping devices awake through long downloads, and surfacing update status to local applications. A new device-local agent status API makes this possible: applications on the device can see what the Device Update agent is doing at any time, for example, whether an update is in progress. With that visibility you can: Avoid triggering operations that would conflict with an active update Keep battery-powered or low-power devices awake while an update is downloading or installing Surface update status in local applications or user interfaces Diagnose update behavior using local signals. Because the API runs locally, it works even when network connectivity is limited or intermittent. The payoff is fewer disrupted rollouts, more reliable updates across your fleet, and easier troubleshooting when something needs attention. Expanded Linux platform support The 1.3.0 reference implementation now adds Debian 13 and Ubuntu 24.04 to the Linux distributions you can already build on, including Debian 12 and Ubuntu 22.04. That gives you flexibility to work on newer OS versions without changing your existing update workflow. Call to action Ready to see the benefits? Extending and adapting the 1.3.0 reference implementation is a device-side change — existing service-side deployments and configurations stay as they are, so you can move at your own pace. Build from the Device Update for IoT Hub GitHub repository, integrate delta artifact generation into your build pipeline, and run your first delta in your next rollout to measure the bandwidth and download savings across your fleet. Learn more: Device Update for IoT Hub documentation | Microsoft Learn Deploy delta updates with Azure Device Update for IoT Hub | Microsoft Learn We’d love your feedback. Help shape the future of Azure Device Update for IoT Hub at aka.ms/dufeedback.PWA shortcuts don't keep asociated with window - Linux
I recently upgraded to version140.0.3485.14 (Official build) beta (64-bit) and noticed that my PWA, even if they open correctly in a independent window, don't show the "running window counter" on the taskbar. So, for example, if a open Outlook, the window open and loads the app, but if a I click the icon again, it opens another window, wich is a little annoying. I tried removing the PWA from Edge, rebooting, and installing again, but didn't work. Because the only change I made is updating Edge, I think is related to this build. (too lazy to go back or install the stable release)
Edge displays a splash screen saying ‘Sign in to sync your data’
Hello When the user logs in to a device for the first time and launches Edge, the following splash screen appears, even though we have created the Intune configuration below, which is intended to prevent this. We have following Intune configuration: Why does the splash screen still appear?
Feature request: Closing and restoring all of your profile windows
Hello, I'm trying to migrate from Chrome to Edge. I'm using the multi-profile feature a lot (work / private profile for instance). One feature I'm really missing from Chrome is the ability to close all the open windows of a profile. I didn't find a way to do this with Edge in case you have more than one window open with your profile. You have to close the windows one by one and once you open your profile again, it will restore only the last window you closed. The menu > "Close Microsoft Edge" will close all your profiles, not really useful to fulfill this use case. Chrome shows an entry on your profile menu once you have more than one window open: Then, it will open back all of your windows once you switch to this profile again. I tried with Edge versions stable (91.0.864.67) and Beta (92.0.902.40). Did I miss the option or edge flag to accomplish that? Many thanks in advance, David
Persistent issues with Read Aloud in Edge
I have Windows 11. Today I began having an issue wherein the Read Aloud feature built into Edge doesn't work. I was initially trying to use a similar function on Internet Archive, and noticed that while all the Microsoft voices seemed to be available in the onsite dropdown, the only voices that made any sound were David, Mark, and Zira---none of the "Online (Natural)" voices. I tried to use Read Aloud as a workaround, and found all the buttons greyed out completely. Mind you, everything worked fine yesterday, and I made no changes to my computer in the intervening time. I've opened up two support tickets, but neither live chat agent was able to resolve the issue. Here are the things I've tried with their help: trying the feature on different websites updating & restarting Edge resetting Edge settings to defaults updating & restarting computer switching wifi networks connecting to a hotspot using InPrivate mode using a new Edge profile (rule out interference from extensions) checking that English tts is downloaded in Time & language > Language & region turning Online speech recognition off and back on again resetting experimental features checking sound systems (they work, but just in case) doing a system reset (?) to 24 hours ago, which took about an hour and undid all the updates I just mentioned maybe something else I don't remember? The next thing I am going to try is give my computer a long nap. It's been a while, so maybe it just needs some shut eye. Otherwise, help????
Kiosk Mode
Hi, We are running Edge in Kiosk mode and I am trying to find information how to configure it for our specific requirements in an Enterprise environment. Requirements: URLAllowlist: "domainA.com", "domainB.com" URLBlocklist: "*" User must be able to access downloads from Edge User must be able to right click to save an image for example from a website User must be able to print Edge configuration: msedge.exe --kiosk https://domainA.com --edge-kiosk-type=public-browsing Is this specific configuration even possible with the latest version? I am running: Version 148.0.3967.83 (Official build) (64-bit)
