Unable to work with AlarmEvents (SOAP REST Provider)

[henrik_alarmdir]

Having some troubles working with AlarmEvents 

I testing using the builtin swagger, before I will start any implementation, I suppose that should work?

I'm simply trying to do a simple alarm acknowledge, however no matter what request try I receive a 404 error

request:  http://127.0.0.1:8085/AlarmEvents

Response:

[
{
"AlarmId": "02/EBO1/Folder/Function Block Program/ALARM_1",
"Acknowledgeable": 1,
"OccurredOn": "2020-03-04T10:41:31Z",
"LastTransitionedOn": "2020-03-04T11:02:07Z",
"Message": "",
"Priority": 1,
"State": 3,
"Type": "",
"AlarmSourceName": "ALARM_1",
"Id": "/EBO1|/EBO1/Folder/Function Block Program/ALARM_1|3687876d-e20b-482c-9062-3136e16aa711"
},
{
"AlarmId": "02/EBO1/Folder/Function Block Program/ALARM_2",
"Acknowledgeable": 1,
"OccurredOn": "2020-03-04T10:41:31Z",
"LastTransitionedOn": "2020-03-04T11:02:07Z",
"Message": "",
"Priority": 1,
"State": 3,
"Type": "",
"AlarmSourceName": "ALARM_2",
"Id": "/EBO1|/EBO1/Folder/Function Block Program/ALARM_2|0b61c207-202a-4284-89e8-235d14b105a9"
},
{
"AlarmId": "02/EBO1/Folder/COS_1",
"Acknowledgeable": 1,
"OccurredOn": "2020-03-04T11:13:50Z",
"LastTransitionedOn": "2020-03-04T11:13:50Z",
"Message": "Into Alarm",
"Priority": 1,
"State": 1,
"Type": "",
"AlarmSourceName": "COS_1",
"Id": "/EBO1|/EBO1/Folder/COS_1|98dee723-6f77-400b-a8d6-62dc97a447c3"
}
]

Now I try to ack COS_1 and I tried to use AlarmId and Id provided above, that just don't work (404).

http://127.0.0.1:8085/AlarmEvents/02%2FEBO1%2FFolder%2FCOS_1/Acknowledge

404

http://127.0.0.1:8085/AlarmEvents/%2FEBO1%7C%2FEBO1%2FFolder%2FCOS_1%7C98dee723-6f77-400b-a8d6-62dc97a447c3/Acknowledge

404

I also tried other requests and none works

http://127.0.0.1:8085/AlarmEvents/%2202%2FEBO1%2FFolder%2FCOS_1%22

404

What am I missing here?

[JeffBowman · Accepted solution]

Hi Henrik,

I think the issue you are running into is that the {id} in the URL actually needs to be double URL encoded. Swagger single encodes it.

To test this, copy your alrm ID (the one that ends with the GUID looking string), into a tool like: https://meyerweb.com/eric/tools/dencoder/ and encode it. Then use the resulting string as the {id}.

I think that will make the 404 go away :).

Best Regards,

-Jeff

[henrik_alarmdir]

Yeah, thanks Jeff, as simple as that.

And now I can ack alarms too, at least from behind a smartconnector, the thing is (if you remember two years back), I needed to use EWS protocol directly due to missing functionalities of the REST providers in smartconnector. (e.g. GetAlarmHistory).

I can use forcevalues etc. without problems but I'm having difficulties acknowledging alarms on that interface so I thought I might try to see whats happening when using SOAP REST provider, now I can see that works fine so I must conclude that this provider must be using something else than EWS against the EBO Server ( EcoStruxure Building Operation 3.1  Enterprise Server).

When I request AlarmEvents on EWS I get the AlarmEvents, just like here, except from that the property "acknowledgeable" is 0 (zero).

And when I try to acknowledge I get permission_denied, I think that's really weird because I using the same account and the same alarms.

EWS configuration of course has Acknowledge alarms = Enabled, when I disable that, I get Operation not supported, which makes sense.

