[Frage] Schnittstelle zur Entwicklung eigener Logik Bausteine

[stonie2oo4]

Ich würde mir wünschen dass der TW eine Schnittstelle bekommt mit der man umfangreiche LBS selber schreiben kann.
Ähnlich dem Gira X1 SDK, oder Edomi mit seinen Logik Bausteinen.

Den ganzen Erfolg den Edomi einfährt kommt meiner Meinung zum großen Teil durch die sehr vielen verfügbaren LBS, aber ja die Software an sich ist auch geil .

Ich denke mit einer solchen Schnittstelle würde der TW sehr viel schneller Fahrt aufnehmen und die Jungs von ElabNET würden dadurch sehr entlastet werden.
Zudem besteht auch die Wahrscheinlichkeit dass wesentlich mehr Fremdsysteme in kürzerer Zeit unterstützt werden können, da die gewieften Programmierer eben Dinge für ihre eigenen Geräte entwickeln, egal wie verbreitet sie sind. Diese müssen einfach nicht abwägen was nützlich für den Großteil der Kunden ist.

Ich selbst kann nicht Programmieren, aber ich konnte mir z.B. in Edomi für meinen Pioneer Fernseher und meinen Monoprice Multiroom Verstärker anhand vorhandener LBS einen eigenen zusammenbasteln. Ansonsten könnte ich die beiden Geräte bis heut nicht steuern.
Und genau dass gleiche Problem sehe ich beim TW, dass ich viele Geräte gar nicht nativ darüber ansteuern kann.

[gbglace]

Die Diskussion läuft doch schon in anderen FR.
Es macht keinen Sinn die TWS Basisplattform mit einer Hochsprache zu belasten.

Die wesentliche Grundlage die dem TWS fehlt solche Fremdsysteme anzubinden ist die fehlende Schnittstelle zu den IP-Protokollen MQTT TCP UDPusw.
An diesen Schnittstellen wird gerade gearbeitet.
Sind diese vorhanden, kann mit den bestehenden Editoren auch ein Pioneer AVR angesprochen werden.

Anderer Weg ist eine NodeRed Container auf den TWS zu installieren und sich an den dort vorhandenen Anbindungen zu bedienen. Wenn der TWS dann MQTT kann lassen sich alle Infos via NR auf MQTT Mappen und das im TWS auswerten und ggf auf den KNX-Bus bringen. Im NR Umfeld hat man ja wieder eine der Hochsprachen zur Verfügung. Es muss also keine eigene Programmierplatform im TWS etabliert werden.

Gerade die Nichtprogrammierer (bin auch so einer) machen da ggf mehr kaputt als heile.

[stonie2oo4]

Anderer Weg ist eine NodeRed Container auf den TWS zu installieren und sich an den dort vorhandenen Anbindungen zu bedienen. Wenn der TWS dann MQTT kann lassen sich alle Infos via NR auf MQTT Mappen und das im TWS auswerten und ggf auf den KNX-Bus bringen.

Und für was genau soll ich dann den TW benutzen?
Wenn ich doch alles z.B. in NodeRed oder in Edomi abbilden kann?
Und warum macht Stefan eine Umfrage für eine Integration von DoorBird, wenn diese doch heute auch schon über nodered angebunden werden kann?


Ich glaub man kann sehen worauf ich hinaus will. Alles was direkt im TW unterstützt wird ist einfacher zu handhaben und es wird halt einfach ein Schuh draus.
Seh’s auch mal Marketing Technisch. Lest sich besser wenn was direkt unterstützt wird, als ja man kann ja nen docker installieren und ein anderes System nehmen und damit dann zurück in den TW.

Gerade die Nichtprogrammierer (bin auch so einer) machen da ggf mehr kaputt als heile.

Musst ja nix programmieren. LBS runter laden, installieren, Eingänge belegen, Fertig.
Sollte wohl jeder einfacher hinbekommen, als dass gefrickel mit Docker?


Versteh mich nicht falsch, die Docker Integration ist super, nutze sie selbst für PiHole.
Aber alles mit Logiken sollte doch weitestgehend mit dem TW selber gehen.
Wäre zumindest wesentlich einfacher von der Bedienung.

[gbglace]

Ich habe glaube auch ein anderes Verständnis von Logiken. Logiken im TWS ist für mich eingehende Signale zu verarbeiten nicht Signale irgendwo aus der Welt reinholen.

