Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Informationen zu Timberwolf Logik-Engine und Visa?
[wiregate]
Informationen zu Timberwolf Logik-Engine und Visa?
Ich bin bestimmt nur zu blöd zum Suchen - aber gibt es neben den (ausführlichen!) Informationen zur Hardware auch Informationen zur Art und Weise der Programmierung der Logiken/Logik-Engine sowie zur Visualisierung (oder läuft da auch CometVisu?).
Wenn's irgendwo schon steht gerne auch einfach nur den Link posten!
... gibt es neben den (ausführlichen!) Informationen zur Hardware auch Informationen zur Art und Weise der Programmierung der Logiken/Logik-Engine
Nein, das haben wir noch nicht veröffentlicht. Wir haben einen (wir meinen innovativen) Ansatz entwickelt und den wollen erst zur Messe zeigen.
Einige wesentliche Merkmale:
Isolierte Logiken: Einzelne Logiken können zur Laufzeit hinzugefügt, dupliziert und gestoppt werden ohne dass die anderen Logiken davon tangiert sind. Es ist also nicht nötig, die gesamte Logik neu zu starten, weil man etwas verändert, gelöscht oder hinzugefügt hat. Egal ob es einzelne Objekte oder eine Monsterlogik ist.
Live Anzeige: Eingangs-, Zwischen- und Ausgangswerte können live im Logikeditor betrachtet werden. Ohne Reload-Button, sondern wie in einer Visu mit laufenden Änderungen. D.h. man kann einer Logik direkt zusehen wie Werte eingehen / ausgehen / berechnet werden usw..
Live Test: Vorgesehen ist auch, dass man Eingangsobjekte übersteuern kann, bedeutet, anstatt darauf zu warten, dass ein Objekt einen bestimmten Wert sendet, kann man diesen einfach vorgeben, als wenn er gerade gesendet worden wäre. Z.b. kann man im Sommer bei einer "Winter"-Logik die Außentemperatur (testweise) vorgeben. Auf diese Weise lassen sich Logiken leicht simulieren.Man muss dazu nicht krampfhaft etwas über den Bus schicken.
Einbindung eigener Scripte: Es wird auch in einem späteren Versionsstand möglich sein, anstatt vorgegebener Logiken eigene Skripte, womöglich ganze Docker-Container, einfach einzuhängen, so dass der eigenen Programmierung in jeder beliebigen Sprache alle Türen offen stehen.
sowie zur Visualisierung (oder läuft da auch CometVisu?).
Zunächst werden wir die CometVisu in nativer Version in einem Docker-Container zur Verfügung stellen. Das wird dann entsprechend vorinstalliert bzw. auf Knopfdruck verfügbar sein. Also so einfach wie bisher auch auf dem WireGate Server
Für die folgende Version würden wir die CometVisu gerne nativ integrieren, d.h. mit einem modernern Übertragungsprotokoll und Objektbasiert (also nicht auf GA basiert, sondern auf Objekten, dann kann man auch Werte übertragen, die nicht zuerst auf den KNX Bus geschrieben werden müssen).
Im weiteren Verlauf überlegen wir dann, der CometVisu weitere Designs und Eigenschaften hinzuzufügen, das ist aber noch nicht versprochen (es hängt auch von der Finanzierbarkeit ab, ob wir einen eigenen Entwickler darauf ansetzen können, mein Wunsch wäre es, damit hier mehr voran geht)
Wenn ich Stefan's Beitrag richtig deute, dürfte es einen Logik-Editor wie in Edomi/GPA/HS geben und zusätzlich die Möglichkeit, eigene "Skripte" einzubinden/laufen lassen. Da würd' ich dann im Zusammenhang mit der Aussage, die CometVisu über ein objektorientiertes Protokoll anbinden zu wollen mal raten, dass Perl eher nicht das Mittel der Wahl sein wird...
Im weiteren Verlauf überlegen wir dann, der CometVisu weitere Designs und Eigenschaften hinzuzufügen, das ist aber noch nicht versprochen (es hängt auch von der Finanzierbarkeit ab, ob wir einen eigenen Entwickler darauf ansetzen können, mein Wunsch wäre es, damit hier mehr voran geht)
Dem Wunsch kann ich mich zu 100% anschließen, ich hoffe das ihr das in Zukunft irgendwie ermöglichen könnt. Ein Entwickler, der zumindest einen Teil seiner Arbeitszeit in die CometVisu investieren könnte, würde dem Projekt mehr als gut tun.
Na ja, so wie ich Stefan verstanden habe kann man keine eigenen Sripte einbinden.
Eigene Scripte schreiben sie selbst gegen Geld.
Es soll auch keine Grafische Bausteine geben.
Was mich aber noch so intressiert ist die Datenbank, ich hatte Stefan Influx-DB vorgeschlagen, Sie wollten aber was ganz besonderes (Eigenes) entwickeln.
Wie sieht es damit aus ?
Gruß NetFritz
KNX & Wago 750-849 ,Wiregate u. Cometvisu, iPad 3G 64GB.
WP Alpha-Innotec WWC130HX (RS232-Moxa-LAN),Solaranlage für Brauchwasser und Heizung.
PV-Anlage = SMA Webbox2.0 , SunnyBoy 4000TL, Sharp 4kWP
Meine Erwartung an so ein System - und derzeit das KO-Kriterium gegen fast alle existierenden Lösungen! - ist die Implementierung einer offenen DB-Schnittstelle. Ich will nicht durch die Logik-Engine/Visu darauf festgelegt sein, ob ich SQL, noSQL oder sonstwas nutze! Insb. möchte ich Cloud-Platformen zur Analyse nativ nutzen können.
StefanW Kannst du was dazu sagen, wie/womit wir Logiken erstellen können und wie/welche DB angebunden werden?
An dieser Stelle ist die Entwicklung noch nicht abgeschlossen. Allerdings gibt es den Entwicklungsauftrag, dass Kunden selbst geschriebene Module einbinden und untereinander austauschen können sollen. Soweit möglich in verschiedenen Sprachen. Da wir einen sehr modularen Ansatz haben sollte das nicht allzu schwierig sein.
Meine Maximalvorstellunge hierzu ist: Unsere Kunden nutzen (z.B. von uns vorbereitete) Docker-Container (in die man sich auch mit SSH / WinSCP auch einloggen kann) und installieren / programmieren dort was sie möchten. Schnittstellen werden Sockets sein. Damit dieser Docker einfach in die anderen Logiken einbindbar ist, wird es dazu eine Art "Definitions-File" geben in der Ein- / Ausgänge beschrieben werden. Damit kann man das dann auch leichter verbreiten, weil die Verbindung mit den Objekten in der Kundeninstallation erfolgt dort über den Logikeditor. Für den Nutzer sieht dann die Programmierung im Container aus wie jeder andere (fertige) Logikblock. Das macht dann auch die Verbreitung / zur Verfgungstellung an die Community einfacher.
Na ja, so wie ich Stefan verstanden habe kann man keine eigenen Sripte einbinden.
Vorwort: Unsere Entwicklung geht seit bald sechs Jahren. Was ich früher, teils vor vielen Jahren geschrieben habe, entsprach dem damaligen Wissen, der damaligen Erfahrung und den damaligen Möglichkeiten. Es hat sich viel verändert. Neue Technologien, mittlerweile dreimal soviele Entwickler wie Anfangs und deutlich mehr Wissen geben einen größeren Raum zur Entfaltung. Zudem gibt es heute - auch dank massiv fortschreitender Software-Entwicklung - bessere und weitere Möglichkeiten. Bitte nehmt nicht meine Aussagen von vor ein paar Jahren als Grundlage heran, weil es hat sich sehr vieles verändert.
Bedeutet: Insbesondere mit der Containerisierung wird das Einbinden von kundeneigenen Scripts bis hin zu komplexen Applikationen einfach möglich. Das Limit ist nur noch die Rechnerleistung und die liegt bei den Desktop-Modellen zwischen dem 25 bis 50 fachen gegenüber dem WireGate Server.
Ich bin mir nicht sicher, was mit "grafischer Baustein" gemeint ist? Du meinst damit Boxen mit Ein- und Ausgängen dran, an die man "Leitungen" hängen kann? Und dann vermutlich ein grafischer Editor, in dem man diese Boxen beliebig anordnen und miteinander verbinden kann, bis niemand mehr etwas versteht?
Wenn Du das gemeint hast: Jein, nach derzeitigem Entwicklungsstand.
Entwicklungsstand:
Bausteine in Form eines Rechteckes mit Ein- und Ausgängen: JA
Grafischer Editor mit dem man das beliebig anordnen kann: Nein (derzeit, siehe unten).
Das ist ein vieldiskutierter Punkt. Mir ist bekannt, dass viele Kunden sich einen grafischen Editor wünschen, weil man das von anderen Produkten kennt. Ich konnte das - das kann auch an mir liegen - nicht nachvollziehen, weil ich das für ziemlich unübersichtlich halte.
Ich habe mich für eine halbgrafische Anordnung entschieden, das bedeutet es gibt eine tabelarische Auflistung aller (auch tausender) Logiken untereinander. Eine Zelle nimmt dabei eine komplette Logik auf, die zig Ein- und Ausgänge haben kann. Diese Ein- und Ausgänge sind zeilenweise in dieser Zelle angeordnet. Stellt Euch das ähnlich dem Aufbau einer Tabellenkalulation vor. Links die "Eingänge", Rechts die "Ausgänge". Alles sehr übersichtlich und klar. Man muss keinen Verknüpfungslinien folgen, die über das halbe Blatt gehen und dort noch kreuzen.
Es hat den Vorteil, dass man sehr schnell zwischen den Logiken blättern kann, inkl. sortieren und filtern nach fast jedem sinnvollen Kriterium. Insbesondere kann man das auch schnell runtertippen ohne dass man sich eine Sehnenscheidenentzündung holt, weil ohne Maus nix geht.
Metalogiken: Denkbar (nicht versprochen) ist, dass man nun die Logik dieser Zelle selbst aus mehreren anderen Logiken bilden kann. D.h. komplexere Logiken baut man mit einem (womöglich vollgrafischen) Editor und speichert dies z.B. als "Wärmepume 12X" ab. Diese bindet man dann als "Blackbox" als eine neue Logikzelle in den Logikeditor ein. Auf diese Weise hat man eine Abstraktionsebene geschaffen. Insbesondere wenn nun ein solcher Logikblock zigfach genutzt wird, nur mit verschiedenen Objekten, steigert das die Übersichtlichkeit enorm, weil man eine abstrakte Blackbox vor sich sieht, an die man seine Objekte anschließt. Fertig.
Das ist ähnlich einer herkömmlichen Elektroinstallation. Da gibt es auch spezielle Bausteine (z.B. von Eltako / Finder) die man als Black Box benutzt und seine Leitungen anschließt. Auf den ersten Blick in eine solche Installation sieht man diese Bausteine in Reih und Glied und die an- und abgehenden Signale. Erst wenn man genau wissen will / muss, was in einem der Bausteine passiert, sucht man sich das Datenblatt / Doku und ließt das nach.
Letztlich sieht so der Logikeditor aus: Eine übersichtliche Auflistung der Bausteine nebst deren Ein- und Ausgangssignalen an Logikbausteinen. Die jeweiligen Bausteine (ob vorgebenene, Container für Scripte oder Meta-Logiken) werden jeweils als Box inkl. Beschriftung dargestellt. Objekte dran, fertig.
Fahrplan: Was es dahingehend zuerst geben wird, ist der Logikeditor und fertige Bausteine (geplant für Sommer 2018), dann eröffnen wir die Möglichkeit zum Scripten und dann sehen wir uns die Meta-Bausteine an. Einverstanden?
Was mich aber noch so intressiert ist die Datenbank, ich hatte Stefan Influx-DB vorgeschlagen, Sie wollten aber was ganz besonderes (Eigenes) entwickeln. Wie sieht es damit aus ?
Wir nehmen Beides. Infux und unsere eigene Entwicklung, je nach Plattform.
Desktop-Server: Auch wir haben die Entwicklung von Influx und anderer Datenbanken beobachtet und Dutzende getestet. Hinsichtlich der ursprünglichen Rolloutpläne wäre Influx zu spät gekommen. Während unser Verspätung bei der Entwicklung wurde Influx einsatzreif und daher konnten wir das nun einbinden. Auf den Desktop-Versionen des Timberwolf Servers.
Hutschienen-Server: Hier nehmen wir die eigene Entwicklung. Das besondere an unserer eigenen Entwicklung ist der extrem schlanke Footprint. Influx kann zigfach mehr, aber benötigt hier zuviele Ressourcen.
Meine Erwartung an so ein System - und derzeit das KO-Kriterium gegen fast alle existierenden Lösungen! - ist die Implementierung einer offenen DB-Schnittstelle.
Unsere Schnittstelle heißt SQL (Dialekt mit Timeseries). Auf den Desktop-Server haben wir ohnehin Influx, auf dem Hutschienenserver haben wir eine eigene DB-Engine, nach außen mit dem SQL-Dialekt wie Influx. Für Grafana stellen wir eine "Timberwolf" Datasource zur Verfügung, die entsprechend voreingestellt ist.
Du kannst also beliebig darauf zugreifen. Das gilt auch für das Log der KNX Telegramme.
Insb. möchte ich Cloud-Platformen zur Analyse nativ nutzen können.
Das sollte gehen. Wir denken auch darüber nach, die Möglichkeit zu eröffnen, auf eine externe Influx-DB (kann man sich ja bei Cloudanbietern mieten) zu loggen. Interessant ist das insbesondere, wenn jemand Dutzende bis Tausende von Gebäuden usw. verwalten muss. Unser Hutschienenserver könnte das lokal cachen und ansonsten die Daten an eine DB in die CLoud geben wo man dann mit geeigneten Werkzeugen drauf gehen kann.
Hier zahlt sich dann sicher unser Vorteil aus, dass wir in der Firma eine IT-Security und eine Cloud-Abteilung haben, die solche Dinge für große Kunden professional managed und daher das Know-How dafür gegeben ist, diese Fähigkeiten auch in den Timberwolf Server zu integrieren.
Kannst du was dazu sagen, wie/womit wir Logiken erstellen können und wie/welche DB angebunden werden?
Kurze Zusammenfassung:
Logiken werden Zellenweise erfasst. Jede Zelle benhaltet einen Logikblock mit Ein- und Ausgängen. (Das kann man sich vorstellen wie in einem Schaltschrank mit Spezialrelais für die jeweilige Ausgabe und deren Ein- und Ausgängen, nur dass die Blöcke untereinander angeordnet sind, links die Eingänge, rechts die Ausgänge). Für einfache Logiken - und das macht 95% aller Logikaufgaben aus, ist das extrem einfach und übersichtlich
Scripte in Logiken: Daran arbeiten wir noch, derzeitige Planung geht von Containerisierung aus. Der Container wird dann wir ein Logikblock eingebunden.
Datenbanken: Die Schnittstelle ist Influx-SQL. Logging auf externe DB ist angedacht.
Wenn du die Funktionalität so wie von Stefan beschrieben auf dem TW-Server einsetzen möchtest: Ja. Ich würd's dann auch nicht beim Anlesen belassen sondern einfach mal 'ne VM mit einem Linux deiner Wahl aufsetzen und ein paar Container bauen und untereinander vernetzen.
Sorry, das wollte ich nicht. Mein Fehler, ich habe das obige zu einseitig für die "Cracks" beschrieben.
Die Benutzung wird äußerst einfach werden! Versprochen.
Einer der wesentlichsten Limitationen beim WireGate Server war, dass fortgeschrittene Funktionen nur für Experten erreichbar waren. Wer nicht mindestens 100 bis 300 Stunden mit der Lernkurve verbracht hatte, konnte kaum Plugins schreiben oder verstehen. Dafür hat der normale Hausbauer und auch der Elektriker / Integrator keine Zeit und so sollte das auch nicht sein.
Wesentlichste Designvorgabe für den Timberwolf Server ist daher auch: Einfach, Einfach, Einfach.
Unsere Design-Grundsätze:
So einfach wie möglich: Das ist die "oberste Direktive". Wir arbeiten so lange daran, bis eine Sache wirklich einfach zu bedienen ist. Vorbild ist die einfache Bedienbarkeit von Smartphones / Tabletts und das "mitdenken" und die einfache Verknüpfbarkeit.
So automatisch wie möglich: Alles soll so automatisch funktionieren wie nur möglich, weil was man nicht erst einstellen muss, vereinfacht die Sache bereits erheblich. Daher haben wir sehr großen Aufwand reingesteckt, dass alles automatisch erkannt (angesteckte Interfaces, Busmaster, 1-Wire Sensoren) und mit (einstellbaren) Defauls konfiguriert wird. Z.b. werden die Zeitreihen für Sensoren automatisch angelegt. Wobei man die Defauls dafür nach seinem Gusto einstellen kann (sollte man vor dem Anstecken der Sensoren tun).
So granular einstellbar wie möglich: Trotz aller Automatismen soll man automatisch getroffene Einstellungen auch verändern können. Daher kann man, wenn man möchte, auch im Detail eingreifen. Um bei dem Beispiel mit den automatisch angelegten Zeitserien zu bleiben: Diese kann man jederzeit verändern und anpassen. In der laufenden Zeitreihe (ohne löschen und neu anzulegen). Sondern man ändert einfach die (automatisch angelegte) Regel ab. Fertig. Mit wenigen Klicks. Der Kunde hat die volle Freiheit bis ins Detail, wenn er möchte, beschäftigen muss er sich mit vielem nicht wirklich. Es ist einfach da und funktioniert.
So übersichtlich wie möglich: Der Benutzer soll nicht mit Fragezeichen vor dem System stehen. Daher werden alle relevanten Details in einer Statusleiste angezeigt, die einem bei der Diagnose eines Prolemes sehr viel Zeit sparen, zumal das System selbst Diagnosen vornimmt und auch Vorschläge unterbreitet. Dies wird kontinuierlich verbessert. Bei sehr vielen Punkten reicht es, mit der Maus darüber zu fahren / touchen und man bekommt Details und Begründungen eingeblendet.
So hilfreich wie möglich: Die Oberfläche unterstützt bei der Eingabe soweit das nur irgendiwe geht. Soweit möglich, werden Vorschläge eingeblendet. Beispiel Objekteingabefelder: Es gibt Fehlder, dort muss das Objekt angegeben werden, mit dem kommuniziert werden soll, also z.B. "K19" für ein KNX-Objekt.
Nur hat man nicht alle Objektnummer im Kopf. Daher kann man auch etwas anderes dort eingeben, z.B. die GA (oder Fragmente davon), die Hauptgruppe, Mittelgruppe, ein 'TAG' das man zuvor vergeben hat, die Bezeichnung der Verknüpfung aus der ETS oder nur ein *. Egal was man dort eingibt, auch durcheinander, man bekommt eine Liste aller in Frage kommender Objekte zusammen mit all diesen Angaben und davon dann hervorgehoben, was zur Suche passt. Das muss man wirklich gesehen haben, einfacher geht es wirklich nicht. Hierzu gehören auch farbliche Rückmeldungen während der Eingabe und alle Prüfungen, man kann nicht wirklich etwas falsch machen. Mehr Komfort kann ich mir nicht mehr vorstellen.
Daher bitte keine Sorgen machen. Man muss wirklich nichts lernen außer im KNX Bereich die ETS. Unser 1-Wire ist ohnehin komplett Plug´n´Play und die Verknüpfung der Objekte in den Editoren ist extrem übersichtlich und einfach. Ich werde mal bei Gelegenheit ein Video davon machen, damit man sich das besser vorstellen kann. Gebt mir bitte noch ein paar Wochen dafür. Auf der Messe werden wir das ohnehin zeigen.
Logik Editor:
Jedes Objekt mit jeder Logik: Auch für diesen gelten die oben aufgeführten Grundsätze. Entsprechend ist es äußerst einfach, eine logische Verknüpfung anzulegen. Es wird Dutzende bis Hunderte vorgegebene Logikelemente geben. Einfach Aufrufen (z.B. eine 'Und-Logik), dann die Eingänge dran (es erweitert sich einfach mit jeder Zeile selbständig, man muss also nicht vorher wissen, ob es ein 4-fach oder 6-fach Gatter werden soll) und dann die Ausgänge dran. Ein- und Ausgänge tragen Objekte. Ob das nun KNX-Objekte sind oder DMX oder CAN oder interne Objekte ist egal.
Typenwandlung inklusive ("Mission possible"): Selbst bei den Ein- und Ausgängen ist es egal, welche Typen man verwendet, es können auch analoge Werte auf einen eigentlich digitalen Eingang gehängt werden. Die Typumwandlung wird dann automatisch eingeblendet und gibt man dann eben an. Beispiel: Man hat ein Und-Gatter mit digitalen Eingängen, aber zwei der Eingänge sind Analog (Temperatur oder Spannung oder etwas anderes). Der Editor erkennt, dass der Eingangswert 'nicht binär' ist und gibt Wandelungsmöglichkeiten vor, also z.B. einen Schwellwertschalter mit Hysterese. Dann gibt man eben die untere und obere Schwelle an und fertig. Alles in der Eingangsbelegung. Das klickt man einfach nur (oder tabbed sich durch) und trägt die abgefragten Werte ein.
Kein Expertenwissen notwendig: Für fast alles an Typwandelungen, Logiken, Werteaufzeichnungen, Analysen, Logging usw. muss man NICHTS können außer es anzuklicken. Es ist keine Programmierung erforderlich und man muss keine tieferen Computerkenntnisse haben. Wer ein Smartphone bedienen kann, der wird auch de Timberwolf Server bedienen und einstellen können.
Docker, Container und Scripte:
Hinweis: Smarthome ist was neues und kaum jemand kennt sich wirklich damit aus. Bei Autos haben wir von Kind auf von der Familie gelernt, worauf man bei einem Auto achten muss. Bei neuen Dingen, wie beim Smarthome fehlt dieses Vorwissen. Daher informieren sich nicht wenige Menschen über das Internet, vor allem auch in Foren wie diesem. Tonangebend in solchen Foren sind zumeist die Erfahrenen, die Nerds & Cracks it tiefen Know-How, alteingesessene Pioniere und Experten die das beruflich machen. Diese wirken Meinungsbildend auf die anderen ein.
Wir verkaufen unsere Produkte quasi über das Internet und sind daher auch darauf angewiesen, dass unsere Produkte von diesen Experten auch gemocht werden. Das macht es für uns erforderlich, dass wir nicht nur diejenigen, die einfache Aufgabenstellungen umsetzen wollen, zufriedenstellen müssen, sondern auch die Cracks mit ihren komplexeren Anforderungen. Da Fragen zu Grenzen eines Systems oft von dieser Gruppe kommen, muss ich das eben bedienen, was regelmäßig zur der paradoxen Situation führt, dass manche Interessenten schon beim mitlesen "aufgeben", weil sie meinen, das System ist kompliziert.
Als damals beim WireGate Server mit den Plugins usw. angefangen wurde, haben die Hälfte der Interessenten vor dem Kauf erstmal angerufen und gefragt, ob man wirklich kein "Linux" und kein "PERL" bzw "Programmierung" können muss, weil sie die Angabe in der Artikelbeschreibung über die leichte Bedienbarkeit angesichts der diametral verlaufenden Diskussion im Forum um immer komplizierter werdende Sachverhalte, nicht glauben konnten.
Bedeutet: Um auch die Fortgeschrittenen und die Cracks mit Ihren Anforderungen zufriedenstellen zu können, müssen wir Eigenschaften in das Produkt einbauen, die für diese Kundengruppe vorgesehen ist. Wir wissen aber durchaus, dass dies weniger als 5% der Kundenschicht ausmacht und für alle anderen, das erheblich einfacher sein muss. Weil das ist unsere eigentliche Zielgruppe. Auslegen müssen wir das Produkt - bei Beibehaltung des Verkaufs über das Internet - aber für beide Zielgruppen. Die Newbies wie die Experten. Insofern, wenn ich also die Fragen der Cracks beantworte und die Möglichkeiten aufzeige, soll das nicht bedeuten, dass wir den Newbie vergessen hätten, im Gegenteil. Es sind nur leider deren Fragestellungen im Forum unterrepräsentiert.
Umsetzung Scripte / Container: Gedacht ist diese Funktion vor allem für die Experten. Woran wir aber arbeiten ist, dass wir deren Ergebnisse, soweit diese zur Verfügung gestellt werden sollen, für alle einfach nutzbar sein soll. Es ist noch nicht fertig designed, aber ich denke an eine einfache Oberfläche mit der man diese Container einfach auswählt und auf Knopfdruck installiert bekommt. Nicht schwerer als wie man APPs auf seinem Smartphone installiert.
Wenn also jemand die geniale Steuerung für Heizungsanlage XYZ programiert hat, kann er diese - in einem noch zu definierenden Format - auch allen anderen zur Verfügung stellen, wobei die Nutzer es damit nicht schwerer haben sollen, als wenn Sie eine UND-Logik anlegen.
Fazit: Wer diese komplexeren Möglichkeiten mit Docker und Co. nur Nutzen will, weil andere diese bereitgestellt haben, braucht sich nicht in das Thema Docker usw. einlesen. Selbst diejenigen, die einfache Scripte schreiben können, aber sich den Rest nicht anzun wollen, werden dazu fertig vorgegebene Container von uns bekommen und müssen dort nur ihr Script editieren.
Das meiste ist Fix & Fertig: Wir streben jedoch an, dass für alle Standardaufgaben im Smarthome solch Scripte und Container gar nicht gebraucht werden, weil wir das schon mit der Logikengine bereit stellen. Es wird so ziemlich alles abgedeckt werden, was heute am Markt gängig ist. Wer besondere Ideen hat: Wir freuen uns über jeden Feature Request an support at wiregate dot de. Es findet jeder Vorschlag meine Beachtung, ich lese das alles selbst und kümmere mich um die Umsetzung, wenn ich das gut finde.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar