Client - Agent Information Reporting Error: "DEVICE_GROUP_NOT_FOUND" - mongodb

It appears that IoT-Agent isn't receiving measures, Agent's log says device group not found [MONGO-ALARM]. Does anyone understand what this error means or how to fix it?
Agent's log:
time=2018-12-10T16:48:24.824Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.COAPRouter | msg=Handling request with method [POST] on url [/rd/1] with messageId [24748]
time=2018-12-10T16:48:24.826Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.UpdateRegistration | msg=Handling update registration request
time=2018-12-10T16:48:24.826Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.COAPUtils | msg=Extracting query parameters from request
time=2018-12-10T16:48:24.827Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.UpdateRegistration | msg=Updating device register with lifetime [undefined] and address [193.136.33.222].
{"op":"IOTAgent.LWM2MHandlers","time":"2018-12-10T16:48:24.827Z","lvl":"DEBUG","msg":"Handling update registration of the device"}
time=2018-12-10T16:48:24.829Z | lvl=DEBUG | corr=54b6621d-65fd-43db-ac9b-fade34e4d947 | trans=54b6621d-65fd-43db-ac9b-fade34e4d947 | op=IoTAgentNGSI.MongoDBGroupRegister | srv=n/a | subsrv=n/a | msg=Looking for group params ["resource","apikey"] with queryObj {} | comp=IoTAgent
time=2018-12-10T16:48:24.835Z | lvl=DEBUG | corr=54b6621d-65fd-43db-ac9b-fade34e4d947 | trans=54b6621d-65fd-43db-ac9b-fade34e4d947 | op=IoTAgentNGSI.MongoDBGroupRegister | srv=n/a | subsrv=n/a | msg=Device group for fields [["resource","apikey"]] not found: [{}] | comp=IoTAgent
**time=2018-12-10T16:48:24.836Z | lvl=ERROR | corr=54b6621d-65fd-43db-ac9b-fade34e4d947 | trans=54b6621d-65fd-43db-ac9b-fade34e4d947 | op=IoTAgentNGSI.Alarms | srv=n/a | subsrv=n/a | msg=Raising [MONGO-ALARM]: {"name":"DEVICE_GROUP_NOT_FOUND","message":"Couldn\t find device group","code":404} | comp=IoTAgent**
time=2018-12-10T16:48:24.836Z | lvl=DEBUG | corr=54b6621d-65fd-43db-ac9b-fade34e4d947 | trans=54b6621d-65fd-43db-ac9b-fade34e4d947 | op=IoTAgentNGSI.MongoDBDeviceRegister | srv=n/a | subsrv=n/a | msg=Looking for device with id [raspiSensorTV]. | comp=IoTAgent
time=2018-12-10T16:48:24.843Z | lvl=ERROR | corr=54b6621d-65fd-43db-ac9b-fade34e4d947 | trans=54b6621d-65fd-43db-ac9b-fade34e4d947 | op=IoTAgentNGSI.Alarms | srv=n/a | subsrv=n/a | msg=Releasing [MONGO-ALARM] | comp=IoTAgent
{"op":"IOTAgent.LWM2MHandlers","time":"2018-12-10T16:48:24.843Z","lvl":"DEBUG","msg":"Preregistered device found."}
time=2018-12-10T16:48:24.844Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.UpdateRegistration | msg=Update registration request ended successfully
{"time":"2018-12-10T16:48:24.894Z","lvl":"DEBUG","msg":"Observers created successfully."}
The log above appears everytime the device signals to have sent a measure, but my query for provisioned devices returns empty list:
curl -X GET \
'http://localhost:4041/iot/devices' \
-H 'fiware-service: smartGondor' \
-H 'fiware-servicepath: /gardens'
{"count":0,"devices":[]}
Any idea please?

