Steuerung der KWL Cofoair mit diesem Protokol möglich?

[heckmannju]

Plugins im allgemeinen auch sind, ein ordentliches in C geschriebenes Programm dürfte nochmal eine Stufe robuster sein. Wesentlich für Beginner wäre eine separate Konfig-Seite mit allen Parametern, Diag-Modus, eigenem Log, Fehlerrückmeldung via GA, eMail, Visualisierung usw.. Also eine aufwändigere und dahingehend professionalisierte Lösung.

Das ein C-Programm Robuster sein soll wie ein Perl Programm wage ich zu bezweifeln. Programmierfehler können in beiden drin sein. Beim Pearl bekommt man nur meist eine Fehlermeldung. Beim C ist meist der komplette Prozess weggedumpt.

[Hauke]

Ich wäre ebenfalls bereit mitzutesten/mitzuentwickeln, habe ja auch in dem Plugin schon das eine oder andere ergänzt.

Eine "App" für ComfoAir zu haben hätte sicherlich Vorteile. Ich denke da in erster Linie an die Kommunikation über RS232, die innerhalb des Plugins etwas unglücklich ist. Ob ich bereit wäre, dafür auch Geld auszugeben hängt natürlich vor allem davon ab, wie teuer eine solche App wäre. Ich kann selbstverständlich nachvollziehen, dass euer Aufwand irgendwo bezahlt werden muss. Solange die Lösung aber keinen deutlichen Mehrwert gegenüber dem aktuell sehr gut funktionierenden Plugin bietet, würde ich mit Sicherheit keinen dreistelligen Betrag in eine Solche App investieren. Wenn's das für eine kleine zweistellige Summe gibt, und dafür ein kleiner Gewinn an Stabilität oder Geschwindigkeit dasteht, wohl schon eher.
Wie gesagt, alles eine Frage des Kosten/Nutzen-Verhältnis.

Ich sehe aber auch die Möglichkeiten des Plugins noch nicht am Ende, hatte nur schon länger keine Zeit mich damit eingehend zu beschäftigen.

Allgemein habe ich im Moment den Eindruck, dass sich das WireGate weg von OpenSource und hin zum "konventionellen" Produkt entwickelt. Ihr wollt eine App programmieren, die es dann nur gegen Aufpreis gibt. Wenn da eine Funktion fehlt, die ich gerne hätte, habe ich Pech. Beim Plugin könnte ich mir das dazubasteln...
Diesen Trend finde ich sehr schade.

Vielleicht als Anregung: Nur die RS232 Kommunikation "auslagern". Interessant wäre auch eine Oberfläche, um Plugins zu konfigurieren wie ein Gerät in der ETS. Die Definition dazu, muss natürlich im Plugin bzw. in der .conf-Datei geschaffen werden. Dazu braucht es aber eine Schnittstelle.

Gruß,
Hauke

[Hauke]

Ach ja, und ergänze doch bitte mal jemand von den Admins das fehlende 'm' im Thredtitel. Das sieht ja schrecklich aus...

[StefanW]

Ach ja, und ergänze doch bitte mal jemand von den Admins das fehlende 'm' im Thredtitel.

Der Threadname ist auch die URL. Bei einem so alten und vielgelesenen Thread ist von vielen Verlinkungen innerhalb und außerhalb auszugehen. Nur wegen einem fehlenden 'm' die Links zu brechen wäre falsch.

Ich ändere daher Überschriften entweder schnell oder nie (wenn der Titel nicht völlig daneben ist).

Stefan

[StefanW]

Solange die Lösung aber keinen deutlichen Mehrwert gegenüber dem aktuell sehr gut funktionierenden Plugin bietet, würde ich mit Sicherheit keinen dreistelligen Betrag in eine Solche App investieren.

Müsstest Du auch nicht, wir wollen niemandem etwas wegnehmen.

Wenn's das für eine kleine zweistellige Summe gibt, und dafür ein kleiner Gewinn an Stabilität oder Geschwindigkeit dasteht, wohl schon eher.

