We’re having a similar problem as described in Sting Data Label In DataMailbox where API call via URL parameters DO NOT bring back any data from the historical log for a “string” data type tag even though data is in there.
I’ve tried getting it via the /ParamForm?AST_Param=$dtHL$ftT$stL$et_m0$ut$tnLOT_CODE
and ParamForm?AST_Param=$dtHL$ftT$st_h24$tnLOT_CODE
but it brings back only the header/column definition values and no data values for the fields.
I’ve already done LOGIO
to get new data in the tag, and it is there is I download via the eWON web UI file transfers. The same API URL call syntax’s work on this same eWON for every other tag than this 1 “string” data type tag we have defined.
Furthermore, we have an internally hosted eSync server that does NOT get the string tag sent to the MySQL tables and I assume that’s because that version of eSync server we use for internal hosting does not allow the value in “string” data type and thus this is why for string data types, I need to use API call to get the value so I can get moved over to our final reporting database.
I believe a colleague is going to put in a call about this and give you guys the full URLs that we are using, but this is what’s going on.
I don’t fully understand the solution mentioned on Sting Data Label In DataMailbox, and I’m wondering if it’s the solution to this problem for us too.
Questions:
- Does the tag names for “string” data types need to follow some standard case sensitivity wise or this “bug” occurs, or what is the deal?
- Is there an eSync server version and correlated documentation for reading regarding us hosting an eSync server than can also take the “string” data types from tags?
- We have most all our eWONs send to our eSycn hosted server MySQL DB that I setup back in the day when Jordan was around, and then we grab the data from there and put it into other reporting DBs and such, and wipe all historical data from the eSync tables that are “x” days old.