Your request is showing that no devices have been successfully provisioned yet.
It is likely that you have either not provisioned a service group for your IoT Agent or not provisioned the device itself. If a measurement is received before a service group has been provisioned then the IoT Agent will not know how devices identify themselves or where to persist the measurements.
You can provision a service group in multiple ways, but one method would be as follows:
curl -iX POST \
'http://iot-agent:4041/iot/services' \
-H 'Content-Type: application/json' \
-H 'fiware-service: <xxxxxxx>' \
-H 'fiware-servicepath: <yyyyy>' \
-d '{
"services": [
{
"apikey": "<api-key>",
"cbroker": "http://orion:1026",
"entity_type": "Thing",
...etc
}
]
}'
Thereafter any unknown device responding with the correct <api-key> will create an entity called Thing.
Of course if you want to be more specific you can provision the device as shown:
curl -iX POST \
'http://iot-agent:4041/iot/devices' \
-H 'Content-Type: application/json' \
-H 'fiware-service: <xxxxxxx>' \
-H 'fiware-servicepath: <yyyyy>' \
-d '{
"devices": [
{
"device_id": "motion001",
"entity_name": "urn:ngsd-ld:Motion:001",
"entity_type": "Motion",
"attributes": [
{ "object_id": "c", "name": "count", "type": "Integer" }
],
}
]
}
'
This ensures that a device identifying as motion001 will be stored as a Motion entity and various mappings will take place.

Related

How to pass "network_name" in gcloud sql instances patch command

cant add name of the authorized network whie using gcloud sql patch command
stage("Editing Authorized Networks of ${instance_name} CloudSQL") {
steps {
sh "gcloud sql instances patch ${instance_name} --authorized-networks ${network_name}=${ip_range}"
}
}
tried this
gcloud sql instances patch instanceid --authorized-networks Rajeev-Home=0.0.0.0/0
getting this
ERROR: (gcloud.sql.instances.patch) argument --authorized-networks: Bad value [Rajeev-Home=0.0.0.0/0]: Must be specified in CIDR notation, also known as 'slash' notation (e.g. 192.168.100.0/24).
Usage: gcloud sql instances patch INSTANCE [optional flags]
optional flags may be --activation-policy | --active-directory-domain |
--assign-ip | --async | --audit-bucket-path |
--audit-retention-interval | --audit-upload-interval |
--authorized-gae-apps | --authorized-networks |
--availability-type | --no-backup | --backup-location |
--backup-start-time | --clear-authorized-networks |
--clear-database-flags | --clear-gae-apps |
--clear-password-policy | --connector-enforcement |
--cpu | --database-flags | --database-version |
--deletion-protection |
--deny-maintenance-period-end-date |
--deny-maintenance-period-start-date |
--deny-maintenance-period-time | --diff |
--enable-bin-log | --enable-database-replication |
--enable-google-private-path |
--enable-password-policy |
--enable-point-in-time-recovery | --follow-gae-app |
--gce-zone | --help |
--insights-config-query-insights-enabled |
--insights-config-query-plans-per-minute |
--insights-config-query-string-length |
--insights-config-record-application-tags |
--insights-config-record-client-address |
--maintenance-release-channel | --maintenance-version |
--maintenance-window-any | --maintenance-window-day |
--maintenance-window-hour | --memory | --network |
--password-policy-complexity |
--password-policy-disallow-username-substring |
--password-policy-min-length |
--password-policy-password-change-interval |
--password-policy-reuse-interval | --pricing-plan |
--remove-deny-maintenance-period | --replication |
--require-ssl | --retained-backups-count |
--retained-transaction-log-days | --secondary-zone |
--storage-auto-increase | --storage-size | --tier |
--zone

FIWARE orion with atlas mongodb

