evening,
error message makes me think the target is rejecting your connection request.
what is the endpoint target url? does it require security/encryption?
have you connected to this device using regular opcua clients? if so what are the settings in such clients?
Hello,
I use UaExpert client to test the communication with a Wago PFC100 and all is good.
On this WAGO, I need to configure the OPC UA Endpoint with Security Policy - None, and unlimited anonymous acccess. And now I haven’t HA crash.
I will increase security little by little…
By the way, what is the syntax to define login/password in configuration.yaml file ?
And how to change the refresh rate?
so two things.
each certificate has a specific Uri, so both need to be listed in the yaml.
below is an example of mine connecting to a freeopcua server I have running in docker. I borrowed the client certificate from the freeopcua GitHub examples found on GitHub. I then copied those files into my ssl directory and listed them as per below.
FreeOpcUA GitHub example files
opcua:
- name: target1
url: "opc.tcp://192.168.50.113:4840/"
session_timeout: 600000
secure_timeout: 600000
- name: target2
url: "opc.tcp://192.168.50.113:4840/"
application_uri: "urn:example.org:FreeOpcUa:python-opcua"
session_timeout: 600000
secure_timeout: 600000
security_string: "Basic256Sha256,SignAndEncrypt,/ssl/certificate-example.der,/ssl/private-key-example.pem"
I’m not familiar with Wago, or what you’ll need to do to get that opc ua server to trust your clients certificate. hopefully they have good documentation.
is your Wago also using user rights access as well? you can add the following to your yaml
username: ####
password: ####
Also out of curiosity, what are you looking to achieve with the opcua add-on?
that is a slick piece of industrial automation, I see it supports modbus TCP, which is baked into home assistant by default and may be more stable. though less secure.
I have opened an issue in github for this. I wanted to keep track on things for the project.
did this error prevent HA from loading?
With OPC UA, I looking to replace ModbusTCP with the WAGO PLC.
This equipment is great with CodeSys to acquire and control the actuators of my house.
The HA Modbus TCP extension is not fully finalized, especially with regard to reading multiple float register.
YEs, this error prevent the loading of HA.
We can continue this discussion about this issue on GITHUB.
This is correct, I simply add this two line in configuration.yaml and I have a beginning of security element.
opcua:
- name: WAGO_OPC_UA
url: "opc.tcp://192.168.0.21:4840/"
username: !secret WAGO_OPC_UA_user
password: !secret WAGO_OPC_UA_password
I now check the client certificate…
- refresh is fixed at the moment. but can be something we look at making variable. I believe it is 30 seconds default. what kind of rates are you looking for?
A variable would be a good thing. From 1second to 1 hour.
I will look into the scan interval settings. basic searching so far implies it should be relatively easy to implement.
in the mean time you can try this work around for faster scan intervals.
https://community.home-assistant.io/t/dynamically-varying-sensor-scan-interval/159233/4
Thank you !
A simple scan_interval: 10 in the sensors.yaml file
- platform: opcua
scan_interval: 10
nodes:
- name: Sensor1
hub: WAGO_OPC_UA
nodeid: "ns=4;s=|var|WAGO 750-8101 PFC100 2ETH.Application.Publish_NativeMQTT.dwMyCounter"
unit_of_measurement: degrees
thank you,
I’ll add you this too the docs. I’ll also try to fix up that critical error.
are you writing back to the device at all?
Not yet but I will try it quickly
10-4.
I created a service to allow for writing to nodeid’s. I have been using it in automations. here is an example.
I also provided an update on github, to try and catch the error before it crashes HA.
would it be too much to ask to update your custom component and trying to connect again to your WAGO without the username/password. my HA wont crash on the socket error so it is hard for me to test this particular issue.
Thank you,
With this update HA don’t crash, even without the username/password.
Hello minimix1234,
I have also a problem to write to a node on my WAGO PLC.
I created automation script like your example and I have the following message in the log
Error: “The server does not support writing the combination of value, status and timestamps provided.”(BadWriteNotSupported) encountered when attempting to write a value of: 5448123 to nodeid: ns=4;s=|var|WAGO 750-8101 PFC100 2ETH.Application.GVL.OPCUA_WritedVar
I have no problem with other OPC_UA client (like UAExpert)
interesting. let me look at the base FreeOpcUA client code. it may be inherently writing timestamps and status (like opc v1/2/3)
I’m glad I cleaned up the error reporting. that should make it easier to track.
what are this nodeid properties? like when viewed on uaexpert
I think I’m on to something.
there is a helper utility in the freeopcua code that converts python data types to UA datavalues.
It appears that anything that is not a UA DataValue already has the timestamp added to it.
I will need to think about how to get around this one.
def value_to_datavalue(val, varianttype=None):
"""
convert anyting to a DataValue using varianttype
"""
datavalue = None
if isinstance(val, ua.DataValue):
datavalue = val
elif isinstance(val, ua.Variant):
datavalue = ua.DataValue(val)
datavalue.SourceTimestamp = datetime.utcnow()
else:
datavalue = ua.DataValue(ua.Variant(val, varianttype))
datavalue.SourceTimestamp = datetime.utcnow()
return datavalue
Ok,
It looks to be an issue with the client code from freeopcua. Somehow the freeopcua client node.set_value() code generated these errors. The proposed fix was to utilize node.set_attribute() code instead.
I created a tandem service opcua.set_attribute which can be utilized exactly like opcua.set_value. please update and give it a try.
I also found that in an attempt to mitigate a potential sensor unique_id naming collision i introduced a bug that would generate stale entries on HA restarts. I have reverted that change and it is working fine.