Neue Insider Version V 4.5 IP 4 verfügbar

Ein Dutzend Neuheiten, viele Verbesserungen und einige Bugfixes

Profilexport- und Import für HTTP-/REST-API; Visualisierung von Logik-Zellen (!); Erweitertes System-Monitoring; Admin-UI mit nun sechs Sprachen, VISU Client mit zwölf Sprachen; Aufzeichnung und Anzeige von Status-Logs (z.B. Diagnosetexte von KNX-Spannungsversorgungen und KNX-Aktoren); Vielfache Verbesserungen des VISU Editors uvm.

Alle Informationen hier: https://elabnet.atlassian.net/wiki/x/AY ... JwIjoiYyJ9

[Erfahrungsbericht] [V4.5 IP3] Schritt für Schritt Umsetzung einer (Dusch)-Lüftersteuerunjg

Hier bitte Eure Diskussionen und Feature Requests zu neuen Logikmodulen und Funktionen des Logik-Editors

Robert_Mini
Reactions:
Beiträge: 3887
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1254 Mal
Danksagung erhalten: 2183 Mal

#11

Beitrag von Robert_Mini »

Hallo!

Danke für die Initiative und aufgreifen des Balles :-).

Bezüglich deiner Bedenken: dafür gibt es den Schwellwertschalter mit Hysterese.
Ich hab mir das so gedacht: Beim Überschreiten von ($Feuchte_gemittelt + $I_Feuchte_Delta_Max) wird eingeschaltet, beim Unterschreiten von ($Feuchte_gemittelt + $I_Feuchte_Delta_Min) wird ausgeschaltet.

Beispiel mit deinen Werten: aktuell gemittelter Feuchtwert 47%. Bei 47+15=62% wird der Lüfter eingeschaltet, bei 47+5=52% wird wieder ausgeschaltet.

Eventuell braucht es da zusätzlich eine Ausschaltverzögerung.

Einverstanden?

Folgende Code-Schnipsel hab ich in deinem Posting oben eingefügt, da sie im "Template fehlten"

Code: Alles auswählen

//["Comparator" , "$Input1" , "$OutputBool" , ["$UntereSchwelle","$ObereSchwelle"]]
//["Lowpass","$In_val","$Out_val","$Time_const"]
lg
Robert
Zuletzt geändert von Robert_Mini am Mi Mär 12, 2025 9:28 pm, insgesamt 1-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Robert_Mini
Reactions:
Beiträge: 3887
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1254 Mal
Danksagung erhalten: 2183 Mal

#12

Beitrag von Robert_Mini »

Fangen wir mal schritt für Schritt an:

Zusätzliche Variablen in den nächsten Schritten:
- $Feuchte_gemittelt als float
- $I_Zeitkonstante als float

Damit den Tiefpass umsetzen. Für die Zeitkonstante einen weiteren Eingang, als Parameter 7200s.
Dann die Logik speichern. Sinnvoll wäre auch ein Ausgang mit dem geglätteten Feuchtewert und Verknüpfung mit einer Zeitserie für die richtige Einstellung von $I_Zeitkonstante.

Danach die Schaltschwellen berechnen:
Variablen:
- $Feuchte_Einschaltschwelle als float
- $Feuchte_Ausschaltschwelle als float
- $Konst1f als float mit default = 1.0

Die Addition ist etwas "kryptisch", daher gebe ich hier die Antwort:

Code: Alles auswählen

["Polynomial", "$Konst1f", "$Feuchte_Einschaltschwelle",["$Feuchte_gemittelt", "$I_Feuchte_Delta_Max"]],
Analog für die Ausschaltschwelle...

Fehler für den nächsten Schritte nur mehr der Schwellwertschalter (Comperator)...

lg
Robert

PS: Summe als Polynom: f(x) = A0+A1*x mit x=1 ist f(x)=A0+A1 , was mit beliebig vielen Summanden geht.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Ersteller
Franky
Reactions:
Beiträge: 56
Registriert: Di Dez 24, 2024 1:24 pm
Hat sich bedankt: 19 Mal
Danksagung erhalten: 16 Mal

#13

Beitrag von Franky »

