Die Laufzeit steckt fast vollstaendig im Warten auf die CSV-Dateien von
archive.sensor.community - je Sensor rund 0,24 s, davon nur 0,02 s der
Influx-Write und 0,01 s die Mongo-Abfrage. Die Schleife ueber die Sensoren
laeuft deshalb jetzt mit mehreren Arbeitern gleichzeitig (-p bzw. PARALLEL,
Default 4, 1 = altes Verhalten).
Gemessen fuer 2026-08-01 (280 Laermsensoren, 344660 Werte, -d influx):
1 -> 79 s, 4 -> 33 s, 8 -> 35 s, 16 -> 31 s. Ab etwa 4 gleichzeitigen
Abrufen liefert das Archiv nicht mehr schneller; derselbe Verlauf zeigt
sich mit blossem curl ohne Datenbank (71 / 32 / 28 / 29 / 29 s bei 1, 4,
8, 16, 32 Abrufen). Der Default steht deshalb auf 4 und nicht hoeher -
mehr erzeugt nur Last beim fremden Server.
checkProperties() wird jetzt awaited - der Aufruf lief bisher ohne await
gegen das bulkWrite am Ende von main(), was mit parallelen Sensoren kein
Randfall mehr waere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
readarchive ist kein Dauerdienst, sondern ein Lauf mit Parametern. Als
Service mit profiles: ["tools"] liess er sich aus Portainer gar nicht
starten - eine Profil-Auswahl gibt es dort nicht, und ein Gegenstueck zu
"docker compose run" ebenso wenig.
Jetzt steht er in noisesensors/readarchive-stack.yml. Dieselbe Datei
bedient beide Wege: auf der Kommandozeile mit Argumenten via
"docker compose -f readarchive-stack.yml run --rm readarchive ...", im
Portainer als eigenes Stack mit den Parametern als Environment-Variablen
(readFromcsv.js liest -s/-e/-t/-d auch aus START/END/TYP/DBASE).
- eigener Projektname "name: readarchive", damit die Datei auf der
Kommandozeile nicht das Projekt des Haupt-Stacks uebernimmt
- Netz des Haupt-Stacks als external eingebunden
- README: readarchive-Abschnitt neu, Profil-Hinweis in der
Update-Anleitung ersetzt, Datei in Struktur und Dateiliste ergaenzt
- .env.example: Block fuer START/END/TYP/DBASE
- noise.tgz neu gepackt, damit die Datei mit ausgeliefert wird
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Mount aus d6e6cb3 war nie deployt - in /opt/stacks lief das Compose
ohne ihn. Auf einer zweiten Installation hat genau dieser Mount Datenverlust
verursacht: das Entrypoint legt dort beim Setup das CLI-Profil "default" an,
ein schon vorhandenes Profil laesst den Setup scheitern, und danach loescht
das Entrypoint bolt+engine im Datenverzeichnis und startet neu. Weil der
Mount das Aufraeumen ueberlebt, wiederholt sich das endlos.
Damit entspricht das Repo wieder dem, was tatsaechlich laeuft.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mongo.js, influx_post.js und logit.js lagen in beiden Komponenten doppelt
und waren auseinandergelaufen - so ist der Zeitzonen-Fehler entstanden, den
readin seit jeher richtig loest und readFromcsv.js zwei Jahre lang nicht.
Sie liegen jetzt einmal unter common/.
Wo die Fassungen sich widersprachen:
- MONGOAUTH wird als String verglichen. Die readarchive-Fassung pruefte nur
auf truthy, dadurch schaltete auch MONGOAUTH=false die Auth ein.
- writeDataArray(client, coll, data) nimmt den Collection-Namen direkt;
readarchive baut ihn mit dem neuen dataCollName(styp).
- getallProperties liefert das Array selbst. Die readarchive-Fassung mit
{error, properties} war dort ungenutzt.
- properties_collection heisst einheitlich property_coll.
Das Sammelobjekt statistics lag in readin/readdata.js und wurde von
mongo.js und influx_post.js importiert. Es liegt jetzt in
common/statistics.js, damit die gemeinsamen Module readin nicht kennen
muessen.
Der Build-Kontext beider Images ist dadurch das Repository-Wurzelverzeichnis;
das Layout im Image spiegelt das Repository, damit ../common/... unveraendert
aufgeht. Die Volume-Zeile von readin im Compose zieht deshalb auf
/opt/app/readin/data um.
readarchive folgt jetzt den Konventionen des Stacks: deploy.sh statt
build_and_copy.sh, Dockerfile_readarchive statt Dockerfile_rfcsv, und die
eigene docker-compose.yml entfaellt - der Dienst haengt als Profil "tools"
im Compose des Stacks und wird mit Parametern gestartet:
docker compose run --rm readarchive -t noise -s 2026-07-25 -e 2026-07-29
Getestet: beide Images gebaut, beide gegen Testdatenbanken laufen lassen.
Nicht deployt - die Images in der Registry sind unveraendert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
admin