Details
-
Type: Monitor
-
Status: Closed
-
Priority: Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:
-
HD-Chapter:Data
-
HD-Enabler:Orion
Description
Created question in FIWARE Q/A platform on 24-03-2017 at 11:03
Please, ANSWER this question AT http://stackoverflow.com/questions/42997579/fiware-orion-context-broker-subscription-notification-issue
Question:
Fiware Orion context broker subscription/notification issue
Description:
I'm using orion context broker GE image orion-psb-image-R5.4 and I registered a device entity in it , then i implemented in my raspberry pi simple python server script that listens to any incoming message and print it on the Pi's logs . then i sent a subscription message to the context broker to let my raspberry pi subscribe to its corresponding entity in the context broker. The issue is that whenever i update the condition attributes in the entity in the context broker , they're supposed to trigger a notification to the raspberry pi and then the server script in the PI print the notification in the Pi's logs . But what really happens is that the context broker may trigger the notification for once and then stops sending any notification when any additional change is applied to the condition attribute , and on every attempt i make i retrieve the subscription status in the context broker and i find that there was a failure stated by the lastfailure attribute giving me the time of my last failed attempt.
I thought the problem could be the connection to my Pi or even in the server script itself but when i launched direct requests from my terminal to the raspberry pi , it prints the all messages immediately even when the update is made from a remote place . So i concluded that the problem is definitely with the context broker and the notification process of the subscription itself .
Here's the subscription request i made :
curl -v contextbrokeraddress:1026/v2/subscriptions -s -S --header "Fiware-Service: XYZ" --header "Fiware-ServicePath: /XYZ" --header 'Content-Type: application/json' \
d @ <<EOF
{
"description": " Try",
"subject": {
"entities": [
],
"condition":
},
"notification": {
"http":
,
"attrs": [
"switch",
"datashow"
]
},
"expires": "2040-01-01T14:00:00.00Z",
"throttling": 5
}
EOF
now when the switch attribute is updated with a different value , it may trigger the notification to the raspberry pi for the first time only but then fails on any following attempts.
this is the simple python script that listens to the incoming notifications and print it in its logs:
import socket
HOST, PORT = '', 8080
listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
listen_socket.bind((HOST, PORT))
listen_socket.listen(1)
while True:
print "listening on port 8080"
client_connection, client_address = listen_socket.accept()
print "notified"
request = client_connection.recv(1024)
print request
client_connection.close()
And this is how the notification from the context broker is printed on the Pi's logs in its ONLY successful time:
listening on port 8080
notified
POST / HTTP/1.1
User-Agent: orion/1.7.0 libcurl/7.19.7
Host: raspberryPiaddress:8080
fiware-service: XYZ
Fiware-ServicePath: /XYZ
X-Auth-Token: token
Accept: application/json
Content-length: 208
Content-type: application/json; charset=utf-8
Fiware-Correlator: f48ced60-1069-11e7-b743-fa163e7c4daf
Ngsiv2-AttrsFormat: normalized
{"subscriptionId":"58cd49191e9c000de6ea89c7","data":[{"id":"Controller1","type":"Controller","switch":{"type":"command","value":"OFF","metadata":{}},"datashow":{"type":"string","value":"OFF","metadata":{}}}]}
And when the notification is not received on any following updates on the entity , i check that it was failure by retrieving the subscription status which states that a failure happened in the context broker on sending the notification at the exact time of my attempt. This the status i retrieve to check that:
[
{
"description": " Try",
"expires": "2040-01-01T14:00:00.00Z",
"id": "58cd49191e9c000de6ea89c7",
"notification": {
"attrs": [
"switch",
"datashow"
],
"attrsFormat": "normalized",
"http":
,
*"lastFailure": "2017-03-24T08:22:23.00Z",*
"lastNotification": "2017-03-24T08:22:18.00Z",
"lastSuccess": "2017-03-23T22:09:33.00Z",
"timesSent": 66
},
"status": "failed",
"subject": {
"condition":
,
"entities": [
]
},
"throttling": 5
}
]
the problem now seems to be relating to the context broker and the way the subscription/notification processes are handled inside it . Now, i want to know whether the problem regards the context broker image version that i used or whether it regards something else . I just want to know where's the problem and how it can be handled please and thanks so much.
Activity
Field | Original Value | New Value |
---|---|---|
Component/s | FIWARE-TECH-HELP [ 10278 ] |
Assignee | Fermín Galán [ fermin ] |
HD-Enabler | Orion [ 10875 ] | |
Description |
Created question in FIWARE Q/A platform on 24-03-2017 at 11:03 {color: red}Please, ANSWER this question AT{color} http://stackoverflow.com/questions/42997579/fiware-orion-context-broker-subscription-notification-issue +Question:+ Fiware Orion context broker subscription/notification issue +Description:+ I'm using orion context broker GE image orion-psb-image-R5.4 and I registered a device entity in it , then i implemented in my raspberry pi simple python server script that listens to any incoming message and print it on the Pi's logs . then i sent a subscription message to the context broker to let my raspberry pi subscribe to its corresponding entity in the context broker. The issue is that whenever i update the condition attributes in the entity in the context broker , they're supposed to trigger a notification to the raspberry pi and then the server script in the PI print the notification in the Pi's logs . But what really happens is that the context broker may trigger the notification for once and then stops sending any notification when any additional change is applied to the condition attribute , and on every attempt i make i retrieve the subscription status in the context broker and i find that there was a failure stated by the lastfailure attribute giving me the time of my last failed attempt. I thought the problem could be the connection to my Pi or even in the server script itself but when i launched direct requests from my terminal to the raspberry pi , it prints the all messages immediately even when the update is made from a remote place . So i concluded that the problem is definitely with the context broker and the notification process of the subscription itself . Here's the subscription request i made : curl -v contextbrokeraddress:1026/v2/subscriptions -s -S --header "Fiware-Service: XYZ" --header "Fiware-ServicePath: /XYZ" --header 'Content-Type: application/json' \ -d @- <<EOF { "description": " Try", "subject": { "entities": [ { "id": "Controller1", "type": "Controller" } ], "condition": { "attrs": [ "switch", "datashow" ] } }, "notification": { "http": { "url": "http://raspberryPiaddress:8080" }, "attrs": [ "switch", "datashow" ] }, "expires": "2040-01-01T14:00:00.00Z", "throttling": 5 } EOF now when the switch attribute is updated with a different value , it may trigger the notification to the raspberry pi for the first time only but then fails on any following attempts. this is the simple python script that listens to the incoming notifications and print it in its logs: import socket HOST, PORT = '', 8080 listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind((HOST, PORT)) listen_socket.listen(1) while True: print "listening on port 8080" client_connection, client_address = listen_socket.accept() print "notified" request = client_connection.recv(1024) print request client_connection.close() And this is how the notification from the context broker is printed on the Pi's logs in its ONLY successful time: listening on port 8080 notified POST / HTTP/1.1 User-Agent: orion/1.7.0 libcurl/7.19.7 Host: raspberryPiaddress:8080 fiware-service: XYZ Fiware-ServicePath: /XYZ X-Auth-Token: token Accept: application/json Content-length: 208 Content-type: application/json; charset=utf-8 Fiware-Correlator: f48ced60-1069-11e7-b743-fa163e7c4daf Ngsiv2-AttrsFormat: normalized {"subscriptionId":"58cd49191e9c000de6ea89c7","data":[{"id":"Controller1","type":"Controller","switch":{"type":"command","value":"OFF","metadata":{}},"datashow":{"type":"string","value":"OFF","metadata":{}}}]} And when the notification is not received on any following updates on the entity , i check that it was failure by retrieving the subscription status which states that a failure happened in the context broker on sending the notification at the exact time of my attempt. This the status i retrieve to check that: [ { "description": " Try", "expires": "2040-01-01T14:00:00.00Z", "id": "58cd49191e9c000de6ea89c7", "notification": { "attrs": [ "switch", "datashow" ], "attrsFormat": "normalized", "http": { "url": "http://ahmadpi.ddns.net:8080" }, **"lastFailure": "2017-03-24T08:22:23.00Z",** "lastNotification": "2017-03-24T08:22:18.00Z", "lastSuccess": "2017-03-23T22:09:33.00Z", "timesSent": 66 }, "status": "failed", "subject": { "condition": { "attrs": [ "switch", "datashow" ] }, "entities": [ { "id": "Controller1", "type": "Controller" } ] }, "throttling": 5 } ] the problem now seems to be relating to the context broker and the way the subscription/notification processes are handled inside it . Now, i want to know whether the problem regards the context broker image version that i used or whether it regards something else . I just want to know where's the problem and how it can be handled please and thanks so much. |
Created question in FIWARE Q/A platform on 24-03-2017 at 11:03
{color: red}Please, ANSWER this question AT{color} http://stackoverflow.com/questions/42997579/fiware-orion-context-broker-subscription-notification-issue +Question:+ Fiware Orion context broker subscription/notification issue +Description:+ I'm using orion context broker GE image orion-psb-image-R5.4 and I registered a device entity in it , then i implemented in my raspberry pi simple python server script that listens to any incoming message and print it on the Pi's logs . then i sent a subscription message to the context broker to let my raspberry pi subscribe to its corresponding entity in the context broker. The issue is that whenever i update the condition attributes in the entity in the context broker , they're supposed to trigger a notification to the raspberry pi and then the server script in the PI print the notification in the Pi's logs . But what really happens is that the context broker may trigger the notification for once and then stops sending any notification when any additional change is applied to the condition attribute , and on every attempt i make i retrieve the subscription status in the context broker and i find that there was a failure stated by the lastfailure attribute giving me the time of my last failed attempt. I thought the problem could be the connection to my Pi or even in the server script itself but when i launched direct requests from my terminal to the raspberry pi , it prints the all messages immediately even when the update is made from a remote place . So i concluded that the problem is definitely with the context broker and the notification process of the subscription itself . Here's the subscription request i made : curl -v contextbrokeraddress:1026/v2/subscriptions -s -S --header "Fiware-Service: XYZ" --header "Fiware-ServicePath: /XYZ" --header 'Content-Type: application/json' \ -d @- <<EOF { "description": " Try", "subject": { "entities": [ { "id": "Controller1", "type": "Controller" } ], "condition": { "attrs": [ "switch", "datashow" ] } }, "notification": { "http": { "url": "http://raspberryPiaddress:8080" }, "attrs": [ "switch", "datashow" ] }, "expires": "2040-01-01T14:00:00.00Z", "throttling": 5 } EOF now when the switch attribute is updated with a different value , it may trigger the notification to the raspberry pi for the first time only but then fails on any following attempts. this is the simple python script that listens to the incoming notifications and print it in its logs: import socket HOST, PORT = '', 8080 listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind((HOST, PORT)) listen_socket.listen(1) while True: print "listening on port 8080" client_connection, client_address = listen_socket.accept() print "notified" request = client_connection.recv(1024) print request client_connection.close() And this is how the notification from the context broker is printed on the Pi's logs in its ONLY successful time: listening on port 8080 notified POST / HTTP/1.1 User-Agent: orion/1.7.0 libcurl/7.19.7 Host: raspberryPiaddress:8080 fiware-service: XYZ Fiware-ServicePath: /XYZ X-Auth-Token: token Accept: application/json Content-length: 208 Content-type: application/json; charset=utf-8 Fiware-Correlator: f48ced60-1069-11e7-b743-fa163e7c4daf Ngsiv2-AttrsFormat: normalized {"subscriptionId":"58cd49191e9c000de6ea89c7","data":[{"id":"Controller1","type":"Controller","switch":{"type":"command","value":"OFF","metadata":{}},"datashow":{"type":"string","value":"OFF","metadata":{}}}]} And when the notification is not received on any following updates on the entity , i check that it was failure by retrieving the subscription status which states that a failure happened in the context broker on sending the notification at the exact time of my attempt. This the status i retrieve to check that: [ { "description": " Try", "expires": "2040-01-01T14:00:00.00Z", "id": "58cd49191e9c000de6ea89c7", "notification": { "attrs": [ "switch", "datashow" ], "attrsFormat": "normalized", "http": { "url": "http://ahmadpi.ddns.net:8080" }, **"lastFailure": "2017-03-24T08:22:23.00Z",** "lastNotification": "2017-03-24T08:22:18.00Z", "lastSuccess": "2017-03-23T22:09:33.00Z", "timesSent": 66 }, "status": "failed", "subject": { "condition": { "attrs": [ "switch", "datashow" ] }, "entities": [ { "id": "Controller1", "type": "Controller" } ] }, "throttling": 5 } ] the problem now seems to be relating to the context broker and the way the subscription/notification processes are handled inside it . Now, i want to know whether the problem regards the context broker image version that i used or whether it regards something else . I just want to know where's the problem and how it can be handled please and thanks so much. |
HD-Chapter | Data [ 10838 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Status | In Progress [ 3 ] | Impeded [ 10004 ] |
Status | Impeded [ 10004 ] | In Progress [ 3 ] |
Status | In Progress [ 3 ] | Answered [ 10104 ] |
Resolution | Done [ 10000 ] | |
Status | Answered [ 10104 ] | Closed [ 6 ] |
Fix Version/s | 2021 [ 12600 ] |
Transition | Time In Source Status | Execution Times | Last Executer | Last Execution Date | |||||
---|---|---|---|---|---|---|---|---|---|
|
2d 20h 36m | 1 | Fernando Lopez | 27/Mar/17 9:41 AM | |||||
|
3m 33s | 1 | Fermín Galán | 27/Mar/17 9:44 AM | |||||
|
22d 26m | 1 | Fermín Galán | 18/Apr/17 10:11 AM | |||||
|
2s | 1 | Fermín Galán | 18/Apr/17 10:11 AM | |||||
|
1s | 1 | Fermín Galán | 18/Apr/17 10:11 AM |
2017-03-24 12:05|CREATED monitor | # answers= 0, accepted answer= False