Jump to content

StefanOHAN

Members
  • Content Count

    122
  • Joined

  • Last visited

  • Days Won

    3

StefanOHAN last won the day on March 2

StefanOHAN had the most liked content!

Community Reputation

4 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hallo Erik, ich gebe Dir recht man braucht nicht für jedes Bricklet ein Beispiel. Das Remot Switch wäre eines, oder Hinweise wenn zum Ausführen ein Text-String an das Item übergeben werden muss. Beim LCD 128x64 ClearDisplay schreibst Du in Deiner Doku dass ein beliebiger String übergeben werden kann, in dieser Art die Hinweise. viele Grüsse Stefan
  2. Hallo Erik ich habe mir für ein paar meiner Bricklest Deine neue Doku angeschaut, Sie gefällt mir gut. Frage: Hast Du in der Doku auch Beispiele & Besonderheiten vorgesehen ? Ich habe keine gesehen. Hintergrund der Frage anhand des Remote Switch Bricklet betrachtet Du schreibst: Wenn ich jetzt nicht über das Forum Deine Beiträge gelesen hätte, wäre mir nicht klar gewesen dass ich bei dem Channel-verlinktem String-Item (für Socket-A), dem String-Item „on“ oder „off“ übergeben muss. (also als String) Beispiel einer hilfreichen Zusatzinformation in der Dokumentation : Auch Hinweise dass man z.B. einem Channel-verlinktem ITEM eines EdgeCount (der verschiedenen Bricklet) ein „REFRESH“ übergeben kann um einen Update der Werte zu erzwingen wäre nicht schlecht. Generell bin ich für jeden Hinweis dankbar um Fehler zu finden oder zu vermeiden. Ich könnte mir vorstellen, dass diese zusätzlichen Informationen / Beispiele Anfängern oder "Teilzeit" Openhab-Anwendern helfen würden (zumindest geht es mir so). An dieser Stelle nochmal Danke an Deine tolle Arbeit Viele Grüße Stefan
  3. Hallo Erik, kurzer Update ich habe diese Woche meinen zusätzlichen Komponenten bekommen 1 x Air Quality Bricklet 1 x PTC V2 mit Sensor durch den zusätzlichen Masterbrick war ich auch in der Lage ein altes Temperatur Bricklet (HW Version 1.1.0) in die Konfiguration auf zu nehmen. Alle Bricklets funktionieren mit dem Binding und liefern Werte, allerdings habe ich bis jetzt noch keine Action mit diesen Bricklets getestet. Ich vergleich gerade mal wie die verschieden Temperatur-Sensoren Daten liefern. Bist jetzt habe ich den Eindruck dass die Werte des PTC 2 die des Humidty V2 (Temperatur) und die des Air Quallity (Temperatur) sehr nahe zusammen liegen. Die TH-Sensoren liegen näher an den Werten des alten Temperatur Bricklets. Was mir auch gut gefällt ist, dass am PTC V2 ein Offset eingestellt werden kann. Vermutlich werde ich einen Kombination aus Air Quallity Bricklet für innen, PTC & Humidity V2 Bricklet für Außen einsetzten. viele Grüsse Stefan
  4. Hallo Tim, klar macht mehr Sinn das Thema über Privat Nachrichten zu klären, hab Dir hier über die Forum-Funktion einen PV-Nachricht gesendet, ich hoffe Sie ist angekommen. viele Grüsse Stefan
  5. Hallo Tim (Teddy) danke für Dein Angebot bezüglich der „Taster-Abdeckungen“ In meiner aktuellen produktiven Openhab 1.9 Umgebung habe ich ein Bedienfeld mit einem LCD20x4 und einem Multitouch 3x4 Key-Pad. (siehe Bild unten, besteht aus Acryl 5mm, wurde mit einem Laser-Cutter bei einem Lokalen Acryl-Glas Handel hergestellt) Diese Bedienfeld-V1 möchte ich mit der Umstellung meines Prod-System auf OpenHab2 komplett neu aufbauen und aktuelle Tinkerforge Komponenten integrieren. Vom Aufbau würde ich wieder 5mm Acryl nutzen, die Bricklets würde auf einem Basis-UnterRahmen befestigt und mit einem „Abdeckrahmen“ mit entsprechenden Ausschnitt für die Bedienelemente geschützt. Im groben würde folgenden Komponenten in diesem Bedienfeld verbaut sein 1x LCD 128x64 1x Multi-Touch mit 4x3 Key-Pad 1x NFC 1x Dual Button 1x Rotary Encoder 1x Rotary Poti bis auf den Dual-Button sind es im Grunde nur entsprechende Ausschnitte / Bohrungen in der Bedienfeld-Abdeckung. Siehe die Grob-skizze unten. Ich würde vermuten dass mir die reinen Abdeckungen ausreichen würden, hast Du auch ein Bild wie diese Abdeckungen ohne Gehäuse aussehen (evtl wenn sie auf dem Dual-Button liegen) ? Selber steht mir kein 3D Drucker zur Verfügung. Daher würde ich gerne auf Dein Angebot zurück kommen. Jetzt und hier ein große Lob an das gesamte Tinkerforge TEAM 🙂 viele Grüße Stefan
  6. Hallo Erik, Thema on/offline Meldung „Thing“ Dämon. Die Meldung „Bridge of [UID] went online “ sehe ich für alle Bricklets und den Masterbrick der über den Dämon verwaltet werden. Ich sehe aber keine Meldung dass der Dämon online geht. Meine Rule nutze folgenden Trigger und schaltet eine der beiden LED des Dual-Button ein / aus. Gerade eben musste ich feststellen dass die doch Rule funktioniert, auch wenn ich keine „online-Meldung“ des Thing-Dämon im Log sehe. Dass ich fälschlicherweise dachte die Rule funktioniere nicht mehr, hatte einen anderen Grund. Beim neu anlegen der Things, hatte ich für den Dual-Button in der Konfiguration vergessen die beiden LED auf „Channel default on“ zu konfigurieren. Nachdem die LED‘s nicht auf die Zustandsänderung des Dämon reagierten, dachte ich es lag an der fehlenden Meldung im Log. Mit anpassen der Dual-Button Konfiguration waren die LED‘s auch wieder vorhanden und bei der Zustandsänderung des Dämon wurden sie ein / ausgeschaltet. Sorry mein Fehler, Asche auf mein Haupt. Beta 20 habe ich eingespielt, jetzt funktioniert das IO-16 (alt) und auch die Darstellung der Port Konfiguration des IO-16 / IO-16 2.0 / IO4 2.0 zeigt jetzt den richtigen Text an 🙂 Danke für die schnelle Reaktion 🙂 viele Grüße Stefan
  7. Hallo Erik, wow ich war ganz erstaunt als ich sah, dass Du auch am Sonntag die Forum-Einträge liest. Alle Achtung Beim Update auf Beta 19 hatte ich für ein Bricklet einen Fehler die ich nicht beheben konnte. Alle Bricklets bis auf ein „altes“ IO-16 (HW Version 1.1.0 /FW Version 2.0.3 ) gingen wieder online. Um einen Fehler auszuschließen, habe ich anschließend alle Things inklusive der Tinkerforge Dämons deinstalliert und anschließend das System neu gestartet. Auch dann konnte ich das IO-16 nicht online nehmen. Es erschien im Log immer folgende Fehlermeldung Erst nach einem Restart von Openhab konnte ich das IO-16 aus der Konfiguration entfernen. Das IO-16 2.0 und das IO-4 2.0 ließen sich ohne Probleme online nehmen. Weiter ist mir aufgefallen, das sich bei der Port Konfiguration des IO-16 / IO-4 (HW 2.0) die Darstellung fehlerhaft ist. Immer wenn ich auswähle „output (Initial low)“ und dies speichere, erscheint bei erneutem Aufruf der Port Konfiguration der Text „Add or search“. In der Übersicht des IO-16 Thing wird angezeigt dass der Port als Output Konfiguriert ist, aber mit Status Low / High Es ist auch egal ob ich über Firefox oder Chrome das versuche. (siehe auch Bild im Anhang) Weiter Frage: Hast Du die Online/Offline Meldungen der Things / Dämon usw verändert ? Ich habe mir eine Rule gebaut, die das off und online gehen der beiden „Dämon‘s“ (WIFI & USB/HAT) überwacht. Offline Meldungen kommt für Things & Dämon, jedoch sehe ich im Log nur noch die „changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE“ Meldung für die Things (Bricklets) aber nicht mehr für den Dämon. Somit funzt meinen Rule zur Überwachung der Dämons nicht mehr. (Übrigens seit Deinem Beta18 Update hatte ich keine „Ungeplanten“ Dämon Aussetzer mehr) Bis jetzt sind keine weiteren Fehler bei „alten“ Rule‘s / Things aufgefallen. Weiter mit dem Test des Tinkerforge NFC Bricklet (HW Version 1.0.0 / Modell-ID 286 / FW Version 2.0.1) Das Auslesen der TAG-ID hat beim zweiten Anlauf funktioniert. Nachdem ich nicht so ein JAVA Fachman bin, verstehe ich nicht so ganz was die beiden Zeilen in Deinem Beispiel bedeuten. Sie haben bei mir einen Fehler im Log verursacht. Nachdem ich für den NFC-Status aber ein „Number-Item“ mit dem entsprechenden Channel verlinkt habe, habe ich Deine Rule auf diese „Item-Status-Abfrage“ umgebaut und die Rule hat funktioniert. Frage: Was ist die Aufgabe des „newState“ value ? Ich sehe schon um das NFC optimal nutzen zu können, müsste ich tiefere JAVA Kenntnisse haben, denn Deine Zeilen aus der Beispiel Rule sind für mich schon fast „grosses JAVA Kino“ 😉 Bis auf ein paar ältere 10-polige V1 Bricklets (Humidity / Temperatur / Industrial Quad Relais / Dual-Relais /PTC ) die noch in meiner Produktiv Umgebung verbaut sind, habe ich alle mir zur Verfügung stehenden Brickles in meine Test eingebunden. Ich hoffe diese alten Bricklets auch mit dem neuen Binding funktionieren, dies sehe ich aber erst wenn ich die Prod Umgebung von Openhab 1.9 auf 2.x umstelle. Ich würde noch zwei weiter Bricklets testen, aber beide sind leider nicht über Euren Shop verfügbar a) das neue „Servo-Brick“ dass sich noch in Entwicklung befindet (wird es auch vom Binding unterstützt ?) b) das PTC-Bricklet 2.0 (ist aktuell nicht verfügbar) Was mir Echt gut gefällt ist, Euer Dual-Button-Bricklet 2.0 Frage: Gibt es eine passende „Taster-Abdeckung“? Wenn man diese in ein Paneel einbaut, wäre es viel schöner wenn man eine Abdeckung dafür hätte. Ich werde noch weiter an den Rule‘s Testen und berichten. Viele Grüße Stefan P.S. Ich weiß ich werde mir jetzt den Unmut vieler Openhab 2.x User zuziehen, aber bei großen Umgebung finde ich die alte, über einen Thing-Datei Konfiguration, übersichtlicher. Welche Negativen Auswirkungen hätte die Nutzung einer "Thing" Konfiguration's Datei anstelle der GUI ? Wird es auch mal eine Anleitung geben, wie ich diese Tinkerforge Thing‘s Datei anlegen müsste ?
  8. Hallo Max jetzt mal unabhängig von Eriks Hinweis bezüglich des Restart. Kann es sein, dass Du noch mit einem alten Binding arbeitest ? Wenn ich das richtig sehe enthält Dein Channel noch die ID des TF-Dämons. Erik hat in den verschiedenen Bindings das System ein paar mal umgebaut, mal waren die „Dämon-ID‘s“ Bestandteil des Channel, mal nicht. In den letzten Bindings ist die Dämon-ID nicht mehr Bestandteil des Channel. Dieser Umbau hat zur Folge dass Du Deine Channel-Verlinkung der Item‘s und auch die Rule‘s mit Channel Trigger auf die neue Schreibweise anpassen musst. Welche Binding Version hast Du ? Dein Aufruf (siehe markiert, Deine Dämon-ID ) Mein Aufruf (gilt für Binding Beta18/19) viele Grüße Stefan
  9. Hallo Maxicko, ich will mich nicht mit fremden Federn schmücken, die Berechnung für die absolute Luftfeuchte habe ich im OpenHAB Forum gefunden. Den Link selber hab ich nicht mehr, aber den Org Text. Diese Rule ist die Basis meiner Rule, ich hab sie nur noch um einige funktionen erweitert. das ganze war noch für openhab1, vermutlich kannst Du jetzt die meisten Imports weg lassen. Um sicher zu gehen dass dies Berechnung korrekt ist, habe ich mit verschiedenen Temperatur und Luftfeuchte Werten über einen Website (die Berechnung der absoluten Luftfeuchte anbot) die Ergebnisse überprüft. Es waren nur vernachlässigbare Abweichungen fest zu stellen. viele Grüsse Stefan
  10. Hallo Riro, (hallo Erik) freut ich dass meine mini Anleitung geholfen hat 🙂 Ich selbst nutzte nur lieber Rules als .js Bezüglich Deiner Fehlermeldung, da müsstest Du Dich hier im Post an "Erik" wenden, er erstellt das Binding (ist ja noch in der BETA-Phase) . Er kann besser beurteilen ob diese WARN Meldung kritisch ist oder nicht. Ich gehe da manchmal brute-force vor und lösche den Dämon und richtig Ihn wieder neu ein (nur aufpassen dass du Dir die alte Dämon - ID merkst, dass du diese beim neu Anlegen des Dämon eintragen kannst, sonst würden alle Deine LinkChannel nicht mehr funktionieren >> ID ist Bestandteil des Channel). Viele Grüsse Stefan
  11. Hallo riro ich habe das Outdoor Weather Bicklet gemeinsam mit dem TH-6148 Sensor von Tinkerforge im Einsatz. Der Sensor liefert Temperatur & relative Luftfeuchte und einen String wann der letzte Datensatz empfangen wurde. Wenn Du die Outdoor Weather Station hast, dürfte das vorgehen ähnlich sein, nur dass diese mehr Daten übermittelt als der TH-6148 Sensor. Als erstes muss Du den Sensor Identifier (für den TH-6148) oder den Station Identifier (für die WS-6147) ermitteln. Das kannst Du über den Brickviewer oder du legt ein entsprechendes „String-Item“ mit dem passenden Channel des Outdoor Weather bricklet an. Die benötigten Channel findest Du im Konfigurations-Menue des Outdoor Weather Brickelt (Thing) Es kann etwas dauern bis dir dann über das Sting-Item der passende Identifier angezeigt wird. Beispiel meines ITEM‘s zum auslesen der Sensoren ID Weiter mit anlegen/erzeugen des Sensor als „Thing“ Unter Paperui / Configuration / Thing, analog als ob du einen weitern Thinkerforge Dämon anlegen willst („MANUALLY ADD THING“) Hier werden dir alle möglichen Thing-Optionen des Tinkerforge-Binding aufgelistet. (siehe Bild unten) Wenn Du wie ich den TH-6148 Sensor hast, wähle diesen aus. Über das folgende Menü kannst Du nun die Grundkonfiguration des Sensor ausführen. 1) unter Bride Selection / Select a Bridge >> „brickletoutdoorweather ….“ auswählen 2) unter Configuration Parameter die ID des Sensor eintragen 3) speicher und schon wirst du ein neues Thing unter Configuration finden. Wenn Du nur Temperatur / Humidity / Last Change Daten haben möchtest benötigst Du keine Action da reichen entsprechende ITEM-Channel Verlinkungen in der ITEM Datei aus. Beim TH 6148 Sensor gibt es etwas zu beachten. Nach einem Batterie Tausch erzeugt er eine neu ID (gibt hierzu einen Post von Erik), und diese musst du dann über das „Konfiguraion‘s Menue“ des Thing TH-6148 anpassen (siehe oben Punkt2). An den rules oder der Item-Channel-Verlinkung musst Du nichts anpassen. Ich hoffe diese mini Anleitung hilft Dir viele Grüsse Stefan
  12. Hallo Erik ich habe jetzt auf Basis Deines Vorschlag bezüglich „Thing-Status“ meine StartUp-Rules umgebaut. Es hat sich einfach umsetzen lassen 🙂 Meine Rule reagieren jetzt auf Zustands-Änderungen von >> Thing Bricklet >> Thing Masterbrick >> Thing Dämon Es klappt sowohl der Thing Trigger um eine Rule zu aktivieren, als auch die Status-Abfrage mit „getThingStatusInfo“. Mit Deiner Vorgehensweise ist man viel flexibler und kann individueller auf „Ausfälle“ und "Ladezeiten" (beim StartUp) reagieren. Ich ziehe offizielle meine Anfrage nach einer Dämon Initialisierung-Channel zurück 🙂 Weiter mit meiner „Temperatur Mess-Differenz“ Problematik Ich habe jetzt die beiden TH-6148 und das Humidity 2.0 über die letzten Tage verschiedenen Temperaturen ausgesetzt (15 Messzeitpunkte). Die Temperatur-Differenz ist nicht linear und ich kann keine kläre Linie erkennen. Der Unterschied liegt zwischen 0 und 1,5 Grad. Hintergrund meiner Frage: Ich berechne mit den Messwerten (Temperatur / relative Luftfeuchte) die absolute Luftfeuchte innen/außen und eine Rule steuert darüber das Lüftungsverhalten. In meiner Rule habe ich eine Messtoleranz (innen/außen Sensor) von 2,5% berücksichtigt. Kannst Du sagen welche Sensoren-Typen genauer sind, ich vermute mal der Humidity 2.0, oder ? Viele Grüße Stefan
  13. Hallo Erik ich glaub ich hab das ganze viel zu kompliziert erklärt. Dein Vorschlag ist wesentlich eleganter als mein ursprüngliches Ansinnen. Ich wollte einfach nur verhindern, dass während der Hochlauf-Phase viele Fehlermeldungen produziert werden und gleichzeitig meine „brute-force“ Lösung mit dem Wait-Timer nicht mehr benötigt wird. Deine Idee gefällt mir echt gut, ich werde Sie am Wochenende mal in den Rules mit Action versuchen einzubauen. Eigentlich könntest Du das mit dem Dämon Initialisierungs-Channel jetzt schon von Deiner To-Do Liste streichen, denn Dein Vorschlag gefällt mir viel besser als mein Ursprungs-Gedanke. Zum neuen Binding B18 Bis jetzt habe ich keine Error‘s im Log gefunden. Es gab nur eine Warn-Meldung, die aber unkritisch ist Einen TimeOut des Dämon hab ich bis jetzt auch noch keinen gesehen, nachdem der letzte Reboot aber erst gut 24 Stunden her ist, werde ich das Thema noch weiter beobachten. Zum Thema Mess-Unterschiede Humidity Bricklet vs TH-6841, ich hab meinen zweiten TH-6841 neben das Humidity Bricklet gelegt, muss aber noch abwarten bis sich dieser an die Raumtemperatur angepasst hat (war bis eben noch im Kühlschrank 😉 ) Viele Grüße Stefan
  14. Hallo Erik zu Deiner Frage: wie formuliere ich meinen Gedanken am besten. Eigentlich wollte ich nur so eine Art „Statusmeldung“ dass der Dämon nach einem „Neustart/Reboot“ seinen Startup Prozess abgearbeitet hat. Beispiel: Das Humidity-Bricklet 2.0 ist über Dämon-A (z.B. WIFI) angebunden und liefert sehr früh nach einem Startup schon Daten. Die zugehörige Rule soll ab einem Schwellwert auf dem LCD128x64 Daten ausgeben. Das LCD128x64 ist über Dämon-B angebunden (z.B. Masterbrick per USB angeschlossen). In der Hochlaufphase kommt es vor, dass Dämon-A schon fertig alle Komponenten initialisiert hat, und dessen Brickles schon Daten lieferten, während Dämon-B noch beim initialisieren ist (da dieser für mehr Bricklets zuständig ist). Folge ist, dass Unmengen an Fehlermeldungen durch die Rules in das Log geschrieben werden. Ein ähnliches Problem hatte und habe ich auch bei meiner Openhab1 Konfiguration (ca 15 TF Komponenten ). Um diesen „Log-Spam“ zu umgehen und die Lesbarkeit des Log zu erhalten, habe ich damals (openhab1) einfach eine Timer-Rule eingebaut, die 60 Sekunden nach der „System Started“ Meldung ein ITEM mit Namen „SystemOnline“ vom Typ CONTACT auf Closed gesetzt hat. Alle anderen Rule‘s fragten ab, ob „SystemOnline“ den Status CLOSED hat und nur wenn dieses den Status CLOSED hatte, durften die Rules „loslegen“. Mit dieser Regel konnte ich zwar den Log-Spam beseitigen, aber gerade während der Test-Phase hat dies zu laaaaaaaangen Wartezeiten geführt. Bei meiner Frage an Dich, war mein Hintergedanken diese statischen langen Wartezeiten durch den Timer verhindern zu können, in dem das Binding melden würden, wenn es seine Startup Routine abgearbeitet hat. Deine Idee auf den Thing-Status zur reagieren, finde ich aber echt gut. Beispiel wie ich meine Rule‘s „warte bis der TF-Dämon den Init-Lauf abgeschlossen hat“ aufbauen würde. (so ähnlich funktioniert es mit meiner Timer-Rule in openhab1). Mein Gedanke hat allerdings einen Haken. Die Rückmeldung des Binding darf nicht auf die Vollständigkeit der Komponenten mit Status-Online ausgelegt sein, sondern darf nur melden dass der Initialisierungs-Prozess durchgelaufen ist, auch wenn Komponenten „offline“ sind. Beispiel: Ein Dämon kennt ein Bricklet das über eine Masterbrick der per RS485 Extention an den Masterbrick der per USB an das System angeschlossen ist. Wenn nach einem Reboot die Spannungsversorgung des „abgesetzten Masterbrick-Stapel“ nicht mehr funktioniert und der Dämon nur eine Meldung absetzten würde wenn alle Bricklets die er kannte und kennt online sind, würde es bedeuten dass obige Rule „Rückmeldung Dämon Init ausgeführt“ erst aktiv wird, wenn ALLE Komponenten wieder online sind. Somit würden alle Rule‘s die diese positive Rückmeldung benötigen, auf ewig inaktiv bleiben. Da stellt sich die Frage, was und wann soll der Dämon nun melden ? Ich bin mir jetzt echt nicht sicher ob Dein Vorschlag in der Hochlauf-Phase auf die Online-Meldungen der Bricklets zu reagieren nicht sinnvoller wäre. Das ist jetzt viel Text zu lesen, ich wusste aber nicht wie ich es (Inklusive der möglichen Probleme) beschreiben soll. Viele Grüße Stefan
  15. Hallo Erik ich habe soweit meine Test-Rules angepasst. Jetzt kommen nach dem System Reboot keine Fehlermeldungen mehr. Nach dem der System-based trigger „System startet“ meldet, läuft ein Timer an der nach 60 sec das Item „Online“ vom Typ Contact auf Closed setzt. Alle relevanten Rules prüfen nun ab, ob das ITEM Online den Status Closed hat. Nur dann dürfen sie los legen. Um keine „Error-Meldungen“ zu verpassen, habe ich noch das Add-ON „LogReader“ eingebunden und konfiguriert. Wenn eine neue Error-Meldung im Log erscheint gibt der Piezo Speaker einen kurzen Beep ab. Ich muss mal schauen dass ich auch die "offline-Meldungen" für den Dämon mit erfasse (aktuell werden nur "ERROR" berücksichtigt). Zum Thema Temperatur Mess-Differenz zwischen HumidityBricklet 2.0 und Sensor TH-6841 Ja das Humidity-Bricklet gibt die um ca 1.2 Grad höher Temperatur als der TH-6841 Sensor aus. Frage, was verstehst Du unter „hohen“ Sampel Rate ? Ich habe aktuell eine SampeRate von 0.1 und eine „Temperatur Moving Average Length“ von 5. Zu Meiner Frage „Funksteckdosen Fernbedienung“ für Rule Steuerung nutzen. Nachdem ich sah, dass beim betätigen der Fernbedienung im Log erscheint, wollte ich die Daten per Action „brickletRemoteSwitchV2GetRemoteStatusA“ auslesen. Meine Rule sieht wie folgt aus: leider funktioniert die Rule nicht. Siehe Fehlermeldung in Line 228 steht Ich weiß leider auch nicht wo mein Fehler liegt. Zu Deinem Vorschlag Das habe ich noch nicht probiert, ich denke dann müsste ich aber alle relevanten Bricklet auf diese Weise in einer Rule abfragen und über eine "Merker-Varialben / Item" den Status vorhalten. Das muss ich mal testen, ob ich damit in den Rules klar komme. Deutlich einfacher wäre es wenn diese über den Dämon gemeldet wird 😉 Ich werde das mal auf meine Wochenende Test-To-Do Liste setzten Viele Grüße Stefan P.S Die Log-Meldungen kann ich erst heute Abend in aller Ruhe kontrollieren
×
×
  • Create New...