Zum Teil Reinholen aus der Welt bekommt der TWS ja noch die generischen Schnittstellen MQTT TCP UDP und wenn das so umgesetzt ist wie ich mir das vorstelle dann kann jeder auf Basis dieser generischen Schnittstelle eine spezifische Konfigurieren und die Daten von irgendwo reinholen. Wenn ein solches Konfigurationstemplate dann vorliegt kann man das hier in der Community teilen. Im LE wie er jetzt ist kann dann auch ein Baustein mit Logiken gebaut werden sofern notwendig für solche Informationen aber meist genügt ja der DOS um z.B. für Laut/Leise am AVR so einen spezifischen TCP Adapter mit KNX oder MQTT-Visu Objekten zu verbinden.

Da wüsste ich nicht warum es da jetzt eine Hochsprache braucht um selbst eine TCP Schnittstelle zu kreieren.
Da Stefan auch eine berechtigte Angst hat die Schlanke Systemarchitektur könnte durch exessiven Gebrauch solcher Hochsprschembausteine unterlaufen werden, ist das auch erstmal ein valider Ansatz.
Der Umweg Docker ist aber wahrlich auch kein Garant für geringe Systemauslastung.

Für mich ist es daher wichtig, das der TWS nicht einfach nur so technisch befähigt wird die IP-Protokolle zu beherrschen, in dem man einen Code generiert und laufen lässt sondern das man eben mehrere unabhängige spezifische Adapter bauen kann. Und dieses bauen bestenfalls mit KlickKlick geht oder minimaler Parametererfassung. Enduserfreundlich ohne Programmierer sein zu müssen.

[fsl]

Ich kenne Edomi nicht gut, habe aber das Gefühl, dass der Vergleich zum TWS ziemlich hinkt. Edomi ist in erster Linie eine Visu, an die dann bestimmte, so genannte Logik-Bausteine drangeflanscht werden. Dabei handelt es sich wohl häufig um Kombinationen aus drei Aspekten: Erschließung der Eingangsquelle, Verarbeitung der Information und Aufbereitung für die Visu.

Beim TWS ist es nicht die Visu, die alles integriert, sondern wohl dieser DOS. Ich gehe einmal davon aus, dass Elabnet die ersten beiden Aspekte, also die Erschließung der Eingangsquelle und die Verarbeitung der Information super umsetzt, Hierbei kann es in der Tat notwendig werden, über den aktuellen Logik-Editor hinaus eine Art "Sprache" zu benutzen, um z.B. die Interpretation von beliebigen Inhalten zu ermöglichen (ich denke z.B. an das Parsen von Webseiten oder die Parameter einer API). Das muss aber keine Hochsprache, sondern könnte ggf. auch so etwas wie ein einfaches XML sein.

Der Visu-Aspekt ist davon vollkommen losgelöst, da das noch Gegenstand des Kernleistungsprogramms von Elabnet ist. Meines Erachtens wäre es durchaus wichtig, zumindest mittelfristig eine Visu besser zu integrieren und dann alles vom "Backend" auch verarbeiten zu können. Ich denke da insbesondere an den Fall einer Türkommunikation, der gerade anderswo diskutiert wird. Natürlich sind die Informationen "Klingeltaster gedrückt" usw. interessant für den Bus und ggf. Logiken. Was aber die meisten wohl interessieren wird, ist, wie sie das schöne Bild möglichst einfach in eine ansonsten komplette Visu bekommen.

[StefanW]

Hallo,

Ich würde mir wünschen dass der TW eine Schnittstelle bekommt mit der man umfangreiche LBS selber schreiben kann.

Wie andere schon geschrieben haben, das wurde schon mehrmals hier diskutiert.

Wir haben eine (neue) Regel für FRs (also vor allem komplexe).

1. ZUERST eine Diskussion über das Thema um mit mehreren zusammen einen Konsens herauszuarbeiten
2. Dann einen gut formulierten FR mit allen Details, über den man dann auch abstimmen kann und den man an die Entwickler geben kann.

==> Dein FR erfüllt das nicht und es gab auch keine Quotes dazu, ich mach mal eine Frage daraus.

Ähnlich dem Gira X1 SDK, oder Edomi mit seinen Logik Bausteinen.

Wirklich. Hast Du Dir das mal angesehen mit dem GIRA X1 SDK?

• Solche selbst definierten Logikbausteine muss man in C# erstellen, am Besten in einer Entwicklungsumgebung wie Visual Studio ab 2017
• Damit man diese Bausteine dann in den X1 bringt, müssen diese digital signiert sein, dafür benötigt man ein Entwicklerzertifikat von Gira. Bekommt man sicherlich, aber ist mal nicht eben am Wochenende was gemacht.
• Damit die Benutzeroberfläche (Experte) den Baustein auch kennt, muss man noch ein json schreiben.

