@Ronan-Lacroix - yep the time is but the zz is the timezone. SO below an example of the time I just retrieved from your NB-IoT network (at 17:16 PM local time).
+CCLK: “2022/06/07,15:16:21+08”
The timezone is +8 quarters of 15 minutes. So UTC +2 hours. Now I assume that the timezone is changed for winter and summertime (DST).
So I assume that in winter the following will be returned (when local time is 17:16PM)
+CCLK: “2022/06/07,16:16:21+04”
Hi @Florian-Duecker, is there any reason for this limitation?
We are setting up a pilot project using this APN and I hope the APN will last to exist 
Hi Florian,
I didn’t knew about the uplink message tags. Can I add them to existing devices?
It wouldn’t be an endpoint per device. Let’s say (example) an endpoint for 100 location trackers and a different endpoint for 50 Parking sensors.
In my application I create a flow for the location trackers and a flow for the parking sensors (independent from each other). When I add extra location trackers to the ‘location trackers endpoint’, they will reach the corresponding application (same with the parking sensors in the example).
For now this would be two endpoints. But I would prefer to have the option to add more (also for development devices, separated from the live devices).
When using multiple sensor types within 1 project. All sensor data is forwarded to our application with 1 stream. We need to recognise the sensor type in our application.
In (for example) TTN, we can create a application per sensor type and thus have a endpoint per sensor type.
Would it be possible to do this on iotcreators?
Or do we need to have a extra project for that? (But that would mean extra costs)
@uta Hey Uta, I’m reviving this old thread.
I tried registering devices with csv today, but I encountered 2 bugs
Example csv:
8615180405XXXXX,UDP
8615180405XXXXX,UDP
8615180405XXXXX,UDP
8615180405XXXXX,UDP
8615180405XXXXX,UDP
ETC
Is this a issue on my side, or are you experiencing the same?
Or was I not patient enough? 
Thats no problem, thanks for the update.
I have copy+pasted every device manually.
Wasn’t that much work for 100 devices.
@Uta the portal states ‘Import CSV/Excel file’ so I assumpted Excel was supported.
Okay, good to know. Then I can continue with the project. Thanks for the help.
Thanks for the response Uta,
I tried the example you send, but I still get the error “Something went wrong while registering your devices. Please try it again.” Also when not using the header. So I’ll wait with the CSV file untill the bugfix is live.
The complete csv file I used:
IMEI,PROTOCOL
86151********51,UDP
86151********97,UDP
Also tried a excel file, but that also didn’t work.
Importing using a Excel file is also workable.
Do you have an example of a excelfile?
What rows/columns should I use?
I want to import a batch of ±100 devices in IoT creators.
I want to import using a csv or Excel file, but can’t find any examples.
Is there a example for batch import that I can copy?
@Eric-Barten said in Downlink API dataformat:
ary the device visualizes the received data for yo
Okay, that my bad.
Thanks for the answer
@Roalnd-Baldin
Do you know if and how I can send a binary downlink? (see the convo between Stefan and me)
@Stefan-de-Lange Hey Stefan,
Do you know if a binary downlink is possible? And how?
@Stefan-de-Lange
Yes, that would be great
@Stefan-de-Lange said in Downlink API dataformat:
@Roalnd-Baldin 01AB uses twice the amount of data as hi if it’s received as ASCII
Yes, this is what I mean.
In this case I would need to first encode ‘01AB’ to ASCII before sending it to the API.
But I’m not that familiar with ASCII encoding so I’m not sure if there are edge case scenario’s which don’t work.
If its possible. Sending HEX to the API would be best (as it is also the standard for other networks I have worked with)
Hey Roland,
Thanks for the answer.
I’m wondering. Can I send the resourceValue in HEX instead of ASCII?
My payload is in hex. I want to avoid
HEX2ASCII -> T-Mobile -> Node -> ASCII2HEX
Preferred would be
HEX -> T-Mobile -> Node -> HEX
I can’t send a downlink via HTTP PUT as described in the API.
I send the data as HEX to the API, which returns true. But the node doesn’t receive data.
When sending the data in base64 format to the API using this url:
*PUT {{base_url}}/m2m/endpoints/{{DeviceId}}/downlinkMsgBase64/0/data
The node does receive data. But it receives the HEX data as ASCII from T-Mobile.
So for example:
I Send base64 ‘AA==‘ (1 bytes)
(Base64 ‘AA==’ translates to HEX ‘00’)
The node receives the ASCI string: ‘00’ (2 bytes)
This should also mean that all downlinks are twice the size.
From the node (written by my colleague )
AT+CSOSEND=0,36,00000363501E01078041E0163C3000000000
OK
+CSONMI: 0,2,00
Downlink data received: 00 (but this is ASCII, which translates to 3030 in HEX)
Is it possible to send the downlink in HEX so that the node receives it in HEX?
Or could this be a error in the modem?
Hello,
We are using a number of test SIM cards and noticed that IMEI is leading (we expected the IMSI to be leading).
Now we are still in a test phase and it is not that important, however we are looking at live deployments as well.
For real customers
How do we block a customer? Using the IMEI only disables the device itself and does not disable the SIM card and its connectivity. So how does it work within TMO?
Thanks
Laurens