While I personally do not resonate with the culture of YouTube “influencers”, and am unfamiliar with the influencers mentioned, nor am I inclined to view any of

While I personally do not resonate with the culture of YouTube “influencers”, and am unfamiliar with the influencers mentioned, nor am I inclined to view any of the videos, I have looked at the blog post below and have identified several areas for potential improvements: >and we had two basic options - The two options presented are not optimal. While one is superior to the other, there exists a third option that is commonly employed in most automation systems/SCADA/DCS. This involves linking the main controller to the field RTU via profinet/profibus. Utilizing this architecture from the get go could have mitigated many of the challenges encountered like: - - The wiring could have been minimized due to increased flexibility in topology. Moreover, by employing industrial ethernet, issues related to static charges could have been avoided. - - Profinet supplements standard ethernet, thus enabling the network guy to utilize consumer/enterprise equipment, thereby resulting in cost savings. - - Profibus and profinet can be combined depending on the design requirements. Without a diagram, it’s difficult to provide a definitive assessment. However, the general approach involves routing all IO cables to the RTU and then connecting a single cable to the master controller. - The use of SBC should have been avoided. As discovered later, having a full OS for a simple control task is not ideal and often results in “hacky” workarounds. A more suitable alternative would be an industrial controller. Despite sounding complex, these controllers are available in compact sizes, are cost-effective, and can be purchased in bulk and also available since unlike SBC, they have less demands. They also support features like profinet etc. The investment would then be focused on the master controller and one or more switches. For 100 RTUs, a single master would suffice. - If an SBC must be used (not recommended), then it’s advisable not to connect the GPIO directly to your relays! A servo driver could be used instead. Without a wiring diagram, it’s difficult to provide specific advice, but this approach could result in significant savings on relays and even on the SBC since some drivers can support up to 16 outputs and can be cascaded if necessary. In theory, a single SBC could have been used, but this is not advisable for a lot of reasons including the extra wiring will be needed (where profibus can be used to save that) - If an SBC is used, Node.js tends to offer better performance than Python on SBCs from my personal tests (a low-level language would be ideal but time constraints may prevent this), and it integrates better with UI. - The decision to avoid Wi-Fi was prudent; it would have likely exacerbated issues, band interferences, among others. However, wireless options such as VHF or Zigbee could still be considered. Note that VHF might require a license depending on your location. - Socket.IO could have been used for all 100 units or protobuf, both can and will perform well from my tests, one time I tested around 1000 connected IoT and performance was good. I have additional comments but I don’t wish to appear condescending. After all, I understand the pressures of meeting requirements within tight deadlines. So well done!