But then is there a document that specifies the explanation you gave earlier about the GW details and LinkCheck command? 
would still be lovely!
Seems to be the best option - I wasn’t really expecting all the MAC stuff in the web hook / MQTT feed, but I haven’t dug in to the newer releases on the integration side of late.
Not sure about the GW details you mean - the gateway console shows what it was told to do which will link up with the device console - hence all those loverly correlation-ids.
As for the MAC commands, this is like going to the dark side so you can be a better Jedi - try to maintain a connection with reality. I’d start out with v1.0.3 and see the differences that come with v1.0.4 (mostly the join nonce). Don’t go to v1.1 as it’s not really in circulation much:
The main page, is for v1.0.4 which splits the spec in to three documents → LoRaWAN for Developers - LoRa Alliance®
There are various support organisations you can contact if you find yourself struggling with the content but most of them seem to involve heavy drinking to try to forget …
Milesight followed up:
“(…) The fair use policy is mainly used on TTN community version and we did not hear from this problem on other platform. We can provide OEM service to disable rejoin mode before ship if you have a big order.”
WTF - so “we will ship an antisocial spectrum hogging, GW capacity wasting, LNS resource hogging device by default unless some one pays”! Get Real Milesight/Ursalink! At least make the setting user configurable!
Paging TTI Core team to take this up with the vendor?! @adrianmares @KrishnaIyerEaswaran2 @johan
To be clear: it is user configurable per device using their Toolbox app, but Rejoin Mode is enabled by default.
From the manual (https://resource.milesight-iot.com/milesight/document/am103&am103l-user-guide-en.pdf):
“Go to Device > Settings > LoRaWAN Settings of ToolBox App to configure join type, App EUI, AppKey and other information. You can also keep all settings by default.”
Ok , thanks for clarifying - panic over! 
That additional info makes a huge difference. Its not unlike the original RS1xx family from Laird - their default protocol needed an initial time synch and forced confirmed uplinks - not TTN (or Spectrum) friendly, then they quickly adopted and adapted to allow for unconfirmed options etc.It’s now a user selection over BT during set up…
As with the Laird unit guess we need to highlight to AM103 users that they should not just blindly accept defaults
1 Like
@Ichthus_College_Info Hi Steven,
I have the Milesight AM103 in place also on TTN. Normally a Milesight sensor can be password protected for NFC.
Nice to see that Airteq (Dutch company) is selling these as stand alone and not connected to a lorawan network. If you would, you can have a lot of historical data. And based on that, school can take proper actions.
But, Ichtus college is in Veenendaal. I live in Venray. Maybe get in touch? you can have the data enter nicely via TTN in a dashboard that is developed and maintained by your ICT students themselves. I can’t do this myself and use Datacake for this.
So. feel free to email me at < redacted >. I’m happy to help
Marc
PS,
I have given guest lessons at various schools about Lorawan and at ROC in Venray they have started Lorawan themselves
Hi Marc, thanks for your reply!
Luckily, I have some LoRaWAN / TTN experience already thanks to my WIP project www.meetjeleefomgeving.nl which is launching officially 31st of May with two updates planned still (and a slightly outdated website).
I will soon be hooking up all 90 AM103s to TTN and still need somewhat of a dashboard for housekeeping to monitor ventilation etc. Could be done by students as well indeed!
If need be, I’ll know where to find you, thanks
Hi Steven,
perfect. Lorawan is than an easy way to deploy wireless sensors in a school building. 1 or 2 gateways and of you go.
One question: did you buy CO2 sensors because of the Dutch regulations for CO2 in schools?
Marc
Yes we did! And it coincided with research towards ventilation in our school.
meten = weten inderdaad
for our EN friends… but that doesn’t sounds so nice
measuring is knowing
1 Like
@MarcVanBracht, forum policy is to post in English - you can add the same content again in any language that the moderators can translate if you wish. Please edit your post accordingly and given the frequency that Google indexes this site, do not include your email address - send it via private message.
done. sorry for this inconvenius
1 Like
Updated the CO2 sensor a little over 24 hours ago such that it doesn’t send anymore LinkCheckReq uplinks.
Number of downlinks is still a little on the high side…
@descartes does this align with your observations wrt no. of uplinks? I could leave a console running for a couple of hours again.
Or is this behaviour decent for an ADR enabled device?
Seems a bit much - but about what I normally get - a few uplinks, then a couple of downlinks saying they are to set Rx1, then all quiet for a few more hours, rinse, repeat.
As the test device I started on Monday dropped straight down to DR5 power level 2 within the first few minutes and wasn’t moved, I can’t see why it would need further downlinks.
I’ll trawl through the JSON console captures this evening to see if I can learn more.
I’ll leave a fresh console open for a couple of hours to see if I can catch one or more downlinks. Will let you know if there’s anything apart from ADR stuff.
This device is only two floors and a couple meters separated from the antenna, meaning that it also immediately took a dive down to DR5.
There shouldn’t be any ADR stuff - if it’s not moved and given the close proximity of device & antenna and it’s been set, I’m hard pressed to understand why there should be more downlinks.
Perhaps @Jeff-UK or @kersing who are gateway masters could comment …
Gateways are not an active component in the ADR stuff. A node and the LNS are. Gateways are just dumb media convertors (to quote someone) 
1 Like