Das ist alles ein guter und toller Weg. Aber nichts davon ist für einen Endanwender gedacht, sondern richtet sich an professionelle Entwickler. Wieviele Prozent der Endkunden können wohl C# und haben Lust auf Registrierung und Entwicklerzertifikat? 0,1% aller Kunden höchstens.


Wie geht das bei ElabNET:

• Ihr Wünscht euch einfach einen neuen Logikbaustein und wir stellen das so zur Verfügung. Les Dich mal durch das Forum, bisher hat jeder seinen Baustein bekommen
• Die Logikengins wurde (im Development) um mehrere weitere Basisbausteine und Fähigkeiten erweitert, die sich RobertMini gewünscht hat
• Ansonsten kann man sich umfangreichere Logiken auch mit einem simplen Texteditor zusammen schreiben. Das ist viel einfacher als C# und Zertifikate.

Den ganzen Erfolg den Edomi einfährt kommt meiner Meinung zum großen Teil durch die sehr vielen verfügbaren LBS, aber ja die Software an sich ist auch geil .

Edomi - wie auch OpenHAB oder io:Broker - brauchen gut zehnmal soviele Ressourcen als unsere Software. Wenigstens. Wir wollen uns die großartige Performance nicht ruinieren lassen, indem wir Scriptengines einbauen.

Wir haben derzeit Probleme mit Kunden, die Docker-Container aufsetzen und unbeaufsichtigt lassen. Letztens war bei einem Desktop Server die Platte voll. Kunde "ich hab nichts gemacht, das lief ein viertel Jahr einwandfrei, erst nach dem letzten Update kam der Server nicht mehr hoch". Ja so ist das immer, das "letzte Update für den TWS" war schuld, wenn es nur ungefähr zeitgleich damit zusammen trifft, dass der Kaffeeautomat spuckt. Am Ende stellt sich heraus, dass es eine OpenHAB Installation war, die auf "Dauer-Backup" geschaltet war und nach 1420 Backups war dann eben die Platte voll. Wer bezahlt uns diese vier Stunden verschleuderte Entwicklerarbeit. Da kommt mit schlechten Containern wieder der gleiche Mist auf uns zu wie bei den Root-Rechten für den Server.

Und da sollen wir nun eine Möglichkeit einbauen, dass die Kunden mit schlechten Programmen die stabile Logikengine des TWS ruinieren können? Damit ich dann wieder Schlagzeilen ertragen muss in Foren "WireGate tot, Kinder frieren über das Wochenende" (tatsächlich so passiert),

Wir befinden uns in einer Bewertungsgesellschaft in der auf den lautesten Schreier gehört wird und Dinge nach Gefühl wahrgenommen werden und nicht mit Sachkompetenz. Wenn wir zulassen, dass externe Programme unsere Logikengine ausbremsen, dann werden wieder solche Schlagzeilen aufkommen und schon ist der Ruf ruiniert.

==> Machen wir nicht. Nicht so.

Ich denke mit einer solchen Schnittstelle würde der TW sehr viel schneller Fahrt aufnehmen und die Jungs von ElabNET würden dadurch sehr entlastet werden.

Wie gerade geschildert ist das Gegenteil der Fall. Zumindest nach unserer Erfahrung.

Wir haben das mit den Plugins beim WireGate Server oft genug erlebt. Wir mussten ständig eingreifen und helfen, insbesondere wen der Server "stand" weil das Script die Ressourcen überlastet hat.

Zudem besteht auch die Wahrscheinlichkeit dass wesentlich mehr Fremdsysteme in kürzerer Zeit unterstützt werden können, da die gewieften Programmierer eben Dinge für ihre eigenen Geräte entwickeln, egal wie verbreitet sie sind. Diese müssen einfach nicht abwägen was nützlich für den Großteil der Kunden ist.

Wir haben dafür einen anderen Weg gefunden. Einfach etwas Geduld.

lg

Stefan

[gbglace]

Ich kenne Edomi nicht gut, habe aber das Gefühl, dass der Vergleich zum TWS ziemlich hinkt. Edomi ist in erster Linie eine Visu, an die dann bestimmte, so genannte Logik-Bausteine drangeflanscht werden. Dabei handelt es sich wohl häufig um Kombinationen aus drei Aspekten: Erschließung der Eingangsquelle, Verarbeitung der Information und Aufbereitung für die Visu.