Hallo zusammen,
Robert: Hysterese [...] Einverstanden?
Ja, ich denke, das ist eine sehr gute Idee und zudem einfach (im Sinne von -nicht unnötig komplex-). Ich fange mal an, meine restlichen Fragen durchzunummerieren, damit ich sie nicht vergesse :dance: :

1_Ausschaltverzögerung
An die Ausschaltverzögerung habe ich auch schon gedacht. Entweder als Nachlauf nach dem ersten Triggern oder vielleicht besser des letzten Triggerns der unteren Grenze.

2_Funktion_ohne_Vorlauf-Tiefpass_gegeben?
Worauf ich gespannt, bin, ob das ganze sofort funktioniert, oder ob nach einem Reset der Logik (-> wo speichern 'sich' die Werte vom Tiefpass eigentlich? Kann man den Initialisieren? <-) der Tiefpass erstmal Daten sammeln muss. Aber das werde ich testen und auch eine Zeitserie mitlaufen lassen.

3_Lüfter_E/A_init_nach_Neustart
Da ist noch das Thema mit dem Zustandsinit nach Neustart. Das hatte ich hier TWS, GA, Init ja schon mal aufgegriffen. Also unsere neue Logik soll nach einem (Neu)Start den Lüfter (sofort) 'initialisieren': (Neu)Start während des Duschens_ Lüfter 'sofort' einschalten, sollte er schon laufen ist das erneute Einschalten unschädlich. Wenn nicht geduscht wird: ausschalten (sollte er - warum auch immer - laufen), auch hier ist das (einmalige) Stumpfe Senden von Aus bestimmt zielführend. Es soll halt nicht mit jedem Durchlauf der Logik 0 gesendet werden müssen, nur damit das Initiliisierungs-Aus kommt.

EDIT
4_Heardbeat
Da ich die Lüftersteuerung beim Ausfall der Logik (Server, Logikmodul, Teilmenge der Logiken) mit der einfacheren Steuerung durch die Geräte selbst ersetzen will, denke ich an ein Hertbeatsignal (auf Ebene jeder Logik, nicht des gesamten TWS, da ja einzelne Logiken ausfallen können und sei es durch Deaktivierung). Ich vermute, es ist jetzt zielführend, den Schaltbefehl periodisch zu senden. Zumindest können meine MDT-Aktoren diese Art der "Übersteuerung". Der Aktor merkt wenn der Empfang ausbleibt und berücksichtigt dann den Schaltwert alternativer GAs.

hier der aktualisierte Code

Code: Alles auswählen

