Frostbyte

Well, that depends which kernel you are using.  "Default" kernel 4.4 was moved to the Rockchip repository, which provided a huge number of bugfixes/adjustments/new drivers.  4.14 has simply seen the typical maintenance patching.

And more fixes were added by Armbian too! Just the mali4xx/mali-midgard conflict was causing a flood of error messages in syslog, until @TonyMac32 found it and fixed it.

We plan to put them into stable repository after in deep testing. https://forum.armbian.com/index.php?/topic/5149-upcoming-release-date-feature-freeze/ Simply contact @Tido to put you on a list and he will note you when we are ready for a final round of testing. ... if you want to help us out and make this happen sooner.
 

I've just finished writing my SHT31-D (I2C) Nagios plugin.
As promised, it can be found here for anyone else interested.

I've just finished writing my SHT31-D (I2C) Nagios plugin.
As promised, it can be found here for anyone else interested.

IIRC, because of Log2Ram it will not write to SDcard when it crashes. You would have to write the data/logs to another storage device USB-Stick or something externally.
Beside with RPi-Monitor you might also be able to collect some data - is WIP.

I am aware that this board has severe powering issues when using the USB power connector..
After struggling a lot to find a reliable PSU, I ended up buying the "official" RPi PSU that's supposed to provide 2.5 amps, however I still get a shutdown once every 2.5-3 weeks. (I suspect it's power)
Are these patches going to improve this by any chance, or will I forced to craft and use a 3A GPIO PSU?

I'm kind of reluctant, because I've heard that there are no fuses/protection in the GPIO and you can easily toast the board that way.
The reboot fix will be awesome, however.

PS: I'm also coding a nifty little Nagios check for the SHT31-D I2C sensors that just arrived, when my friend takes care soldering the pin headers and making the wires for me, I expect to get it on github soon.

Incredible find, I may just go get a couple of HTS221 to replace my DHT22 then.

I would like however to pose the following questions (excuse my ineptitude, as I'm fairly new to sensors):
Since you mentioned that the current adafruit implementation may return garbage if another process takes over the CPU while the sensors are being read, are I2C-based sensors also susceptible to that? From my understanding I2C uses some sort of special bus, but how exactly does this all work out? Does it interface with the kernel to figure out what to do? (instead of talking directly with the GPIO)
If it's main purpose is to be hardware-agnostic, in theory it should work for every system that there's kernel support for it, right? In order to use it, do I just plug the necessary cables to designated pins (like 3.3v, GND and Data), and just run a sensor check specifying the GPIO # and the sensor type? (I see that Nagios has a designated check_sensor plugin) I've read that there are some cable-length limitations with I2C, I currently use 1-meter wires, will I face a problem? Do sensors share the bus? Can I use multiple I2C sensors on the same board? Provided I have enough GPIO pins and power to feed them. Thanks in advance.

They are hardware I2C peripherals, so they have buffers/control registers/etc, they are not software implementations that can be disrupted by other tasks.  Worst case you overflow a buffer before reading it.

I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI)
I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. 
I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400)
You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers.
 
For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver.
 
Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go
 

I had another look at DHTXXD and it uses another library called pigpiod, which in turn directly access the GPIO registers, so is probably not worth porting to another SoC.
I would go the route of using different sensors, like the BMP085 or BMP280, which offer a standard I2C interface instead of a proprietary one that requires bit-banging - which is always a bad idea to do on a non-real-time OS.
There is many libraries that work with those sensors and they all use the standard /dev/i2c interfaces. Here's one that supports the Tinkerboard: https://github.com/mattjlewis/diozero