Hello I'm trying to launch the FIWARE orion context broker using an atlas mongodb
mongodb+srv://<user>:****************#<domainid>.mongodb.net/<aut_db>
I have tried multiple variations of the docker run command but I never get the connection to success
trace:
$ docker run --name orion -p 1027:1026 fiware/orion:latest -dbhost "<domainid>.mongodb.net/<aut_db>?ssl=true&retryWrites=true&w=majority" -dbuser <user> -dbpwd U9NjLafksdv9mavW -logLevel DEBUG
time=2021-12-01T14:38:42.188Z | lvl=INFO | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=contextBroker.cpp[1063]:main | msg=start command line </usr/bin/contextBroker -fg -multiservice -ngsiv1Autocast -disableFileLog -dbhost <domainid>.mongodb.net/<aut_db>?ssl=true&retryWrites=true&w=majority -dbuser <user> -dbpwd ****** -logLevel DEBUG>
time=2021-12-01T14:38:42.188Z | lvl=INFO | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=contextBroker.cpp[1137]:main | msg=Orion Context Broker is running
time=2021-12-01T14:40:23.011Z | lvl=ERROR | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=mongoConnectionPool.cpp[220]:mongoConnect | msg=Database Startup Error (cannot connect to mongo - doing 100 retries with a 1000 millisecond interval)
time=2021-12-01T14:40:23.011Z | lvl=FATAL | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=MongoGlobal.cpp[142]:mongoInit | msg=Fatal Error (MongoDB error)
time=2021-12-01T14:40:23.012Z | lvl=INFO | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=contextBroker.cpp[591]:exitFunc | msg=Orion shutdown completed
Has someone know how I can configure orion context broker to connect to an mongo atlas?
EDIT: I have checked and I have access from that server to the mongo-db with the mongo shell
Orion currently supports only mongodb:// connection strings, built from the -db, -dbhost, -rplSet, -dbTimeout, -dbuser, -dbpwd, -dbAuthMech, -dbAuthDb, -dbSSL and -dbDisableRetryWrites CLI parameters(or default values, if omitted) as can be see in the source code.
There is an issue in the Orion repository with the aim of making this more flexible, allowing to provide the connection string directly overriding the above parameters.
While that issue comes (contributions welcome ;) you could hack the Orion source code cited above to build an specific version for you with support for mongo+srv:// connection strings.

IBM Watson Discovery - How to list uploaded documents?

I'm trying to get the ID-s of all documents uploaded to IBM Watson Discovery API
It's not obvious from the documentation, but I guess it must be possible?
The structure is:
+--------------------------------------------------+
| Environment |
| |
| +--------------------------------+ |
| | Collection | |
| | | |
| | +--------------+ | |
| | | Document | | |
| | | | | |
| | +--------------+ | |
| | | |
| +--------------------------------+ |
| |
+--------------------------------------------------+
How can I get a list of all documents in a collection?
.
I have tried:
Collections -> List collection fields
curl -u "apikey":"{apikey}" "{url}/v1/environments/{environment_id}/collections/{collection_id}/fields?version=2019-04-30"
Queries -> Query a collection (GET)
curl -u "apikey":"{apikey}" "{url}/v1/environments/{environment_id}/collections/{collection_id}/query?version=2019-04-30"
Environments -> Get environment info
curl -u "apikey":"{apikey}" "{url}/v1/environments/{environment_id}?version=2019-04-30"
Training data -> List training data
curl -u "apikey":"{apikey}" "{url}/v1/environments/{environment_id}/collections/{collection_id}/training_data?version=2019-04-30"
None of these give the list of documents.
.
UPDATE:
Thanks to #Catbelly's answer, the correct way to get a list of documents is:
curl -u "apikey":"{apikey}" "{url}/v1/environments/{environment_id}/collections/{collection_id}/query?version=2019-04-30&return=id
The Query endpoint is the only way to do this - if you set the return value equal to id you will only get ids back. (I am a IBM Watson employee)

Table-Table Join duplicate entries

