KNX Data Secure Unterstützung
für KNX Logger und KNX Busmonitor

KNX Diagnose Monitor, Import des ETS Projektes deutlich beschleunigt, Suche in der Navigation
Mehr Informationen dazu hier im Forum

Insider Version 6 zur 4.5 jetzt für alle Mitglieder des Insider Clubs installierbar
Alle Infos zum Update im Timberwolf Wiki

[BUG] [V4.1.1] Custom Logik für Rasenbewässerung, ACHTUNG KI: führte zu Absturz Logik Subsystem (WD-2731)

Informationen und Diskussionen über Logik-Engine und Logik-Editor
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
Bancoras
Reactions:
Beiträge: 41
Registriert: So Sep 29, 2019 12:53 pm
Hat sich bedankt: 14 Mal
Danksagung erhalten: 10 Mal

[V4.1.1] Custom Logik für Rasenbewässerung, ACHTUNG KI: führte zu Absturz Logik Subsystem (WD-2731)

#1

Beitrag von Bancoras »

Hallo Logik begeisterte und Programmierer.
Ich habe unter anderen jetzt gelesen, dass harte Nüsse und so u.a. für LLM Experimente gesucht werden...

Hier war meine Anforderung an meine KI (ChatGPT):
✅ Ziel der Logik für die Rasenbewässerung:

1. Automatische Bewässerung nur wenn:
Regenmenge der letzten 2 Stunden ist < 5 mm
UND (Temperatur aktuell > 24 °C ODER Durchschnitt der letzten 3 h > 23 °C)
UND Uhrzeit ist genau 04:30 Uhr
UND es besteht keine aktive Sperre (36 h)

2. Manuelle Aktivierung möglich
z. B. per Taster oder über Visu
Diese umgeht alle Bedingungen außer der Sperre

3. Sperrlogik (36h):
Nach manuellem Start oder
wenn Regen ≥ 5 mm in 2h
→ wird eine Sperre aktiviert (Monoflop)
→ Dauer: 36 Stunden (129600 Sekunden)


Hinweis: Ich wollte 3 Tage Sperre, hab aber 36h bei der Erstellung angegeben. 3 Tage Nacht mehr Sinn, aber tut der Logik ja nichts zur Sache.

Heraus kam folgende Logik: :!: :!: :!: Diese Logik führte u.a. zum Absturz des gesamten Logik Subsystems!!!!

Code: Alles auswählen

