Autor Thema: FileLog soll regelmäßig Werte auch ohne Event "pollen" - elegante Lösung?  (Gelesen 1361 mal)

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
FileLog schreibt ja nur Werte, wenn ein entsprechendes Event auftritt.
Gibt es eine elegante Möglichkeit in regelmäßigen Abständen die im FileLog definierten Quellen zu "pollen" um so "Stützpunkte" für die Diagramme zu generieren?
Ich denke eine im FileLog selbst integrierte Lösung wäre am idealsten?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
Kannst du den Thread bitte von "Forum-Software" wegverschieben?

Zur Lösung des Problems "Plot-Abriss vermeinden" gibt es einen Artikel im Wiki, die elegante Variante ist vermutlich LogProxy...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21661
Zitat
Gibt es eine elegante Möglichkeit in regelmäßigen Abständen die im FileLog definierten Quellen zu "pollen" um so "Stützpunkte" für die Diagramme zu generieren?
Das habe ich selbst nach dreimaligen Lesen nicht verstanden.

Was ich per "Brainstorming" liefern kann:
- es gibt ein inotify Modul (Linux-only)
- wenn ein notify mit den gleichen Regexp wie FileLog bestueckt ist, dann kann man eine Aktion ausfuehren.
- SVG versucht bei longpollSVG die Grafik zu refreshen. Ist aber nicht perfekt.

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
Zur Lösung des Problems "Plot-Abriss vermeinden" gibt es einen Artikel im Wiki, die elegante Variante ist vermutlich LogProxy...

LogProxy hilft mir doch auch nicht wenn die letzte Statusänderung / der letzte Eintrag ein Monat zurück liegt und ich mir den Plot der letzten 24h ansehe?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
@Rudi:
Verstanden habe ich das auch nicht ganz, hatte aber den Eindruck, dass das nahe bei der Diskussion rund um diesen Beitrag ist: https://forum.fhem.de/index.php/topic,106385.msg1002414.html#msg1002414.

(Und da du Mod bist: Magst du ausnahmsweise diesen Beitrag verschieben; gehört vermultlich zu FileLog=>Automatisierung)

@chunter1:
"Kleben" der logfiles und ggf. die Zeitgrenzen in LogProxy entsprechend anpassen _könnte_ helfen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
Das habe ich selbst nach dreimaligen Lesen nicht verstanden.

Was ich per "Brainstorming" liefern kann:
- es gibt ein inotify Modul (Linux-only)
- wenn ein notify mit den gleichen Regexp wie FileLog bestueckt ist, dann kann man eine Aktion ausfuehren.
- SVG versucht bei longpollSVG die Grafik zu refreshen. Ist aber nicht perfekt.

Sorry, ich versuchs mal so...
Ich hab z.B. folgendes FileLog definiert das alle Daten einer Heizungssteuerung mitloggt:

define FileLog_COE_Node_CMI_2 FileLog ./log/COE_Node_CMI_2-%W.log COE_Node_CMI_2
In diesem Fall werden alle Readings von "COE_Node_CMI_2" bei einem entsprechenden Event geschrieben.
Es wäre doch praktisch wenn man mittels attribut das FileLog anweisen könnte, dass alle z.B. 60 Sekunden alle Readings des device "COE_Node_CMI_2" gelesen und geloggt werden sollen.
Wenn im Filelog explizit einzelne Readings angegeben werden, dann sollen nur diese "gepollt" werden.

Ich weiß nicht ob das eine gute Idee ist - ich möchte nur fehleranfällige Redundanz vermeiden und denke, dass eine direkte Integration in FileLog am elegantesten wäre?

« Letzte Änderung: 19 Dezember 2019, 14:13:35 von chunter1 »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21661
Wozu pollen, wenn die Events selbst kommen?
Wenn zu viele kommen, dann kann man sie entweder per event-min-interval oder sonstwie begrenzen.
Wenn zu wenig, wieso was erfinden? Nur damit die Linie schoen ist?
Wenn einen nur Stunden/Tages/etc Werte interessieren, dann berechnet man diese erst (per statistik/etc) und zeichnet nur diese auf.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
Auch zwischenzeitlich fertig getippt...

