# Error calling OPC UA method

**URL:** <https://forum.inductiveautomation.com/t/error-calling-opc-ua-method/83234>\
**Category:** Ignition\
**Tags:** python, ignition81, scripting\
**Created:** [December 17, 2023, 9:15am UTC](https://forum.inductiveautomation.com/t/error-calling-opc-ua-method/83234 "2023-12-17T09:15:27Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 17, 2023, 12:59pm UTC](https://forum.inductiveautomation.com/t/error-calling-opc-ua-method/83234/2 "2023-12-17T12:59:42Z")

</div>

Yes, unfortunately this is due to a bug in FreeOpcUa that has not been fixed yet.

When we browse to discover the TypeDefinition of a Node FreeOpcUa returns no references, and this ends up forcing us to treat the Node as a base VariableNode, but in your case this is being called from some higher level code that expects correct modelling constraints.

It also manifests in simpler scenarios: [[milo-dev] server status node has wrong type](https://www.eclipse.org/lists/milo-dev/msg01041.html)

The code in this gist reproduces the issue: [Scratch.java · GitHub](https://gist.github.com/kevinherron/75ebdca52bbaf4fc433c0886c00208bc)

---

_[View the full topic](https://forum.inductiveautomation.com/t/error-calling-opc-ua-method/83234)._