{
  "Level": [
    ["$Rain_2h", "float", 0],
    ["$Temp_now", "float", 25],
    ["$Temp_3h_avg", "float", 24],
    ["$Hour", "int", 4],
    ["$Min", "int", 30],
    ["$LockActive", "int", 0],
    ["$ManualTrigger", "int", 0],

    ["$RainLimit", "float", 5],
    ["$TempLimitNow", "float", 24],
    ["$TempLimitAvg", "float", 23],
    ["$HourTarget", "int", 4],
    ["$MinTarget", "int", 30],

    ["$One", "int", 1],

    ["$RainHigh", "int", 0],
    ["$RainLow", "int", 0],

    ["$TempNowOk", "int", 0],
    ["$TempAvgOk", "int", 0],
    ["$TempOk", "int", 0],

    ["$HourOk", "int", 0],
    ["$HourNotOk", "int", 0],

    ["$MinOk", "int", 0],
    ["$MinNotOk", "int", 0],

    ["$TimeOk", "int", 0],

    ["$NoLock", "int", 0],

    ["$AutoStart", "int", 0],

    ["$LockTrigger", "int", 0],

    ["$WaterOn", "int", 0]
  ],
  "Module": [
    ["Comparator", "$Rain_2h", "$RainHigh", "$RainLimit"],
    ["Xor", ["$RainHigh", "$One"], "$RainLow"],

    ["Comparator", "$Temp_now", "$TempNowOk", "$TempLimitNow"],
    ["Comparator", "$Temp_3h_avg", "$TempAvgOk", "$TempLimitAvg"],
    ["Or", ["$TempNowOk", "$TempAvgOk"], "$TempOk"],

    ["Comparator", "$Hour", "$HourOk", "$HourTarget"],
    ["Xor", ["$HourOk", "$One"], "$HourNotOk"],

    ["Comparator", "$Min", "$MinOk", "$MinTarget"],
    ["Xor", ["$MinOk", "$One"], "$MinNotOk"],

    ["And", ["$HourOk", "$MinOk"], "$TimeOk"],

    ["Xor", ["$LockActive", "$One"], "$NoLock"],

    ["And", ["$RainLow", "$TempOk", "$TimeOk", "$NoLock"], "$AutoStart"],

    ["Or", ["$ManualTrigger", "$AutoStart"], "$WaterOn"],

    ["Or", ["$ManualTrigger", "$RainHigh"], "$LockTrigger"],

    ["Monoflop", "$LockTrigger", 0, "$LockActive", 129600, 0]
  ],
  "Input": [
    ["Rain_2h", "Regen 2h (mm)", "$Rain_2h", "c"],
    ["Temp_now", "Temperatur aktuell (°C)", "$Temp_now", "c"],
    ["Temp_3h_avg", "Temperatur 3h Mittel (°C)", "$Temp_3h_avg", "c"],
    ["Hour", "Aktuelle Stunde", "$Hour", "c"],
    ["Min", "Aktuelle Minute", "$Min", "c"],
    ["ManualTrigger", "Manuelle Aktivierung", "$ManualTrigger", "c"]
  ],
  "Output": [
    ["WaterOn", "Bewässerung aktiv", "$WaterOn", "c"],
    ["LockActive", "Sperre aktiv", "$LockActive", "c"]
  ]
}
Wenn die Logik auch nicht vollends passend umgeschrieben werden kann, vielleicht hilft es ja heraus zu finden, was genau da zum Fehler führte Oder hilft euch bei Erstellung der eigenen KI für die Logikengine?
Zuletzt geändert von ms20de am Do Jun 12, 2025 6:33 pm, insgesamt 2-mal geändert.
Timberwolf 350Q
timberwolf409, VPN offen, Reboot jederzeit

eib-eg
Reactions:
Beiträge: 560
Registriert: Fr Sep 14, 2018 5:03 pm
Hat sich bedankt: 1560 Mal
Danksagung erhalten: 358 Mal

#2

Beitrag von eib-eg »

Hallo @Bancoras ,

herzlich willkommen im Kreis der Logik-Tüftler! Es tut mir leid zu hören, dass du mit deiner Rasenbewässerungslogik einen so frustrierenden Start hattest, der sogar zum Stillstand des Logik-Subsystems geführt hat. Solche Erfahrungen sind ärgerlich, bieten aber auch wertvolle Lernchancen für uns alle hier im Forum. Gemeinsam können wir versuchen, die Ursachen zu ergründen und eine robustere Lösung für dich zu entwickeln.

Ich (eib-eg, mit Unterstützung einer lernenden AI) habe mir deine Anforderungen und den von ChatGPT generierten Code angesehen. Hier sind einige detaillierte Beobachtungen und vor allem viele wichtige Rückfragen. Diese sind nicht böse gemeint, sondern absolut notwendig, um eine Logik zu entwerfen, die nicht nur funktioniert, sondern auch sicher und an deine spezifische Umgebung angepasst ist:




1. Analyse der bisherigen Logik und möglicher technischer Fehlerquellen:

Der von dir gepostete Code enthält einige Konstruktionen, die auf Timberwolf Servern, insbesondere mit älteren Firmware-Versionen wie deiner V4.1.1 (Frozen Pumpkin), zu Problemen führen können.

Das Comparator-Modul (Hauptverdächtiger!):

In deiner Logik werden alle Comparator-Aufrufe ohne einen expliziten "Mode"-Parameter verwendet (z.B. ["Comparator", "$Rain_2h", "$RainHigh", "$RainLimit"]).