{
    "Level":[
    //
    // Eingänge
    //
	["$I_Feuchte","float",0],
 	["$I_Trigger","bool",false],
	["$I_Feuchte_Delta_Ein","float",15.0],
	["$I_Feuchte_Delta_Aus","float",5.0],
	["$I_Laufzeit_Max","float",120.0],
	["$I_Laufzeit_Manuell","float",5.0],
	["$I_Zeitkonstante_Tiefpass","float",7200.0],
	//
	// Verarbeitung
	//
	["$Feuchte_gemittelt","float",0.0],
    ["$Feuchte_Einschaltschwelle","float",0.0],
    ["$Feuchte_Ausschaltschwelle","float",0.0],
    ["$Konst1f","float",1.0],
    //
    // Ausgänge
    //
	["$O_LuefterEA","float",0.0]
    ],
    "Module":[
		["Lowpass","$I_Feuchte","$Feuchte_gemittelt","$I_Zeitkonstante_Tiefpass"],
		  // Berechnet den Funktionswert eines Polynoms der Form: f(x)=A0 + A1 * X + A2 * X^2 + ... + An * X^n
          // ["Polynomial", "$Variable_X", "$Ergebnis",["$A0", "$A1", "$A2", ..., "$An"]],
        ["Polynomial", "$Konst1f", "$Feuchte_Einschaltschwelle",["$Feuchte_gemittelt", "$I_Feuchte_Delta_Ein"]],
        ["Polynomial", "$Konst1f", "$Feuchte_Ausschaltschwelle",["$Feuchte_gemittelt", "$I_Feuchte_Delta_Aus"]],
          // ["Comparator","$InF","$OutB",["$UntereSchwelle","$ObereSchwelle"]]
        ["Comparator","$I_Feuchte","$O_LuefterEA",["$Feuchte_Ausschaltschwelle","$Feuchte_Einschaltschwelle"]]

	//
	// VORLAGE
	//
	  //["Polynomial", "$Var_x", "$OutputFloat",["$A0", "$A1"]],
	  //["Ratio","$Zaehler","$OutputFloat","$Nenner"],
	  //["Limiter","$Input1","$OutputFloat","$InputInnerhalb",["$Untergrenze", "$Obergrenze"]],
	  //["Comparator", "$Input1", "$OutputBool", "$Vergleichswert"],
	  //["Comparator", "$Input1", "$OutputBool", ["$UntereSchwelle","$ObereSchwelle"]]
	  //["Multiplexer",["$Input1","$Input2"],"$OutputFloat","$SelectInput"],
	  //["Or" , ["$Input1","$Input2"], "$OutputBool"],
	  //["And" , ["$Input1","$Input2"], "$OutputBool"],
	  //["Monoflop","$Trigger","$Reset","$TimerStatus","$Dauer",1],
	  //["Latch","$Input1","$Output","$Trigger",0],     // Übernimmt den Wert von $Input1 auf $Output, wenn Trigger = 0, Option 0/1/2/3 = wenn true/pos. Flanke/neg. Flanke/jede Flanke
	  //["Clocksignal","$Enable","$Takt","$Periode"],   // Zyklischer Trigger, $Takt wechselt jeweils nach Ablauf von $Periode zwischen TRUE/FALSE
	  //["HobbsMeter","$Status","$Time","$Reset"],      // Zaehlt bei $Status = TRUE die Zeit in [h]
	  //["Stopwatch","$Status", "$Time"],               // Stoppt die Zeit in [s] ab $Status = TRUE, bei $Status = FALSE wird auf 0 zurückgesetzt
	  //["CalcFormula",["$Day1Case","$Day2Case","$Day3Case","$Day4Case","$DayEquals"], "$Case", "$Formula3"],
	  //["Cron","$KonstTrue","$Reset",0,"$CronString"],
	  //["Wakeup","$Utime_start","$Status"],
	  //["BinaryMultiplexer",["$In_D","$In_E","$In_F"],"$Output"],
	  //["Lowpass","$In_val","$Out_val","$Time_const"]
	  //["Triggered", "$InputVar", "$Touched" ],        // Touched = TRUE, wenn der Eingang $InputVar die Logik getriggert hat
	  //["SendExplicit","$Send","$OutputVar",0],        // Sendet Ausgang $OutputVar, abhängig von $Send 0/1/2/3 (Paramter analog Latch), ACHTUNG "x" am Output setzen!
	  //["Interpolation","$In", "$Out", [ [x1,y1] , [x2,y2] , ... , [xn,yn ] ] ]  **/
    ],
    "Input":[
        ["Feuchte Messwert","Aktuelle relative Luftfeuchtigkeit, DPT9","$I_Feuchte","c"],
        ["Trigger manuell","TRUE sendenm, um Lüfter manuell zu starten","$I_Trigger","c"],
        ["Lüfterlaufzeit man.","Laufzeit für manuelles Lüften (Minuten)","$I_Laufzeit_Manuell","c"],
        ["Feuchtemittlung, Zeitfenster","(Sekunden, 2h sinnvoll)","$I_Zeitkonstante_Tiefpass","c"],
        ["Anstieg für -Lüfter an-","Feuchteanstieg zum Mittel für Lüfterstart (abs. rel. Feuchtigkeits-differenz)","$I_Feuchte_Delta_Ein","c"],
        ["Anstieg für -Lüfter aus-","Feuchteanstieg zum Mittel für Lüfterstop (abs. rel. Feuchtigkeits-differenz)","$I_Feuchte_Delta_Aus","c"],
        ["Lüfterlaufzeit max.","maximale Laufzeit (Sicherheitsaus in Minuten)","$I_Laufzeit_Max","c"]
    ],
    "Output":[
        ["Schalten E/A","Lüfter schalten (Ein/Aus) DPT1","$O_LuefterEA","c"],
        ["Debug_Feuchte_gemittelt","Ergebnis vom Tiefpass","$Feuchte_gemittelt","c"]
    ]
}
ok, ich habe jetzt u.a. verstanden, dass die Funktionen in dem Module-Block sequentiell nacheinander abgearbeitet werden und die Outputs einer vorgschalteten Funktion in der Regel als Input für eine nachgeschaltete Funktion dient. Ich glaube, ich muss bald mal ein paar Aufgaben damit lösen, bevor ich entscheide, ob ich das usable finde, oder doch lieber Code machen würde... Aber ich hoffe, wir sind hier noch nicht am Ende :->>

