If you have a chance, we’d like to learn more about the use case behind this request.
By default, PI Vision will automatically pick up and use the time zone of the client machine a user is running their browser on, so all times should be displayed in a user’s local time zone.
If this isn’t the behavior you are seeing, or if you have a use case where users need more control over the time zone being used to display data please let us know.
This is the behavior we are seeing but we would like for our users to go into the settings and change the timezone they prefer to see. Again, we have two Operations centers that span time zones. Both sites will want to view data in the same time zone, even though their client times are local to them.
I understand that users browsers present the data in their time zone. The issue for us is that when Operators are talking to each other, across time zones, they would like to be able to set the time zone by which they are viewing the data. We actually have this issue with other products as well IE Process Book. It seems that there should be an option to use client time, or select from a dropdown the time zone you would like to see the data in.
One other thing not consistent is the way categories are handled between Vision and ProcessBook. We like that users can drag and drop a category from PI vision bringing over multiple tags. You can't drag categories to a display in ProcessBook. Sorting categories also doesn't work in ProcessBook if there are more then one assigned.
101 votesRESEARCHING / EVALUATING · 10 comments · PI Server » Asset Framework (AF) · Flag idea as inappropriate… · Admin →
100 % agree. I think there are other posting in regards to this.
I expand them all every time I open it.
Same boat. They need a better solution here. 10 minuets is short! Ours can take over 45 min.
This item is under technical review. Currently, support for collecting Snapshot data can be achieved via PI to PI interface and should be considered for achieving this specific functionality.
In response to Franz Krauter, "PI to PI in parallel is not a solution. ..."
Couldn't agree more!
In response to Joshua Duncan, "I wouldn't get your hopes up. I received..."
I had heard the same thing, but I've also recently heard they've re considered.
PI to PI and APS is still not meeting our requirements. While OSIsoft says this is the solution, its not a good one. PI APS processes tags one at a time. Startup time for PItoPI is also slow. APS and PItoPI is not multithreaded. The APS syncing for a large amount of tags is not meeting our need. Because the Connector still does not meet our requirements, we've had to add many (currently 14) interfaces which is very difficult to manage across multiple servers at multiple locations. Anytime we have PI to PI or APS talking to systems at other locations (for disaster recovery) latency causes the startup time and sync times to take hours. Not an acceptable high availability solution.
With 47 votes you would think the folks would listen to what we need. I have not been impressed with how slow this connector has been moving. APS and PItoPI are not working for us. Syncing a collective across a few states, causes latency issues and the sync process takes 24 hours currently.
In response to Matthew Bailey, "We need this as well. We have a project ..."
I should add that we have been waiting for the connector to meet these requirements for 4 years!
Essentially we want two collectives ( a source and destination) to be the same.
- Send PI data even if it's not in AF.
- Send real-time snapshot data. It seems really useless for us to be able to only send archive data. Users using the destination system don't get the real-time or accurate values? A breaker is closed, but the users see's it open? Not making sense.
- If a tag name is changed on the source collective, it should update on the destination side.
- Should be much faster then PI to PI and APS (multi threaded), should work better across two locations where latency comes to play.
- Should be easier to configure then PItoPI and APS
We need this as well. We have a project on hold until this is done.
Agree! Seems like a given.
FYI I have found a way to do this and I'll share it so that others know.
1.) Rename the Queue folder located under programdata\osisoft\pinotifications\data\servername
2.) Open System Explorer, click contacts, tools, delivery channels, right click on email, settings.
3.) Change the SMTP server to something fake.
4.) Restart the notifications service.
5.) Wait a few minuets
6.) Update the SMTP Server to the correct server name
7.) Restart the notification service.
This will stop old or queued emails from being sent.
At this time, this item is not currently scheduled for a release of PI Vision. If this changes, this item will be updated to reflect the current status.
We need this for our engineers to edit Limits. We have our Limits set as PI points and if they changed, we would like to allow users with permission to edit values.