探讨：工业物联网，纯上报设备的数采

专栏介绍与文章目录-CSDN博客

        事情是这样的，有一台设备是modbus-tcp协议，手工操作测量，自动发送测量结果，就这，没别的了。

        开始看起来挺简单，连接上去就等着收数据嘛，多简单！后来发现麻烦得很啊，关键的麻烦就是TCP连接断开是无法知晓的（TCP的keep-alive机制非常慢，要以小时计），所以设备如果断电（关掉），DTU（程序是我写的）是无法及时发现的，只会傻等，而设备再次打开后程序不会发现，于是客户反应没有数据。由于没有设备验证，以上也只是我的猜测。

        但是不管怎么样，此类问题还是要有个通用的防范机制的。

        首先可以把问题分为两类，或者说两个思路：

• 用交互解决。因为这种设备其实不会离开人工操作独立运行（不按下按钮就不会测量），所以DTU独立运行的模式根本就是错的，只要通过界面操作手动连接或重连，就不会发生问题了。这个思路没什么问题，但是实际实施有问题，因为整个系统是别人设计的（展开说就不是技术问题了）。
• 纯技术解决。想办法自动发现连接断开，比如自动重连以确认设备正常。由于手头没有设备，不知道设备有没有特别限制（比如某些设备只允许一个连接，第二个连接直接拒绝），只能先从通用角度考虑。

        然后分别分析一下具体做法。

        交互方式比较容易，就是支持用户发一个指令来重新连接，只要前端肯配合，实现是很容易的。前端不配合的话，我可以写个单独的客户端，就一个大大的按钮“重新连接”（好像不太好意思哦）。

        纯技术考虑的就是这么几个点：

• 超时无数据自动断开重连。超时时间不好控制，因为测量是人工触发，间隔可能会很久很久，但是又可能刚好是断开重连的时候出结果，这样就会错过数据。
• 原有连接不断开，尝试一个新连接。这就与设备特性有关了，设备会不会只支持一个连接（这种设备确实有），第二个连接会不会破坏第一个连接（猜的），会不会导致数据丢失？
• 差不多吧，先写写看，再测测看。

（这里是结束）