- Le plus récent
- Le plus de votes
- La plupart des commentaires
Hello Sahil, I experienced similar issues when my OPC-UA server had tags configured as datatypes other than what can be ingested given that Sitewise presently only consumes String, Integer, Double, Boolean ( https://docs.aws.amazon.com/iot-sitewise/latest/userguide/measurements.html)
My OPC-UA server was publishing NaN, String Arrays, Long data types etc, and greengrass services seemed to be busy filtering data and rejecting data (look in the rejected log for hints on dropped tags) . The issue was resolved by deploying the latest OPC-UA collector component and forcing the OPC-UA server to publish what it could, according to sitewise datatypes, and just have to live with not being able to ingest OPC arrays at this point in time, whilst awaiting AWS to develop. Presently ingesting ~35,000 tags per second
Can you see a RejectedPropertyValues.log file in further insight in /greengrass/v2/work/aws.iot.SiteWiseEdgePublisher/exports (i'm using a linux edge)
Latency wise, network <500ms from opc server (remote minesite in the Australian outback!) to greengrass client/opcua collector.
Overall, the sitewise datastreams are approximately 1 minutes lagging from remote opc-server to Amazon Managed Grafana visualisation.
I actually did not checked that, the SiteWise data is our secondary source which we use for a different use-case and so, not for full data. Our main point of issue is for Kinesis, which is a greengrass stream-manager's stream for OPC-UA Collector. We did checked the
/greengrass/v2/work/aws.greengrass.StreamManager/greengrass_stream
and observed that the data does not appear for first 3 hours and then when it starts appearing latest data entered in the files is of 10-15mins old. And that's why I suspect it's an issue with OPC-UA Collector.
Contenus pertinents
- demandé il y a un an
- demandé il y a 2 mois
- demandé il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
Thanks for response JasonH, I believe this also comes as
ConversionErrors
in OPC-UA Collector Logs and we are receiving log which defines the value of this to be 0. Also, the measurements we have are mostly double or integer only. Along with that, I believe conversion issue will occur once the collector starts getting the data, which is after it have created required groups, and that is where it takes a lot of time.JasonH, If you can, could you please share the network configuration in your setup and what performance do you see in-terms of latency?