ElabNET Technik Forum

Hallo Zusammen
Ich hab schon lange den Wunsch, wie sicherlich einige andere auch, die Anbindung aller Geräten im Haus zentral und direkt über den TWS laufen zu lassen. Die Pflege der 3. Systeme wie ioBroker oder Homeassist sind zeitaufwendig und wenn einem selbst mal was passiert, so gut wie nicht von dritten zu handhaben.
Den Aufbau wie zB ioBroker funktioniert, über die Adapter die Verbindung zu den unterschiedlichen Geräten herzustellen, finde ich vom Ansatz nicht schlecht, deshalb stellt sich mir schon lange die Frage, ob es nicht eine für programmierbegabte, relativ einfach Möglichkeit gibt, Teile des Programmcodes der einzelnen Adapter für zB die HTTP-API im Timberwolf vom Endanwender einzubinden?

Ich habe bei vielen Themen, die zur HTTP-API aufkommen, den Eindruck, dass wir hier versuchen das Rad neu zu erfinden bei zB Authentifizierung für Kameras, wobei dies in den Adaptern vom zB ioBroker schon sehr gut funktioniert.

Ich kenne mich leider mit der Programmierung der Adapter und der HTTP-API im TWS noch zu wenig aus, um mir da ein genaueres Bild zu machen.

Lasst doch mal hören ob ich da zu einfach denke oder man evtl doch bestehenden Code als Grundlage für zB HTTP-API Abfragen im TWS nutzen könnte.

Grüsse

Hi Micha,

es gibt auch bei uns Überlegungen, wie wir - über die generische Einrichtbarkeit einer Geräteverbindung über HTTP / MQTT hinaus - eine einfachere Anbindung fremder Geräte realisieren und die bisher von uns angedachten Lösungen drehen sich um ladbare Geräteprofile ähnlich wie bei Modbus.

Wobei wir hier - und das gilt dann auch für Modbus - diese Geräteprofile bereits über die Cloud nachladbar anbieten wollen würden (so wie die ETS die Applikation von der KNXA lädt). Man würde dann nur noch eingeben "4 x Shelly XYZ" und nach Rückfrage der Adresse würde dann der Gerätemanager diese Geräte mit allen verfügbaren Objekten fertig einrichten.

Der Punkt ist wieder das liebe Geld. Weil aus den Rückmeldungen zu io:Broker usw. habe ich den Eindruck, dass die Qualität und die Pflege der jeweiligen Module ein Risiko für den Nutzer darstellt. Hier arbeiten zwar tausende von Entwickler zusammen und haben eine große Bandbreite an unterstützten Geräten entwickelt, aber die Qualität scheint von Entwickler zu Entwickler stark zu schwanken und ob es dann auch ein Update gibt, wenn Shelly die Firmware anpasst, ist ein wenig Glückssache.

Man muss sich also bei solchen Vorschlägen auch immer fragen, in welcher Qualität soll das sein? Und wenn es gute Qualität sein soll, dann ist auch ein Aufwand dahinter und dann stellt sich die Frage, wer das trägt? Könnten wir dann einen Fünfer verlangen für ein funktionierendes Geräteprofil?

Daher immer meine Bitte für solche Ideen: Sehr gerne, aber bitte immer angeben welche Qualität und mit welchem Komfort das nutzbar sein soll, wer sich um die Implementierung, die Updates und den Support kümmert und - sofern ElabNET hier Arbeitsanteile übernehmen soll - wie das dann bezahlt werden soll.

lg

Stefan

Hallo Stefan
danke dir erstmal für deine, wie immer sehr schnelle ausführliche Antwort. Ich finde es super, dass ihr sowas in der Art auf dem Schirm habt und ich meine, dass mit den Profilen, nicht nur für Modbus, wurde auch schon mal angeschnitten an verschiedenen Stellen. Die Herangehensweise wäre natürlich super.

StefanW hat geschrieben: ↑Fr Jun 16, 2023 1:53 pm Der Punkt ist wieder das liebe Geld. Weil aus den Rückmeldungen zu io:Broker usw. habe ich den Eindruck, dass die Qualität und die Pflege der jeweiligen Module ein Risiko für den Nutzer darstellt. Hier arbeiten zwar tausende von Entwickler zusammen und haben eine große Bandbreite an unterstützten Geräten entwickelt, aber die Qualität scheint von Entwickler zu Entwickler stark zu schwanken und ob es dann auch ein Update gibt, wenn Shelly die Firmware anpasst, ist ein wenig Glückssache.

