system.historian.storeDataPoints does not store float values correctly to MariaDB

Ignition
1

I don’t know if this has been reported yet, but as of 8.3.2, when using system.historian.storeDataPoints to push float values into a MariaDB historian, the value is stored as an intvalue and not floatvalue in the sqlt_data table.

Environment:

Ignition Docker, seen in both 8.3.2 and 8.3.3-rc1. 8.3.1 looks to store the value in the correct column.

MariaDB Docker image, 10.5

My DB connection to MariaDB kept all the default settings in the gateway, as did the historian setup. I think tag changes get stored to the proper column, but I didn’t fully explore that.

My code that I ran in my script console to replicate this:

histProv = "db"
tagProv = "default"
tagPath = "maria/insertFloat"


serverName = system.tag.readBlocking(["[System]Gateway/SystemName"])[0].value
insertFormat = "histprov:{}:/sys:{}:/prov:{}:/tag:{}".format(histProv, serverName, tagProv, tagPath)
print "Insert format: " + insertFormat

system.historian.storeDataPoints([insertFormat], [2.05], [system.date.now()])
2

@Kurt.Larson

3

I’m away from my computer right now, but I’ll dig into this deeper tomorrow.

Regarding the scripting function, nothing has changed specifically with system.historian.storeDataPoints since 8.3.1, but we did fix an issue in 8.3.3 regarding values momentarily hitting the wrong data column within the SQL Historian during datatype changes. Because of that fix, the core tag storage logic has been pretty heavily tested recently.

If you have time to test before I get back, could you check a few things?

Isolate the Environment

  • Have you been able to reproduce this newly on 8.3.1? I want to make sure the success there wasn't just historical/cached.

  • Can you verify that a standard Float tag (driven by a device/simulator, not the script) is landing in the proper column?

Check the Configuration

  • What does the unretired sqlth_te entry look like for one of these tags? Specifically, what is the datatype value set to?

Logger Diagnostics

  • It would be helpful to see the point when the Historian Manager processes it vs. when it actually gets stored. Can you turn these loggers to TRACE and run the script?

    • historian.manager (This shows the point as it's processed initially on the gateway-side).

    • store.forward.sink.TagHistoryDatasourceSink (Warning: This will be very spammy. This shows when the SQL historian actually stores the values).

This should tell us if the SQL Historian actually thinks the tag is an integer, or if the bridge class is converting/dropping precision before it hits the Store & Forward system.

I'll follow up tomorrow. Thanks.