ElabNET Technik Forum

Ihr führt hier eine sehr spannende Diskussion, die mich sehr nachdenklich stimmt. Insbesondere die kritische Sicht auf die Langzeiteffekte von Chris aus der Perspektive eines Programmierers lässt mich hellhörig werden.
Mir kommen für unser Einfamilienhaus gerade folgende Sorgen bzw. Abwägungen:

Im Haus wird z.B. ein KNX-Jalousieaktor verbaut, der sonnenstandsabhängig beschatten kann. Macht es da noch Sinn, die gesamte Steuerung in eine Logik zu überführen, weil die letzten 10% vorstellbarer Funktionen vom KNX-Gerät nicht erbracht werden können?
Baue ich mir mit Logiken einen zusätzlichen SPOF auf, weil ich an sich intelligente Geräte entmündige und durch noch mehr Intelligenz an anderer Stelle zentral zu übersteuern versuche? Was geht dann noch, wenn der TWS mal nicht will wie er soll?
Bedeuten eigene Logiken am Ende gar keinen Komfortgewinn, weil dem Gewinn ein bei mir steigender Wartungsaufwand hierfür gegenübersteht?
Wirken eigene Logiken sogar wertmindernd, wenn das Haus irgendwann verkauft werden soll und der Käufer niemanden findet, der die Wartung übernimmt oder beurteilen kann, wie oder warum Dinge im Haus funktionieren?

Ich stelle nicht in Frage, dass es Notwendigkeiten für Logiken geben mag. Auch staune ich, was Ihr mit Logiken so alles bewerkstelligt. Nur stelle ich mir inzwischen die Frage, ob es mir das Wert ist, unabhängig davon, in welcher Weise ich eine Logik zusammenbaue. Vielleicht ist weniger hier mehr für mich. Irgendwann bin ich so alt, dass ich nicht mehr mein eigener Admin sein will.
Das frage ich mich auch bei der Visualisierung. Damit kann man sich ja auch Monate beschäftigen, aber das Interesse an der irgendwann fertigen Visu im Alltag lässt wahrscheinlich nach 2 Wochen nach (zumindest was den bedienenden Teil der Visu betrifft; Langzeitbetrachtung und Bewertung gemessener Werte mal außen vor).

Bin gespannt, welche Wege Ihr findet, das zu vereinfachen.

Verehrte Foristen,

ich verstehe Euch durchaus und Ihr rennt auch offene Türen ein.

Wir haben eine enge Terminlage und haben uns beim Design des derzeitigen Logikeditors nach 98% der Einsatzfälle gerichtet (das sind einfache übersichtliche Logiken) und dem Ausfeilen der erweiterten Fähigkeiten hinsichtlich granulares Instant-Update, Persistenz, Performance und Simulation & Fehlersuche. Zudem werden viele Funktionen, die in anderen Systemen von der Logik übernommen werden müssen, bereits durch Dispatcher und den protokollspezifischen Funktionsmodulen übernommen, womit die Logikengine für vieles gar nicht in Anspruch genommen werden muss.

Es ist ja nicht mit einem "größeren Editor" getan. Das selbst wäre nicht sehr schwer. Sondern es geht dabei auch gerade darum, diese vielen erweiterten Leistungsmerkmal darin auch unterzubringen. Das ganze in allen Browser auf allen Devices und auch über VPNs bei geringer Bandbreite funktionierend auf einer embedded Hardware mit einer TDP von 2 Watt. Das ist ein umfassendes Projekt.

Selbst Rom ist nicht an einem Tag gebaut worden und unser Plan besteht darin, zunächst die Konnektivität zu anderen Systemen zu verbessern, weil dies einen erheblich größeren Nutzwert hat und danach arbeiten wir an all den Logikthemen, komfortablen Zeitschaltuhren, Übersichtsdarstellung zu verknüpften Objekten, Visu-Generatoren usw.

Ich würde mir wünschen, dass Kritik nicht nur nicht einseitig auf das eine fehlende Leistungsmerkmal abzielt, während die vielen anderen Leistungsmerkmal weitestgehend unerwähnt bleiben. Ein einseitiges Bashing ist weder motivierend noch nachvollziehbar, bitte denkt an die hier mitlesenden Entwickler. Alle zwei Wochen auf eine gleiche Kerbe zu dreschen ist nicht hilfreich und kostet uns wertvolle zeitliche Ressourcen, nur um am Ende jedesmal die gleiche Antwort zu geben.

Wir arbeiten daran alle Wünsche zu berücksichtigen und bitten um entsprechende Geduld.


Ich bitte um Verständnis

Stefan

@Smart_Jeanie: Ich handhabe das so, dass ich alles, was geht, direkt in den Aktoren einstelle. Für meine Sonnenstandsabhängige Beschattung benötige ich z.B. 0 Logik von irgendeiner Logik-Engine. Ich habe einfach die MDT-Aktoren so eingestellt, dass es für mich passt ... und sogar meine bessre Hälfte ist begeistert davon. Alles was nicht direkt in den Aktoren eingestellt werden kann (oder ich einfach nicht weiß, dass das möglich wäre), übernimmt eine Logik.

@StefanW: Für mich persönlich eine Antwort, mit der ich recht gut leben kann. Wie schon geschrieben, für mich wäre es auf jeden Fall grafisch schöner, aber bis dahin lebe ich auch ganz gut mit dem selber coden. Und wenn es soweit ist, dass ihr das umsetzt, freue ich mich darüber.

Also nur nicht demotivieren lassen, für mich ist mein TWS nach wie vor mein Lieblingsspielzeug im Haus.

LG
Marcus

@Smart Jeanie

Es ist ja ein wenig OT die Problemstellung, denn egal wie gut die TWS-logik sich bedienen lässt jede Zentralisierung in einer Logik bringt auch eine zentralisierung eines umfassenden Stillstandes der KNX-Funktionalität.

Insofern ist es immer ratsam viel an Funktionalität vor zu planen und dann jene Geräte auszuwählen, die diese Anforderungen möglichst direkt per ETS-Parameter erbringen. Dann solltenin den zentralen Logiken bestenfalls nur noch Funktionen stecken, auf dieman auch hier und da mal verzichten kann, da sie "nur" besondere Komfortbedürfnisse erfüllen.
Bei der Konstruktion der Logiken sollten diese bestenfalls so implementiert sein, das wenn die Logik nicht funktioniert, die Standardfunktionalität ddavon nicht beeinträchtigt ist.

Also nicht einfach die Taster / PM dumm machen und alles in der Logik verbauen, sondern die Möglichkeiten der Geräte nutzen und nur ergänzend mit der Logik wirken.

Ansonsten bleibt aus Erfahrung festzuhalten, wer einen Anspruch an ein wirklich smartes Haus hat, der wird in der gesamten Anlage wohl nie fertig werden, weil man immer mal neue "Spielzeuge" findet die integriert werden wollen oder sich auch einfach Nutzungsverhalten ändern.
der TWS ist ein wichtiger Schritt zu einer echten KI gesteuerten Logik, da er schonmal das potential reichlicher Sensordatensammlung mitbringt. im Docker lassen sich dann sicher auch die ein oder anderen kI-Module Implementieren, die dann wiederum via TWS zu sinnvollen Aktionen führen.

Ich glaube das wird in der Zukunft der nächste notwendige Schritt an Logik werden.
Womöglich braucht es dann kaum noch so einen Logikeditor. Sondern nur noch eine Verbindung von Sensorwerten zu einem Funktionsknoten und die GA's zu den Aktoren als Ergebnis. Die jetzt noch mühsam erdachten / programmierten Bedingungen erkennt das System dann selbst.

