SmartHome.py

[mivola]

Der Trick wäre nun die 5 Ansätze brauchbar zusammenzubringen, damit jew. mehr als 1-2 Entwickler an der Sache "beste OSS-Logikengine" stricken..

+1
LIKE
oder wie das heutzutage heißt...

[makki]

Wir (Chris, Makki, Nils und ich) können ja gerne mal über Synergien reden/chatten/mailen.

Gerne, (auch weitere die sich berufen fühlen); ich denke auch das es wenig Sinn macht das in einem Thread auseinanderzufieseln.. Es hat sicherlich jeder seine Kompetenzen, spezifischen Ideen und Ansätze/Erfahrung.
Ich hadere mit dem Thema (was die Grundstruktur angeht, nicht die Umsetzung oder die konkrete Programmiersprache) schon seit ewig, hab sehr viele Tests gemacht..

Hab mich heute Nachmittag auch mal "ne Stunde" hingesetzt und es nicht sinnvoll ans laufen bekommen. Vielleicht bin ich zu dämlich, was 1-Wire, KNX und Ubuntu ist weiss ich aber glaube ich eigentlich; das mal nur so als Grössenordnung.
Hinweise daraus:
- en/decode aller DPTs kann man sich hier ausleihen, den Spass haben sich Nils&me schonmal gemacht..
- Hinweis auf ephem, da gibts kein Paket für.. Also vielleicht auch einfach beilegen..

Es gibt da mindestens zwei Gesichtspunkte: geniale Software - und ob die jemand normales am Ende des Tages auch sinnvoll verwenden kann; da fühle ich mich eher berufen, dafür zu sorgen..
Genau aus diesem Grund bin ich übrigens bei mh raus. bevor ich rein bin..

Ich sage nicht das ich aller Probleme Lösung kenne oder so, aber ein paar Ideen hätte ich
Der Trick wäre nun die 5 Ansätze brauchbar zusammenzubringen, damit jew. mehr als 1-2 Entwickler an der Sache "beste OSS-Logikengine" stricken..

Makki

P.S.: Ein klitzekleiner Widerspruch @Chris: Python nimmt Perl da schon verdammt viel: es ginge wenigstens theoretisch, während in Perl alles was Threads/IPC/Prozesse in Daemons angeht einfach grundlegend kaputt ist.. Die Quintessenz aber bleibt: den Kern würde ich in C(++) machen, Scriptsprachen dann für komfortable "Plugins"..

[Chris M.]

Dennoch:
Wenn verschiedene Logik-Engines den gleichen Standard für die Kommunikation der internen Variablen nach Außen nutzen, dann kann es doch eine einheitliche Plugin-Schnittstelle geben, oder?

Du kannst sicher über diese Schnittstelle auch Plugins anbinden. Im Einzelfall ist aber zu klären ob das auch die beste Möglichkeit ist.

Wenn die Engine auf Events basiert, muss ein Plugin anders aussehen, als wenn sie auf Signalfluss basiert.
Darf ein Plugin interne Zustände haben? Soll es die intern speichern oder per Zustandsvektor im der Logik-Engine?
...

=> Man kann sicher gleiche Schnittstellen haben wollen, ob die aber nicht eher kontrakproduktiv sind, wäre zu klären.

Was ich noch nicht verstehe... PyWiregate und Smarthome.py hören sich beide verdächtig nach Python an.
Bisher dachte ich, es gäbe zwei Projekte, weil jeder nunmal seine Sprache bevorzugt. Aber wenn es schon die gleiche Sprache ist: Macht es dann nicht Sinn, die Energie zu bündeln -in einem Projekt?

Die verwendete Programmiersprache ist erst mal ziemlich egal. Ein erfahrender Programmierer kann innerhalb kürzester Zeit (Einheit: Stunde) eine ihm bis dahin unbekannte Sprache verwenden und ist nur etwas später auch schon gut produktiv (Einheit: Tage).
Klar bevorzugt jeder eine Sprache über einer anderen - aber entscheidend ist das nicht.

Wesentlich wichtiger ist, welche Eigenschaften die verschiedenen Sprachen haben. Aber da nimmt sich Perl und Python nicht viel (auch PHP wäre in dieser Klasse anzusiedeln.)

