Doing ICC Virtually as well - Only thing I didn't get with the power historian is how it will be licensed. Didn't get if it is replacing the Tag Historian Module or if this is in addition to that. Also wondering how this affects 3rd party Historians like Canary who currently have to use the Tag Historian module.
It looks to be included in the tag historian module.
Whatsapp support as in alarm pipeline ?
Ps how about a ICC Europe event ?
Yes, it's a new Notification Profile type, for use in Alarm Pipelines.
Is there any breakthrough comming for the code editor?
Note: This is strictly read-only, and not really recommended/encouraged. Power Historian is deliberately meant to be more of a "black box" of optimized history storage (though, it is still just a QuestDB instance, so you can still connect to it from external tooling, we're not locking up your data in anything proprietary).
The term of art here is "deployment modes" - you can have as many as you want, with whatever names you want, and you assign whatever meaning to them. Each deployment mode can override the entire configuration of any gateway config resource, so you can do things like have your database connection swap from a "test" to "prod" instance without having to change the name of anything else in the system.
Standard gateway backups are still all-or-nothing. "Partial" gateway config export/import will be some other file format to reduce confusion, and probably will be an 8.3.X feature, not 8.3.0.
Nothing big coming in 8.3. Definitely plans for future versions.
One thing I just thought about is with all resources and config in JSON and being friendly with version control like Git, is the file system actively watched for updates to JSON files outside of Ignition processes so that any updates are instantly flagged in the designer and/or clients as an update being available, or is this done periodically on some sort of schedule/timer?
Thanks for filling in more details.
In 8.1, yes, at a configurable scan rate with a default value of every five minutes (for projects).
In 8.3, no, not at all. If you push config, you either invoke a REST API method to trigger a demand poll right after (for config), or you call the scripting function to do so (for projects). No more time based scanning, and no more overwriting of file resources with what we loaded in memory.
I've made a little video for the people who could not attend ICC with some of the biggest changes. Go check it out if you're still interested .
I'm wondering if there are any plans for Ignition 8.3 to include support for OPC UA 1.04 or 1.05?
Yes, OPC UA 1.05.
What does that mean to you though? What functionality are you looking for?
Thanks for the confirmation! To be honest, I find OPC UA a bit of a hassle, and I felt that version 1.03 was sufficient. However, some are interested in implementing Companion Specifications and complex types, which, from what I understand, require version 1.04.
Additionally, there’s interest in how MQTT and OPC UA’s Pub/Sub communication, introduced with OPC UA 1.05, will be supported. Could you clarify if Ignition 8.3 will include these features and how they will be integrated?
PubSub is not going to be supported, at least not initially.
Companion specs aren't really relevant for Ignition. As a server, we're just acting as a basically a protocol conversion gateway, and its the driver implementation that decides how data is modeled in the address space. Our server is not there for users to model arbitrary data so companion specs aren't relevant.
As a generic client, whether a server used a companion spec to model its data or not is also not relevant.
Thanks for the clarification Kevin! Looking forward to the release!
Oops. Somehow I quoted myself instead of responding to you...
I was just saying I like your YouTube and I plan to binge watch it when I'm less jetlagged. Good stuff.
Where did you make this video? In the Attic?
Thanks allot! I just have 2 video’s so far, so you’ll be done quick
That is my office, but still a bit under construction
Good stuff! Thanks for the video Jasper.