Offline
Hi All,
Just wanted to let you know we have updated our developers documentation. We have separated it into 2 parts, Angular for the UI and Java for the backend. As of Mango 3.7 there is a new 'development' mode that can save time developing. Check them out here:
To use a specific Timezone:
DateTimeFormatter dateTimeFormatter = DateTimeFormat.forPattern("MM/dd/yyyy HH:mm").withZone(DateTimeZone.UTC);
xbastek,
You say:
But i don't know how to update this files in my mango installation...
It will be far easier for you to upgrade to Mango 2.6.0 that has all the work done for you. It will be pre-released very soon.
Thanks,
Terry
@nachum37 thanks for making us aware of this, I will take the information you provided here and have our team replicate what is happening so we can fix any problems we find.
Sorry, our maven repository only holds the latest snapshot versions and lets the older ones roll off. The latest version is 3.6.1-SNAPSHOT for the api module. Since that version will also eventually drop off of the repository I would suggest you use the release version of the api module as that will always be available. So change the dependency from 3.6.0-SNAPSHOT to 3.6.0 and you should be good to go.
I wrote this help article not too long ago which may provide some insight into configuring the Apache proxy.
@vanjr something isn't quite right with the image you posted. First try to understand what function code 02 is doing, Read an Input Status at an offset starting from 10001.
https://www.simplymodbus.ca/FC02.htm
Maybe I'm missing something but it doesn't seem possible that there is an input register at location 100001 as that offset from 10001 is larger than the 2 bytes that are allowed for the offset in the protocol message of function code 02. My guess is that there is a display error in the software you are using and the address is really 10001 in which case the offset is 0.
@MattFox the problem isn't specifically with our repo. The way maven works is that it checks all the repositories you have listed in the module's POM or its parent POMs in some order.
That plugin isn't owned by us and thus isn't hosted in our maven repository. What your goal should be is to figure out why your build isn't finding it on the public maven repositories such as this one:
https://mvnrepository.com/artifact/org.codehaus.mojo/build-helper-maven-plugin/1.9.1
or this one:
https://central.sonatype.com/artifact/org.codehaus.mojo/build-helper-maven-plugin/1.9.1
I'm pretty sure the problem is that your computer can't reach Maven central because of a proxy or some other problem. I would start by looking there, perhaps delete your
~/.m2
directory and rebuild. Let me know if that solves it or you have a different problem.
@BG I am pretty sure there will be no problems with the versions of MariaDB that support JSON columns. To make a long story short we have not tested it with MariaDB but the only place we use the JSON type column so far is in the create table script for the users table so the alias they have will be fine on that statement.
In the future we may actually create queries that introspect the data in that column but this will likely be for custom modules and not part of the standard Mango application. Also H2 does not support JSON column types so all of our queries basically use that column as a LONGTEXT type currently.
@Nurr
There is the possibility to use the Email Event handler to do this. If you return "CANCEL" from the script on an email event handler it won't actually send an email. Leveraging this one could write a script to make an SQL query for the numbers and then call your global script. You can call Java code directly from the script but it will require some knowledge of Java and how to use it within the Nashorn Javascript Engine. There should be some examples of this on our forum. Basically the script needs superadmin permission and you must use the full package and class name when you reference a Java class.
If you are game to give it a try, here is some documentation on the SQL api for Java:
https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html
As a side note Mango 4.0 will have a Message event handler that will allow using Twilio and in the future other platforms to send messages.
@MattFox just letting you know I've tried in the past to fix this but didn't have much luck. But I tried again today and managed to make an improvement. There are likely other models that will suffer from this problem so when Mango 3.7.0 is released if you see any more of these types of problems please let us know.
Here is the git issue if you are interested in following:
https://github.com/infiniteautomation/ma-modules-public/issues/72
We are looking for examples of how our Rate of Change event detector is being used. We have a list of features and changes for upcoming releases of Mango so I am investigating the use of this detector because it is on our list.
Please let us know the configuration you are using and why please.
Thanks!
@tungthanh500 there are ways around this. In Mango 5 the default is to have HTTPS enabled on first start. This also enables HSTS which redirects from the HTTP port to HTTPS. You can change these settings by injecting mango properties into the container or modifying the mango.properties file you are loading.
Take a look at these properties:
# Note: Enabling SSL/TLS also turns on HSTS by default, see the ssl.hsts.enabled setting below
ssl.on=true
ssl.port=8443
...
# Configure HSTS (HTTP Strict Transport Security)
# Enabled by default when ssl.on=true
# Sets the Strict-Transport-Security header, web browsers will always connect using HTTPS when they
# see this header and they will cache the result for max-age seconds
ssl.hsts.enabled=true
ssl.hsts.maxAge=31536000
ssl.hsts.includeSubDomains=false
And how to inject them into the container as env variables: https://docs-v5.radixiot.com/configure-mango-properties
Just note that if you change the HSTS settings you will need to clear your browser cache since it will have cached the entry to always use HTTPS already.
@MattFox you are correct we were busy with the release of Mango 3.7.x. I'm making some assumptions here but the "too many open files" problem can be caused by the ulimits being too low on a linux system. Each process is assigned a limit to the number of open files it can have and this will need to be increased on a Mango instance with a large number of data points. Since the database is sharded there will be multiple files open for each data point when reading and writing to the database.
Take a look at this post on how to increase these limits:
https://forum.infiniteautomation.com/topic/2624/mango-locking-up-after-2-8-4-update/2
Version 4.2.0
The REST api has a feature that allows bulk updating of data points via a PUT of a JSON array, but this has not been rigorously tested and is still in Beta. Use at your own risk since not every type of data point has been verified to work. I would suggest making a backup of your database prior to testing your specific updates.
Here is the basic idea:
Note that since the JSON structure for a Data Point in the REST API is different than the Mango JSON Export you cannot use one with the other.
Dan,
There is no way to currently get a list of realtime values for multiple points by filtering by data point XID. The next release of Mango will have some RQL endpoints. I can see if I can put it in for the realtime endpoint, this would allow you to perform SQL-like queries via the URL such as:
http://localhost:8080/rest/v1/realtime.json?in(xid,(DP_1,DP_1))&limit(100)
More on RQL here: https://github.com/persvr/rql
For now you could just request ALL the realtime data and filter it by XID on the client side. See this:
http://localhost:8080/rest/v1/realtime.json?limit=100
Where the limit is greater than or equal to the number of points in your Point Hierarchy.
Great news. Also no worries, we all really appreciate the help you provide on the forum so its good to be able to pay you back.
@Phillip-Weeks
That bug is fixed in 3.7.x I was not aware it was in the 3.6 release. I am planning another 3.6 release in the next few weeks so I'll get that fix in there. In the meantime you cannot end a script with a comment line. So adding a newline after that I think should work.
Basically you cannot represent 30.03 exactly in binary.
The publisher is sending the raw value of the data point, which is represented by a Java double as the value you are seeing sent out 30.029...
When using a TextRenderer (which only happens for display purposes) you can set it to round the value via the pattern on it. That is why in the UI it looks correct but it is actually stored as 30.029....
(11110.00000111101011100001)₂ = (1 × 2⁴) + (1 × 2³) + (1 × 2²) + (1 × 2¹) + (0 × 2⁰) + (0 × 2⁻¹) + (0 × 2⁻²) + (0 × 2⁻³) + (0 × 2⁻⁴) + (0 × 2⁻⁵) + (1 × 2⁻⁶) + (1 × 2⁻⁷) + (1 × 2⁻⁸) + (1 × 2⁻⁹) + (0 × 2⁻¹⁰) + (1 × 2⁻¹¹) + (0 × 2⁻¹²) + (1 × 2⁻¹³) + (1 × 2⁻¹⁴) + (1 × 2⁻¹⁵) + (0 × 2⁻¹⁶) + (0 × 2⁻¹⁷) + (0 × 2⁻¹⁸) + (0 × 2⁻¹⁹) + (1 × 2⁻²⁰) = (30.02999973297119140625)₁₀