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.
Related
I'm using IoT Agent with Ultralight run directly (not as a dockerized component). I'm able to register new device, which is mapped in Orion Context Broker. However I have an issue with registering Actuators which require commands within configuration data. I use:
curl -iX POST \
'http://MYIP:4061/iot/devices' \
-H 'Content-Type: application/json' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-d '{
"devices": [
{
"device_id": "lamp003",
"entity_name": "urn:ngsi-ld:Lamp:003",
"entity_type": "Lamp",
"protocol": "PDI-IoTA-UltraLight",
"transport": "MQTT",
"commands": [
{"name": "on","type": "command"},
{"name": "off","type": "command"}
]}
]
}
And in response I'm hit with:
op=IoTAgentNGSI.DeviceProvisioning | from=n/a | srv=n/a | subsrv=n/a |
msg=Device provisioning failed due to the following error: |
comp=IoTAgent Request error connecting to the Context Broker:
{"code":"400","reasonPhrase":"Bad Request","details":"missing isDomain
value for registration attribute"}
I tried adding "isDomain": "false" to elements of command table, but no luck. It used to work before and furthermore similar solution is presented on official guide.
isDomain part of the deprecated NGSI-v1 syntax. It is not used in NGSI-v2 or NGSI-LD
I think you may be running the IoT Agent as NGSI-v1. You'll need to set contextBroker.ngsiVersion in your config.js or set the following Env variable in Docker or Docker-compose.
IOTA_CB_NGSI_VERSION=v2
config.js
{
host: '192.168.56.101',
port: '1026',
ngsiVersion: 'v2'
}
I am new to Fiware and need help.
I want to configure a road side device (sensor) using CoAP protocol to the IDAS IoT agent (Lightweight M2M agent), so this device can send some data to IDAS.
How can I accomplish this task?
We are a company that works with LwM2M protocol through FIWARE technologies, may be our IoT FIWARE Dockerized infrastructure could help you.
https://gitlab.hopu.eu/software/FIWARE/fiware-docker-infrastructure
Reading your comments before, I understand that you want to build an scenario in order to connect your sensors to IotAgent-LWM2M.
In order to use LW2M2 IotAgent:
Install LW2M2 agent: git clone https://github.com/telefonicaid/lightweightm2m-iotagent.git
Install yarm to install all dependencies using npm packages
Install Lightweight M2M client: git clone https://github.com/telefonicaid/lwm2m-node-lib.git
Technical Requirements:
Mosquito MQTT v3.1 Broker
Orion latest
MongoDB v.3.2
NodeJS v0.12
I suggest you to use docker to install dependencies before comment
version : "2"
services:
mongo:
image: mongo:3.2
command: --nojournal
ports:
- "27017:27017"
expose:
- "27017"
orion:
image: fiware/orion
links:
- mongo
ports:
- "1026:1026"
command: -dbhost mongo
expose:
- "1026"
mosquitto:
image: ansi/mosquitto
ports:
- "1883:1883"
expose:
- "1883"
Note:
Mosquitto play a role like a sensor
Getting started: StepByStep
Step 1 : Create a device
(curl localhost:4041/iot/devices -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' --header 'fiware-service: Factory' --header 'fiware-servicepath: /robots' \
-d #- | python -mjson.tool) <<EOF
{
"devices": [
{
"device_id": "robot1",
"entity_type": "Robot",
"attributes": [
{
"name": "Battery",
"type": "number"
}
],
"lazy": [
{
"name": "Message",
"type": "string"
}
],
"commands": [
{
"name": "Position",
"type": "location"
}
],
"internal_attributes": {
"lwm2mResourceMapping": {
"Battery" : {
"objectType": 7392,
"objectInstance": 0,
"objectResource": 1
},
"Message" : {
"objectType": 7392,
"objectInstance": 0,
"objectResource": 2
},
"Position" : {
"objectType": 7392,
"objectInstance": 0,
"objectResource": 3
}
}
}
}]}
EOF
Step 2 : Create a service
curl -X POST -H "Fiware-Service: myHome" -H "Fiware-ServicePath: /environment" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{
"services": [
{
"resource": "/",
"apikey": "",
"type": "Robot",
"cbroker":"localhost:1026"
}]
}' 'http://localhost:4041/iot/services'
Step 3: connect your sensor to the client
(bin/iotagent-lwm2m-client.js)
Object Creation:
LWM2M-Client> create /7392/0
Battery attribute:
LWM2M-Client> set /7392/0 1 89
Message Attribute:
LWM2M-Client> set /7392/0 2 "First robot here"
Position attribute:
LWM2M-Client> set /7392/0 3 "[0,0]
Step 4: connect with the server
LWM2M-Client> connect localhost 5684 robot1 /
Step 5: Update attributes
set /7392/0 1 67
Step 6: Query to Orion to see updated attributes
curl -X POST http://localhost:1026/v1/queryContext -s -S
--header 'Content-Type: application/json' \
--header 'Accept: application/json' --header 'fiware-service: Factory'
--header 'fiware-servicepath: /robots' \
-d '
{
"entities": [
{
"type": "Robot",
"isPattern": "false",
"id": "Robot:robot1"
}
]
}
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 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.