YAML payload parsing

Yeah, I don’t think the YAML data he’s reading is well formed.

3 Likes

try using just a string, and not the tag value and see if it parses correctly

yaml = '''
data: 
  level: -5.937274933
  press: -23.74909973
  temp: 0.0009031557711
'''

image
The code works when the yaml data is given as
yaml = ‘’’
data:
level: -5.937274933
press: -23.74909973
temp: 0.0009031557711
‘’’
I am now certain that when the data is in the memory tag in ignition it does not maintain its format since it becomes a normal string
Not sure how to proceed

Great! First maybe start off by using the hard-coded yaml string and comparing it to the tag value.

print repr(yamlString)
print repr(tagYamlString)


Seems like there is a space difference in the tag version of the data vs manually entered yaml data

If you’re populating the memory tag value with the tag editor in the Designer then you’ll lose your formatting, but if you wrote the YAML data to it via scripting or when it comes from a “real” source the format will be preserved.

For this application I am receiving the payload over a MQTT stream. The MQTT stream is supposed to send YAML format. It comes in into a memory tag.
Currently before I test the live data stream I have been trying to do the same by testing it with a data set which I enter manually using the tag editor into a memory tag.

Also to add to the conversation above,

Manually entered yaml data is stored with “u” infront of the data which is probably the unicode I am guessing

The data value for your memory tag seems to be changing in between your screenshots as this post has progressed. As it is in the last one, with the newline characters, I would expect it to parse.

1 Like

The website prevented me from commenting after my 20 comment quota for the day.

You were right about your statement above and it did parse.
I have tested it with the live stream of data and it works.
Thank you @Kevin.Herron @dkhayes117 @PGriffith
One of my colleagues pointed the following link and may be another path for this issue as well.

1 Like

Glad you got it working! You never know, I may need to do this in the future :slightly_smiling_face:

2 Likes

When I use the Ignition Exhange resource mentioned above I get this error only when running as a tag change script or gateway tag change event script while trying to convery python dictionary to yaml.

com.inductiveautomation.ignition.common.script.JythonExecException: Traceback (most recent call last): File "", line 1, in ImportError: Error loading module core: Traceback (most recent call last): File "", line 59, in ImportError: Error loading module dumper: Traceback (most recent call last): File "", line 18, in ImportError: Error loading module representer: Traceback (most recent call last): File "", line 298, in File "", line 91, in add_representer TypeError: unhashable type: 'stringmap'

at org.python.core.Py.ImportError(Py.java:329)

at com.inductiveautomation.ignition.common.script.ScriptModule.loadModule(ScriptModule.java:79)

at com.inductiveautomation.ignition.common.script.ScriptPackage.findattr_ex(ScriptPackage.java:84)

at org.python.core.PyObject.findattr(PyObject.java:902)

at org.python.core.PyObject.impAttr(PyObject.java:1035)

at org.python.core.imp.import_next(imp.java:1161)

at org.python.core.imp.import_logic(imp.java:1278)

at org.python.core.imp.import_module_level(imp.java:1369)

at org.python.core.imp.importName(imp.java:1528)

at org.python.core.ImportFunction.call(builtin.java:1285)

at org.python.core.PyObject.call(PyObject.java:433)

at org.python.core.builtin.import(builtin.java:1232)

at org.python.core.imp.importFromAs(imp.java:1620)

at org.python.core.imp.importFrom(imp.java:1595)

at org.python.pycode._pyx813.f$0(:3)

at org.python.pycode._pyx813.call_function()

at org.python.core.PyTableCode.call(PyTableCode.java:173)

at org.python.core.PyCode.call(PyCode.java:18)

at org.python.core.Py.runCode(Py.java:1687)

at com.inductiveautomation.ignition.common.script.ScriptManager.runCode(ScriptManager.java:803)

at com.inductiveautomation.ignition.gateway.project.ProjectScriptLifecycle$TrackingProjectScriptManager.runCode(ProjectScriptLifecycle.java:819)

at com.inductiveautomation.ignition.common.script.ScriptManager.runCode(ScriptManager.java:751)

at com.inductiveautomation.ignition.gateway.project.ProjectScriptLifecycle$TrackingProjectScriptManager.runCode(ProjectScriptLifecycle.java:800)

at com.inductiveautomation.ignition.common.script.TagChangeScriptExecutor$TagChangeExecutionCallback.execute(TagChangeScriptExecutor.java:242)

at com.inductiveautomation.ignition.common.script.TagChangeScriptExecutor$TagChangeExecutionCallback.execute(TagChangeScriptExecutor.java:194)

at com.inductiveautomation.ignition.common.util.SerialExecutionQueue$PollAndExecute.run(SerialExecutionQueue.java:102)

at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.base/java.util.concurrent.FutureTask.run(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.base/java.lang.Thread.run(Unknown Source)

Caused by: org.python.core.PyException: ImportError: Error loading module core: Traceback (most recent call last): File "", line 59, in ImportError: Error loading module dumper: Traceback (most recent call last): File "", line 18, in ImportError: Error loading module representer: Traceback (most recent call last): File "", line 298, in File "", line 91, in add_representer TypeError: unhashable type: 'stringmap'

from shared.tools.yaml import core

Executing this line in the script console executes and imports the function right.
When I do the same in the gateway tag change script, I encounter the above.
Any help would be great !

Sorry to hear that - I've updated the module to correct for the import bug. While it's in review, you can download it here.

Ignition-8-shared.tools.yaml-v1.1.0.zip (52.5 KB)

What you saw was a bit of an inside baseball look into how the gateway scope is a little different from the designer. The from module import * directive was pulling in a lot of unexpected stuff that managed to confuse the representer loading. This isn't a bug in how the import works, just a missed __all__ entry from me being sloppy.

I tested it in a tag script, also saw your error, and applied the above to patch it. Cheers!

4 Likes

@andrew.geiger Thank you for the modified code above. I have tested it on my app and it works well. Appriciate your quick response.