Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Cheers Jared, That's working fine now. Brian

Ohhh.... Is what you wrote there a single scripting source script? Not necessarily. I didn't do anything there that wouldn't work in any of Mango's script environments (well, using a cron pattern limits it to scripting or meta). I did think of it as being a scripting data source, though. CONTEXT_POINTS is a map of varName to their DataPointRT (which is different than the point's script wrapper, so this[varName] !== CONTEXT_POINTS[varName] ) I create a separate point with a script associated as follows, however my solution would require another point for each point I want to monitor... If you're not familiar with Alphanumeric points' regex state detector, you may find that suiting to setting error messages with additional information into a single point and emailing that. You would need to set it back to a non-error state to get the event to raise again, but that's simple enough. If you want historical trending, I would use a meta point for any point you wished to do this for, executing on the same cron and storing the last hours average, something like... var thisAverage = p.last(HOUR).average; var myHistory = my.last(5); //list of PointValueTime objects var historyList = []; for( var j = 0; j < 5; j+=1 ) { historyList.push( myHistory[j].doubleValue ); } historyList.push(thisAverage); var historyScore = historyIsSketchy( historyList ); if( historyScore > 0 ) { //Not null, some string returned, whatever you want to pass to the output point alphanumericRegexStateDetectedContextPoint.set("Badness: " + my.getDataPointWrapper().getExtendedName() + " had a history score of " + historyScore); alphanumericRegexStateDetectedContextPoint.set(""); } return thisAverage; The small blemish being if two meta points interleaved in setting the regex state detecting point to the detected state before reseting it to the base state, one of those events wouldn't be raised. There are certainly ways to solve that if need be. While it may be possible to put event detectors directly on the points you wish to average and then force them somehow through a script that is doing the detection on its context points, that would definitely be hacky. Do you need the event detectors on the points, or to record these events against each point? Edit: And for anyone who likes the simplicity of CONTEXT_POINTS on a scripting data source (where you would only have to add a point to the context to get that behavior), it may be excessive (you could just generate them once and be done, too) but you could create a script to create these meta points for any points in the context (probably want to check if they already exist first!)

So, it seems that the memory usage chart from my last post is "normal" for the JVM, and I have misinterpreted the large upward spikes of memory as a restart when it is, in fact, normal gc behavior. Would you agree with this assessment? For the most part, yes, but in a chart of the internal memory free data point it can appear the same, since both a reset and a full gc will spike back to lots of free memory. If there was any horizontal pause in the chart we could reason the point has no data there, so that could be a restart, but that's probably an unnecessary level inference when the crash times should be recorded in ma.log, ma-script.log and possibly /var/log/messages and the hs_err file if it was a JVM crash. These are MangoES devices, and all configuration was done through the Mango UI. I am unsure what other processes can be affecting OS memory usage that would not have been captured in a database copy. What OS information would be useful in troubleshooting other processes? The script in /opt/mango/bin/ext-enabled sets the memory limits, and that information is not stored in the database so it does not move over in a copy. I would expect the two ES's have the same allocation in the memory-small.sh script in that directory, but you could check. I believe the OOM Killer message in dmesg or /var/log/messages records the process that made the fatal allocation. If Java requested the memory and Java got killed, then we can be confident nothing else on the system is involved. Would it be a reasonable assessment to attribute the Jan21 5am spike in free memory (original post) to gc operations? There was no one working on the system at that time, and memory use continued in the same pattern. I was guessing that to be a crash because it didn't run low (< 100MB remaining) on memory like your other charts have before doing the full gc. I can't say for sure which it is from the chart alone. If the issue has not been replicated, the only other step in troubleshooting I can consider is getting a MangoES v3 to load the backup databases. I'm at a loss for ideas here at this point because we are running on a device pre-configured for the mango service. Do you have any ideas on what else could be running? I would guess your deployed V3 ES is on JDK8 revision 131. The memory settings in the ext-enabled script could be checked. The actual board does differ between the V2 and the V3, but the V3 is more powerful. After examining the files you sent me, I think one of the differences is the size of the data history available to those Meta points. Based on your last post, the Java process itself does not appear to be the root cause for the behavior. Does that make sense or am I jumping to conclusions? I am not aware of any memory leaks in the version I would expect to be on the deployed device (but funnily enough there is a memory leak in the version you were testing, 1.8.0_33 they fixed in 102 or thereabouts!). Updating to the latest JDK8 isn't a bad idea.

I ended up upgrading my EC2 instance one level higher and then gave the JVM a ton of memory, system has been stable and very snappy since.

@jared-wiltshire Cool. That works pretty slick. Thanks Jared.

FYI I added the exact same values a second time to the points history at a different time and now the averages are spot on.

Thought so, thanks for confirming

Hi rshah, It means the modbus slave responded with an error packet, but googling reveals there is no exception code 0x80! This likely means that your serial bus isn't configured correctly (and the CRC error supports that). I would guess your parity setting doesn't match the parity setting of the device, but you should double check the buad rate, data bits, stop bits, etc. against the manual for the device.

The error can be seen in the table name, DATAPOİNTTAGS capitalized incorrectly due to a bug in the JOOQ library. In your other thread I provided instructions on how to set your language to English in the mean time to avoid this issue. In case someone finds it here, For the moment, you could try putting a file like this into Mango/bin/ext-enabled/ BAT if you're on Windows: set-language.bat if "%1" == "init" ( rem Startup with the default language set to English set JAVAOPTS=%JAVAOPTS% -Duser.language=en ) SH otherwise: set-language.sh #!/bin/bash case "$1" in init) # Startup with the default language set to English JAVAOPTS="$JAVAOPTS -Duser.language=en" ;; esac Then stop Mango, and start it again.

@Jared-Wiltshire @phildunlap Thanks again for your help!

Thanks! That was quick!

There is an old acronym, PEBKAC....

LOL didn't even think those might be related. K I'll try to get you something, first I have to migrate my db to nosql.

Thank you! That makes sense, appreciate the help! Edited the title of the post to make it easier for people to find in the future if searching for something similar.

Thank you, it works in my sandbox Mango environment! :) You just saved me 4 hours of exporting-textediting-deleting-importing-testing nightmare! Thanks again!

Good solution!

Thanks @JoelHaggar, I knew I'd take a bit of a performance hit but seeing as a lot of our live values are reporting every few minutes to half an hour, I want to believe speed won't be too much of an issue. Thank you all for your input and advice. This forum really is an excellent source of information.

I didn't find this earlier when searching, but this seems to be similar to unable to discover a bacnet device on my network, specifically in the brief window of apparently successful operation when saving or enabling the publisher.

Surprisingly, resolution was found in slightly different Local Device settings, specifically he had to use the broadcast address that was proper for the network and the sink address to bind. So, in this instance, bind address 0.0.0.0 and broadcast address 192.168.1.255