I have set my weather station with different sensors attached. My practice until now was to send the sensor data to a web address. But now that I have set up a CentOS 6.6 on a server with its IP address so now I want to send the sensor data directly to that machine that has orion context broker installed.
So my question is, how do I configure orion context broker to accept these post requests (from the weather station sensors) that are being sent to the CentOS machine?
You shouldn't have any problem sending post requests to a CentOS machine that is running Orion Context Broker. In fact, that is the supported OS for running Orion.
Just make sure you have the port open that Orion will be listening at (by default it's 1026), and that the payload in the post is acceptable.
For example, to send a value you could do a POST to <host>:<port>/v1/contextEntities/mySensor/attributes and a payload such as
{
"attributes" : [
{
"name" : "temperature",
"type" : "float",
"value" : "26.5"
},
{
"name" : "pressure",
"type" : "integer",
"value" : "763"
}
]
}
Start out simple by doing a GET :1026/version to see if it works and work up to more advanced queries (see the documentation for more good stuff :)
Related
I am a student working on a project and exploring viability of using fiware for that. So far I've learnt that to call external APIs we can use registrations for an entity to fetch dynamic data.
Here is the situation:
In my project, I am calling external APIs for fetching some data at frontend.
I want to add access control for users so that they are restricted from calling the APIs if not permitted. For this reason I am trying to find out a way such that keyrock can validate the requests so that I don't have to manually validate these external APIs. Since these aren't related to any entity I don't want to use registration for this purpose.
I intend to do user management through keyrock itself. Currently keyrock can restrict based on resources (i.e. URL path) of the application and permission. I am very confused at this point that if I add an API call at any page to fetch data from external API, how can I make use of keyrock access control in this situation.
Also, can I make orion call the external API somehow and make the data an entity?
Any help and hint is greatly appreciated. Thanks in Advance.
A registration is a contract to return a series of attributes connected to an entity, how that is connected to an external API is up to you. There is an annotated example in the NGSI v2 tutorials - the code is also available for NGSI-LD but the documentation for NGSI-LD needs updating to reflect certain recent changes and clarifications made in NGSI-LD 1.6.1.
Regardless of the version of NGSI you use, the steps to call an external API are the same.
Create a proxy service with a handler to deal with one or more NGSI endpoints - for NGSI-v2 this will usually be the batch endpoint /op/query, for NGSI-LD I would recommend /ngsi-ld/v1/entities/<id>.
Create a registration from your context broker to this proxy e.g. for NGSI-v2:
curl -iX POST \
'http://localhost:1026/v2/registrations' \
-H 'Content-Type: application/json' \
-d '{
"description": "Random Weather Conditions",
"dataProvided": {
"entities": [
{
"id": "urn:ngsi-ld:Store:001",
"type": "Store"
}
],
"attrs": [
"relativeHumidity"
]
},
"provider": {
"http": {
"url": "http://location/of/the/proxy/interface"
}
}
}'
Note that you can also pass additional custom information using custom headers or annotating the path of the URL or whatever.
Within the proxy code make a request to the third party API and convert the response back to NGSI format. The tutorial example explains how to connect to Twitter or Cat Facts as examples.
I want to add access control for users so that they are restricted from calling the APIs if not permitted.
This is purely a matter of placing a PEP proxy in front of the call to the registrant. Imagine a context broker request like this one to Kong:
curl -X GET \
http://localhost:8000/orion/v2/entities/urn:ngsi-ld:Store:001?options=keyValues \
-H 'Authorization: Bearer {{X-Access-token}}'
Either you place the PEP in front of the context broker (in which case the entity is only returned if you have appropriate permissions, or you place a PEP in front of your registrant webservice, in which case the attributes are only appended to the entity if you have appropriate permissions. Note that the context broker Registration needs to be configured to ensure that the Authorization header will be passed on to the registrant as well.
I'm migrating from Firebase where this was rather simple to do.
I'm building a custom api because the environment I need to build in will not let me use any official sdk's or anything, so this solely has to be done via rest type actions.
I essentially want to just post the username/password to aws cognito, and recieve an auth token that I can then append to the headers of future requests (to other api calls)
After hunting for quite a bit, almost all help has postman connecting to Amazon's login UI etc, and I cannot do that. It must completely handle the login process "behind the scenes" and not prompt the user with Amazon's own UI.
So, assuming this is possible:
What headers do I need (content-type etc)
How do I format the body json (or is it using something else?)
I assume I'd send it as "raw" body.
This is as far as I got so far and I'm scratching my head:
Url: https://[DOMAIN].auth.us-east-1.amazoncognito.com/oauth2/token
Body Json:
{
"ClientId": "1234etc",
"Password": "Password1_",
"UserAttributes": [
{
"Name": "email",
"Value": "test#test.com"
}
],
"Username": "test#test.com"
}
No idea if this is even the right format for the JSON I just scalped it from other posts.
We would like to add an IoT device which uses specific API calls / responses, and we would like to know the best way to do it. Can we do this integration using the FIWARE JSON IoT Agent? We have to develop a custom FIWARE IoT Agent?
If you have a JSON payload (or you can create one) then the JSON IoT Agent is a good baseline to start from. There are two basic approaches:
Gateway Solution
Custom IoT Agent
In the first approach you could create a separate gateway component which listens to your API and it reads and interprets measures and posts back onto an MQTT topic /attrs. For commands, the gateway receives a JSON payload on /cmdExe MQTT topic and sends it on using your API. Your gateway would be responsible for marshalling/unmarshalling payloads.
In the second approach, you are writing your own IoT Agent. Effectively you are responsible for creating your own binding mapping to your API.
The advantage of the Gateway Solution is that you can continue to upgrade using the standard IoT Agent, so you will get bug fixes for free. The custom IoT Agent may be cleaner architecturally - you don't (ab)use MQTT as a message bus - but keeping the custom IoT Agent updated becomes your responsibility.
In general, I would recommend that a custom IoT Agent is used whenever the protocol is in wide enough use that multiple end-users and developers could benefit from it. Custom IoT Agents can also be developed if there are a large number of extra dependencies involved. Most IoT Agents are developed in Node.js
For a single proprietary API, gateway is probably better. If you look at the accompanying video, you'll see that in the IOTA case, both the payload and the transport are customised. A Gateway could be developed in any code language (provided it has an MQTT client available.)
Thank you #jason-fox. We have just finished the development of our custom gateway and we're trying to test it. We've just created the service group into the IoT JSON Agent:
"services": [
{
"apikey": "our-api-key",
"protocol": [
"IoTA-JSON"
],
"cbroker": "url-context-broker:1026",
"entity_type": "Device",
"resource": "/iot/shelly/json"
}
]
And provisioning the device:
"devices": [
{
"device_id": "shelly003",
"entity_name": "shelly-xxxx",
"entity_type": "Device",
"protocol": "IoTA-JSON",
"transport": "HTTP",
"endpoint": "gateway-url",
"commands": [
{
"name": "turn",
"type": "command"
}
]
}
]
We're trying to send command to the device via Context Broker sending the following body to the endpoint:
"turn": {
"type" : "command",
"value" : "on"
}
But we're getting always error. What are we doing wrong?
Would appreciate any tips/help.
I have a security system that uses a controller and a video monitoring software, both of which are connected to a LAN (direct ethernet from controller to a POE switch and monitoring software also on same network).
The problem I have is that the security controller can't push strings to an IP address, which is what is required with the video monitoring software.
I need to create a separate device that requests data from the security controller's IP and then takes what the IP address returns (a JSON object) and converts it into a string to send to the video monitoring software's IP address.
Example of the device I need to create:
The device needs to request data from controller 192.168.1.9 address:
http://192.168.1.9/inputs/0.cgi
This will return a JSON object:
{
"description": "Sensor 1",
"type": "NO",
"alarm": false
}
(If the alarm is triggered, "alarm" will be true.)
Then I need to take that JSON object, and convert it into a string (.stringify?)
Then I have to take that string and send it to my video monitoring software's address:
“http:///monitor-mobile/write.fcgi?serverId=1&pin=4&status=1”
This seems uniquely complicated and simple at the same time and I apologize if I left out any information required to solve my problem. Basically, I am wondering if there is a device that I can connect to my network (hard-wired ethernet) that requests data from the security controller and then converts the data (JSON) to a string, and sending it to a different IP (the monitoring service))
I'm using Azure API management for my project, with a backend service provided by Fiorano ESB. Fiorano to Azure has a peer-to-peer connectivity.
The services is deployed in the peer server which is added as a cloud service in azure.
So my concern is : for an API, in the URL if the resource is missing or wrong by default we'll get a json response as
{
"stausCode" : 404,
"message" : "Resource not found"
}
Is there any way that I can define this in OData standard format i.e. can i define it in a custom format as given below:
{
"error":{
"code" : "404_RES",
"message":{
"lang":"en-uk",
"value":"Resource $(wrong_resource given) is not found"
},
"innererror":{
"trace":[],
"context":{}
}
}
}
The $(wrong resource) should be taken dynamically
Take a look at set-body policy: https://msdn.microsoft.com/en-us/library/azure/dn894083.aspx#SetBody.
Basically, it allows you to modify/replace message bodies of incoming and outgoing requests.