Und das entscheidende bei den verschiedenen Ansätzen für die Logik-Engine ist die Philosophie dahinter.
Alles rein -> Berechnen -> Alles raus wie bei einer SPS?
Auf Bus-Pakete per Events reagieren und alle Funktionen per Events koppeln?
Per Signalfluss?
Oder gar per differentiell-algebraischen Gleichungen (DAE)?

PyWireGate hatte NilsS eventbasiert geschrieben und wurde von mit um Signalfluss erweitert (die DAEs kann man ja mal in der mittleren Zukunft nachlegen).
Die anderen Systeme kenne ich zu wenig, als dass ich dort was zum Prinzip sagen kann.

[henfri]

Hallo,

ich verstehe.
Dennoch:
Wenn verschiedene Logik-Engines den gleichen Standard für die Kommunikation der internen Variablen nach Außen nutzen, dann kann es doch eine einheitliche Plugin-Schnittstelle geben, oder?

Z.B. ein Squeezebox-Plugin. Wenn dies nach einem Standard -z.B. dem COMET-Pattern- den aktuellen Song bereitstellt und als Input z.B. next, lauter, leiser, ... annimmt, kann man dieses Plugin mit Smarthome, PyWiregate, ... nutzen.

Was ich noch nicht verstehe... PyWiregate und Smarthome.py hören sich beide verdächtig nach Python an.
Bisher dachte ich, es gäbe zwei Projekte, weil jeder nunmal seine Sprache bevorzugt. Aber wenn es schon die gleiche Sprache ist: Macht es dann nicht Sinn, die Energie zu bündeln -in einem Projekt?

Gruß,
Hendrik

[Chris M.]

Verstehe ich es richtig, dass man, wenn alle Logiken das CometVisu Protokoll spricht, sogar Plugins "tauschen" könnte?

Nein, leider nicht.

Das CometVisu-Protokoll hat erst mal nichts mit Logiken zu tun, genau so wenig wie die CometVisu-Anwendung.
Wie der Name schon ausdrückt, ist es eine Visualisierung, die als Technologie das COMET-Pattern benutzt.

Eine Logik-Engine dagegen hat nichts mit einer Visualisierung zu tun. Die Bekommt Input, verarbeitet den und erzeugt Output. Fertig.

Der Berührungspunkt kommt dann, wenn die Visu auch interne Größen der Logik-Engine darstellen soll.

Doofes Beispiel:

Du hast einen Treppenhausautomaten in der Logik-Engine erstellt.
Input: Per Bus wird Licht angefordert
Verarbeitung: Internen Zähler auf X setzen, jede Sekunde um eins kleiner machen und wenn der Null ist, aufhören.
Output: Wenn der Zähler größer Null ist, Licht an, sonst Licht aus

Das kommt locker ohne Visu aus. Und die Visu kann auch ganz leicht den Status des Lichts anzeigen, da die auf dem Bus horcht und teilnimmt, wie jeder andere auch.

Aber wenn Du jetzt auf der Visu anzeigen willst, in wie vielen Sekunden das Licht ausgeht, kannst Du entweder diese interne Größe auf den Bus schicken und normal anzeigen - oder, um die Zahl der GAs zu reduzieren und den Bus nicht zuzumüllen - einen Kanal zwischen der Visu und der Logik-Engine aufmachen.
Wenn ich hier über das CometVisu-Protokoll im Rahmen einer Logik-Engine spreche, dann ist das immer dieser extra Kanal.

[henfri]

"Konkurrenz" belebt das Geschäft. Zersplitterung bremst andererseits jeden aus.
Im übrigens gibt es schon zwei fertige Logik-Engines: misterhouse und linknx.

Dennoch gibt es Gründe, warum hier weitere entstehen.

Konkret:
Ich würde mich freuen, wenn jemand mit Sencha eine Visu-Applikation erstellt, die das CometVisu-Protokoll spricht. Und wenn SmetHome.py das CometVisu-Protokoll sprechen würde (so wie PyWireGate auch schon das CometVisu-Protokoll spricht)
Dann könnte hier beliebig und frei gemischt werden und jeder die Logik-Engine und die Visu verwenden, die am besten passt.