MMn ist das keine so tolle Idee, warum sollte was geloggt werden, ohne dass tatsächlich ein zugehöriges Event stattgefunden hat?

Soweit es um die "Schönheit" von SVGs geht, kann ich das nachvollziehen, aber alles andere ist nur "Stress" bzw. "Datenmüll".

@Rudi:
Die "addLog"-Variante aus dem Wiki hat aber mindestens den Nachteil, dass (allgemeine) Events erzeugt werden, nur um Logeinträge zu erzeugen.
Vielleicht könnte man eine (Perl-)-Anweisung zulassen, mit der nur FileLog angewiesen wird, eine Art "addLog" zu schreiben? (Der Spur nach: filelogtrigger("<device>","<Event>")).

(OT: In dem anderen Thread gab es eine Diskussion, ob man für FileLog ggf. separate "event-on-" Attribute haben sollte, um weniger/nicht alle Events zu loggen; ist mMn unnötig, aber evtl. siehst du das ja anders...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
Wozu pollen, wenn die Events selbst kommen?
Das Problem ist ja, dass eben keine Events kommen weil z.B. die Heizkreispumpe seit Monaten durchläuft.
Das erste Event das im Jahre vorkommt ist z.B. am 1. Oktober wenn die Pumpe von aus auf ein geht.
Das zweite Event ist dann im April wenn die Pumpe von ein nach aus wechselt.

Wenn zu wenig, wieso was erfinden? Nur damit die Linie schoen ist?
Sie sind ja nicht unschön sondern gar nicht vorhanden. :)
Meine Filelogs sind immer Wochenweise - also mit "%W".
Ich verwende auch "creategluedfile".
Das alles hilft aber nicht wenn das letzte Event Monate zurückliegt und ich mir nur den aktuellen Tag ansehe.

Ich finde z.B. alle 24h einmal alle Stati zu lesen und ins FileLog zu schreiben keinen Datenmüll sondern Konistenzsteigerung :)
« Letzte Änderung: 19 Dezember 2019, 14:55:02 von chunter1 »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
OK, für solche Sonderfälle kann ich es nachvollziehen, dass man irgendwann einen Status schreibt...

Warum dann nicht die "addLog"-Variante aus dem Wiki? Hängt an dem/den Events noch mehr dran an Eventhandlern? (ggf.: kann man die begrenzen, dass die nicht auf "addLog"-endende trigger reagieren?)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
Warum dann nicht die "addLog"-Variante aus dem Wiki? Hängt an dem/den Events noch mehr dran an Eventhandlern? (ggf.: kann man die begrenzen, dass die nicht auf "addLog"-endende trigger reagieren?)

Naja, addLog ist zwar nett, aber meiner Meinung nach eben eine parallel existierende, redundante und fehleranfällige (Vergessen/Übersehen) Lösung.
Erfahrungsgemäß sind Umsetzungen die nur an einem einzigen Punkt gewartet/geändert werden müssen am idealsten.
Alle Infos sind ja in der Definition von FileLog selbst schon vorhanden - einzig ein Timer fehlt (einfach gesagt :) )

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 5934
dad geid so nischd ....

flielog ist doch praktisch ein "notify fürs Wegschreiben ins log" (Sorry fürs vereinfachen).

Wenn Du z.B. auf *broetchen* trickerst, um alle brötchensorten (wurstbroetchen, kaesebroetchen) wegzuschreiben, wie soll dann das filelog Wissen, was es für brötchen gibt? Falls der RegEx Ausruck noch komplizirter wird, z.B. +(broetchen|semmel)* würde es noch viel Komplizierter ....

Edit:
Beta-User hat es (unter diesem Beitrag) sogar besser erklärt: Stichwort Eventbasiert
« Letzte Änderung: 19 Dezember 2019, 15:33:23 von Wernieman »
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
Na ja, m.E. ist das "Problem", dass FileLog eventbasiert arbeitet und daher eben auf die entsprechenden Strukturen zugreift
(https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/92_FileLog.pm#L184). Ob die nach der Event-Verarbeitung noch existieren, kann ich nicht definitiv sagen, vermute aber eher nicht...
Wenn die Vermutung stimmt, hat FileLog eben nicht alles an Infos zum loggen, sondern außerhalb der Eventverarbeitung keine Ahnung, was es tun soll ;) .