we are using kafka in production and I try to push the adoption and usage of KSQL in the same direction. But I already failed with one simple table-table join. I’ve tried with our production data first and ran in an issue. So I thought I missed something and moved back to the example from the confluent docs and ran in the same problem.
I will explain my issue with the example data https://docs.confluent.io/current/ksql/docs/tutorials/basics-docker.html#table-table-join
When I have created both tables and try to join the data it works, but as soon as I try to alter or add something I get new entries in my table. From every example I found at confluent or even at the youtube videos this is not suppose to happen.
Creating records
docker run --interactive --rm --network tutorials_default \
confluentinc/cp-kafkacat \
kafkacat -b kafka:39092 \
-t warehouse_location \
-K: \
-P <<EOF
1:{"warehouse_id":1,"city":"Leeds","country":"UK"}
2:{"warehouse_id":2,"city":"Sheffield","country":"UK"}
3:{"warehouse_id":3,"city":"Berlin","country":"Germany"}
EOF
docker run --interactive --rm --network tutorials_default \
confluentinc/cp-kafkacat \
kafkacat -b kafka:39092 \
-t warehouse_size \
-K: \
-P <<EOF
1:{"warehouse_id":1,"square_footage":16000}
2:{"warehouse_id":2,"square_footage":42000}
3:{"warehouse_id":3,"square_footage":94000}
EOF
Creating tables
CREATE TABLE WAREHOUSE_LOCATION (WAREHOUSE_ID INT, CITY VARCHAR, COUNTRY VARCHAR)
WITH (KAFKA_TOPIC='warehouse_location',
VALUE_FORMAT='JSON',
KEY='WAREHOUSE_ID');
CREATE TABLE WAREHOUSE_SIZE (WAREHOUSE_ID INT, SQUARE_FOOTAGE DOUBLE)
WITH (KAFKA_TOPIC='warehouse_size',
VALUE_FORMAT='JSON',
KEY='WAREHOUSE_ID');
Creating a joined table:
CREATE TABLE WH_U AS SELECT WL.WAREHOUSE_ID, WL.CITY, WL.COUNTRY, WS.SQUARE_FOOTAGE
FROM WAREHOUSE_LOCATION WL
LEFT JOIN WAREHOUSE_SIZE WS
ON WL.WAREHOUSE_ID=WS.WAREHOUSE_ID;
With this I get the expected results:
1 | Leeds | UK | 16000.0
2 | Sheffield | UK | 42000.0
3 | Berlin | Germany | 94000.0
But when I add or chnage records, this happens:
1566375174496 | 1 | 1 | Leeds | UK | 16000.0
1566375174496 | 2 | 2 | Sheffield | UK | 42000.0
1566375174496 | 3 | 3 | Berlin | Germany | 94000.0
1566375595372 | 4 | 4 | London | UK | null
1566375641291 | 4 | 4 | London | UK | 94000.0
1566375641291 | 1 | 1 | Leeds | UK | 1.0
I expected:
1566375174496 | 1 | 1 | Leeds | UK | 1.0
1566375174496 | 2 | 2 | Sheffield | UK | 42000.0
1566375174496 | 3 | 3 | Berlin | Germany | 94000.0
1566375641291 | 4 | 4 | London | UK | 94000.0
What am I missing?
SOLVED
The reason for this behaviour was a simple env in ksql server. KSQL_CACHE_MAX_BYTES_BUFFERING was set to 0

Orion failing to receive context notification from IoTAgent: response NOT OK

Having a little difficulty understanding what is going wrong with IoTAgent-Orion subscription to publish context information to Orion. Orion service health check OK, but failed to recieve context with response NOT OK code 404. Orion log:
time=Thursday 28 Feb 14:25:57 2019.783Z | lvl=INFO | corr=c3b64466-3b64-11e9-b463-0242ac1d0005 | trans=1551363484-821-00000000032 | from=172.29.0.6 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=logMsg.h[1844]:lmTransactionStart | msg=Starting transaction to http://lightweightm2m-iotagent:4041/publish
time=Thursday 28 Feb 14:25:57 2019.783Z | lvl=INFO | corr=c3b64466-3b64-11e9-b463-0242ac1d0005 | trans=1551363484-821-00000000032 | from=172.29.0.6 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=httpRequestSend.cpp[592]:httpRequestSendWithCurl | msg=Sending message 3 to HTTP server: sending message of 576 bytes to HTTP server
time=Thursday 28 Feb 14:25:57 2019.791Z | lvl=INFO | corr=c3b64466-3b64-11e9-b463-0242ac1d0005 | trans=1551363484-821-00000000032 | from=172.29.0.6 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=httpRequestSend.cpp[612]:httpRequestSendWithCurl | msg=Notification Successfully Sent to http://lightweightm2m-iotagent:4041/publish
time=Thursday 28 Feb 14:25:57 2019.791Z | lvl=WARN | corr=c3b64466-3b64-11e9-b463-0242ac1d0005 | trans=1551363484-821-00000000032 | from=172.29.0.6 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=httpRequestSend.cpp[625]:httpRequestSendWithCurl | msg=Notification response NOT OK, http code: 404
EDIT:
I edited my question again to reproduce the scenario generating the error. Below is the agent log:
time=2019-02-28T15:15:53.810Z | lvl=DEBUG | corr=bd797a30-3b6b-11e9-98a6-0242c0a85005 | trans=b725da6c-8917-4dde-9d29-defa97970b1a | op=IoTAgentNGSI.DomainControl | srv=smartgondor | subsrv=/gardens | msg=response-time: 8 | comp=IoTAgent
time=2019-02-28T15:16:00.398Z | lvl=DEBUG | corr=05d60d9d-dd2e-4d0e-b80f-ad1c384431d7 | trans=05d60d9d-dd2e-4d0e-b80f-ad1c384431d7 | op=IoTAgentNGSI.GenericMiddlewares | srv=n/a | subsrv=n/a | msg=Request for path [/iot/about] from [localhost:4041] | comp=IoTAgent
time=2019-02-28T15:16:00.399Z | lvl=DEBUG | corr=05d60d9d-dd2e-4d0e-b80f-ad1c384431d7 | trans=05d60d9d-dd2e-4d0e-b80f-ad1c384431d7 | op=IoTAgentNGSI.DomainControl | srv=n/a | subsrv=n/a | msg=response-time: 1 | comp=IoTAgent
time=2019-02-28T15:16:13.255Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=LWM2MLib.InformationReporting | srv=n/a | subsrv=n/a | msg=New data on resource /3303/0/5700 in device [1] | comp=IoTAgent
time=2019-02-28T15:16:13.255Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IOTAgent.LWM2MHandlers | srv=n/a | subsrv=n/a | msg=Handling data from device [raspiSensorTV] | comp=IoTAgent
.
.
time=2019-02-28T15:16:13.256Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IoTAgentNGSI.MongoDBGroupRegister | srv=n/a | subsrv=n/a | msg=Looking for group params ["type"] with queryObj {"type":"Device"} | comp=IoTAgent
time=2019-02-28T15:16:13.260Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IoTAgentNGSI.MongoDBGroupRegister | srv=n/a | subsrv=n/a | msg=Device group for fields [["type"]] not found: [{"type":"Device"}] | comp=IoTAgent
time=2019-02-28T15:16:13.260Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IoTAgentNGSI.NGSIService | srv=n/a | subsrv=n/a | msg=error {"name":"DEVICE_GROUP_NOT_FOUND","message":"Couldn\t find device group","code":404} in get group device | comp=IoTAgent
.
.
time=2019-02-28T15:16:13.261Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IoTAgentNGSI.NGSIService | srv=n/a | subsrv=n/a | msg=Updating device value in the Context Broker at [http://orion:1026/v1/updateContext] | comp=IoTAgent
time=2019-02-28T15:16:13.261Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IoTAgentNGSI.NGSIService | srv=n/a | subsrv=n/a | msg=Using the following request:
{
"url": "http://orion:1026/v1/updateContext",
"method": "POST",
"headers": {
"fiware-service": "smartGondor",
"fiware-servicepath": "/gardens"
},
"json": {
"contextElements": [
{
"type": "Device",
"isPattern": "false",
"id": "Device:raspiSensorTV",
"attributes": [
{
"name": "Temperature Sensor#0",
"type": "string",
"value": "�\u0016DA�\u0000\u0000",
"metadatas": [
{
"name": "TimeInstant",
"type": "ISO8601",
"value": "2019-02-28T15:16:13.261Z"
}
]
},
{
"name": "TimeInstant",
"type": "ISO8601",
"value": "2019-02-28T15:16:13.261Z"
}
]
}
],
"updateAction": "UPDATE"
}
}
| comp=IoTAgent
time=2019-02-28T15:16:13.274Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IoTAgentNGSI.NGSIService | srv=n/a | subsrv=n/a | msg=Received the following request from the CB:
{
"contextResponses": [
{
"contextElement": {
"type": "Device",
"isPattern": "false",
"id": "Device:raspiSensorTV",
"attributes": [
{
"name": "Temperature Sensor#0",
"type": "string",
"value": "",
"metadatas": [
{
"name": "TimeInstant",
"type": "ISO8601",
"value": "2019-02-28T15:16:13.261Z"
}
]
},
{
"name": "TimeInstant",
"type": "ISO8601",
"value": ""
}
]
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
| comp=IoTAgent
time=2019-02-28T15:16:13.274Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IoTAgentNGSI.NGSIService | srv=n/a | subsrv=n/a | msg=Value updated successfully | comp=IoTAgent
time=2019-02-28T15:16:13.274Z | lvl=DEBUG | corr=e4633c8b-1db7-4207-b307-3e419f78223f | trans=e4633c8b-1db7-4207-b307-3e419f78223f | op=IOTAgent.LWM2MHandlers | srv=n/a | subsrv=n/a | msg=Data handled successfully | comp=IoTAgent
time=2019-02-28T15:16:13.282Z | lvl=DEBUG | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=e822ce3a-f639-4257-8179-a40804eb1ba7 | op=IoTAgentNGSI.GenericMiddlewares | srv=smartgondor | subsrv=/gardens | msg=Request for path [/publish] from [lightweightm2m-iotagent:4041] | comp=IoTAgent
time=2019-02-28T15:16:13.282Z | lvl=DEBUG | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=e822ce3a-f639-4257-8179-a40804eb1ba7 | op=IoTAgentNGSI.GenericMiddlewares | srv=smartgondor | subsrv=/gardens | msg=Body:
{
"subscriptionId": "5c77fb29a23ec2205a00b013",
"data": [
{
"id": "Device:raspiSensorTV",
"type": "Device",
"Temperature Sensor#0": {
"type": "string",
"value": "�\u0016DA�\u0000\u0000",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2019-02-28T15:16:13.261Z"
}
}
}
}
]
}
| comp=IoTAgent
time=2019-02-28T15:16:13.283Z | lvl=DEBUG | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=e822ce3a-f639-4257-8179-a40804eb1ba7 | op=IoTAgentNGSI.DomainControl | srv=smartgondor | subsrv=/gardens | msg=response-time: 4 | comp=IoTAgent
This scenario was reported in the agent log, while orion log shows the following:
time=Thursday 28 Feb 15:16:13 2019.269Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000018 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=logMsg.h[1844]:lmTransactionStart | msg=Starting transaction from 192.168.80.4:52068/v1/updateContext
time=Thursday 28 Feb 15:16:13 2019.269Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000018 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=rest.cpp[885]:servicePathSplit | msg=Service Path 0: '/gardens'
time=Thursday 28 Feb 15:16:13 2019.271Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000018 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=connectionOperations.cpp[94]:collectionQuery | msg=Database Operation Successful (query: { _id.id: "Device:raspiSensorTV", _id.type: "Device", _id.servicePath: { $in: [ /^/gardens$/ ] } })
time=Thursday 28 Feb 15:16:13 2019.272Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000018 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=connectionOperations.cpp[449]:collectionUpdate | msg=Database Operation Successful (update: <{ _id.id: "Device:raspiSensorTV", _id.type: "Device", _id.servicePath: { $in: [ /^/gardens$/ ] } }, { $set: { attrs.Temperature Sensor#0: { value: "�DA�>)
time=Thursday 28 Feb 15:16:13 2019.273Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000019 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=logMsg.h[1844]:lmTransactionStart | msg=Starting transaction to http://lightweightm2m-iotagent:4041/publish
time=Thursday 28 Feb 15:16:13 2019.273Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000018 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=logMsg.h[1874]:lmTransactionEnd | msg=Transaction ended
time=Thursday 28 Feb 15:16:13 2019.274Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000019 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=httpRequestSend.cpp[592]:httpRequestSendWithCurl | msg=Sending message 2 to HTTP server: sending message of 573 bytes to HTTP server
time=Thursday 28 Feb 15:16:13 2019.284Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000019 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=httpRequestSend.cpp[612]:httpRequestSendWithCurl | msg=Notification Successfully Sent to http://lightweightm2m-iotagent:4041/publish
time=Thursday 28 Feb 15:16:13 2019.284Z | lvl=WARN | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000019 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=httpRequestSend.cpp[625]:httpRequestSendWithCurl | msg=Notification response NOT OK, http code: 404
time=Thursday 28 Feb 15:16:13 2019.285Z | lvl=INFO | corr=c915945a-3b6b-11e9-b854-0242c0a85005 | trans=1551366811-541-00000000019 | from=192.168.80.4 | srv=smartgondor | subsrv=/gardens | comp=Orion | op=logMsg.h[1874]:lmTransactionEnd | msg=Transaction ended
I commit the following IoTAgent-Orion subscrption request:
$curl -iX POST localhost:1026/v2/subscriptions -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' --header 'fiware-service: smartGondor' --header 'fiware-servicepath: /gardens' -d'
{
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Device"
}
],
"condition": {
"attrs": [ "Temperature Sensor#0" ]
}
},
"notification": {
"http": {
"url": "http://lightweightm2m-iotagent:4041/publish"
},
"attrs": [ "Temperature Sensor#0" ]
}
}'
Luckily, it is now working despite this error still appearing. At least it is working, nothing to worry.