Our Milestone plugin integration needs to get a list of sensors from our own third party system and automatically add them into Milestone .
Our solution is partially working. When our Milestone plugin connects to our system, sensors are automatically added to Milestone. These automatically added sensor items appear in almost every list they should, including as alarm definition sources and as items that can be placed on the map. But they do not appear as possible sources for rule trigger events. On the other hand, if we manually add one of our custom sensor items through the management client, that sensor appears in the list of sources for a rule trigger event.
Note: sensors can produce custom events, and these custom event can be set as a trigger for a rule, the issue arises after setting the custom sensor event as a trigger, when trying to select a source for the custom event that triggers the rule.
Why do the manually added sensor items appear as possible sources for a rule trigger event but the automatically added ones do not?
Here is how new sensors are automatically added in the code of the MIP SDK plugin. This is in the BackgroundPlugin.cs file
No matter if the background plugin is in the MC or elsewhere, it is important to know that the MC is unfortunately not reloaded automatically. If you push F5 or click Action → Refresh you might discover that the item is added.
Note; when creating Alarms the MC does ask the Event Server every time and no cached data causes this issue.
Yes the plugin is a MC plugin. The items are successfully added, the issue is that once added, they do not appear as a possible source for an event that can trigger a rule. Event after refreshing the management client. But they appear in the list of devices for alarm sources and in the general list of items for our plugin.
Is it at all possible that the “Kind” for the auto-created items vs the user-created items is different? It seems like as long as you’ve overridden the GetKnownEventTypes and GetKnownEventGroups methods in your ItemManager, it shouldn’t matter whether the items were created from the admin plugin or the background plugin, with the only caveat being that if the items were created in the background plugin while the Management Client was open, there probably isn’t a good way to automatically refresh the configurationmanager passed to the “rules plugin” in the Management Client so a refresh or re-launch of the Management Client might be necessary to discover them. I’m assuming you’ve tried that though. And I’m guessing you’re referencing the same GUID constant for the Kind in both places but that’s the only thing that jumps out at me as an obvious reason why you’d get different behavior between the background plugin and the admin plugin.
Another thing that might explain it is if the events aren’t visible to the management client until the management server has been restarted. I don’t know if that would be the case, but it feels like the intent of an admin plugin is to create/manage item configuration and the intent of a background plugin is to do something in the background, but not necessarily manage configuration. So maybe the configurationmanager in the Management Client triggers something on the management server that the event server doesn’t do with background plugins? Definitely something for one of our SDK devs to comment on - I don’t spend a lot of time with admin plugins personally.