ElabNET Technik Forum

Hallo Sven,

Robosoc hat geschrieben: ↑Mo Aug 17, 2020 10:12 pm Und wie schon von Robert geschrieben, es geht nicht darum die Möglichkeiten einzuschränken, sondern lediglich im Code einer Customlogik definieren zu können, dass ein Eingang als ParameterEingang konzipiert ist.

Ja, habe ich auch so verstanden, und die Idee finde ich auch grundsätzlich gut!

Trotzdem denke ich, dass man über einige Dinge gut nachdenken sollte, damit die an sich gute Idee die Sache am Ende nicht insgesamt für den Anwender von geteilten Logikbausteinen verkompliziert. Das wäre z. B. für mich der Fall, wenn Anpassungen über die Oberfläche (und auch das Neu-Speichern) unterschiedlich reagieren, abhängig davon ob ein Eingang im Code als Parameter-Eingang definiert wurde, oder ich einen "normalen" Eingang selber auf der Oberfläche zum Parameter-Eingang gemacht habe. Oder ich auf der Oberfläche einen im Code als Parameter-Eingang definierten Eingang in eine Objektverknüpfung geändert habe...

Und es hilft auch sehr, wenn man sich noch nicht so auskennt mit dem TWS und eine fremd-geschrieben Logik übernimmt, wenn man weis, dass ein Eingang vom Ersteller als Parameter Eingang gedacht war...

Ja, finde ich ein gutes Argument

da nervt es dann sehr, wenn du jedesmal 6-7 Eingängen je Logik erklären musst, dass Sie Parametereingänge sind und dass viele die gleichen Parameter verwenden...

Wäre es hier denn nicht einfacher, einfach die Logik einmal zu erstellen, die gewünschten Eingänge auf "Parameter" setzen und dann x mal zu kopieren? Beim Kopieren werden doch die Parameter-Einstellungen mit übernommen?!

Robosoc hat geschrieben: ↑Mo Aug 17, 2020 10:18 pm

maggyver hat geschrieben: ↑Mo Aug 17, 2020 9:57 pm Jedoch sollte die Mitgabe eines Defaultwertes optional sein.

Unbedingt, ja. Ich finde sogar zwingend und nicht optional, weil das Level ja eh immer einen Defaultwert hat. Und am Liebsten sollte auch der Defaultwert aus dem Level genommen werden, der mit dem Input zusammenhängt, dann gibt es nur einen Defaultwert und der Code ändert sich nicht weiter.

Parameterinputs sind Inputs, die ihre Defaultwerte direkt aus den Levelen der Inputs selbst beziehen. Die Definition kann man so stehen lassen und genau so sollte es dann auch umgesetzt werden.

Oder?




Da der Code kopiert wird, werden auch die Defaultwerte der Parameterinputs mitkopiert. Bei einer Änderung der Defaultwerte durch den Anweder zum Originalcode sollte es eventuell eine Kennzeichung geben. Auch hinsichtlich der etwaigen "Fehlersuche", dies könnte in der Oberfläche des TWS erfolgen, falls dies als notwendig erachtet werden sollte. Wie genau man dies oder ob es überhaupt Sinn macht, solang dies reine Customlogiken sind, weiß ich nicht. Der Wunsch für diesen Anzeigenwunsch kam beim Schreiben der Zeilen auf bevor ich es wieder vergesse ...

Mehr zum Thema "Anzeige von Versionsnummer der Logiken direkt auf Oberfläche bzw. im Editor darstellen" ist nicht bestandteil dieser Diskission und sollte wenn Bedarf besteht eben in einer andere Diskussion fortgeführt werden, dazu geht es hierlang viewtopic.php?f=24&t=2355.



LG

René

Parameter oder Konstante könnte man doch zentral erfassen. Kenne das bisher von Loxone das man sowas extra macht und dann wie auch merker überall nutzen kann wo man es braucht.

Hallo Michael,

Robosoc möchte einen Paramtereingang haben, der sich wie ein Eingang verhält, jedoch den Datentyp und ein eventuellen Startwert aus dem Level holt und automatisch behält, bis der Startwert eventuell durch eine Änderung in dem dazugehörigen Leveleintrages geändert wird oder dann überschrieben wird falls eben einen extrener Wertgeber von einer anderen Logik einen neuen Wert auf diesem Parametereingang sendet.

