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).
Related
Recently some registrations of commands expired so I am trying to patch their "expires" attribute. However, I receive a 405 method not allowed message error.
Retrieving info about the registration:
curl -X GET \
http://localhost:1026/v2/registrations/5d3ff3e2ab1e270d7775a7bf \
-H 'Accept: application/json'
{
"id": "5d3ff3e2ab1e270d7775a7bf",
"expires": "2019-08-29T07:38:10.00Z",
"dataProvided": {
"entities": [
{
"id": "urn:ngsi-ld:ActuatorScreenshot:001",
"type": "Actuator"
}
],
"attrs": [
"Screen"
]
},
"provider": {
"http": {
"url": "http://localhost:4041"
},
"supportedForwardingMode": "all",
"legacyForwarding": true
},
"status": "active"
}
I attempted following the example from http://telefonicaid.github.io/fiware-orion/api/v2/stable/:
curl -X PATCH \
http://localhost:1026/v2/registrations/5d3ff3e2ab1e270d7775a7bf \
-d '{
"expires":"2040-10-04T00:00:00"
}'
But as I said I got the error message:
405 Method Not Allowed
Feel free to ask for more info.
The operation to modify registrations has not been yet implemented in Orion 2.2.0 (last version in the moment of writing this). As mentioned in Orion documentation:
Orion implements registration management as described in the NGSIv2
specification, except for the following aspects:
List item PATCH /v2/registration/<id> is not implemented. Thus, registrations cannot be updated directly. I.e., updates must be done
deleting and re-creating the registration. Please see this
issue about
this.
However, the workaround is pretty simple: delete the old registration and create a new one with the modified parameters.
I am using IOT-agent JSON with MQTT binding
I have a sensor-actuator registered in orion using iot-agent and I created the subscription.
If a third party application modifies a sensor value, orion must send iot-agent information and iot-agent to the device.
for example, if I have 3 attributes inside the sensor and one of them controls a valve.
In orion that attribute is true or false.
if the attribute is modified in orion must be sent to iot-agent and iot-agent to the device to close or open the valve.
extra information:
The software is two component of Fiware Generic Enable.
iot-agent JSON: https://github.com/telefonicaid/iotagent-json
Fiware-orionCB: https://github.com/telefonicaid/fiware-orion
Is it possible?
There is no official tutorial connecting the JSON IoT Agent to a device over MQTT, but a very similar one exists for the Ultralight IoT Agent
IoT Devices are either:
sensors - reading measurements from the real world
actuators - altering the state of the world
or both
Your issue here is that you cannot get Orion to update the attribute/state of a sensor directly. The attributes of the entity in the Context Broker represent the incoming state of the sensor - i.e. the measurements from that sensor.
For example for the sensor reading the state of a valve it could be "open: "true"
In order to update an actuator, you will need to send a command, rather than alter the value.
You should set up the command when provisioning the device (it is assumed you have a service already):
curl -iX POST \
'http://localhost:4041/iot/devices' \
-H 'Content-Type: application/json' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-d '{
"devices": [
{
"device_id": "bell001",
"entity_name": "urn:ngsi-ld:Bell:001",
"entity_type": "Bell",
"protocol": "PDI-IoTA-UltraLight",
"transport": "MQTT",
"commands": [
{ "name": "ring", "type": "command" }
],
"static_attributes": [
{"name":"refStore", "type": "Relationship","value": "urn:ngsi-ld:Store:001"}
]
}
]
}
'
You can then send the command to do something (like ring a bell, open a valve etc.) by altering the state of the command attribute.
curl -iX PATCH \
'http://localhost:1026/v2/entities/urn:ngsi-ld:Bell:001/attrs' \
-H 'Content-Type: application/json' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-d '{
"ring": {
"type" : "command",
"value" : ""
}
}'
Depending upon how you have provisioned devices, you may also need to register the command - though this may not be necessary.
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.
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.
So far I have configured ContextBroker to send data to Cygnus which in turn saves data by default names in database.
But what if I want to target a specific database with a specific table?
I know I have to set:
dbName=<fiware-service>
tableName=<fiware-servicePath>_<entityId>_<entityType>
I dont know where that file is, and I know it isnt in /etc/sysconfig/contextBroker because that folder doesnt exist.
EDIT1: here is my updatecontext:
(curl localhost:1026/NGSI10/updateContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: FiwareDatabase' --header 'Fiware-ServicePath: /AllSensors' -d #- ) <<EOF
{
"contextElements": [
{
"type": "Television",
"isPattern": "false",
"id": "TV2",
"attributes": [
{
"name": "channel",
"type": "integer",
"value": "14"
},
{
"name": "volume",
"type": "float",
"value": "9"
}
]
}
],
"updateAction": "APPEND"
}
EOF
As I said the table does get automatically created but the database doesnt.
Fiware-Service and Fiware-ServicePath are set at entity creation time using HTTP headers in the entity creation REST request. Please have a look to the following sections in the Orion User Manual:
Service
Service path
UPDATE: for example, in order to create an entity in service "servA" and service path "/path1" you could use the example shown in the create entity section in the manual adding two additionals HTTP headers to the curl line:
(curl localhost:1026/v1/updateContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: servA' --header 'Fiware-ServicePath: /path1' -d #- | python -mjson.tool) <<EOF
...
That would make to insert information in the following MySQL database/table (assuming that Cygnus is well configured, subscriptions are correct, etc.):
dbName=servA
tableName=path1_<entityId>_<entityType>
Note that the default behaviour is to store the information for each entity in a different table. That default behaviour can be changed, but if you are interested in that possibility, please create a new question in StackOverflow for dealing with that.