search

grafana / opcua-datasource

An OPC UA datasource for reading from OPC UA servers (DA/HDA/AE) into Grafana directly
GNU Affero General Public License v3.0
54 stars 10 forks source link

dotnet, C#, DA/HDA/AE, .... #10

Closed MarkoBursic closed 4 years ago

MarkoBursic commented 4 years ago

Nice project, but I do think it goes into a wrong way. The OPC UA will supersede all DA,...older OPC variants, since the were DCOM based, Windows,...OPC UA is the new technology of OPC and it shall be implemented in language that is cross-platform. By using dotnet and C# this project will never see a bright light, because OPC UA was born to eliminate this Windows dependency . There are some nice projects that you can switch to:

https://open62541.org/

https://github.com/gopcua/opcua

srclosson commented 4 years ago

Hi Mark,

Thanks for the feedback.

Grafana uses GRPC to communicate with plugins, allowing the developer to use the language of choice for writing the backend. Although Grafana has standardized on golang, many of the OPC UA tools, examples, and utilities supplied by the OPC Foundation are in C#. This is not for OPC COM/DCOM compatibility, but for OPC UA compatibility. I'm using dotnet core and compiling for 3 separate OS's for the backend, thus all 3 will be supported (osx, windows, linux). I spent quite a bit of time in the past looking at gopcua, but found that it was not quite mature enough.

With that said, backends can be written in any language and you are welcome to fork and use something else. The open62541 project looks quite good, but I liked having an object oriented language to work with. I had even (at one point) tried to use open62541 wrapped with golang.

In the end, it's my personal opinion that C# is still the best path forward.

MarkoBursic commented 4 years ago

Dear Stephanie,

For now, I need to somehow make a OPC UA server and update variables in a golang app. As you said, gopcua has poor documentation, the open62541 looks promising, but it would need a kind of wrapper for my golang app - I think it's the way to go. Things I do like from open62541 is that it is made for embedded systems, it does not require large memory and computation power. Since it is build in C, it should be easily ported on various platforms and OS.

Once I will make the OPC server running, I will try your datasource. Everything will run on ARM processor, OS is Linux Debian buster.

I know, that it takes lots of efforts to make a stable application. My personal opinion is that your application would be best if made in golang, as the Grafana is also made in golang (personally I don't like the golang) just to make it more portable and preferably someday merged into master. I do think that the OPC UA client for Grafana is a very useful add-on.

If you decided to go with .NET and C# then we shall use it in this form, every contribution is welcome. I wish you all the best.

srclosson commented 4 years ago

Thanks for your comments Marko. I'm not suggesting I would do this work, but one more thought for you. What about bypassing golang entirely. If memory is a constraint, would it not make more ssense to go to open62541 directly using a C grpc backend? I suppose if there is a use case, there is no reason why you could not have multiple backend implementations. One for low memory environments. The trade off being one may be less feature rich than the other, or better supported, etc. etc.

RavilN commented 4 years ago

My 2 cents: in my opinion implementation of OPC UA Server has nothing to do with the Grafana plugin for OPC UA because the later is a client. I don't think it is typical that the Grafana server would be running in some resource constraint machine, the same where your OPC UA Server is running. I would think that the Grafana server in most cases runs in some PC kind of machine. And agree with Stephanie that if you decide to use open62541, it is better to write your server in C.