We're trying to implement subscriptions with Orion Context Broker v2, but when we create a new subscription it's returning a '405 Method Not Allowed' response.
We're following the documentation (http://telefonicaid.github.io/fiware-orion/api/v2/), I've attached an image with the request sent with Postman:
Postman subscription request
The Orion Context Broker version we are using is:
{
"orion": {
"version": "0.25.0",
"uptime": "16 d, 23 h, 49 m, 31 s",
"git_hash": "a8cf800d4e9fdd7b4293a886490c40309a5bb58c",
"compile_time": "Mon Nov 2 09:13:05 CET 2015",
"compiled_by": "fermin",
"compiled_in": "centollo"
}
}
Are we doing something bad related with the request?
Thanks in advance.
NGSIv2 operations to create/update/delete subscriptions have not been yet implememented in Orion 0.26.1 (the last version at the moment of writting this). The NGSIv2 operations related with subscriptions available in that version are:
GET /v2/subscriptions, to get all subscriptions
GET /v2/subscripstions/<id>, to get a given subscription (by id).
Note that NGSIv2 is yet in beta status, so sometimes the specification goes ahead of Orion implementation. Please, have a look to the following table in order to know the current implementation status of the different operations described at the NGSIv2 draft specification. This table is updated in a monthly basics.
EDIT: NGSIv2 operations to create/update/delete subscription are available from Orion 0.27.0.
Related
We are using FIWARE Orion NGSI V2 version and MQTT JSON IoT Agent. We have attached the version of Context Broker and IoT Agent we are using below.
By default, whenever we send telemetry data through MQTT broker, for a device which does not exist in Fiware, the IoT Agent is automatically provisioning/creating the device in IoT Agent and corresponding entity in Context Broker.
We want to restrict this behavior and do not want the IoT Agent to auto-provision devices, but to only accept telemetry data for already registered devices.
We have already tried to set the IOTA_APPEND_MODE environment variable to false, also tried to set the autoprovision flag to false when creating the service group. None of these options are working and autoprovisioning is still happening.
Need your help and guidance on how do we disable the auto-provisioning IoT Agent.
IoT Agent version:
{"libVersion":"2.12.0-next","port":"4041","baseRoot":"/","version":"1.14.0-next"}
Context Broker Version:
{
"orion" : {
"version" : "2.3.0",
"uptime" : "12 d, 18 h, 50 m, 12 s",
"git_hash" : "764f44bff1e73f819d4e0ac52e878272c375d322",
"compile_time" : "Tue Nov 5 09:16:27 UTC 2019",
"compiled_by" : "root",
"compiled_in" : "cfe8becf7aae",
"release_date" : "Tue Nov 5 09:16:27 UTC 2019",
"doc" : "https://fiware-orion.rtfd.io/en/2.3.0/"
}
}
Have you tried to deactivate the autoprovision flag for a given iotagent device group?
https://github.com/telefonicaid/iotagent-node-lib/blob/f2e0305ca13a181140ee1fd1df8debb5a0838bee/doc/advanced-topics.md#autoprovision-configuration-autoprovision
Best
Version 1.18.0 seems it fix some issues related with autoprovision flag. As #fgalan mentioned, the version you are running is quite old, so probably you need to upgrade at least to 1.18.0. I really encourage you to upgrade since it is backward compatible.
I have been reading old blocks from the solana JSON RPC API (using python), but now I am trying to subscribe to the block production on the solana network (to get up live updates).
I tried to pull updates through the RPC API using
{"jsonrpc": "2.0", "id": "1", "method": "blockSubscribe", "params": ["all"]}
This doesn't work, with response: 'code': -32601, 'message': 'Method not found'
Looking at the docs.solana.com info, it states that:
This subscription is unstable and only available if the validator was
started with the --rpc-pubsub-enable-block-subscription flag. The
format of this subscription may change in the future
I assume this means I need to run solana-test-validator --rpc-pubsub-enable-block-subscription, but this just returns:
error: Found argument '--rpc-pubsub-enable-block-subscription' which wasn't expected, or isn't valid in this context
Did you mean --rpc-port?
USAGE:
solana-test-validator --ledger <DIR> --rpc-port <PORT>
I can't seem to find any more information on how to subscribe to blocks using the RPC.
Any ideas or help with what I'm doing wrong?
Thanks in advance
You are correct that the validator has to run --rpc-pubsub-enable-block-subscription. For mainnet-beta usage, it is recommended to either find a private rpc with this enabled or have your own. Please note though, the method is marked currently as unstable.
It looks like rpc-pubsub-enable-block-subscription is not available on the test validator. You can find the full command list here.
This subscription is unstable and only available if the validator was started with the --rpc-pubsub-enable-block-subscription flag. The format of this subscription may change in the future
I have multiple subscriptions to different entities, and at some random time one of the subscriptions stops being notified.
This is because the lastNotification attribute is set in the future. Here is an example :
curl 'http://localhost:1026/v2/subscriptions/xxxxxxxxxxxxxxx'
{
"id": "xxxxxxxxxxxxxxx",
...
"status": "active",
...
"notification": {
"timesSent": 1316413,
"lastNotification": "2021-01-20T18:33:39.000Z",
...
"lastFailure": "2021-01-18T12:11:26.000Z",
"lastFailureReason": "Timeout was reached",
"lastSuccess": "2021-01-20T17:12:09.000Z",
"lastSuccessCode": 204
}
}
In this example, lastNotification is ahead of time. It is not until 2021-01-20T18: 33: 39.000Z for the subscription to be notified again.
I tried to modify lastNotification in the mongo database but that does not change it. Looks like the value 2021-01-20T18: 33: 39.000Z is cached.
The field lastFailureReason specifies the reason of the last notification failure associated to that subscription. The diagnose notification reception problems section in the documentation explains possible causes for "Timeout was reached". It makes sense to have this fail randomly if your network connection is somehow unstable.
With regards to timestamping in the future (no matter if it happens for lastNotification, lastFailure or lastSuccess) is pretty weird and probably not associated to Orion Context Broker operation. Orion takes timestamp from internal clock of the system where it is running, so maybe your system clock is set in the future.
Except if you run Orion Context Broker with -noCache (which in general is not recommended), subscriptions are cached. Thus, if you "hack" them in the DB you will not see the effect until next cache refresh (refreshes takes place at regular intervals, defined by -subCacheIval parameter).
while running the vorto dashboard im getting the following error
JWT expired, getting new Token Wed Aug 26 2020 07:38:56 GMT+0100 (BST)... StatusCodeError: 401 -
{"status":401,"error":"gateway:authentication.failed","message":"Multiple authentication
mechanisms were applicable but none succeeded.","description":"For a successful authentication
see the following suggestions: { The JSON Web Token is not valid. },
{ Please provide a valid JWT in the authorization header prefixed with 'Bearer ' }."
The contents of config.json is as follows
{
"client_id": "xxxxxxxxxxx",
"client_secret": "xxxxxxxxxxxx",
"scope": "xxxxxxxxxx",
"intervalMS": 10000
}
Tried with setting the contents of config.json as environment variables. Then also im getting same error. Screenshot of web front end on accessing localhost:8080 is attached
Tried with the following links Error running Vorto Dashboard for Bosch iot suite. But still its not working. Please help me in solving this issue
I have discussed the matter internally to Bosch (disclaimer: I am an employee).
After discussing with the Bosch Suite Auth team, here is a summary of what happened.
The Suite Auth team recently transitioned from Keycloack to Hydra for their authentication technology
The relevant bit here is that previously, the scopes passed to the token request were ignored
The Vorto Dashboard app had been passing the wrong key for the scope parameter all along, when requesting a token, but it was ignored
Now that this parameter is relevant, the (incorrect) notation was not failing to produce a token, but obtained one that was not suitable to authorize with Bosch IoT Things, because it did not contain the appropriate scope
In turn, fixing this key produces a token that successfully authorizes with Bosch IoT Things
If you're in a hurry, you can check out this branch with the fix (it's literally an 8 characters change set).
Otherwise, you can monitor this GitHub ticket for closure - I will close it when the fix is merged to the master branch of the Vorto Examples project.
Does the new version (0.24) of Orion let fuzzy search (approximate string search) over entities properties?
In addition, I tried to create an entity with an empty string, but althought the server is returning a 201 code, the entity is not created.
//url to create entity (POST)
http://some.ip:port/v2/entities
//payload:
{
"type": "Test",
"id": "Test.1",
"nombre": ""
}
//reponse
code 201
//url to list entities (GET)
http://some.ip:port/v2/entities?type=Test
//response
[]
This case doesn't work in Orion 0.24.0 due to a bug that has been recently solved in the develop branch. The fix will be available in the version next to 0.24.0, either 0.24.1 or 0.25.0 (number not yet decided at the moment of writting this) by the end of september 2015.
Regarding fuzzy search, we haven't consider yet that functionality in NGSIv2. If you find it useful/needed I'd recommend you to create a new issue in the Orion repository, explaining the feature request as detailed as you can, please.