LG Franky
Zuletzt geändert von Franky am Do Mär 13, 2025 8:59 pm, insgesamt 7-mal geändert.
Timberwolf 3500L ID:1642; Support-VPN für ElabNET nach Rücksprache

Robert_Mini
Reactions:
Beiträge: 3887
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1254 Mal
Danksagung erhalten: 2183 Mal

#14

Beitrag von Robert_Mini »

Franky hat geschrieben: Do Mär 13, 2025 7:35 pm 1_Ausschaltverzögerung
An die Ausschaltverzögerung habe ich auch schon gedacht. Entweder als Nachlauf nach dem ersten Triggern oder vielleicht besser des letzten Triggerns der unteren Grenze.
ganz klar Nachlauf auf die Untergrenze, dann wir langes/kurzes Duschen besser unterschieden.
Franky hat geschrieben: Do Mär 13, 2025 7:35 pm 2_Funktion_ohne_Vorlauf-Tiefpass_gegeben?
Worauf ich gespannt, bin, ob das ganze sofort funktioniert, oder ob nach einem Reset der Logik (-> wo speichern 'sich' die Werte vom Tiefpass eigentlich? Kann man den Initialisieren? <-) der Tiefpass erstmal Daten sammeln muss. Aber das werde ich testen und auch eine Zeitserie mitlaufen lassen.
Die glättung läuft langsam hoch, die Logik kennt die Geschichte ja nicht.
Sollte kein großes Thema sein, idealerweise wird die Logik im Zustand normale Feuchte gestartet.
Franky hat geschrieben: Do Mär 13, 2025 7:35 pm 3_Lüfter_E/A_init_nach_Neustart
Da ist noch das Thema mit dem Zustandsinit nach Neustart.
die Frage ist, ob das wirklich sein muss (im Sinne von keep it simple).
Ich würde da eher ein zyklisch senden mit 30min vorsehen (Sendeoption ct am Ausgang).
Wenn der Feuchtewert hoch ist, wird sowieso eingeschaltet, wenn gering, dann ausgeschaltet.
Franky hat geschrieben: Do Mär 13, 2025 7:35 pm 4_Heardbeat
Da ich die Lüftersteuerung beim Ausfall der Logik (Server, Logikmodul, Teilmenge der Logiken) mit der einfacheren Steuerung durch die Geräte selbst ersetzen will, denke ich an ein Hertbeatsignal (auf Ebene jeder Logik, nicht des gesamten TWS, da ja einzelne Logiken ausfallen können und sei es durch Deaktivierung)
siehe oben.

Ich hab über diese Dinge auch schon oft nachgedacht.
In der Praxis aber aufgrund der Stabilität des TWS und der Option Persistenz aber absolut ausreichend.

Persistenz stellt auch sicher, dass nach einem Reboot der Tiefpass noch stimmt, sofern nicht in der Zeit nicht geduscht wird.

Lg Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

jhaeberle
Reactions:
Beiträge: 154
Registriert: Do Aug 24, 2023 11:07 am
Wohnort: Raum Augsburg
Hat sich bedankt: 67 Mal
Danksagung erhalten: 33 Mal

#15

Beitrag von jhaeberle »

Wow! Schaut schon sehr gut aus. Wie wäre es mit einem (optionalen) Inhibit-Eingang?

Da der Eingangswert float ist, kann ich meine VOC-Messwerte auch schon verwenden.

Warum die Abschaltschwelle überhaupt angeben? Ist das nicht einfach der tiefpassgefilterte Messwert?

Gruß
Jochen
TWS 3500XL, ID: 1409 (VPN offen, Reboot nach Rücksprache)

Robert_Mini
Reactions:
Beiträge: 3887
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1254 Mal
Danksagung erhalten: 2183 Mal

#16