zu 1. ich wäre auch hier wieder bereitdie Profile für meine Geräte einzukaufen für zB 5€/Gerätetyp (bei 5 shellys 3EM enstehen dann nur einmal Kosten oder als Shellypaket, ohne wiederkehrende Kosten), wenn diese in der von euch gewohnten Qualität angeboten werden, die Pflege dieser Profile sollte sich meiner Meinung nach in Grenzen halten, da die Hersteller ja meistens nicht die komplette Ansteuerung über den Haufen werfen.

zu 2.es wären aus meiner Sicht beide Wege möglich, qualitativ hochwertige Profile von euch erstellt, getestet und gepflegt für alle die dafür bezahlen wollen (allen den die Qualität und Funktionsfähigkeit wichtig ist zB Industrie)
auf der anderen Seite Community lösungen, da ihr ja nicht alle 100000 Profil selbst erstellen könnt/wollt, in die Richtung zielte mein primärer Post eigentlich erstmal ab.

Ganze Profile zu integrieren war nicht unbedingt meine Intension im 1. Post, sondern eher, das man sich bestimmte Teile in den ioBroker Adaptern abzuschaut um dann über die bereits vorhandene HTTP-API diese Geräte leichter zu integrieren.

Ich hoffe ich konnte es einiger massen verständlich rüber bringen

Mibr85 hat geschrieben: ↑Fr Jun 16, 2023 2:48 pm die Pflege dieser Profile sollte sich meiner Meinung nach in Grenzen halten, da die Hersteller ja meistens nicht die komplette Ansteuerung über den Haufen werfen.

Und diese Annahme ist leider absolut nicht passend.

Ja ein bestehendes Gerät wird eine weile einfach funktionieren, aber es werden dann einfach alle neuen Geräte fehlen. Wenn ich mir im NR anschaue wie oft da ein neuer Alexa-Adapter gebaut wird oder auch der Telegrammadapter, das ist schon nicht ohne. Manchmal weil das Ziel sich in der API ändert, mal weil die Basis im NR sich ändert (was dann hier ein TWS OS Release wäre)

Schaue Dir an wie stabil eine Hager Domovea oder auch das BAb-tec Appmodul laufen oder die ISE-IoT-GW's. Die haben alle zu ihrem Rollout gute Laune und dann nach einigen Monaten schwindet die mit jedem Update der Zielwelten.

Das ist alles genau das warum Matter so gehypt wird, weil man sich da dann einfach mehr Stabilität wünscht im IoT Umfeld.

In der IST-Situation.
Wäre die durchgängige Herstellung der Profil load/export Funktion in den Gerätemanagern die beste Alternative für den TWS. Und dann wird halt auch die Community entsprechende Profile/Geräte bauen. Ob dann da Anleihen am HA / IOB / NR genommen werden ist dann jedem Communityentwickler überlassen.


Profile/Adapter fertig von Elabnet, da überschlage ich 1 -2 Vollzeitkräfte zur Implementierung und später zunehmend zur Aktualisierung. Und eine weitere Vollzeitkraft um das dann (auch mit den anderen Features des TWS) in einer Support-Kommunikation zu begleiten.

Und offensichtlich ist das auch bei anderen größeren Firmen so noch nicht realisiert.

Hallo Göran,

gbglace hat geschrieben: ↑Fr Jun 16, 2023 3:23 pmUnd diese Annahme ist leider absolut nicht passend.

Danke sehr. Den Aufwand den wir insgesamt treiben müssen, damit Dinge möglichst auf Knopfdruck einfach funktionieren ist viel größer als man denkt.

Weil digitale Kompatibilität ist ein "Mistviech", wie wir in Bayern sagen. Ein Bit falsch, oder 1 ms zu früh, oder zu spät und schon knirscht es im Getriebe.

Im Billig-Nachrüst-Markt haben die Hersteller kein großes Interesse an irgendeiner dauerhaften Kompatibilität. Wenn die neuen Zigbee HUBs mit den alten Zigbee Sensoren nicht mehr funktionieren, dann ist das eben so. Bei den neueren Thread Hubs ist dann das ohnehin so. Ich hatte mit für Zigbee-Versuche einen Aquara M2 Hub gekauft um die Jahreswende, jetzt ist schon der neue angekündigt. Oder die Unzuverlässigkeit hinsichtlich der Dauerhaftigkeit von Cloud-APIs. Bei letzerem wird auch munter abgeschaltet, wenn ein Teil nicht so performt am Markt. Oder die neue Generation am Start ist. Am Anfang konnte man für die Google Nest der ersten Generation noch eine Cloud API benutzen, gibt es mittlerweile nicht mehr. Weitere Beispiele gibt es endlos.