Kritisch für Firmware V4.1.1: Unsere intensiven Tests (siehe auch diverse Threads hier im Forum und unsere Community-Referenzanleitungen) haben gezeigt, dass der Comparator bei Verwendung mit nur einer Schwelle zwingend einen expliziten Mode-Integer (0-5) als letzten Parameter benötigt. Fehlt dieser, liefert der Comparator auf vielen Firmware-Ständen (sehr wahrscheinlich auch auf deinem) immer false oder verhält sich undefiniert. Dies kann die gesamte nachfolgende Logik ad absurdum führen und potenziell Instabilitäten bis hin zu Abstürzen verursachen, wie von dir erlebt. Eine KI wie ChatGPT, die nicht spezifisch auf die Eigenheiten des TWS trainiert ist, kann dieses kritische Detail leicht übersehen.

Empfehlung: Jeder Vergleich muss mit dem korrekten Mode umgesetzt werden. Für einen Vergleich A < B wäre das z.B. Mode 1 (siehe Tipp 11 unserer Community-Referenz oder TSKB für eine Liste der Modi).

Datentypen für logische Zustände:

Deine Logik verwendet durchgehend den Datentyp int (Integer) für Variablen, die eigentlich boolesche Zustände (wahr/falsch) repräsentieren (z.B. $RainHigh, $LockActive). Der TWS kann Integer (0 und 1) oft als Booleans interpretieren. Problematisch wird es, wenn durch Fehler (z.B. beim fehlerhaften Comparator) andere Integer-Werte als 0 oder 1 in diese Variablen gelangen. Dann ist das Verhalten von Logikgattern (And, Or, Xor), die boolesche Inputs erwarten, nicht mehr vorhersagbar.

Empfehlung: Für alle Zustände, die wahr oder falsch sein können, explizit den Datentyp bool verwenden.

Monoflop-Parameter:

Der Aufruf ["Monoflop", "$LockTrigger", 0, "$LockActive", 129600, 0] verwendet das Literal 0 als $ResetSignal und als $ModeInteger.

$ResetSignal = 0: Ist syntaktisch zulässig und bedeutet, dass kein aktives Reset-Signal verwendet wird.

$ModeInteger = 0: Bedeutet "Pegelgesteuert durch $SetVar, nicht retriggerbar bei aktivem $SetVar". Dies muss zum gewünschten Verhalten der Sperre passen (d.h., die Sperre startet, sobald $LockTrigger true wird, und läuft dann für 36h, es sei denn $LockTrigger wird vorher false).

Datentyp für $LockActive und $LockTrigger: Beide sind als int deklariert. Das Monoflop erwartet für seinen Set-Eingang ($LockTrigger) und seinen Q-Ausgang ($LockActive) typischerweise bool-Werte. Eine fehlerhafte Interpretation von int als bool könnte hier zu Problemen führen.

Potenzielle Zirkelbezüge und Timing-Probleme:

Wie @gbglace im Thread "Logikengine ist blockiert" anmerkte, können Zirkelbezüge (wo ein Ausgang direkt oder indirekt wieder auf einen Eingang wirkt, ohne klare Auflösung) zu Blockaden führen. Deine Logik hat eine Rückkopplungsschleife: $LockActive beeinflusst $NoLock, was $AutoStart beeinflusst, was wiederum $LockTrigger beeinflusst, welches das Monoflop für $LockActive steuert. Wenn hier die Wertaktualisierungen innerhalb eines Logikzyklus nicht sauber definiert sind (besonders in Kombination mit den potenziell fehlerhaften Comparatoren), kann das System instabil werden.




2. Präzisierung deiner Anforderungen und deiner Systemumgebung (Ganz wichtig!):

Die ursprüngliche Anforderungsliste ist ein guter Start, aber für eine robuste Implementierung fehlen viele Details. "Der Teufel steckt im Detail", gerade bei Automatisierungen.

Sensorik – "Was passiert, wenn...?":

Regenmenge ($Rain_2h):

Quelle? (KNX, Netatmo, HTTP-API, interner Zähler?) Wie oft wird der Wert aktualisiert?

Was ist der Wert bei Sensorausfall oder Kommunikationsstörung? (z.B. 0, der letzte gültige Wert, ein spezieller Fehlerwert wie -9999?) Soll bei Sensorausfall sicherheitshalber NICHT bewässert werden?

Temperatur aktuell ($Temp_now) und Durchschnitt 3h ($Temp_3h_avg):

Gleiche Fragen wie beim Regen: Quelle, Aktualisierungsintervall, Verhalten bei Sensorausfall?

Muss der 3h-Durchschnitt von der Logik berechnet werden, oder liefert ein Sensor diesen Wert bereits?

Uhrzeit ($Hour, $Min):

Kommen diese zuverlässig vom NTP-synchronisierten Timberwolf Server, oder von einer externen, potenziell ungenauen Quelle?

Manuelle Aktivierung ($ManualTrigger):

Ganz wichtig: Ist dies ein Taster (erzeugt einen kurzen Impuls, wenn gedrückt) oder ein Schalter (bleibt AN oder AUS, bis er erneut betätigt wird)? Davon hängt die gesamte Triggerlogik für die manuelle Bewässerung und die Sperre ab!

Aktorik (Magnetventile) – Das "Wie" der Ansteuerung:

Wie werden die Magnetventile technisch angesteuert?

Über einfache Relais-Ausgänge (z.B. KNX Schaltaktor)? Hier würde ein Dauer-EIN-Signal das Ventil offenhalten.

Oder verwendest du spezielle Ventilaktoren, z.B. 1-Wire Ventilaktoren von ElabNET? Diese haben ein besonderes Verhalten: Sie benötigen oft ein periodisch wiederholtes EIN-Signal (z.B. jede Minute), um offen zu bleiben, und schalten bei Signalausfall automatisch ab. Wenn das bei dir der Fall ist, muss die Logik das berücksichtigen!

Gibt es Rückmeldeobjekte von den Ventilen, die anzeigen, ob sie tatsächlich geöffnet oder geschlossen sind? Dies wäre sehr nützlich für eine robustere Steuerung und Fehlererkennung.

Wie viele Ventile/Bewässerungskreise sollen gesteuert werden? Alle gleichzeitig mit einem Signal, oder einzeln/sequenziell?

Genauigkeit und Verhalten in Grenzfällen:

"Regenmenge < 5 mm": Was ist bei exakt 5 mm? Nicht bewässern?

"Temperatur aktuell > 24 °C ODER Durchschnitt > 23 °C": Was bei exakt 24°C bzw. 23°C?

"Uhrzeit ist genau 04:30 Uhr": Bedeutet das exakt um 04:30:00 Uhr für eine Sekunde/einen Zyklus, oder ein Zeitfenster (z.B. von 04:30 bis 04:35 Uhr)? Eine exakte Sekunde ist schwer zu treffen. Ein Zeitfenster ist meist robuster.

Sperrlogik:

Soll die 36h-Sperre auch dann aktiviert werden, wenn während einer bereits laufenden (manuellen oder automatischen) Bewässerung die Regenmenge 5mm erreicht?

Wenn ja, soll die laufende Bewässerung dann sofort abgebrochen werden?

Bewässerungsdauer:

Wie lange soll automatisch oder manuell bewässert werden, wenn die Bedingungen erfüllt sind und die Bewässerung startet? Diese Information fehlt in der Anforderung und ist entscheidend. Wird die Dauer fest vorgegeben, oder hängt sie von anderen Faktoren ab? Soll ein weiteres Monoflop die Bewässerungszeit steuern?

Prioritäten und Überschneidungen:

Was passiert, wenn genau um 04:30 Uhr (Automatikzeit) auch eine manuelle Aktivierung erfolgt? Hat Manuell Vorrang, oder wird die Automatikprüfung trotzdem durchgeführt? (Deine Beschreibung "Manuelle Aktivierung ... umgeht alle Bedingungen außer der Sperre" deutet darauf hin, dass Manuell + keine Sperre immer zu Wasser führt, unabhängig von Zeit/Wetter).




3. Vorschläge für einen robusteren und sichereren Logik-Ansatz:

Basierend auf den obigen Fragen und allgemeinen Best Practices:

Sicherheitsaspekte zuerst (Fail-Safe-Verhalten):

