NEWS
[Skript] Namespace für Datenpunkte in Skripten abändern
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
seltsam - bei mir ist da nix rotmein Editor zickt des Öfteren, aber da war zB ein callback mit return, was eig. keinen Sinn macht
ist mit wieder eingefallen - ich wollte in der vis das filesystem abbilden - um evtl mp3's asuszuwählen und diese an einen audio-streamer zu senden - dabei habe ich diesen code gefunden
hier eine etwas aufgräumtere Version. Es wird ein Backup angelegt und eine neue Datei mit Endung .new. Die css wird nicht angefasst, kannst Du in Zeile 22 ändern.
Nach dem Lauf des Skripts muss wie schon erwähnt ein Upload erfolgen(Nach Rename) oder der auskommentierte Teil benutzt werden.
das eigentliche thema - habe mal dein script vom ersten post laufen lassen
das sind meine settings:
let dbg = false; // Zusatzausgaben fürs Debugging const newNamespace = '0_userdata.0.CONTROL-OWN'; //neuer Namespace für DP // Eigene Einstellungen const oldNamespace = 'controll-own.0'; //Ordner für Namespace welcher ersetzt wird const replaceInSystemsDB = false;// lädt geänderte Dateien sofort ins System(ACHTUNG! *** auf eigenes Risiko ***) const writeToFileSystem = false;// Geänderte Dateien ins Filesystem schreiben const pathToRestore = '/opt/iobroker/scripte-switch/'; // <=== Pfad eintragen mit abschliessendem / const extChanged = 'Chg'; // Wird im Falle einer Änderung an ID und Name angehangen let changes = 0; // Zählt Änderungen in einem Skript let changesResult = []; // Zussammenfassung der Ergebnisse, wird in DP geschriebenmit diesen settings sollte ich doch im json widget etwas bekommen bzw. sehen?
mach ich was falsch ?
-
das eigentliche thema - habe mal dein script vom ersten post laufen lassen
das sind meine settings:
let dbg = false; // Zusatzausgaben fürs Debugging const newNamespace = '0_userdata.0.CONTROL-OWN'; //neuer Namespace für DP // Eigene Einstellungen const oldNamespace = 'controll-own.0'; //Ordner für Namespace welcher ersetzt wird const replaceInSystemsDB = false;// lädt geänderte Dateien sofort ins System(ACHTUNG! *** auf eigenes Risiko ***) const writeToFileSystem = false;// Geänderte Dateien ins Filesystem schreiben const pathToRestore = '/opt/iobroker/scripte-switch/'; // <=== Pfad eintragen mit abschliessendem / const extChanged = 'Chg'; // Wird im Falle einer Änderung an ID und Name angehangen let changes = 0; // Zählt Änderungen in einem Skript let changesResult = []; // Zussammenfassung der Ergebnisse, wird in DP geschriebenmit diesen settings sollte ich doch im json widget etwas bekommen bzw. sehen?
mach ich was falsch ?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
mit diesen settings sollte ich doch im json widget etwas bekommen bzw. sehen?
ja solltest du, Ich hatte gestern plötzlich und aus heiterem Himmel ähnliche Fehler, obwohl im Selektor werden die IDs in der forEach angemault. Für mich sah es so aus dass in jacascript.x.scriptEnabled DPs waren für die es keine Skripte mehr gab(ich verschiebe alte Versionen immer in einen Ordner Löschen). Als Abhilfe habe ich jeweils die kompletten scriptEnabled und scriptProblem gelöscht und nach Neustart der JS-Instanzen aufbauen lassen. Danach waren die Fehler weg. Allerdings hatte ich trotzdem Daten im JSON, ich hatte nicht geprüft ob es alte Daten waren.
Leider kenne ich keinen anderen Weg um Skripte zu listen, als den indirekten Weg über scriptEnabled, zum Glück bleiben dann die Pfade in script.js so erhalten. Der Selektor findet ja nur DP und in script.js(wo die eig. Skripe sind) gibt es keine DP.
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
danke - das schaut doch sehr gut aus
dieses script für sich wäre schon einen thread wert :-) hätte ich gut brauchen können als trashschedule die adapter-object-werte geändert hatte
meine ersten test sehen sehr gut aus - vis und vis-editor zeigen alles richtig an
- habe noch eine whitelist hinzugefügt - falls du dies anders "coden" würdest - einfach ändern - eine einschränkung ist besser beim testen und für den "tägl" gebrauch kann es auch sinnvoll sein, wenn man nur bestimmte vis-projekte ändern kann
- habe auch das backup file unbenannt (datum-uhrzeit) -damit es nicht überschrieben wird
- wenn direkt ins system geschrieben wird, braucht es eigentlich keine new datei
@liv-in-sky deine Änderungen machen alle Sinn, ganz speziell der timestamp!. Beim Schreiben ins System hatte ich manchmal Fehler, dennoch war die Datei anschliessend vorhanden. Diese Option ist also wirklich nichts für Anfänger, evtl. darf und sollte man das nicht tun :-)
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
mit diesen settings sollte ich doch im json widget etwas bekommen bzw. sehen?
ja solltest du, Ich hatte gestern plötzlich und aus heiterem Himmel ähnliche Fehler, obwohl im Selektor werden die IDs in der forEach angemault. Für mich sah es so aus dass in jacascript.x.scriptEnabled DPs waren für die es keine Skripte mehr gab(ich verschiebe alte Versionen immer in einen Ordner Löschen). Als Abhilfe habe ich jeweils die kompletten scriptEnabled und scriptProblem gelöscht und nach Neustart der JS-Instanzen aufbauen lassen. Danach waren die Fehler weg. Allerdings hatte ich trotzdem Daten im JSON, ich hatte nicht geprüft ob es alte Daten waren.
Leider kenne ich keinen anderen Weg um Skripte zu listen, als den indirekten Weg über scriptEnabled, zum Glück bleiben dann die Pfade in script.js so erhalten. Der Selektor findet ja nur DP und in script.js(wo die eig. Skripe sind) gibt es keine DP.
@fastfoot thema script enabled
durch meine 3 instanzen kam es da schon immer zu einem extremen wildwuchs (script-enabled) - vorallem, wenn man scripte verschiebt
ich hatte mich nie getraut, script eabled zu löschen - aber du sagst, die legen sich neu an - verstehe ich das richtig ?
ein anderer weg für die scripte - dachte anfangs, dass du das darüber machen wirst:
ich habe mal ein script gemacht um mir alle scripte anzusehen - da nutzte ich die scripte-spiegel function vom js-adapter und ging auch durch das directory - ich glaube das nutzen auch einige, die mit einem anderen/externen script editor arbeitensieht so aus:
-
@liv-in-sky deine Änderungen machen alle Sinn, ganz speziell der timestamp!. Beim Schreiben ins System hatte ich manchmal Fehler, dennoch war die Datei anschliessend vorhanden. Diese Option ist also wirklich nichts für Anfänger, evtl. darf und sollte man das nicht tun :-)
habe gerade gesehen, dass du ja ein script hast, welches über diesen mirror-ordner geht ( Extrahiert XML Datei aus Blockly.js im Mirror-Pfad)
warum nutzt du diesen weg nicht ? ist das wegen den blockly scripte ?
-
@fastfoot thema script enabled
durch meine 3 instanzen kam es da schon immer zu einem extremen wildwuchs (script-enabled) - vorallem, wenn man scripte verschiebt
ich hatte mich nie getraut, script eabled zu löschen - aber du sagst, die legen sich neu an - verstehe ich das richtig ?
ein anderer weg für die scripte - dachte anfangs, dass du das darüber machen wirst:
ich habe mal ein script gemacht um mir alle scripte anzusehen - da nutzte ich die scripte-spiegel function vom js-adapter und ging auch durch das directory - ich glaube das nutzen auch einige, die mit einem anderen/externen script editor arbeitensieht so aus:
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
verstehe ich das richtig ?
ja tust du, die beiden Ordner werden beim Neustart der jeweiligen Instanz sofort wieder aufgebaut(dennoch: Backup!). Ich habe das schon oft gemacht und nie(!) Probleme damit gehabt.
Über den Mirrorpfad zu gehen wäre auch eine Option gewesen, eines meiner älteren Skripte nutzt das um aus Blocklys XML Dateien zu erzeugen. ich wollte es aber bewusst so machen. Die dritte Option wäre gewesen, eine Kopie der objects.json zu nutzen, aber da muss man das System vorher stoppen um die Kopie zu ziehen, läuft aber sehr sauber. Das hatte ich ja auch mal gepostet, hatte aber das Namespace Switching nicht mit drin.
Evtl. sollte man aber ein issue zum Selektor aufmachen, das sollte eig. auch mal sauber laufen. Da wollte ich aber noch mehr belastbare Daten haben, damit die Entwicklerdas nachvollziehen können. Vieles ist auf meiner Seite Spekulation. Allerdings wirft das Skript unmittelbar die Fehler unmittelbar nach der Definition des Selektors und anschliessendem Durchlaufen, ohne dass man die Chance hätte etwas falsch zu programmieren
Probiere das doch mal mit Bereinigung dieser beiden Ordner, das geht sehr schnell. Für mich ein Hauptgrund für dieses Skript ist eigentlich die Auflistung mainer Skripte incl. ihres Zweckes, das setzt natürlich immer einen Header vorraus, den du mittlerweile in fast allen meinen Skripten sehen kannst. Ist etwas Arbeit aber für mich hat es sich schon gelohnt :-)
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
verstehe ich das richtig ?
ja tust du, die beiden Ordner werden beim Neustart der jeweiligen Instanz sofort wieder aufgebaut(dennoch: Backup!). Ich habe das schon oft gemacht und nie(!) Probleme damit gehabt.
Über den Mirrorpfad zu gehen wäre auch eine Option gewesen, eines meiner älteren Skripte nutzt das um aus Blocklys XML Dateien zu erzeugen. ich wollte es aber bewusst so machen. Die dritte Option wäre gewesen, eine Kopie der objects.json zu nutzen, aber da muss man das System vorher stoppen um die Kopie zu ziehen, läuft aber sehr sauber. Das hatte ich ja auch mal gepostet, hatte aber das Namespace Switching nicht mit drin.
Evtl. sollte man aber ein issue zum Selektor aufmachen, das sollte eig. auch mal sauber laufen. Da wollte ich aber noch mehr belastbare Daten haben, damit die Entwicklerdas nachvollziehen können. Vieles ist auf meiner Seite Spekulation. Allerdings wirft das Skript unmittelbar die Fehler unmittelbar nach der Definition des Selektors und anschliessendem Durchlaufen, ohne dass man die Chance hätte etwas falsch zu programmieren
Probiere das doch mal mit Bereinigung dieser beiden Ordner, das geht sehr schnell. Für mich ein Hauptgrund für dieses Skript ist eigentlich die Auflistung mainer Skripte incl. ihres Zweckes, das setzt natürlich immer einen Header vorraus, den du mittlerweile in fast allen meinen Skripten sehen kannst. Ist etwas Arbeit aber für mich hat es sich schon gelohnt :-)
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Die dritte Option wäre gewesen, eine Kopie der objects.json zu nutzen, aber da muss man das System vorher stoppen um die Kopie zu ziehen, läuft aber sehr sauber
hört sich für mich ganz gut an - eine sichere methode - ich stoppe auch gerne das system dafür
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Probiere das doch mal mit Bereinigung dieser beiden Ordner
werd ich
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Evtl. sollte man aber ein issue zum Selektor aufmachen
kannst du gerne machen - es gibt überhaupt keinen time-stress . ob das in ein paar tagen oder später funktioniert ist mir nicht wichtig - nur : das es funktioniert :-)
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das setzt natürlich immer einen Header vorraus
ist das der header?
-
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Die dritte Option wäre gewesen, eine Kopie der objects.json zu nutzen, aber da muss man das System vorher stoppen um die Kopie zu ziehen, läuft aber sehr sauber
hört sich für mich ganz gut an - eine sichere methode - ich stoppe auch gerne das system dafür
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Probiere das doch mal mit Bereinigung dieser beiden Ordner
werd ich
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Evtl. sollte man aber ein issue zum Selektor aufmachen
kannst du gerne machen - es gibt überhaupt keinen time-stress . ob das in ein paar tagen oder später funktioniert ist mir nicht wichtig - nur : das es funktioniert :-)
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das setzt natürlich immer einen Header vorraus
ist das der header?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
ist das der header?
ja, für das JSON Widget braucht es natürlich nur den Zweck, aber ein Datum schadet nie und wenn ich es veröffentliche weiss jeder gleich an wen er sich wenden kann. Mittlerweile habe ich auch oft eine Zeile Forum.
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
ist das der header?
ja, für das JSON Widget braucht es natürlich nur den Zweck, aber ein Datum schadet nie und wenn ich es veröffentliche weiss jeder gleich an wen er sich wenden kann. Mittlerweile habe ich auch oft eine Zeile Forum.
die warnings sind jetzt weg - nach dem löschen der script-enabled
nur noch der bekannte error
-
die warnings sind jetzt weg - nach dem löschen der script-enabled
nur noch der bekannte error
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
nur noch der bekannte error
na mir ist der nicht bekannt :-) Evtl. hat ein Skript da keinen source. müsste man prüfen indem man im Selektor auf einen Ordner begrenzt oder auf ein Skript und sich in Zeile 38 den Namen anzeigen lässt
log(obj.common.name);iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
nur noch der bekannte error
na mir ist der nicht bekannt :-) Evtl. hat ein Skript da keinen source. müsste man prüfen indem man im Selektor auf einen Ordner begrenzt oder auf ein Skript und sich in Zeile 38 den Namen anzeigen lässt
log(obj.common.name);@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
log(obj.common.name);
meinst du so ?
das waren 2 leere scripte :-( :-) kannst/willst du das abfangen ?
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
nur noch der bekannte error
na mir ist der nicht bekannt :-) Evtl. hat ein Skript da keinen source. müsste man prüfen indem man im Selektor auf einen Ordner begrenzt oder auf ein Skript und sich in Zeile 38 den Namen anzeigen lässt
log(obj.common.name); -
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
log(obj.common.name);
meinst du so ?
das waren 2 leere scripte :-( :-) kannst/willst du das abfangen ?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das waren 2 leere scripte kannst/willst du das abfangen ?
ja natürlich! Gibt immer wieder Dinge welche man nicht im Traum dran denkt dass sie passieren könnten :-)
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
leere scripte gelöscht - jetzt läuft es durch
wow! ich komme gerade mal auf 255, incl. alter Versionen :-)
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
log(obj.common.name);
meinst du so ?
das waren 2 leere scripte :-( :-) kannst/willst du das abfangen ?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
kannst/willst du das abfangen ?
ändere in Zeile 36 zu
if(obj && obj.type === 'script' && obj.common.source){Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
leere scripte gelöscht - jetzt läuft es durch
wow! ich komme gerade mal auf 255, incl. alter Versionen :-)
@fastfoot
du willst die genaue zahl - dann hättest du das widget nicht limitieren sollen - es sind 746- da sind aber einige sonder-scripts für andere user
- und viele scripte, mit allen versionen bei der entwicklung
- viele still-gelegte
gehört wohl mal aufgeräumt :-)
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
kannst/willst du das abfangen ?
ändere in Zeile 36 zu
if(obj && obj.type === 'script' && obj.common.source){Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
weiß ich leider nicht - habe das log angesehen, dass script gecheckt, welches als letztes angezeigt wurde und das "leere" gelöscht
noch ne frage - habe die beiden scripte (im log), die leer waren gelöscht - alle js-instanzen neugestartet und bekomme nun dieses warning
das problem dabei, in script_enabled werden die datenpunkte nicht gelöscht. nur in der eigentlichen instanz wird der dp gelöscht - in den anderen beiden bleibt dieser dp enthalten - man sollte also auf jeden fall alle script_enabled-ordner aller instanzen löschen bovor das script läuft - evtl in der anleitung als pflicht angeben ?
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
kannst/willst du das abfangen ?
ändere in Zeile 36 zu
if(obj && obj.type === 'script' && obj.common.source){Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
-
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
weiß ich leider nicht - habe das log angesehen, dass script gecheckt, welches als letztes angezeigt wurde und das "leere" gelöscht
noch ne frage - habe die beiden scripte (im log), die leer waren gelöscht - alle js-instanzen neugestartet und bekomme nun dieses warning
das problem dabei, in script_enabled werden die datenpunkte nicht gelöscht. nur in der eigentlichen instanz wird der dp gelöscht - in den anderen beiden bleibt dieser dp enthalten - man sollte also auf jeden fall alle script_enabled-ordner aller instanzen löschen bovor das script läuft - evtl in der anleitung als pflicht angeben ?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das problem dabei, in script_enabled werden die datenpunkte nicht gelöscht. nur in der eigentlichen instanz wird der dp gelöscht - in den anderen beiden bleibt dieser dp enthalten - man sollte also auf jeden fall alle script_enabled-ordner aller instanzen löschen bovor das script läuft - evtl in der anleitung als pflicht angeben ?
eigentlich sollte der Fehler nicht auftauchen, da in Zeile 32 auf die Existenz des Objekts geprüft wird. Zusätzlich wird, falls existent, auch die Instanz der scriptID mit der tatsächlichen verglichen und nur bei Gleichheit weitergemacht. Theoretisch sollte also egal sein was in scriptEnabled steht. DA hilft nur die beiden Skripte zu prüfen,
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
das ist richtig, du kannst aber auch die Datei im Filesystem nutzen und erstmal von Hand importieren, es werden nur Dateien geschrieben welche auch eine Änderung haben(also oldNamespace beinhalten). Müsstest du im Pfad von pathToRestore finden, vorher löschen damit nur diese Datei drinne ist. Für ein Schreiben ins System empfehle ich mit Endung Chg, dann wird ein neues Skript angelegt und das alte bleibt erhalten!
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558
Support us
613
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge