Beantwoord

Lora https endpoint

  • 11 January 2023
  • 28 reacties
  • 362 keer bekeken

Hallo,

Sinds 10 januari na 13:25 lijkt het formaat van de data wat naar het HTTP endpoint gaat gewijzigd, 
voor die tijd zag het er zo uit:
[{"bn":"urn:dev:DEVEUI:....:","bt":1.667058215E9},{"n":"payload","vs":"....."},{"n":"port","v":2.0},{"n":"TIME_ORIGIN","vs":"THINGSENGINE"}]
na die tijd:
[{"bn":"urn:dev:DEVEUI:....:","bt":1.673357143769e9,"n":"payload","vs":"...."},{"n":"port","v":2.0},{"n":"timeOrigin","vs":"NETWORK"}]
Geen probleem, programmatuur aangepast waardoor het weer werkte. 

Elk half uur stuur ik data door maar tot mijn verbazing zie ik tussen 10-1-2023  13:25 en nu (11-1-2023 21:50) dat er zes keer toch weer data wordt verstuurd in het 'oude' formaat.
Hoor graag hoe dat mogelijk is :-)

Met vriendelijke groet,
Frans
 

icon

Beste antwoord door Rick S. 24 January 2023, 09:39

Bekijk origineel

28 reacties

Reputatie 7
Badge +6

Hey Filip,


I have previously raised this issue with our specialists and they indicated that further investigation should be done. However, at that time there were other matters with a higher priority. I can't say what the situation is now. I retransmitted the issue. If I get feedback, I will of course get back to you.

Hi Rick, any news from the specialists yet? It’s been another week now and we’ve been missing quite some data that we have to put significant effort into getting it to our platform another way.

 

Reputatie 7
Badge +6

Hey @adekam

Thanks for the message!
I understand that the second update to the network was completed this week. So it should work fine now and you shouldn't see any difference in the messages anymore.

@Rick S.  Can confirm, thanks for the updates.

Reputatie 7
Badge +6

Goodmorning @adekam,

Great to hear, thank you! 
If you have any other questions, feel free to create a new topic. 

Badge

Het oude formaat was geen correcte senml. Het Nieuwe is dat wel. Dat er af en toe nog wat oude formaten verschijnen is inderdaad raar. Ik heb zelf bij aanvang de parser aangepast zodat ie de foute syntax wel begrijpt. Dat hou ik er nog een tijdje in dus. Het Nieuwe formaat zou elke goede senml parser moeten snappen.

Hi Rick,

 

We have just ran into this problem ourselves. Sometimes a device reports as expected (the expected json object) while sometimes it reports the full payload in hex format.

 

Best,

Filip

Ha Joost, dank voor je reactie.
Zal ook e.e.a. aan moeten passen zodat het oude formaat nog herkent wordt, vanochtend om 11:00 zat er weer een misser tussen :-(  Inderdaad vreemd dat zoiets blijft gebeuren.

Frans


 

...in de laatste 24 uur weer 8 missers, het lijkt zelf toe te nemen :-(
Ben ik de enige die daar last van heeft??

Reputatie 7
Badge +6

Goedemorgen @FransP,

Toen ik het topic tegen kwam ben ik dit ook na gaan vragen bij de specialisten. Ik kreeg de volgende terugkoppeling: 

Als de destination onbereikbaar is geweest kan het zo zijn dat het tot 24 uur later afgeleverd wordt. Dat zou dan zijn gestart in de legacy tak en dan 24 uur later daar ook worden afgehandeld. Op 10 januari is de nieuwe FlowEngine live gezet, dus dat lijkt overeen te komen. Meer informatie over de wijziging is te vinden op de Upcoming changes in KPN SenML pagina. 

Hallo Rick S. ,

Dank voor je reactie.

De destination is niet offline geweest en ook nu gaat het nog regelmatig mis, van de laatste drie dagen heb ik even de tijden erbij gezocht waarbij ik verkeerde formaat binnenkreeg:
14/01/2023 14:28:27 , 14/01/2023 16:28:31 , 14/01/2023 16:58:32 , 15/01/2023 05:28:53 , 15/01/2023 06:28:54 , 15/01/2023 06:58:55 , 15/01/2023 17:29:13 , 15/01/2023 19:29:16 , 15/01/2023 22:29:21 , 16/01/2023 03:29:30 , 16/01/2023 09:59:41 , 16/01/2023 12:59:46 , 16/01/2023 19:29:57 , 16/01/2023 21:30:00 , 17/01/2023 01:30:07

Elk half uur stuur ik meetgegeven door en meestal gaat het dus goed :-)  De parser heb ik aangepast zodat deze met beide formaten overweg kan maar ergens gaat er dus iets mis lijkt me.

Met vriendelijke groet,
Frans

Reputatie 7
Badge +6

Goedemorgen Frans, 

Ik heb inmiddels weer een terugkoppeling gekregen van de specialisten en er blijkt inderdaad wat mis te gaan. Er wordt op dit moment bij elk bericht van een device een nieuwe flow gegenereerd en opgeslagen. Wanneer er ongeveer tegelijkertijd een locatie-bericht en een payload-bericht binnenkomen (wat gebruikelijk is) ontstaat er een zogeheten race-conditie. Als de payload als eerst wordt verwerkt, gaat de payload SenML in de nieuwe opmaak en de locatie in het oude formaat. Als het locatie-bericht eerder is gaat het andersom. De reden hiervoor is dat de flow tegelijkertijd wordt geüpdatet, wat niet mag en waardoor er een exception optreedt. Gelukkig is dit nu boven water en wordt er gewerkt aan een oplossing. 

Hallo Rick S.,

Goed te horen dat de oorzaak gevonden is.
Sinds gistermiddag 12:05 zie ik het ook niet meer fout gaan, het lijkt dus opgelost te zijn.

Bedankt weer voor het uitzoeken en met vriendelijke groet,
Frans

 

...helaas het gaat nog steeds fout 😒

Reputatie 7
Badge +6

Hey Filip, 

Thanks for your patience! 
I understand that my colleagues are going to research this issue further next week. So hopefully I can give a substantive update on the issue and the solution next week

Hi Rick,

 

Thanks! 

...en nog steeds niet goed, het lijkt een lastig probleem 😏

Reputatie 7
Badge +6

Goedemorgen Frans, 

Excuses voor de late reactie! 
Na het laatste bericht van de specialisten heb ik (nog) niet de bevestiging gekregen dat het opgelost is, dus fijn dat je het meld. Ik ga er van uit dat het nog in behandeling is (ook al had ik eerlijk gezegd ook al de oplossing verwacht). Natuurlijk geef ik dit signaal weer door.

Reputatie 7
Badge +6

Goedemorgen Frans, 

Na het navragen bleek mijn vermoeden correct. De fix is nog niet helemaal geïmplementeerd. Bij deze fix werden er direct nog wat andere zaken meegenomen, waardoor het wat tijd nodig heeft. Het gaat nu echter niet lang meer duren. Als het goed is krijg ik ook nog een berichtje als het zo ver is. 

Reputatie 7
Badge +6

Good afternoon everyone,

I have been in contact with the specialists again and I understand that a definitive solution has now been found for this problem. This will roll out with 2 updates on the network. The first has already been done and the second will follow soon. Soon this problem will no longer occur.

Dag Rik,
Ik haak maar even aan in dit topic. Heb je al meer zicht wanneer de fix er is?
Naast het feit dat de request body anders is geformeerd, zijn ook de headers anders van de twee requests.
Zo was de “content-type” header altijd gedefineerd, en is dat in de nieuwe structuur niet meer zo.

 

Reputatie 7
Badge +6

Goedemorgen @adekam,

Geen probleem om aan te haken hoor!
Ik ben er weer even achteraan gegaan en ik heb begrepen dat de fix sinds 21-02 geïmplementeerd is.  De berichten zouden nu dus alleen in de nieuwe opmaak verwerkt moeten worden. 

Als je dit niet zo ervaart of tegen andere zaken aanloopt hoor ik het graag en gaan we het natuurlijk verder onderzoeken. 

Bij ons geeft het inderdaad problemen sinds 21-02, omdat in de nieuwe opmaak de header “content-type”:”application/json” niet meer standaard mee wordt gegeven. Dit is soms wel / soms niet het geval, en de webhook waar wij mee werken interpreteert de data dan als 1 hex waarde waardoor onze parser faalt.

Ik zou er wat dieper in moeten duiken hoe vaak het wel / niet goed gaat. Maar zo op eerste inspectie lijkt het dat de locatieberichten wel die header meegeven, maar de payload maar een enkele keer, en de body is dan nog in de oude opmaak.

Hallo Rick,

Bij mij zie ik het nog dagelijks 1 of meerdere keren fout gaan, na 21-2 geen verbetering dus.

Groet,
Frans

Reputatie 7
Badge +6

Goedemiddag @adekam & @FransP,

Na jullie reacties van donderdag heb ik dit signaal gelijk doorgezet naar de specialisten. Ik kreeg vanochtend de reactie dat zij dit weer verder willen gaan onderzoeken. Het is alleen op dit moment niet duidelijk wanneer dit afgerond kan worden i.v.m. meerdere projecten. 

Reageer