Sensorausfall: Implementiere eine Logik, die auf ungültige oder fehlende Sensorwerte reagiert. Z.B.: Wenn Regensensor "Error" meldet, Automatik blockieren.

Plausibilitätsprüfungen: Prüfe Sensorwerte auf realistische Bereiche (z.B. Temperatur nicht -50°C oder +80°C). Außerhalb plausibler Bereiche -> Automatik blockieren oder Warnung ausgeben. Module wie Limiter können hier helfen.

Standardverhalten: Definiere ein sicheres Standardverhalten (z.B. "Bewässerung immer AUS"), falls kritische Bedingungen nicht eindeutig erfüllt sind oder Fehler auftreten.

Modulare Struktur: Teile die Logik in klare, testbare Blöcke auf:

1. Sensorwert-Aufbereitung und -Validierung.

2. Bedingungsprüfung für automatische Bewässerung.

3. Logik für manuelle Anforderung (inkl. Flankenerkennung, falls Taster).

4. Sperrlogik (Monoflop, Triggerbedingungen).

5. Finale Entscheidungslogik (Was hat Vorrang? Was passiert bei Sperre?).

6. Ansteuerung der Aktorik (ggf. mit Timer für Bewässerungsdauer und periodischem Signal für spezielle Aktoren).

Explizite Zustandsvariablen: Verwende klar benannte bool-Variablen für Zustände (z.B. $State_AutomatikBedingungErfuellt_Bool, $State_ManuelleAnforderungAktiv_Bool, $State_SperreAktiv_Bool, $State_BewZeitLaeuft_Bool).

Saubere Impulsverarbeitung: Wenn $P_ManualTrigger_Bool von einem Taster kommt, eine saubere Flankenerkennung implementieren (z.B. mit unserem "Ein-Zyklus-Impuls"-Pattern), um Aktionen nur einmal pro Tastendruck auszulösen.

Debugging-Outputs: Definiere im Output-Block deines Logikmoduls wichtige interne Zustände und Sensorwerte als Ausgänge mit UI-Typ "c". Das erleichtert die Fehlersuche und das Verständnis des Logikablaufs im Doktormodus des TWS enorm.

Backup erstellen: IMMER, IMMER, IMMER ein Backup des Timberwolf Servers machen, bevor du neue oder stark veränderte, komplexe Logiken hochlädst und aktivierst.

Testen auf Nicht-Produktivsystem: Wenn du die Möglichkeit hast (z.B. ein zweiter TWS ), teste komplexe Logiken zuerst dort.

Schrittweise entwickeln und testen: Baue die Logik nicht als riesigen Monolithen, sondern entwickle und teste einzelne Funktionsblöcke separat, bevor du sie zusammenfügst.

Logik-Diagnose-Monitor nutzen: Der TWS bietet im Logikeditor oft einen Diagnose-Monitor, der Fehler oder Warnungen der Logik-Engine anzeigt. Diesen im Auge behalten.




4. Zu KI-generiertem Code und unseren Community-Referenzen:

Wie du gemerkt hast, ist ChatGPT (und andere KIs) ein mächtiges Werkzeug, aber es kennt nicht alle spezifischen Eigenheiten und Syntaxregeln jeder einzelnen Plattform wie des Timberwolf Servers.

Wir hier im Forum (@eib-eg, @Franky , @AndererStefan und viele andere) arbeiten intensiv daran, sehr detaillierte Referenzanleitungen und Syntax-Demos zu erstellen (aktuell z.B. unsere Referenz V4.16.7), die speziell auf die Tücken und die korrekte, validierte Syntax des Timberwolf Servers zugeschnitten sind. Diese enthalten auch explizite Meta-Regeln für die AI-Nutzung.

Eine KI, die auf solch einer spezialisierten Wissensbasis trainiert oder instruiert wird, kann deutlich besseren und sichereren Code liefern. Es wäre interessant zu wissen, ob und welche Referenzinformationen ChatGPT für die Erstellung deiner Logik zur Verfügung hatte.

Wie wir dir konkret weiterhelfen können:

