Thanks for all the great reply’s guys! I’m currently looking into all the stuff you guys proposed.
I have created a protoype with the Arduino nano 33 / i2c LCD / DHT22 / RFM 95 This seems to work great for now.
If i am going to do this on a larger scale i will have to take a look at all the hardware and see which fits my needs best.
Good tips. I’ve been working on the same project.
MKR1310 WAN is an easy one device. All the sensor stuff is a different question.
@descartes: You are spot on with your comment whether it’s for 10 or 10.000pcs.
Also: is it a (semi)professional or industrial application?
The user-case would dictate the components to use, for both the Transceiver/mcu part and for the sensor side.
Personally I wouldn’t use an Arduino for an industrial application, but a Miromico module. They are available with STM, Renesas and Maxim microcontrollers.
Also I like the Renesas/IDT HS3001 for temperature and humidity. It’s very accurate and extremely stable over time.
Being stable would eliminate the need for an annual calibration 
@LouThings I am not sure about the DHT22. We are requiring a precision of 0.4 degrees C and 2% humidity. It looks to be quite stable compared to the sensors we have installed right now. A initial calibration will tell if it is working over the range.
The calibration is mandatory for our procedures. Even if the device is extremely stable.
I am currently evaluating the Hardware we could use, it needs to be friendly priced. But also the size of the total package needs to be taken into a count.
Our usecase, provided that the prototype is successful is to use it in about 100 locations. Arduino seems an easy way to go since im familiar with the code.
You should probably look at ARM based platforms not ATmega based ones. The 32u4 should be crossed right off the list due to limited memory resources, the nano every might barely survive but still doesn’t offer much advantage since the radio doesn’t share its wide voltage range.
It’s not clear that there’s currently any TTN V3 compatible codebase maintained for either of those.
More importantly, consider the initial board only a proof-of-concept since you’d probably move to placing the same processor and radio module on your own with the needed sensor.
So for example, look at the Feather M0 LoRa, but price it in terms of the constituent parts.
Arduino seems an easy way to go since im familiar with the code.
Arduino tends to make it easy to get started but then a real nightmare later since it insists on doing absolutely everything in a way that is both non-standard and truly terrible in terms of software development practice.
Fortunately there is the option of later going to a non-Arduino codebase on the same hardware.
RM186 + custom PCB + Si7021 about € 25. Needs an uFl connected antenna and power source.
Uses SmartBasic, easy to learn but not Arduino.
Pre: certified LoRaWAN stack which your code can’t mess up. (Ok, there are ways if you search real well) no need to use LMIC…
Like Murata, not available anywhere for months, which may also impact on the Arduino MkrWAN (Murata).
Beginning to run out of options at present …
So id better go for this one: Feather M0 Radio with LoRa Radio Module
Would it be a good idea to design our own PCB eventually? How would we go about in doing that? As i have no experience with anything like that.
At least 25 available for immediate shipment. And a couple of hundred in the second half April.
The Pros of the RM186 & the Arduino MRK WAN is that you don’t need to get involved in the radio software - you just send commands and a sub-module “just does it”.
The Feather requires you use software that is fully supported and comes with many instructions. But still requires a good number of people to ask questions here on how to set it all up, most of the time we end up pointing them at the line in the instructions they missed. Because your code will co-exist with the radio software, you have to be reasonably careful that you leave it to do it’s work when you require it - so ambitions to read sensors WHILST the device is trying to do the LoRaWAN bit is harder than hard on a hard day.
If you are amenable to being helped, I have no problem with the Feather - I have one on my desk in front of me pushing packets to a test v3 stack I setup. I wanted to add a push button to send on demand which took a couple of minutes to add in. So it can be a productive environment.
I think I may have emailed you already. But basically you find someone who’s already built stuff so you don’t get charged for re-inventing the wheel. One hundred is a small batch but unless you have some exotic requirements that aren’t already pre-prepared, will compare well with the Feather. It will also allow some flexibility on what components to use depending on the state of supply. It’s anticipated that the crystal oscillator factory that burnt down will be operational May/June but it will still take time for the radio manufacturers to get hold of supplies and make more boards.
I bought the Feather 32u4 to test its functionality and got it to work fairly easily. I haven’t yet tried to connect the sensor and a screen to it, that might end up being a headache.
I am still awaiting your email, or I have missed it!
I am still looking at the most reliable way to go, obviously id prefer a PCB that has all the equipment build in already.
Which hardware would I have to use to use the TTN library instead of the LMIC?
Just remembering a lesson of a while ago.
A hundred is a horrible number.
It feels too small to want to shop for and setup a fully automated solution, so you decide that you’ll do X, Y, and Z beyond the basic machine-populated PCB yourself.
That then turns into long all-hands “work parties” because even 5 simple tasks drag out when you have to do them 100 times.
Sensor you should be OK with. Getting a screen in to the 32u4 with LMIC will be Mission Impossible, not enough flash or RAM.
The TTN library is special, but not in the best of ways. The preference is to use a SiP like Murata or RM186 or RAK to handle all the LoRaWAN for you. Failing that, the Feather is a reasonable option - SAMD1 with decent amount of flash & RAM.
I’ll revisit my email in the morning.
Yup. But if you treat it like Lego on the PCB + PnP side and you have a bunch of people with years of experience of soldering for the random connectors being used who like the pocket money plus someone to manage them, it’s a problem that happens out of sight 
The ‘trick’ is to penalise every deviation from the pre-designed elements harshly. Or get the customer to start at a few thousand, then they can have all the NRE they can afford.
Hi @wesselvs for a quick evaluation and compact off the shelf product you might consider looking at the following evalboard from Miromico: FMLR-EvalKit-RSEVK2 (50x26mm). It’s already equipped with a Sensirion SHT21 temperature (±0,3c) and humidity sensor (±2%RH). Then if you are content and wish to drop the price even further you can simply use a FMLR-61-U-RSS3-4M (14,2x19,5mm) module on your own board with sensors and formfactor of your choice. The kit comes with a full LoRaWAN stack. The micro on the module is a Renesas S3 (Cortex-M4). Professional dev environment and compiler are FoC.
Hi
All temp + humidity or pressure or air quality sensors that I tested had higher temps than ambient. Airflow over the sensor can make a difference, but is a problem with battery powered operation. A temperature sensitive resistor can be easier to place on a “good location”.
You’re calibration procedure should be quite good. and be aware off the enverimont from the sensor itself.
I have used Sensirion SHT3x and SHT7x Temperature / Humidity sensors in Scientific instruments for years. Through calibration checks pre-deployment, post-deployment and in field calibration checks they have proven to be very accurate.
There some obvious gotchas, if you have the internal heaters of the sensors enabled, for example to expect to subject them to very low temperatures or a the dew point, then naturally they will read higher than ambient. Also no matter what housing you put them into they need have asperated (air “flowing” across the sensor face) otherwise you are going to be measuring the temperature of their case, the pcb, the temperature inside the enclosure etc.
Do you have to calibrate them pre-deployment or more of a check that they are running fine. In other words was the temperature correct before the calibration.
I’ve not tested them for long term differences, but low drift or other problems would be nice.
We have to send them of to a external company. The first test unit i have “pre-calibrated” with a already calibrated unit as reference. It should currently be in the calibration facility. Hopefully it will be accepted for use.