Der Zusammenhang „ohne Abfrageintervall kein Gerät nicht in der HG Auswahl“ hat mich etwas verwirrt. Ich hätte die Geräte immer im HG erwartet.
Denn gerade Aktionen/Aktivitäten wie „wird geschlossen“ sind doch eher reiner Zufall, wenn diese durch ein Abfrageintervall erfallst werden. Verlässlich werden solche Zustandsänderung ja nur bei Aktionen (und damit einhergehend impliziter Statusabfrage) erkannt, die über homee getriggert wurden. und genau solche sind ja vollkommen unabhängig von der zyklischen Abfrage.
Aber wie man das alles einfach im UI dem User vermitteln kann, stellt mich auch vor ein Rätsel.
Wäre es machbar, „Abfragen“ als manuelle HG-Aktion zur Verfügung zu stellen?
So könnte man gezielt den Status abfragen, um den Zustand zu prüfen.
Usern mit vielen Geräten geht sonst eventuell der Duty Cycle zu hoch, wenn zyklisch abgefragt wird. Da spart gezieltes Abfragen.
zumindest in der Webapp sind für den Torantrieb falsche/doppelte/sinnlose Auslöser und Bedingungen.
Das sollte Mal konsolidiert und eingedampft werden.
Die Bedingungen machen alle so Sinn, auch wenn man diese nicht unbedingt häufig braucht aber mir würde durchaus für jede Bedingung ein Anwendungsfall einfallen…
stimmt. da hast du Recht. theoretisch passen die alle.
Bei Bedingungen erwarte ich eigentlich nur Zustände und keine Vorgänge.
Aber hier tickt Hörmann eben anders wie Z-Wave und Co. Da ist man anderes gewohnt.
Das Mehr an Auswahl bei Hörmann geliefert am Ende des Tages weniger Funktionalität als beispielsweise ein Z-Wave roller shutter ab.
das verwirrt vielleicht mehr als dass es hilft.
Auf der anderen Seite bin ich natürlich auch kein Freund von Bevormundung und „kastrierten“ Geräten.
Ich benutze die Vorgänge bei den Bedingungen, ich habe aber auch kein Hörmann
Auslöser Balkontüre wird geöffnet, wenn Raffstore schließt, dann Raffstore stoppen und Raffstore öffnen.
Ich lerne ja gerne was dazu.
d.h. während der Raffstore runter fährt, reißt du die Tür auf, um den Vorgang abzubrechen. Wenn der Raffstore aber unten ist, bleibt er auch nach dem Türöffner zu. korrekt?
ok, da mag dieser temporäre Zustand vielleicht Sinn ergeben.
Wenn im mir aber überlege, dass du dein Homeegramm auf ein Garagentor überträgst.
Entweder homee bekommt noch gar nicht mit, dass sich das Tor bewegt hat, und das HG (mit welchem Auslöser auch immer) wird nicht ausgeführt
oder homee hat während der Fahrt den Zustand aktualisiert und öffnet das Tor wieder, obwohl es bereits seit einer Minute geschlossen war.
@Stefan00
werden die falschen Auslöser aufgenommen und korrigiert?
die Auslöser scheinen nicht doppelt zu sein, sondern nur falsch benannt.
Das eine beschreibt z.b. den Endzustand „offen“, wenn sich nix mehr bewegt. das andere den Zustand „öffnet“, während das Tor sich noch bewegt.
Das offene Garagentor durch den Auslöser sehr gut erkannt und gemeldet. Der Öffnungsvorgang erwartungsgemäß aber nie, insofern das Tor nicht über homee bewegt wird.
Bitte korrigiert mich wenn ich falsch liege, aber die Auslöser machen bei dem zyklischen Abfrageintervall doch nur bedingt Sinn, oder?
Ich mach mein Garagentor mit meinem Handsender (direkt ans Tor angelernt) oder dem Schalter (direkt am Tor verdrahtet) auf - wenn nicht zufällig homee genau in dem Zeitraum wo das Tor hoch oder herunter fährt die Statusaktualisierung macht, wird das homeegramm doch gar nicht ausgelöst, da mein Tor keine 1 Minute zum Verfahren braucht? Aus homee Sicht hat das Tor ja dann auf einmal einfach nur einen neuen Zustand (auf/zu/teiloffen). Vielleicht würde es besser funktionieren, wenn der Handsender auch über den Würfel ginge, das reduziert aber bestimmt meine Handsender-Reichweite vor der Garage (Vermutung - noch nicht getestet).
Sinnvoller wäre sowas wie Status hat sich geändert von Zu auf Offen oder so, oder?
Zumindest hab ich mal probiert mit den „wird geöffnet“ oder „wird geschlossen“ Auslösebedingungen zu arbeiten und das hat nicht zuverlässig funktioniert.
Ich wollte mir einen Trigger bauen der mir eine Push-Benachrichtigung schickt, wenn das Tor länger als 5 Minuten auf ist.
Ich habs noch nicht ganz geschafft aber ich arbeite aktuell halt als Workaround mit einem Homeegramm, welches jede 1 Minute ausgeführt wird und den Zustand des Tors auf „nicht geschlossen“ (oder was auch immer man überwachen will) prüft. Zusätzlich ist beim Tor Abrufintervall 1 Minute eingestellt. Hat nen 15% Duty Level bei mir pro Stunde.
Nur das mit „erst nach 5 Mins ne Push schicken“ hab ich nicht nicht hinbekommen
P.s: nichtsdestotrotz auf jeden Fall schon mal 100000x besser als die Originalimplementierung. Damit kann man schon arbeiten, würde ich sagen, auch wenn noch Luft nach oben besteht
das scheint in der Tat zu funktionieren! Selbst wenn das Tor irgendwann zwischen den beiden Abfragezyklen bewegt wurde. Evtl. wurde da ja doch was clevereres implementiert
Vielen Dank!
edit: und wenn ich einfach mal deinen Beitrag ganz oben gelesen hätte hast du die gleiche Frage auch schon gestellt. Mea culpa!
@Steffen
könnt ihr die Texte anpassen? Das verbale Umformen von Zuständen und Vorgängen ist absolut kontraproduktiv, wenn das Gerät selbst schon einen Messwert mitbringt, der sich „Zustand“ schimpft und sowohl Zustände als auch Aktivitäten als Werte zurückliefert.
verständlicher, wenn auch nicht "schon, wäre es, wenn sich sowohl HG Auslöser als auch Bedingungen sich 1:1 an die Bezeichnung des Messwerts hält
Bitte nicht immer für jedes Gerät eigene Geräteprofile einführen Dann braucht es noch mehr HG’s um festzustellen, ob im Haus, Fenster, Haustüre, Rollläden und Garagentor geschlossen sind.
Das ist nämlich jetzt schon so, weil es eine Geräteprofile für Fenstersensoren mit Und ohne Kippstellung gibt. Voll nervig.
@Support bitte um Feedback.
könnt ihr bei den Zuständen im/fürs Homeegramm was tun?
Mit den aktuellen Bezeichnungen ist es nicht möglich, sicher ein funktionieres HG zu erstellen, ohne vorab mit Trial & Error alle möglichen Auslöser und Bedingungen durchzutesten, um deren wahre Bedeutung zu verstehen.
