Hi Alvaro, i pushed now a potential fix for your issue. Can u verify if it solves the problem? This fix still uses the discovery capabilities of the Milo-Endpoint because it is a quite heavy configuration. There I then replaced the endpoint address with the provided one and removed the discovery URL. So I stick with the param notation "nDiscovery" because it is still using parts of the discovery and runs in a special mode which has to be enabled and is disables by default.
So if u want to use it attack "nDiscovery=true" as a Get-parameter like: "opcua:tcp://opcua.demo-this.com:51210/UA/SampleServer&nDiscovery=true" Try that on the Branch: PLC4X-157OPC-UADisablediscovery Greetings Matthias Matthias Strljic, M.Sc. Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) Seidenstraße 36 70174 Stuttgart GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: [email protected] Web: http://www.isw.uni-stuttgart.de -----Ursprüngliche Nachricht----- Von: Strljic, Matthias Milan <[email protected]> Gesendet: Thursday, December 5, 2019 9:28 AM An: [email protected] Betreff: AW: AW: [jira] [Created] (PLC4X-157) OPC-UA: Disable by config endpoint discovery Hi Alvaro, i am close to push this feature. But you have for me setup/example server to test the issue? Because my attempt would be to use the existing discovery tools to generate the ApplicationDescription and then replace the host address with the public address or just remove included discovery urls. Greetings Matthias Matthias Strljic, M.Sc. Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) Seidenstraße 36 70174 Stuttgart GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: [email protected] Web: http://www.isw.uni-stuttgart.de -----Ursprüngliche Nachricht----- Von: Álvaro Del Castillo <[email protected]> Gesendet: Thursday, December 5, 2019 7:59 AM An: [email protected] Betreff: Re: AW: [jira] [Created] (PLC4X-157) OPC-UA: Disable by config endpoint discovery Hi Matthias, On Wed, 2019-12-04 at 14:12 +0000, Strljic, Matthias Milan wrote: > Ok, then i will include the typical URI style for GET-parameters like > u and Chris suggests. So are you going to implement it? We need this fix so I can help in the implementation of it or in the testing. Cheers! -- Alvaro > Perhaps there I try to hard to stick to the domain URL (if there is > sometimes one 😃 ) > > Greetings Matthias > Matthias Strljic, M.Sc. > > Universität Stuttgart > Institut für Steuerungstechnik der Werkzeugmaschinen und > Fertigungseinrichtungen (ISW) > > Seidenstraße 36 > 70174 Stuttgart > GERMANY > > Tel: +49 711 685-84530 > Fax: +49 711 685-74530 > > E-Mail: [email protected] > Web: http://www.isw.uni-stuttgart.de > > -----Ursprüngliche Nachricht----- > Von: Julian Feinauer <[email protected]> > Gesendet: Monday, December 2, 2019 1:42 PM > An: [email protected] > Betreff: Re: [jira] [Created] (PLC4X-157) OPC-UA: Disable by config > endpoint discovery > > Hi, > > thanks fort he fast reply Matthias. > I agree with what Matthias says... I highly suggest the Camel > Parameter Syntax (basically valid URI's). > And yes, probably the subtype approach makes sense (this is consistent > with having the physical transport layer also there for protocols that > support multiple ones). > > Julian > > Am 02.12.19, 13:31 schrieb "Strljic, Matthias Milan" < > [email protected]>: > > Hi all, > > For this I have a question: How should we deal with this > consistently in the project? > > The Camel discussion about parameters/annotation is not over yet > (?) and I want to avoid parameters in the URL that are not part of the > domain model of the protocol. > So I would solve it first as a new connection subtype. > "opcua:tcp-ndiscover://145.............". > But on the other hand this only makes sense if this is a real > exception and would else explode in number by defined subtypes. > > So what do you think? > > Greeting > Matthias Strljic, M.Sc. > > Universität Stuttgart > Institut für Steuerungstechnik der Werkzeugmaschinen und > Fertigungseinrichtungen (ISW) > > Seidenstraße 36 > 70174 Stuttgart > GERMANY > > Tel: +49 711 685-84530 > Fax: +49 711 685-74530 > > E-Mail: [email protected] > Web: http://www.isw.uni-stuttgart.de > > -----Ursprüngliche Nachricht----- > Von: Alvaro del Castillo (Jira) <[email protected]> > Gesendet: Friday, November 29, 2019 5:21 PM > An: [email protected] > Betreff: [jira] [Created] (PLC4X-157) OPC-UA: Disable by config > endpoint discovery > > Alvaro del Castillo created PLC4X-157: > ----------------------------------------- > > Summary: OPC-UA: Disable by config endpoint discovery > Key: PLC4X-157 > URL: > https://issues.apache.org/jira/browse/PLC4X-157 > Project: Apache PLC4X > Issue Type: Improvement > Components: Driver-OPC-UA > Reporter: Alvaro del Castillo > > > Some real world devices like the [ > https://iqunet.com/server-and-data/] includes as the OPC-UA server the > FreeOPCUA server running inside a docker. When you discover the > endpoints, the IPs advertised are the internal ones in the docker > container, so you can not access these endpoint from the network. > > It is an issue in the device, but for those cases, just using > directly the public IP in which the OPC-UA server is listening as the > endpoint is the only solution. > > For PLC4x to work in those cases, a config option must be > available to disable the endpoint discovering and just connect to the > endpoint build with the public IP. > > > > > > -- > This message was sent by Atlassian Jira > (v8.3.4#803005) > >
