chwe

As you can imagine, my time & know how (in this area) is somehow limited, but if it helps you and other developers to do the hard stuff that I'm for sure not able to do, we can give it a try. Yes. This is at least much simpler to support and is to consider. I see the point, maybe something to consider as soon as more important issues are solved. I'm still impressed by the FriendlyArm wiki, but for sure the have much more man power to do that.

Firstly, I wanna thank to the hole 'team armbian' for spending so much effort in this project. You did, and still do a great job. The reason why I moved from RPi to an OPi zero is Armbian. When I noticed that there is a Linux which is state of the art and a community which gives so much support, I saw no reason to spend more time playing around with my RPis. I follow this thread for a while when it started arround nightly images and moved now to a more basic discussion about armbian and what it should be. My strenghts are definitely not in software engineering nor software support (if you ever have questions about chemistry or biology, let me know cause thats things I understand ). But I saw a lot of projects failing cause of people loss the spirit spending their time to explain the same questions again and again and I don't want to see that armbian also fails. Support via Forum is important and let the community grown but it needs a lot of time. Questions like: Why does "random function" does not work on my "random board" are annoying. Maybe some additional information to each board and some basic question rules can help to avoid this. Additional Information: A lot of customers are driven by the specs that the vendor gives what should be possible with this board. Having a wiki-page to each supported SBC that shows if the vendor claimed features are supported by armbian or not or if there is some known projects where someone works on this feature could help to avoid people from buying false boards. Also if the community brings something (e.g kodi etc.) to work on a specific board, a small how-to could be written there to help less experienced users start their project. I know this needs some time especially due to the fact that a lot of boards are supported but once the basics are there, you can push people to read the wiki before asking stupid questions. Basic Question Rules: Define some basic forum rules for what is important (e.g. board type, armbian version, what was tried, logs of errors etc. )before someone can give support should also shorten your time for support. Something like a "how-to ask questions so that you improve your chance to get an answer". So that a moderator can close every question that doesn't follow this rules. For the roll-out of armbian 5.30 which leads in a brick of the network connectivity on some boards keep in mind that even big players like microsoft broke their DHCP service on windows 10 by an update . It should not happen but it can. I'm thinking of whenever a major update is planed an announcement thread should be pinned to each subforum that testers are needed to check if everything works properly. If you get the respond that it works, the update can be rolled out for the boards you get these test replies. And if no owner of a specific board feels responsible to do this tests, I dont's see any reason why the development team should feel responible to improve armbian for this board.

In case you just use the opi only as a dataloger. Why you don't use node-red (it hase some nice features for save data and graphs packages to show the stuff.. Have a cheap esp8266 and a mqtt broker on it makes it easy to reuse most of your code from the arduino... or if it just had to work use an arduino with firmata on it over serial. Firmata & node-red

Mostly its not a problem of price. Delivery time for getting the next one is more a problem.. (I should have one or two around, just to be shure when I burn one. ) Did you test test i2c or spi with the lib?

As you can see in the readme for the second lib you mentioned it is tested for the OrangePi PC not OrangePi zero.

For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works. Hardware: OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation: First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/ with npm i node-red-dashboard If everything goes right you should have access to node-red via browser on port 1880: 192.168.1.xx:1880 and to the UI of dashboard: 192.168.1.xx:1880/ui/ Setting up everything: Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos): VCC -->3.3V Signal --> D4 GND -->GND Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...) For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager): PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker: The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data). Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing) We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture) To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo is provided "as is", without warranty etc.

Hi, I read this forum quite a while and i'm glad that you're also work on boards in which you're not that much interested. Lots of stuff here is quite a little bit over my skills so where can I contribute to your project to your work? Definitly not in geting software to work. But for those of you who have a 3D-printer I have desinged a small case for the OPI 2G-IOT with holes to the: Power button USB Power supply 3.5mm Jack SIM Card slot TF Card slot Wifi antenna It's not perfect but should work for most cases. For those of you who are familiar with 3D-Printing there are are some bridging parts which are not that easy to print, but it should work if you use support material (I printed it with PETg which isn't good in printing bridging but I was to lazy to change the filament and I use PETg for most of my other projects). In my opinion it would look much better if you Print it with PLA. The walls are thin enough that you can plug in the power supply. There are some holes for screwing the board on the bottom part of the case but i never tested it (something like m2 screws ~4-5mm long should work). Since there was no 3D-file of the board available I had to redrawn it from scratch and therefore some of the dimensions do of course not 100% fit with the board but from what I saw, the holes are big enough to remove everything while the board is in the case. The STL-File for printing it is added to this post. Let me know if you have some improvements for the case. I observed that the SOC gets quite hot when I pluged in only the power supply without any SD-card (just tiped the finger on it without any proper measurement, but for shure more than 55°C). Is this normal? Since this is not high priority project to me, I don't know which temperatures are normal for the SOC. case_bottom.stl case_top.stl