Nee eben nicht. Es gibt viele die EDOMI auf Grund der Komplexität der Visu nicht als Visu nutzen, sondern nur als Logik.

EDOMI hat eben genau beide Komponenten.

Die Visu auf der man sich Grafiken Symbole usw. mit Animation in CSS bauen kann. Das beliebig detailverliebt wie man es mag und kann. Die Effekte und Werte werden dabei immer mit Objekten verknüpft entweder direkt KNX-Objekte oder interne Objekte.

Die Logik ist eine eigene Instanz von EDOMI, da kann man mit den Stanardbausteinen wie sie auch die TWS Engine hat sich komplexe Strukturen bauen. Input/Output sind auch immer Objekte entweder direkt KNX oder interne. Die Darstellung ist eben anders.

Bei den LBS baut man quasi kleine mini SW-Pakete in vollen PHP die so ziemlich die komplette Systemarchitektur ansprechen können. Außenrum bekommt man dann so eine Box an die man wieder Objekte verknüpft. Entweder KNX oder interne. Also vom Prinzip ähnlich dem TWS.

Wie man es oben lesen kann hat Elabnet ein berechtigtes Interesse die Nutzung der Kernressourcen nicht durch schlecht programmierte LBSe überlaufen zu lassen. Dabei muss nicht mal ein einzelner LBS schuld dran sein, sondern ggf nur die Kombination verschiedener.

Bei EDOMI finden sich auch immer mal Berichte über lahmgelegte Systeme durch den Einsatz verschiedener Kombinationen oder eigener Anpassungen an den LBS. Dazu kommt das man eben für EDOMI-Standard auch mit kleinen PC-Systemen hinkommt es aber auch genügend gibt die da recht potente Maschinen hinstellen Und auch solche hat man da schon mal in die Knie gezwungen.

[StefanW]

Richtig Göran.

Man darf auch nicht vergessen, dass die Forenwelt eine Scheinwelt ist.

So wie es Usus ist, die kommerziellen Produkte von Herstellern eher kritisch in Foren zu bewerten (der Kunde ist König und "die müssen das aushalten") ist es auch eine allgemeine Tendenz, dass Community-Produkte umgekehrt gehypt und gelobt ("unglaublich, was der geschafft hat und uns nun schenkt") werden.

Was gab das für ein aufgeregtes Geschrei, als die ersten saugünstigen RasPi auf dem Markt erschienen und Software wie OpenHAB oder SmartVisu dazu. "Jetzt können wir alles selbst. Brauchen die Hersteller mit ihren teuren Produkten nicht mehr". Da wurden enorme Projekte gestartet.
Von den teils ernüchternden Ergebnissen hat man dann eher nichts mehr gehört. Ich erinnere mich an manche mit wehenden Fahnen gestarteten Projekte und Ankündigungen und wenn man dann mal nach einem Jahr nachgefragt hat, dann kam - wenn überhaupt - ein leises "hab mir doch einen Home Server gekauft". Von dem großen Projekt keine Spur mehr und die Dutzenden die sich daran gehängt hatten schauten mit dem Ofenrohr ins Gebirge.

Ich kenne kaum einen RasPI Bastler der nicht zugibt, nicht schon wenigstens fünf bis zehn Stück wegen Defekten in die Tonne getreten zu haben. Nebst unzählichen totgeschriebenen SD-Karten. Ressourcenshonung? Von manchen Kunden höre ich durchaus eine Menge an Problemen im Detail mit dem ein oder anderen geschenkten Produkt - weshalb sie dann zu uns kommen. Manche nach zweijähriger Odyssee. Stehen tut sowas in den Foren natürlich nicht.

Wegen der allgemein gefärbten Berichterstattung über kommerzielle vs. freien Produkte gibt es leider kaum eine sachliche und schon gar keine ehrliche und korrekte Auseinandersetzung mit tatsächlichen Leistungsmerkmalen oder Langzeit-Ergebissen usw. über die verschiedenen Produkte.

Nur jemand der die Szene schon seit zig Jahren verfolgt, bekommt so allmählich ein komplettes Bild von der Sache. Wir haben Edomi (und andere) auch installiert für uns um das zu testen. Aufgefallen sind hoher Ressourcenverbrauch (allesamt), teils sehr umständliche Konfiguration (besonders die ersten Schritte zur ersten Edomi-Visu war eine Enttäuschung - gegenüber was man in Foren vorher so gelesen hat), die Stabilität ist teils schlecht, Update teils kompliziert und nicht selten mit Datenverlust verbunden, weil sich die Konfig eben geändert hat und ein Open-Source-Programmierer sich eben nicht die Mühe macht, noch ein Modul zur Datenübernahmen beim Update zu schreiben, da fängt man halt von vorne an mit dem Konfigurieren.

