让我们从铁开始
我曾经在一家工厂工作过，在那里他们雕刻了各种电子产品，虽然不是很复杂，但有时都属于“物联网”的定义。 在大多数情况下，用于安全系统的各种传感器：烟雾，噪音，穿透力，火灾等等。 产品范围很广，批次有时少于500件，几乎每种产品都必须制成单独的测试装置-实际上，只是将要进行测试的产品放入锡盒中，盖上盖子，从下方将接触针按到接触点上在印刷电路板上，如下所示：
因此，可以与设备进行物理通信。 我们拥有的通信协议在业界非常普遍-RS232（COM端口，一种UART）。 盒子中还装有用于测试最终产品的各种简单受控设备。 所有这些辅助仪器都以相同的方式进行控制。 整个结构非常脆弱，各种问题都是日常工作的一部分。
问题的范围非常广泛-接触不良，安装过程中极性颠倒，被测产品，控制和测量设备，接触针，测试代码出现问题...但是您永远不会知道！ 但是有必要进行持续测试，并且如果测试开始“推广”到某个地方，则其中一名工程师不得不sto脚，开始手动检查所有内容。
首先，启动了Docklight-一个很好的实用程序，用于通过COM端口进行“通信”，但是它有很多限制。 在这里，我们正在探讨问题的实质。
为什么Docklight不适合我？
好吧，走吧。
- 第一个问题是Docklight 仅在Windows上运行。 因此，可以忘记以RaspberryPi的形式安装“神经中心”，它将连接所有设备或类似的设备。 我必须安装NUC-在这种情况下最便宜的解决方案。 重，相当大，而不是最便宜的。 顺便说一下，当这些测试装置从一个地方拖到另一个地方时，NUC进行了非常非常大的战斗（尽管我承认他们的设计非常扎实）。
- 第二-远程访问只能通过桌面共享来进行-即使通过本地网络，它也减慢了速度，甚至通过Internet，它也完全是me脚。
- 第三，每个设备都有自己的一组命令，Docklight可以使用命令列表加载文件。 例如，如果您必须与部门中的某人共享类似的列表，则发送包含该文件的电子邮件，或...在共享文件夹中发送指向该文件的链接！ 自然地，每个Docklight安装程序都需要在本地安装此类文件，而所有这些操作都必须手动完成数十次（即使不是数百次）-对于每个NUC，每位工程师都拖动了自己喜欢和方便的命令列表。 在院子里2019，让我提醒你...
- 第四，Docklight不允许您将COM端口与设备名称自动关联：例如，Windows在连接Power Supply时将通过COM12与设备通信。 如果要手动“拉动字符串”，则在Docklight中需要打开COM12。 您怎么知道我们在谈论电源，而不是在谈论SwitchBoard？ 好吧，您可以每次查看设备管理器，并尽量不要忘记哪个设备连接到哪个端口。 同时，没有人保证如果您简单地拔出设备然后再次插入，则先前的端口将保留在该设备中。 简而言之，每次您都必须手动进行操作。 相信我，直到一天结束时，我的头都因此而旋转。
- 第五，每个端口都需要一个单独的程序副本，当然，所有操作都必须针对每个设备单独完成，尽管Docklight支持脚本编写，但是各个实例之间没有交互。
下一个 没有提供与任何其他产品的集成。 这似乎是一件小事，但在这种情况下，白热化了：测试失败了，我们需要找出原因。 首先，您需要连接到设备，看看它们是否完全没电。 我们转到设备管理器，查看设备位于哪个端口，打开Docklight，启动与我们端口的通信...错误。 该死！ 我忘记停止NUC上安装的服务并保留所有端口。 独家，你知道。 好的，我们减慢服务速度，打开端口，使用设备的命令加载文件，发送命令，我们将获得（或未获得）答案，我们将解决问题。 我们再次运行测试，它再次崩溃...哦，该死，我忘了关闭Docklight并重新启动服务。 一切似乎都没有错误。 但这是接下来的几个小时，直到再次出现问题。 并相信我，有必要比我们更经常地解决这些问题。
好吧，当然，关于任何扩展，请添加。 没有任何功能或类似功能-产品已关闭，编写了很长时间（似乎不再专门开发），没有自定义功能。
好吧，我决定做点我的事情，但是要纠正（或改善）所描述问题的情况。
原来是类似Zabbix的东西，但是针对特定情况进行了锐化。
那有什么区别呢？
从对体系结构的一般描述开始，然后进行详细介绍，也许是有意义的。
该方案如下所示：
我们有一个在与我们的设备物理连接的站点上运行的代理。 Agent是用Python编写的，因此它可以在Windows，Linux上正常工作，并且可以安全地完成它以在RaspberryPi和类似设备上使用。 该程序对资源极为不需要，而且非常稳定。 代理始终通过Websocket连接到服务器（后端），并在初始化和更新期间从那里接收所有端口设置及其参数。 在这种情况下，代理具有自己的GUI来进行设置和监视（可能是连接丢失，许可证已过期）。
下一个 服务器（又名后端）从docker上升（因此不仅可以在Amazon或Google Cloud中运行，而且还可以在装有Linux的LAN上任何不那么强大的计算机上运行）。 它是用Django与Redis一起编写的（以支持websocket）。 它存储所有设置，并提供用户GUI（仅是用ReactJS编写的页面）以及通过代理与我们的设备之间的通信。 双向通讯，完全异步。 所有设置都存储在Postgres和Mongo中。
好吧，也许，系统中最重要的部分是客户端本身（简单来说，就是浏览器中的页面，是为ReactJS编写的，以提高动态性）。
是的，视觉设计远非完美，但这是可以修复的。
好了，这可以四舍五入了，我只会在项目状态和演示中添加几句话。
- 这是相当早期的alpha版本，旨在更可能展示潜在的便利设施并检查兴趣水平。
- 播放演示- 在这里
登入
用户名：operator_0
密码：123456789
我们选择QA_Test和任何站点（这只是模拟企业结构的尝试-端口连接到站点，它们划分为部门，每个办公室都有自己的结构）
原则上，如果有兴趣，我将添加对https的支持，并为不同平台构建Agent的程序集，并添加所有其他功能。
我将很高兴收到任何反馈和建议。 欢迎批评！