news 2026/10/23 3:03:40

边缘AI进入建筑后,WiFi Halow技术帮集成商搞定带宽、距离和功耗

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
边缘AI进入建筑后,WiFi Halow技术帮集成商搞定带宽、距离和功耗

边缘AI正在改变数据在建筑里的流动方式,让建筑变得越来越智能。视频监控能实时认出人、车辆和异常活动;门禁系统能把身份验证、数据分析和自动反应结合起来;空调和供暖系统会根据房间里有没有人来调节能耗;环境传感器能在空气质量和温度刚出现变化时就发现苗头;烟雾、火灾和安全系统的反应也越来越快。

边缘AI让摄像头、传感器和控制系统不用再一直把原始数据传到云端,而是先在本地分析,判断哪些信息重要,然后再传出去。但随之而来有一个新的基础设施难题:智能设备处理数据和AI任务时,带宽、距离和功耗怎么解决?因为摄像头、传感器和控制系统在不同情况下要传的数据量差别很大,比如:

👉一个AI摄像头平时可能只发送很小的元数据,但在发现事件后,会突然传一张核实图片或一段视频。

👉一个预测性维护传感器可能长时间安安静静,但在发现异常后,会上传更详细的诊断信息。

👉一个建筑控制器可能隔一段时间就需要一次固件或AI模型更新,数据量比它平时的流量大得多。

这些数据到底差多少?一个简单的传感器事件、目标检测的元数据不到1KB,而一张用于核实的图片可能需要几十KB,一张高分辨率图片、一段视频或一次模型的空中更新,就需要几百KB甚至几兆。流量忽大忽小、时有时无,网络就不能只按日常的低值来设计,否则平时够用,一遇到图片、视频或模型更新就卡住了。

安防系统就是一个典型例子。安防摄像头恰恰是那种平时数据量很小、关键时刻突然要传图片和视频的设备,所以网络能不能稳定承载这种突发流量,直接决定了摄像头能装在哪。本来摄像头的一些重要点位应该装在入口、停车楼、装卸区、围栏边、物业周界(周界,即防护区的外围边界)这些更需要风险管控的地方,但现实中经常装在网络信号很好的地方。之所以这样,是因为传统Wi-Fi穿过墙壁、地板、金属结构和户外环境时,性能会明显变差。集成商不得不把摄像头靠近接入点、缩小周界范围、加装更多节点,或者多拉线缆来弥补。

然后又带来新问题:

👉摄像头离周界远了,只能在事件发生后记录下来,不能更早发现可疑活动。

👉多加接入点和节点会增加安装时间,额外增加更多需要配置、供电和维护的设备。

👉连接不稳定会增加排故成本、反复上门成本和售后支持成本。

同样的问题遍布整个智能建筑。空调设备可能装在屋顶或机房,电力和能源管理系统可能在地库或地下室,环境传感器可能要覆盖很大的园区,门禁设备可能分布在好几栋楼里。在每一种情况下,AI设备的安装点位都只能反过来迁就网络,而不是装在最应该装的点位。直接原因就是传统WiFi穿墙差、距离一远性能就下降。而其他技术也各有短板:低功耗广域技术省电、距离远,但很多只适合小数据包,传不了图片和视频;蜂窝网络覆盖广,但长期费用和功耗不适合大量固定端点;有线以太网和PoE可靠,但在改造、室外和大型分散设施里又贵又不灵活。

怎么办?有一种技术正好同时满足:把WiFi扩展到sub-GHz频谱。IEEE 802.11ah,通常叫Wi-Fi HaLow(WiFi联盟认证名称),设计目标就是比传统2.4 GHz和5 GHz WiFi距离更远、更省电,同时保留原生IP网络和现有WiFi的安全框架。

这里简单说明sub-GHz: 我们平时用的WiFi主要在2.4 GHz和5 GHz频段,频率高,速度快,但信号穿墙差、传得近。sub-GHz指的是频率低于1 GHz的频段,频率低,信号传得更远、更容易穿过墙壁和障碍,但速度相对慢一些。可以粗略理解为:2.4 GHz和5 GHz像城市快速路,车道多、跑得快,但一堵墙就绕不过去;sub-GHz像乡间小路,跑得慢,但能绕很远、穿过去。

