Logik, Laufzeit und Reihenfolge der Berechnung

[Tokamak]

Warum nicht? Das wäre aber dann aber eher ein "Nordrhein-Stammtisch"...

[Taxus]

So ein Aachen-Stammtisch hätte was ... .

[Tokamak]

Interessanter Ansatz. Müsste man vielleicht im Hinblick auf den nächsten HS mal drüber diskutieren.

Möglicherweise interessant, aber sicher unausgegoren.
Nächster HS? HS4?

Btw, bin jetzt ab und zu in Aachen - Sohnemann fängt Studium an - da kann man das ja mal bei einem Bier vertiefen

Das Phänomen "Sohnemann in Aachen" ist sehr geläufig Melde dich einfach.

[MatthiasS]

Interessanter Ansatz. Müsste man vielleicht im Hinblick auf den nächsten HS mal drüber diskutieren.

Btw, bin jetzt ab und zu in Aachen - Sohnemann fängt Studium an - da kann man das ja mal bei einem Bier vertiefen

[Tokamak]

Ja, klar. Aber welcher Eli könnte eine Client-Programmierung a la Quad-Client usw. hinbekommen? Dort wird seitens Dacom/Gira investiert, sicher auch, weil ihr das pusht.

Bei der Programmierung tut sich nichts. Eine zusätzliche Python-Schnittstelle mit Zugriff auf GAn, das wäre schon mal was. Dann könnten wir hier auch Klassen austauschen.

[MatthiasS]

Das meine ich.

Ok, da stimme ich dir voll zu.

Letzendlich muss man aber bedenken, für wen die Kiste gemacht ist, für den Elektro-Installateur. Da ist nix mit C++ etc. Da ist Klicki-Bunti nicht lästig, sondern überlebenswichtig

[Tokamak]

"Verschiedene Programmiersprachen" gibt es im HS nicht, das ist alles Python.

Das meinte ich nicht. Ich muss eine krude "Programmiersprache" a la GDV-Datensätze lernen, um Bausteine zu schreiben, die Python kapseln. Die setze ich mit Klicki-Bunti in einem Graphik-Editor zusammen (auch eine Art "Programmierspache", wenn auch graphisch). Dann gibt es losgelöst davon Sequenzen, wieder ein eigener Editor, auch eine Art "Programmierung". Man braucht X verschiedene Editoren, um etwas hinzubekommen. Das meine ich.
Wie einfach wäre die Welt doch, würde es für den Experten eine Python-Schnittstelle im Experten geben. Das wäre stringent. Der Rest wirkt zusammengewürfelt, ohne architektonisches Konzept. Eine Diplomarbeit für die Bausteine, eine Diplomarbeit für den Graphikeditor, "hoppala, Sequenzen wären nett", das alles in einen Topf geworfen und irgendwie passend gemacht.

Sicher ist mein Zugang ein anderer. SPS kenne ich nicht, aber Eclipse, C, C++ und Java. Für Menschen, die mit SPS begonnen haben, mag der HS ein Fortschritt sein. Für mich ist es ein Rückschritt.

Python befindet sich im Experten, in Form von gekapselten Modulen. Die darf man selbst erstellen, Gira liefert sogar eine kleine Anleitung dazu.

Meinst du die Anleitung, die man von Dacom bekommt, wenn man dort nachfragt? Eine andere kenne ich nicht. Dort steht nichts von Bytecode.

Und wer mag/kann, darf in in einzeiligen Logikbausteinen auch komplexe Programme mit Datenbankhandling (hs-phone), einem TCP-Server (hs-fusion) oder was auch immer codieren.

Klar kann ich das. Aber das sind keine Standard-Boardmittel, die für einen User, der sich den HS und Experten installiert, leicht zugänglich sind.
Für mich klingt das so, als ob Apple das iPhone damit verkauft, dass es Jailbreak gibt, oder ein Hersteller sein Windows 6.5-Handy, weil man darauf auch Android installieren kann.

Wie gesagt, ich habe meinen Frieden mit der Kiste geschlossen, kann aber weiterhin nachvollziehen, dass andere ihre liebe Not mit dem HS haben.

[NilsS]

Zusätzlich stelle ich die Behauptung auf, das eine Objektorientierter Logikbaustein zuverlässiger arbeitet als sein konvetioneller Pendant.
Eine gewisse Komplexität natürlich vorausgesetzt.

Intern ists dem HS egal, da die Logik wenn sie Werte empfängt, genauso compiliert ist wie in den ByteCode Bausteinen.

Jedoch nicht bei einem Baustein.
EN[1]==1 -> mache Funktiona
EN[1]==1 -> mache Funktionb
EN[1]==2 -> mache Funktionc

sondern
if EN[1]==1 -> mache Funktiona und Funktionb
elseif EN[1]==2 _> mache Funktionc

[NilsS]

Ok hab nur mal kurz angelesen,

was willst du machen. Gehen tut "fast" alles und das fast betrifft eigentlich nur SSL und Verschlüsselung, als auch große Speicheranforderungen an das Gerät.

[MatthiasS]

So ist es. Klar ist, dass bytecodierte Bausteine nicht unbedingt einfach zu durchschauen sind. Aber wenn sie laufen, dann laufen sie auch, genau wie konventionelle Logiken auch.

Die Warnung von Michel bezieht sich strenggenommen auf jeden selbst erstellten (nicht im Auslieferumfang) Baustein, ob konventionelle HS-Python-Logik oder die komplexere mittels eval().

