espid2sensor in den Hauptstack integriert: verschachteltes Git-Repo
aufgeloest, Dockerfile/deploy.sh an die anderen Services angeglichen,
als Service in noisesensors/docker-compose.yml aufgenommen (Port 3004,
gemeinsame Mongo-Instanz), APIHOST-Bugfix fuer die Adressaufloesung,
Versionsbump auf 1.3.2.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ueberfluessig, seit deploy.sh direkt ueber docker build + push
arbeitet (wie bei den anderen Services) statt ueber das alte
scp-basierte Kopieren auf einen Zielhost.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
REGISTRY per Env-Variable konfigurierbar (Default ghcr.io/dnms-org/laermkarte-sensor-community),
Build direkt ueber docker build -f Dockerfile_esp2sensor statt ueber das
alte scp-basierte build_and_copy.sh, einheitlicher Aufbau/Ausgabe wie bei
noise/sensorapi/readin/readarchive.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ohne APIHOST griff der externe Default (https://noise.fuerst-stuttgart.de/srv/),
der im Container mit einem TLS-Fehler (self-signed certificate) fehlschlug. Die
dadurch leere Adresse wurde vom Frontend faelschlich als "Sensor unbekannt"
interpretiert, obwohl der Sensor in Mongo existierte.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
espid2sensor lief bisher nur per eigenem Dev-Compose mit isolierter
Wegwerf-Mongo. Jetzt Teil von noisesensors/docker-compose.yml, Port 3004,
Zugriff auf die dort laufende mongodb-Instanz (sensor_data). DEV_AUTO_LOGIN
explizit aus, SESSION_SECRET ueber neue Env-Variable statt Code-Default.
Dockerfile_esp2sensor an das Muster der anderen Services angeglichen
(node:22-alpine, /opt/app, npm ci, tzdata/Europe-Berlin, deluser node).
espid2sensor/.git entfernt (war eigenes verschachteltes Repo) und der
komplette Verzeichnisinhalt ins laermsensor-stack-Repo uebernommen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Alle vier Skripte schieben das gebaute Image jetzt auch nach
gitea.fuerst-stuttgart.de/admin, damit es nicht nur an einer Stelle liegt.
Der zweite Push laeuft nach dem ersten und ist bewusst nicht fatal: schlaegt
er fehl, liegt das Image bereits in docker.citysensor.de, aus der der Stack
zieht. Das Skript meldet dann nur, dass die Zweitablage fehlt, statt den
ganzen Deploy als gescheitert auszuweisen.
Abschalten mit REGISTRY2= ./deploy.sh
Voraussetzung ist ein docker login gitea.fuerst-stuttgart.de (Access Token
mit write:package genuegt).
Geprueft: noise, sensorapi, readarchive und readin liegen in beiden
Registries unter demselben Digest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beide Komponenten wurden fuer die Korrektur der Stadtsuche angefasst, die
Versionen im Log und in der Oberfläche sollen das zeigen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wer auf dem Kartenreiter die Einstellungen oeffnete und eine Stadt eingab,
bekam danach nur noch ein graues Fenster. Drei Fehler wirkten zusammen:
1. getCityCoords() rief Nominatim ohne eigenen User-Agent auf. Nominatim
beantwortet den axios-Default mit 403, und zwar fuer jede Stadt. Die
Schwesterfunktion getAddress() setzt seit jeher einen User-Agent -
deshalb funktionierten die Adressen an den Sensoren, nur die
Stadtsuche nicht. Beide nutzen jetzt dieselbe Konstante.
2. cityCoords() lieferte im Fehlerfall den String "no coordinates". Der
landete als Kartenzentrum in L.map().setView(), Leaflet warf "Invalid
LatLng object" - und weil showMap() die alte Karte vorher schon
entfernt hat, blieb der Container leer. Daher grau statt Fehlermeldung.
cityCoords() liefert jetzt {coords, err}; schlaegt die Suche fehl,
bleibt das bisherige Zentrum stehen und der Text wird angezeigt.
3. Der Proxy in noise/routes/api.js kodierte die bereits prozentkodierte
req.originalUrl ein zweites Mal. 'Goettingen' kam als 'G%c3%b6ttingen'
an. Das fiel bisher nicht auf, weil schon Punkt 1 alles abfing.
Ausserdem: Tippfehler getCityCoord.name, fehlendes encodeURI bei der
Stadtsuche, Koordinaten als Zahl statt String, und eine eigene Meldung
(ENOCITY), wenn Nominatim den Ort nicht kennt.
Geprueft ueber die volle Kette noise -> sensorapi -> Nominatim:
Stuttgart, Goettingen (Umlaut), Bad Cannstatt (Leerzeichen) liefern
Koordinaten, ein erfundener Ort eine saubere Meldung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Das docker-compose.yml des Haupt-Stacks deklariert kein Netz - Compose
legt <projektname>_default selbst an. Bei Portainer ist der Projektname
der Stack-Name, der in readarchive-stack.yml eingetragene Wert
noisesensors_default passt also nur, wenn das Stack auch so heisst. Sonst
bricht der Lauf mit "declared as external, but could not be found" ab.
Dazu als Option das Umbenennen des Default-Netzes (fester Name, unabhaengig
vom Stack-Namen) und der Hinweis, dass ein networks: an einem Service
dessen automatische Zuordnung aufhebt - wer dort etwas eintraegt, muss
default mit auffuehren.
Co-Authored-By: Claude Opus 5 (1M context) <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 README beschrieb bisher nur die Erstinstallation. Neu:
- Abschnitt "Update eines laufenden Stacks" mit der Reihenfolge
Rollback sichern, Compose angleichen, nur den geaenderten Container
ziehen, verifizieren. Inklusive der beiden Fallen: der Volume-Pfad
von readin hat sich auf /opt/app/readin/data geaendert, und ein Mount
auf /etc/influxdb2 fuehrt zu Datenverlust.
- readarchive in der Container-Liste, mit Parametern und Aufruf ueber
das Profil tools.
- common/ unter den Sourcen, mit dem Hinweis, dass eine Aenderung dort
beide Container betrifft.
- deploy.sh: Tag mitgeben, sonst gibt es keinen Weg zurueck.
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>
Gegenstueck zu readin/: waehrend readin alle 5 Minuten die Live-API
abfragt, liest readarchive rueckwirkend die Tagesdateien von
archive.sensor.community in dieselben Datenbanken ein.
Ohne History uebernommen (das Projekt lag bisher in einem eigenen
Repository unter Sensors/Laerm/laerm_readfromcsv_to_database).
Stand entspricht dort e33a7b7:
- Zeitstempel werden in UTC gespeichert, unabhaengig von der Zeitzone
der Maschine. readin/parse.js macht das seit jeher richtig,
readFromcsv.js lag zwei Stunden daneben.
- Fehlgeschlagene Influx-Writes werden gemeldet und setzen den
Exit-Code, statt still verloren zu gehen.
- Der Container nimmt Parameter entgegen (ENTRYPOINT in Exec-Form).
Hinweis: mongo.js, influx_post.js und logit.js gibt es auch unter
readin/, mit abweichendem Stand. Zusammenfuehren waere der naechste
Schritt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
admin
rbsensors