Wenn du uns die oben genannten Punkte (insbesondere zur Sensorik, Aktorik, gewünschtem Verhalten in Grenz- und Fehlerfällen sowie zur Bewässerungsdauer) genauer erläutern kannst, können wir gemeinsam versuchen, eine Logik zu skizzieren oder sogar einen Code-Entwurf zu erstellen, der deinen Bedürfnissen besser entspricht und auf den gesicherten Erkenntnissen zur Custom Logic Syntax basiert.

Das Ziel sollte immer sein, dass du die Logik am Ende verstehst, um sie ggf. später selbst anpassen oder Fehler finden zu können. Ein "Blackbox"-Code von einer KI, den man nicht versteht, ist langfristig oft problematisch.

Wir freuen uns auf deine detaillierteren Infos!

Viele Grüße,

eib-eg (mit Unterstützung einer lernenden AI)
TW 2600_99 seit 1.1.2018 / VPN zu

Ersteller
Bancoras
Reactions:
Beiträge: 41
Registriert: So Sep 29, 2019 12:53 pm
Hat sich bedankt: 14 Mal
Danksagung erhalten: 10 Mal

#3

Beitrag von Bancoras »

Hallo @eib-eg,

erst einmal vielen Dank für deine ausführliche Antwort und vor allem für die Analyse der Logik. :)
Ja, ich habe gelernt, dass ich noch VIIEEEL lernen muss und halt einiges einfach noch nicht (richtig) verstehe/verstanden habe... Habe teilweise einfach zu blauäugig und blind der KI vertraut und dummerweise gedacht, dass sobald der Logikeditor keine Fehlermeldung mehr ausspuckt, die Logik schon passen würde. :think:
Naja, falsch gedacht :arrow: gibt Lehrgeld.

Und NEIN, ich habe nichts böses in deinen Rückfragen und Analysen gelesen. :D

1.)
Meine Antwort wird kurz: Ich fange nochmal wieder weiter vorne an und taste mich deutlich langsamer an eigene Logiken heran. Sollte vielleicht vermehrt bei Sonderwünschen mit vorgegeben Logikbausteinen hantieren und diese erst einmal in einer Custom-Logik zusammen setzen. ;)


2.)
  • Regenmenge:
--> Ist noch im Aufbau <--
Die Regenmenge wird von einem Regenmengenmesser mit Kippwaage gemessen, welcher an einem KNX-Binäreingang hängt. 0.2mm Niederschlag je Kipppunkt. Die Messung soll in einer separaten Logik ausgewertet und u.a. an Grafana weitergeleitet werden, Anzeige in Visu etc.
Was tun bei Sensorausfall? Gute Frage! Ist bei einer Kippwaage über Binäreingang schwierig. Da würde eine weitere Logik mitspielen müssen:
[*]- Regensensor (KNX) meldet über 2h ununterbrochen Regen + keine gelieferte Regenmenge durch Binäreingang/Kippwaage = sperren
[*]- oder evtl. etwas komplexer: Ausgabe Fehlermeldung (z.B. an Visu)
ACHTUNG: Regenmesser defekt/blockiert? Bewässerung gesperrt!
und als Reaktionsmöglichkeit
OK
und
Sperre aufheben, kein Regen!
  • Temperatur:
Temperatur kommt von KNX-Wetterstation, Aktualisierung alle 5min sowie bei Änderung Temperatur 1,0K.
Hier würde ich vielleicht doch etwas anders arbeiten... T= in letzten 24h >24°C --> true (Wenn nachts kühler, würde sonst die Logik wieder gesperrt werden, um im frühen morgen zu bewässern.) Bei Ausfall Sensor, Fehlermeldung an Visu und sperren.
Die Logik für "T = >24°C/24h" würde ich separat laufen lassen.
  • Uhrzeit:
Diese kommt vom TWS, dieser dient auch als Zeitserver/-geber für KNX.
  • manuelle Aktivierung:
Es soll ein Schalter (an/aus) sein.
  • Aktorik (Magnetventile):