(Und noch mehr würde ich mich freuen, wenn jemand das CometVisu-Protokoll dem GIRA HomeServer und auch dem EibPC beibringt - bei letzterem gab es diesbezüglich schon mal Kontakt)

(Fast) FullQuote, weill FullACK.
Mir fehlt der Überblick, um es so auszudrücken. Aber genau das halte ich für wichtig:
Es sollte 1+1>2 gelten ;-) Sprich: Nutzt Synergien. Macht kompatibel.
Es wäre toll, wenn man flexibel zwischen

• PC
• Wiregate
• Homeserver
• EibPC

• CometVisu
• HomeServer Visu
• EibPC Visu

• Smarthome.py Logik
• Homeserver Logik
• CometVisu Logik
• EibPC Logik

Wechseln kann.

Verstehe ich es richtig, dass man, wenn alle Logiken das CometVisu Protokoll spricht, sogar Plugins "tauschen" könnte?

Gruß,
Hendrik

[greentux]

Es gibt da viel freakiges Zeugs, ich hab da jetzt persönlich kein Problem mit aber halt 99% meiner Mitmenschen

Da kanns doch dann jemand geben, der schöne deb Pakete macht und die fürs WG und Co bereitstellt. Da hat das eine ja erstmal nix mit dem anderen zu tun.
Aus meiner Sicht wäre es schon extrem hilfreich, wenn die xml Datei per Webdav mit "schönen" Editoren im Windows/Linux zu bearbeiten wäre. Syntaxcheck etc wäre damit schon gegessen (wenn man Editor x darauf anpasst/konfiguriert). Ich denke, 99% ist etwas hoch gegriffen. Die Leute, die man mit einem Release und Announcement hier im Forum erreicht, haben durchaus geringere Schmerzgrenzen.
Beim Rest stimme ich euch unbedingt zu.

[callidomus]

Tja, das ist IMHO der Denkfehler, Sorry..
Es gibt da viel freakiges Zeugs, ich hab da jetzt persönlich kein Problem mit aber halt 99% meiner Mitmenschen

Das schöne ist, das kann jeder selbst entscheiden bzw. auch einfach machen. Wenn jemand einen Logik-Editor-Plugin schreiben möchte, würde ich ihn dabei unterstützen. Ich persönlich muss nicht 99% des Marktes erreichen, Ich will nichts verkaufen. Ich sehe SmartHome.py eher als (künftige) Konkurrenz zu Misterhouse.

Ergo, wenn man das zum Erfolg bringen will und mit 65 der liebsten nicht immernoch jede Funktion selber in XX coden kann/will dann wäre - meine 5ct - ein bündeln der aktivitäten schon hilfreich..
Die Ansätze gäbe es, aber mehr als anregen/fragen kann ich auch nicht, mit einer 2-3man-show wird das nix.

Wir (Chris, Makki, Nils und ich) können ja gerne mal über Synergien reden/chatten/mailen.
Ich hatte im Oktober mit Nils bereits Kontakt, er wollte jedoch einen speziellen Weg bei der Logik einschlagen. Über meine Bewegründe SmartHome.py weiterzuentwickeln können wir gerne reden.

so long

Marcus

[makki]

(Und noch mehr würde ich mich freuen, wenn jemand das CometVisu-Protokoll dem GIRA HomeServer ..)

Das wird zwangsweise passieren (die Frage ist nur noch wie man das einem Hersteller der das garnicht wollte hinlegt..)
Aber wichtiger fände ich Synergie, es ist ja super wenn 5 Projekte parallel tun aber wenn wir uns bei 1-2 wirklich aktiven wenigstens irgendwie einigen könnten -> wär das IMHO besser..

Makki

[makki]

An einen Editor denke ich nicht einmal. Wenn man SmartHome.py einrichten kann inkl. der anderen SW (eibd, owserver, Asterisk, ....), dann kann man
ein paar Zeilen Logik-Code in Python schreiben.

Tja, das ist IMHO der Denkfehler, Sorry..
Es gibt da viel freakiges Zeugs, ich hab da jetzt persönlich kein Problem mit aber halt 99% meiner Mitmenschen

Ergo, wenn man das zum Erfolg bringen will und mit 65 der liebsten nicht immernoch jede Funktion selber in XX coden kann/will dann wäre - meine 5ct - ein bündeln der aktivitäten schon hilfreich..
Die Ansätze gäbe es, aber mehr als anregen/fragen kann ich auch nicht, mit einer 2-3man-show wird das nix..