Für eine kleine zweistellige Summe ist eine solche Nischenlösung nicht zu erstellen und schon gar nicht zu supporten. Das kostet ja schon die Beantwortung eines einzigen Anrufes.

Allgemein habe ich im Moment den Eindruck, dass sich das WireGate weg von OpenSource und hin zum "konventionellen" Produkt entwickelt.

Die Nutzer wollen mehr und bessere Features. Nur etwa jeder 200 Nutzer eines WG bringt einen größeren Beitrag in Open Source ein, die anderen 199 nutzen das jeweils nur. Dieses Verhältnis reicht nicht um die Sache größer voranzubringen. Richtig große Fortentwicklungen (abgesehen von Plugins) macht außer uns fast niemand. Die Entwickler hier müssen bezahlt werden, das macht hier keiner in der Freizeit. Wenn ich für deren Leistung kein Geld im Bereich WireGate einnehmen kann, dann werden wir eben etwas anderes tun für das wir auch bezahlt werden.

Das bedeutet nicht, dass wir jemandem etwas wegnehmen. Das WireGate 1 Multifunktionsgateway bliebt wie es ist.

Aber das nimmt uns nicht das Recht, über fort- und weiterentwickelte Leistungsmerkmale, Apps, Leistungsausweitungen usw. als optionale kostenpflichtige Module nachzudenken oder diese anzubieten. Ist unser Risiko.

Damit bekäme jeder das was er will. Der Open-Source-Anhänger mit guten eigenen Kenntnissen, der keinen Support braucht und sich seine Merkmale selbst programmieren will, kann die Plugins nutzen.

Derjenige der eine Anlage einfach in Betrieb nehmen möchte, damit sind auch die vielen Elektriker und Heizungsfachbetriebe gemeint, brauchen eine Lösung out-of-the-Box mit 5 bis 10 jährigem Support ohne Anpassung. Oder soll der Heizi jedesmal zum Kunden fahren, weil sich beim Neustart die USB-Nummer geändert hat?

Diesen Trend finde ich sehr schade.

Bei unserem Shopsystem ist das so gemacht: Da gibt es die freie 'Community Edition' mit eingeschränkten Merkmalen und ohne Support. Und es gibt die 'Enterprise Edition' für 50.000 $ im Jahr und mehr. Die letztere finanziert auch die erstere. Was ist nun schade daran, wenn wir in ähnlichen Geschäftsmodellen denken?

Ist es so verwerflich, dass ich als Unternehmer sichere Arbeitsplätze schaffen möchte und dazu Möglichkeiten untersuche?

Warum sollen wir nicht prüfen, ob es Kundenschichten gibt, die sich über eine Lösung mit Support freuen, weil sie sich nicht mit Perl & Co. auseinandersetzen wollen? Weil sie Anrufen und eine Antwort bekommen möchten?

Interessant wäre auch eine Oberfläche, um Plugins zu konfigurieren wie ein Gerät in der ETS. Die Definition dazu, muss natürlich im Plugin bzw. in der .conf-Datei geschaffen werden. Dazu braucht es aber eine Schnittstelle.

Ja, gute Idee. Schreib es doch bitte, wir integrieren das gerne.


lg

Stefan

[Hauke]

Für eine kleine zweistellige Summe ist eine solche Nischenlösung nicht zu erstellen und schon gar nicht zu supporten. Das kostet ja schon die Beantwortung eines einzigen Anrufes.

Das dachte ich mir schon. War auch nur als ehrliche Antwort auf deine Frage gedacht.

Richtig große Fortentwicklungen (abgesehen von Plugins) macht außer uns fast niemand. Die Entwickler hier müssen bezahlt werden, das macht hier keiner in der Freizeit. Wenn ich für deren Leistung kein Geld im Bereich WireGate einnehmen kann, dann werden wir eben etwas anderes tun für das wir auch bezahlt werden.