1-Wire Ventilaktoren von Elabnet. (Liegt hier noch im Karton, käme dann aber endlich zum Einsatz. Neue Verkabelung der alten Garage, wo die Leitungen zum Ansteuern zusammen laufen, ist gerade in Arbeit...)
Nein, es gibt leider keine Rückmeldungen von den Ventilen. Es sind Standard 24VAC Hunter-Magnetventile.
Es gibt 5 Bewässerungskreise, jedoch würde ich für jeden Kreis eine eigene Logik erstellen. Kreis für die Hecke z.B. bräuchte nur alle 5 Tage angesteuert werden, Blumenbeet dafür täglich. Genauso wie die Dauer der Bewässerung, aber die Frage kommt ja noch weiter unten.
  • Genauigkeit:
- "Regenmenge <5mm": Japp. ab 5mm (auch bei genau 5mm) nicht bewässern.
- Temperatur: hatte ich oben schon erwähnt, würde ich eher auf >24°C letzte 24h setzen. Ich denke die Anforderung von z.B. "T= >24°C im Durchschnitt zwischen 12-15 Uhr" wäre zu aufwändig...
- "Uhrzeit ist genau 04:30 Uhr": Da haste meinen Denkfehler gefunden! :lol: Ich würde die Uhrzeit mit der Bewässerungsdauer kombinieren. Die Bewässerungsdauer soll 10 Minuten betragen, daher für den Zeitraum von 04:30-04:40 Uhr freigeben.
  • Sperrlogik:
- Hier war auch ein kleiner Zeitfehler meinerseits, ich wollte eigentlich ne Sperre von 3 Tagen, bzw. Bewässerung nur alle 3 Tage, also 72h.
- Ja, wenn bewässert wird, es aber zusätzlich regnet und die 5mm erreicht werden, dann Bewässerung sperren und abbrechen.
  • Bewässerungsdauer:
Da frage ich mich auch, wo die hin verschwunden ist, die sollte 10 Minuten betragen... Hab ich nicht aufgepasst und ist mir 'durch die Lappen gegangen', als endlich eine Logik erstellt wurde, die ohne Fehlermeldung akzeptiert wurde. :doh:
Wie unter "Genauigkeit" erwähnt, kann man die Dauer besser mit der Uhrzeit kombinieren.
  • Prioritäten und Überschneidungen:
Manuell hat immer Vorrang!
Sinnvoll wäre hier jedoch, dass die Dauer der manuellen Aktivierung nur zu einer weiteren 72h-Sperre führt, wenn diese 10 Minuten innerhalb 4h überschreitet. (manuelle Aktivierung für: Kinderspaß im Sommer, Bewegungsmelder nachts (Nachbars-Katzen-Schreck, Personen im Garten) <-- wieder externe Logik, da nur für die Dauer von ?15 Sekunden? getriggert

3.)
Vielen vielen Dank für die Denkanstöße. :arrow: Ausgedruckt und neben den Monitor gehängt!
Und auch hier: JA! Ich habe gerade die Worte einer meiner letzten Chefs im Ohr: "Merke tüchtig, tüchtig, tüchtig [...]!" Ich werde NIE WIEDER das Backup vergessen!!! :bow-yellow:

Leider habe ich keinen zweiten TWS zur Verfügung... Aber dafür HIER eine starke Community, die vor Aktivierung einer selbst gebastelten Logik mit Sachverstand drüber schauen kann. :handgestures-thumbupright:

Es ist definitiv wirklich besser, vor allem für einen ungeübten User wie mich, so eine Logik in einzelne Logikblöcke aufzubauen und die nach erfolgreicher Testung in einer einfachen UND-Logik zusammen zu führen....

4.)
Japp, habe ich definitiv gemerkt. Und auch bei weiteren intensiveren Tests in anderen Bereichen feststellen müssen, dass diese 'Werkzeuge' hilfreich sein KÖNNEN, aber durchaus sehr oft Unsinn ausgeben, dieses jedoch in so schönen Worten verpackt, dass man geneigt es, es zu glauben... :!: GEFAHR!