And when I check the supported requests I get these back.

11:12:26 VERBOSE: Profile:Basic Exchange Profile supported
11:12:26 VERBOSE: Profile:Alarm Profile supported
11:12:26 VERBOSE: Profile:History Profile supported
11:12:26 VERBOSE: Profile:Pull Eventing supported
11:12:26 VERBOSE: Operation:AcknowledgeAlarmEvents supported
11:12:26 VERBOSE: Operation:ForceValues supported
11:12:27 VERBOSE: Operation:GetAlarmEvents supported
11:12:27 VERBOSE: Operation:GetAlarmEventTypes supported
11:12:27 VERBOSE: Operation:GetAlarmHistory supported
11:12:27 VERBOSE: Operation:GetContainerItems supported
11:12:27 VERBOSE: Operation:GetEnums supported
11:12:27 VERBOSE: Operation:GetHierarchicalInformation supported
11:12:27 VERBOSE: Operation:GetHistory supported
11:12:27 VERBOSE: Operation:GetItems supported
11:12:27 VERBOSE: Operation:GetNotification supported
11:12:27 VERBOSE: Operation:GetUpdatedAlarmEvents supported
11:12:27 VERBOSE: Operation:GetValues supported
11:12:27 VERBOSE: Operation:GetWebServiceInformation supported
11:12:27 VERBOSE: Operation:Renew supported
11:12:27 VERBOSE: Operation:SetValues supported
11:12:27 VERBOSE: Operation:Subscribe supported
11:12:27 VERBOSE: Operation:UnforceValues supported
11:12:27 VERBOSE: Operation:Unsubscribe supported

{
"version": "1.2",
"version_Specified": true,
"getAlarmHistoryResponseStatus": {
"moreDataAvailable": false,
"moreDataRef": "",
"moreDataRef_Specified": false,
"dataContext": null
},
"getAlarmHistoryAlarmEvents": {
"alarmEvent": [
{
"iD": "21634",
"sourceID": "02/EBO1/Folder/Function Block Program/ALARM_1",
"sourceName": "ALARM_1",
"acknowledgeable": 0,
"timeStampOccurrence": {
"dateTime": "2020-03-04T10:41:31Z",
"dataContext": null
},
"timeStampTransition": {
"dateTime": "2020-03-04T10:41:31Z",
"dataContext": null
},
"priority": 1,
"state": 1,
"type_": "",
"message_": "Into alarm",
"dataContext": null
},
{
"iD": "21635",
"sourceID": "02/EBO1/Folder/Function Block Program/ALARM_2",
"sourceName": "ALARM_2",
"acknowledgeable": 0,
"timeStampOccurrence": {
"dateTime": "2020-03-04T10:41:31Z",
"dataContext": null
},
"timeStampTransition": {
"dateTime": "2020-03-04T10:41:31Z",
"dataContext": null
},
"priority": 1,
"state": 1,
"type_": "",
"message_": "Into alarm",
"dataContext": null
}
],
"alarmEvent_Specified": true,
"metadata": [],
"metadata_Specified": false,
"dataContext": null
},
"dataContext": null
}

Any suggestions?

regards

Henrik

[JeffBowman · Accepted solution]

Hi Henrik,

Good to hear you are able to acknowledge now via the REST Provider now.

I can assure you that the SOAP REST provider is using pure EWS behind the scenes, and we are doing nothing fancy or different in terms of acknowledgement. 

GetAlarmHistory does not return acknowledgable alarms, it only returns historical alarms (ones that are not active). You would need to use GetAlarmEvents/GetUpdatedAlarmEvents to get alarm events that are acknowledgeable.

Best Regards,

-Jeff

[henrik_alarmdir]

Ahhh, I see, okay so to me that would mean crossing the creek to fetch water 🙂

So a combination of GetAlarmHistory and to acknowledge, also use GetAlarmEvents and GetUpdatedAlarmEvents to fetch the Id.

Thanks Jeff, that seems to work, a bit complex to implement such a "simple" feature though 😉

regards

Henrik