UDP op het impact platform met SARA-N211

Andre Rodenburg

Hallo allemaal.

Vandaag met support van @afzal_m geprobeerd UDP messages te sturen naar onze backend.
CoAp werkt goed, UDP lukt nog niet.

Ik heb de volgende stappen uitgevoerd:

POST - (UI) Register endpoint (Device) (standaard API call uit het TMNL CDP pakket)

alt text

POST - Register UDP application
Een voor UDP omgebouwde versie van de PUT - Register application API call welke origineel bedoeld was voor CoAp.

De code die ik van @afzal_m gekregen heb:

curl -X POST
https://gui.m2m.t-mobile.nl/impact/m2m/endpoints
-H ‘Accept: application/json’
-H ‘Cache-Control: no-cache’
-H ‘Content-Type: application/json’
-d '{ “additionalParams”: {
“adaptationLayerName”:“TMNL_UDP_AL”
},
“address”: “”,
“groupName”: “<your tenant name>”,
“identifier”: “”,
“protocol”: “HTTP”,
“serialNumber”: “IMEI:<your imei>”
}

Mijn implementatie:
alt text

Header:
alt text

Response:

{
“msg”: “Device added successfully”,
“code”: 3000
}

POST- Register subscriptions (standaard API call uit het TMNL CDP pakket)

Alles lijkt goed te gaan dusver?

We doen op het device de standaard network attach en openen een UDP socket:
-> AT+NSOCR=“DGRAM”,17,7000,1
<- 0

Sturen een bericht:
-> AT+NSOST=0,“172.27.131.100”,15683,4,“45726963”
<- 0,4
<- OK
<- +NPSMR: 0
<- +CSCON: 1
<- +CSCON: 0
<- +NPSMR: 1

Dus het bericht is succesvol verzonden!

Wat mij opvalt:

De standaard API call voor CoAp gebruikt PUT, dit werkt niet met mijn versie voor UDP. Post werkt wel.
De Get resources subscriptions API call laat vier keer dezelfde subscriptie zien voor hetzelfde device. Dit heeft misschien iets te maken met het POST commando aangezien deze een nieuwe resource aanmaakt… maar hier heb ik verder geen ervaring mee.
Ik kan geen resources / devices deleten. Ik zou graag één of meerdere API calls willen hebben om resources te deleten, zoals bij OceanConnect wel kon.

Echter komt het bericht nooit aan. Ik heb verschillende IP en poortnummers geprobeerd, zowel die van het t-mobile CDP als ons eigen backend. Ik heb de firewall open gezet en met een andere methode (geen nb-iot) een UDP pakket naar de server gestuurd. Dit pakket komt wel aan, ook met de firewall actief. Ook worden er geen IP adressen bij ons geblokkeerd dus t-mobile whitelisten heeft geen zin.

Hopelijk willen jullie het ook proberen, misschien komen we er samen uit.

afzal_m

Thanks voor het delen van je bevindingen hier!

~~Ik heb begrepen dat resource subscription niet nodig is in de UDP adapter.~~

~~Dus dat betekent dat je alleen een IMEI hoeft te registreren en een applicatie te registreren. Zou je het opnieuw kunnen proberen zonder de resource subscriptions stap te doen?~~

[Eric] Een resource subscriptie is ook nodig voor UDP net als bij CoAp.

Verwijder door een DELETE call te doen naar {{base_url_cdp}}/rest/device/<je ID>

We gaan het nog toevoegen in een nieuwe postman collectie!

afzal_m

Ik heb voor de zekerheid zelf even je device verwijderd. Hij stond nu ook 2x in je applicatie.

Andre Rodenburg

@afzal_m

Zou je dat nog een keer kunnen doen? Ik zie nu dat ik het registreren van een device dubbel doe en met de verkeerde parameters…

afzal_m

@andre-rodenburg done!

Andre Rodenburg

@afzal_m Bedankt! Zou je mijn resource subscriptions ook kunnen verwijderen? Die staan er nu ook een stuk of 6 keer tussen :)

Een delete call naar {{base_url_cdp}}/rest/device/<je ID> werkt overigens niet. Misschien mis ik een header oid?

afzal_m

Dat is gek! Bij mij werkt het wel.
En de delete call voor de subscription dus ook niet?

Andre Rodenburg

@afzal_m

Een delete call voor subscription werkt wel:

DELETE{{base_url_cdp}}/m2m/subscriptions/<subscriptionId>

Andre Rodenburg

@afzal_m Misschien maak ik een fout in de syntax?

DELETE{{base_url_cdp}}/rest/device/XXXXXXXXXXXXX

Met XXXXXXXXX als mijn IMEI. Zonder haakjes of wat dan ook. Geeft altijd de response RESOURCE NOT FOUND.

afzal_m

Ik neem aan dat je IMEI:XXXXXXX bedoelt?

Andre Rodenburg

Oke kleine update:

Ik doe nu:

Register device POST
{ “additionalParams”: {
“adaptationLayerName”:“TMNL_UDP_AL”
},
“address”: “”,
“groupName”: “{{group_name}}”,
“identifier”: “”,
“protocol”: “HTTP”,
“serialNumber”: “IMEI:XXXXXXXXXXXXX”
}
Response:
{
“msg”: “Device added successfully”,
“code”: 3000
}
Register application POST
{ “headers” : { “authorization” : “Basic XXXXXXXXXXXXXXXXXXXXX”
},
“url” : “http://office.interay.nl:1732”
}

