@cmusselm Thanks for letting me know!

One other note on this.

I found the following info on the 65533 value/� symbol:

U+FFFD (decimal 65533) is the "replacement character". When a decoder encounters an invalid sequence of bytes, it may (depending on its configuration) substitute � for the corrupt sequence and continue.

One common reason for a "corrupt" sequence is that the wrong decoder has been applied.

Hi, Terry,

Is the comment you made here: https://forum.mango-os.com/topic/4691/virtual-serial-client/24 still valid? This seems like the exact situation we have.

This device is a black box, and cannot connect to our IP:port, we have to open a socket to it and just listen to capture packets that it sends out. Based on your note, it sounds like using a Virtual Serial Client with a Serial data source won't work.

If that's the case, is the only real solution to create some middleware/applet that connects to the host and reads the data, then pass it along to Mango in a way it can read?

We thought that if the device passes data every 6 seconds, and we use a TCP/IP Data Source to poll it every 3 seconds, we'd be guaranteed to get all of the packets, but that actually made the results worse, and we got fewer packets than when we had it polling every 6.3 seconds. (Don't know why adding the 0.3 seconds makes a difference, but it definitely does.)

Thanks,
Chad

I know it's been a while, but I wanted to let others know what I found with this.

I created a test scripting data source with 110 data points. (I would post it here, but its 5700 lines and I don't have permissions to attach the file.) I basically use the .set for all 110 data points.

When I clicked the validate button I would get the following error:

ReferenceError: "varDP110" is not defined at line: 28

The error was not generated when the script ran on its normal schedule, so from what I can tell it's something related to how the validate button pulls in the variables for the script to run.

Thanks,
Chad

Excellent, glad you got it working. Basically, you need to allow unprivileged users access to lower ports. By default, Linux does not allow this.

Bizarre, help docs used to mention using -1 as no limit. Glad you have got it sorted!

Fox

Thanks, Craig, that explains some of the results I've seen.

For the specific example I showed, the poll had a timeout of 4 seconds, and it was coming back in 3.2 seconds. Since there was no Modbus device actually connected to that IP, did Mango report the poll simply because it received TCP/IP info from the server?

One other quick note I forgot to include...

When I first tried this solution I was getting an error about a valid certificate path. I found this on Stack Overflow which resolve that issue: https://stackoverflow.com/questions/21076179/pkix-path-building-failed-and-unable-to-find-valid-certification-path-to-requ

@cmusselm
that is a good outcome! Thanks for the update.

Terry,

Updating the priority seemed to do the trick. The job ran on time this morning.

Another factor that I'm sure contributed is that we didn't realize our CPU was pegged for a couple days and had to restart Mango to clear that up. (Different post created for that issue...)

Thanks,
Chad

@cmusselm that setting may help depending on what you are doing. That setting will effectively send a short value to a register if it is 2 bytes according to the point locator's modbus data type. If it is > 2 bytes then no matter what it will send an array to the slave and likely will write > 1 register.

Wanted to give a quick update to let others know how this was resolved.

After working with the support team (thanks, Craig!) we found it it was a licensing issue. Once our license was updated and applied everything worked as expected.

Thanks, Craig, for the info. I've removed the Font Awesome JS reference and can still see the icons, so that's good.

The bad news is that I still get the error posted in my initial post. Not sure what's causing it now. The only thing I thought each page with the error had in common was using Font Awesome, but it must be something else. I even removed all references to Font Awesome and still got an error.

I have a work-around, so it's not the end of the world, just a little annoying.

Thanks,
Chad

Thanks, Terry, that's great info, I'll try that out!

One more bit of information I discovered a couple days ago.

For a different reason, we had to reboot the production instance. After the reboot, we were getting warning in the MA.log file about datapoints being too far into the future. Of course it was the data points we were retrieving via the JSON retriever.

As a quick fix I updated the data points, removing the Time JSON Pointer so it used the Mango timestamp.

Something seems off with how that played out. Why didn't the system start to flag the datapoints with that warning right away after I updated the system to not allow data points that far into the future? Does that setting not take effect until reboot? If so, some warning about that on-screen would be nice.

Also, after the reboot it was complaining about every poll having a future date/time stamp. If that's the case, then why didn't the point details screenshot shown above use that future time stamp when the values were being recorded. Seems that some of the date/time functions aren't behaving properly.

Thanks for the confirmation, I appreciate it.

Awesome, thank you! I'll try this out.

Thank you! That probably won't make the point usable for what we want, but is good to know. I guess we could use the /data-sources/status/{xid} API endpoint and parse the results to see if there are any failures over the past x minutes.

Just realised in my own silly way that the tags is an object. Not an array.. Need more coffee!
pt.tags.join(',') Will not work.
I believe you can usept.tags|json or you can choose what tags you want to show with pt.tags.tag1 or whatever naming convention you used...

Fox