Beitrag von Robert_Mini »

jhaeberle hat geschrieben: Fr Mär 14, 2025 1:36 pm Warum die Abschaltschwelle überhaupt angeben? Ist das nicht einfach der tiefpassgefilterte Messwert?
Weil das eher undefiniert ist. Je nach Trend der Feuchte nach Jahreszeit steigend/fallend kann das das zu sehr unterschiedlichen Zeiten führen.
Wenn die Feuchte leicht steigt erreicht der ungefilterte Wert den geglätteten erst nach Stunden (gefühlt nie).
Daher zusätzliche Schwelle unten und Nachlaufzeit.

Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Ersteller
Franky
Reactions:
Beiträge: 56
Registriert: Di Dez 24, 2024 1:24 pm
Hat sich bedankt: 19 Mal
Danksagung erhalten: 16 Mal

#17

Beitrag von Franky »

1_Ausschaltverzögerung
Robert_Mini hat geschrieben: Fr Mär 14, 2025 11:41 am ganz klar Nachlauf auf die Untergrenze, dann wird langes/kurzes Duschen besser unterschieden.
sorry, ja die Grenze meinte ich auch. Ich weiss nur nicht, ob das erstmalige Erreichen der Grenze das Lüfteraus einleiten soll, oder ob ein erneutes Überschreiten der Untergrenze den Ausschalttimer wieder löschen sollte. Also wenn die Ausschaltgrenze kurz erreicht wurde (langes Einseifen) und danach die Feuchtigkeit wieder steigt, aber die Einschaltschwelle nicht mehr erreicht, soll er ja eigentlich nicht ausschalten. Hmmm, aber dann kann man nicht mit der normalen Hysteresefunktion arbeiten, nehme ich an. Wäre das nicht eine sinnvolle Erweiterung/Variante für die Hysteresefunktion?

Aber auf jeden Fall erstmal ausprobieren. Ist wahrscheinlich nur ein theoretischer Fall. Zur Not würde ich die Hysteresefunktion nachbauen unter Einbezug der Erweiterung. Ich glaube auch das wäre eine gute Übung für custom logiken.

3_Lüfter_E/A_init_nach_Neustart
Robert_Mini hat geschrieben: Fr Mär 14, 2025 11:41 am die Frage ist, ob das wirklich sein muss (im Sinne von keep it simple).
ACK! Ich gucke mir aber noch mal Deine Lösung von hier an: Erweiterung für Persistenz: Senden nach Reboot

4_Heardbeat
Robert_Mini hat geschrieben: Fr Mär 14, 2025 11:41 am Ich hab über diese Dinge auch schon oft nachgedacht.
In der Praxis aber aufgrund der Stabilität des TWS und der Option Persistenz aber absolut ausreichend.
Auch das dürfte (auf den TWS bezogen) stimmen. Ich habe aber die fixe Idee, dass das Haus auch dann noch (mit Komfortabstrichen) funktionieren soll, wenn ich mal längere Zeit ausfalle und dann ein Logikmodul kaputt geht, also dem Vorteil der dezentralen KNX-Welt. Und da das mit den MDT-Aktoren - glaube ich - echt easy ist, will ich das probieren. Für die Logik reicht es zyklisch zu senden. Der Aktor regelt den Rest: Kein zyklischer Eingang aus dem Logikmodul/TWS mehr da, dann verwendet er automagisch die parallel immer eingehenden Telegramme der Haupt-KNX-Geräte (also die Hystereseschaltfunktion des Feuchtigkeitssensors). Diese werden im Regelbetrieb ignoriert, so lange die Logiktelegramme zyklisch eingehen. Eigentlich ganz pfiffig. Es gibt halt zwei Automatisierungen parallel. Die eine, einfache, von den Geräten selbst (nur eventbasiert) die nur berücksichtigt wird, wenn der Server ausfällt. Der Server arbeitet halt Eventbasiert und refreshed sein Signal periodisch, damit der Aktor weiß, dass die Logik noch lebt.

Das tolle ist, die einfache Lösung (Kommunikation der Geräte selbst), gibt es in der Regel ja schon.

