Ankündigung

Einklappen
Keine Ankündigung bisher.

SmartHome.py

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    SmartHome.py

    Hallo,

    ich habe soeben mein Steuerungsprojekt auf Sourceforge geladen.
    Es nennt sich SmartHome.py und basiert auf Python.
    Ich habe grossen Wert auf die einfache Programmierung der Logiken gelegt. Ein weiterer wichtiger Aspekt ist die einfache Erweiterbarkeit mit zusätzlichen Plugins.

    Es steht unter der GPLv3 und Copyright 2011 KNX-User-Forum e.V.

    Momentan gibt es vier Plugins (KNX, 1-Wire, UDP, Prowl) und weitere werden folgen. Als nächstes steht ein Visu-Plugin an.

    Ihr könnt es unter http://smarthome.sourceforge.net/ finden.

    Ich hoffe es nützt ein paar von euch. Bei Fragen oder Problemen könnt ihr euch gerne an mich wenden. Entweder per PN, diesem Thread oder im Sourceforge Bug-Tracking.

    Bis bald

    Marcus

    P.S. ja ich kennen das neue Wiregate-Framework. Ich habe schon vor 9 Monaten mit der Programmierung angefangen und bin von meinem Ansatz überzeugt.

    #2
    kannst du evtl noch ein paar sätze dazu schreiben?
    was tut es?

    Kommentar


      #3
      Zitat von SebastianFey Beitrag anzeigen
      was tut es?
      Zuerst ist ein zentraler Speicherplatz für 'Items'. Diese Items werden in einem Baum organisiert.
      Code:
      wohnzimmer
          - licht
          - temperatur
          - fenster
      Jedem dieser Items kann man Attribute zuweisen. Mit Hilfe der Plugins können diverse Schnittstellen (KNX, UDP, 1-Wire, ....) eingebunden werden. Dadurch kann man sehr einfach Brücken zwischen den Schnittstellen schlagen.

      Folgende Config liest z.B. die Temperatur von einem 1-Wire Sensor und überträgt sie an die KNX GA 1/1/2.
      Code:
      [wohnzimmer]
          [[temperatur]]
              type = num
              knx_dpt = 9
              knx_ga = 1/1/2
              ow_id = 28.BBBBB20000 # see 1-Wire plugin
              ow_sensor = temperature # see 1-Wire plugin
      Neben dieser Gateway-Funktion kann man sich relativ einfach mächtige Logiken bauen, ohne sich um die Details im Hintergrund zu kümmern.

      Code:
      if sh.wohnzimmer.fenster() == 'offen':
          sh.wohnzimmer.heizung(aus)
      Ich habe auch sehr viel auf der Homepage dokumentiert.
      Soweit alles klar?

      Bis bald

      Marcus

      Kommentar


        #4
        Hallo,

        sehr interessant. Danke dafür!

        Ich kann es sicherlich nicht gut genug einschätzen. Aber ich sehe SmartHome.py als gute Ergänzung zur Comet Visu. (von dir als "Wiregate-Framework" bezeichnet (?)). Diese kann nämlich all das, was SmartHome.py kann nicht (und hat auch nach meinem Verständnis diese Ambition auch garnicht), während sie einen wesentlichen Punkt, der dir noch fehlt bereitstellt:
        Roadmap

        • Visu: HTTP
        Es wäre also zu überlegen, ob du diesen Punkt nicht überspringst und beim nächsten weitermachst.

        Die Kombination aus SmartHome.py und CometVisu klingt für mich jedenfalls sehr attraktiv!

        Nochmal danke für deine Arbeit und das Veröffentlichen.

        Gruß,
        Hendrik

        Kommentar


          #5
          Zitat von henfri Beitrag anzeigen
          Ich kann es sicherlich nicht gut genug einschätzen. Aber ich sehe SmartHome.py als gute Ergänzung zur Comet Visu. (von dir als "Wiregate-Framework" bezeichnet (?)).
          Das "WireGate Framework" ist vermutlich SourceForge.net: LogicEngine - Open Automation
          Zitat von henfri Beitrag anzeigen
          Diese kann nämlich all das, was SmartHome.py kann nicht (und hat auch nach meinem Verständnis diese Ambition auch garnicht)
          Richtig, die CometVisu ist eine reine Visualisierung und hat damit nichts mit einer Logik-Engine gemeinsam - und wird auch nie eine Logik-Engine enthalten. Sie kann aber leicht mit den verschiedensten Logik-Engines gemeinsam genutzt werden.

          Was mir am SmartHome.py fehlt (und auch am o.g. "WireGate Framework"), ist jedoch der grafische Logik-Editor. Denn nur bei der Signalfluss basierten (bzw. hier wohl eher Eventfluss) Modellierung sehe ich ein Potential für breitere Anwendung.
          Der ganze Rest ist für mich nur eine erweiterte Bibliothek zu einer Progammiersprache der persönlichen Präferenz und damit auf Leute beschränkt, die programmieren können. Das grafische ist zwar auch programmieren, aber die Einstiegshürde ist geringer, für Gelegenheitsanwender ist's besser und für Profis (die auch programmieren können) oftmals übersichtlicher.
          TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

          Kommentar


            #6
            Ohne sonstige Ausschweife, ein Hinweis: das ignorieren von Telegrammen vom (lokalen) eibd anhand der PA 0.0.0/1 halte ich für ziemlich bedenklich:
            Diese könnten auch von anderen Anwendungen auf derselben Maschine, ETS, EibPC, Dreambox (oder sonstwas, das via KNXnet/IP darüber zugreift) oder gar einem zweiten eibd via TP kommen und trotzdem etwas bewirken wollen

            Makki
            EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
            -> Bitte KEINE PNs!

            Kommentar


              #7
              Hi Hendrik,

              danke erst einmal.

              Zitat von henfri Beitrag anzeigen
              Es wäre also zu überlegen, ob du diesen Punkt nicht überspringst und beim nächsten weitermachst.
              Ganz so einfach ist es leider nicht. Man/ich braucht auf jeden Fall eine Verbindung zwischen Visu und SmartHome.py. Das ist im Endeffekt ein Comet-fähiges (S)CGI/Server. Welche Visu dann mit SmartHome.py spricht ist wahrscheinlich relativ egal. Hauptsache man kann halt long polling damit realisieren.
              Ich möchte auch keine eigene Visu-Engine entwickeln (JavaScript). Evtl. kann ich die von ChrisM nehmen oder die von sencha (Sencha - Sencha Touch Overview - Mobile Web App Development for Android & iPhone | Sencha Touch | Products | Sencha).
              Mal sehen Schritt für Schritt.

              Ach ja das Wiregate-Framework (nicht Comet Visu) kann schon ein bisschen mehr als du vermutest, die können auch Werte umsetzen und wahrscheinlich noch mehr. Ich bin aber nicht so richtig durch den Code gestiegen.


              Bis bald

              Marcus

              Kommentar


                #8
                Hi Chris,

                Zitat von Chris M. Beitrag anzeigen
                Was mir am SmartHome.py fehlt (und auch am o.g. "WireGate Framework"), ist jedoch der grafische Logik-Editor. Denn nur bei der Signalfluss basierten (bzw. hier wohl eher Eventfluss) Modellierung sehe ich ein Potential für breitere Anwendung.
                da gebe ich dir Recht, nur ohne stabile Basis von Null auf hundert ist halt ein bisschen viel (für mich). Naja, mal sehen was die Zeit so bringt. Ich bin echt gespannt wie sich euer Projekt weiter entwickelt.

                Zitat von Chris M. Beitrag anzeigen
                Das grafische ist zwar auch programmieren, aber die Einstiegshürde ist geringer, für Gelegenheitsanwender ist's besser und für Profis (die auch programmieren können) oftmals übersichtlicher.
                hmm, mag vllt daran liegen das ich keinen HS habe, aber was ich da an Logiken gesehen habe fand ich nicht besonders übersichtlich und einfach zu verstehen.

                Ich sehe eher die Installationshürden. Wenn jemand ein lauffähiges Setup (linux, eibd, owserver ...) realisiert, dann wird er auch das bisschen Python sprechen lernen bzw. die Logiken anpassen können. Das sieht man auch im Wiregate-Forum wenn dort Leute, die eigentlich keine Ahnung von Programmierung haben, selber Plugins schreiben/anpassen.

                Daher finde ich eine Appliance für diese Zielgruppe der Mausschubser ;-) besser.
                Ich sehe es auch als den eigentlichen Mehrwert den die Hersteller dieser Appliances bringen sollten, das die Enduser eine saubere GUI bekommen.

                Bis bald

                Marcus

                Kommentar


                  #9
                  Hi Makki,

                  Zitat von makki Beitrag anzeigen
                  Ohne sonstige Ausschweife, ein Hinweis: das ignorieren von Telegrammen vom (lokalen) eibd anhand der PA 0.0.0/1 halte ich für ziemlich bedenklich
                  danke für den Hinweis, das sehe ich auch so. Deswegen habe ich es dieses Verhalten auch in der Doku beschrieben. Ich sehe es aber auch als bedenklich an, wenn man Pakete dupliziert was bei euch anscheinend auch vorkommen kann. Da, bin ich mir aber nicht sicher.
                  Wenn ich z.B. eine 'dimme um 10%' reinbekommen und dann dann zweimal einen Dimm-Befehl an KNX übergebe. Verstehst du was ich meine, oder wo mein (und euer?) Problem liegt.

                  Bis bald

                  Marcus

                  Kommentar


                    #10
                    Zitat von mknx Beitrag anzeigen
                    da gebe ich dir Recht, nur ohne stabile Basis von Null auf hundert ist halt ein bisschen viel (für mich). Naja, mal sehen was die Zeit so bringt. Ich bin echt gespannt wie sich euer Projekt weiter entwickelt.
                    Dort habe ich schon mal ein Konzept für einen Web basierten GLE aufgesetzt - dem, wenn man's genau nimmt, eigentlich völlig egal ist, welche Engine dahinter steckt...
                    Evtl. ist das ja für Dich interessant. Code ist im SVN. Aber, wie gesagt, noch auf Konzept-Level.
                    Zitat von mknx Beitrag anzeigen
                    hmm, mag vllt daran liegen das ich keinen HS habe, aber was ich da an Logiken gesehen habe fand ich nicht besonders übersichtlich und einfach zu verstehen.
                    Ich hab auch keinen HS.
                    Was ich aber kenne ist Matlab/Simulink und ähnliche grafische Programmiersprachen. Und deren professioneller Einsatz um durchaus auch sicherheitskritische Software zu erzeugen. Da dort Simulink (bzw. ggf. TargetLink) durch einen Auto-Coder erst zu C gewandelt wird und dieses C durchaus mit per Hand geschriebenem C zusammen verwendet wird, kann ich, glaub ich, ganz gut den Unterschied zwischen grafisch und textueller Programmierung (zumindest im Kontext von Steuergeräten) vergleichen. Der Unterschied in der Verständlichkeit kann dramatisch sein (das gilt anders herum genau so - aber im Bereich der Regelungstechnik ist Signalflussbasiert typischer Weise besser)
                    Zitat von mknx Beitrag anzeigen
                    Ich sehe eher die Installationshürden. Wenn jemand ein lauffähiges Setup (linux, eibd, owserver ...) realisiert, dann wird er auch das bisschen Python sprechen lernen bzw. die Logiken anpassen können.
                    Das ist der Unterschied zwischen einer Lösung für Bastler und einem für kommerzielle Zwecke geeignetem Tool. Aber, da Du das ja in erster Linie für Dich machst so wie für andere interessierte, habe ich Verständnis, wenn Dir ersteres reicht.
                    Zitat von mknx Beitrag anzeigen
                    Das sieht man auch im Wiregate-Forum wenn dort Leute, die eigentlich keine Ahnung von Programmierung haben, selber Plugins schreiben/anpassen.
                    Wenn man ehrlich ist, sind die Plugins eine Notlösung. Wenn's nur bisschen komplexer werden soll, und z.B. ein Delay rein soll, wird's sehr aufwändig und ist für "Copy&Paste-Programmierer" nicht mehr geeignet. (Und mir ist's ehrlich gesagt zu blöd, daher beschäftige ich mich lieber mit der Weiterentwicklung als dass ich ein paar für mich sinnvolle Plugins schreibe...)
                    Zitat von mknx Beitrag anzeigen
                    Daher finde ich eine Appliance für diese Zielgruppe der Mausschubser ;-) besser.
                    Ich sehe es auch als den eigentlichen Mehrwert den die Hersteller dieser Appliances bringen sollten, das die Enduser eine saubere GUI bekommen.
                    Das sehe ich auch so. Nur ist der GLE nicht Bestandteil der GUI sondern der Logik-Engine. Das hängt damit zusammen das man ja eine grafische Syntax hat und nicht nur eine GUI zum Parameter-Verstellen (wie das "Programmieren" in der ETS, was, wenn man's genau nimmt, ja nur ein Applizieren ist)

                    Das alles unter einen Hut zu bringen und komfortabel bedienbar zu machen ist dann der Job für den Hersteller der Appliance. (Das ist auch der Grund warum ich keinen Editor für die CometVisu geschrieben habe. Aber bevor ElaboratedNetworks da was machen konnte hatte Netzkind den schon geschrieben... )
                    TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                    Kommentar


                      #11
                      Zitat von mknx Beitrag anzeigen
                      Wenn ich z.B. eine 'dimme um 10%' reinbekommen und dann dann zweimal einen Dimm-Befehl an KNX übergebe. Verstehst du was ich meine, oder wo mein (und euer?) Problem liegt.
                      Bzgl. KNX verstehe ich das Problem eigentlich nicht: Man verwendet tunlichst für setzen (Taster, Visu-Bedienung, Logik,..->Aktor) und Rückmeldung (Aktor-> Visu-Anzeige, aktualisierung von Stati [hörende GA]) einfach unterschiedliche GA's.
                      Wenn ein Anwender diese beiden zusammenlegt, wird er bei allen KNX-Geräten dasselbe Aha-Erlebniss lernen müssen

                      Deswegen ist ja erstmal nichts "doppelt", der eibd refektiert nur - IMHO völlig richtig so* - alle Telegramme auf alle clients.
                      *Man stelle sich eine Multithreaded-Anwendung vor, hier schreibt die Visu oder Zeitschaltuhr, auf die eine Logik o.ä. in einem anderen Thread (auch) reagieren soll..

                      Makki

                      P.S.: Nein, die PL-Plugins sind keine Logikengine
                      EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                      -> Bitte KEINE PNs!

                      Kommentar


                        #12
                        Version 0.2

                        Hallo,

                        es gibt ein kleines Update mit ein paar Verbesserungen:
                        - Threshold: Schwellwertschalter für Items, damit die Logiken nur bei überschreiten der Schwellwerte getriggert werden.
                        - Offset: man kann einem Item einen Offset zuweisen. Damit lassen sich einfache Abweichungen oder Umrechnungen erledigen.
                        - DMX Plugin: naja DMX halt
                        - CLI Plugin: ein kleines Plugin das einen Telnet-Zugang zu SmartHome.py bietet um Werte auszulesen und optional zu setzen

                        Zitat von makki Beitrag anzeigen
                        Bzgl. KNX verstehe ich das Problem eigentlich nicht: Man verwendet tunlichst für setzen (Taster, Visu-Bedienung, Logik,..->Aktor) und Rückmeldung (Aktor-> Visu-Anzeige, aktualisierung von Stati [hörende GA]) einfach unterschiedliche GA's.
                        Wenn ein Anwender diese beiden zusammenlegt, wird er bei allen KNX-Geräten dasselbe Aha-Erlebniss lernen müssen o
                        Das habe ich mir zu Herzen genommen und abgeändert.

                        Mehr Informationen und der Download findet sich wieder unter:

                        SmartHome.py - Homepage

                        Viel Spaß am Gerät

                        Marcus

                        Kommentar


                          #13
                          Hi Marcus,

                          wie ist denn smarthome.py im vergleich mit linknx einzuordnen? ich bin einer von denen, der schon noch mal ne xml datei schreiben kann bzw. auch python "lesen" kann
                          derzeit betreibe ich die comet visu (per xml config) auf dem WG und nutze ein paar Plugins. Nun steht an, entweder linknx als Logicengine zu nutzen oder aber "was anderes".

                          grüße
                          Derzeit zwischen Kistenauspacken und Garten anlegen.
                          Baublog im Profil.

                          Kommentar


                            #14
                            Hi Markus oder Matthias?,

                            Zitat von greentux Beitrag anzeigen
                            wie ist denn smarthome.py im vergleich mit linknx einzuordnen?
                            ich habe mir linknx vor einem Jahr mal näher angeschaut...

                            - Linknx ist wahrscheinlich schneller bzw. Ressourcenfreundlicher
                            - Damals gab es eine Limitierung der Variablen auf max 14 ASCII, damit waren URLs oder ähnliches nicht dynamisch abzuspeichern (was ich benötigt hätte).
                            - Linknx ist aus meiner Sicht eher starr und sehr auf KNX fokussiert. SmartHome.py ist sehr flexibel und lässt sich beliebig und aus meiner Sicht einfach erweitern. KNX, 1-Wire, DMX, Asterisk (gerade im Test), ...
                            - SmartHome.py wird (aktiv) weiterentwickelt.
                            - Python ist mächtiger als Lua bzw. einfacher über Module zu erweitern

                            Man kann es ingesamt eher mit Misterhouse vergleichen. Misterhouse sah für mich aber nach Perl-Gefrikel aus. Und Perl ist nicht so meines.

                            Das nächste SmartHome.py Release wird die erwähnt Asterisk-Anbindung und die Umstellung der Thread-Architektur bringen. Bisher hat jede Logik einen eigenen Thread bekommen, das wird in Zukunft von ein paar Worker-Threads erledigt. Weiterhin kann man 'faden' also einen Wert schrittweise erhöhen oder reduzieren um sanfte Übergänge zu realisieren.

                            Alles klar? Oder hast du noch weitere Fragen?

                            Bis bald

                            Marcus

                            Kommentar


                              #15
                              Hallo,

                              was macht denn die Asterisk Erweiterung?

                              Gruß,
                              Hendrik

                              Kommentar

                              Lädt...
                              X