Wi-Fi HaLow就是用sub-GHz频段来跑WiFi,在距离和穿透上优于传统 WiFi,在速率上低于传统 WiFi。不过Wi-Fi HaLow不是要取代传统WiFi、以太网、蜂窝或其他低功耗技术,而是把WiFi模式扩展到过去很难用无线覆盖的地方。因为sub-GHz频段能让信号传得更远,也更容易穿过墙壁和其他障碍,同时支持那些不只是简单传感器遥测的应用所需的数据速率。这就为传统网络覆盖边缘的摄像头、门禁系统、建筑传感器和其他设备提供了新选择。

有了更好的连接,结果可能也就不同了。过去因为网络限制被迫往内装的摄像头,主要用来记录事件发生后的情况。现在更可靠的远距离连接可以让摄像头和传感器往外装,靠近入口、停车区和物业周界。再结合本地分析,就能更早发现、实时报警,在事件升级前做出响应。

同样道理也出现在建筑运营的其他方面。一个振动传感器发现设备行为异常,可以在故障前触发预测性维护;环境监测器可以更早发现不安全状况;空调系统也可以更动态地响应人员变化和条件变化。每一种情况下,设备能在数据产生的地方工作,并且能和建筑其他部分稳定通信,智能才更有用。

在规划下一代建筑系统时,连接性应该和计算、传感、分析一起考虑,因为建筑要用很多年。今天装的设备可能要用好几年,而软件、AI模型和数据需求还会不断变化。如果只按今天的流量需求来设计,明天就可能变成基础设施瓶颈。所以连接问题不再只是网络有多快,而是网络能不能把带宽、距离和功耗搭配好,让AI能在整个建筑里真正发挥作用。

说明:1.文章参考公开报道并借助AI工具进行整理和分析,如有不妥之处欢迎指正。2.部分市场数据基于行业估算、发布以及官方报道,具体精确数据请以权威机构为准。3.欢迎长期追踪边缘AI的朋友一起探讨。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/23 3:03:24

地址输入提示接口实战:从敲第一个字到选中地点的完整接入

摘要:电商下单页、外卖收货地址、物流寄件表单——凡是需要用户填写地址的场景,都少不了"输入提示"(也叫地址联想、地址自动补全)。本文以丰图地址输入提示API为例,给出一个可直接改造的前端接入方案&#x…

作者头像 李华
网站建设 2026/10/23 3:03:19

前端通用组件开发全指南|从 0 到 1 打造稳定可复用的业务组件

适合 Vue / React 开发者,面向 B 端后台系统(跨境、ERP、SaaS 场景),兼顾设计原则、避坑经验,附思维导图要点,适合技术博客发布很多团队都会踩同一个坑:业务写着写着,到处是重复弹窗…

作者头像 李华
网站建设 2026/10/23 3:03:01

Go reflect 包动态调用与方法反射 —Call、MakeFunc 与性能

1. Value.Call 全景:一次反射调用的生命周期:Call/CallSlice 都落到 Value.call(value.go:385,约 200 行)。调用一个函数,编译器生成的代码要做的事 reflect 全要手工做一遍:Value.Call(in []Value) []Valu…

作者头像 李华
网站建设 2026/10/23 3:02:58

CDS Table Function 上层 WHERE 到底能不能下推到数据库表

在 SAP 项目里使用 CDS Table Function 时,有一个性能问题特别容易靠经验判断。 假设底层数据库表有几百万甚至几千万条数据,我们通过 CDS Table Function 包了一层 AMDP SQLScript,业务程序再从这个 Table Function 上查询数据,并加上类似下面这样的过滤条件。 WHERE re…

作者头像 李华
网站建设 2026/10/23 3:02:06

Flutter 3.47 鸿蒙三方库适配实战:从 0 到 1 处理 call_state_handler

Flutter 3.47 鸿蒙三方库适配实战:从 0 到 1 处理 call_state_handler 监听设备通话状态,并在状态变化时向 Dart 推送事件。 本文以 call_state_handler 3.0.0 为例,记录我如何保留原有 Dart API、补齐 Flutter OH 插件入口、在鸿蒙端接入真…

作者头像 李华