` input: opcua: endpoint: 'opc.tcp://192.168...
# umh-support
d
Copy code
input:
  opcua:
    endpoint: 'opc.tcp://192.168.2.101:4840'
    nodeIDs: ['ns=3;s="DB_00CommunicationDayResults"','ns=3;s="DB_00CommunicationMachineStatus"']
    subscribeEnabled: true

pipeline:
  processors:
    - bloblang: |
        root = {
          meta("opcua_path"): this,
          "timestamp_ms": (timestamp_unix_nano() / 1000000).floor()
        }

output:
  mqtt:
    urls:
      - '192.168.2.31:1883'
    topic: 'umh/v1/TLT/Muzzroom/Meulebekestraat/ProductionLine1/SortingUnit1/originID/_historian/${! meta("opcua_tag_path") }'
    client_id: 'benthos-umh'
j
It seems that the port 4595 (or similar) is already in use on the system
Is there another benthos still running?
Or another service?
You can definitely change that port
d
Ok i should have seen that i will retest should i worry about the thirth last line ? ("service is closing due ...")
j
good catch, yeah that needs to be adjusted
let me give you a working MQTT confifg
note the tcp://
this is from a protocol converter from the UI
d
i dont think this will be the issue to be honest ( i will test it)
I think its the port binding (costumer is testing it atm)
it worked fine before with this yaml so i suppose the tcp:// is not really required
j
between your benthos version and the current one, we did a benthos update with over 2years of benthos changes. if i try it on my side, it will throw this error:
as soon as I add the tcp:// it works
d
clear! 😄
We got the new version running!
seems to work
i will have to rewrite the post processor tho
also quite a lot of errors
problem with current filter is: "tagname" is the same over multiple machines
and its overwrite the same mqtt tag
for example "iStatus" (second tag in screenshot) comes from both ns=3....DR1...iStatus and ns=3....DR2....iStatus
so i will have to change the filter in the mean time this new version will stay running as a stability test
feedback about stability will come by tonight / coming days
i was using "opcua_tag_path" before but this doesnt seem supported in the documentation?
@Jermuk here! 🙂
j
it is still supported, but deprecated and we removed it from the documentation. tag name and tag group are now better option to better structure it
check out how the yaml looks like in our protocol converters, that might give you some ideas how to good structure them
d
Thanks! I wil l give it a try
i just have to play around a bit to find a solution i like