Auf die Devices/Readings rückwärts zu kommen, würde vielleicht noch gehen (devspec2array), aber dann müßte man wissen/davon ausgehen, dass dann alles geloggt werden soll. Das Abgrenzen der wichtigen/wirklich gewünschten Daten geht "anders rum" (via addLog) mMn. viel eher.
(Ich selbst nutze übrigens DBLog, von daher existiert das Problem für mich so nicht...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline chunter1

  • Sr. Member
  • ****
  • Beiträge: 831
(Ich selbst nutze übrigens DBLog, von daher existiert das Problem für mich so nicht...)

Ok, ich denke, ich werde mir mal das DBLog genauer anschaun (obwohl mir noch ein Server und dessen Wartung/Probleme etc. gar nicht gefällt).

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
Na ja, habe auch lange gezaudert (und weiß bis heute nicht, ob das aus den von dir genannten Gründen eine für mich weise Entscheidung war; plotten geht damit jedenfalls deutlich schneller und man hat _eine_ Datenbasis, was die Auswertung "crossover" vereinfacht)...
Die mariadb liegt auf demselben Server (kein Pi!).

Aber auch da mußt du ggf. mit logProxy erst einen "ersten Wert" finden lassen (oder die dortige addlog-Funktion nutzen), von ganz alleine geht das auch mit DBLog nicht. Von daher würde ich eher die simple "addLog"-at-Variante empfehlen, wenn das sonst für dich paßt.

(Ich habe das nur erwähnt, damit keiner den Eindruck hat, ich würde mich aus eigennützigen Motiven mit dem FileLog-Code rumschlagen, dann aber um die Umsetzung drücken...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21661
Ich habe die FileLog Attribute addLog und filelog-event-min-interval hinzugefuegt:
Zitat
addLog
    This attribute takes a comma-separated list of devspec:reading:maxInterval
    triples.  You may use regular expressions for reading. The last value of
    the reading will be written to the logfile, if after maxInterval seconds
    no event for this device/reading has arrived.

filelog-event-min-interval
    This attribute takes a comma-separated list of devspec:reading:minInterval
    triples.  You may use regular expressions for reading. Events will only be
    generated, if at least minInterval seconds elapsed since the last reading
    of the matched type.
Gefällt mir Gefällt mir x 3 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9259
  • eigentlich eher "user" wie "developer"
Thx!

@amenomade hatte dankenswerterweise bereits einen Hinweis im Wiki bei Plot-Abriss eingetragen, hab's jetzt noch etwas umstrukturiert.

Dazu eine Frage zur commandref:
Ist "Events will only be generated..." zutreffend? Oder sollte da "logged" stehen?

(Etwas OT: Es hat mich etwas gewundert, dass das Timer-Thema Eingang gefunden hat, nicht aber das Hysterese-Ding aus "event-on-change..", um das Logging ggf. zu reduzieren. Der Grund wäre interessant, oder war's "nur" das Aufwandsthema? (Ist nicht als Kritik gemeint, reines persönliches Interesse, und ich bruache auch nicht unbedingt eine Antwort dazu!))
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21661
Zitat
Ist "Events will only be generated..." zutreffend? Oder sollte da "logged" stehen?
Natuerlich Letzteres, habs korrigiert.

Wg. event-on-change-:
- insb bei der Kombination dieser Attribute wird es zunehmend kompliziert und Fehleranfaellig.
- ich meine immer noch, dass diese Attribute nicht wirklich notwendig sind. Und bei Weihnachts-Geschenken ist irgendwo Schluss :)
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline Maista

  • Full Member
  • ***
  • Beiträge: 342
@rudolfkoenig

Hallo Rudi,

seit dem Update von 92_FileLog.pm am 19.12.19 funktioniert bei mir das Schreiben von Daten in einer bestimmten Konstellation nicht mehr.

Ich hole mir von meiner Fritzbox mit dem Modul FBREMOTE die Pegel des Kabelmodems.
Die stehen in einem Reading ZKanal.
Wenn das gelesen wurde, rufe ich ein Notify auf welches ein myModul aufruft. In diesem generiere ich jeweils neue Readings für das Modul FBREMOTE.

   fhem("setreading FB6490 RxFrequenz $RxFrequenz"); #Reading setzen
Das funktioniert soweit alles.

Wenn nun dieses Reading gesetzt wurde wird das Logfile geschrieben.

Internals:
   CFGFN      /opt/fhem/FHEM/fritzbox.cfg
   DEF        /opt/fhem/log/FileLog_DOCSIS-%Y-%m.log FB6490:RxFrequenz|FB6490:RxPowerLevel|FB6490:RxMSE|FB6490:Rxkorr_Fehler|FB6490:RxNicht_korr_Fehler|FB6490:Frequenz|FB6490:TxFrequenz|FB6490:TxPower_Level
   FD         10
   FUUID      5d99d47f-f33f-e1be-c968-e726c86566fd22fd
   NAME       FileLog_DOCSIS
   NOTIFYDEV  FB6490
   NR         127
   NTFY_ORDER 50-FileLog_DOCSIS
   REGEXP     FB6490:RxFrequenz|FB6490:RxPowerLevel|FB6490:RxMSE|FB6490:Rxkorr_Fehler|FB6490:RxNicht_korr_Fehler|FB6490:Frequenz|FB6490:TxFrequenz|FB6490:TxPower_Level
   STATE      active
   TYPE       FileLog
   currentlogfile /opt/fhem/log/FileLog_DOCSIS-2019-12.log
   logfile    /opt/fhem/log/FileLog_DOCSIS-%Y-%m.log
   READINGS:
     2019-12-24 16:31:43   linesInTheFile  19757
Attributes:
   createGluedFile 1
   room       1Testen,Ereignisse->FB,Logs,System

Seit einem Update am 22.12. wurde das nicht mehr geschrieben.
Ich habe das erst heute bemerkt und einige Zeit damit verbracht und es nicht mehr zum schreiben bewegen können.
Ich hatte auch schon
REGEXP     FB6490:RxFrequenz..*|FB6490:RxPowerLevel..*|FB6490:RxMSE..*|FB6490:Rxkorr_Fehler..*|FB6490:RxNicht_korr_Fehler..*|FB6490:Frequenz..*|FB6490:TxFrequenz..*|FB6490:TxPower_Level..*probiert, aber half ebenfalls nichts.

Selbst mit der Event-Monitor-Funktion die Defines dazu erzeugt funktionierte es nicht.
Erzeugt wurde hierdurch:
DEF ./log/FB6490_FileLog_1.log FB6490:RxFrequenz:..*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*Was aber zu keinem Eintrag führte.

Der Mittschnitt im Event-Monitor sieht so aus:
Zitat
2019-12-24 16:31:43 FBREMOTE FB6490 RxFrequenz: 578 490 522 530 538 546 562 570 474 594 626 642 650 658 666 674 682 690 698 706 746 754 762 770
2019-12-24 16:31:43 FBREMOTE FB6490 RxPowerLevel: 5.9 8.4 6.6 6.2 5.6 5.7 5.8 5.8 8.9 6.7 8.1 8.7 9.0 9.2 8.9 8.9 8.9 8.7 8.7 8.7 8.2 7.2 7.3 6.4
2019-12-24 16:31:43 FBREMOTE FB6490 RxMSE: -37.4 -37.4 -37.4 -37.4 -36.6 -36.6 -37.4 -37.4 -39.0 -37.6 -38.6 -39.0 -38.6 -38.6 -39.0 -37.6 -38.6 -38.6 -38.6 -38.6 -37.6 -37.6 -37.6 -37.4
2019-12-24 16:31:43 FBREMOTE FB6490 Rxkorr_Fehler: 22098 189 130696 370 536 588 516 390 184 176 101 110 126 115 151 93 99 69 87 86 95 92 104 130
2019-12-24 16:31:43 FBREMOTE FB6490 RxNicht_korr_Fehler: 0 0 0 0 102 0 0 0 0 0 0 0 95 0 99 0 96 0 409 0 0 0 0 0
2019-12-24 16:31:43 FBREMOTE FB6490 TxFrequenz: 45.2 58.4 51.8 30.8 37.4
2019-12-24 16:31:43 FBREMOTE FB6490 TxPower_Level: 41.8 41.0 41.3 42.8 43.2

Mit der Datei von
Zitat
# $Id: 92_FileLog.pm 20537 2019-11-18 21:28:30Z rudolfkoenig $
funktioniert es wieder.

Muss hier nun ein Attribut gesetzt werden oder ist das ein Bug?

Allen ein schönes Fest

Danke und Gruss
Gerd

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21661
Zitat
   REGEXP     FB6490:RxFrequenz|FB6490:RxPowerLevel|FB6490:RxMSE|FB6490:Rxkorr_Fehler|FB6490:RxNicht_korr_Fehler|FB6490:Frequenz|FB6490:TxFrequenz|FB6490:TxPower_Level
Achtung: dein Regexp wird in FileLog (und notify/etc) mit ^FB6490:RxFrequenz|...|FB6490:TxPower_Level$ geprueft, das ist vmtl. nicht das, was du willst.
Ich schlage als FileLog REGEXP (FB6490:RxFrequenz|...|FB6490:TxPower_Level) vor.

Zitat
Seit einem Update am 22.12. wurde das nicht mehr geschrieben.
Mag sein, ich kann das aber nicht nachvollziehen: mit der gezeigten FileLog Definition landen die setreading Daten aus dem angehaengten Event-Monitor Ausschnitt bei mir in der FileLog-Datei. Vermutlich fehlt mir noch ein Detail.

Zitat
DEF   ./log/FB6490_FileLog_1.log FB6490:RxFrequenz:..*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
Das ist ja haesslich, das habe ich jetzt etwas verschoenert.

Offline Maista

  • Full Member
  • ***
  • Beiträge: 342
Hallo Rudi,

danke für die Antwort.
Ich war gerade dabei zu schreiben das ich das Problem nun gefunden habe.

In meinem MyModul hatte ich die Readings (und fünf weitere) als Beispiel mit
   fhem("setreading FB6490 RxFrequenz $RxFrequenz"); gesetzt.

Mit dem alten 92_FileLog.pm funktionierte es bis vorhin wieder. Ich hatte aber das Moduls mit Komma anstatt mit Leerzeichen in den Globals als  Exclude stehen.
Dadurch wurde das alte Modul durch das neue beim Update wieder überschrieben.
Nach dem ich das alte wieder aufgespielt hatte wollte das setzten dann auch nicht mehr Funktionieren ::) :o

Schlussendlich habe ich dann die Commandref bemüht.
In der steht zu setreading:
Zitat
Note: setreading won't generate an event for device X, if it is called from a notify for device X. Use "sleep 0.1; setreading X Y Z" in this case.

In meinem myModul setze ich nun die Readings mit
   fhem("sleep 0.1;setreading FB6490 RxFrequenz $RxFrequenz");und nun wird das Reading wieder geschrieben!
Auch mit der neuen 92_FileLog.pm vom 22.12.19!

Das RegEx habe ich nun auch einfach gekürzt
FB6490:Rx.*|FB6490:Tx.*
Funktioniert also. Ist das eventl. ein Zeitproblem gewesen?

Zitat
Das ist ja haesslich, das habe ich jetzt etwas verschoenert.
Ok ;)

Danke für deine Info.

Eventl. probiere ich ob es mit deinem Vorschlag auch funktioniert.
Warum das bis zum 22.12 funktioniert hatte ist mir ein Rätsel.

Wenn nötig kann ich dir weitere Daten zu kommen lassen.

Dir noch schöne Feiertage

Gruss Gerd
« Letzte Änderung: 26 Dezember 2019, 00:35:14 von Maista »

 

decade-submarginal