"structure" und erzeugte events - Probleme

[Elektrolurch]

Hallo,

ich habe mir für die Beleuchtungen in verschiedenen Räumen "structure" angelegt.
Ziel war es u.a. ein Ereignis zu generieren, wenn das erste Licht im Raum angeht oder das letzte eingeschaltete Licht ausgeht.

Die Attribute für die structure sehen so aus:
alias Arbeitszimmer Licht
clientstate_behavior relative
clientstate_priority ein|on aus|off
eventMap /on:ein/off:aus/
room ts

Das notify sieht so aus:
[A-Z][a-z]_Lstruct:LastDevice_Abs.* {Log(1,"Lstruct_not: $NAME event: $EVENT"); my ($ev,$arg) = split(" ",$EVENT); AktivMon("INFO",AttrVal($NAME,'alias','nicht gefunden') . " " . Value($NAME) . '('.AttrVal($arg,'alias','???') . ' = '. Value($arg) . ')'); return undef;}

# der Log-Befehl ist nur zum Testen gewesen

Das erzeugt folgenden Output über AktivMon:
12:08:10 Büro Licht ein(Deckenlampe = ein)
12:08:36 Büro Licht aus(Deckenlampe = aus)


Soweit funktioniert das jetzt auch schon seit Monaten.

Aber:
Nun habe ich bei den FS20 zusätzliche readings (für den Stromverbrauch) angelegt und wenn ich diese per readingsBulkUpdate aktualisiere, wird auch das notify oben getriggert:

12:59:24 Büro Licht aus(Deckenlampe = aus)
12:59:24 Büro Licht aus(Deckenlampe = aus)
12:59:26 Büro Licht aus(Einbaulampen 1 in Galerie = aus)
usw.
obwohl ja kein Licht geschaltet wird.

Daraufhin habe ich die commandref gelesen (!)

clientstate_behavior relativeKnown
clientstate_priority ein|on aus|off

Dort steht:
▪ relativeKnown
Like relative, but do not trigger on events not described in clientstate_priority. Needed e.g. for HomeMatic devices.

Obwohl nun ja eigentlich beim Aktualisieren des readings 'power-hourly' kein Event mehr kommen sollte (clientstate_priority ein|on aus|off
), wird das notify oben weiterhin getriggert.

Also weiter probiert:

attr Az_LichtStruct event-on-change-reading state

und das notify oben auf [A-Z][a-z]_Lstruct:.* {  abgeändert.

Nun wird das notify überhaupt nicht mehr getriggert.

Okay, nächster Versuch:

event-on-change-reading wieder gelöscht.

Nun wird das notify getriggert und schreibt folgendes ins Log:

2014.11.03 15:40:41 1: Lstruct_not: Bu_Lstruct event: LastDevice: Bu_Deckenlampe
2014.11.03 15:40:41 1: Lstruct_not: Bu_Lstruct event: LastDevice_Abs: Bu_Deckenlampe
2014.11.03 15:40:41 1: Lstruct_not: Bu_Lstruct event: ein

2014.11.03 15:42:30 1: Lstruct_not: Bu_Lstruct event: LastDevice: Bu_WandLampe
2014.11.03 15:42:30 1: Lstruct_not: Bu_Lstruct event: LastDevice_Abs: Bu_WandLampe
2014.11.03 15:42:30 1: Lstruct_not: Bu_Lstruct event: ein


Obwohl
clientstate_behavior relativeKnown

gesetzt ist,
erzeugt das weitere Einschalten einer Lampe (Bu_Wandlampe) über den struct erneut ein "ein" - Event.

wenn ich event-on-change-reading ein|aus setze, bekomme ich überhaupt kein Event. Erwartet hätte ich, dass ich nur einmal ein "ein" beim Einschalten von "Bu_Deckenlampe" erhalte und kein Event "ein" beim Einschalten der zweiten Lampe  "Bu_Wandlampe".

Also, meine zwei Fragen:

1. Wie kann ich verhindern, dass das Schreiben von readings der Teilnehmer des structs den struct dazu veranlasst, events zu erzeugen?

2. Was muss ich tun, um nur das "ein" und "aus" Event (gem. Definition von "relative") zu erhalten, wenn die erste Lampe eingeschaltet, bzw. die letzte eingeschaltete Lampe ausgeschaltet wird?

Für qualifizierte "Erleuchtung" wäre ich dankbar.

Gruß

Elektrolurch

[rudolfkoenig]

Ich meine, dass deine Ueberlegungen richtig sind, und relativeKnowndas Problem loesen sollte.
Kannst du mir bitte eine nachstellbare Konfiguration hier anhaengen, ich wuerde mir das Erstellen dieser gerne sparen.

[Elektrolurch]

Hallo Rudi,

danke für das Angebot.
Da gibt es eigentlich nicht viel vorzubereiten:

Du hast doch bestimmt eine struct für Beleuchtung in einem Raum definiert.

Sagen wir mal mystruct.

Setze für mystruct:

clientstate_behavior relativeKnown
clientstate_priority ein|on aus|off

und dann ein notify:

define mystruct_not notify mystruct:.* {Log(1,"mystructnot: name: $NAME event: $event");}

Wenn Du dann auf einer der Komponenten des structs:

setreading mylamp1 power-hourly 1234

machst, so wie es bei mir jede Stunde erfolgt, müsstes Du Eintragungen im Log bekommen.

In meinem Beispiel oben aus Beitrag 1 wird führt das Setzen des readings bei "mylamp1" zum Triggern des notify mit:

Lastdevice_Abs mylamp1.


Gruß

Elektrolurch

[rudolfkoenig]

relativeKnown bewirkt, dass kein Event generiert wird, falls das status Reading des Geraetes bei _einem_ der Struktur-Mitglieder nicht im priority aufgezaehlt ist, es hat nichts mit dem aktuellen Event zu tun.

Eigentlich duerfte ein structure nur auf status-Aenderungen reagieren, aber man kann leider nicht explizit auf sowas testen, da als Spezialfall beim state-Events der Name des Readings weggelassen wird, damit man notifies auf "Lampe:on" machen kann, statt auf "Lampe:state:on".

-> Ich weiss zur Zeit keine Loesung fuer dein Problem. Falls jemand Ideen hat...

[Elektrolurch]

Okay. Danke für die Info.
"structure" scheint auch ziemlich viel Performance abzuziehen.
Ich baue ja gerade einen "EnergieMonitor", der einmal in der Stunde meine 42 registrierten devices im Sekundentakt abarbeitet und die readings für die Verbrauchsmessungen setzt. Durch das Setzen von "power-hourly" und den weiteren Zeitzählern wird auch jedesmal die mit der Lampe "assoziierte" structure getriggert. Dadurch erhöht sich die Verarbeitungszeit um fast 20 Sekunden. Ich habe jetzt mal die structure gelöshct und jetzt gehts rasend schnell.
Auch habe ich mehrere Gruppenschaltungen, die durch einen Schalter eingeschaltet werden. Da wurden die Lampen mit deutlicher Verzögerung von ca. 0.5 Sekunden und mehr hintereinander eingeschaltet. Nachdem ich die structure gelöscht habe, schalten die Lampen fast nun zeitgleich ein.

Werde wohl als Lösung lieber ein bisserl perl-Code schreiben, als structure zu verwenden.
Trotzdem Danke.

Gruß

Elektrolurch

[rudolfkoenig]

Structure ist zwar nicht extrem leichtgewichtig, andererseits kommen die von dir genannten Zahlen sehr hoch vor, und ich vermute, die sind nicht in structure selbst, sondern in den zusaetzlich generierten Events, bzw. deren Abarbeitung begruendet. Wenn du meinst, dass es doch an structure liegt, und du Lust hast ein Beispiel zusammenstellen, wo ich das nachvollziehen kann (siehe auch mseclog), dann wuerde ich das tun.

Tipp: falls das notify Regexp den Namen der Quelle exakt enthaelt (sichtbar an einem gesetzten NOTIFYDEV hash Eintrag), dann wird dieser nur fuer diese Geraete aufgerufen, und das spart auch ein bisschen Zeit. Also

Code Auswählen Erweitern

define n notify Schalter:on set Lampe on
ist besser als einer der folgenden, falls man nur einen Schalter hat

Code Auswählen Erweitern


define n notify Schalter.*:on set Lampe on
define n notify Schalter.* set Lampe on
define n notify .*on set Lampe on


[Elektrolurch]

Ok. Das ist ein Tipp.
Muss da mal meine notify's durchforsten.  Der Hinweis bezieht sich aber nur auf den Namensteil und nicht auf das Event.

Die sich beim Energiemonitor ergebenden Verzögerungen ergeben sich dadurch,
1. Das Setzen eines readings triggert "structure". Gesetzt werden je device und Stunde: power-hourly, power-weekly, power-monthly, power-yearly - also 4 x Mal.
2. Die Events landen im fhem-Bau und damit in der notifyFn des Energiemonitors. Da passt zwar das device, aber nicht das Event "LastDevice_Abs", somit wird es verworfen.

Da ich aber aus Performancegründen nicht einmal je Stunde alle devices aktualisiere, mache ich das gegen Ende der Stunde im Sekundentakt. Der InternalTimer wird immer nach Ablauf eines Berechnungszyklus für ein device neu berechnet. Auf Grund der Verzögerung durch structure-Event dauerte die Berechnung je device länger als 1 Sekunde, (ohne ca. structure ca. 0.3 Sekunden) und damit rutscht die Berechnung des nächsten devices in den übernächsten Zeitslot.

Werde mal sehen, ob ich da etwas "sparsamer" auch mit regex umgehen werde.

[gandy]

Hallo Rudi,

ich bin derzeit einem Problem auf der Spur, das wohl ebenfalls mit structure zu tun hat, deshalb möchte ich mich hier anhängen.

Das Problem besteht seit einigen Wochen und äußert sich darin, dass beim Fahren mehrer HM-gesteuerter Rollläden (bis zu 15 Stück) nach dem ersten jeweils eine sehr lange Pause entsteht, während der FHEM zu hängen scheint (ausführliche Besschreibung siehe im Beitrag http://forum.fhem.de/index.php/topic,29169.0.html)

Hintergrund: Die RolloSchalter01..15, im folgenden kurz RS01..RS15 sind in verschiedene structures gruppiert:

Code Auswählen Erweitern


define RolloSchalterAll structure room RS03 RS04 RS05 RS06 RS07 RS08 RS09 RS10 RS11 RS12 RS13 RS14 RS15
define RolloSchalterGast structure room RS01 RS02
define RolloSchalterLog structure room RS09 RS10 RS11
define RolloSchalterOst structure room RS01 RS02 RS03 RS04
define RolloSchalterPenn structure room RS11 RS12 RS13 RS14 RS15
define RolloSchalterSud structure room RS05 RS06 RS07 RS08
define RolloSchalterTVwand structure room RS06 RS07 RS08 RS09 RS10
define RolloSchalterWest structure room RS12 RS13 RS14 RS15
define RolloSchalterWohn structure room RS03 RS04 RS05 RS06 RS07 RS08 RS09 RS10


Alle diese structures sowie alle RolloSchalter.. haben zudem das Attribut "room AlleRollos", um einzelne Gruppen oder RolloSchalter bequem schalten und den Status kontrollieren zu können. So hat das sehr lange problemlos funktioniert; wenn ich eine der Gruppen per webCmd auf vordefinierte Positionen stellte, fuhren die zugehörigen Rollos sogleich los (mit sehr kurzem Delay von wenigen 100ms dazwischen) und man konnte in pgm2 in Raum "AlleRollos" sehr schön sehen, wie die einzelnen Schalter der Reihe nach auf "set_xy" gingen. Die Benutzung des ganzen Systems war sehr geschmeidig.

Dann vor einigen Wochen (genauer kann ich es nicht eingrenzen) fing das geschilderte Problem an, sic zu manifestieren. Das fiel auch in die Zeit, da ich von einem Laptop als FHEM Server auf einen CubieTruck aufgrund eines Hardwaredefekts zügiger wechseln musste als ursprünglich geplant, also hatte ich zunächst neben ein paar experimentell eingerichteten Modulen auch den CT in Verdacht.

Dann habe ich angefangen, mich mit apptime zu beschäftlichen, das zunächst viele Auffälligkeiten für CUL_HM Funktionen aufzeigte. Auch mit gesetztem 'attr global verbose 5' sah es weiter so aus, als wäre das Problem irgendwo in CUL_HM zu suchen. Die Details dazu stehen in besagtem Thread.

Erst dann kam ich auf die Idee, vor einem "set RolloSchalterAll" für alle Devices vebose hochzusetzen, mit 'attr .+ verbose 5'. Da begann ich, meine Aufmerksamkeit doch mehr auf structure zu richten.

Wie ich inzwischen glaube verstanden zuhaben, passiert folgendes:

• 'set RolloSchalterAll up 10' geht alle konfigurierten Schalter der reiihe nach durch, also erstmal RS03
• RS03 postet ein Event mit der Zustandsänderung, dieses geht auch in die Notifies der structures
• RolloSchalterAll erkennt, dass RS03 zwar iim CONTENT ist, ignoriert das Event aber, weil es vom gerade gesetzten Zustand herrühren muss
• RolloSchalterOst erkennt das nicht und ändert seinen Zustand auf 'undefined', was ein weiteres Event auslöst. Gleiches passiert bei jedem weiteren Structure, in dem RS03 enthalten ist. Für jeden weiteren RS.. gilt das gleiche Prinzip. Insgesamt werden also eine Menge von Events losgetreten
• Alle Events treffen irgendwann auch auf FHEMWEB_Notify, das z.B. per longpoll eine Seite mit room=AlleRollos versorgt.
• Für jede solche Seite wird für jede Structure irgenwann FW_devState() und von dort getAllSets() aufgerufen, was schließlich in einem CommandSet() mit Argument "?" mündet -  zunächst im jeweiligen Structure, von dort aber auch im HM-Device. Entsprechend finden sich im LogFile plötzlich sehr viele Einräge der Art 'Unknown argument ?, choose one of clear:readings,trigger ...'

Im täglichen Betrieb habe ich in der Regel 3-5 FHEMWEB Clients, der Delay nach Setzen des ersten Schalters in einer structure beträgt z.T. gut 11 Sekunden. Entsprechende Perfmon Einträge finden sich zuhauf.

Nun habe ich zum Test in 98_structure eine Änderung eingefügt, durch die in structure_Set() die Funktion früh abgebrochen wird, wenn sie mit "set ?" aufgerufen wird. Alleine dadurch konnte ich die 11 Sekunden reproduzierbar auf 1-2 Sekunden reduzieren. Im nächsten Schritt habe ich einen einfachen Caching-Mechanismus in die Funktion eingebaut, die "set ?" beim ersten Mal noch auswertet und von da an dieses Ergebnis zurückliefert. Auch dann bleibt es bei einem Delay von 1-2 Sekunden. Ich kann aber nicht beurteilen, welche Nebenwirkungen das hat. Zumindest aber scheint es zu zeigen, woher das problematische Timing rührt.

Was sagst Du zu meinen "Erkenntnissen", klingt das für Dich plausibel, ist der Ansatz für den Fix richtig? Soll ich meine gepatchte Version posten? Im Moment ist sie (ausgehend von 98_structure.pm 6936) neben dem Workaround stark mit zusätzlichen Log3 Zeilen dekoriert, ich kann das aber gern wieder auf die funktionale Änderung zurückstutzen. Ich kann Dir auch umfangreiche Logs zur Verfügung stellen, die das Verhalten (mittels der zusätzlichen Logeinträge) ganz gut belegen.

Mir ist sehr an einer Behebung des Problems gelegen und trage gern alles bei, was zu einer "sauberen" Lösung beitragen kann.

Beste Grüße,
Andy.

[rudolfkoenig]

Hallo gandy.

Ich meine deine Analyze ist perfekt, und ich habe das "set ?" caching in structure eingebaut und eingecheckt.
Wenn ich mehr tun kann, sag Bescheid, mit faellt aber nichts ein, was keine Nebenwirkungen haette.

Gruss,
  Rudi

[gandy]

Hallo Rudi,

Spitze, danke für die zeitnahe Umsetzung.

Nach dem Update heut morgen habe ich erneut getestet. Dabei wurde mir gewahr, dass ich zum Testen auch in CUL_HM ein Event auskommentiert hatte, was mit dem Update rückgängig gemacht wurde.

Insofern lande ich bei knapp 6 Sekunden für das erste Delay, was immer noch besser ist als >12 Sek. - aber natürlich nicht so schön wie 2 Sek.

Die erreiche ich wenn ich auf allen structures das Attribut 'disable 1' setze, was aktuell aber in der Attributliste fehlt und nur in der deutschen commandref enthalten ist. Damit verzichte ich aber natürlich auf jeglichen Status-update.

Ähnlich kurze delays sehe ich aber auch wenn ich disable in allen structures setze ausser in derjenigen, auf der ich das 'set' ausführe. Darüber muss ich noch ein wenig nachdenken.

Ebenfalls überlege ich, ob man ein 'set' auf der structure nicht über den timer sequentiell abarbeiten könnte (optional). Wenn aus deiner Sicht keine offensichtlichen Dinge dagegensprechen, wäre ich auch gern bereit, einen Lösungsvorschlag zu erarbeiten.

Grüße,
Andy.

[rudolfkoenig]

Gerne, und am besten klar sagen, was ich tun soll.
Aus deiner Ausfuehrung gerade eben konnte ich nicht ableiten, ob und was ich machen soll (disable?)

[gandy]

stimmt, danke für den Hinweis, hatte glatt übersehen, meine Frage zu disable zu stellen:
In structure_Notify wird isDisabled() verwendet, um die Eventbehandlung zu unterbinden. In der deutschen commandref wird auf disable und disabledForIntervallls verwiesen, nicht aber in der englischen. Auch für Attributliste beinhaltet beide Attribute nicht, sie können also nicht gesetzt werden.

M.E. ist disable sinnvoll, daher mein Vorschlag: Bitte
- Attributliste erweitern
- engl. commandref nachziehen

Kann auch gern einen patch bereitstellen, aber zumindest für den ersten Punkt wär ich mir nicht sicher ob das wie bei $readingFunctionAttributes über eine variable gelöst werden sollte.

Danke,
Andy.

[rudolfkoenig]

Habe disable & disabledForIntervals aktiviert.

[gandy]

Hallo Rudi,

Habe disable & disabledForIntervals aktiviert.

Vielen Dank fürs Einfügen des disable. Nachdem ich (etwas spät) auch den Commandref Eintrag gelesen habe, erscheint es mir doch nicht mehr so geeignet zu sein, wie ich ursprünglich dachte. Dort ist von der Unterbindung der "set" Ausführung die Rede. Eigentlich ist das was ich damit verbinde aber ja eher sowas wie ein "clientstate_behavior none" - also keinerlei clientstate Bearbeitung, nur die ursprüngliche Verteilung von set-Kommandos an die Clients. Der STATE der structure könnte entsprechend "undefined" lauten. Was denkst Du darüber, ein entsprechendes neues clientstate_behavior zu implementieren? Soll (noch) nicht heissen dass Du was tun sollst, deine Meinung wäre mir erstmal wichtig.

Ebenfalls überlege ich, ob man ein 'set' auf der structure nicht über den timer sequentiell abarbeiten könnte (optional). Wenn aus deiner Sicht keine offensichtlichen Dinge dagegensprechen, wäre ich auch gern bereit, einen Lösungsvorschlag zu erarbeiten.

Anbei nun mein Vorschlag zu einer asyncronen Bearbeitung der set Kommandos ohne Filter über eine Warteschlange. Gesteuert wird das neue Verhalten über das Attribut "async_delay". Ist es nicht gesetzt, bleibt alles wie bisher. Ansonsten werden alle normalen set Befehle (also explizit die ohne FILTER) die an nicht-structure clients gehen, in eine Warteschlange eingestellt und per InternalTimer einer nach dem anderen ausgeführt. Der Wert von async_delay bestimmt die Zeit bis zum nächsten Aufruf. Ich habe ausgiebig getestet, auch mit async_delay=0, was die schnellstmögliche Ausführung gestattet, dabei aber nicht zu den extrem langen Delays in der Event- und Timerbearbeitung führt, die ich ohne async_delay beobachte. Nebenwirkung: So ausgeführte set Kommandos tragen notgedrungen nicht mehr zum return-Wert des structure_Set bei (entsprechend wird "set ?" von dieser Behandlung ausgenommen). Wenn das auch für andere set-Argumente ein Problem darstellt, könnte ein weiteres Attribut "async_excempt" per regexp solche Argumente ebenfalls von der asyncronen Behandlung ausnehmen.

Wenn Du den Patch so akzeptieren kannst, würde ich mich über eine Übernahme in FHEM freuen. Der Name des Attributs kann gern auch anders lauten. Wenn es etwas nachzubessern gibt, freue ich mich über Deine Anregungen.

Beste Grüße,
Andy.

[rudolfkoenig]

Entgegen der Doku bewirkt disabled z.Zt., dass die Statusaenderungen in structure nicht ueberprueft werden. Auf set hat es keine Auswirkung.

Ich verstehe noch nicht genau das Problem, was dein Patch loesen soll. Zum Patch-Format: eigentlich perfekt, bis auf die Doku: es sollte nur ASCII enthalten, d.h. ö -> ö usw.

[gandy]

Der Patch bezieht sich auf das Problem mit roßen structures (siehe etwas weiter oben, Beitrag http://forum.fhem.de/index.php/topic,28623.msg221222.html#msg221222), das mit dem Einbau des helpCache zwar schon deutlich entschärft, aber immer noch präsent ist.

Der Patch erlaubt, eine von zwei Alternativen zu wählen:

• Das bisherige Verhalten, hier wird unmittelbar mit Aufruf des "set <structureName>" für alle enthaltenen Clients die set Funktion aufgerufen. Je nach Größe der structure und Menge der pro Client ausgelösten Events kann das einige Sekunden in Anspruch nehmen, während der der FHEM Kern blockiert ist - und folglich alle anderen Devices. Bei schneller Abarbeitung mag das kein Problem sein, bei mir beobachte ich hier allerdings bei den größeren structures nach wie vor Zeiten von 6-8 Sekunden, die ich für kritisch erachte.
• Das neue Verhalten erlaubt, die set-Kommandos in den Clients nicht unmittelbar mit Aufruf des "set <structureName>" auszuführen, sondern jeden davon einzeln aus der Timerbehandlung heraus. Für N derart behandelte Kommandos sind also N Aufrufe der Timerfunktion erforderlich. Zwischen diesen Aufrufen hat der FHEM Kern die Möglichkeit, IOdevs, anstehende Timer und Events zu behandeln, was insgesamt die Ausführung aller set-Kommandos zwar nicht beschleunigt, aber für das System einen responsiveren Gesamteindruck beim Benutzer hinterlässt. Mir ist bewusst, dass FHEM kein Echtzeitsystem ist, und ich erhebe auch keinen Anspruch in dieser Richtung. Dennoch bin ich der Meinung, dass die Interaktion mit einem Heimautomationssystem ein wesentlicher Bestandteil desselben ist und finde, dass diese Interaktion auch während aufwenidgerer Aktionen "fluffig" bleiben sollte. Non-blocking Mechanismen ermöglichen das während potentiell langwieriger Geräte-Operationen, mit meinem Patch versuche ich, das für die structure zu ermöglichen.

Gibt das für Dich Sinn? Oder gibt es mit Bordmitteln elegantere Möglichkeiten, für mehr Responsivität bei großen structures zu sorgen? Ich hatte auch kurz mal darüber nachgedacht ob es Sinn hätte so eine Art "deferrer"-Modul zu schreiben, das ein set-Kommando ähnlich verzögert ausführen kann. Aber irgendwie scheue ich mich davor, Performance-Problemen mit noch mehr Resourcenbedarf zu begegnen.

Beste Grüße,
Andy.

[rudolfkoenig]

Ich habe dein Patch etwas modifiziert, getestet und eingecheckt. Haupt Unterschied (mAn) ist, dass bei einem structure-set evtl. noch im Puffer befindliche Befehle nicht geloescht werden. Waere aber gut, wenn Du es auch testen koenntest.

[gandy]

Hallo Rudi,

vielen Dank für Übernehmen und Überarbeiten des Patches! Testen kann ich erst heute abend, aber durchgesehen habe ich mir die eingecheckte Version. Deine Änderungen finde ich gut, nur eine Sache ist mir dabei aufgefallen: Die Queue darf m.E. nicht verwendet werden, wenn man auf den Rückgabe-Wert des set-Befehls angewiesen ist, wie das z.B. bei "set ?" der Fall ist. Siehe auch beigefügten Patchvorschlag zur aktuellen SVN Version. Ansonsten erwarte ich beim Testen keine Überaschungen, werde aber auf jeden Fall berichten.

Beste Grüße,
Andy.

[rudolfkoenig]

Danke fuer den Hinweis, habs gefixt und eingecheckt.

[gandy]

Hallo Rudi,

nach einigen Tagen Betrieb und diversen Tests kann ich sagen, die aktuelle Version von structure funktioniert zu meiner vollsten Zufriedenheit. Nochmals recht vielen Dank für deine Unterstützung!

Beste Grüße,
Andy.