Ik wil graag de LMiC library gebruiken om met een SX1276 module te communceren met het LoRaWan netwerk van KPN. Ik heb verschillende vragen
Ik heb een NodeJS backend met SSL certificaat. Als ik op test connection druk krijg ik OK. Toch blijft de status 'The last message could not be forwarded to the destination URL'. Ik laat overigens mijn server als response code een 200 terugsturen.
Ik heb twee devices aangemaakt, een OTAA en een ABP.
Bij OTAA kopieer ik Device EUI naar de variabele APPEUI[8] en keer de byte volgorde om. Ik kopieer AppKey naar APPKEY[16] en keer de byte volgorde ook om. Ik krijg de melding 44689: EV_JOINING
en daar blijft het bij. Op de backend komt niets binnen.
Bij ABP kopieer ik NwkSKey naar NWKSKEY[16] in omgekeerde byte volgorde, AppSKey naar APPSKEY[16] in omgekeerde volgorde en Device address naar DEVADDR. Ik krijg de melding 135084: EV_TXCOMPLETE (includes waiting for RX windows) en zie wederom niets op de backend.
- Waarom krijg ik een OK bij de uplink test en tegelijkertijd de melding 'The last message could not be forwarded'?
- Welke aanpassingen moet ik doen om via de LMiC library te communiceren met LoRaWan van KPN? Overigens lukt het mij wel om via TTN LoRaWan payloads te versturen.
Alvast dank voor de hulp!
LMIC's standaard instellingen (kanalen etc) werken prima met KPN (2/3 weken geleden getest) addresering van de frames gebeurt op basis van (hoe kan het ook anders) het 'devAdr'
[i]// LoRaWAN end-device address (DevAddr)
static const u4_t DEVADDR = 0x14XXXXXX ; //
[i]// LoRaWAN end-device address (DevAddr)
static const u4_t DEVADDR = 0x14XXXXXX ; //
Dankje @Dion Leurink voor het delen van je ervaring! Goed om te lezen dat de standaard instellingen van LMiC werken op het KPN netwerk.
@JeroenD Wat betreft de Uplink Test foutmelding moet ik eerlijk bekennen deze specifieke melding nog niet eerder te hebben gezien. Ik heb uw account gevonden middels uw e-mailadres, kan het kloppen dat uw server / hostname momenteel onbereikbaar is?
Assessment failed: Unable to connect to the server
Assessment failed: Unable to connect to the server
Ja dat klopt, ik zet de route alleen aan tijdens testen, ook omdat ik hier nog aan ontwikkel. Ik kan de server wel een tijdje laten draaien.
Ah juist, duidelijk. Zoiets verwachtte ik inderdaad.
Kunt u een schermafbeelding maken van de foutmelding met de uplink test knop?
Kunt u een schermafbeelding maken van de foutmelding met de uplink test knop?
Blijkbaar wordt de mouse over niet gecaptured, maar de letterlijke tekst is:
The last message could not be forwarded to the destination URL endpoint
Overigens komen de berichten van mijn LoRaWan node keurig binnen! ☺️
Kan jij enge activiteit van mijn nodes zien?
Hallo Jeroen, over het maximum aantal verstuurde berichten ga ik navraag doen. Het is niet bij mij bekend dat daar iets in veranderd. Dezelfde cuty cylce and beperkingen blijven volgens mij van toepassing (max 10 devices, max 3 downlinks per uur).
De foutstatus bij je devices komt mogelijk doordat je server adres 10 keer achter elkaar onbereikbaar is geweest. De server van KPN stopt dan met het doorgeven van berichten. In de developer portal kun je deze counter resetten zodat de devices weer werken. Echter als de server wederom onbereikbaar is voor meerdere berichten, zal de counter weer oplopen en het device eventueel deactiveren.
Gisteren heb ik alleen even gekeken wat de eigenschappen van je server zijn en of het certificaat klopt. De server was down en heb ik verder ook niets gedaan. Mijn advies om even goed naar de error counter te kijken! Vanmorgen heb ik de devices voor je geactiveerd en werken ze vermoedelijk weer. (ik kwam alleen nu pas aan een reactie toe 😊 )
Ontzettend bedankt voor de informatie over de test uplink foutmelding! Dat gaan we verder uitzoeken. Gezien de functie wel lijkt te werken, zou je de melding kunnen negeren lijkt me.
Verneem graag van je of je weer aan de slag kan!
De foutstatus bij je devices komt mogelijk doordat je server adres 10 keer achter elkaar onbereikbaar is geweest. De server van KPN stopt dan met het doorgeven van berichten. In de developer portal kun je deze counter resetten zodat de devices weer werken. Echter als de server wederom onbereikbaar is voor meerdere berichten, zal de counter weer oplopen en het device eventueel deactiveren.
Gisteren heb ik alleen even gekeken wat de eigenschappen van je server zijn en of het certificaat klopt. De server was down en heb ik verder ook niets gedaan. Mijn advies om even goed naar de error counter te kijken! Vanmorgen heb ik de devices voor je geactiveerd en werken ze vermoedelijk weer. (ik kwam alleen nu pas aan een reactie toe 😊 )
Ontzettend bedankt voor de informatie over de test uplink foutmelding! Dat gaan we verder uitzoeken. Gezien de functie wel lijkt te werken, zou je de melding kunnen negeren lijkt me.
Verneem graag van je of je weer aan de slag kan!
Ik heb een werkende uplink gehad, met hetzelfde device naar zowel KPN als TTN (met andere sleutels en device id uiteraard). Ik heb deze diverse keren aangemeld via ABP. Later lukte het me niet meer om te communiceren, niet met jullie en niet met KPN. Toen op beide platformen een nieuw device aangemaakt, en met de nieuwe sleutels kon ik weer communiceren. Mijn vragen zijn:
- ik mag toch zo vaak als ik wil een ABP join doen? Ik begrijp dat dit geen best practise is :)
- Kan het zo zijn dat een device dat op een andere LoRaWan aangemeld is geweest niet meer herkend wordt? Ik kan het me bijna niet voorstellen, maar wil dit graag uitsluiten..
Ik heb wel een nieuwe vraag 😉 : als ik een OTAA doe, is dat bij jullie een geautomatiseerd proces? Maw: is de device direct na de OTAA activatie operationeel en kan ik direct berichten versturen?
Hi @JeroenD , sorry voor mijn late reactie. Goed dat je de oorzaak hebt gevonden m.b.t. de berichtenteller! Deze wordt gereset bij een rejoin.
Voor zover ik weet kun je inderdaad zo vaak als je wilt een ABP join doen. Echter adviseren wij om OTAA te gebruiken vanwege de beveiligingsredenen. OTAA voor de Developer Portal wordt niet automatisch doorgezet / aangemaakt. Er zit nog een kleine controle op die overdag doordeweeks plaats vindt. Een OTAA registratie in de nacht wordt de volgende werkdag goedgekeurd. De device is dus niet meteen operationeel.
Voor zover ik weet kun je inderdaad zo vaak als je wilt een ABP join doen. Echter adviseren wij om OTAA te gebruiken vanwege de beveiligingsredenen. OTAA voor de Developer Portal wordt niet automatisch doorgezet / aangemaakt. Er zit nog een kleine controle op die overdag doordeweeks plaats vindt. Een OTAA registratie in de nacht wordt de volgende werkdag goedgekeurd. De device is dus niet meteen operationeel.
Hi @JeroenD , voor de developer portal worden de OTAA's niet automatisch verwerkt en registreren we deze dagelijks handmatig. Ik zie dat op 5 maart om 09:30 uur een OTAA aanmelding van jou is verwerkt.
Echter, wat mij op valt is dat jouw Dev EUI al door iemand anders in gebruik is, dat gaat niet werken. Je zult een unieke Dev EUI nodig hebben. De App EUI voor OTAA heb je wel helemaal goed. 🙂
Echter, wat mij op valt is dat jouw Dev EUI al door iemand anders in gebruik is, dat gaat niet werken. Je zult een unieke Dev EUI nodig hebben. De App EUI voor OTAA heb je wel helemaal goed. 🙂
Zie je enige activiteiteit op mijn device met naam "Test-OTAA"? Kan jij of iemand anders bij KPN mij helpen?
Vriendelijke groet, Jeroen
Dag Jeroen, uiteraard helpen we graag!
Jouw device "Test-OTAA" is geregistreerd en staat actief. Er is echter nog geen activiteit geweest, voor zover ik zie staan de counters nog op 0. Het lijkt erop dat de device nog geen bericht heeft verzonden?
Een volgende stap als het niet werkt is om bijvoorbeeld even een simpele Hookbin endpoint toe te wijzen aan je device. De hookbin endpoints werken namelijk altijd en moet de inhoud van de post weergeven. Als dat ook niet werkt, gaat er iets mis aan de kant van je device. Mocht het wel werken, doet jouw application server iets verkeerd. Op die manier kun je factoren verder uitsluiten en komen we er hopelijk achter waar de oorzaak van het probleem zit.
Jouw device "Test-OTAA" is geregistreerd en staat actief. Er is echter nog geen activiteit geweest, voor zover ik zie staan de counters nog op 0. Het lijkt erop dat de device nog geen bericht heeft verzonden?
Een volgende stap als het niet werkt is om bijvoorbeeld even een simpele Hookbin endpoint toe te wijzen aan je device. De hookbin endpoints werken namelijk altijd en moet de inhoud van de post weergeven. Als dat ook niet werkt, gaat er iets mis aan de kant van je device. Mocht het wel werken, doet jouw application server iets verkeerd. Op die manier kun je factoren verder uitsluiten en komen we er hopelijk achter waar de oorzaak van het probleem zit.
Ik stuur als test 6x per uur een bericht. Soms komen er 6 aan, vaker zijn het er minder. De SF is elke keer 7. Zijn er mogelijkheden om de betrouwbaarheid te verhogen door de SF te verhogen? Enig idee hoe dat dan moet?
Wat is er anders als ik sleutels koop? Biedt KPN zelf ook sleutels aan, of gaat dit altijd via een partner? Ik neem aan dat DevEUI en AppKey nog steeds vrij te kiezen zijn, maar de AppEUI ook? Kan de backend van KPN nog steeds de decryptie doen, of moet mijn eigen server dat doen? Ik wil graag sleutels in mijn microcontroller zetten, die wellicht nog een tijdje "op de plank liggen". Is het mogelijk om pas te gaan betalen na eerste contact met het netwerk?
Dag @JeroenD ,
Er is een kleine kans, die ik klein acht, dat je maximale berichten per uur erdoor zijn. Voor de developer portal hebben we momenteel een limiet van 3 downlinks per uur. Ik durf alleen niet te zeggen hoe die limiet wordt gehanteerd. Wellicht wel iets om rekening mee te houden. Als voor een bepaalde toepassing meer berichten gewenst zijn, kunnen we dat altijd voor je bekijken.
Voor de spreading factor zou je kunnen spelen met de Adaptive Data Rate (ADR). Het is ook mogelijk om een vaste spreading factor te kiezen. Dat kun je vanuit je device bepalen.
We werken samen met een reseller, Simpoint, voornamelijk voor afname van een kleine hoeveelheid keys. De ondersteuning bij storingen en vragen wordt verzorgt door Simpoint. Het is ook mogelijk om keys rechtstreeks van KPN te nemen, wij hanteren andere tarieven en opstartkosten.
De AppEUI wordt door KPN geleverd, zoals deze ook voor de developer portal vast staat. Decryptie is aanwezig en kun je hier meer over lezen.
Voor het afnemen van keys en afspraken daarover moet ik je doorverwijzen naar mijn collega's die daarover gaan bij Simpoint of KPN. Ik vermoed dat je de keys eerder ontvangt dan het contract in gaat, maar dat is vast enkel een kwestie van dagen. Daar is de developer portal natuurlijk ook een beetje voor bedacht, je kunt over wanneer je er klaar voor bent! 😉
Er is een kleine kans, die ik klein acht, dat je maximale berichten per uur erdoor zijn. Voor de developer portal hebben we momenteel een limiet van 3 downlinks per uur. Ik durf alleen niet te zeggen hoe die limiet wordt gehanteerd. Wellicht wel iets om rekening mee te houden. Als voor een bepaalde toepassing meer berichten gewenst zijn, kunnen we dat altijd voor je bekijken.
Voor de spreading factor zou je kunnen spelen met de Adaptive Data Rate (ADR). Het is ook mogelijk om een vaste spreading factor te kiezen. Dat kun je vanuit je device bepalen.
We werken samen met een reseller, Simpoint, voornamelijk voor afname van een kleine hoeveelheid keys. De ondersteuning bij storingen en vragen wordt verzorgt door Simpoint. Het is ook mogelijk om keys rechtstreeks van KPN te nemen, wij hanteren andere tarieven en opstartkosten.
De AppEUI wordt door KPN geleverd, zoals deze ook voor de developer portal vast staat. Decryptie is aanwezig en kun je hier meer over lezen.
Voor het afnemen van keys en afspraken daarover moet ik je doorverwijzen naar mijn collega's die daarover gaan bij Simpoint of KPN. Ik vermoed dat je de keys eerder ontvangt dan het contract in gaat, maar dat is vast enkel een kwestie van dagen. Daar is de developer portal natuurlijk ook een beetje voor bedacht, je kunt over wanneer je er klaar voor bent! 😉
Hi @JeroenD , dat is een realistisch aantal. Ik heb je downlinks gezet op 6 per uur. Veel succes! 😃
Heb je tips hoe ik het aantal gemiste berichten (uplinks) kan verminderen? Zoals gezegd is de SF van de berichten die aankomen altijd 7, dus ik verwacht dat ik goed bereik heb naar de LoRaWan gateway.
Groet, Jeroen
Dag @JeroenD , bij mijn weten zit er geen beperking op uplinks, behalve de duty cycle waar iedereen zich aan moet houden. Dat er veel uplinks ontbreken kan inderdaad te maken hebben met het bereik. Een idee is om de SF vast in te stellen op 12, zodat deze op de meest efficiënte manier wordt verstuurd. Als de SF altijd op 7 staat heb je dat zo ingesteld of is het bereik inderdaad gewoon prima.
Reageer
Meld je aan
Heb je al een account? Inloggen
Welkom
Nog geen account? Maak een account aan
Inloggen of registreren met sociaal netwerk
Inloggen met Facebook Login with LinkedInof
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.