磁悬浮自动门远程开门与监控核对

开门请求和门位监测，分别列完成条件

远程界面上，一个按钮可能发出开门请求，一个图标可能显示门位。二者可以同时存在，也可能只提供其中一项。需求写“手机控制”时，先问清能控制什么、能看见什么、反馈覆盖哪樘门以及哪一扇。

请求提交、服务接收、设备收到、动作允许和门体到位属于不同证据。平台返回成功可能只到达其中一步，具体含义查准确接口与配置，不能用统一的成功提示包办整条链路。

监控也不能反向代替控制：看见关到位，并不说明刚才的关门请求一定促成了该结果；需要关联时，应有匹配的请求与观察记录。同样，有控制接口而缺少有效位置反馈时，不能凭按钮状态补造门位。

字段的物理来源先看反馈点位核对。本页继续核对这些字段是否仍能代表当前观察，而不把网关在线、门位和锁位合成一项。

至少分清属性时间、接收时间和刷新时间

一条门位记录可能带现场采集或上报时间，平台另有收到记录的时间，网页又有本次刷新时间。它们不是同一个时刻。界面每刷新一次就把门位更新时间改成现在，会隐藏真实数据已经多久没有得到确认。

先定义每个时间字段在记录哪一步：实际状态变化、设备采样、发送、服务器接收，还是页面读取。时间含义不清时，即使都显示到秒，也不能直接相减后宣称通信延迟或状态年龄。

还要区分变化上报、周期上报、轮询应答与心跳。状态长时间不变化，可能仍有正常的确认机制；也可能只是没有新的证据。多久未变化不能单独作为掉线判断，心跳出现也未必代表每个门位字段都被重新采集。

字段有效性与节点连接分别记录。云端连接恢复，但下游设备尚未恢复上报时，可以确认的只有相应连接环节；不能因为页面可打开，就认为所有门位和锁位都已更新。

虚拟时间线：页面刚刷新，门位仍可能是旧值

以下是自编说明例，不是德恩科系统实测或产品时限。假定时间已经按同一可比基准整理；只列出收到的证据，不假定存在未说明的轮询、心跳或采集能力。

表格可横向滑动查看。

在这个假设中，10:07与10:01相差六分钟，但六分钟只是本例间隔，不是任何设备的过期门槛。能否把状态视为当前有效，还需看实际更新机制、链路与项目约定。

可保留“最近一次关到位记录：10:01”，同时说明连接和当前确认状态。不能把网页刷新写成“10:07已确认关到位”，更不能据此声称门已经锁好。

如果另有有效的现场观察或新的采集结果，应分别关联来源与时间，再更新结论。不能为凑齐时间线补填一条并未取得的门位，更不能靠远程重复发开关门指令代替现场核查。

后来收到的消息，不一定更新

某些链路可能先收到新状态、后收到延迟的旧记录。是否有顺序号、版本、会话或其他排序依据，要查具体平台资料；按网页到达先后直接覆盖，可能让显示倒退到旧值。

假定同一对象、同一排序域和同一会话内，版本已明确按更新顺序递增，先收到12、后收到11，后到的11不能仅因更晚到达就当作更新状态。这是自编顺序例，数字不是德恩科协议或程序版本。

这个条件不能套到不同门号、不同来源、设备重启后的新会话或没有同样版本规则的系统。数值更大不一定更新，序号重置、回绕或记录补传等行为应按实际定义处理。

最新状态的选择与事件留档也不同。延迟收到的一条历史故障仍可能需要进入审查记录，不能因为不应覆盖当前显示就删掉历史证据。事件发生顺序另见多源时间线核对。

重连后分别确认状态和未完成请求

重连先核对对象身份、适用映射和当前可取得的状态。缓存里的一条旧值、设备新上报的一条值，以及平台重新读出的值，按来源和机制分开，不把“又联网了”当作所有反馈已新鲜。

断线期间的请求是否保存、取消、到期或等待重新确认，也要在方案中说明。本文不主张重连就补发旧开门命令；控制行为、权限、现场模式和保护条件仍按实际系统处理，不能从监控数据恢复推导运动许可。

复验时，在获准的环境与方法中核对正常更新、连接中断、数据停更和恢复。不能实施的情形写明未测，不随意拔接未知端子，也不取消保护来制造一次演示。

需要核对楼控映射版本时，继续看平台改版复核。有些问题来自字段解释变化，不能全部归为网络慢或门机故障。

交付状态证据，保留仍不知道的部分

可下载远程状态与时间条件空白表。逐项记录请求结果、状态来源、更新机制、时间定义、连接与有效性，再说明哪条观察支持哪句界面文案。

AWS IoT官方文档区分期望状态和最近上报状态，并用属性时间与文档版本解释更新和顺序。本页只借鉴信息分层的核对方法，不表示德恩科使用AWS、具有相同协议或提供相同缓存及排序机制。

没有统一刷新秒数或离线时限可由本页直接套用。具体能力按准确设备、网关和平台资料确认，账号、内部点表、程序与原始私密日志由责任方保存，不需要公开上传。

常见问题