Stap 2 geeft een timeout. Lijkt er op dat de server weer wacht op een 200 OK bericht terug. Voor HTTP gaat dit dus wel goed.

Andre Rodenburg

@afzal_m said in UDP op het impact platform met SARA-N211:

Ik neem aan dat je IMEI:XXXXXXX bedoelt?

IMEI:XXXXXXX heb ik inderdaad ook geprobeerd. Daar krijg ik deze reactie op:

{
“code”: “UNEXPECTED_ERROR”,
“localizedMessage”: “Internal system error. Please contact administrator if the problem persists.”
}

DELETE{{base_url_cdp}}/rest/device/{{DeviceId}} heb ik ook nog geprobeerd, gaf hetzelfde resultaat.

Andre Rodenburg

@andre-rodenburg

In de documentatie staat dit:

During registration, the CDP platform automatically checks if the callback URL provided is valid, that
is, it verifies if the CDP client is reachable at that address. This is to ensure that CDP platform sends
notifications to the correct URL. In case, CDP client is not reachable, registration will fail with 400
error code.

Hier gebruik ik dus de PUT register application call voor:

{ “headers” : { “authorization” : “Basic XXXXXXXXXXXXXX”
},
“url” : “{{north_application}}”
}

Dit gaat goed als op {{north_application}} HTTP draait.

Hoe registreer ik een applicatie als op {{north_application}} UDP draait?

Eric Barten

Hoi Andre voor de North application url maakt het niet uit onder welk protocol je device connect. Dit blijft hetzelfde.

Andre Rodenburg

@eric-barten

Dus

Device <-UDP-> CDP <-HTTP-> Backend ?

Eric Barten

Inderdaad de netwerken blijven gescheiden op deze manier.

Eric Barten

@andre-rodenburg bij deze call moet je het device id gebruiken en niet de naam / serialnumber. dus de call ziet er zo uit ; (DELETE / GET){{base_url_cdp}}/rest/device/187
Je kan devices en id’s opvragen met de call (GET) {{base_url_cdp}}/rest/device?iDisplayLength=-1

Andre Rodenburg

@eric-barten Heel erg bedankt, delete device call werkt nu ook!

Inderdaad de netwerken blijven gescheiden op deze manier.

Hier was ik mij niet van bewust maar het verklaart wel een hoop. Je hebt me weer een paar stappen verder gebracht!

Andre Rodenburg

@afzal_m @Eric-Barten

Het lukt ondertussen nog steeds niet om UDP messages te ontvangen, raw udp of udp passthrough maakt geen verschil:

Openen socket: AT+NSOCR=“DGRAM”,17,7000,1
Versturen bericht: AT+NSOST=0,“172.27.131.100”,15683,4,“45726963”

Geven geen enkele error. Ik krijg een bevestiging van het modem dat het bericht verstuurd is. Ook de attachment gaat vlekkeloos.

Misschien iemand anders die het wel werkend heeft gekregen met een ublox modem?

melvinItude

Hoi Andre,

Lastig probleem om op te lossen als je niet kan nagaan waar de fout zit.
Zelf heb ik wel UDP uplinks werkend maar dat is dan met de BG96.
Wat mij wel is opgevallen is dat ik soms ook geen UDP binnen kreeg na registratie.
Ik heb toen het device verwijderd uit de API en alles opnieuw uitgevoerd:

registeren device
opnieuw registreren applicatie
registeren subscription (dit blijkt niet nodig te zijn voor UDP)

Daarna heb ik de BG96 opnieuw laten connecten met het netwerk en na enige tijd ging het dan werken.

Andre Rodenburg

@melvinitude Dat het jou wel gelukt is met een BG96 moet betekenen dat het netwerk het wel kan. Inderdaad lastig om de fout te vinden, ook omdat blijkbaar nog niemand anders het met een ublox geprobeerd heeft.

Ik ben wel benieuwd naar welke AT-commands je gebruikt hebt en in welke volgorde. Misschien mis ik daar iets. Ik zal ook eens proberen de hele sequence opnieuw te doen inclusief de API.

melvinItude

@andre-rodenburg
Met deze commando’s heb ik gewerkt op de BG96:

Open socket: AT+QIOPEN=1,0,"UDP SERVICE","127.0.0.1",0,5683,0
send message: AT+QISEND=0,<payload size>,"172.27.131.100",15683
A > will follow from bg96. Type payload
Check for incoming message: AT+QIRD=0
Close socket: AT+QICLOSE=0

Een volledige communicatie tussen MCU en BG96:

AT+QIOPEN=1,0,"UDP SERVICE","127.0.0.1",0,5683,0

OK

+QIOPEN: 0,0
AT+QISEND=0,4,"172.27.131.100",15683

> test
SEND OK
AT+QISEND=0,0

+QISEND: 4,4,0

OK
AT+QIRD=0

+QIRD: 0

OK
AT+QICLOSE=0

OK

Hoop dat je er wat aan hebt!

Andre Rodenburg

@melvinitude Bedankt voor je informatie!

Lijkt er op dat we dezelfde commando’s gebruiken, al is de syntax voor mijn uBlox modem anders.

Mij ideeën zijn wel een beetje op nu. Misschien kunnen jullie het intern eens proberen met uBlox hardware? @Eric-Barten @afzal_m