Homee kanns aber Homey nicht?

Und das ist auch gut so! :+1:t3:

Hi @DirkG @Baschtl @Undertaker

24 Stunden Erfahrung mit Homey!

Erst Mal muss ich euch sagen, dass ich es Spitze findet, dass Ihr mir Fragen beantwortet. Und die Bazooka hat was :wink: Aber brauche ich ja nicht, weil ich “die ganze Strasse mit Zwave-Mesh zuverlĂ€ssig” versorgen kann, das habe ich noch nicht ausprobiert.

Mein erstes Fazit Homey vs Homee:

  • Ja, ist schon ein Unterschied wie tag und Nacht. Klar, wenn das Smarthome ĂŒber eine gewisse Anzahl GerĂ€te und WĂŒnsche wĂ€chst ist Homey viel besser - und auch cooler. Aber fĂŒr Kleinanwender, die sich mit Logiken weniger auskennen reicht Homee völlig und hat durch eine einfachere Sprache in Homeegrammen auch Vorteile. Homee kann also viel weniger, aber wenns lĂ€uft, dann lĂ€ufts, und hier ist eben die SchwĂ€che von Homey etwas grĂ¶ĂŸer:
  • In der Tat erkennt man auch bei Homey ein Problem, wenn neue GerĂ€te einer vorhandenen App auf den Markt kommen: Begrenzte ProgrammierkapazitĂ€ten und auch gerne mal lieblose Integration, geschockt hat mich das, als es um Premium-Produkte von Athom ging (also die sie selber pflegen)
  • Beispiel: Die Fibaro-Integration ist teils Buggy (Roller Shutter liefern Stati nicht zuverlĂ€ssig zurĂŒck, obwohl es dafĂŒr Karten gibt. Die Community beschwert sich schon seit 1 Jahr, nix passiert. Bei der Fibaro Walli Serie verzichtet man gleich ganz auf die HĂ€lfte (!) der möglichen und coolen Karten. Das ist ganz schön lieblos. Schade!
  • Meckermecker, aber immerhin gibt es dann Workarrounds, was Homee nicht kann, aber zeigt, dass man eben mehr Suchen, Zeit und Grips braucht. Am Ende lĂ€uft der eigene Workarround.
  • Am Ende bleibt der coole Athom-Move: Es gibt bei Homey viel mehr coolen Stuff durch leidenschaftliche Community-Programmierer wie Euch und ĂŒberall im Homey-Universum. Das hat Vor- und Nachteile, zum Beispiel weiss man nie, wie lange eine Community-App aktualisiert wird, wenn sich der Betriebssystemstand Ă€ndert, und davor habe ich schon etwas Angst. Aber das ist natĂŒrlich Meckern auf höchstem Niveau, Abgehakt. :wink:
  • Ich hab zum letzten Mal Spiele auf dem C64 programmiert, also vor 100 Jahren. Logiken kann ich, und das braucht es auch, wenn man Homey nutzen möchte. Aber meiner Familie will ich nicht antuen, dauernd im Keller rumzuprogrammieren und tiefer einzusteigen, daher auch kein Home Assist.

Mein Smarthome soll laufen, ohne dass ich dauernd dauernd dauernd Fehler suchen muss. Mein Frau soll die App bedienen können und sie cool finden. Mal schauen, ob das bei Homey funktioniert, das immerhin lief bei Homee doch recht gut. :slight_smile:

In jedem Fall fand ich Eure Reaktionen geil, trotz des provokanten Titels :innocent: Danke!

Stefan

2 Likes

Kurzes Feedback zu den genannten Fibaro GerÀten.

Fibaro Roller Shutter 2: Meine RS2 laufen zuverlĂ€ssig und geben auch zuverlĂ€ssig den Status zurĂŒck. ABER, diese habe ich irgendwann 2019 inkludiert und seitdem nicht mehr angefasst, spĂ€ter mehr dazu.

Fibaro Walli Serie: Das ist leider wahr was das Fehlen von Funktion wie z.B. Scene Activation betrifft. Und wie Du schon sagst handelt es sich bei Fibaro definitiv um eine Premiummarke die von Athom selber gepflegt wird. Das ist ein absolutes NoGo! Deshalb gehe ich denen auch regelmĂ€ĂŸig auf den Keks und schreibe denen eine Email.
Stattdessen werden der Sonos App, definitiv auch eine Premiummarke, ein paar lieblose Sounds spendiert und das obwohl es mehrere Wege gibt eigene Sounds auf den Sonos abspielen zu lassen. Und weil das so toll ist machen die sogar ein Video davon. (Ironie off).

ZurĂŒck zu den RS2. Wie Athom selber grade erst zugegeben hat (siehe diesen Thread dazu), haben sie frĂŒher bei der Programmierung der FW und der Apps scheinbar geschlammt. Zwar hat vielleicht vieles funktioniert, aber vermutlich u.A. mit falschen BefehlssĂ€tzen, Capabilities oder was auch immer.
Meine Theorie dazu ist, dass Athom jetzt versucht nach und nach die Fehler auszumerzen, dadurch aber teilweise neue Probleme verursacht werden (siehe z.B. dieser Thread). Außerdem wird man je nach Änderung der FW/App die GerĂ€te neu includieren mĂŒssen, was zugegebenermaßen nicht wirklich anwenderfreundlich ist.
Meiner Meinung nach ist aber das grĂ¶ĂŸte Problem, dass Athom solche Sachen nicht/kaum kommuniziert.

Sollten Dir Probleme und Fehler insbesondere von Hardwarekomponenten auffallen, kann ich nur empfehlen Dich an Athom zu wenden. Bei Problemen mit Flows sitzt das Problem meistens vorm Bildschirm
 :wink:

Ich hoffe Du fĂŒhlst Dich jetzt nicht verarscht weil ich Dir das auch schon frĂŒher hĂ€tte sagen können.
Wie Du an den Threads aber erkennen kannst sind das fĂŒr mich auch neue Erkenntnisse worauf ich meine Theorie stĂŒtze.

Das liegt dann aber wieder am App-Entwickler. In der App kann man die GerĂ€te prĂŒfen, alte Capabilities löschen und neue ergĂ€nzen. Dann mĂŒssen die GerĂ€te nicht neu eingebunden werden. Diese AbwĂ€rtskompatibilitĂ€t bzw. Device-Aktualisierung muss aber im Code so vorgesehen sein. Kann man auch ĂŒber das “Wartungs-MenĂŒâ€ machen wie kĂŒrzlich bei der Nuki-App.

Alles wird gut.
Ich hab mich schon frĂŒher ĂŒber Fibaro geĂ€rgert.
Ich sag nur Tramper Alarm, den kein Mensch braucht.
Nach und nach hab ich alles aus Polen auslaufen lassen und bis auf Hand voll, die einfach nicht kaputt gehen wollen, bin ich Fibaro clean.
Meine Lieblinge sind Shelly und Neo Coolcam geworden. Das Zeug funktioniert einfach und ist zudem noch preiswerter wie Fibaro.
Ich sag ja immer, die Forum Programmierer haben oft mehr drauf, als die Jungs von Athom. Selbst wenn mal einer keinen Bock mehr hat, findet sich meist ein Nachfolger, der das Projekt weiter fĂŒhrt.
Bisher konnte ich bei Homey noch nichts in die Tonne werfen, weil die App nicht mehr weiterentwickelt wurde.
Die App Entwicklung durch Community Mitglieder birgt aber immer das Risiko, dass der Support eingestellt wird. Andererseits ist dadurch eine Vielfalt entstanden, die seinesgleichen sucht.

Warte es mal ab, du wirst dich auch noch mit Home Assistant beschĂ€ftigen. Ich programmiere da auch nichts, oder mache Automatisierungen. Aber als Zuspieler fĂŒr exotische Sensoren oder Funktionen ist HA genial. Zum Beispiel funktionieren Hoppe Enocean Fenstergriffe perfekt. HA stellt die Dinger lediglich per MQTT, Homey zur VerfĂŒgung und den Rest der Automatisierung macht Homey. Das funktioniert ĂŒbrigens auch in Echtzeit. Egal ob FĂŒllstĂ€nde von Drucker-Kartuschen, Unwetterwarnungen oder Dashboards de Luxe , HA macht das und somit auch Homey.
Wie gesagt, lass es langsam angehen, sonst bekommst du Gehirntrombosen. Die Flows sind eigentlich nie fertig. Je mehr du in der Materie drin bist, umso umfangreicher werden die Automatisierungen. Mir geht es beispielsweise genauso wie @DirkG. Da gibt es so viele Variablen, die teilweise sogar Berechnungen machen, dass ich keine Ahnung mehr habe, ob sie ĂŒberhaupt noch verwendet werden :rofl::rofl::rofl::rofl::shushing_face::shushing_face::man_shrugging:

Keine Ausreden :grin:

Bist Du Dir sicher das das auch fĂŒr Z-Wave GerĂ€te gilt? Nuki ist per API eingebunden, ich gehe mal davon aus das man das nicht vergleichen kann.
Bei den Sensative Strips (Z-Wave) gibt’s zwar auch ein “Wartungs-MenĂŒâ€, aber damit kann man nur einen Tamper-Alarm resetten.
Zuletzt wurden fĂŒr die Aeotec Smart Switch 6 die Capabilities “Volt” und “Ampere” per App-Update zugefĂŒgt. Die konnten aber nur per neuer Inklusion hinzugefĂŒgt werden.

Was die Sensoren von Fibaro angeht gebe ich Dir recht @Undertaker, nicht umsonst nutze ich auch NEO Coolcam PIRs und Sensative Strip Guards. :wink:
Mit den Aktoren von Fibaro hatte ich bisher aber grundsĂ€tzlich noch nie Probleme. Wenn es Probleme gibt dann sind diese durch Athom verschuldet. Ähnliche Probleme scheint es ĂŒbrigens mit Qubino zu geben. 3x darfst Du raten wer der Appentwickler ist
 :wink:

Wisst Ihr eigentlich, warum der Chronograph keine Tags zur VerfĂŒgung stellt (“Timer starten oder resetten”)? Ist es korrekt, dass man sozusagen immer Coppy Paste machen muss (und es sich merken muss), wo der Cronograph eingesetzt wurde? :wink:

Ja, ich weiß !
Ich hab nur noch keine Zeit dafĂŒr gehabt !
Schande ĂŒber mich !

Gute Frage ! :man_shrugging: Frag doch mal den App Entwickler.

1 Like

Im Prinzip ja. Man muss den Timername immer angeben.
Der Timer wird bei Start per Flow-Aktion ĂŒber den Name angelegt. Bei allen weiteren Aktionen muss der Name ebenfalls angegeben werden.

Es gibt auch ein Skript, um die Verwendung der Timer zu finden. Verwendung in my.homey.app unter ‘Homeyscript’.

Ja, ich meinte die Capabilities der Homey-GerÀte, also die Eigenschaften, die man nach einem langen Klick auf das GerÀt sieht.
Wenn man als Entwickler neue Attribute ergÀnzt, dann werden bestehende GerÀte nicht automatisch ergÀnzt.
Das kann man aber programmieren (prĂŒfen und einfĂŒgen, wenn nicht vorhanden). So kann man vorhandenen GerĂ€ten neue Attribute hinzufĂŒgen.
FrĂŒher musste man die GerĂ€te entfernen und neu einbinden.

Es sind noch andere Timer im App Store erhĂ€ltlich, bei denen man die Namen in der App hinterlegt und dann bei den entsprechenden Karten aus einer Liste auswĂ€hlen kann. Ein Vertippen ist somit nicht möglich, ich meine u.A. ist das bei der CountDown App so. Allerdings bieten die anderen Apps nicht so viele Möglichkeiten an. DafĂŒr kann man mit einer App, ich weiß momentan leider nicht mehr welche es ist, fĂŒr einen ĂŒblichen Licht-Flow (1. Flow: Bewegung → Licht an → Timer an | 2. Flow: Timer abgelaufen → Licht aus) sich den 2. Flow sparen Diese App hat eine Dann-Aktionskarte „Timer abgelaufen dann Schalte Licht/GerĂ€t aus“.

Bzgl. der Chronograph App sollte es theoretisch möglich sein vorher erstellte Text-Variablen als Tags zu nutzen.

1 Like

TatsÀchlich das geht, Danke!

aber mal wieder zurĂŒck zum Thema des Threads, 60 Stunden sind rum :wink:

Fibaro Aktoren lassen sich ohne Ausbau excludieren und im Homey Inkludieren, cool.

Was vermisse ich? Mehrere Trigger beim Flow-Start kann man verkraften, ABER: Eine “und”-Bedingungen, die erst beim “Dann”-AusfĂŒhren abgefragt wird (ggf auch nach Zeitkonstanten), fehlt mir am Tag 3 doch immer noch sehr. Damit lassen sich so schöne AblĂ€ufe im Homee machen, die Workarrounds in Homey sind doch bei sowas eher aufwendig und nicht in einem Flow abzubilden, was ja echt unnötig ist. Wie ist Euer Workaround?

Danke an @Undertaker, ich habe mir ein paar Shelly Spielzeuge gekauft und bin gespannt. Ich bin etwas misstrauisch, da ich nicht weiss, wie viel zusĂ€tzliche Strahlung sie erzeugen, wenn sie im Standby sind, das ist bei Zigbee oder Zwave natĂŒrlich besser. Man muss ja nicht alles ohne Not zuballern, wenns nicht sein muss, aber dazu gibts nix zu finden.

Variablen sind halt schon toll, Das ZWAVE ist deutlich stabiler bei Homey, heilt besser, wenn eine Route nicht passt. Bei Zigbee fehlt die Option leider.

Was vollkommen klar ist, dass die Entscheidung Homey komplett richtig ist.

1 Like

Homey soll ja auch ein Smarthome-System fĂŒr alle Nutzer sein. DafĂŒr ist die HomeyApp ausgelegt. Das ist eine Mischung aus Funktionsumfang (Apps) und einfacher Bedienung (etwas eingeschrĂ€nkte Logik).

Wenn du komplizierte Logiken gewohnt bist (klingt so) und keine Angst vor JavaScript hast, dann kannst du die komplexeren PrĂŒfungen als HomeyScript basteln und im Flow als EINE Bedingung verwenden (incl. RĂŒckgabe von Tags/Werten). Vielleicht ist das ja eine Option fĂŒr dich.

Da ich kein homee GeschÀdigter bin :stuck_out_tongue_winking_eye: kann ich Dir nicht ganz folgen. Kannst Du mal ein Beispiel nennen?

Das stimmt nicht. In Developer → Tools → Zigbee kann man die einzelnen GerĂ€te per Interview heilen bzw. eine bessere Route suchen lassen. NatĂŒrlich mĂŒssen EndgerĂ€te (batteriebetrieben GerĂ€te) vorher aufgeweckt werden. Das gesamte Zigbee Netzwerk (nur Router wg. der Thematik mit dem Aufwecken) lĂ€sst sich mittels des gedrehten Pfeils in der rechten oberen Ecke optimieren.
Durch einen Homey Neustart oder PTP ordnen sich die Netzwerke (Z-Wave & Zigbee) auch neu. PTP wirkt manchmal Wunder, belastet durch das abrupte Unterbrechen der Stromversorgung aber vermutlich etwas die Hardware.

:+1:t3:

1 Like

:grinning_face_with_smiling_eyes:
Naja, ich finde in der Logik Praktisch, innerhalb eines Flows bei jedem Auslösen zu prĂŒfen, ob eine Bedinung noch gilt. Beispielsweise die Garage nur dann nach 10 Minuten zugeht, wenn sowohl zum x-beliebigen Startauslöser als auch nach 10 Minuten eine Bedingung erfĂŒllt ist und im selben Flow noch nach 12 Minuten das Licht ausgemacht wird, aber ebenfalls nur wenn die Bedingung noch gilt. Aber ich habs jetzt mit zwei Flows und Variablen gelöst, geht ja auch.

In der Summe ist eine Else-VerknĂŒpfung wichtiger, das spart viel mehr Flows im Alltag.

Die Zeitversetzten Aktionen (Bereich “Dann
”) und nochmaliger ÜberprĂŒfung von Bedingungen, bekommt man meines Wissens nur mit 2 “normalen” Flows hin. Das “Licht aus” kann durch eine Verzögerung erreicht werden, das ist ja keine kritische Aktion wie z.B. das Schließen des Garagentores (Verletzungsgefahr).
Ich bin mir allerdings ziemlich sicher, dass es mit der H.O.O.P. App auch in einem Flow machbar ist.
In diesem Thread hat Peter ein kleines Video dazu eingestellt, vielleicht ist es ja ganz hilfreich. Ansonsten gibt’s noch mehrere Threads mit ErklĂ€rungen und Beispielen zu dieser App.

Bin mir jetzt nicht sicher, ob das eine Feststellung oder der Wunsch nach einer Else-VerknĂŒpfung ist, und fĂŒr welchen Flow Bereich (Und/Dann).
Mit H.O.O.P. sind im Bereich “Und
” Else-VerknĂŒpfungen möglich, im Bereich “Dann
” ja von Haus aus.

1 Like

Ich hab mich an H.O.O.P noch nicht dran getraut. Steht aber auf meiner Agenda. Sobald ein paar Leute das richtig kapiert haben, machen wir einen deutschen Thread dazu auf. In der Muttersprache schnalle ich so Sachen besser.

Ich hab mich auch noch nicht dran getraut. :joy: