Ankündigung

Einklappen
Keine Ankündigung bisher.

SmartHome.py

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

    #76
    noch ne allgemeine Frage: in der smarthome.conf muss ich quasi für jede GA einen separaten Eintrag erstellen, sehe ich das richtig? Also z.B. bei Lampen die dimmbar sind brauche ich einen für schalten und einen für dimmen. Ebenso bei Jalousien einen für AUF/AB, einen für Position Behang und einen für Position Lamelle. Wird das nicht schnell etwas unübersichtlich?

    Kannst du mal ne config von dir posten?
    Mit freundlichen Grüßen
    Niko Will

    Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
    - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

    Kommentar


      #77
      Hi,

      Ich bin gerade auf der Baustelle, heute Abend kann ich ausführlicher antworten und eine Konfiguration posten.

      Mit 0.7 kann man beliebige (tiefe) Hierarchien bauen und nicht mehr nur zwei Ebenen. Weiterhin wird auch eine einfache Visu automatisch erzeugt.

      Bis dann

      Marcus

      Kommentar


        #78
        Zitat von mknx Beitrag anzeigen
        Mit 0.7 kann man beliebige (tiefe) Hierarchien bauen und nicht mehr nur zwei Ebenen. Weiterhin wird auch eine einfache Visu automatisch erzeugt.
        Und das sagst du mir jetzt... hab gerade angefangen das für beliebig tiefe Hierarchien umzuschreiben

        Weißt du schon, wann du die 0.7 releasen willst?
        Besteht Interesse an einer Zusammenarbeit oder willst du das alleine pflegen?
        Mit freundlichen Grüßen
        Niko Will

        Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
        - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

        Kommentar


          #79
          Wer viel fragt bekommt viele Antworten ;-)

          Hi Niko,

          jetzt aber richtig.

          Zitat von 2ndsky Beitrag anzeigen
          Habe Smarthome.py heute mal im Büro getestet und war recht angetan. Nun wollte ich es auf'm Wiregate installieren, was aber nicht ganz einfach ist. Da dort standardmäßig Python2.5 installiert ist und ein einfaches Update auf 2.6 nicht möglich, da nicht im Repo, hab ich 2.6 aus den sourcen parallel installiert.
          Freut mich! Es scheint Dir ja echt gefallen zu haben wenn Du das auf Dich nimmst.
          An Nachahmer: Ich würde generell gleich den Schritt zu 2.7 empfehlen. Momentan ist zwar 2.6 ausreichend aber das ist auch schon angezählt. Bei Ubuntu 12.10 wird 3.0 als default installiert.

          Zitat von 2ndsky Beitrag anzeigen
          noch ne allgemeine Frage: in der smarthome.conf muss ich quasi für jede GA einen separaten Eintrag erstellen, sehe ich das richtig? Also z.B. bei Lampen die dimmbar sind brauche ich einen für schalten und einen für dimmen. Ebenso bei Jalousien einen für AUF/AB, einen für Position Behang und einen für Position Lamelle. Wird das nicht schnell etwas unübersichtlich?
          Das verstehe ich nicht ganz. Man kann viele GAs pro Item für unterschiedliche Aufgaben angeben (Init, Listen, Send, Reply..). Wenn aber man unterschiedliche Funktionen steuern möchte braucht man unterschiedliche Items.

          Zitat von 2ndsky Beitrag anzeigen
          Kannst du mal ne config von dir posten?
          Anbei eine Config (0.7) von meiner Entwicklungsmaschine. Die Visu dazu packe ich in den Anhang.
          Code:
          lat = 49.48
          lon = 9.59
          elev = 177
          tz = 'Europe/Berlin'
          
          
          [dg]
              name = Dachgeschoss
              [[buero]]
                  name = Büro
                  [[[temp]]]
                      type = num
                      name = Temperatur
                      cache = yes
                      visu = div
                  [[[hum]]]
                      name = Luftfeuchtigkeit
                      type = num
                      cache = yes
                  [[[dew]]]
                      name = Taupunkt
                      type = num
                      eval_trigger = dg.buero.temp, dg.buero.hum
                      eval = "sh.tools.dewpoint(sh.dg.buero.temp(), sh.dg.buero.hum())"
                      visu = div
                  [[[motion]]]
                      name = Bewegung
                      type = bool
                      visu = toggle
          
          [og]
              name = Obergeschoss
              [[schlafzimmer]]
                  name = Schlafzimmer
                  [[[temperature]]]
                      name = Temperatur
                      type = num
                      visu = slider
              [[ankleide]]
                  name = Ankleide
              [[kinderbad]]
                  name = Kinderbad
              [[elternbad]]
                  name = Elternbad
              [[kind1]]
                  name = Kind 1
              [[kind2]]
                  name = Kind 2
              [[flur]]
                  name = Flur
          
          [eg]
              name = Erdgeschoss
              [[wohnzimmer]]
                  name = Wohnzimmer
                  [[[temperature]]]
                      name = Temperatur
                      type = num
                      visu = slider
              [[kueche]]
                  name = Küche
              [[vorrat]]
                  name = Vorratsraum
              [[abstell]]
                  name = Abstellraum
              [[essen]]
                  name = Essen
              [[eingang]]
                  name = Eingang
              [[garderobe]]
                  name = Garderobe
              [[wc]]
                  name = WC
              [[flur]]
                  name = Flur
          
          [kg]
              name = Keller
              [[hauswirtschaft]]
                  name = Hauswirtschaft
              [[technik]]
                  name = Technik
              [[werkstatt]]
                  name = Werkstatt
                  [[[temperature]]]
                      name = Temperatur
                      type = num
                      visu = slider
          
          [aussen]
              name = Außenbereich
              [[garage]]
                  name = Garage
              [[terasse]]
                  name = Terasse
              [[wetter]]
                  name = Wetter
                  [[[temperature]]]
                      name = Temperatur
                      type = num
                      visu = slider
                  [[[strahlung]]]
                      name = Strahlung
                      type = num
                      visu = slider
          
          [haus]
              [[bewohnt]]
                  type = bool
                  eval = or
                  eval_trigger = marcus.anwesend, frau.anwesend
          
          [marcus]
              name = Marcus
              [[anwesend]]
                  type = bool
                  visu = toggle
              [[urlaub]]
                  type = bool
          
          [frau]
              [[anwesend]]
                  type = bool
          
          [autovisu]
              name = Visu Elemente
              [[text]]
                  value = default text
                  type = str
                  visu = text
              [[textarea]]
                  value = default text area
                  type = str
                  visu = textarea
              [[toggle]]
                  value = True
                  type = bool
                  visu = toggle
              [[slider]]
                  value = 40
                  type = num
                  visu = slider
              [[select]]
                  value = 1
                  type = str
                  visu = select
                  visu_opt = 1, 2, 3
              [[radio]]
                  value = 3
                  type = str
                  visu = radio
                  visu_opt = 1, 2, 3
              [[checkbox]]
                  value = False
                  type = bool
                  visu = checkbox
              [[div]]
                  value = default div
                  type = str
                  visu = div
              [[span]]
                  value = default span
                  type = str
                  visu = span
              [[img]]
                  value = /img/weather/30.png
                  type = str
                  visu = img
              [[dynamic_img]]
                  value = True
                  type = bool
                  visu = img
                  visu_img = /img/off.png, /img/on.png
              [[push]]
                  value = True
                  type = bool
                  visu = push
                  visu_img = /img/on.png, /img/on.png
              [[switch]]
                  value = True
                  type = bool
                  visu = switch
                  visu_img = /img/off.png, /img/on.png
          Und ein KNX-Teil meiner Produktiv-Installation:
          Code:
          [led]
              type = bool
              knx_dpt = 1
              knx_listen = 1/1/4
              knx_send = 1/1/3
              knx_init = 1/1/4
          Verständlich?

          Zitat von 2ndsky Beitrag anzeigen
          Weißt du schon, wann du die 0.7 releasen willst?
          Es ist 'eigentlich' fertig. Ich muss aber noch testen und Dokumentation erstellen. Da ich momentan ein Haus renoviere komm ich aktuell leider nicht so schnell voran. Ich würde mal 1-2 Monate schätzen.
          Zitat von 2ndsky Beitrag anzeigen
          Besteht Interesse an einer Zusammenarbeit oder willst du das alleine pflegen?
          Klar, Ich würde mich über eine Zusammenarbeit sehr freuen.
          Es gibt auch noch einen anderen Entwickler der gerade angefangen hat sich in SH.py einzuarbeiten und sein erstes Plugin geschrieben hat.
          Ich wollte eh mal ein SVN für den Code einrichten. Es würde sich anbieten das mit dem 0.7 Release zu kombinieren bzw. zum Beta-Test.

          Bis bald

          Marcus
          Angehängte Dateien

          Kommentar


            #80
            Wenn das "ernst" und wirklich notwendig (?) ist, versuche ich mal nen Backport.

            Die Frage ist: ist Python >2.5 wirklich notwendig oder nur aus bequemlichkeit/versehen? (Weil man die Abwärtskompatibilität nicht geprüft hat oder so )

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

            Kommentar


              #81
              Hi Marcus,

              Zitat von mknx Beitrag anzeigen
              Freut mich! Es scheint Dir ja echt gefallen zu haben wenn Du das auf Dich nimmst.
              Habe dir ja am Münchner Stammtisch bei makki erzählt, dass ich noch nicht genau weiß wie ich Logiken realisieren soll. Nachdem ich jetzt beruflich ab und an mit Python zu tun habe ist das wesentlich interessanter für mich als Perl. Python ist für mich einfach schlüssiger. Hab mir dann deinen Code angesehen und gefallen daran gefunden

              Zitat von mknx Beitrag anzeigen
              An Nachahmer: Ich würde generell gleich den Schritt zu 2.7 empfehlen. Momentan ist zwar 2.6 ausreichend aber das ist auch schon angezählt. Bei Ubuntu 12.10 wird 3.0 als default installiert.
              Uff, ich dachte halt, weil auf der HP steht, dass es mit 2.6 getestet ist nehme ich auch einfach 2.6. Aber jetzt weiß ich ja wie es geht, da sollte auch 2.7 kein Problem mehr sein

              Zitat von mknx Beitrag anzeigen
              Das verstehe ich nicht ganz. Man kann viele GAs pro Item für unterschiedliche Aufgaben angeben (Init, Listen, Send, Reply..). Wenn aber man unterschiedliche Funktionen steuern möchte braucht man unterschiedliche Items.
              Das habe ich schon verstanden, je Item gebe ich den Typ an und über welche GAs der Wert geschrieben/gelesen etc. wird. Bei einer zweistufigen Hierarchie wie sie in 0.6 noch war, müsste man für eine Jalousie vier Items auf selber Ebene erstellen, also so:

              Code:
              ['wohnen']
                  [['jalousie_langzeit']]
                      type = bool
                      ...
                  [['jalousie_kurzzeit']]
                      type = bool
                      ....
                  [['jalousie_position']]
                      type = num
                      ...
                  [['jalousie_lamelle']]
                      type = num
                      ...
              Schöner wäre (was mit der mehrstufigen Hierarchie möglich sein sollte):

              Code:
              ['wohnen']
                  [['jalousie']]
                      [[['langzeit']]]
                          type = bool
                          ...
                      [[['kurzzeit']]]
                          type = bool
                          ...
                      [[['position']]]
                          type = num
                          ...
                      [[['lamelle']]]
                          type = num
                          ...
              Damit ändert sich der Zugriff von sh.wohnen.jalousie_position() auf sh.wohnen.jalousie.position() was in meinen Augen besser ist. Auch Stockwerke (wie du sie ja in deiner neuen Konfig schon verwendest) sind natürlich sinnvoll für die Struktur.

              Eine andere Möglichkeit wäre, dass man mit abgeleiteten Items arbeitet. Also es gibt die "primitiven" Items, bei denen der Typ angegeben wird wie bisher und zusätzlich gibt es spezielle Items wie z.B. Jalousie und dimmbare Lampen. Denn eine Jalousie hat immer Langzeit-, Kurzzeit-, Position- und Lamellen-GAs. Vorteil hier wäre, man könnte für die Visu gleich Widgets anhand des Typs angeben die dann eben in einem Widget das Dimmen und An/Aus Schalten erlauben.

              Wegen der Unübersichtlichkeit: die Konfiguration ist zwar recht einfach, aber wird doch recht schnell ziemlich lang. Besser wäre, wenn man die Konfigurationsdatei auf mehrere aufteilen könnte (z.B. stockwerksweise), die man in der Hauptdatei lädt, ähnlich wie bei den Logiken.

              Zitat von mknx Beitrag anzeigen
              Es ist 'eigentlich' fertig. Ich muss aber noch testen und Dokumentation erstellen. Da ich momentan ein Haus renoviere komm ich aktuell leider nicht so schnell voran. Ich würde mal 1-2 Monate schätzen.

              Klar, Ich würde mich über eine Zusammenarbeit sehr freuen.
              Es gibt auch noch einen anderen Entwickler der gerade angefangen hat sich in SH.py einzuarbeiten und sein erstes Plugin geschrieben hat.
              Ich wollte eh mal ein SVN für den Code einrichten. Es würde sich anbieten das mit dem 0.7 Release zu kombinieren bzw. zum Beta-Test.
              Eigentlich hast du ja bei SF schon ein Git Repo, nur leider liegt der Code da nicht drin bzw. wenn ich es auschecke bekomm ich einen leeren Ordner. Weil wenn die 0.7 eigentlich fertig ist wäre es doch praktisch, wenn ich mir das gleich ansehe und bei mir teste. Weil ich fange jetzt natürlich nicht an, meine ganze Konfig zweistufig hinzufrickeln um dann auf mehrstufig umzustellen.

              Wenn dir das SVN Einrichten jetzt zu stressig ist, könntest du mir den jetzigen Code vielleicht schnell per Email schicken, dann kann ich wenigstens auf nem aktuellen Stand weiter machen und diffen kann ich es dann immer noch wenn du das Repo dann hast.

              Als Plugin würd ich als erstes was für'n ekey schreiben. Das habe ich bisher auch in Perl und erkennt genau einen meiner Finger. Aber bevor ich das in Perl zusammen frickel damit auch meine Freundin mal keyless eintreten kann, mach ich das lieber in Python wo ich weiß was ich tue (es geht ja auch immerhin um die Eingangstür)

              Beste Grüße
              Niko
              Mit freundlichen Grüßen
              Niko Will

              Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
              - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

              Kommentar


                #82
                Aber sowas von ernst

                Zitat von makki Beitrag anzeigen
                Wenn das "ernst" und wirklich notwendig (?) ist, versuche ich mal nen Backport.
                Danke für das Angebot.

                Zitat von makki Beitrag anzeigen
                Die Frage ist: ist Python >2.5 wirklich notwendig oder nur aus bequemlichkeit/versehen? (Weil man die Abwärtskompatibilität nicht geprüft hat oder so )
                Ich habe damals auf einer aktuellen Maschine mit 2.6 das entwickeln angefangen. Ich konnte ja nicht ahnen das man es zwei Jahre später mit einer noch älteren Version laufen lassen will.
                Es gibt einige Funktionen in 2.6 die das Leben deutlich einfacher machen bzw. den Code wesentlich schlanker werden lassen. Ich glaube ich habe momentan keine 2.7 Funktionen eingebaut, aber ich entwickle (immer noch) auf einer aktuellen Maschine mit 2.7.

                Wie sieht eigentlich der Upgrade-Pfad vom Wiregate aus? Wie lange packt Ihr es noch mit der alten Distri? Stellt doch mal auf Ubuntu LTS um, dann kannst Du Dir das lästige Backporten von ausgefallenen/aktuellen Ports und Sicherheitspatches sparen und hast trotzdem eine Umgebung die von vielen anderen auch getestet/genutzt wird.
                Oder ist das nur aus Bequemlichkeit weil man sich keine Gedanken zum OS-Upgrade gemacht hat )?

                Bis bald

                Marcus

                P.S. ich habe jahrelang für einen Appliance-Hersteller gearbeitet, ich weis was eine OS-Upgrade bedeuten kann.

                Kommentar


                  #83
                  Zitat von mknx Beitrag anzeigen
                  Oder ist das nur aus Bequemlichkeit weil man sich keine Gedanken zum OS-Upgrade gemacht hat )?
                  Eher schon, sonst hätt ich mir meine Distro selbstgestrickt und nicht Debian genommen, ne?

                  Wir geben unseren Kunden nur sehr viel mehr Freiheiten als das üblich ist, das macht ein Dist-Upgrade jedoch ungleich schwieriger..
                  Erschwerend kommt hinzu, das ohnehin 50% der relevanten SW selbstgebacken sind (eibd, linknx, wiregated, owfs, ...) weil upstream nicht oder nur sehr veraltet verfügbar.
                  Solange kein zwingender Bedarf besteht - den ich nicht sehe - mache ich gerne Backports
                  Schau mir das mit py2.6 nochmal an..

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

                  Kommentar


                    #84
                    @Makki
                    Ich denke sinnvoller wäre es die 2.7.3 zu backporten, wenn es die gäbe wäre es schon gut, momentan teste ich auf einem externen Rechner.

                    @mknx
                    Eine beliebig tiefe Hirachie ist ein echter Fortschritt, ein Splitten der Konfiguration bei der Visu würde ich mir auch wünschen. Bei linKNX geht das z.B. auch nicht, was ich als riesen Nachteil empfinde.

                    Kommentar


                      #85
                      Ich hätte natürlich zuerst 2.7 versucht (scheint bis auf ein paar glitches auch zu gehen..)

                      Aber irgendwie erinnert mich die Diskussion gerade stark an
                      Die Woche: Desktops und Birnen | heise open
                      Dem Entwickler ists ja wurscht, ob das mit 2J alter "Plörre" geht, klassischer Fall von SEP
                      Ich stehe mehr auf langzeit&stabil, aktuelles Debian-Stable ist 2.6.6, darüber ist für mich erstmal Pre-Alpha (allerdings egal, weil nichts auf dem WG auf Py basiert..)

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

                      Kommentar


                        #86
                        "2 Jahre alte Plörre" klingt jetzt "gut".
                        Da endete der Support vom Etch, welches 2007 das Licht der Welt erblickte.
                        Die allermeisten Admins haben ihr RZ dann 2009 auf Lenny gezogen...
                        Aber nun. Der Vorteil einer länger verfügbaren Hardwareplattform kommt hier voll zum tragen. Das passt schon.

                        Die SW in der Firma muss auf der aktuellen + den 2 vergangenen Lenovo X/T Generationen laufen. Da ist man schnell bei einigen Komponenten ganz vorn im git dabei...
                        Derzeit zwischen Kistenauspacken und Garten anlegen.
                        Baublog im Profil.

                        Kommentar


                          #87
                          ( ) Du weisst das auf den meisten SoHo-Routern und xDSL-Modems ein Linux 2.4 läuft?
                          ( ) Nicht

                          Makki

                          Edit: Sorry für OT, aber es hat damit zu tun, insofern das SW auch benutzbar sein muss ohne sich mit Expertenwissen anzueignen - mein Credo: es geht auch ohne wenn man eben auf stabile Distributionen setzt..
                          EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                          -> Bitte KEINE PNs!

                          Kommentar


                            #88
                            Ja natürlich weiss ich es. Und es hat in der Tat auch seine Berechtigung. Daher sind dort aber auch nur die wirklich notwendigen Pakete drauf. Und selbst der Kernel besteht dann nur aus den Modulen, die wirklich gebraucht werden. Alles andere fehlt. Der Support ist dann überschaubarer.
                            Wenn man aber das WG als offene Plattform verkauft, mit der man alles machen können soll, ists halt schwierig mit dem Spagat. Ich denke, das ist auch verständlich. Ohne das man das ankreuzen muss...
                            Derzeit zwischen Kistenauspacken und Garten anlegen.
                            Baublog im Profil.

                            Kommentar


                              #89
                              Hallo Marcus,

                              danke für's Zusenden des Codes. Bin gerade noch am drüber schauen bevor ich das die nächsten Tage aufs Wiregate ziehe.

                              Eine Anmerkung hätte ich z.B. schon, auch wenn es nur Schönheitskorrekturen sind. Die Klasse Knot würde ich unbedingt in Node umbenennen, da das einfach gebräuchlicher ist. Ich musste z.B. erstmal in die lib/Knot.py rein um zu sehen, was das sein soll
                              Gibts eigentlich das Beta Forum noch? Weil evtl. könnte die Diskussion hier in Richtungen abdriften, die den normalen User eher nicht interessieren. Wenn ja, könnte mir da jemand Rechte geben?
                              Mit freundlichen Grüßen
                              Niko Will

                              Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
                              - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

                              Kommentar


                                #90
                                Vielleicht versteh ich noch nicht alle Besonderheiten von Python, aber warum rufst du in der Knot.py zweimal add_knot in der smarthome Klasse auf?

                                Code:
                                 65                 smarthome.add_knot(sub_path, False)
                                 66                 sub_knot = Knot(smarthome, self, config[attr], sub_path)
                                 67                 vars(self)[attr] = sub_knot
                                 68                 smarthome.add_knot(sub_path, sub_knot)
                                Weiter rufst du im Falle das "cache" gesetzt ist die _db_read Methode auf:

                                Code:
                                104         if self._cache:
                                105             self._value = self._db_read(self._type)
                                Du übergibst hier den Typ, der Übergabeparameter wird aber in der Methode garnicht verwendet (du greifst immer auf self._type zu):

                                Code:
                                222     def _db_read(self, typ=None):
                                223         try:
                                224             with open(self._sh._cache_dir + self._path, 'r') as f:
                                225                 return cPickle.load(f)
                                226         except IOError, e:
                                227             logger.info("Could not read {0}{1}".format(self._sh._cache_dir, self._path))
                                228             try:
                                229                 return getattr(self, '_return_' + self._type)(0)
                                230             except:
                                231                 return False
                                232         except EOFError, e:
                                233             logger.info("{0}{1} is empty".format(self._sh._cache_dir, self._path))
                                234             try:
                                235                 return getattr(self, '_return_' + self._type)(0)
                                236             except:
                                237                 return False
                                Da du ja nun Tools eingeführt hast, würde ich die fade Methode eher dort hin verschieben. Weil fade macht nur (zumindest sehe ich sonst noch keinen Anwendungsfall) bei Lampen sinn, es aber dann in einen Knoten einzubauen find ich falsch.

                                Des Weiteren finde ich die Verwaltung der Knoten in der Smarthome Klasse für den falschen Platz. Dadurch wird diese unnötig aufgebläht. Ich würde dort nur den root Knoten halten und beim Zugriff über den Pfad diesen anhand des Punktes splitten und dann jeweils über Zugriffsmethoden der Unterknoten den Baum hinabwandern. Dadurch sind die Klassen nicht so eng mit einander verbunden und man tut sich bei einem späteren Refactoring einfacher.

                                Das sind jetzt mal ein paar Anregungen, die mir spontan aufgefallen sind. Wie bereits angeboten würde ich da gerne mitarbeiten, wir brauchen nur einen Platz, wo wir über sowas diskutieren können und natürlich eine Versionsverwaltung (evtl. kannst du mich auch bei SF mit aufnehmen - Username: wu-mc).
                                Mit freundlichen Grüßen
                                Niko Will

                                Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
                                - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

                                Kommentar

                                Lädt...
                                X