I am using the Ultralight 2.0 IOT Agent.
Although I can see that the payload, that my gateway sends, is subscribed at a specific topic into the mosquitto MQTT broker, how could I test that the IOTAgent is listening at port 4061 and that it is receiving something from the broker?
I am refering to the IOTAgent-UL which is running on a CentOS 7 VM as a service. I have access to it with REST calls and I also see that the payloads, that my gateway sends, are subscribed into the MQTT broker. How could I pass my payloads from the mosquitto to the IOTAgent and after to the Context Broker?
thanks a lot!
What you are asking for seems to be related with the basic operational workflow of the IOTAgents in general. Thus, I'd recommend you to have a look to the following Step by step guide. It is based in another agent (the one for JSON payloads instead of UL) but most of the procedure is the same, so I think it could be useful.
EDIT: JSON format is documented here. UL format is documented here. Payload format is indepedent of the transport, i.e. is the same no matter if you use HTTP or MQTT.
Related
Despite of set attrsFormtat to legacy it's not working, I get Missing parameter: updateAction
Any suggestions?
Thanks.
EDITED: I try it in a million ways and i can't handle this always getting the same error.
I am not an expert in Cepheus Broker but I have a bit of experience playing with Cepheus CEP and Orion Context Broker in FIWARE ecosystem, maybe I can be useful.
According to the official documentation of CEP, you should be deploying Cepheus Broker before Orion Context Broker instead after. I know that both speak the same NGSI API so it should be the same, but I am not completely sure about that. Any particular reason why you are deploying these components in that order?
I make a little experiment using official Docker images of Cepheus Broker and Orion context Broker, creating context subscriptions through v1 and v2 Orion APIs. The same error as you on Cepheus Broker logs.
Then I proved with this little app made by Fiware fellows, that you can use for debbuging NGSI context subscriptions. I tried with v1 and v2 subscriptions, with legacy and no legacy in v2 and any of this produces a "updateAction" field in the request. Then I realized that as far as I know, within the NGSI API methods the only service that receives the updateAction parameter is the updateContext service.
May be Cepheus can not connect with Orion Context Broker through Context Subscription mechanism. Maybe he's waiting for a context update instead a context change notification.
Sorry for not being of more help.
Regards!
You are trying to make Orion send a notifyContext request to the updateContext endpoint of Cepheus CEP. This cannot work as an updateContext request is expected to contain an updateAction field in the payload according to the NGSI v1 protocol.
Cepheus CEP expects notifications from subscriptions to be done to its notifyContext endpoint.
Moreover Cepheus CEP will send its own subscription requests to Orion when properly setup (you must declare Orion as a provider in the CEP configuration). It will ask Orion to send back notification to the correct endpoint.
Finaly, you cannot make the subscription on behalf of Cepheus CEP like you are trying to do: Cepheus CEP will only accepts notifications for the subscriptions it made itself because it validates the subscription ids of all notification it receives.
Could someone suggest me the easiest way to send data from my android phone to my local Orion Broker Instance via MQTT? I have installed locally Orion Broker and IoT Agent for the Ultralight 2.0 protocol.
Assuming that IoTAgent is correctly configured to interact with Orion and with MQTT broker, the steps would be as follow:
Provision your phone device at IoTAgent, using the IoTAgent provisioning API
Start sending data using MQTT transport, from your device to the MQTT broker. IoTAgent will get that data and publish at Orion Context Broker.
Get your data from Orion Context Broker, either using synchronous queries or subscriptions/notifications.
The step by step guide at IOTAgent documentation explains bullets 1 and 2 with more detail. However, note this document is based in JSON payloads, so you have to adapt them to UltraLight 2.0. For example, the UltraLigth 2.0 equivalent for
mosquitto_pub -t /1234/sensor01/attrs -m '{"l":4,"t": "31.5"}'
would be
mosquitto_pub -t /1234/sensor01/attrs -m 'l|4|t|31.5'
I've used the FIWARE Orion Context Broker and IoTAgent-UL in my project. I've registered a virual device by sending a Json message carrying the device attributes, the command attributes, device endpoint address and the used protocol (UL2.0).
If I update the command attribute of the device entity in Orion Context Broker, how can i check that the command is sent to the IoTAgent successfully before it is forwarded to the device virtual device itself?
Moreover, can I make the IP address of a Raspberrypi the endpoint itself and assign a port to a device connected to the Raspberrypi? And how could this be done?
Finally, in case I have no physical device could I consider the IoTAgent's address an endpoint to check whether any update on the command attribute in the context broker will be forwarded to that endpoint?
Thanks
There are three ways of checking the update context/command has been sent to the agent, and from the agent or the device:
Check Orion or agent logs.
Check the MQTT broker logs, if you are using MQTT transport.
Check the device itself. If the command was received, you'll be able to see the effects of the command.
Regarding the place a Raspberry Pi may play in an architecture using IoT agents, typically it is used to replace the agent :) I mean, if having a device such as a Raspberry Pi, the usual scenario is to connect to the R-Pi all your sensors and actuators, as if it was a gateway, and then let the R-Pi connect directly to Orion Context Broker by implementing a NGSI client running in the R-Pi. Schematically:
Orion <---> R-Pi + NGSI client <---> sensor/actuator
Nevertheless, I guess you can use the R-Pi as if it was a final device (sensor or actuator) in order to test IoT agents. Regarding how to emulate the final device itself, I guess you'll have to run certain logic in the R-Pi in order to accept the UL messages from the IoT agent/MQTT broker. A simple netcat could help you; more complex emulation services could be run, of course. Schematically:
Orion <----> UL agent <---> R-Pi + netcat
Anyway, please observe always a final device (sensor or actuator) is required, either real, either simulated (running netcat or similar in a R-Pi/server), since the UL agent must have an endpoint where to send the UL payloads.
Orion <---> UL agent <---> R-Pi + netcat OR server + netcat OR real sensor/actuator
I am using the MQTT IoT agent to send data to my fiware context broker, I am wondering if I can send data from my IoT agent to multiple context brokers. Is that possible? if yes how to?
Thanks in advance for your help!
The MQTT IoT-Agent is connected to a specific Context Broker instance depending on the Service provision. If the Service Context Broker instance is not configured, then the "ngsi_urls" parameter is used.
Therefore, yes, you can deliver information to multiple ContextBroker instances but only one per defined FIWARE service.
If you want to send the information of one single service to multiple instances of Context Brokers I think you may send it to one and then federate the other instances. To learn about Context Broker instances federations you should check the ContextBroker related documents.
Thanks for using IDAS and sorry for a so delayed response (we have been slower regading support due to an internal migration process).
I need to create a http post request that will put a message in a message queue.So far I am able to do it successfull within the test framework i.e: using the integration node.
My question is how I will be able to test this from a external browser?
Do I need to deploy it in an external server?
Any links or suggestion will be really helpful.
I often use curl for testing webservices deployed to IIB. You can use the "-d" parameter to specify a file containing the POST data and this works well for both HTTP and SOAP.
I don't think browsers are meant to call web services directly, try SOAPUI for testing.
Message Broker Applications need to be deployed on a Broker and Execution Group or Integration Node and Integration Server (after V9).