Updating the settings will not work. You will need to delete the device and create a new one. At creation you need to fill in the advance settings. (changing them afterwards didn’t work for me)
If done as in my settings overview (previous post) you should get the result as also posted. For me this works with TinyLora on a STM32 device + RFM95.
Why would you use such an incomplete stack on an STM32? On an ATmega I could see (if disagree with) the argument, but on an STM32?
Good t know. I will try it. But this is actually very bad 
why allow users to update device parameters when they cannot be put in effect. I presume this is a bug (defect) that shall be repaired.
Why would you use such an incomplete stack on an STM32? On an ATmega I could see (if disagree with) the argument, but on an STM32?
This is for testing only…
Only just recently I switched over to the STM32L051 family but I have still many old devices (Atmega’s and evem Attiny84’s). They all work perfectly and some of them are running already 3 years continuesly on 1 battery (eg in the freezer, doors, PIR’s, moistsensors for plants, mailbox etc 
).
I don’t want to scrap them because they are limited in memory or old. For what they need to do they are perfect.
But going forward I will use the STM32 and a more complete stack but I want to keep my old devices running.
That’s a nice architecture, but probably worth going for the pin compatible STM32L07x series as most using them for LoRaWan and similar are, to have a little more elbow room than the L051’s.
Good afternoon
I have a bit of a silly question, I’m not sure if what I’ve done has worked or not. I’ve followed the guidance in this forum post to create a new device in the v3 console, and I get the same live data as @rvdvoort , which leads me to believe that it it is working (even though it seems to be scheduling downlinks):
However, the downlink counter is incrementing on every uplink:
Is this correct or have I messed something up?
Thank you!
Seems to look ok for me.
A standard downlink will always be scheduled after an uplink as this is part of the Lorawan standard (at least that is how I understand it). I don’t think that this downlink can be disabled.
Ah right ok, thanks for clearing that up!
While the receive windows for possible downlinks do indeed follow directly after an uplink such that a node needs to listen for responses there, in terms of healthy network operation an uplink should “hardly ever” trigger a downlink.
If it’s regularly doing so, something is wrong. Either the node is unwisely sending confirmed uplinks (the acks for which will rapidly burn through the airtime allowance), or there’s a “disagreement” between the network and node about state.
That’s what we’re seeing in this case - the network is sending a device status query, and the device is not answering (because it doesn’t know how to even receive that) so it’s being sent over and over.
This is an unhealthy situation that needs to be understood and corrected.
Oh ok. What steps would you suggest I take to figure out the issue?
Thanks!
That’s the tough part!
Officially, you should fully implement LoRaWan with working downlink and functional MAC command parsing.
Or you could de-power the device until they maybe get a “disable MAC” feature implemented. Or at least put some sanity limits on server effort-per-node.
Otherwise there’s not much choice… maybe you can find a magic combination of settings which fools the server, but at the end of the day this isn’t really part of the apparent plan for V3. (a plan which, like a number of details of the LoRaWan spec itself, I am explaining rather than endorsing)
In that case I suppose I will wait a while to see if disabling MAC becomes available at some point.
Thanks again!
Let me say again that you should not be doing this. The Things Network is trying to grow up and become more mature. Using non-compliant devices does not contribute to that.
@rvdvoort is right. If you tell the Network Server that the device uses an RX1 delay of 1 second, it will try and change that to 5 seconds with a MAC command. If you want to prevent the Network Server from sending these MAC commands, you’ll have to tell the Network Server that the device already uses 5 seconds (even though that’s not actually true).
So:
@bru even if we would decide to allow an option to disable the MAC layer, it’s not going to be a priority. The core team spends its time on supporting actual LoRaWAN devices. There were some concerns about these devices having a noticable impact on the downlink budget of gateways, which would justify adding this. However, from what we can deduct from our telemetry, these non-compliant devices actually make up only a small fraction of devices on the network, and would only impact a small number of gateways.
With the command-line interface, you can already tell the Network Server to send these device status requests less often. The flags for that are --mac-settings.status-count-periodicity and --mac-settings.status-time-periodicity.
My node is a single Arduino Pro Mini with an RFM95 set up as an air quality monitor. It runs on solar energy so it needs to consume as little power as possible, which is why I set it up using ABP, to reduce the number of transmissions needed. Sometimes the battery runs out and the device resets, which is why frame counter checks are disabled.
Up until now I had been using TinyLoRa. The only other LoRaWAN library I know of is LMIC, which doesn’t fit in the board’s memory alongside the rest of the libraries for the sensors.
How do you suggest I proceed?
Thanks!
They’re probably going to impact those particular gateways heavily though.
But perhaps those are effectively private gateways covering isolated experiments or deployments.
Overall, in working on a custom server stack, something that’s been constantly in mind is sanity limiting, or as we sometimes call it in discussions “spam filtering” in the sense of not being willing to expend bandwidth responding to buggy behavior (though of course we also want to notice and source correct the bugs!)
To that end, while a “disable” setting would be great, I wonder if what might be most beneficial overall would be to actually build an enforcement mechanism for per-node downlink airtime, and to have warnings/violations visible/reported on device status. Perhaps almost to the level of uplink metadata including an allowed utilization percentage - because after all the real goal (in terms of intended downlinks, not accidental ones) is to get people to design away from patterns of excessive usage, rather than to literally cut it off at the point it exceeds a limit. Especially because something like a node abusively using confirmed uplink is going to keep spamming the uplink if it’s not getting replies.
Probably the best thing to do would be to move to a different board - the ATmega4809 (aka “Nano Every”) might be the lowest effort port, but a lot of ARM based Arduinos and Arduino-likes may give you the most options.
There are also integrated-stack coprocessor solutions, eg as used on the Things Not-Any-Sort-Of-Uno.
So if we set this flag for example to 1000 than there will only be once every 1000 uplinks a device status request.
If correct than the discussion about “violating” the downlink airtime becomes a non-issue.
Is there somewhere a clear guide or example of how to set this flag. The provided documentation on the website is not very clear (at least not for me 
)
After some try-ing out I was able to create a new device with the CLI using the “mac-settings.status-count-periodicity” set to 1000. That didn’t help with reducing the device status requests. I still get for every uplink a downlink status request.
Is this a “bug” or am I missing something. 
Below is the response of the CLI and ahow the new node is created.
I suppose that he request again after 1000 uplinks but it seems that you have to answer in first uplink. If not, it will keep try?
What if we send a device status answer every 10 uplinks?