Völlig richtig. Ich verstehe sehr gut, das euer "Überleben" am Markt entscheident davon abhängt, das sich das Wiregate weiterentwickelt. Ich glaube aber, das sich viele hier für das WG entschieden haben, weil jeder Plugins schreiben kann, weil es einen root-Zugang gibt, usw. Die Weiterentwicklung in eine Richtung zu lenken, bei der jede Funktion extra bezahlt werden muss und deren Code nicht offen ist, finde ich eben nicht schön...

Aber das nimmt uns nicht das Recht, über fort- und weiterentwickelte Leistungsmerkmale, Apps, Leistungsausweitungen usw. als optionale kostenpflichtige Module nachzudenken oder diese anzubieten. Ist unser Risiko.

Selbstverändlich! Aber wäre es nicht sinnvoller, wenn ihr euch auf die Leistungserweiterungen konzentriert, bei denen das Verhältnis von Aufwand und Nutze(r)n in einem besseren Verhältnis steht?
Beispiel: Ein Plugin für die ComfoAir nutzen hier schätzungsweise ein Dutztend Leute, vielleicht ein paar mehr. Den Entwickungsaufwand dafür schätze ich recht hoch, da z.B. das Protokoll nur teilweise entschlüsselt ist, eine beträchtliche Anzahl von Funktionen umgesetzt werden soll und und und...
Die Programmierung eines Daemon für die USB-RS232 Schnittstelle erfordert sicherlich tiefere Kenntnisse der WG-Software als das Erstellen eine Plugins. Das ist aber nicht nur für die ComfoAir-Besitzer interessant, sondern vielleicht auch für andere. Zudem ist der Entwicklungsaufwand geringer, da "nur" die Anbindung der Hardware und die Schnittstelle zum Plugin geschaffen werden muss.
Anderes Beispiel: Wieviele Plugins gibt es mittlerweile im SVN? Viele Plugins inzwischen mit recht ähnlichem Funktionsumfang, weil eben doch die Bedürfnisse der Nutzer recht unterschiedlich sind, und das Anpassen auf eine allgemeingültige, flexibel konfigurierbare Struktur immenser Aufwand ist und das Plugin sowie dessen Konfiguration sehr komplex machen. Was fehlt, ist eine Schnittstelle zwischen Plugin und Otto-Normal-Anwender. Dann kann auch der Elektriker ein Plugin beim Kunden in Betrieb nehmen, selbst wenn er kein Programmierer ist. Aufwand: Überschauber. Nutzbar: Für alle Plugin-Andwender. Eben nicht nur für die, die das spezial-Rolladen-xy Plugin oder wasweißichwas benötigen.

Derjenige der eine Anlage einfach in Betrieb nehmen möchte, damit sind auch die vielen Elektriker und Heizungsfachbetriebe gemeint, brauchen eine Lösung out-of-the-Box

Ja, glaube ich auch. Aber wenn der Kunde unbedingt eine Anlage mit KNX-Anbindung haben will, greifen die doch einfach zur Anlage die bereits Herstellerseitig KNX-Anbindung hat, auch wenn's den Kunden 1000 EUR Aufpreis kostet und die Anlage andere Nachteile hat.
Ich kann mir nicht vorstellen das ihr das billiger entwickeln könnt.

Ist es so verwerflich, dass ich als Unternehmer sichere Arbeitsplätze schaffen möchte und dazu Möglichkeiten untersuche?

Warum sollen wir nicht prüfen, ob es Kundenschichten gibt, die sich über eine Lösung mit Support freuen, weil sie sich nicht mit Perl & Co. auseinandersetzen wollen? Weil sie Anrufen und eine Antwort bekommen möchten?

