i think we all have to calm down a little.
i dont like nodes that cant handle the complete protocol or at least most of it
and i think a ATTiny84 cant handle that. but it is only my honest opinion
if the ATTiny84 can do it great but if not be open for other platforms.
I love it!
I can appreciate the do-it-yourself route that is taken during this project, you probably learned a lot along the way.
I also have some sensors running based on the attiny84a + RFM95W combination. Maybe I will change the setup in the future, but for now I prefer it because:
Of course there are more powerful uC available, I will probably thinker with them in the future (I already have a project planned), but the restricted space on the attiny family also forces you to program more efficient which triggers my interest.
Iām eager to learn more, especially about the fact that my sensors are maybe not well-behaving according to the specifications (I simply donāt know?). Looking at the responses above it is clear that people have something to say about this kind of combination, but Iām missing clear violations and Iām also missing help and information about how to overcome this (Iām under the impression that this should be the goal of a forum, but maybe Iām wrong).
So for the experts above, can you shine some light on:
Bear in mind: Iām not a professional, Iām just tinkering with it in my spare time.
First of all, as an intellectual exercise and an example of low resource programming this is a very nice project. However for a fully compliant LoRaWAN node it is not efficient.
Regarding your points:
Keep tinkering by all means. Invest your time in whatever you want as it is yours to invest. But please keep an open mind about the limitations. (And I know some of those limitations make the challenge interesting)
A question because I am curious about your choice: have you ever checked the available cheap Arm based controllers or is the ATTiny just a default you know well?
Thank you for your reply.
If I understand correctly, for my use case (hobby projects) it is not obligated to receive (and process) the MAC commands. I should of course be careful about the messages I send (spreading factor, transmission power, duty cycle) and should respect the 868 MHz band rules and the TTN Fair Access Policy. In my use case (SF7, low transmission power and duty cycle below 0.001 %) I think Iām in the clear. Or should I still be worried?
A good remark is that the device will not have LoRaWAN certification, but if I understand correctly, certification is not mandatory for TTN? If so, this should not be stated as a problem but can certainly be noted as a remark when it is reasonable that the project will be used commercially.
Regarding the receiving part, reading posts from this forum I conclude it is possible to receive and process the MAC commands with an attiny8x + rfm95w combination (link). You said before that this combination of hardware will never be compliant. I assume that you probably meant never be certified instead of compliant (because you say compliant specification does not explicitly state receiving/processing MAC commands to be mandatory). But when receiving and processing of MAC commands are implemented, why should it still fail certification? Can you shine some light on that?
It is confusing to read such a resistance against a project like this. I can understand that it is maybe not the approach other people would prefer, but that doesnāt mean it is wrong and cannot be tweaked to something that is right without using other hardware. I think it is good the keep an open mind about different use cases and levels of skills. Not everyone is building a commercially device in high volumes, a lot of people are trying to learn something here.
I actually started tinkering with Raspberry Piās (not with LoRa at the time), but after some time I thought, thatās quite some overhead, running a full OS, to control some simple electronics. That was the start to first learn about some Arduino stuff and later a dive into bare attiny chips. Which are, funny enough, for a lot of small projects still overkill. And now I am used to the Atmel chips and those are lying around here and I also use them for other projects.
You say this node is not efficient, āefficientā can be interpreted in several ways. I think the combination is quite efficient regarding power, size and costs, but maybe not the most efficient looking at the full development process. But yeah, buying an off-the-shelf node would then be the most efficient, but where is the fun in that? 
But still, if you know a module with better specs (size, power consumption) without being more expensive, I would love to know.
Receiving LoRaWAN messages was already something on my learning list, not necessarily for processing MAC commands but primarily for other things. I will certainly dive into the specifics of that in the future. Looking at this conversation and multiple other posts at this forum, I think an open conversation about the development of this kind of nodes is a positive thing.
@koenn As far as I am aware, you should take care that your device does at least the following:
Regarding the receiving part, reading posts from this forum I conclude it is possible to receive and process the MAC commnds with an attiny8x + rfm95w combination
No, itās not really possible to implement proper bidirectional LoRaWAN - especially not when leaving program space for the node to do anything meaningful with sensors. People whoāve not been up to their elbows in the details simply do not understand the complexity, period.
You said before that this combination of hardware will never be compliant.
Indeed, it will not be
It is confusing to read such a resistance against a project like this.
The only thing that is confusing is why people like you are so ignorantly determined to continue wasting time and money on something that can never work right, when there are so many alternatives MCUs that are easier to work with, physically as small and low power, inexpensive, and have memory room to grow to full compliance.
Receiving LoRaWAN messages was already something on my learning list, not necessarily for processing MAC commands but primarily for other things. I will certainly dive into the specifics of that in the future. Looking at this conversation and multiple other posts at this forum, I think an open conversation about the development of this kind of nodes is a positive thing.
Such learning goals are precisely why you need to cease wasting time with an ATtiny and switch to a chip with enough memory to support these goals.
You donāt buy a growing child shoes that are already too small.
@cslorabox @koenn We have a LoRa implementation consisting of ATtiny85 + RFM95 with 8 channels, all datarates, full bidirectional communication, ABP or OTAA and support for a pretty decent subset of MAC commands.
The only thing which is really limiting is the IO on the ATtiny. If you implement a full SPI interface with the RFM, thereās not much IO left for a sensor. But as a small size and really cheap geotracker or for detecting some on/off signal it works great.
@koenn, the LoRaWAN standard prescribes that all devices (and also all gateways) should at least support those 3 basic channels: 868.10 / 868.30 / 868.50
As to your last paragraph, I donāt follow the reasoning that a fixed channel device uses lower bandwidth. In my opinion it makes no difference. However, a fixed channel device puts an unbalanced load on the frequency spectrum as a whole (i.e. only one channel) therefore I would say such devices are unwanted.
Posts shall not contain only links, which holds even stronger for topic start posts.
Your start post contains only a link but no description. As a result it is not clear what the link is about (without first clicking it) and worse it is unclear why you are posting it, which invites to any random responses - including critical ones - wasting other peopleās time and efforts and leading to nothing.
RFM95 is a LoRa radio that itself does not support the LoRaWAN protocol. The LoRaWAN protocol stack software therefore needs to run on the microcontroller. Only few public LoRaWAN compliant libraries are available and they are too large to fit on an ATTiny84 (were not designed for that).
That software is closed source and was developed commercially, investing much time. The source code is not publicly available. The IoT space and LoRaWAN have matured since then and more capable hardware and software solutions are currently publicly available. It is therefore not wise to use ATTiny for development of new LoRaWAN devices.
The TinyLoRa device appears to be able to transmit / send LoRaWAN uplink messages only - which is only a part of the LoRaWAN protocol - and without capabilities to handle downlink (control) messages.
Devices that are able to transmit only are NOT LoRaWAN compliant and are therefore NOT supported on the forum (similar to āsingle-channelā devices and LoRa-only devices).
My 2Ā¢: The RFM95 module alone is much more expensive than ATTiny84 and many microcontroller(board)s that are more capable than the ATTiny84. Add to that the price of the sensors. So from price perspective I personally do not really understand why to save (less than) ā¬0.75 on a microcontroller(board) and then spend a lot of time and hassle to get LoRaWAN (somewhat) working on ATTiny.
The contents in this thread has moved way off-topic and appears to lead to nothing but discussions, even behavior not tolerated on the forum.
To quote @TwentySixerās undiplomatic statement
I will now end above discussions.