Posts made by Florian Duecker

In regards to the CSV upload: I think most of your wishes will be fulfilled by the updated version. It will be deployed in the next days and it would be great to get your feedback then. In regards to the supported formats - at the moment is is UDP and COAP (we might change the identifier to NEUL in the future). See also here: https://forum.iotcreators.com/topic/715/batch-import-excel-csv

In regards to the subscription, I’m not sure if I understand you correctly. Is this happening when registering the device via CSV? Is this related? Or is this an unrelated problem that even occurs when you register the device “manually”? When you enter an application endpoint it should automatically create the subscription!

Hi Maarten Good news: we were already aware of this, it is fixed and will be deployed in the next release. The original idea was to have a first row for headers (as you can see in the import dialog), but we also found this not a 100% clear/obvious. So our dev-team came up with a solution to auto-detect whether the first line includes a header or an IMEI. It should of course also removes the error of adding more than just 3 IMEIs.

As Afzal said, our SIMs are PIN-free and should work out-of-the-box. So make sure the SIM card is installed correctly and all of the components do work correctly.

I also recommend to check out our documentation library.

We have a step-by-step tutorial for the BG-96: https://docs.iotcreators.com/docs/_-quectel-bg96-tuino096

Good luck!

@Roalnd-Baldin Can you confirm this?

Hi Yosiel,

can you please re-check and maybe (if possible) try to register another device. We deployed a hot fix today, so it should be fixed now. If you tried to send a message before registering this might cause issues as well as @magnatron pointed out.

Florian

@magnatron I sent you an email with more info on the MFF2 sims and I will manually sent you some MFF2. Please don’t be mad at me, but I need to moderate this thread a little bit as we now start to talk also about other stuff like migration communication which nothing has to do with bugs - I move some of the posts to the migration thread.

Hi Yosiel,

thanks for bringing this up. This is a known bug, see here: https://forum.iotcreators.com/topic/704/iot-creators-bug-tracker. You should be able to see the device after you reload the project page.

But were working on a proper fix right now.

Florian

@Cees-Meijer Thanks. I added this to the list and our backlog.
@magnatron regarding the communication of the change: I’m sorry you missed that. I will try to make it more prominent next time, but please also check your emails from 24.04 and 19.05 where we also made aware of this. Regarding the SIM: From my understanding: MFF2 is the form factor. eSIM stands for embedded SIM and this could be done in different form factors (e.g., MFF2, WLCSP). But the MFF2 SIM is an eSIM. It needs to be soldered on. I’m not an expert on this and would ask to bring this topic to another thread if necessary as I don’t consider this as bug. thanks!

@magnatron Please check: https://docs.iotcreators.com/docs/sim-cards - it has information about eSIM and nuSIM. Last week this link lead another old version without these information and old links. This should now be fixed. Maybe you need to clear your cache.

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

Thanks. I put this to the list of errors and created some backlog tickets for our developers. In case you need to change your billing address at the moment, you still should be able to do this in the setting view.

Hi magnatron,

thanks for reporting. I can not reproduce the bug. Can you please give more details.

Thanks

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!

Hi all,

we know that bugs are frustrating, but let’s keep track on them together so we can fix them ASAP. If you encounter any other problems, please let us know here.

These are the bugs that we are aware of and working on

PORTAL

• Search device by IMEI not functional (28.05 fixed with limitation; 02.06 fully fixed)
• Device overview not consistent (i.e., empty pages) (28.05 fixed for most cases)
• Broken Link to edit billing address in invoice overview (02.06 fixed)
• Confusing 404 wording (fixed)
• Adding devices in project results in error message and site needs to reload in order to see all devices (Hotfix deployed: 31.05)
• Refresh Table link on the portal does not work (02.06 fixed)
• Minor issues with the CSV import

 
DOCUMENTATION

• Page https://docs.iotcreators.com/docs/sim-cards has a link leading to https://forum.iot.t-mobile.nl/ (28.05. URL fixed with newest version)

Florian

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

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..

CLOSED: Migration cancelled. New thread will be opened for new migration.

CLOSED: Issue resolved.

I agree the conflicting pre-migration communication to you specifically was not good at all and I’ve already apologized (see my email that I have sent to you).

In regards to today’s communication, however, I disagree. We were super transparent. The migration itself went well, all components of the system were running. We switched the portal back on at 11:10 (yes, 10 mins. late). The problems only started to appear when the high load hit the system and as soon as we noticed we immediately started to do a communication (here at 11:45 and email at 11:55).

We did several updates and tried to keep everyone as much as possible in the loop while focusing on fixing the issues. And I’m really appreciative for the positive messages that I have received about the transparent communication, even though not everything went as planned.

@Cees-Meijer Thanks for the motivating words!

Hi @magnatron and everybody else who was affected:

I’m really sorry that the process was not as smooth as we all have wished for. And if it caused any inconvience, I apologize for this.

We have planned and tested this for month, but you never know how a productive system behaves even though everything went smoothly in a testing environment.

As Afzal said, we had our reasons to do this during “office hours”. We have discussed other options, but that seemed to be the most reasonable way for us to do it as we do have critical devices sending data 24h (so from that perspective our office hours are 24/7).

Did everything go as planned today? No. But we will learn from this and hopefully we can make it better next time. We were super transparent as soon as we realized that there were some problems and updated our community as much as possible while troubleshooting the problems.

Hopefully the next attempt will more smooth. Thanks for your understanding.

Hi all,

we have successfully upgraded our system today, but we still need some time to stabilize the system.

The portal is back up, but to be transparent: We are experiencing some instabilities in our platform with delivering the device messages currently [11.05.2021 - at 11:45]. We are working at full speed to fix the problems.

[UPDATE 12:55] We see that all components of the new release are running well and therefore we decided not to rollback the platform and rather work on stabilizing it. We are currently reconfiguring the sizing of our infrastructure to resolve the problem as quickly as possible.

[UPDATE 15:15] Unfortunately, we could not stabilize the system and we will roll back to the old version.

We like to apologize for any inconvenience caused. We will keep you updated on the progress.

Thanks for your understanding.

Florian
IoT Creators Team

**[STATUS UPDATES]**
11:00 - Migration is done
11:10 - The IoT Creators Portal is back online
11:45 - We are troubleshooting some problems in message delivery
12:55 - The instability o is caused by the high load that we have on our productive platform. 
13:00 - We are currently reconfiguring the sizing of our infrastructure
15:15 - Decision: we roll back to the old version until the issues have been fixed
15:20 - Rollback started
15:35 - Rollback completed