Da sieht man mal, welchen tollen Job die KNXA macht, dass alles wunderbar Kompatibel ist zueinander. Mal abgesehen von den drei Generationen Funk-KNX-Teilen. Wobei ich letztens auf einer KNXA Veranstaltung war und die bauen jetzt einen Super-Funk-KNX-Adapter mit vielen neuen ETS Funktionen, damit wieder alles zusammen kommt. Das hat gedauert, aber ist absolut vorbildlich gemacht. Das bezahlt man halt dann auch mit den Kosten für ETS & die KNX Geräte.

Auch bei den Shellys. Wir hatten da eigentlich vor, dass es für diese fertige Geräte-Profile nebst Logik-Bausteinen (wegen der Textmeldungen) von uns gibt. Aber es gibt jetzt die neue Plus Serie von Shelly und man hat den Aufbau der API komplett geändert. Klar kann man das auch noch machen, aber jetzt müssen wir erst dem Gerätemanager neue Tricks beibringen, bevor man dann auch hierfür Profile machen kann. Das hält halt auf und es läuft am Ende auf die Fragestellung heraus, "wer bezahlt das jetzt". Weil wir bekommen für solche Funktionen nicht einen müden Euro mehr beim Verkauf des Timberwolf Servers. Vielleicht verkaufen wir zwei Server mehr, aber die Menge wird das nicht sein, weil wegen Shelly kauft niemand den Server, sondern KNX, VISU, Logik usw. und wenn wir dann sagen, wir können auch Shellys usw. dann ist das sicher schön, aber hundert Euro mehr dafür bekommen wir nicht. Und den Support für zehn Jahre dafür halt auch nicht.

gbglace hat geschrieben: ↑Fr Jun 16, 2023 3:23 pmSchaue Dir an wie stabil eine Hager Domovea oder auch das BAb-tec Appmodul laufen oder die ISE-IoT-GW's. Die haben alle zu ihrem Rollout gute Laune und dann nach einigen Monaten schwindet die mit jedem Update der Zielwelten.

Richtig, Weil das das ist, woran auch andere Hersteller scheitern und letztlich sowas nicht in dauerhaft laufend anbieten können (zumindest nicht in Verbindung mit einem leicht erreichbaren Support). Es wird nicht bezahlt.

Ich hatte oben mal die 5.- EUR in den Raum geschmissen pro Gerät. Da meinte ich dann schon pro einzelnes Gerät. Micha hat dann schon - typisch Endkunde - daraus pro Gerätetyp gemacht. Also für 10 Shelly xyz dann nur einmal. Aber das es bei zehn Geräten vom gleichen häufiger einen Supportfall geben kann (weil neun funktionieren und der zehnte nicht) wird nicht gesehen. Wirklich, das rechnet sich nicht.

gbglace hat geschrieben: ↑Fr Jun 16, 2023 3:23 pmDas ist alles genau das warum Matter so gehypt wird, weil man sich da dann einfach mehr Stabilität wünscht im IoT Umfeld.

Wobei heftigst gepatched und gebastelt wird im Moment und es dort richtig knirscht.