Ich freue mich darüber, das ihr genau das macht! Da du aber hier im Forum nach der Meinung fragst: Macht nicht alles doppelt, sondern konzentriert euch auf das, was ihr besser und effizienter könnt als die Community. Und damit meine ich nicht, den Funktionsumfang eines Plugins als C-Code in das Betriebsystem einzubauen. Nutzt doch einfach das, was ihr von der Community geschenkt bekommt. Auch wenn's nur 0,5% der Anwender sind, die sich an der Weiterentwicklung beteiligen, kommt doch immer noch eine beachtliche Anzahl zusammen denke ich.
Wäre es nicht sinnvoller, ihr sorgt dafür das ich dem USB irgendwo einen Namen geben kann, so dass er seine Nummer eben nicht bei jedem Neustart ändert? Dafür müsst ihr doch nicht 1000 Plugins, die auf den USB zugreifen, als App verkaufen.

Ja, gute Idee. Schreib es doch bitte, wir integrieren das gerne.

Würde ich sogar tun, aber bin schon froh das ich gerade so eben mit Perl klarkomme. Ich helfe aber gerne bei der Spezifikation der Schnittstelle und passe alle meine Plugins so an, das sie dazu konform sind und stelle sie ins SVN.
Außerdem würde das sicher eine Funktion, die näher an die Grundfunktionalitäten des WG heranreicht als ein Plugin. Da ist es doch nicht mit programmieren und integrieren getan. Wie lange hat es gedauert, bis das Compile_Plugin und das selektive subscribe_GA ihren Weg in den wiregated.pl gefunden haben? Nicht falsch verstehen, absolut verständlich das ihr sowas ausgiebig testen müsst, da eine Fehlfunktion hier auf das Produkt Wiregate und nicht auf ein Plugin zurückfällt.
Aber genau deswegen sind doch das die Funktionen, die am besten von Euch und nicht von uns umgesetzt werden. Und auch soetwas hat einen echten Mehrwert für das Wiregate.

Gruß,
Hauke

[StefanW]

Ich glaube aber, das sich viele hier für das WG entschieden haben, weil jeder Plugins schreiben kann, weil es einen root-Zugang gibt, usw.

Das wird auch nicht angetastet.

Die Weiterentwicklung in eine Richtung zu lenken, bei der jede Funktion extra bezahlt werden muss und deren Code nicht offen ist, finde ich eben nicht schön...

Es geht nicht um "jede" Funktion, sondern um spezifische und aufwändige Extras. Nicht jeder hat Lust darauf, Monate oder Jahre darauf zu warten, ob sich ein community-driven-plugin zur allgemeinen Brauchbarkeit entwickelt hat, zumal viele Entwickler nur bis zum "it´s work for me"-Punkt arbeiten.

Beispiel: Ein Plugin für die ComfoAir nutzen hier schätzungsweise ein Dutztend Leute, vielleicht ein paar mehr.

Das ist was ich herausfinden wollte. Ich bin von den Zugriffszahlen her von einem größeren Interesse ausgegangen. Wenn es nur eine sehr kleine Minderheit interessiert, dann lassen wir das eh.

auch wenn's den Kunden 1000 EUR Aufpreis kostet und die Anlage andere Nachteile hat. Ich kann mir nicht vorstellen das ihr das billiger entwickeln könnt.

Doch, das glaube ich schon, weil wir baukastenmäßg arbeiten. Jeder Hersteller beginnt für sich von neuem.

Nutzt doch einfach das, was ihr von der Community geschenkt bekommt. Auch wenn's nur 0,5% der Anwender sind, die sich an der Weiterentwicklung beteiligen, kommt doch immer noch eine beachtliche Anzahl zusammen denke ich.

Ich will niemanden Leistung schmälern, aber - abgesehen von den Plugins - ist das wenige für eine wirkliche Weiterentwicklung nicht ausreichend. Besonders bei den kernigen Aufgaben im OWFS, im eibd und der Oberfläche ist die Mitarbeit durchschnittlich (!) nicht so hoch, dass der Aufwand der Integration über dem "geschenkten" Wert liegt.

Wie lange hat es gedauert, bis das Compile_Plugin und das selektive subscribe_GA ihren Weg in den wiregated.pl gefunden haben?

Richtig, am Ende hat das viel zu lange gedauert. Weil keine guten Entwickler bei uns verfügbar waren. Jetzt sind diese da, jetzt wird das binnen Wochen integriert aber jetzt kosten diese Entwickler eben auch richtig Geld.
Ich glaube Dir ist nicht bewusst, was die Integration dieser guten und fertigen Fixes und die Tests dafür am Ende für einen Kostenaufwand verursachen. Makki hat diese Dinge früher auf Kosten seiner Freizeit gemacht, diese Zeiten sind vorbei. Die Freibier-Show ist vorüber.

Am Ende entscheiden das die Kunden. Wer möchte, dass es einen Strom von brauchbaren und wertvollen Erweiterungen auf Knopfdruck gibt, wird dafür einen Obulus entrichten. Alle anderen haben jede Freiheit, nötiges selbst zu entwickeln.

Ich wollte keinesfalls den Thead hier kapern. Wenn meine Idee nicht gut, unerwünscht oder am Ende nicht umsetzbar ist, dann lassen wir es eben.

lg

Stefan

[Hauke]

Das ist was ich herausfinden wollte. Ich bin von den Zugriffszahlen her von einem größeren Interesse ausgegangen. Wenn es nur eine sehr kleine Minderheit interessiert, dann lassen wir das eh.

Abwarten, vielleicht irre ich mich ja und du hast Recht

Besonders bei den kernigen Aufgaben im OWFS, im eibd und der Oberfläche ist die Mitarbeit durchschnittlich (!) nicht so hoch, dass der Aufwand der Integration über dem "geschenkten" Wert liegt.

Ich glaube Dir ist nicht bewusst, was die Integration dieser guten und fertigen Fixes und die Tests dafür am Ende für einen Kostenaufwand verursachen.

Doch, ist es. Gerade deswegen traue ich mir nicht zu, dort sinnvoll zu unterstützen, ebensowenig wie den meisten der Plugin-Schreiber. Die Leute die das können sind vielleicht 1-2% der Leute die sich selbst ihre Plugins programmieren.
Ich wollte einfach nur mal den Denkanstoß liefern, ob es für euch nicht zielführender sein könnte, sich auf die "kernigen" Themen zu konzentrieren.

Nehmen wir mal an, es gäbe im WG eine ETS-ähnliche Konfig-Oberfläche für Plugins, mit denen auch der Elektriker in der Lage wäre, das Plugin in Betrieb zu nehmen. Ich denke wir hätten im Handumdrehen eine ganze Reihe von Plugins, die von den Plugin-Entwicklern auf diese Oberfläche angepasst wären.
Das Risiko wäre vergleichsweise gering, da es nach wie vor nur Plugins sind. Der für Otto-Normal-Anwender zugängliche Funktionsumfang aber immens größer, da sich nun jeder Installateur an den verfügbaren Plugins bedienen kann. Mit einem Bruchteil des Entwicklunsaufwandes bei ElabNet im Vergleich zu der Variante das ihr jede Funktion als App entwickelt.

[swiss]

Ich kann mir auch vorstellen, dass noch unerschlossenes Potenzial da wäre. Einersets nutzen momentan schätzungsweise 95% der ComfoAir Plugin nutzer dies für die ComfoAir350L Wenn man mal eine vollständige Liste aller kompatiblen Geräte und für z.B. Die 350D ein fertiges und preiswertes Adapterkabel hätte, so hätten bestimmt noch ein paar mehr Interesse an einer solchen Lösung. Zumal viele Googeln und nur die, die nach ComfoAir 350 KNX suche stossen umstäntlich auf die Pluginlösung. Wenn es was fertiges gäbe, dass auch als solches offen und gut im Netz auffindbar wäre, so würde warscheinlich noch der eine oder andere seine ComfoAir anbinden.

Nur so ne Idee... Eventuell könnte man auch "Pakete" machen...