Man startet ja oft erst mit einer einfachen Basisfunktion und merkt dann, dass man mehr will. Dann schaltet mal die einfache Version halt einfach nicht ab, wenn die TWS-Lösung da ist und schon gibt es das Fall back (fast) "geschenkt" (klar, doppelte Anzahl Telegramme, höhere Komplexität des Gesamtsystems, zwei Lösungen zu pflegen und ab und zu auch zu testen)...
Zuletzt geändert von Franky am Fr Mär 14, 2025 7:24 pm, insgesamt 1-mal geändert.
Timberwolf 3500L ID:1642; Support-VPN für ElabNET nach Rücksprache

Robert_Mini
Reactions:
Beiträge: 3887
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1254 Mal
Danksagung erhalten: 2183 Mal

#18

Beitrag von Robert_Mini »

So, lass uns das mal abschließen:

Es fehlen noch 2 Dinge:
- Ausschaltverzögerung
- Sperre der Logik

Für die Verzögerung dient das Modul Monoflop:

Code: Alles auswählen

["Monoflop","$Trigger","$Reset","$TimerStatus","$Dauer",1],
Als Trigger dient der Schwellwert, dafür am Comperator $O_LuefterEA durch $Schwellwert_Status ersetzen.

Das Monoflop lautet dann:

Code: Alles auswählen

["Monoflop","$Schwellwert_Status","$I_Sperre","$NachlaufTimerStatus","$I_Nachlaufzeit",1],
Neue Variablen natürlich zu definieren und $I_Sperre und $I_Nachlaufzeit als weiteren Eingang.

Hinweis: Sperre als Reset am Timer bewirkt, dass der Timer beim Sperren zurückgesetzt wird.

Für den Ausgang braucht es noch ein wenig UND/ODER-Logik:

$NachlaufTimerStatus ODER $Schwellwert_Status => $LuefterEin

$LuefterEin UND -$Sperre => $O_ LuefterEA

Lg
Robert


PS: zum Thema Einseifen: das stellt irgendwie den Schwellwert in Frage.
Entweder setzt man den oberen Schwert klein genug, dass nach dem Einseifen dieser wieder überschritten wird, oder den unteren klein genug, dass nicht ausgeschaltet wird oder die Nachlaufzeit lange genug, dass das Einseifen egal ist.

PPS: Wenn man es wirklich komplexer möchte würde ich den Oberen Schwellwert während der Nachlaufzeit = dem unteren Schwellwert setzen, das würde nur in der Zeit die Nachlaufzeit nach dem Einseifen früher neu triggern => gefällt mir 😉.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

jhaeberle
Reactions:
Beiträge: 154
Registriert: Do Aug 24, 2023 11:07 am
Wohnort: Raum Augsburg
Hat sich bedankt: 67 Mal
Danksagung erhalten: 33 Mal

#19

Beitrag von jhaeberle »

Super!!

Eine (miese) Erfahrung mit Sperren… Wenn die Sperre eintrifft während der Lüfter schon läuft, ist es (jedenfalls für mich) nicht selbstverständlich, dass da am Ausgang noch ein Ausschaltsignal ankommt. Per Definition ist ja nix mit Nachlaufzeit… Jedenfalls ist das mit einem Inhibit-Eingang scheinbar so. Der schaltet die Logik einfach ab, wie ein BREAK in vielen Programmiersprachen und du hast keine Möglichkeit, noch irgendwas an den Ausgang zu bringen. Das ist okay, wenn die Logik gar nicht erst anlaufen soll, aber verhindert ein sauberes Ende einer bereits laufenden Logik…
TWS 3500XL, ID: 1409 (VPN offen, Reboot nach Rücksprache)

jhaeberle
Reactions:
Beiträge: 154
Registriert: Do Aug 24, 2023 11:07 am
Wohnort: Raum Augsburg
Hat sich bedankt: 67 Mal
Danksagung erhalten: 33 Mal

#20

Beitrag von jhaeberle »

Wow. Visualize in V4.5 IP4…

Bild

Allerdings bin ich noch nicht dahinter gestiegen, wie man die Objekte selber anordnen kann… es geht irgendwie, aber nicht so, dass man einen Kasten packt und bewegt…

Aber, tolle Sache und der richtige Weg…
TWS 3500XL, ID: 1409 (VPN offen, Reboot nach Rücksprache)
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Logik (Module & Editor)“