I put the newly created mango.properties file in the mango root folder, just with the specific lines as above.
This worked

@mwright Further to this, "restarting of Mango fixes the issue", without doing anything with Windows. Suggesting that if Windows did grab the COM port for some process, it re-released it
after.

I'm not asking for anything, but future updates might include attempts to re-open the COM ports once this error is encountered, as this error just kills the data source.

So it's a standard Modbus response:

05 ACKNOWLEDGE

The slave has accepted the request
and is processing it, but a long duration
of time will be required to do so. This
response is returned to prevent a
timeout error from occurring in the
master. The master can next issue a
Poll Program Complete message to
determine if processing is completed

@lgorence https://docs-v4.radixiot.com/clean-mango-properties-file

@hayden_AUS thanks for your help!

Fox

@terrypacker Thanks, I will set them up using meta points as you suggest.

@MattFox yes we are aware of the email problem and are working on it.

I could see this being a new feature/change to the way it works. Instead of only having a single delay task we could have many. For example if your meta point is context updating every 1s and your execution delay is 1hr after 1hr of running you will have 3600 tasks sitting around with 1 executing every second after that. Execution delays were not really designed for that though as if you were to stop mango or that data source you would lose 3600 point values in the tasks that had not yet run.

So an event detector must be used to trigger your alarm.

That's exactly what I was in the middle of discussing with Hayden...

Wow, you're correct

Just press ENTER !

Didn't press ENTER, just SAVE.

Thanks

Okay, I took a deeper look, and it appears the validation of binary meta points and other scripts with expected result types has an issue with returning false, as the message reports as though it return UNCHANGED; . This does not affect the actual runtime of the points or other such scripts. So, that explains the output on the validation in the first post. https://github.com/infiniteautomation/ma-core-public/issues/1487

Thanks for bringing this to our attention!

I have not been able to reproduce the event message except by returning a value with something like the lastValue function, although it could be a binary point doing that as well. In your first script there is an else if so it would be possible not to return a value, although I would expect it to get a false (binary) / 0 (numeric and meta) / empty string (alphanumeric) value if nothing is returned.

@hayden_AUS I incorporated a calculator directly into the data point editor for modbus points -
https://forum.infiniteautomation.com/topic/4477/release-notes-for-modbus-3-6-4

@phildunlap said in Multiple Set Points in Event Handler:

it doesn't sound to me like that'd solve how his users are going to identify points they want to control and control them easily. That's going to be an issue only his implementation of a dashboard / Mango could completely solve.

Agreed, but as he was only able to give an example without greater in depth information on the desired outcome, only wishing to be able to add multiple points to a context. I'd give him what I knew was freely available. I do not believe he wants to go into the grit of a custom dashboard page at this time. However, if that changes I'll be more than happy to assist.

Fox

Thanks Jared, you guys are awesome!

Great response time, much appreciated.

@craigweb said in Multiple Set points on one Event Handler:

set them to your desired value in the script. with key.set(True)

Just an FYI.... you mean key.set(true); not 'True'

OK thanks Phil, will do some experimenting.

I checked the free bundle, it doesn't seem to have the NoSQL module so I'm not sure what happened there.

See ya in the emails!

I've written a few scripts/dashboards that involve irrigation in mango. Due to IP I cannot share it. I can definitely agree with the idea of using the advanced scheduler as that allows you to use time when to fire and set a duration.
However if they are always sequential and you know that you will always have a fixed amount of sprinkler zones to work with I suggest doing a dashboard that involves the use of slider inputs to set your duration either in minutes or percentage (if your time will never exceed n minutes) and perhaps the same for a delay tied to a virtual data point. And also a binary datapoint with a <ma-switch) to toggle a zone on or off.
As Phil suggests if you've got a PLC in the mix definitely use that as I'm sure you must have some sort of real time clock you can work from to generate the interrupts you need. Then map those to the settings generated via mango. ie timer ticks etc

I'm not hugely aware of how your system is constructed. At least by every time you make an amendment to these settings, you can either make it trigger an update via the scripting source to push these settings down the line. Otherwise set it to have an hourly (or whatever is needed) push for the settings.

Happy to give more input if you can describe how the system works. Sorry I don't use modbus so I cannot help a great deal in that area.

Hmm. Do you know if you saved the point link when the event was active, and that's when it returned to normal?

I do think it's possible for a point link to get stuck thinking it's running. I think it would have to be an exception in the PointLinkRT's execute method. I'm not sure where one could produce such an error, but I will do some checking. I would have expected an error in your log like, "Uncaught exception in work item" and that the PointLinkRT's execute method will appear in the stack trace.

Otherwise, it could be that two point events for the source series were running at the same moment and the error about not being able to run the point link again is incidental to not having set the value to the device. If the modbus connection was simply down AND two events got queued at the same time, we could expect what you're describing. There would have been a data source event for the set point failure.

I have ensured the .sh scripts will be executable when downloaded from the store. This was caused by some recent changes we made in the store to make uploading new minor releases easier for us. Sorry for the inconvenience.

Edit: As of 5/7/18 the file permissions in the downloads will be right on Mac / Unix if you unzip it on the command line using "unzip" but may be wrong if you unzip them by right clicking the archive in a file explorer and extracting. We'll iron out this issue sooner than later.