Hi! We just published our latest article along wit...
# general
r
Hi! We just published our latest article along with a Youtube video on Integrating HighByte with the United Manufacturing Hub. Check it out here: https://learn.umh.app/blog/integrating-highbyte-with-the-united-manufacturing-hub/ We would love to hear your thoughts.
d
i would like to do the same thing with Apache streampipes. This is not a single container but a docker-compose Do you have experience with this? How should i approach this best?
@Denis @Jermuk
j
oh nice! keep us posted!
you can easily let docker-compose run in parallel
let me checkotu streampipes quiockly, maybe you can put it into kubernetes
I would position streampipes as a method for OT engineers to access the data from the UMH easily so UMH Protocol Converter --> UMH UNS --> Apache Streampipes --> UMH UNS
d
To answer the docker-compose part: I think Kubernetes would just replace the function of docker-compose. Esentially, docker-compose is just a very minimal container orchestration service
d
I had a different vision, I was planning to collect data with stream pipes and put it on mqtt topics on the umh hivemq broker
But as it is build on docker-compose I cannot directly deploy it in kubernetes? How can I approach this best?
Chat gpt Translate the compose to kubernetes?
j
Oh, what are the reasons for not using our protocol converters and benthos-umh? If it is slow to work with, there is an update in the next days that fixes it 🙂
About Kubereneted: you can either ChatGPT the compose to kuberneted (works in like 90 percent of cases for simple stuff), or you can take a look at the referenced link which is their official tutorial to deploy it in Kuberneted
d
General capability; - nice webinterface making it accessable to costumers - broad range of PLC4X connectors - data modelling/pipelines
these would be a few reasons to use streampipes
their opcua connector supports browsing; that alone is worth gold to an inexperienced user
j
Thank you for the feedback! About the topic of configuration file vs UI: - we've been discussing this a lot internally, and one of the problems we see with most UIs is that they don't scale well. It is easy to connect a couple of machines, but then when you want to apply it across an enterprise, it falls apart. - our approach at the moment is to have the YAML as the single source, and then simplify the generation of the YAML as much as possible. We plan on having a "pure UI" that converts to YAML for some connectors. with this the OT can connect and model some machines, but then also the IT guy can then come, template it and roll it out across hundreds of machines easily. What are your thoughts on this?
d
Siemens industrial edge had the same issue and they implemented a very similar solution
I think it was okay
Not great, not terrible
2 Views