1. Home
  2. The Thing For IoT Creators
  3. UDP op het impact platform met SARA-N211

UDP op het impact platform met SARA-N211

  • A

    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:

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

    alt text

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

    1. POST- Register subscriptions (standaard API call uit het TMNL CDP pakket)
      alt text

    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:

    1. De standaard API call voor CoAp gebruikt PUT, dit werkt niet met mijn versie voor UDP. Post werkt wel.
    2. 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.
    3. 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.

    0
  • afzal_m
    Deutsche Telekom IoT

    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!

    1
  • afzal_m
    Deutsche Telekom IoT

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

    0 A 1 Reply
  • A

    @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…

    0 afzal_m 1 Reply
  • afzal_m
    Deutsche Telekom IoT

    @andre-rodenburg done!

    0 A 1 Reply
  • A

    @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?

    0
  • afzal_m
    Deutsche Telekom IoT

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

    0 A 2 Replies
  • A

    @afzal_m

    Een delete call voor subscription werkt wel:

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

    0
  • A

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

    0 E 1 Reply
  • afzal_m
    Deutsche Telekom IoT

    Ik neem aan dat je IMEI:XXXXXXX bedoelt?

    0 A 1 Reply
  • A

    Oke kleine update:

    Ik doe nu:

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

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

    0
  • A

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

    0 A 1 Reply
  • A

    @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?

    0
  • E
    Deutsche Telekom IoT

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

    1 A 1 Reply
  • A

    @eric-barten

    Dus

    • Device <-UDP-> CDP <-HTTP-> Backend ?
    0
  • E
    Deutsche Telekom IoT

    Inderdaad de netwerken blijven gescheiden op deze manier.

    0 A 1 Reply
  • E
    Deutsche Telekom IoT

    @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

    1
  • A

    @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!

    0
  • A

    @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?

    0
  • M

    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.

    1 A 1 Reply
  • A

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

    0 M 1 Reply
  • M

    @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!

    0 A 1 Reply
  • A

    @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

    0
Log in to reply