ich habe mich kürzlich entschieden, den Antrieb meines Schiebetors aufzurüsten, Hauptziel war, sicher sein zu können, dass das Tor geöffnet oder geschlossen ist, wenn ich das will. Vorgestellt hatte ich mir ein Homeegramm, dass z.B. abends den Status prüft und ggf. das Tor schliesst oder, falls der Status nicht zuverlässig zu ermitteln ist, einfach abends den Befehl zum Schliessen sendet.
Ich habe mir einen Lineamatic P Antrieb gekauft, verbaut und an Homee angelernt. Dabei wurden alle Befehle einzeln programmiert (Öffnen, Schliessen, Teilöffnung, Impuls) und funktionieren auch mit Hilfe der Buttons im Homee UI. Allerdings fehlen mir zwei wichtige Dinge.
der Status des Tors kann nicht als Bedingung in Homeegrammen verwendet werden.
(viel schlimmer) anscheinend ist der einzige Befehl, den man per HG ausführen kann, der Impuls
Das heisst, ich habe zwar Homee das Senden der Befehle Öffnen und Schliessen antrainiert, aber im Homeegramm kann ich nur den Impuls senden und HOFFEN, dass das Tor das tut, was ich will. Dann hätte ich jedes No-Name Tor kaufen können!
Ich habe hier in der Community nachgelesen und bin etwas erschreckt, in welchem Stadium sich der Hörmann-Cube offenbar befindet. Aber ich möchte hier nicht die ganzen anderen Themen noch einmal wiederholen. Für mich geht es um eine ganz simple Frage: wie kann ich einen Befehl, den ich in Homee per Klick im Web problemlos auslösen kann, auch im HG verwenden?
Ich hoffe, @Hoermann_KG_AST, das Homee-Team oder die Community kann mir hier den entscheidenen Tipp geben, der für mich den Unterschied zwischen einer Lösung und einer absoluten Fehlinvestition macht.
Wenn Öffnen/Schließen per App funktioniert, sollte/müsste es auch per HG funktionieren.
Das sieht mir in dem Fall nicht nach einer Unzulänglichkeit des Cubes oder beabsichtigten Beschränkung aus, sondern einem Software-Bug.
Stehen mehr Aktionen zur Verfügung, wenn du das Gerät in eine Gruppe packst und darüber ins HG einbindest?
Hast du das Gerät Mal ohne Impuls-Befehl eingelernt?
Scheint so als wäre es ein Bug oder sogar Benutzerfehler und kein fehlendes Feature, das wäre super, denn besonders letzteres müsste schneller zu beheben sein!
Also teile ich mal mehr Details, damit die Sache hoffentlich aufgeklärt werden kann…
Problem 1 (doof, aber nicht ganz so dramatisch)
Wenn ich versuche auf irgendwelche Events vom Tor per HG zu reagieren, muss ich feststellen. dass das Tor in der Liste der Events (Im „Wenn“-Abschnitt des HG) überhaupt nicht auftaucht. Daher kann ich das Tor und jegliche Statusänderung auch nicht als Trigger verwenden. Habe ja verstanden, dass externe (nicht-Homee-verbundende) Fernbedienungen nicht unterstützt sind. Das ist ein Gap, wird aber in einem anderen Thread behandelt. Aber wenn ich mit Homee den Status des Tores ändere, wird der neue Status auch im Web angezeigt, warum kann ich dann nicht per HG darauf reagieren?
Problem 2 (wirklich ein großes Problem für mich und Unterschied zwischen Fehlinvestition oder nicht)
Ich wollte ein HG schreiben, wo ich bei Drücken eines Buttons einer Fernbedienung das Tor zu fahren lasse und bei einem anderen Buotton auf. Später sollten HGe folgen, wo z.B. Abends das Tor zugefahren wird, egal ob es offen ist oder nicht. Für all diese Szenarien eignet sich ein „Impuls“ in keiner Weise. Leider taucht (neben Licht) nur „Impuls“ und Teilöffnung (Impuls) auf. Es fehlen die wichtigen Befehle „Fahre auf“ und „Fahre zu“:
Und was ist, wenn du auf Zustand klickst, kommt da nicht noch ein Untermenü hinter?
Ich kann mir vorstellen, dass du dann auswählen kannst, ob du auf- oder zufahren möchtest.
Tatsächlich handelt es sich hier um ein Layer 8 Problem (und sagen wir mal immerhin zum Teil provoziert durch ein wenig intuitives UI).
Der Befehl Teilöffnung ist zwar auf oberster Ebene zu finden, die Befehle für Öffnen und Schließen existieren, aber sind unter den Untermenüs zu finden.
Problem 1 konnte ich damit nicht lösen (der Status des Tors taucht nicht als Bedingung für HG auf), aber dafür kann ich derzeit (unschöne, aber funktionierende) Workarounds finden.
Der Fall kann damit geschlossen werden, muß ich das irgendwie hier entsprechend markieren?
Ist das dein Ernst ?
homee’s UI ist doch sehr bedienerfreundlich und übersichtlich. Sicherlich etwas angestaubt langsam aber trotzdem leicht und intuitiv zu bedienen.
Ja, das sehe ich so. Das heikle an Benutzerfreundlichkeit ist natürlich, daß man 5 Leute fragen kann und 7 verschiedene Meinungen bekommt. Daher gebe ich dir insofern Recht, daß es nicht richtig ist zu sagen, die UI von Homee ist generell nicht benutzerfreundlich. Ich finde sie übrigens an vielen Stellen ziemlich gut.
Daher formuliere ich anders:
ICH PERSÖNLICH FINDE, daß es nicht intuitiv ist, wenn ein Tor 4 Fahrbefehle unterstützt und ich 2 davon auf oberster Menüebene anzeige und die anderen beiden auf 2 Ebenen tiefer im Menü platziere.
wenn gleich ich das „Problem“ in diesem Fall vollständig auf der Seite vor dem Bildschirm sehe, kann homees UX natürlich maßgeblich zur Vermeidung solcher „Layer 8“ Fehler beitragen.
Hier wirkt die imo „berechtige“ (konstruktive) Kritik, eher wie der Versuch eine Teilschuld vom persönlichen Versagen auf homee abzuwälzen. … ist nicht böse gemeint.
Und auch wenn homee schon recht nutzerfreundlich ist, gibt’s es dennoch einiges an Verbesserungspotenzial.
Daher würde ich das ganze auch nicht auf eine persönliche Empfindung reduzieren.
Auch an dieser Stelle geht’s einfacher/intuitiver auch, wenn das Jammern auf sehr hohem Niveau sein mag.
Warum gibt’s verschiedene Ebenen? Warum sind nicht alle Aktionen auf der gleichen Ebene? Warum sind, gerade wenn’s der Übersicht nicht schadet, nicht alle Aktionen direkt unter dem Gerät angesiedelt?
Wenn es verschiedene Ebenen gibt, warum heben sich Aktionen und „Unterordner“ nicht optisch von einander ab?
Wie kann es bei Aktion überhaupt „Zustand“ geben? Das passt semantisch überhaupt nicht zusammen.
so… genug OT. dein Problem ist ja gelöst. ich klink mich aus. will hier keine Diskussionen starten.
