I'm working with an Orion context broker version 1.2.0. I have subscribed in it two different cygnus (0.11 and 0.13) using NGSIv2, as follows:
(curl 172.21.0.23:1026/v2/subscriptions -s -S --header 'Fiware-Service: prueba_015_adapter' --header 'Fiware-ServicePath: /Prueba/Planta_3' --header 'Content-Type: application/json' -d #- ) <<EOF
{
"description": "Cygnus subscription",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "density_algorithm"
}
],
"condition": {
"attrs": []
}
},
"notification": {
"http": {
"url": "http://172.21.0.33:5050/notify"
},
"attrs": []
}
}
EOF
But when the context broker sends a notification to any of these cygnus modules, the next error appears in the log:
15 jun 2016 12:46:48,641 INFO [1469152682#qtp-857344131-3153] (com.telefonica.iot.cygnus.handlers.OrionRestHandler.getEvents:150) - Starting transaction (1463998603-759-0001644173) 15 jun 2016 12:46:48,641 INFO [1469152682#qtp-857344131-3153] (com.telefonica.iot.cygnus.handlers.OrionRestHandler.getEvents:232) - Received data ({"subscriptionId":"57612ed9efa20b5b23e71bd5","data":[{"id":"C-A2","type":"density_algorithm","densityPlan":{"type":"string","value":"C-A2","metadata":{}},"devices":{"type":"string","value":"43","metadata":{}},"timestamp":{"type":"string","value":"2016-06-15T12:53:26.294+02:00","metadata":{}}}]}) 15 jun 2016 12:46:48,641 INFO [1469152682#qtp-857344131-3153] (com.telefonica.iot.cygnus.handlers.OrionRestHandler.getEvents:255) - Event put in the channel (id=957931298, ttl=-1) 15 jun 2016 12:46:48,642 WARN [1469152682#qtp-857344131-3153] (com.telefonica.iot.cygnus.interceptors.GroupingInterceptor.intercept:289)
- No context responses within the notified entity, nothing is done 15 jun 2016 12:46:48,642 WARN [1469152682#qtp-857344131-3153] (org.apache.flume.source.http.HTTPSource$FlumeHTTPServlet.doPost:203)
- Error appending event to channel. Channel might be full. Consider increasing the channel capacity or make sure the sinks perform faster. org.apache.flume.ChannelException: Unable to put batch on required channel: org.apache.flume.channel.MemoryChannel{name: mongo-channel}
at org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:200)
at org.apache.flume.source.http.HTTPSource$FlumeHTTPServlet.doPost(HTTPSource.java:201)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:814)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: java.lang.IllegalArgumentException: put() called with null event!
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:88)
at org.apache.flume.channel.BasicTransactionSemantics.put(BasicTransactionSemantics.java:89)
at org.apache.flume.channel.BasicChannelSemantics.put(BasicChannelSemantics.java:80)
at org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:189)
... 16 more
If I use NGSIv1 instead to register both subscriptions, everything goes fine: no log error is shown and the data is persisted into both cygnus modules.
(curl 172.21.0.23:1026/v1/subscribeContext -s -S --header 'Fiware-Service: prueba_015_adapter' --header 'Fiware-ServicePath: /Prueba/Planta_3' --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- ) <<EOF
{
"entities": [
{
"type": "density_algorithm",
"isPattern": "true",
"id": ".*"
}
],
"attributes": [],
"reference": "http://172.21.0.33:5050/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": []
}
]
}
EOF
I'm sending the entities to the context broker using NGSIv1. Can the problem be due to an incompatibility between NGSIv1 and NGSIv2?
Thanks in advance
For the time being, NGSIv2 notifications are not supported in Cygnus. It is expected to be implemented, but it has not been scheduled yet.
However, you can use attrFormat (inside nofitication field) equal to legacy to use NGSIv1 notification format (have a look to more detailed information here). NGSIv1 notification format is fully supported by Cygnus, so that should work.
Related
Working on setting Cygnus as a sink to CKAN, and I get this error, what part of Cygnus setup is responsible for this( subscription, configuration ...)
cygnus_1 | time=2018-10-01T12:40:04.517Z | lvl=DEBUG | corr=1ea858dc-c577-
11e8-b0fd-0242ac140003 | trans=5c553916-f5e6-4bbc-b98a-bcaba61a306c |
srv=waste4think | subsrv=/room/test | comp=cygnus-ngsi | op=getEvents |
msg=com.telefonica.iot.cygnus.handlers.NGSIRestHandler[320] :
[NGSIRestHandler] Parsed NotifyContextRequest:{"
subscriptionId":"5bb2153fd1bde90f8813b236","originator":"null","contextResponse
s":[]}
I assume the error is connected to this contextResponses because it is empty, but I found no additional info what is causing this where I should look. And the error is not helping.
This is the more general question that issue since I cannot call this issue because I have no idea if it is me who is causing this or Cygnus to have indeed some problems.
Thanks.
When setting up the subscription, Cygnus currently only accepts notifications in the older NGSI v1 format- the attrsFormat=legacy is therefore needed.
e.g.
curl -iX POST \
'http://localhost:1026/v2/subscriptions' \
-H 'Content-Type: application/json' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-d '{
"description": "Notify Cygnus of all context changes",
"subject": {
"entities": [
{
"idPattern": ".*"
}
]
},
"notification": {
"http": {
"url": "http://cygnus:5050/notify"
},
"attrsFormat": "legacy"
},
"throttling": 5
}'
Further information about setting up subscriptions in Cygnus can be found in the Cygnus Tutorial
I'm trying to send commands to the Orion Context Broker using iotagent-ul with HTTP protcol.
Context Broker and IoT Agent are in different servers (actually IoTA is in running in my laptop).
I've configured the necessary parameters in config.js file.
My request is as follows:
curl -L POST -H "Fiware-Service: myHome" -H "Fiware-ServicePath: /environment" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{
"devices": [
{
"device_id": "sensor01",
"entity_name": "LivingRoomSensor",
"entity_type": "multiSensor",
"attributes": [
{ "object_id": "t", "name": "Temperature", "type": "celsius" },
{ "object_id": "l", "name": "Luminosity", "type": "lumens" }
]
}
]
}
' 'http://localhost:4061/iot/devices'
It shows the following erros:
In IoTA terminal:
time=2017-02-14T15:06:14.832Z | lvl=ERROR | corr=88ed3729-6682-44ce-9b0a-28098e54c94e | trans=88ed3729-6682-44ce-9b0a-28098e54c94e | op=IoTAgentNGSI.DomainControl | srv=myHome | subsrv=/environment | msg=TypeError: Cannot read property 'findOne' of undefined | comp=IoTAgent
In "cURL terminal":
curl: (52) Empty reply from server
Please can you tell us what's the IoT Agent UL version you are using?
On the other hand, it seems you are missing the 'protocol' field in the payload, please check
http://fiwaretourguide.readthedocs.io/en/latest/connection-to-the-internet-of-things/how-to-read-measures-captured-from-iot-devices/
best
I'm working with Orion context Broker version 1.0.0. I have an active subscription constantly receiving notifications that should be redirected to a cygnus.
My concern is that last thursday this subscription did expire. Theorically, while a subscription keeps sending notifications to it's subscribers, the expiration date is updated. Then, anyone knows why that active subscription did expire?
That's how I do the subscription registrations:
(curl 172.21.0.33:1026/v1/subscribeContext -s -S --header 'Fiware-Service: xxxx' --header 'Fiware-ServicePath: /xxxx/xxxx' --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "tmp_reading",
"isPattern": "true",
"id": ".*"
}
],
"attributes": [],
"reference": "http://172.21.0.23:5050/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": []
}
]
}
EOF
One temporal solution seems to be to establish a very large duration period. Is that neccessary?
Theorically, while a subscription keeps sending notifications to it's subscribers, the expiration date is updated
That's not correct. On the contrary, a subscription is active as long as it hasn't reached its expiration date, which is calculated with current time + duration at subcription creation/updating time (in NGSIv1) or directly is the value of the expires field (in NGSIv2), no matter if notifications are being sent or not.
In addition, note that NGSIv2 allows to create permanent subscriptions (the ones created without specifying the expires field).
i have a shell script for santander:device or santander:traffic
(curl orion.lab.fi-ware.eu:1026/v1/queryContext?limit=1000 -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' --header "X-Auth-Token: $TOKEN" -d #- | python -mjson.tool) <<EOF {
"entities": [
{
"type": "**santander:device*",
"isPattern": "true",
"id": ".*"
}
],
"attributes": [
"TimeInstant"
]}
but
it returns no changes on attributes since 11 April for all santander:device or santander:traffic?Any idea?
best regards
philg
Context information flow from SmartSantander sensors to Orion global instance at FIWARE Lab has been interrupted due to maintenance reasons. We hope to restore it in the short term, maybe by next week (i.e. the week starting on May 2nd 16th) as much.
EDIT: it has been already restored.
I have installed cygnus 0.8.2 on fiware image CentOS-7-x64, I subscribed to orion context broker using:
(curl 193.48.247.246:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: egmmqtt' --header 'Fiware-ServicePath: /egmmqttpath' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "sensors",
"isPattern": "false",
"id": "sensors:switch2A"
}
],
"attributes": [
"switch2A"
],
"reference": "http://193.48.247.223:5050/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"switch2A"
]
}
],
"throttling": "PT1S"
}
EOF
No notification has reached cygnus and I got this error on orionContextBroker logs:
time=2015-10-06T17:43:37.898CEST | lvl=WARNING | trans=1443447780-161-00000000423 | function=sendHttpSocket | comp=Orion | msg=clientSocketHttp.cpp[358]: Notification failure for 193.48.247.223:5050 (curl_easy_perform failed: Couldn't connect to server)
I dont know why the cygnus instance is not reached under the associated public IP adress. In fact I can't ping cygnus machine instance from Orion instance. Any ideas of what I have missed? thanks!
In the security rules of cygnus instance the port on which cygnus is listenning (in my case 5050) has to be open so orion can reach cygnus instance.