Und klar, auch mit dem Originalbausteinen kann man bei geschickter Vorgegensweise den HS abschießen.

@Tokamak
In einigem stimme ich dir zu, manchem muss man aber widersprechen, weil es schlicht falsch ist.

"Verschiedene Programmiersprachen" gibt es im HS nicht, das ist alles Python.

"Kein Konzept" ist falsch - offensichtlich.

Python befindet sich im Experten, in Form von gekapselten Modulen. Die darf man selbst erstellen, Gira liefert sogar eine kleine Anleitung dazu. Und wer mag/kann, darf in in einzeiligen Logikbausteinen auch komplexe Programme mit Datenbankhandling (hs-phone), einem TCP-Server (hs-fusion) oder was auch immer codieren.

Alles in reinem Python, mit einem minimalen Overhead, damit der HS die Bausteine in seiner GUI (als Funktionsblock) anzeigen kann (genau wie z.B. eine SPS).

[MarcNaroska]

Prinzipiell machen Nils Bausteine nichts anderes, als mehrere Python-Befehle abzuarbeiten, anstatt nur eine "if then"-Abfrage auszuführen und ggf. noch einen Timer zu starten.

Man schafft es auch ohne größere Probleme, mit den vorhandenen Baustein-Möglichkeiten den HS lahmzulegen (durch Schleifen, etc.).

Das Lahmlegen geht natürlich mit Nils Bausteinen ein wenig "schicker", wenn man da einfach mal "was hinrotzt". Ich sehe das Problem aber nicht ganz so dramatisch mit Michel, wobei ich auch nur auf meinem eigenen HS bastele und nicht für Kunden o.ä...

Vorsicht ist aber natürlich immer geboten wenn es ums programmieren geht...

[GKap]

Hallo MatthiasS!

Schleifen, Bedingungen, innerhalb eines Bausteines doch überhaupt kein Problem. Die Bytecode-Bausteine von Nils (und anderen) nutzen das intensiv.

Also auf Anhieb verstehe ich das Konzept von Nils nicht vollständig, da müsste ich mich erst mal einarbeiten. Aber offensichtkich kann man in den Homeserver mehr reinbringen, als nur die einzeiligen Python-Befehle bei selbst entwickelten Bausteinen. Das würde sicher die Möglichkeiten stark erweitern. ABER: In einem Posting dazu von Michel ist mir eines aufgefallen:

[WARNUNG]Die Nutzung dieser Möglichkeit kann bei unsachgemäßer Anwendung euren HS/FS komplett lahmlegen!

Ich rate dringend davon ab, das auf produktiven HS/FS einzusetzen und/oder zeitkritische bzw. umfangreiche Aktionen in den Code zu packen!

Die Behandlung dieses Codes weicht vom HS-internen Standard erheblich ab!
[/WARNUNG]

Nach meinem Vertändnis soll doch der Homeserver einem gewissen professionellen Anspruch genügen, daher kämen für mich solche Methoden nur dann in Frage, wenn dies von Gira/Dacom auch so vorgesehen und dokumentiert ist!

Oder wie seht ihr das?
fragt
GKap

[Tokamak]

Schleifen, Bedingungen, innerhalb eines Bausteines doch überhaupt kein Problem. Die Bytecode-Bausteine von Nils (und anderen) nutzen das intensiv.

Und ein Fehler in solch einem Baustein zerrupft im schlimmsten Fall den HS derart, dass man nicht mehr an ihn herankommt.
Hinzu kommt, dass sich dahinter kein Konzept verbirgt. Verschiedene Editoren, verschiedene "Programmiersprachen", ein bisschen hier, ein wenig dort...

Wie gesagt, ich habe für mich eine Lösung gefunden. Meine Bausteine sind weiterhin klein, machen mir aber das Leben leichter, weil sie meiner Art zu programmieren ein wenig mehr entsprechen. Die Logik bleibt im Editor des Experten, nicht im HSL-Editor.

Bezeichnest du Python nicht als eine solche?

Doch, sicher. Aber es ist eine Hintertür. Das hat nichts mit einem stringenten Konzept zu tun. Brächte Dacom Python in den Experten, wäre ich dabei.

[MatthiasS]

Mit einer richtigen Programmiersprache...

Bezeichnest du Python nicht als eine solche?

[Tokamak]

Vermutlich liegt es auch am Marketing. "Männer-Visus" lassen sich besser verkaufen als eine Programmierschnittstelle, die dem Namen gerecht wird.

Mir ist es total zuwider, mit einer Maus a la Turtle bunte Kästchen zu verschieben. Meine Logik für eine externe Steuerung der Wärmepumpe (die keine KNX-Schnittstelle hat) ist derartig komplex, dass sie durch den Experten nicht mehr geprüft werden kann. An ihr habe ich tagelang gesessen, und sie ist immer noch nicht fehlerfrei. Mit einer richtigen Programmiersprache wäre das Thema in wenigen Stunden abgefrühstückt gewesen.

Die meisten haben sich damit abgefunden oder wie Nils einen Workaround gefunden, mit dem Dacom sicher nicht gerechnet hat. Ich selbst habe wegen der grottigen Programmiermöglichkeiten mit dem Gedanken gespielt, den HS wieder zu verkaufen und auf inzwischen vorhandene Alternativen umzuschwenken. Hierzu fehlen mir aber insbesondere Zeit und Muße, alleine schon für die Aus- und Bewertung der Alternativen.