Raum in dem alle Eingeschalteten Geräte angezeigt werden

    • in Planung

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Raum in dem alle Eingeschalteten Geräte angezeigt werden

      Hallo agent,

      für die Ver. 3 fände ich es cool, wenn es einen Tab (quasi Raum) gäbe in dem sich alle Schaltelemente die eingeschaltet sind automatisch mit dem einschalten eintragen.

      Dadurch könnte man auf einem Blick sehen was im Haus noch "An" ist.

      Wird ein Schaltelement ausgeschalten, wird es in dem (quasi Raum) wieder gelöscht.

      Ich hoffe Du verstehst was ich meine. Quasi eine Status Page für eingeschaltete Schaltelemente.
      SHC Master B2+ WLAN sowie 1 Slave B2+, 2 Slave B+ und 2 Slave Raspi B. 5x Pi Cam; Imac mit OSX El Capitan; Iphone 6 plus; Ipad mini; Lenovo Android Tablet.
    • In dieser Hinsicht gebt es viele verschiedene Befürfnisse. Wenn ich allein mal von mir ausgehe, dann würde ich sogar noch gerne weitere, anpassbare "Filter" habe wollen. z.B. einen Raum mit allen Temperaturfühler > X°. Oder bei Fensterkontakten nur die Fenster, die offen sind.
      Und ein anderer hat sicherlich wieder ganz andere Ideen. Das hängt letztlich davon, wofür und wie intensiv man das SHC einsetzt.

      Da das SHC in der V3 ja von Grund auf neu programmiert wird, und das ganze in Java passiert, könnte man in dem Zuge vielleicht auch über eine PlugIn-Schnittstelle nachdenken. So was könnte den Aufwand, den Oliver jedes Mal hat wenn einer die nächste Idee hat, um ein wesentliches reduzieren, so dass er sich verstärkt um die Kernfunktionen kümmern könnte.

      Und im Zuge der V3 wird möglicherweise die JSON-Schnittstelle für App's ja auch noch ein wenig aufgebohrt, was dann in dem Bereich auch wieder neue Möglichkeiten der Darstellung und Steuerung ermöglicht.

      Die Idee finde ich jedenfalls vom Thema her sehr gut.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • Das wäre wenn dann etwas zum Nachrüsten. Direkt in Version 3 wird das erst einmal nicht einfließen.
      Wobei das dann auch schon wieder sehr Speziell wird.

      @DieterWo
      Was die Pluginschnittstelle angeht, ist da so eine Sache. Eine solche Schnittstelle ist machbar, beim Server als auch den Clients. Allerdings erfordert das sehr viel Arbeit, zum einem beim Programmieren, aber auch beim Dokumentieren.
      Bis jetzt musste ich immer die Erfahrung machen das diese dann nicht genutzt wurden und der Aufwand dafür ins nichts verlaufen ist. Für Version 3 würde das auch bedeuten das Plugins selbst auch in Java geschrieben sind, was wahrscheinlich den nutzerkreis auch auf sehr wenige beschränkt.
    • Du hast natürlich recht, wenn du erst einmal die z.Zt. vorhandenen Funktionen in V3 umzusetzen. Da ich kein Java-Entwickler bin, und mich mit Java erst einmal auseinandersetzen müsste, kann über den Umfang, den eine solche Erweiterung gleich bei der Neuentwicklung mit sich bring, nicht wirklich was sagen.

      Was eine Plugin-Schnittstelle angeht, so hängt davon ab, wie so eine Schnittstelle implementiert ist. Man kann das auch so gestallten, dass es unabhängig von verwendeten Sprache ist. Ich hätte da auch schon einige Ideen, aber das würde den Rahmen hier sprengen, dass jetzt alles hier reinzuschreiben. Aber natürlich ist es für so was auch noch zu früh. Erst mal muss die Version 3 soweit fertig sein. Von daher, warten wir ab.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.
    • Ja, man kann auch Schnittstellen für andere Sprache erstellen, dafür wird der Aufwand aber noch größer und die Anwendung im schlimmsten Fall auch langsamer.

      Ich werde jetzt dieser Tage auch schon mit der Desktop App anfangen. Eigentlich wollte ich erst noch ein paar Module vom App Server programmieren, aber das wird auf dauer langweilig. Außerdim ist ja etwas richtig sichtbares immer besser.
    • Ja, wenn dann die Abfragen und JSON's dann stur nur die Hierarchie des SHC abbilden, lassen sich solche Probleme, wie "Zeig mir alle offenen Fenster" auch den Client regeln.
      Zur Verdeutlichung wie ich das meine: z.Zt. kann ich ja nur die Räume abfrage, und dann die Elemente eine bestimmten Raums. Wenn ich jetzt alle offenen Fenster haben will, muss ich mir also erst die Räume holen und anschließen alle Elemente jedes Raums und aus der Gesamtliste dann eben alle Offenen Fenster zu finden.
      Wenn ich aber z.B. über die HTTPS-Abfrage alles bekommen, aber optional in der gleichen Abfrage auch Kriterien setzen könnte, dann hätte schon alles, was man braucht.
      z.B. index.php?app=shc&a -> Liefert wirklich alles als JSON zurück
      index.php?app=shc&a&element=sensor -> liefert nur Sensordaten als JSON
      index.php?app=shc&a&room=5 -> liefert alle Elemente von Raum-Id 5
      index.php?app=shc&a&room=5&element=sensor -> liefert alle Sensoren von Raum 5

      Ist nur ein simples Beispiel. Aber was ich damit meine sollte jetzt rüber kommen.

      Ich will darauf hinaus, ob du (Oliver) über diese Schnittstelle die Grenzen der Gestaltung festlegen möchtest, oder ob du eben wirklich alles offen lässt, so dass die Grenzen über die App/Client festgelegt werden können. Wenn alles offen ist, dann könnten z.B. auch Bedingungen über eine App verändert werden.
      Gruß Dieter
      --------------
      Alle sagten: "Das geht nicht.". Dann kam einer, der wusste das nicht, und hat's einfach gemacht.