Derzeit ist eine Übernahme eines Startwertes nur über das JSON-Objekt mit dem Schlüssel Level möglich.

Siehe auch hierzu die KB 4.6.5 Custom-Logikbausteine 4.a app.php/kb/viewarticle?a=84

Du würdest das Ganze umgehen und würdest dir einen Konstantenmerker wünschen, den direkt mit dem Parametereingang verbinden um der Logik dann einen Wert vorgeben zu können. Das löst aber das Problem mit dem Startwert nicht, denn beim Abspeichern der Logik fordert ja der Baustein keine Werte an und selbst mit einen Wertgeber, der zyklisch seinen Wert versendet, würde es keinen Startwert geben.

Michael und Robosoc, habe ich dies so richtig verstanden?



LG

René

Ich finde Markus (Ide71) hat es hier recht gut dargestellt und darauf bezeihe ich mich ja auch in meinem Beitrag #1.

Ich will überhaupt nichts Neues haben und ich glaube einige von Euch, die sich hier beteiligen, haben mich irgendwie falsch verstanden.

Alles soll so bleiben wie es ist. Ich (und Markus mit seinem anderen Post ja auch bereits) wollen lediglich, dass man in einem Customlogik-Code vorbestimmen kann, dass ein Eingang als Parametereingang dargestellt wird, wenn man die Customlogik anlegt.

Dafür finde ich den Ansatz von Robert optimal einfach ein Eingangsmerkmal p (zusätzlich zu a, c, u und x) zu definieren.
["TriggerInterval","Logik triggered alle x Sekunden", "$interval","p"]

Desweiteren sollte ein "p"-Input sich meines Erachtens wie eine c verhalten. Da ein Parameter ja nicht dynmisch über externe Signale geändert wird, wäre ein c-Verhalten quasi ein u-Verhalten, ausser jemand ändert den Wert des Parameters im Doktormodus. Im Gegensatz zum u könnte man dann im Doktormodus damit dann schneller testen. Aber letztlich kann ich auch gut mit einem reinen u-Verhalten leben.

Da man im Custom-Code immer einen Defaultwert für ein Level definiert (es geht garnicht ohne), sollte auch ein p-Input in der Oberfläche diesen Defaultwert ausweisen (denn im Code hat er den ja schließlich auch sofort, und dass erkennt nur Jemand, der den Code zu lesen weiß, was beim übernehmen von fremden Code aus dem Forum ja nicht immer gegeben ist).

Beispiel zu meinem Vorschlag:
Übernimmt jemand diesen Code ab, so würde das wie folgt aussehen: Speichert man die Logik, würde man (als Einsteiger) erwarten, dass nichts passiert und man würde sich sehr wundern, dass die Logik wie von Geeisterhand alle 10 Sekunden den Ausgang toggled.

Deshalb soll mein Featurerequest folgendes bewirken. Nur durch Ändern des Codes an einer einzigen Stelle (durch setzen des p statt c) am Ende der folgenden Codezeile bewirkt man, dass die Logikzelle wie folgt aussieht: Der zweite Eingang wird also direkt mit dem im Code eingestellten Default-Wert angelegt. Selbstverständlich kann man ihn auch auf Wunsch mit externen Eingängen verknüpfen, wenn man das will. Es ist ein normaler Eingang. Aber auf diese Weise kann der Schreiberling der Logik dem Nutzer klar erkennbar machen, wie der Eingang ursprünglich geplant war.

Und in diesem Beispiel kann man auch erkennen, warum ich das c-Verhalten besser fände. Ändert jemand im Dok-Modus den Wert von 10 auf 2, dann würde man sich wundern, wenn das nichts ändert. Man müsste hier erst einmal auf dem Input 1 triggern um den Intervall aktiv zu ändern.

Was meint Ihr? Soll ich der FR losfeuern und zum Abstimmen bringen?

Hallo Robosoc,

ich habe mich weiter mit der Thematik beschäftigt und mittlerweile verstehe ich was Markus (Ide71) wollte und du versucht hast hier zu klären.
Zurück zu deiner Frage.
Von meiner Seite aus kannst du den FR so wie von Markus (Ide71) gewünscht und von dir beschrieben wurde zur Abstimmung geben.


LG

René