malaga reacted to jeanrhum in How to install Docker on a banana-Pi system: ... and separate the config-data in a smart way
Your question is not directly related to armbian or any relevant OS for a given board, but it is more a question about docker itself and how it manages data: https://docs.docker.com/storage/
On dockerhub, you'll find most images where the data specific to the encapsulated software is binded to a local folder by setting the relevant volume. Look for instance to this image: https://hub.docker.com/r/linuxserver/nextcloud where -v /path/to/appdata:/config defines the location where your can access to the config files from the host operating system and -v /path/to/data:/data corresponds to the data stored with nextcloud so that you can target any local drive properly configured and mounted from the host operating system.
malaga reacted to lanefu in collect data (temperature & humidity) from DHT22 into csv and sending them over the net
to @arox's point.. MQTT is a good fit for this.
Mosquito is easy to install.
Here's an example of doing something similar.. with a different library
malaga reacted to arox in collect data (temperature & humidity) from DHT22 into csv and sending them over the net
I don't understand your point.
The problem when designing a distributed system is to ensure reliability when systems crash, reboot or the network disconnects. For systems like SBC or microcontrollers, you have to detect crash and assure recovery, maintenance and debugging on system without screen and keyboard - and avoid corrupted storage problems. For network, you must provide reconnect procedures (witch also suppose that the disconnection has been detected), frequents with over-the-air networks, or in case of peer restart.
I use (and you were aiming to do so ?) MQTT with a local broker for that reason. I first so that others used it on this forum and initially thought I didn't need it. But I changed my mind : MQTT allows to deploy a multiple "publisher" / "subscriber" loosely connected network with a trivial message protocol and some option to control reliability of message delivery. Even with that, you will have to carefully design your agents to handle crash, disconnections, sensor errors or network failures. At least, I have found that the Eclipse MQTT broker "mosquitto" is reliable.
Basically you can handle MQTT disconnects at application level with a 15 lines of python code MQTT client (if you don't bother to have some samples lost). Sensors error handling is more difficult (often needs reboot). Wifi problems depends on drivers and hardware (so carefully choose the SBC and wifi controller). To ensure reliability of unattended systems connected by wifi is even more difficult in particular with SD cards, rw root fs and OS targeted at graphical UI use case ...
I am not sure smtp is a good idea for IoT. It is reliable but slow. MQTT is a messaging protocol with open subscription (no recipient list) and 1 second latency if you implement your broker. Much more like a "software bus". Ideal in a local network behind a firewall were you don't even need to bother with credentials. If you like complex and heavy solutions or like to be worked up, try Nodered in a Docker container.
Well, that is just my point of view ... but I have lost track of the number of agents at my home for a long time. Fortunately, bugs (hardware, software or design) remind me of some regularly.
malaga reacted to Werner in [Invalid] - operating-system wanted for the Alwinner A 20 - which one to take
Your issue report is invalid for one or multiple reasons (non-exhaustive enumeration):
it has been stated at the wrong place it lacks fundamental requested data it could have been easily solved by a quick search and/or reading documentation unsupported userspace/image/SBC
Since you refused to use the bug reporting form carefully and follow the information there as you have been asked for we have no intention to further investigate.
Please add missing information if applicable.
malaga reacted to guidol in [Invalid] - operating-system wanted for the Alwinner A 20 - which one to take
find at https://www.armbian.com/download/ all downloads
- Alwinner /banana Pi A 20
- Udoo Quad Makerboard Rev. D.
- Orange PI Prime rev 1.0
malaga reacted to Moklev in Motioneye (OPI)
Yes, for CSI camera you must stay on legacy (Jessie dafault).
CSI on mainline is on WIP stage.
Main difference is Motion 3.2.12 (instead of 4.01). Next kernel 4.14.18 is more stable than 3.x (uptime: weeks vs few days). On Jessie may need "deb multimedia" packages for a recent ffmpeg version.
I recommend you a good USB camera H264/MJPEG capable.