How to Debug IoT Agents Webinar - 17th April 2019 Corresponding webinar recording: https://youtu.be/FRqJsywi9e8 Chapter: IoT Agents Difficulty: 3 Audience: Any Technical Presenter: Jason Fox (Senior Technical Evangelist, FIWARE Foundation) How to debug IoT Agents - investigating what goes wrong and how to fix it.

1. How to debug IoT Agents
Jason Fox, Senior Technical Evangelist
FIWARE Foundation

2. Learning Goals
 How to diagnose common problems
 How to test services in isolation
 How to set-up and interpret debug
 Configuring IoT Agents:
• Where are settings described and defined?
• How can they be overridden?
 Adding diagnostic debug
 Where to look for help and advice?
1

3. FIWARE Catalogue
22
Data/APIManagement
PublicationMonetization
Core Context Management
(Context Broker)
Context
Processing, Analysis, Visualization
Interface to
IoT, Robotics and third party systems
Deploymenttools
2
Development of
Context-aware applications
(Orion, STH-Comet,
Cygnus, QuantumLeap, Draco)
Connection to the
Internet of Things
(IDAS, OpenMTC)
Real-time
processing of
context events
(Perseo)
Handling authorization
and access control to
APIs
(Keyrock, Wilma,
AuthZForce, APInf )
Publication and
Monetization of Context
Information
(CKAN extensions, Data/API
Biz Framework, IDRA)
Creation of
Application Dashboards
(Wirecloud)
Real-time
Processing of media
streams
(Kurento)
Business Intelligence
(Knowage)
Connection to robots
(Fast RTPS,Micro XRCE-DDS)
Big Data
Context Analysis
(Cosmos)
Cloud Edge
(FogFlow)
Documents exchange
(Domibus)

4. Generic Scenario: IoT Sensors to FIWARE Context Data
3
 We are using an IoT Agent to receive data
from a series of devices using a common
protocol
 The IoT Agent must interpret the data and create
and modify NGSI data entities in the Context Broker
 The system must react on changes of state. In this
example, changes of state of data entities must
somehow be persisted into a database using Cygnus,
but we could equally be doing some processing or
visualization.
 In a working system is possible we would want amend
the transport or add security.

5. What can possibly go wrong?
 Listening on the wrong port/resource-path/protocol
 Check data is received on each part of the chain
 Not paying attention to the FIWARE service headers
 Misinterpreting received measures
 Reading Numbers as Strings
 Misusing localhost in a containerized environment
 Setting up subscriptions too narrowly
 Provisioning services and devices incorrectly
 Using deprecated interfaces (NGSI v1)
 Using obsolete or incompatible Generic Enablers
4

6. Configuration and Provisioning
 config.js
• Base configuration file found in root of each enabler
• Annotated
• Most options switched off
 Using Docker, you can:
• Inject your own config.js volume
• Override common ENVs
• Override specific ENVs
 Provisioning Groups and Devices
• Further override options
5

7. Setting Debug
Debug options vary considerably between components:
 Orion:
 IoT Agents:
 Cygnus:
 Keyrock:
 PEP Proxy:
6
-logLevel DEBUG -noCache -logForHumans
IOTA_LOG_LEVEL=DEBUG
CYGNUS_LOG_LEVEL=DEBUG
DEBUG=idm:*
Amend the log_config.json file directly

8. Debugging
 Check Services are running
 Follow the logs
 PM2 Monitoring
 Listening to MQTT traffic
 Sending dummy MQTT data
7
docker ps
docker logs -f fiware-iot-agent
docker exec -it fiware-iot-agent pm2
monit
docker run -it --rm --name mqtt-
subscriber --network fiware_default
efrecon/mqtt-client sub -h mosquitto -t
"/#"
docker run -it --rm --name mqtt-publisher
--network fiware_default efrecon/mqtt-
client pub -h mosquitto -m "c|1" -t
"/TEF/motion001/attrs"

9. Sanity Checks
 Always stick to a specified version of each component
 Check by using /version endpoints
• check component versions against releases
 Read debug to see where data is/is not being retrieved
 Initially use "idPattern": ".*" in subscriptions
 Check the notification details such as timesSent
 Ensure IOTA_CB_NGSI_VERSION and IOTA_AUTOCAST are set
 Check your mapped attributes on provisioned devices
8

10. Add diagnostic debug by amending the source
 git clone - grep the source code for your error message
 git clone - amend source code - add debug - create image
direct from source - instructions in Dockerfile
docker build -t iot-agent .
 Fork source code and amend - create image from fork
docker build -t iot-agent .
--build-arg GITHUB_ACCOUNT=<your account>
--build-arg GITHUB_REPOSITORY=<your repo>
--build-arg SOURCE_BRANCH=<your branch>
 All FIWARE projects are open-source - PRs accepted.
9

11. Where to get help
 Read the Documentation
• https://www.fiware.org/developers/catalogue
 Find the Source Code on GitHub
• https://github.com/FIWARE/catalogue
• Raise issues with individual enablers
 Ask development questions on Stack Overflow
• https://stackoverflow.com/questions/tagged/fiware
• Always tag question fiware plus relevant tags
• Stack Overflow is a third-party site. Follow their rules of engagement:
• Development questions only
• Provide logs/evidence of your efforts
 Use the FIWARE Q+A
• https://ask.fiware.org/questions
• Also Usable for non-development questions
10

12. Summary
 Avoid simple problems by running basic sanity checks first
• Test each link in the chain to diagnose your real issue
• Setting up debug differs for each component - always check the documentation
for details
 IoT Agents can be set up and overridden many different ways:
• Base config.js, injected config.js, Docker ENV overrides
• Device specific provisioning
 Read the documentation on ReadTheDocs
 If you’re still having problems, add diagnostic debug by
amending the source code and running a local image
 Further help can be found on Ask, Stack Overflow or raising
issues on GitHub
11

13. Thank you!
http://fiware.org
Follow @FIWARE on Twitter
12