Wir haben schon überlegt, ob wir künftig Matter anbieten. Mag eines Tages besser funktionieren, aber wie soll man das am Ende supporten? Der eine hat Apple TV als Matter Controller, der andere Apple Homepod, der nächste Samsung irgendwas usw. Ein anderer alles drei auf einmal und es ist gar nicht so klar, wer der Matter Controller dann für was ist. Dann noch mehrere Thread Border Gateways (da gibt es dann einen Apple TV der hat Thread mit drin und die anderen Apple TV Modelle haben es nicht). Da kann man bei der Fehlersuche schnell ein paar Mannstunden (= ein paar hundert Euro) verpritscheln. Das wird niemand bezahlen wollen. Aber wenn dann jemand unzufrieden ist, weil seine wilde Matter Installation nicht einwandfrei funktioniert, dann schreibt er schnell im nächsten Forum "ElabNET verweigert Support". Hatten wir alles schon. Weil den Hersteller "über die Klinge springen lassen" wenn irgendwas nicht tut, man selbst keinen Durchblick hat und nun aus Frust einen Schuldigen sucht, geht manchen ganz schnell von der Hand. Den großen (wie Apple") ist das egal. Die reiten zweimal im Jahr eine für Millionen vorproduzierte Show im Internet, aber sind später für Detailprobleme im Haus von Joe Sixpack auch nicht zu erreichen.

gbglace hat geschrieben: ↑Fr Jun 16, 2023 3:23 pmProfile/Adapter fertig von Elabnet, da überschlage ich 1 -2 Vollzeitkräfte zur Implementierung und später zunehmend zur Aktualisierung. Und eine weitere Vollzeitkraft um das dann (auch mit den anderen Features des TWS) in einer Support-Kommunikation zu begleiten.

So in etwa. Da sind wir dann bei 150 bis 200k im Jahr an Kosten. Ich sehe nicht, wie das finanziert werden soll (man bedenke bitte, wir verdienen an diesen IOT Geräten ja nichts).

Technisch ist es auch so, dass io:Broker Adapter in NodeJS geschrieben sind, also einer langsamen und RAM-Intensiven Script Sprache. WIr erstellen unsere Kommunikationsmodule dagegen in puren C. Der Unterschied ist so der Faktor 25.fach bis 100-fach in Performance. Solche Adapter würden den TWS ausbremsen und man bekäme die gleichen Probleme, die schon io:Broker Nutzer heute haben.

lg

Stefan

Die Diskussion geht in die völlig falsche Richtung und ähnliche Diskussionen gab es schon häufiger.
1. finanzielle Dinge wollten wir doch aus dem Forum raushalten
2. ist mir zu 100% klar, dass ihr nicht die ganzen Adapter Supporten und erstellen könnt. Deshalb ist nur die Grundlage schaffen der interessante Weg. Die Community kümmert sich dann schon darum das häufig gebrauchte Geräte unterstützt werden. Über die Qualität lässt sich dann diskutieren.

Die Grundidee war eher bereits vorhanden zB IOB Adapter mit geringem Aufwand für den TWS nutzbar zu machen, so das die bereits geleistete Arbeit nicht nochmal für das nächste System (in dem Falle der TWS) gemacht werden muss. Die Authentifizierung bei einem Gerät über HTTP funktioniert doch genau gleich egal ob sich der IOB bei dem Gerät authentifiziert oder der TWS.

Sorry Micha,

"nur die Grundlage schaffen" dass IO:Broker Software und HomeAssistent Software einfach mal eben so im Timberwolf Server laufen und die Daten an das Objektsystem übergeben, aber wir haben keinen Aufwand mehr damit? Und alle können das dann künftig genau auseinanderhalten und werden nie ein Ticket bei uns eröffnen, wenn dann ein io:Broker Adapter nicht tut was er soll?

Der Timberwolf Server ist eben genau deshalb so stabil, WEIL wir genau aufpassen, was alles läuft. Ich habe da große Bedenken für die Stabilität, das fremde Software von Nutzern selbst eingebunden werden kann.

Ich verstehe den Wunsch und natürlich ist das in der Phantasie eine tolle Lösung. Aber der Timberwolf Server hat ein paar Eigenschaften, die ihn besonders machen. Stabilität. Stabilität. Stabilität. Dazu noch Effizienz, Speed-Support, Diagnose-Tools und, sofern ich das nicht vergessen habe, STABILITÄT. Das ist, was unsere Kunden wollen und wofür sie bezahlen und ICH werde das nicht aufgeben für ein paar wackelige Features mehr.

Der Timberwolf Server ist ein Fels in der Brandung, das haben wir uns hart erarbeitet.

Stefan

Deshalb ja auch die Überschrift des Themas, es war nur ein Gedankenspiel.

Ich würde nur gern verstehen, was immer wieder zu solchen Post wie mit zB mit der Hikvision-Einbindung oder der Viessmann-Einbindung führt und was da die großen Probleme sind.
Wahrscheinlich liegt es daran das die Hersteller alle ihre eigene Suppe kochen und 1000 Varianten auf dem Markt sind wie man jetzt mit einer HTTP API kommuniziert.

Wahrscheinlich liegt es auch an der Ungewissheit, dass ich mich noch nicht mit den HTTP Abfragen im TWS beschäftigt habe.

Nein die Adapter von IOB oder HA in den TWS übernehmen, das würde nur funktionieren wenn Du dann im TWS entweder einen Container IOB/HA laufen hast, den aber noch viel enger angebunden als das was sich jetzt jeder selber bauen kann, weil er musste ganz in Hintergrund bleiben und unter der TWS Oberfläche zu bedienen sein.
Oder man baut sich die Engine von denen ins eigene System.

Das ergibt ja architektonisch gar keinen Sinn. Weil man dann nicht nur die einzelnen Adapter adaptiert sondern auch noch immer die Quellengine vom IOB und HA. Und HA will ja auch in Teilen nur sehr gut funktionieren wenn es als ganzes OS und nicht nur als Container daher kommt.

Ja die Schuld liegt nicht bei Elabnet, dass das alles so schwer ist solche Fremdsysteme anzubinden. Ich will nicht wissen mit wieviel Eifer und wieviel Zeit die Communityentwickler unterwegs sind auf den anderen Plattformen Adapter zu bauen.

Diese ganzen IP basierten Anbindungen sind zwar dank HTTP-API oder MQTT sehr schnell aber man kann sowas auch sehr sehr komisch implementieren. Da kommt es bestimmt auch immer drauf an aus welcher Systemhistorie das jeweilige Entwicklerteam kommt. Jemand der Jahrzehnte nur mit Datenbanken und SQL gemacht hat und nun ne API bastelt, wird das komplett anders aufsetzen als jemand der da irgendwie bei der Entwicklung von Android Handyapps sein Handwerk gelernt hat.

Insofern ja ein Profilaustausch auf all den Subsystemebenen wäre schon ein gewaltiger Schritt in Richtung Community Beteiligung. Aber eine native Integration der anderen Adapter nicht sinnvoll.

Die CV oder NR als Container sind Beispiele wie es noch anders gehen kann. Man baut sich mit MQTT als User selbst einen Mediator. Aber ja es ist dann die Nummer noch eine Abstraktionsebene mehr.

Ein ganz anderer Weg, aber aktuell nicht im Sinne des Erfinders wäre es wenn der TWS einen Adapter ins HA baut. Aber dann wäre HA das Kernsystem und steuert den TWS. Das ist dann in Teilen das was ProKNX Server mit NR macht. Da gibt es einige Nodes für NodeRed und im NodeRed wird die IOT Welt und die Logik gebaut. Und mit den ProKNX nodes bindet man es an den Server, die Visu und dem KNX selbst an.

Aber da sehe ich derzeit den TWS als zu gut und umfangreich als das es sorum Sinn ergibt.

Womöglich wenn das alles in der IOT Welt noch viel viel bunter und verrückter wird, der TWS aber sonst einfach DAS stabile und verlässliche Kernsystem ist und auf irgendeiner anderen Plattform aber eine solch riesige Community und Adapter in die IOT Welt existiert und diese Plattform als relativ schlanker Container daher kommt, dann könnte sowas schon Sinn ergeben, quasi einen TWS Adapter für diese Plattform zu bauen.

Bis dahin gehe ich den Weg TWS MQTT NR und von Dort in die bunter IOT Welt, da ich die Details der ganzen API Vielfalt auch nicht durchsteige um das selbst anzulegen.
Mehr davon nativ in den TWS dann, wenn dann mal Profile ausgetauscht werden können.

Ich würde nur gern verstehen, was immer wieder zu solchen Post wie mit zB mit der Hikvision-Einbindung oder der Viessmann-Einbindung führt und was da die großen Probleme sind.

Anstatt zu versuchen irgendwelche Adapter aus anderen Systemen nutzbar zu machen, sollte man eher die Energie nutzen und die Protokolle breiter/ universeller unterstützen. Es geht ja immer wieder dabei um Authentifizierung, Unterstützung von irgendwelchen Content-Typen usw.
Meine Vorstellung ist ja, dass ich mit dem TWS ein „Master of the Universe Tool“ besitze, um, als Nicht-ITler, selber Systeme anbinden zu können und eben nicht mehr in die Abhängigkeit von vielleicht schlecht gepflegten Community Adaptern gehen zu müssen.

Mehr davon nativ in den TWS dann, wenn dann mal Profile ausgetauscht werden können.

Das wäre dann die elegante Weiterführung. Wir bekommen durch den TWS die Möglichkeit die Systeme anzubinden und können die Profile teilen. Sollte ein Hersteller etwas ändern, dann kann der Einzelne reagieren und die Anpassung vornehmen. Ändert sich was am Protokoll, dann müsste Elabnet das Werkzeug anpassen.