Und eine Erkenntnis ist auch, dass man das System leicht lahmlegen kann mit dem ein oder anderen Script. Oder weil ein wildes Backup die Platte vollschreibt. Lesen tut man das nur ganz selten, weil die Maker eben lieber posen als über die Misserfolge zu berichten.


Unsere Kunden sind überwiegend an einem komplett stabilem System interessiert und wollen das nicht durch mögliche Spielereien auf Spiel setzen können. Und darum sind wir in dieser Frage auch zurückhaltend und überlegen lieber alternative Wege.

Folgende Bitte: Wenn immer es heißt "wie XYZ" weil das ist soooo toll und einfach.... bitte vorher die ganze Wahrheit ansehen.

lg

Stefan


PS: Nur damit kein Missverständnis aufkommt. Ich finde diese Produkte wie EDOMI, OpenHAB, io:broker und viele weitere absolut klasse und ziehe meinen Hut vor der vielen vielen jahrelangen Arbeit nebst Support, welche die Ersteller hier aufgewendet haben. Das ist wirklich super und sicherlich eine gute Alternative. Ich wünsche mir nur mehr Objektivität und Ehrlichkeit in den Bewertungen (auch für unseren Server) für eine sachliche Diskussion. Wir haben nun 30 Mannjahre in unser System gesteckt, das dürfte deutlich mehr sein, als in manch andere Systeme die auf den ersten Blick womöglich auch alles oder mehr können. Und doch gibt es ein paar grundlegende Unterschiede bei Ressourcenverbrauch, Stabilität, Einzelfallsupport und Updatekomfort der bitte auch geeignet honoriert werden sollte.

[gbglace]

Wegen der allgemein gefärbten Berichterstattung über kommerzielle vs. freien Produkte gibt es leider kaum eine sachliche und schon gar keine ehrliche und korrekte Auseinandersetzung mit tatsächlichen Leistungsmerkmalen oder Langzeit-Ergebnissen usw. über die verschiedenen Produkte.

Die Färbung entsteht eben auch gerade dadurch das sich in den Foren auch primär die erfahrenen Bastler tummeln und Ihre Projekte vorstellen. die Neulinge sind ggf gar talentiert und konsumieren das noch ganz gut. aber der Otto-Normalverbraucher sucht gar nicht nach diesen Foren und ist dann auch nicht in der Lage solche Projekte aufzusetzen oder gar zu warten.

Hersteller mit neuen Produkten werden dann in den Mix-Foren nur daran gemessen ob denn nun wirklich alles was alle Systeme inkl. der opensource Projekte in der Nische ggf super machen auch haben. Kann das Neue nicht alles min genau so gut wie die optimierte Selektion aus der Masse der Alternativen ist es eben schlecht und überflüssig, wobei aber nicht eines der anderen auch nur annähernd alles super kann.

[Sun1453]

Unsere Kunden sind überwiegend an einem komplett stabilem System interessiert und wollen das nicht durch mögliche Spielereien auf Spiel setzen können. Und darum sind wir in dieser Frage auch zurückhaltend und überlegen lieber alternative Wege.

Folgende Bitte: Wenn immer es heißt "wie XYZ" weil das ist soooo toll und einfach.... bitte vorher die ganze Wahrheit ansehen.

lg

Stefan


PS: Nur damit kein Missverständnis aufkommt. Ich finde diese Produkte wie EDOMI, OpenHAB, io:broker und viele weitere absolut klasse und ziehe meinen Hut vor der vielen vielen jahrelangen Arbeit nebst Support, welche die Ersteller hier aufgewendet haben. Das ist wirklich super und sicherlich eine gute Alternative. Ich wünsche mir nur mehr Objektivität und Ehrlichkeit in den Bewertungen (auch für unseren Server) für eine sachliche Diskussion. Wir haben nun 30 Mannjahre in unser System gesteckt, das dürfte deutlich mehr sein, als in manch andere Systeme die auf den ersten Blick womöglich auch alles oder mehr können. Und doch gibt es ein paar grundlegende Unterschiede bei Ressourcenverbrauch, Stabilität, Einzelfallsupport und Updatekomfort der bitte auch geeignet honoriert werden sollte.

Kann deine Aussagen nur bestätigen. Bei euch gibt es alles aus einem Guss und mit einer spitzen Stabilität, Einzelfallsupport und Updatekomfort.