1

We are following the theory that as users we must issue a command to the Context Broker to change the state of a device: Image 1

In our case, this command already works if we do it from the IoT Agent, but however, if we execute it from the Context Broker through a PATCH, it does not reach the IoT Agent.

Do you know why this could be happening?

Our Context Broker request is the following: Image 2

And finally, the request we make from the IoT Agent, which is the one that works, is this: Image 3

Another doubt that arises is, if the IoT Agent updates all the information in the Context Broker, why not execute the request from there instead of from the Contex Broker?

Cristina Carretero
  • 21
  • 3

1 Answers1

0

Your request to Context Broker seems to be ok. Sometimes, the lack of ?type in the request causes problems (see for instance this post) but it doesn't seem to be your case.

I'd suggest to check registrations at Orion. Registration is the mechanism in which the request forwarding from Orion to IOTAgent is based (more info in Orion documentation. IOTAgent should create and manage them, but something could be failing. You can get existing registrations in Orion with the GET /v2/registrations operation.

With regards:

Another doubt that arises is, if the IoT Agent updates all the information in the Context Broker, why not execute the request from there instead of from the Contex Broker?

The FIWARE data management model is context-centric. Thus, the Context Broker is the central piece of the architecture, to intermediate between context producer and context consumer. Commands are a kind of "context production", so it makes sense that Context Broker deals with commands. Note that the client issuing the command maybe doesn't even are able to access to the IOTAgent directly (they use to be "close" to the physical devices they manage and not typically open to direct client requests).

fgalan
  • 11,732
  • 9
  • 46
  • 89