Makki

[Chris M.]

Ich würde mir eine Logik-Engine für die Comet-Visu wünschen.

Ich mir auch

Es wird aber schon eine gebaut.

Ja - aber das sagt nichts über "verwertbare" Releases aus.
Bei der CometVisu hatte ich fest damit gerechnet in den letzten Weihnachtsferien die öffentliche Beta zu veröffentlichen...

Eine zweite kann nicht schaden.

Ja und nein.
"Konkurrenz" belebt das Geschäft. Zersplitterung bremst andererseits jeden aus.
Im übrigens gibt es schon zwei fertige Logik-Engines: misterhouse und linknx.

Dennoch gibt es Gründe, warum hier weitere entstehen.

Andererseits: Wenn du dich für Sencha entscheidest gibt es zwei tolle Visus inklusive Logik-Engine ;-)

Ürbigens:

CometVisu ist erst mal ein Konzept mit einem Protokoll so wie einer JavaSript-Bibliothek, die das Protokoll einfach verfügbar macht.

Das was die meisten sehen, ist die oben drauf gesetzte CometVisu-Applikation - die aber nur eine von unzähligen möglichen Realisierungen ist.

Konkret:
Ich würde mich freuen, wenn jemand mit Sencha eine Visu-Applikation erstellt, die das CometVisu-Protokoll spricht. Und wenn SmetHome.py das CometVisu-Protokoll sprechen würde (so wie PyWireGate auch schon das CometVisu-Protokoll spricht)
Dann könnte hier beliebig und frei gemischt werden und jeder die Logik-Engine und die Visu verwenden, die am besten passt.

(Und noch mehr würde ich mich freuen, wenn jemand das CometVisu-Protokoll dem GIRA HomeServer und auch dem EibPC beibringt - bei letzterem gab es diesbezüglich schon mal Kontakt)

[henfri]

Das verstehe ich nicht ganz. Das ist ja kein Argument (für mich) pro Comet.

Genau.
Ich würde mir eine Logik-Engine für die Comet-Visu wünschen. Es wird aber schon eine gebaut.
Eine zweite kann nicht schaden.
Andererseits: Wenn du dich für Sencha entscheidest gibt es zwei tolle Visus inklusive Logik-Engine ;-)

Von daher gefallen mir beide Varianten.

Gruß,
Hendrik

[greentux]

Tja, ich kann zwar ne Logik im Python "hinbekommen", aber programmieren ist nicht mein Ding. Testen, Doku geht.
Wichtig wäre mir nur, das das auch auf den Ressourcen eines WG vernünftig läuft.
Und momentan bin ich mit der Cometvisu ganz zufrieden. Nur eben die Logik, da stehe ich am Scheidepunkt

[callidomus]

Gleich einen Editor mitliefern zu wollen kostet einiges an Ressourcen.

@mknx: bist Du da allein am Start oder coded noch jemand mit?

An einen Editor denke ich nicht einmal. Wenn man SmartHome.py einrichten kann inkl. der anderen SW (eibd, owserver, Asterisk, ....), dann kann man
ein paar Zeilen Logik-Code in Python schreiben. Das ist bei SmartHome.py wirklich einfach. Ich versuche die ganzen komplizierten Sachen (Bitshifting & Co) vom Benutzer wegzuhalten, damit der Logik-Code möglichst einfach ist.

Ich schreibe und dokumentiere das momentan alleine. Willst du mitmachen? Schau dir mal Sencha an, das ist echt mächtig.

so long

Marcus

[callidomus]

Was sagt der WAF?

Die sagt komm jetzt endlich ins Bett...
Wie gesagt das läuft bei mir momentan erst im Labor von daher hat sie keine Berührungspunkte. Ich würde ihr das auch nicht zumuten wollen. Also Schatz zum dimmen des Lichtes geh doch bitte mal auf die Kommandozeile und gebe ein telnet smarthome 2323 und dann ....

Comet wäre toll.
Dazu wird aber ja auch schon eine Logik-Engine gebaut.

Das verstehe ich nicht ganz. Das ist ja kein Argument (für mich) pro Comet.

so long

Marcus