Devices with Internet connectivity have some specific tabs on the Device detail page to display Internet specific information.
DvnUUID - UUID to uniquely identify the Device data coming in.
Shared Secret - The pre-shared password used for authorizing ingestion of IoT data from the device by the system.
Learn more about connecting your Device over Internet to KPN Things.
When generating your own DvnUUID we advice to use a Version 4 UUID.
Devices with M2M connectivity have some specific tabs on the Device detail page to display M2M specific information.
When registering an M2M device to KPN Things, some information needs to be provided:
IMEI - The IMEI number that uniquely identifies your device. This value is used for authenticating the device when IoT data is received by the system.
Shared Secret - The pre-shared password used for authorizing ingestion of IoT data from the device by the system. This value is not required for all types of M2M devices.
Additionally, Things needs to know the ICCID of the SIM card that is inserted in the Device. The ICCID that uniquely identifies the SIM card. This is used for connectivity management and sending SMS to the device if configured.
Learn more about M2M connectivity in KPN Things.
MSISDN - MSISDN is a number uniquely identifying your M2M subscription in the mobile network. It is also known as phone number, or 06-nummer in Dutch. Although M2M SIM cards often have a 079-nummer.
Rateplan - The commercial bundel of your SIM card.
Coming soon
The Device Twin is a digital representation of your Device. It expresses how your Device is doing, so it gives you a clear overview of the state of your Device!
The image below illustrates how the Device Twin data are set and used. All data can be read through the Portal and the API per Device.
Below the four parts of the Device Twin are :
Reported state - the most recent values of (a part of) the data sent from your Device. So if your Device sends a temperature measurement and you have configured that temperature should be stored in the Device Twin, you will find the last known temperature of that Device in its Twin.
Desired state - the state you want your Device to be in. For instance, if your Device supports changing the sending interval, you set the desired state of your Device to the desired interval, Things will recognize the desired state is different from the reported state and a downlink message is send to the Device to switch to a different interval.
Observed state - information that KPN Things can derive from the behavior of your Device. Here you can find for instance the Device sending interval.
Metadata - static information about your Device you want to store in the Device Twin. For instance in which batch the Device was produced, or the color of the casing of the Device. That way you store all important information for Device management in KPN Things.
The exact content of a Device Twin depends on the data a Device sends, the commands a Device can process, and the metadata you add manually to the Device Twin. Not all attributes may have a desired part, and sometimes an attribute with a desired state may not have a reported state. Closing the loop on desired and reported state is in the end something you should do.
In order to get the Twin up and running for a Device, some parts need to be configured in advance.
Before the Device Twin is able to show some values, the Device must be added to at least one Flow. This triggers processing of the data and allows the system to feed the Device Twin.
All data we receive from the Device is shown in the Device Twin. Previously you were required to configure in the Flow, which values you wanted to see before anything was shown. This setting has been removed from the Flow configuration.
Currently the available controls for the Desired state of a Device is determined in the Device type. Since the Own device types include a large set of different devices, we cannot yet provide a Desired state for own devices.
So, the Desired state is only available for KPN Devices.
In the near future, it will become possible to define your completely own Device type and with that define the Desired state options for your Device.
When you open de Device detail page of a certain Device, the Device Twin tab will provide you with all the information from the Device Twin of that Device.
Before the Device Twin will work:
Your Device should be in at least one Flow.
The Device Twin tab will point you in the right direction if the prerequisites is not yet fulfilled.
After all the configuration is in place, the Device Twin will start filling up with every incoming message from your Device.
In the screenshot below you see an example of a filled Device Twin with labeled:
The reported state
The desired state
The observed state
The metadata
Additionally the Device Twin tab provides you with links to the Device Twin documentation (#5) and a link to the Device Twin configuration page (#6). There is also a refresh button (#7), allowing you to refresh the Device Twin values without having to refresh the complete page.
The state section has been divided into two sections:
Device – showing all state expressing the Device, for instance firmware information, battery information and mode of operation. The name of the measurement is used by KPN Things to determine whether it is a Device state.
Other – all other values.
Below we will discuss every part of the Device Twin in detail.
The reported state of the Device Twin is composed of (a selection of) the most recent values of measurements KPN Things received from your Device. For each measurement where a reported state is known, its value and unit is displayed, as well as the moment when this value was last received. If you hover your mouse over the exact date and time, a popup will show you how long ago the reported state was last set.
Some trivial units will be hidden in the Portal, like enum, /, and string.
In a future release it will be possible to change the desired state even before the first reported state has been stored in the Device Twin of a Device.
The desired state of a Device expresses how you want the Device to behave. It depends on the Type of device which desired state values are available for control. For each state value where desired state control is available the most recent requested desired state is shown.
Next to the desired state value the exact date and time is shown of the moment the most recent desired state change was last requested. If you hover your mouse over the exact date and time, a popup will show you how long ago the reported state was last set. A blue timestamp with a blue circle next to it shows that the desired state change is still underway. If this is the case, the popup will also show you that the state change is still underway.
You can click on a certain desired state to change it (not available for read only accounts). Some values can be edited with a dropdown (#1 in the screenshot below), other values with a free input field (#2 in the screenshot below). After committing the desired state change, the state change will be communicated with your Device. Since the desired state change translates in to a downlink, you can see further information about the status of the downlink on the Send instruction tab of your Device.
The observed state tells you about the behavior of your Device from the perspective of KPN Things.
Currently only the Send interval is determined by calculating the time difference between the two most recently received messages. That means that in the case of a LoRa device, the interval may show a multiple of the expected send interval, since the lost message was not received by KPN Things.
In the metadata of the Device Twin you can (manually) store information about your Device in a key-value manner.
By clicking on Add a metadata property (#1 in the screenshot below) you will be given the input fields to add new metadata and its value. Click Save to store the new metadata property. You can edit the value of existing metadata by simply clicking the value (#2 in the screenshot below) after which an input field is shown and a Save button to store the change. If you want to remove a metadata property you can simply click the corresponding delete icon (#3 in the screenshot below).
In the future it will be possible to view a selection of the Device Twin values on the All Devices page, allowing you to search, sort and filter on these values. This feature is still in development.
Below you find a list of the values you can expect in the Reported state of the KPN Devices.
BatteryVoltage in Volt
CO2Concentration in parts per million
Humidity in % relative humidity
Illuminance in lux
Motion in count
Temperature in Celsius
BatteryVoltage in Volt
CO2Concentration in parts per million
Humidity in % relative humidity
Pressure in Pascal - the measured atmospheric pressure
Temperature in Celsius
VOC in parts per million - measured Volatile Organic Compound concentration
BatteryLevelLow as true/false
BatteryLevelLow_beacon as true/false - the battery level low indication of the detected beacon
Count_LidOpen - number of times the bin lid has been opened
DetectedBeacon - DevEUI of the last detected beacon
Distance in meters - distance to the detected object from the fill sensor
DistanceMeasurementIsValid as true/false
LidOpenedSincePreviousTransmission as true/false
Temperature in Celsius
BatteryLevelLow as true/false
Sabotaged as true/false
Temperature in Celsius
BatteryVoltage in Volt
FirmwareCRC - unique code to express the firmware on the Device
FirmwareVersion
Mode
SettingsCRC - unique code to express the settings on the Device
AcceleratorActive as true/false
AlarmMode as true/false
BatteryVoltage in Volt
MotionTime in minutes
MovementIndication
NfcFieldDetected
Sabotaged as true/false
Temperature in Celsius
No additional data.
AccX in m/s2 - measured acceleration in the X-axis
AccY in m/s2 - measured acceleration in the Y-axis
AccZ in m/s2 - measured acceleration in the Z-axis
CompX in Tesla - measured compass orientation in the X-axis
CompY in Tesla - measured compass orientation in the Y-axis
CompZ in Tesla - measured compass orientation in the Z-axis
DvLat - geographical latitude
DvLon - geographical longitude
GpsFix
Heading in radians
Io31 in 1/0 - arbitrary bit
IoButt in 1/0 - whether the Device's button was pressed
IoMot in 1/0 - whether the Device is in motion
IoRxd in 1/0 - Device's external digital i/o value
Speed in m/s
Temp in Celsius
VBat in Volt - measured battery voltage
MovementIndication
BatteryVoltage in Volt
FirmwareVersion
Altitude in meters
GpsTime in seconds
Heading in radians
Latitude
Longitude
Radius in meters - the accuracy of the geographical latitude and longitude
Status
Temperature in Celsius
Velocity in m/s
TIME_ORIGIN or TimeOrigin
Interval in minutes or hours - sending interval of Device
Latitude
LocAccuracy - deprecated
LocOrigin
LocPrecision - deprecated
LocTime
Longitude
Radius - the accuracy of the geographical latitude and longitude
Devices with LoRa connectivity have some specific tabs on the Device detail page to display LoRa specific information.
Currently only LoRaWAN 1.0.x is supported. Also, only OTAA is available. ABP is not available since it is less secure.
DevEUI - Unique LoRa device identifier.
AppEUI - LoRa application identifier.
AppKey - LoRa device authentication and encryption root key.
Learn more about LoRa connectivity in KPN Things.
This tab shows you detailed information about the messages send to and from your Device from the perspective of our LoRa network.
Messages in LoRa data history are stored up to 1 month.
The message overview of LoRa data history gives you an overview of all message to and from your Device in descending order of time. So the most recent message is at the top of the list of messages.
What you can see here is:
The type of LoRa message.
Whether it was an uplink (🔵 blue) or downlink (🟢 green) message.
Whether it was a Join request, Join accept or regular message.
Whether the message was confirmed or unconfirmed, or whether the message carried an ACK.
Whether the messages contained data, mac, or both.
Whether a LoRa Geolocation result could be determined on that message (only available for uplink).
The exact timestamp of the message, with millisecond accuracy.
The frame counter value of the message. Uplink (FCntUp) and downlink (FcntDown) communication has its own counter.
An indication of the signal strength the message.
Click on the chevron at the end of a row to see more details of a message.
Search bar to see the message history up to a certain point in time.
Button to load more data history (if available).
When you open the details of a message by clicking the chevron at the right side of the row, you can see the following:
Details about the message signal:
The used Spreading factor.
The used LoRa channel.
The number of gateways that received the message (uplink only).
The Received Signal Strength Indicator (RSSI) of the message (uplink only). This gives you an indication of how strong the message's signal has been received by the best receiving gateway.
The Signal to Noise Ratio (SNR) of the message (uplink only). This gives you an indication of the amount of noise when the message was received by the best receiving gateway.
The Estimated Signal Power (ESP) of the message (uplink only). ESP is calculated from RSSI and SNR and gives an indication of the used link budget.
Details about the content of the message:
The LoRa application port on which data was send or received (if applicable).
The exact payload of the LoRa message (if applicable).
The exact MAC content of the LoRa message (if applicable).
Flags that were in the LoRa message, like ACK, FPending or ADRAckReq.
Details of the LoRa Geolocation result:
Coordinates of the calculated location.
Radius in meters, the theoretical inaccuracy of the LoRa Geolocation result.
This section will explain what you can expect when you first connect your LoRa Device to KPN Things.
In the screenshot below you can see the beginning of a typical LoRa data history. The message are shown in descending order of time, so the first message is at the bottom of the list of messages.
Below at the section Step 5. Normal operation you can find an even more elaborate example. If your LoRa data history is not the same as in the screenshot above, you can continue reading to understand the chronology of LoRa data history.
The first thing your device should do is try to join our network. With a join request, the device will ask to network whether it may join. Learn more about joining in LoRaWAN.
This means the network does not see any activity from your device. Try one of the following actions to fix:
Check whether the LoRa registration was successful by checking the connectivity status on the Device detail page.
Check if your device is programmed/configured with the same DevEUI you find in the connectivity details on the Device detail page.
Check if your device is sending the join request on one of the default LoRaWAN channels. Learn more about LoRaWAN channels.
Maybe the network coverage is not ideal at your current position. Thick walls or a sub-optimal antenne can cause issues. Try to move to a more exposed location for better coverage, like moving closer to a window.
It could be that your device is not sending the join request on SF12, the spreading factor with the farthest reach. Program/configure your device to use this spreading factor when joining to increase coverage of your device.
Maybe you are completely out of reach of the network. You can check our LoRa network coverage online.
After receiving the join request, the network will check whether the Device is known and whether the security details are correct. If so, the network will respond with a join accept.
This means the network sees your requests to join the network, but there is a (security) reason not to accept your join request. Try the following to fix it:
Check if your device is programmed/configured with the correct AppEUI.
Check if your device is configured with the correct AppKey. This could also have to do with the endianness with which you should enter the AppKey in your device.
Try to remove your device from the Portal and re-add it, maybe you made a typo when registering your device.
After your Device has received and processed the join accept, it can begin sending data.
This means the join is completed from the network point of view, but somehow your device does not see it the same way. Try the following to fix it:
Often join accepts are sent on the RX2 receive window. Is your RX2 receive window correctly configured? This should be 869525000 MHz and DR0 (SF12). Some device manufacturers have the device wrongly configured with the RX2 receive window listening on DR3 (SF9). (This is a common issue with Dragino devices!)
Sometimes the link budget for downlink is smaller than uplink, meaning downlinks are harder to receive than it is to send uplinks. This accounts for worse coverage for downlink than for uplink. Try to move to a more exposed location and try again.
It could be that there is a programming error in your Device that causes your Device to incorrectly process the Join accept. Please refer to your device manufacturer documentation for more help on that.
It could be a LoRa reception problem, due to configuration problems or insufficient coverage. You can check the possible solutions for "I don't see uplink data appearing in the LoRa data history!" above for more info.
Download messages are messages send by the network to your Device. These can be mac messages, containing commands to your Device about LoRaWAN transmission settings, or they can contain data from your application or from KPN Things.
After a Device has joined, the network will send up to three downlink messages with mac commands in them.
Now your Device will go into normal operation, often meaning periodically sending uplink messages. In the screenshot below you can see a typical LoRa data history.
Using the timestamps for consecutive uplink messages you can determine the average sending interval of your Device. This sending interval should not be too high, since you might be violating the fair use policy of KPN Things.
Make sure your Device does not send more often than once every 5 minutes on average.
Each mac command consists of a request and an acknowledge message. So mac messages should come in pares in the LoRa data history.
If this is often not the case and you see that downlink mac messages are not answered by the Device, please check your Device, because there might something wrong. If your Device does not follow up mac commands, the transmission settings cannot be optimized.
Make sure your Device responds to all mac commands.
Not every uplink message will give a new calculated LoRa Geolocation. This is normal. It can be caused by the fact that too few gateways received the uplink, or if other circumstances were sub-optimal.
When a value for FCntUp is missing in the LoRa data history, it means that that specific message has not been received by the network. In LoRaWAN communication it is normal to have lost messages, your application should take this into account. It is a side-effect of the very energy efficient way LoRaWAN works. In normal situations you can expect up to 5% message loss. If your losses are higher, coverage on the location of your Device might be temperate.
If you see a join ceremony before each first message (FCntUp = 0), there is something wrong with your Device. Maybe it is losing power in between data transmissions or there is another reason your Device rejoins after each message.
Your Device should not rejoin after each message, because it puts unnecessary stress on the battery consumption of your device and it prevents the network to optimize the LoRaWAN transmission configuration through mac commands.
Make sure your Device remembers its join in between uplink messages.
If you see your Device (almost) only send Confirmed uplink messages, your Device is not properly configured. Sending too much Confirmed uplink messages puts too much demand on downlink communication, since every Confirmed uplink message requests a downlink message containing an ACK (acknowledgement) from the network. The network has not been designed to handle constant Confirmed uplink messages. This will negatively impact the overall capacity of the network. Therefor the use of Confirmed uplink messages is part of our Terms of Use.
No more than 10% of the uplink messages of your Device may be Confirmed messages. All other messages must be Unconfirmed.
Want to learn more about LoRa connectivity? Head on over to our KPN LoRa documentation!
A Device represents a single physical device that can send data to the platform. When adding a device to KPN Things, you register the following information:
Name - A descriptive name of the Device.
Barcode (optional) - The serial number of other code that is visible on the outside of the Device.
Description (optional) - More information about your Device.
Device type - What type of Device it is.
Network info - The information required to register the Device to the correct network.
In KPN Things the Device type is used to express the connectivity and data capabilities of a Device, like whether it is a LoRa or an M2M device, and its compatibility to Data Processing components such as decoders and encoders.
We have two categories of Device types, namely Own Devices, where you bring your own Device to KPN Things, and KPN Devices, where you buy a Device from us. Each categorie has its own set of Device Management features in the Portal.
Legenda ✅ - Available for this device type. 🟡* - Configurable for your own device, coming soon. ❌ - Not available for this device type.
Each Device in KPN Things will have a processing status. This will tell you whether data from and to that Device will be processed by KPN Things.
To connect a Device to KPN Things it needs either to be registered to our LoRa or M2M network, or it needs to be an Internet-connected device running our SDKs or other KPN Things compatible software.
Separate pages will explain more about the supported network types:
On the All Device page, you have an overview of all your Devices.
Elements on the page are:
Total number of Devices you have and see on the current page.
Device list of all your Devices with some information:
The Device name.
The Device type.
The primary identifier of your Device.
For LoRa this is the DevEUI
For M2M the IMEI
For internet the DvnUUID
The moment Things last received a message from the Device.
The Project the Device belongs to.
The number of Flows your Device is in. Hover over the number to get a popup with a list of Flow names.
Clicking on a row will open the Device detail page of that Device.
Search element to search for your specific Devices. You can search by Name and Primary identifier.
Link to add a new Device.
Bulk manipulation options. Select some or all Devices and choose the bulk action from the action bar at the bottom of the page.
Sorting options, by clicking on a specific table header the table will sort by the selected value.
A lock 🔒 icon for KPN (Managed) devices. For such devices fewer editing options are available. We have a table comparing what you can do with Own and KPN devices.
This is the place where your register new Devices and add them to KPN Things and our networks.
If you have more than one Project, you will have to select to which Project you would like to add your Device.
Depending on your Project subscription, available Device types may vary.
Name: Typically can be a Device ID or the name of a physical asset which the device is linked to.
Barcode (optional): Barcode or serial number used to identify a device.
Description (optional): Any additional device information.
When done, click Add Device to continue.
This step will look differently, depending on the type of network information.
If you selected Own LoRa device (programmable) device type in the previous step, the Portal will give you the OTAA join information (DevEUI, AppEUI and AppKey). Make sure to copy-paste or write down the provided identifiers. For security reasons the secret values will not be retrievable through the Portal after closing this page.
Click Finish to continue.
If you selected Own LoRa device (preset connectivity) or a supported device type, you should provide the LoRa network information for your device in this step.
Click Add network info to save the network information and then Finish to continue.
IMEI of your Device.
ICCID of your SIM-card - select the correct SIM card from the drop down. If you have an Early access SIM, you choose the option "Add early access SIM" and enter the ICCID of the SIM manually in the newly appeared input field (see A in the screenshot below).
Shared secret.
After entering the values, click Add network info to save the information, or click Finish without adding Network to continue without adding network information to your Device object.
DvnUUID - the unique number to identify incoming data from your Device. Your Device UUID is prefilled, but you can enter any UUID you like.
Shared secret - kind of password.
The most impotant difference is that: Device deactivation can be used temporarily and is neccesary when you want stop data from devices being send to devices. As an example: a customer has not paid his invoice and in response this customer receives no data. Deletion is permanent. When you want to delete a device, you can log a ticket via our IoT Servicedesk to ask them to delete your devices. After the deletion, you can't onboard this device again.
In the table below you can read about the differeces between deleting a Device and deactivating a Device.
This page offers you all detailed information about your Device and its connectivity.
The elements on this page are:
Connectivity information card for your Device, depending on your network type.
LoRa information card for devices with LoRa connectivity.
M2M information card for devices with M2M connectivity.
Internet information card for devices with Internet connectivity.
Send Instruction tab allowing you to send data to your Device.
Device tab showing you more details about your Device.
Device Twin tab showing you the Twin of your Device.
Flows tab showing you detailed information about the Flows your Device is linked to.
A button to delete your Device. This will completely remove your Device from KPN Things! (Not available for KPN (managed) devices).
The Device information card contains general information about your Device:
The name of your Device.
The Device type.
The processing status of your Device, which you may be able to update.
The Flows linked to your Device.
Clicking on the Device name or Device type will open the Device tab with more information about your Device.
The LoRa information card contains more LoRa specific information of your Device.
The DevEUI of your Device.
The connectivity status.
The moment KPN Things last received data from your Device.
Clicking on the DevEUI or the Type = LoRa part of the card will open the LoRa tab with all LoRa specific information of your Device.
The M2M information card contains more M2M specific information of your Device.
The IMEI of your Device.
The ICCID of the SIM card linked to your Device.
The MSISDN of the subscription linked to the SIM card in your Device.
The connectivity status with the possibility to change its value.
The moment KPN Things last received data from your Device.
The moment your SIM card has been activated.
The rate plan of the subscription linked to your SIM card.
Button to unlink the current SIM card from your Device. (Not available for KPN (managed) devices).
Clicking on the IMEI or the white part of the card will open the M2M tab with all M2M specific information of your Device.
The Internet information card contains more Internet specific information of your Device.
The SenML base name
The connectivity status.
The moment KPN Things last received data from your Device.
Clicking on the base name or the white part of the card will open the Internet tab with all Internet specific information of your Device.
LoRa data history will show you all data and mac traffic sent to and from your Device up to one month ago. Learn more about LoRa data history.
Currently you can only send data to your Device if your Device is linked to at least one Flow!
On this tab you can send data or instructions to your Device, and you can see the status of requested data/instructions. Data to LoRa devices is also called a downlink.
Depending on your device type, different ways of sending data/instructions to your Device will be available. These could be:
Raw LoRa data - for own LoRa devices and supported LoRa devices.
Raw SenML - for any Things M2M or Internet device.
Predefined commands - for KPN devices. Learn more about KPN devices.
No downlink available - for devices that do not support downlink communication.
To see which methods are available for your device type, you can check the available encoders for your device type.
Some Device types allow you to send raw LoRa data to your Device. To do this, you need to enter two values in the form as shown below:
FPort - the LoRa application port you want to send the data on.
Payload - the data you want to send to your Device in hexadecimal characters.
Things M2M devices and Internet devices can communicate with SenML. So downlinks to these devices should also be SenML.
The input form in the Portal should be filled in with a valid SenML measurement list formatted as JSON. Learn more about SenML. The entered SenML measurement list does not have to contain base values, KPN Things will add those before sending the downlink to the Device.
For KPN Devices we provide a predefined list of human readable commands that you can send to the Device. Simply select the desired command to send by clicking on the radio button (if multiple commands are available), select the desired value for the command from the drop down, and click submit.
If downlink is not available for your Device, you will see the following:
If your Device is not yet linked to a Flow, doing this could enable Downlink for your device. A Flow is required to enable an encoder that is required for downlink communication. Learn more about downlink communication in de Developer Manual.
Often data or an instruction sent to your Device is not received immediately. Often the Device is in sleep mode and will be able to receive the data when it wakes up again. So to monitor the status of the requested data/instructions to your Device, you can check the downlink status table on this tab.
There are five downlink statuses, illustrated in the diagram below and further explained in the table below.
More information on sending data to your Device can be found in the Getting started 5, send downlink to LoRa Device.
This tab shows you detailed information about your Device configuration. Learn more about the Device information you can find here.
This tab shows you the Twin of the selected Device. There is a separate page explaining the Device Twin in detail.
You can read more about the LoRa network information you can find on this tab.
If your LoRa Device is not yet registered on the LoRa network, you can click Register Device on Network here. This will open a modal for you to enter the LoRa network information for this Device.
The M2M tab shows you detailed information about your M2M connectivity. You can read more about the M2M network information you can find on this tab.
Additionally, you can perform some M2M specific actions:
2. Edit M2M Device Configuration - allows you to generate a new shared secret for your M2M device. 3. Switch SIM card - allows you to administratively switch the SIM card of your M2M device. 4. Unlink SIM card- allows you to administratively remove the SIM card from your M2M device.
If your M2M Device is not linked to a SIM card, you can click Link Connectivity here. This will open a new page to allow you to link your Device to a SIM card. The steps you take for this action are the same as for linking your SIM card to a Device.
In the Flows tab you can see:
A list of all the Flows your Device is linked to and the Project this Flow is in.
You can click on a Flow to open it.
You can click on Unlink from this Flow to remove the Device from that Flow.
Also you can add your Device to another Flow.
If there is a possible issue with one of the Flows your Device is in, a warning icon is shown on the Flow tab link and in the row of the concerning Flow. By clicking on the warning icon of a Flow, you will continue to the Flow detail page displaying more information about the warning.
After you click on Link to another Flow in the Flows tab, a modal will open.
In this modal you can:
Select the Project to which you want to add the Device, if you have more than 1 Project.
Select the Flow to which to link your Device.
Optionally create a new Flow to which to link your Device.
| Status | Description |
|---|---|
| Deactivate Device | Delete Device | |
|---|---|---|
Can be recognized by the 🔒 symbol in the Device list.
Bring or Buy
Bring yourself
Buy
Add to / remove from Portal
✅
❌
Edit name and description
✅
✅
Activate / deactivate in Portal
✅
✅
Send / receive raw payload
✅
❌
Send commands
🟡 *
✅
Device Twin - Reported state
✅
✅
Device Twin - Clear measurements
✅
❌
Device Twin - Desired state
🟡 *
✅
Device Twin - Metadata
✅
❌
🟢 Active
Data coming from and going to your Device will be processed.
⚫ Deactivated
Data coming from your Device will not be processed or forwarded by KPN Things. Also downlinks will not be sent to your Device. Data history will still be available, since Things will still accept data from your Device. The network connection is not denied.
⚫ Not yet linked
Your Device is not connected to a Flow, so data will not be processed in KPN Things.
Status
Description
⚪ Not yet linked to a network
Your Device is added to KPN Things, but Network information is still missing in able to register your Device to the network.
🔵 Pending create
Your Device is being registered to the network.
🟢 Active
Your Device or SIM card is registered to the network and should be able to join and send data.
⚫ Deactivated
Your Device or SIM card is registered to the network, but labeled as Inactive, meaning incoming connections will not be accepted.
🔴 Failed
The Device could not be registered to the network. Probably the Network info you entered to register your Device was incorrect or already in use.
⚫ Inventory
Your Device and its Network information is known in the system but not yet registered to the network. If you want you can activate the network registration on the Device detail page.
Why use it?
Temporarily disable data from Device. (example: disable data for sub customers)
The device is end of life and should be tossed out.
Can customers do it themselves?
Yes, in bulk and for individual devices.
No
Is it permanent?
No, you can easily Activate the Device again in the Portal in bulk and individually.
Yes, the Device is removed from all KPN systems. You can not use this the device again.
Does it influence billing?
No, remove from Flow to have it stop being counted (applicable to Modular customers, E2E customers are being billed by information in C8Y)
Yes, because it is also removed from the Flow.
Impact on battery if Device is still turned on
Connection between Device and Network is not changed, so the Device continues operating as normal.
Network registration of Device is removed. Depending on how the Device is programmed it may continue operating as normal, but it will probably change to a more energy consuming mode because the device will (uselessly) try to reconnect to the Network.
Can you check the operation afterwards?
Yes, because the Device object still exists, only has the attribute "STATUS" changed to "Deactivated". But once the Device is reactivated, you cannot see when it has been deactivated.
No, the Device is completely removed from all systems.
Status
Description
Pending
When a downlink is requested on the Actuator API the command will get the status Pending. This means the downlink is accepted by Things and will be processed shortly. If there is another downlink of the device already in Executing, the downlink will stay in Pending until the other downlink reaches a final status. Downlinks will be processed by KPN Things in order of request date, so FIFO.
After the previous downlink has been finalized, it can take up to an hour or so for the next pending downlink to be taken into execution. We are working on it to shorten this period.
Cancelled
Pending downlinks can be cancelled. Since a pending downlink is not yet being processed by network systems, KPN Things can safely remove the downlink from its queue. Cancelled downlinks will not be processed any further and will get the final status Cancelled.
It is not possible to cancel a downlink that is in Executing, since we cannot guarantee the withdrawal of a downlink request that is already being executed by the network system.
Executing
When there is at least one downlink in the queue for a device, so with status Pending, it will be processed further by the system. It will then be de-normalized and sent to the device. During de-normalization, sending and waiting for feedback on delivery, the downlink is in Executing.
Only one downlink per device can be in Executing.
Failed
When KPN Things does not receive acknowledgement of the successful delivery of the downlink, or if KPN Things receives a timeout on sending the downlink, the downlink will get the final state Failed.
Delivered
When the delivery of the downlink is acknowledged by the device, the downlink will be set on final state Delivered.