Adapterkabel 2m RJ45 auf RS232 für 10.- Euro
Vollintegrierte WG APP für alle Kompatiblen KWL's 50.-
Kombipaket mit Adapterkabel und APP 55.-

Somit wäre für jeden etwas dabei und der reduzierte Preis für das Kombipaket macht es auch uninteressanter für z.B. die 350D das APP zu kaufen und sich den Adapter selber zu löten zumal der "Rabatt" auch Psychologisch noch helfen kann...

Sind natürlich nur Beispielpreise. Ob eine APP Lösung wirklich interessant wird, hängt natürlich von der Preisgestaltung ab...

Allerdings wäre echt mal interessant zu erfahren wie gross der Nutzerkreis des Plugins wirklich ist. Denn es gibt ja immer auch eine "Dunkelziffer". Bekant sind mir gerade mal ca. ein Dutzend aber ich denke die Anbindung wird noch von ein paar mehr genutzt die sich hier einfach nie dazu gemeldet haben...

[swiss]

Hmmm...

Wobei ich gerade nochmal über die Sache nachgedacht habe... Das Finanzielle Risiko ist warscheinlich viel zu gross. Denn Bei den Elektrikern ist der HS immer noch weit verbreitet und für den gibt es schon eine ComfoAir Anbindung.

Der nächste Punkt ist die Kostendekung. Wenn die Entwiklung 10k Euro kosten würde, dann bräuchte es bei einem App Preis von 100.- Euro auch 100 Käufer bis nur mal die Ausgaben gedeckt sind. Und ich befürchte viele werden warscheinlich bei einem APP Preis von 100.- Euro eher das Plugin verwenden und dafür die Einschränkungen in Kauf nehemen oder die Anbindung ganz sein lassen...

Ich fürchte also dass sich das nicht rechnen wird. Ich kann mich aber auch irren...

[lio123]

...tut mir leid, wegen dem vergessenen "m"...

Kann's gar nicht oft genug sagen:
Danke, Patrick & Co für Eure Unterstützung



Grüße,
Lio

[gospelrock]

Bei mir läuft das Plugin eigentlich ohne Probleme. Aber seitdem ich es installiert habe, kam es schon mehrmals vor, dass nach ca. 2 Wochen alle Plugins hängen. Der Plugin-Log ist leer. Auf der Status-Seite habe ich festgestellt, dass der 1wire-Server in dem Fall auf "Off" steht. Nach einem Neustart läuft alles wieder bis zum nächsten Hänger.
An Apps habe ich nur noch die Schaltuhr installiert (bereits seit 2 Jahren). Deswegen kann der Aufhänger nur vom ComfoAir-Plugin kommen.

Für Tipps und Hinweise wäre ich sehr dankbar!

Peter

[swiss]

Hallo Peter

Hmmm... Das ist in der Tat seltsam. Du bist der erste von dem ich das höre... hast du mal ein screenshot der Pugin Übersichtsseite wenn mal wieder alles hängt? Auch die log Datein sollte gesichert werden bevor ein Neustart durchgeführt wird da die danach meist leer sind. Davor hätte man die Changse noch etwas herauszulesen.

Was auch hilfreich sein könnte. Hättest du mir mal den Inhalt der configdatei des Plugins? Auch die Version des Plugins ist von Bedeutung für die Fehlersuche.

Was du auf keinen Fall machen solltest ist das Plugin auf debuglevel 2 oder höher laufen zu lassen! Damit werden hunderte von Logeinträge pro Stunde generiert die beim Dauerbetrieb dazuführen dass nach ein paar Wochen der Speicher voll ist und desshalb das WG "hängt". Das wäre eine mögliche Ursache für das von dir geschilderte Verhalten.

[gospelrock]

Hallo Patrik,

ich hatte vor dem Neustart nach der Logdatei gesehen. Die war leider da schon leer.
Jetzt warte ich erst einmal wieder ab, bis alles hängt. Dann kann ich Dir genaueres mitteilen.

Peter