IoT Creators Upgrade 26/05/2021 [STATUS UPDATES]

Florian Duecker

Hi everyone,

we have shifted our major upgrade to a new time window on the 26/05/2021 from 4 am to 6 am.

As the last time, during this time period, the portal and the API will not be available. The device uplink and downlink messaging should only be interrupted for some minutes. We found the issues that caused the problems last time, but to be a little bit more cautious with our promises this time, I ask you to please bear with us between that time period if not everything works a 100% immediately. We will keep you updated during the migration in this forum thread.

The upgrade of the system shall not last longer than 6 am. The graphical interface of the portal, however, will only be available later (around 8 am).

Please keep in mind that the current API URL iot.netwerk.t-mobile.nl will be replaced with api.scs.iot.telekom.com, which is available directly after the upgrade.

I also want to remind you of the two API changes:

GET <base-url>/rest/device:
In case registered device ids contain a leading prefix such as “IMEI:” (e.g. “IMEI:860350939064505”) the returned element “deviceId” doesn’t contain the prefix. The full device id with prefix is returned with the element “fullDeviceId”.
BUT in all API functions where devices are identified by its deviceId the leading prefix is required.
POST <base-url>/m2m/endpoints:
The API user with which devices are created needs to have registered an application URL. If this is not the case the creation of the device object fails.

UPDATES

TIMELINE / UPDATES:
*[19/05/2021 - 18:15] Announcement of new upgrade window
*[26/05/2021 - 04:00] System upgrade start
*[26/05/2021 - 04:53] Migration completed
*[26/05/2021 - 04:55] Started with testing
*[26/05/2021 - 05:10] No packet loss so far
*[26/05/2021 - 05:50] Perfromance and traffic level confirmed as 'normal'
*[26/05/2021 - 06:00] Bringing back portal/GUI functionalities
*[26/05/2021 - 07:00] Coffee, breakfast, waiting for more customer feedback
*[26/05/2021 - 07:45] Some of our colleagues already fell asleep, the coffee did not help
*[26/05/2021 - 10:20] Positive feedback from all customers!
*[26/05/2021 - 10:40] We just found out that it was decaf coffee..

magnatron

@Florian-Duecker said in IoT Creators Upgrade 26/05/2021 [STATUS UPDATES]:

also

Good morning. Great to read that the migration is completed successfully. I run into some issues:

The portal errors on every search for a specific IMEI. (like https://portal.iotcreators.com/projects/<project-num>/devices - try to search for any IMEI)
Device messages are not passed to our platform.
Combination of those two leads me to not knowing if messages from devices are sent to your platform.

Thank you for looking into these issues.

afzal_m

@magnatron
Thanks for providing this feedback, can you please send me some IMEI’s via DM or email?

afzal_m

@magnatron the IMEI that you just provided was only active on the May 19th and 23rd of May.

Is this a device that sends uplinks to your platform only after you triggered the device with a downlink? If so, than maybe the problem is not the uplink but the downlink.

If not, do you have another IMEI example which was online more recently?

magnatron

No, it’s a device that sends an uplink after a human triggered it on location.

magnatron

After another try, the device message did get through. Could this be the issue in which the first message by CoAp is seen as registration and then discarded before the message actually gets through?

afzal_m

Yeah, we just saw a successful message of this device coming in at 06:19!

I’s not the issue of being a registration message. In that case we’d have seen the message coming in.

And the last message before today 06:19 was from May 23rd…

Hence, the message never arrived. Maybe a temp. issue with the mobile network?

How is it going with the other devices?

With regards to the portal functionalities: we’re still bringing back the portal.

magnatron

Let’s keep it at an anomaly.
happy to say I see multiple devices getting their message across.
How’s the system holding up?

afzal_m

It’s going very well!

We even checked devices of many of our customers individually and it looks like everything is fully back up & running.

No packet loss unlike last time.

magnatron

Time for ️ + and getting the kids to school. Thanks to everybody for making this second time around a success!

afzal_m

Positive feedback from all our customers. Most of them did not even notice the downtime.

We’re happy!

magnatron

The portal is still not functional. Everybody sleeping?

Florian Duecker

What is not functional? The portal is up and running for me. What errors do you encounter?

Derko Drukker

I can confirm this. When I try to do a “search by IMEI” from the Device-tab in the Portal it always gives a “Something went wrong”-error.
I have no issues with losing data. Thatś all fine.

Florian Duecker

Thanks for all of your valuable feedback. I’ve started a new thread (https://forum.iotcreators.com/topic/704/iot-creators-bug-tracker) to track all current bugs that we are aware of and working on!

magnatron

API endpoint not working

URGENT!!
The API endpoint /impact/m2m/endpoints does not exist anymore.

A call like:

curl --location --request POST 'http://api.scs.iot.telekom.com/impact/m2m/endpoints' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Basic xxxxx' \
--header 'Cookie: xxxx' \
--data-raw '{    "additionalParams": {
         "adaptationLayerName":"TMNL_COAP_AL"
     },
     "address": "",
     "groupName": "CON_0000001xxx",
     "identifier": "",
     "protocol": "HTTP",
     "serialNumber": "IMEI:3588780801xxxxx"
} 
'

Results in a 404:

<html>

<head>
	<title>JBWEB000065: HTTP Status 404 - RESTEASY001185: Could not find resource for relative : /m2m/endpoints of full
		path: https://api.scs.iot.telekom.com/impact/m2m/endpoints</title>
	<style>
		<!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}
		-->
	</style>
</head>

<body>
	<h1>JBWEB000065: HTTP Status 404 - RESTEASY001185: Could not find resource for relative : /m2m/endpoints of full
		path: https://api.scs.iot.telekom.com/impact/m2m/endpoints</h1>
	<HR size="1" noshade="noshade">
	<p><b>JBWEB000309: type</b> JBWEB000067: Status report</p>
	<p><b>JBWEB000068: message</b> <u>RESTEASY001185: Could not find resource for relative : /m2m/endpoints of full
			path: https://api.scs.iot.telekom.com/impact/m2m/endpoints</u></p>
	<p><b>JBWEB000069: description</b> <u>JBWEB000124: The requested resource is not available.</u></p>
	<HR size="1" noshade="noshade">
</body>

</html>

Florian Duecker

Hey,

I had the same problems with the device registration (it works - but gives you a wrong error message). I will put this on the list.

In regards to the end-point. The end-point changed as we communicated in our migration announcement (https://forum.iotcreators.com/topic/701/iot-creators-upgrade-26-05-2021-status-updates). To quote myself:

"I also want to remind you of the two API changes:

GET <base-url>/rest/device:
In case registered device ids contain a leading prefix such as “IMEI:” (e.g. “IMEI:860350939064505”) the returned element “deviceId” doesn’t contain the prefix. The full device id with prefix is returned with the element “fullDeviceId”.
BUT in all API functions where devices are identified by its deviceId the leading prefix is required.

POST <base-url>/m2m/endpoints:
The API user with which devices are created needs to have registered an application URL. If this is not the case the creation of the device object fails."

This means the new end-point is: /m2m/endpoints instead of /impact/m2m/endpoints

magnatron

@Florian-Duecker

I did not read a mentioning of changing the actual URL.
The “also like to inform” made me think it was a side note.

I would like to request that a breaking change will get its deserved attention next time.

thanks

magnatron

@Florian-Duecker I checked the email but there’s no e-mail from the 24th. Do you mean the 28th? The original announcement for the update? In that e-mail there is also no mention of a breaking change in the URL. There was no mention anywhere about changing the URL from /impact/m2m/endpoints to /m2m/endpoints and as we were not using the /m2m/endpoints endpoint, our logical conclusion was this change did not apply to us.
My point is that if you make breaking changes, please make sure you fully communicate the changes.
We did not “miss” the communication of the change, you just did not communicate it.
thanks!

magnatron

I think there’s another change: Adding the application URL now sends an empty set of JSON where it used to send nothing? This to check if the application URL is valid.
Our application saw nothing as a valid hit but started working on the JSON only to find there was nothing in there, reporting an “error”. Which in turn disabled the saving of the application URL.

Not a bug but something to note in the docs. I think the docs should be super-clear about this:

I propose to change:

If you push the Save button in the YOUR APPLICATION SERVER tab IoT Creators will send an empty request to the URL to test if it is available.

️
If your application URL doesn’t return HTTP code 200 on the first test request the URL can not be saved in the "YOUR APPLICATION SERVER** tab.

Into something like:

If you push the Save button in the YOUR APPLICATION SERVER tab IoT Creators will send a POST request to the URL with the following JSON to test if it is available:
{"reports":[],"registrations":[],"deregistrations":[],"updates":[],"expirations":[],"responses":[]}

️
If your application URL doesn’t return HTTP code 200 on this first POST test request the URL can not be saved in the "YOUR APPLICATION SERVER** tab.

Florian Duecker

@Roalnd-Baldin Can you confirm this?

Roland Baldin

@magnatron It was never possible to store the application url if the application didn’t return 200.

In the old version the inital request contained an empty body to test if the URL is valid. This has actually changed. No an empty dictionary structure is put as payload.

Regads, Roland

Florian Duecker

[TOPIC CLOSED]