Ich lese hier nur konstruktive und sachlich gut begründete Kritik aber kein Bashing Stefan!
Erst sagst du wir sollen uns damit beschäftigen, was auch gemacht wurde. Das Feedback dazu passt dir dann aber offensichtlich nicht. Ich weiß es ist schwer das euch nicht jeder zu Füßen liegt und das Produkt in den Himmel lobt. Das würde euch aber nicht weiter bringen. Das Feedback hier von einigen erfahrenen Power Usern halte ich für sehr wichtig um Verbesserungspotential aufzuzeigen.
Da finde ich es schade wenn das gleich wieder klein redetet, als Bashing abgetan wird.

starwarsfan hat geschrieben: ↑Di Aug 11, 2020 9:36 pm Also nicht zu wollen, lasse ich mir nicht vorwerfen. Dann hätte ich die Kohle ganz sicher nicht dafür ausgegeben, zumal der TW für seinen ursprünglichen Einsatzzweck (Edomi@Docker) ja auch schon nicht zum Einsatz kommt.

Ok sorry, war sicher ein wenig über‘s Ziel geschossen.

Aber mich würde interessieren warum du Edomi nicht am TWS laufen lässt?

starwarsfan hat geschrieben: ↑Di Aug 11, 2020 9:54 pm Ich habe da so eine vage Idee, woher nicht unwesentlicher Input für diesen Baustein kommt...

Eher nein. War ursprünglich mit Suntracer Logik umgesetzt und ist dann nach Bedarf gewachsen. Man sieht daran aber, dass sich eigentlich ein Standard an Anforderungen ergibt, leider durch die Vielfalt Sam Aktoren etwas scheitert.

FabKNX hat geschrieben: ↑Di Aug 11, 2020 10:26 pm Ich brauche definitiv mehr Geleit bei der Erstellung einer Funktion. Ich brauche mehr Beispiele. Auch ganz Einfache! Beim Auswählen der Bausteine bleibe ich stecken! Ich weiss nicht, was ich von den zig Möglichkeiten ich brauche. Ich weiss nicht was ein Monoflop ist und wofür ich ihn gebrauchen könnte.

Zähl mal ein paar Beispiele auf, dann Versuch ich zu helfen.

Lg
Robert

Hallo FabKNX,

hast du dir schon das mal angesehen? Darin ist durch Wolfgang (Eraser) dies sehr schön im Detail erklärt, da gibt es auch ein kleine Beschreibung zum Herunterladen. Sind auch einige nützliche Verschaltungen angegeben. Vielleicht hilft das für das Thema Monoflop.

viewtopic.php?f=24&t=1911


LG

René

Robert_Mini hat geschrieben: ↑Do Aug 13, 2020 2:28 pm

starwarsfan hat geschrieben: ↑Di Aug 11, 2020 9:36 pm Also nicht zu wollen, lasse ich mir nicht vorwerfen. Dann hätte ich die Kohle ganz sicher nicht dafür ausgegeben, zumal der TW für seinen ursprünglichen Einsatzzweck (Edomi@Docker) ja auch schon nicht zum Einsatz kommt.

Ok sorry, war sicher ein wenig über‘s Ziel geschossen.

Aber mich würde interessieren warum du Edomi nicht am TWS laufen lässt?

Weil edomi leider nicht auf dem Hutschienen TWS läuft, da edomi zwingend eine 64 Bit Architektur voraussetzt.

Vg
Earl

Yves hat aber nen 2500-er TWS, das nix Hutschiene. Er hat sich aber so eine schicke Montagehalterung für seinen TWS gedengelt, wodurch er seinen Platz auch in der Verteilung gefunden hat.

jetzt wo du es sagst... ich hatte nur noch die Diskussion von Yves bezüglich der 32 Bit Version im Hinterkopf, bei der er sich ja sehr um einen solchen Port bemüht hatte und eben aufgeben musste.

Ich nehme also alles zurück und behaupte das Gegenteil

Grüße
Earl