To restate above:

My User has a THING in EDT that is monitored. The Mango Server lives in MST. The USER wants to see data on their site in their timezone, so they put in 8/1 to 8/31, they want to see data from 8/1 to 8/31 IN THEIR TIMEZONE (as set by the user timezone setting). They do not want to see that data read in at a different timezone and adjusted, because is in my example earlier, they want 8/1 to 8/31 in EST/EDT, and are getting 7/31-8/30, because "month" changes to midnight.

Any feedback here on this? I really hate daylight savings time, as it provides unnecessary headache to all of this.

What I just told my customer is "You'll have to set your TZ to MST, since that's the best way to make all this line up"

Am I using this wrong? Which bit am I missing?

Greetings:

This just came up again with one of my customers- The Time Zone changed, and things are a little broken again. Is this something that can be fixed so that the not incorrect improper correctional timezone adjustment adjusting is adjusted so that the reports run based on the USERS TZ Selection (and not on the Server's TZ with some adjustment applied?).

Cheers,
-Greg

Greetings, all:

Busy day here in our world headquarters.

I'm trying to do some basic automation here: I've got a device that reliable gets modbus holding register write commands when using the "set" button on the data point details screen.

However, in the script I'm working on, doing the VariableName.set(100) doesn't seem to trigger the Modbus write. This is automatically operated by a context update. When it does, I expect it to write 100 to the external context point mapped to VariableName.

So: Here's what's happening:
(1) The Script is firing properly, and the Set command is running: The graph on the point details screen shows the value being set to 100.
(2) The connected modbus device never gets the value 100
(3) If I manually click "set" on the Details Screen, the connected modbus device gets the command, and operates as expected.

So: What am I doing wrong? The Modbus data point is set for "settable", and since the unit responds as expected using the SET button, I expect that that my modbus serial is working correct.

Everything is set to superadmin, so I don't think there's a roll issue here. I have the current alarms enabled, and I'm not getting any alarms when the set command runs.

My script is literally two lines:
if(PC1.value > 0) {
ModbusOutput.set(100);
}

I just need the number 100 to get written out to the register mapped as ModbusOutput when the PC1 value (which comes in from another modbus point) is > 0.

This is literally the most basic thing ever, and I'm annoyed with myself that it doesn't appear to work.

Thanks!

Cheers,
-Greg Linder

This.. Is a Spicey MeatBall Solution..

So:
(1) The 3.7.7 release has a broken Excel importer, since it's on its way out, anyways.
(2) The only way to modify existing points is to use the REST API as an admin and delete point values using XIDs?
(3) I really don't want to delete.. I want to export, filter, and re-import. I suppose I could do the filtering on a Meta, and "generate history", but there's no way to move that back into the Active polled point, which is used elsewhere in our system for doing other math-related things.

I really think there needs to be some way to do this sort of bulk "export / filter / re-import" way native to Mango..

This, and the benefits of Copy and Paste at the data source level, are two things that have been vanished from the Legacy interface that cause me no small amount of consternation.. I mean, the legacy UI could copy'n'paste data sources, which was a really easy way to roll things out. Now I'm exporting JSON, finding and replacing XIDs, and re-importing, which takes at least a billion times as longer than "copy, paste, rename".

Now I have to go whip up another external tool to Mango to do this export / filter / import thing? I mean.. I guess I can write a custom Excel importer using the "data import" thing, and pipe that back into the system... But the "remove" type of excel interface made this so it was a feature we were trying to sell as a benefit to fix this kind of data catastrophe, which happens more often than not.

Greetings, all:

Perhaps I'm alone in this one, but I (sometimes) have data that writes trash into the database. I try to keep it out, but, well, then a sensor breaks lose and is swinging around in the wind writing a bunch of garbagy numbers into something.

The way I used to do this, as described in a previous thread, was to use the Legacy Point Details screen to export (all) the data from the sad point as an excel file. Into excel it goes, with Standard Excel Stuff Applied to find the points to delete. I would then take the modify (add/delete) column, copy'n'paste as values (so the math and stuff doesn't go back into the import file), and save that as an excel, then use the Legacy UI Data Point Import screen to load that back in.

This worked reliably until I upgraded to 3.7.7.. Now, when I do that process, I see the following message:
Error importing row 12, Invalid text in modify column, add or delete only allowed

The modify columns in question, in fact, contain only the word delete or nothing at all. This has worked in the past.

I know with the V4.0 rollout the Legacy UI is going away entirely; Is there still a way to do this sort of "all the data out, filter it, and load it back in" style of feature? Has this function been removed somehow in 3.7.7? Is there a better way to do this?

I realize that I can filter more with metapoints, and set extreme import sets, and lots of other things when the data is first polled into the system. That's all fine and good. But, well, things happen, and sensors go crazy, and sometimes you're left with a big stack of gibberish that needs some hand-adjusting to straighten out. I don't like doing this, since it's a pain in the butt, but, well, sensors do fail in ways that can't easily be filtered on the input.

This particular example relates to a temperature sensor issue: The sensors were damaged somehow, and the values (although in a valid input range) are clearly changing in ways that are not physically possible. We've identified the problem, and fixed it, but I have a reasonable amount of records in the system that need deleting or adjusting to make this data point usable. Any advice here?

I've got a message into customer support: I'll post here when I get a response (unless they respond here first).

Thanks!

I appreciate your help on this:

I've been gradually rolling out Option (1), and it seems to work out ok. Seems to be it would be a Handy and Useful Feature to have an alarm point that would fail within the Persistent publisher itself when the link fails (for any reason). Maybe some people do persistent links that come up and down randomly through the day, but it seems that the persistent link feature is generally intended to be used.. Well, persistently.

Anyways, the not changed event detector option for the persistent metrics seems to do the job.

Thanks!

-Greg

Greetings:

Just to add:
ItsPronouncedDAYtuh and I are working together on this thing:

We've both been able to replicate this:
(1) If you run a report by Config-> Run, it runs with the local timezone of the user.
(2) If you run a report automatically, it appears to run the report based on adjusting the offset to server time as described above based on the last time the user saved the report. So, for example, if you switch your user account timezone, and the report runs next, it does NOT take the new timezone settings. The user has to go back to the report, re-save the report with their new timezone settings, and then the report runs in that timezone as described above.

In all cases, it appears as though the report is running based on Server Time, but not properly adjusting for the users' time zone setting...

To replicate this:
(1) Set up a report.
(2) Run the report
(3) Change your timezone away from the server timezone
(4) Run the report again
(5) You'll see that the From and Too have been adjusted to the SERVER timezone, with offsets applied from the User timezone, However, something is goofy in this, and it turns out that the data is actually read based on the User TZ, causing a real offset in the data: If a User is in Eastern and runs a report on a Server in Mountain, the report does run over the last month, but it does it as if the user configured the report to run from an offset defined by the difference between user TZ and Server TZ.

This results in, for example, a "last month" setting on relative time to run really from 7/31-8/30, rather than 8/1 to 8/31 (for example).

Cheers,
-Greg Linder

Greetings, all:

Here's something exciting. One of our servers is set to Denver time. Some of our Customers are on the East Coast.

They run reports, using rollup on days and months. Their Time Zone is set for EST (since, well, they're on EST).

So. When they set up their report to do a Monthly Max or Delta, and run it in Denver (SERVER TIME), it runs swell. When they run a report using their own local timezone (EST, in this case) the rollup appears to run the report on the MST (SERVER timezone) settings.

This causes confusion, since the "monthly" reports are actually last day or previous month to day before the last day of this month, due to the 2-hour timeshift, and the midnight hour.

So:

Here's what we see:

Our reports (running on a user with EST Time Zone)
has this line:
"TS_Start - 2020/07/31 22:00:00 MDT to 2020/08/31 22:00:00 MDT"
when set for "monthly" rollups.

Their TimeZone is set to EST, but the reports adjust to MDT to run the report.

If we set their Timezone to Mountain (or server time zone) the following line comes out:
"TS_Start - 2020/08/01 00:00:00 MDT to 2020/09/01 00:00:00 MDT"

Which is what I expect to see. Notice in the previous line, the start and end are 7/31 to 8/31, when we really want 8/1 to 9/1.

I guess what I expect to see, when a report is ran by a user with EST Time Zone Settings, would be this:

"TS_Start - 2020/08/01 00:00:00 EST to 2020/09/01 00:00:00 EST"

Which bit of obviousness am I missing here?

Greetings, Craig:

Thanks for the help.

So, what do the Data Source Exception and Decryption Failed alarms do on the Master side of a persistent tunnel actually indicate? What would cause those to actualy generate their own events?

I've seen the Outstation (Publisher) side give me alarms when alarms are enabled, when I remote in to do troubleshooting and stuff, but I've never see the Master (Data source) alarms actually do anything.. Do they actually alarm on anything? I understand the difficulty of alarming on the Persistent thing, since there's a lot of hair on how people configure it (updating nightly, etc).. So, maybe I just answered my own question there.

I appreciate your advice, and I'll go for option (1). Putting a heartbeat on an edge detector seems like a kludgey workaround to me. And, well, I'm paying for cell data bandwidth here, so I'd rather not shovel more data than I need to. Especially if there's already handy counters built into the Persistent TCP metrics.

You've got me thinking, though, of any other steady-state values I regularly get throughout the day that I could alarm on for this. We do solar, and it changes all day long, but at night nearly all my data goes dead (no sun, you see), but we do have all our environmental sensors going out there. Problem is, we already have alarms on most of those.. and for some really still nights, the temperature and stuff are really quite stable.

I'll have to think a bit on this.. I think maybe your option 1 is probably the best option for this. Thanks for your help!

Cheers,
-Greg

Greetings, all:

I'm running Mango 3.7 right now:

I'm wondering why my Mango Persistent TCP Tunnels don't seem to show alarms. I've got the "Event Alarm Levels" set for Urgent and Urgent for both Data Source Exception and Decryption Failed. We have one of our persistent tunnels offline due to perhaps a cell modem failure, and none of those alarms show in the "current alarms" panel on the Persistent publisher screen.

What am I missing here? I'd like to get an event created when the Tunnel fails, so I can go start fixing the problem.