SmartHome.py

[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

[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]

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.]

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.

[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"..

[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...

[greentux]

gabs da was neues im "chat" etc zu?

[callidomus]

gabs da was neues im "chat" etc zu?

Nein, bis jetzt gibt es nichts dazu. Mal sehen wie die 'richtigen' (wer ist das?) zusammenkommen.

@makki: wollen wir dazu einen Thread im WG Beta Forum aufmachen? Dazu bräuchte ich dann aber Zugriff.

Bis bald

Marcs

[greentux]

So wie es aussieht, wäre das da der Treffpunkt in Bayern zu suchen oder?
Vl. könnte man sich auf Hoif einigen ?

[vento66]

Oder der Stammtisch in München......


Sent from my iPhone using Tapatalk

[callidomus]

Oder der Stammtisch in Franken (der findet ja bald wieder statt)... ;-)

[makki]

@makki: wollen wir dazu einen Thread im WG Beta Forum aufmachen? Dazu bräuchte ich dann aber Zugriff.

Erledigt, mach
Stammtische werden auch wieder stattfinden, in Bayern bin ich gewöhnlich sicher dabei aber ich kann da natürlich nur für mich sprechen..

Wiegesagt, mehr als eine - gerne! - "beratende Moderator-Rolle" sehe ich da akuell für mich aber nicht. Ich war heute gegen 23:30 Uhr mit den neuen, abonnierten Threads fertig

Makki

P.S.: Wir suchen immernoch dringend helfende Hände denn die Ideen übersteigen die verfügbare Zeit bei weitem..

[callidomus]

SmartHome.py 0.3

Hallo,

es ist mal wieder Zeit für ein neues Release. Die größte Änderung findet sich unter Haube: Ich habe den Thread-Bedarf deutlich reduziert. Jedes Plugin verwendet einen Thread und die Logiken teilen sich 10 Worker-Threads. Somit sollte es auch auf kleinen Kisten mit vielen Logiken ohne Probleme laufen.

Weiterhin gibt es folgende Änderungen:

• Asterisk Plugin: Man kann UserEvents aus der extensions.conf abfangen um z.B. bei eingehenden Anrufen eine Signalisierung zu starten. Weiterhin kann man aktive Channels (vereinfacht: Telefongespräche) monitoren um die aktiven Telefone zu erkennen (Musik leiser, ....).
• fade Funktion für items um einen sanften Übergang zu ermöglichen. Das verwende ich mit meinem DMX-Plugin um die RGB-LED-Leiste zu dimmen.
• Crontab Keyword init: damit kann man Logiken beim Start laufen lassen.
• und noch ein paar Kleinigkeiten ...

Mehr dazu unter: http://smarthome.sourceforge.net/

Bis bald

Marcus

[gramels]

Hallo Marcus,

ich probier smarthome.py grad aus und bekomme auf Debian 5 das folgende:

/usr/local/smarthome/bin# ./smarthome.py 
/usr/local/smarthome/lib/item.py:186: Warning: 'with' will become a reserved keyword in Python 2.6
Traceback (most recent call last):
  File "./smarthome.py", line 40, in <module>
    import lib.item
  File "/usr/local/smarthome/lib/item.py", line 186
    with open(self._sh.cache_dir + self.path, 'r') as f:
            ^
SyntaxError: invalid syntax

dpkg -l|grep python
ii  python                            2.5.2-3                    An interactive high-level object-oriented la
ii  python-central                    0.6.8                      register and build utility for Python packag
ii  python-configobj                  4.5.2-1                    a simple but powerful config file reader and
ii  python-dateutil                   1.4.1-2                    powerful extensions to the standard datetime
ii  python-minimal                    2.5.2-3                    A minimal subset of the Python language (def
ii  python-support                    1.0.10                     automated rebuilding support for Python modu
ii  python2.5                         2.5.2-15+lenny1            An interactive high-level object-oriented la
ii  python2.5-minimal                 2.5.2-15+lenny1            A minimal subset of the Python language (ver

Das heisst vermutlich, dass es zwingend python 2.6 sein muss, also Debian 6 oder halt händisch python 2.6 auf debian 5 quetschen.

Ich bin jedenfalls sehr gespannt drauf, vor allem auf das knx dmx gateway mit fader.

Grüsse

Lothar

[callidomus]

Hi Lothar,

Das heisst vermutlich, dass es zwingend python 2.6 sein muss...

leider ja. Bei anderen Fragen oder Problemen frag einfach.

Viel Spaß mit SH.py

Bis bald Marcus