业务和功能介绍
设备统一管理模块：支持Wi-Fi、蓝牙、Zigbee等多种协议设备的发现、配网、分组与重命名。
智能场景中心：用户可自定义“回家模式”、“影院模式”、“睡眠模式”等，一键触发多设备联动（如：开启“回家模式”，自动开灯、开空调、播放音乐）。
实时控制面板：提供图形化拖拽界面，直观控制所有设备状态；集成语音助手接口，支持语音控制。
能源管理模块：可视化统计各设备历史耗电量，提供节能建议与定时开关策略。
家庭安防看板：集中显示安防摄像头画面、门窗传感器状态，异常情况及时APP推送告警。
智能场景中心：用户可自定义“回家模式”、“影院模式”、“睡眠模式”等，一键触发多设备联动（如：开启“回家模式”，自动开灯、开空调、播放音乐）。
实时控制面板：提供图形化拖拽界面，直观控制所有设备状态；集成语音助手接口，支持语音控制。
能源管理模块：可视化统计各设备历史耗电量，提供节能建议与定时开关策略。
家庭安防看板：集中显示安防摄像头画面、门窗传感器状态，异常情况及时APP推送告警。
项目实现
1、整体架构和设计思路，不同模块使用的技术栈。
项目采用前后端分离的微服务架构，确保高可用与可扩展性。
前端（Vue 3 + TypeScript + Pinia）：采用组件化开发，使用Vite构建，确保优秀的开发体验与运行时性能。移动端使用Vant组件库，管理后台使用Element Plus。
后端（Node.js + Koa）：
用户与设备管理服务：处理用户认证、设备元数据存储（MySQL）。
消息转发服务：核心服务，使用MQTT协议与设备端通信，并利用Redis的Pub/Sub功能实现控制指令的实时推送与设备状态同步。Redis同时缓存高频访问的设备状态，降低数据库压力。
场景引擎服务：解析和执行用户设定的自动化规则，采用规则引擎处理复杂的“如果-就”逻辑。
通信：设备与云端通过MQTT保持长连接，实现低延迟控制；前端通过WebSocket与后端通信，获取实时状态更新。
2、“我”的负责模块和结果（尽可能量化）。
我作为后端核心开发，主要负责：
消息转发服务的设计与实现：独立设计了基于MQTT Topic和设备ID的路由方案，实现了设备指令毫秒级（平均<200ms）下发。该服务成功接入了超5万个在线设备，日均处理消息300万条。
设备实时状态同步机制：利用Redis存储设备最新状态，并通过WebSocket向所有在线用户推送状态变更。实现首页设备状态加载时间从原始的2-3秒降低至500毫秒以内。
场景引擎核心逻辑开发：负责开发了场景触发条件的解析器与动作执行器。上线后，用户创建的自动化场景数累计超2万个，场景执行成功率达到99.5%。
3、“我”遇到的难点、坑，和解决方案。
难点一：海量设备连接下的状态一致性。当多个用户同时操作同一设备时，可能出现状态不同步。
解决方案：引入基于Redis的分布式锁，在发送控制指令前对设备ID加锁，确保同一时间只有一个控制请求被处理。同时，所有状态变更以设备端最终上报的状态为准，通过版本号进行乐观锁控制。
难点二：MQTT消息积压与服务质量（QoS）选择。初期对所有消息使用QoS 2（确保送达），在高并发下导致服务端消息积压。
解决方案：区分消息类型。对控制指令采用QoS 1（至少送达一次），保证可靠性；对设备频繁上报的状态数据采用QoS 0（最多一次），保证吞吐量。并对服务端进行水平扩容，按设备类型拆分MQTT Broker集群。
难点三：场景联动的执行顺序与错误处理。一个场景包含多个动作，部分失败会影响用户体验。
解决方案：设计了一个可回滚的动作执行队列。为每个动作定义反向操作（如“开灯”的反向是“关灯”）。当序列中某个动作执行失败时，自动中断并尝试回滚已执行的动作，同时向用户发送明确的失败报告，提示用户检查具体设备。
项目采用前后端分离的微服务架构，确保高可用与可扩展性。
前端（Vue 3 + TypeScript + Pinia）：采用组件化开发，使用Vite构建，确保优秀的开发体验与运行时性能。移动端使用Vant组件库，管理后台使用Element Plus。
后端（Node.js + Koa）：
用户与设备管理服务：处理用户认证、设备元数据存储（MySQL）。
消息转发服务：核心服务，使用MQTT协议与设备端通信，并利用Redis的Pub/Sub功能实现控制指令的实时推送与设备状态同步。Redis同时缓存高频访问的设备状态，降低数据库压力。
场景引擎服务：解析和执行用户设定的自动化规则，采用规则引擎处理复杂的“如果-就”逻辑。
通信：设备与云端通过MQTT保持长连接，实现低延迟控制；前端通过WebSocket与后端通信，获取实时状态更新。
2、“我”的负责模块和结果（尽可能量化）。
我作为后端核心开发，主要负责：
消息转发服务的设计与实现：独立设计了基于MQTT Topic和设备ID的路由方案，实现了设备指令毫秒级（平均<200ms）下发。该服务成功接入了超5万个在线设备，日均处理消息300万条。
设备实时状态同步机制：利用Redis存储设备最新状态，并通过WebSocket向所有在线用户推送状态变更。实现首页设备状态加载时间从原始的2-3秒降低至500毫秒以内。
场景引擎核心逻辑开发：负责开发了场景触发条件的解析器与动作执行器。上线后，用户创建的自动化场景数累计超2万个，场景执行成功率达到99.5%。
3、“我”遇到的难点、坑，和解决方案。
难点一：海量设备连接下的状态一致性。当多个用户同时操作同一设备时，可能出现状态不同步。
解决方案：引入基于Redis的分布式锁，在发送控制指令前对设备ID加锁，确保同一时间只有一个控制请求被处理。同时，所有状态变更以设备端最终上报的状态为准，通过版本号进行乐观锁控制。
难点二：MQTT消息积压与服务质量（QoS）选择。初期对所有消息使用QoS 2（确保送达），在高并发下导致服务端消息积压。
解决方案：区分消息类型。对控制指令采用QoS 1（至少送达一次），保证可靠性；对设备频繁上报的状态数据采用QoS 0（最多一次），保证吞吐量。并对服务端进行水平扩容，按设备类型拆分MQTT Broker集群。
难点三：场景联动的执行顺序与错误处理。一个场景包含多个动作，部分失败会影响用户体验。
解决方案：设计了一个可回滚的动作执行队列。为每个动作定义反向操作（如“开灯”的反向是“关灯”）。当序列中某个动作执行失败时，自动中断并尝试回滚已执行的动作，同时向用户发送明确的失败报告，提示用户检查具体设备。
示例图片视频
相似推荐
24小时车保姆
聚焦车主 “车辆路边抛锚” 的应急维修需求（如爆胎、亏电、油路故障、小修小补等），整合城市自由修车人资源，通过 “LBS 智能匹配 + 24 小时响应”，实现 “3 分钟下单、10 分钟匹配、30 分钟内师傅到达现场” 的应急服务闭环，核心解决传统路边维修 “找不到人、价格不透明、技术无保障” 的痛点。
多模态信息理解世界以更新城市地图（高精地图）
通过多模态数据（视觉、激光雷达、GNSS、里程计等），通过以深度学习为核心的综合技术创新进行物理世界理解和构建，建设完善情报体系产线（车道线、指示牌、车道结构等），最快可达分钟级别对物理世界的更新、端侧小时级更新（考虑到功能安全）。
基于 DQN 算法实现疏散标识方向动态优化预研
针对大型公共场所（客运枢纽、商场）紧急疏散标识指引不合理、效率低的问题，探索 AI 与疏散仿真融合的技术路径，开展 “AI 控制疏散标识” 预研，验证技术在动态场景下的适用性，为智慧安全领域提供技术储备。
综合客运枢纽结构和功能仿真平台的构建
仿真模型输入：导入交通枢纽的平面CAD图纸，可视化的拖拽输入交通枢纽的各种交通设施，如入口出口、车辆（地铁、公交、出租车）停播点、收票口、检票口等。用鼠标连接这些交通设施，形成行人在枢纽内的换乘过程。仿真场景曾达到上万平方米，仿真人数达到上千人。
仿真过程：模拟行人在交通枢纽内的换乘过程，宏观路径使用自主研发基于可视图和A*路径规划算法，微观路径使用经过改进的社会力算法，避免行人与行人，行人与障碍物产生重叠。
分析过程：根据鼠标划定的区域，统计分析客流量、密度、速度等指标，以图表形式输出
酒店自助系统
酒店自助系统(KioskSystem)使用C++语言编写，使用QT库，MYSQL数据库，MQTT通信等，主要实现住户入住酒店全流程自助办理功能，包括办理入住、续住、退房、停车、发票获取等功能，其中房间预定入住是核心模块，支持身份证、电子身份证等入住方式。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服