To use a specific Timezone:
DateTimeFormatter dateTimeFormatter = DateTimeFormat.forPattern("MM/dd/yyyy HH:mm").withZone(DateTimeZone.UTC);
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:
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.
@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 and you should be good to go.
@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.
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.
If you are game to give it a try, here is some documentation on the SQL api for Java:
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:
@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.
@Pedro unfortunately there is no automatic migration path, the 2 features are very different. The recommended migration path is to rebuild the pages in the new tool, since there are so many more options you will most likely end up with a much nicer page.
The documentation is pretty good and is located in the Mango UI which describes how to use each component.
@Curtis it looks like you ran into the same problem mentioned in a comment the original post. The docs are out of date so I suggest you look at the public modules repository for some examples.
A good example of a module with additional SQL tables would be the Maintenance Events module here:
Above is a link to the code that would be compatible with Mango 4.3.x
By placing a create-Tables-H2.sql file with the table definitions into the resources folder JOOQ will generate the necessary Table and Record classes during the build for you to use your DAO implementation. See the MaintenanceEventDao class for how that works.
Its sort of a chicken-egg problem where you first create the schema, perform a generate phase of the build and then have the generated source to continue your implementation.
Do you know where the Data Source Runtime Status data is kept?
It's only in memory (cached on the running data source).
and is there a way that we could tell Mango to keep more than the previous 10 data point values?
This is hard coded to keep the last 10 poll statistics only.
Just to be sure I read through the status endpoint code and I can't see how it would affect a shard. So either this is an impressive coincidence or we are missing something.
@cmusselm a few thoughts for you.
@rodrigo I imported your example as superadmin and everything works as expected. When I try to create a schedule as non-superadmin I can't even save it, but I don't think this is the problem you are describing.
From the description I see that you are having problems with a non superadmin user. We will need more information to help you out.
Can you elaborate on what "not working" means? Please provide a detailed step by step procedure that describes what the problem is and how to reproduce it.
Can you provide the full log output or screenshot of the event in the UI you are seeing, I'm unsure of what this means and where you see it: "The event states "Scheduler failed to initialize because user does not hold the required role/s"
@hazel there are no plans to update that documentation, your best bet is to review the code for our modules here:
If you can be specific about what you are trying to accomplish I might be able to point you in the direction of some code that will help your specific use-case.
@cbyrne I think it is a side affect of why we implemented the 'Sets historical' feature. That is there to allow importing or generating large amounts of historical data which bypass the point-value event system. This prevents an overload of web socket messages and event detectors raising events.
@cbyrne I was just looking through the Script Data Source code and see that if you have the "Sets historical" checkbox checked it won't fire any events to trigger the meta points.