Was hatte ChatGPT für Referenzinformationen?
Ich habe die KI u.a. mit Anleitungen aus der KB gefüttert sowie mit vorhandenen funktionierenden Logiken z.T. aus dem Forum und mit den Fehlermeldungen des Logik-Editors.
Anscheinend war es nicht genug oder wurde nicht richtig von der KI verarbeitet/falsch interpretiert? Schwierig genau fest zustellen, woran genau das lag.
Habe auch nur die kostenlose Version genutzt. Vielleicht ist hier schon der erste Fehler???


Ich hoffe, ich habe alles an Infos liefern können, die noch unklar waren. Wenn doch noch was fehlt, ich antworte. :mrgreen:

Vielen Dank für eure Unterstützung und die großartige Arbeit!

Marcel
Timberwolf 350Q
timberwolf409, VPN offen, Reboot jederzeit

eib-eg
Reactions:
Beiträge: 560
Registriert: Fr Sep 14, 2018 5:03 pm
Hat sich bedankt: 1560 Mal
Danksagung erhalten: 358 Mal

#4

Beitrag von eib-eg »

Hallo @Bancoras

Der Text oben wurde nicht von mir geschrieben, sondern von der ki nach Fütterung von Infos sowie Wissen meinerseits.

Da eine Frage viewtopic.php?t=5908 aufgetaucht ist könnte ich dir helfen mit der ki.

Allerdings nicht mehr öffentlich sondern per pn.

Da wird dann alles weitere stehen.

Ich werde alle fehlerhaften und alte Dateien zur Erstellung von Logiken durch die ki löschen, um solche Fehler wie bei dir passiert sind in Zukunft möglichst zu vermeiden.

Das löschen der Dateien funktioniert aktuell am Handy nicht.
Werd es am Abend nachholen.

Dieser Text wurde von einer menschlichen ki geschrieben 😉.

Mfg
eib-eg
TW 2600_99 seit 1.1.2018 / VPN zu

Ersteller
Bancoras
Reactions:
Beiträge: 41
Registriert: So Sep 29, 2019 12:53 pm
Hat sich bedankt: 14 Mal
Danksagung erhalten: 10 Mal

#5

Beitrag von Bancoras »

eib-eg hat geschrieben: Fr Jun 06, 2025 1:13 pm Hallo @Bancoras

Der Text oben wurde nicht von mir geschrieben, sondern von der ki nach Fütterung von Infos sowie Wissen meinerseits.
Hoppala! Und ich hab das nicht einmal gecheckt, obwohl extra drunter stand (mit Unterstützung einer lernenden AI)... Ich hatte jetzt gedacht, dass du damit meinst, dass du zur Logik-Erstellung eine extra KI mit Daten sowie Fehlern fütterst.
Nicht, dass diese auch noch für dich schreibt.

Also, mal ganz ehrlich:
Unterstützung bei Code-Erstellung oder Zusammenfassung von langen Texten, insbesondere nach langen Tagen, wo man nicht mehr ganz so aufmerksam ist, ist das OK. Aber ganze Texte für sich schreiben lassen? Hmmmm..... :think:


Gruß

Marcel
Timberwolf 350Q
timberwolf409, VPN offen, Reboot jederzeit

ms20de
Elaborated Networks
Elaborated Networks
Reactions:
Beiträge: 1267
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 358 Mal
Danksagung erhalten: 695 Mal

#6

Beitrag von ms20de »

Hallo Marcel,

ich konnte den Fehler nachvollziehen und die Ursache finden.

Der Auslöser des Problems ist, dass beim Modul "Monoflop" die Zeit 129600 direkt als Zahl angeben wurde und nicht als Variable.

Code: Alles auswählen

["Monoflop", "$LockTrigger", 0, "$LockActive", 129600, 0]
Siehe: https://elabnet.atlassian.net/wiki/spac ... ulbaustein

Ich werde nächste Woche mit meinem Kollegen klären, warum dieser Code von Editor akzeptiert wurde.

Viele Grüße,
Matthias
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
TWS 3500 ID:695 VPN offen, Bitte kein Reboot ohne Absprache
Antworten

Zurück zu „Logikengine & Logik-Editor“