Ich hab gerade einen Gast-Homey zum Einrichten.
Heute hab ich jetzt die ganzen Hues direkt ohne Bridge eingebunden. Der Pro läuft auf 7.4.rc22 beta.
Was mir sofort aufgefallen ist, dass insbesondere die Hue Iris, sporadisch Befehle mit einer Fehlermeldung quittieren, oder nicht reagieren.
Eine Gegenprobe mit meinem Homey mit v7.3.0, Hue Bridge und HA, zeigt dieses Verhalten nicht.
Kann das jemand mit der rc22 bestätigen ?
Durch das Zurückspielen eines Backups wird die neueste stabile Version einer App heruntergeladen und installiert, unabhängig davon, welche Version Sie ausgeführt haben.
Es geht also darum, die /test Version selbst nachträglich zu installieren.
Danke für den Tip, werde ich mir Morgen nochmal vornehmen.
Heute wurde eine neue Version der Shelly App veröffentlich mit folgendem Hinweis:
“Version 3.9.7 — Code improvements for upcoming Homey firmware 7.4.x. No functional changes.”
Die IcalCalender App wurde für SDK3 aktualisiert, was vermutlich auch mit der v7.4.x zutun hat.
Auch Ronnys OpenWeather App wurde hinsichtlich v7.4.x bereits 2x aktualisiert.
Die Zahl der Apps, die für die Homey Version v7.4.x aktualisiert werden (müssen), steigt also weiter an.
Sorry, bin immer noch auf v7.3.0 
Ich hatte zwei Dinge festgestellt - mal als technsiche Erläuterung für Interessierte:
Nicht abgefangene Fehler im Programm werden nicht mehr ignoriert (sah man bisher nur bei lokalen Tests in der Konsole), sonder tauschen im CrashLog in der Developer-Seite auf. Für mich hat das den Vorteil, dass ich so auf bisher nicht aufgefallene Sonderfälle reagieren kann. Z.B. wenn OWM keine Daten in den Wetterdaten hat, wo das Programm welche erwartet, dann führt das beim Ändern der Capabilities zu Fehler, wenn der Datentyp nicht passt (z.B. einen String in einen Zahlenwert schreiben). Oder wenn OWM Werte liefert, die in den Festwertlisten der Capabilities (noch) nicht enthalten sind.
An der Stelle ist es sogar gut, wenn man nicht jeden Fehler abfängt, sondern diese Fehlerquellen sieht und das Programm anpassen kann, also fehlerresistenter machen kann.
In den letzten Testversionen hatte ich solche Fehlerbehandlungen ergänzt und schau nun im CrashLog, ob noch mehr auftritt. Bisher sieht es ganz gut aus 
Aktuell bricht die App nicht ab, sondern ich sehe in dem Log nur die Fehler. In späteren NodeJS-Versionen könnte das durchaus zum Crash der App führen. Athom hat das in der Firmware gut abgefangen, so dass wir Entwickler die Meldungen sehen, die App aber nicht komplett abbricht.
Edit: Man könnte also sagen, mit 7.4.x fallen bisher unentdeckte Fehler in der App nun auf und man kann sie korrigieren. Das ist ganz hilfreich für nicht alltäglliche Konstellationen oder Situationen, die nur bei wenigen Usern auftreten und nicht beim Entwickler selbst.
In der NodeJS-Version bis 7.3.x wurde Lokalisierungen bei Datums-Konvertierungen komplett ignoriert. D.h. man konnte das Datum nicht in eine lokalisierte Textausgabe konvertieren (z.B: TT.MM.YYYY statt MM/TT/YYYY für de-DE).
Dazu hatte ich mir eine eigene Konvertierung gebaut, die das Datum zumindest in eine “internationale” Variante YYYY-MM-TT konvertiert.
Mit 7.4.x liefert NodeJS nun tatsächlich eine lokalisierte Datumsversion. Ich muss nun in allen Apps eine Prüfung auf Version >= 7.4.x einbauen und das Datum nun anhand der Homey-Sprache konvertieren. Und das alles auf gut Glück, weil ich besser (noch) nicht auf 7.4.x aktualisiere.
Dazu werden also demnächst noch Updates kommen.
Die Aussage von Emile stiftet etwas Verwirrung: Er spricht von “native modules”, meint aber “addons”.
Addons enthalten kompilierten Code, d.h. sie sind nicht in JavaScript (oder TypeScript) geschrieben, sondern in C++ und für die Verwendung in Node.js kompiliert.
Der Grund, warum Addons problematisch sind, ist, dass sie an eine bestimmte Node.js-Version gebunden sind, was bedeutet, dass ein Addon, das für Node.js v12 kompiliert wurde, in Node.js v17 ohne Neukompilierung nicht funktioniert.
Die Verwendung “normaler” Module ist kein Problem.
Übersetzt mit DeepL Translate: The world's most accurate translator (kostenlose Version)
So, ich hab’s jetzt endlich gewagt. FW v7.4.0-rc.22 ist drauf.
Was ich bisher festgestellt habe ist, dass nach dem Homey Neustart die Geräte in Apple Home (via HomeyKit App) nicht mehr funktionierten. Nach einem Neustart der HomeyKit App war das Problem allerdings gelöst.
@Undertaker, ich habe zwar keine Hue Iris aber ich habe mal ein bisschen mit einer E27 White/Ambiance und einem Lightstrip rumgespielt.
Reaktionszeiten < 1 s und alle Lampen haben auf jeden Befehle reagiert.
Was mir allerdings aufgefallen ist, dass beim Umschalten meiner Standardlichtszenen, ich habe die originalen Hue Lichtszenen “Lesen”, “Konzentration”, “Entspannen” und “Aktivieren” nachgestellt, Farben sichtbar sind, und das obwohl der Lichtmodus “Temperatur” eingestellt ist und nur die Farbtemperatur und das Dimmlevel geändert werden. Je nach Wechsel ist mal ein schwaches Grün, ein Rot oder ein Blau sichtbar.
Ob das mit v7.3.0. auch schon war, kann ich nicht mit Sicherheit sagen. Vorher habe ich beim Lichtszenenwechsel nie so genau hingeschaut.
Mir ist das mit den Iris mittlerweile noch mehr aufgefallen. Sie verabschieden sich teilweise komplett aus dem Netz und jeder Schaltvorgang wird mit einer Fehlermeldung quittiert. Stecker raus und wieder rein und sie sind wieder da und reagieren.
Hauptsächlich verabschieden sie sich beim langsamen Dimmen oder dem Farbwechsel.
Ein neues Einlernen brachte keine Verbesserung.
Das gleiche Verhalten zeigen auch die alten Lightify Lightstripes. Es kann also nicht an der Hue App liegen, sondern muss mit der neuen Firmware zu tun haben.
Mit der Stable Firmware, der Hue Bridge oder Conbee 2 an HA, tritt dieses Verhalten nicht auf.
Ich habe den Homey zurück gesetzt und die Stable wieder aufgespielt. Alles in Butter, es funktioniert wieder, wie es soll.
Andere Fehler hab ich bei der beta bisher nicht gefunden.
Wer hat noch nicht, wer will nochmal ?
Schon ausprobiert?
Frage an die Programmierexperten @RonnyW und @robertklep (sorry only in German, but I know that you’re using deepl.com ) bezüglich des Punkts:
[Apps] Prevents apps from adding capabilities that don’t exist
In der Homematic App wird z.B. für das Homematic IP Smart Home Modul für Hörmann-Antriebe HmIP-MOD-HO folgende Capabilities verwendet:
Die Capabilities measure_mod_ho_door_state und homematic_button_mod_ho_partial_open gibt es in der Übersicht der offiziellen Device Capabilities aber nicht.
Bedeutet das jetzt, dass das Homematic Gerät HmIP-MOD-HO mit der Firmware v7.4.1-rc.2 nicht mehr funktionieren wird wenn es schon gekoppelt ist? Oder kann dieses Gerät zukünftig, also unter v7.4.1x, nicht mehr hinzugefügt werden?
Nein, ist mir zu risikoreich.
Mir auch. Ich möchte zumindest erst o.g. Frage geklärt haben. Wenn durch die neue FW meine Homematic Geräte nämlich nicht mehr funktionierten, habe ich ein Problem.
Hi, ich hab mal ein paar Kommentare von Slack kopiert. Ich hoffe, das ist ok?
Es geht wohl darum, das verhindert wird, ungültige Capabilities danymisch in Geräte einzufügen.
Das Problem ist da wohl nich tHomsyKit, sondern andere Apps, die ungültige Capabilities liefern (würden).
Wenn es bisher funktioniert hat, sollte das auch weiter funktionieren. Im Zweifel fängt Robert die Exception ab und alles ist ok (denke ich).
Bis dahin könnte die App ggf. crashen, falls der Fehler nicht von Athom abgefangen wird. Sicher bin ich da nicht. Ich sehe auch CrashLogs, weiß aber nicht, ob die nur informatorisch sind (also ein Log-Auszug aus der Konsolenausgabe) oder app die App tatsächlich beendet wurde.
=> Slack-Auszug:
With the new 7.4.1-rc2, do you see that some specific,eg. community app, will stop working because of the 2nd improvement (prevents apps…)7.4.1-rc.2
[Core] Improve monitoring of load average and CPU usage
[Apps] Prevents apps from adding capabilities that don’t exist
Which app are you referring to? I haven’t noticed an issue.
judging by the crash reports I’m seeing for HomeyKit, there are at least some apps that set invalid capabilities (I don’t log which apps because I never assumed that devices could have invalid capabilities)
I had a bug in some code that tried to add an undefined capability and the API rejected the promise, as it should.
log] [ESPEasy] Rejection reason: Error: invalid_capability at Remote Process { code: 404 }
Maybe some app developer removed the capability from the device definition?
no, HomeyKit doesn’t care about that, it just gets a list of capabilities for a device from the Web API
some are invalid ( null ), some don’t seem to exist (creating a listener for it crashes because the device doesn’t have such a capability (even when it was on the list of capabilities for the device…))
Verstehe ich, so ähnlich geht es mir mit den MQTT Apps.
No Risk no Fun, könnte große Teile meines Systems abschießen.
Das hatte ich schon gelesen, verstehe es aber nicht. Deshalb hatte ich hier explizit ein Beispiel mit entsprechenden Capabilities genannt.
Deine Zusammenfassung des Slack Protokolls verstehe ich auch nicht ganz. Was sind z.B. “ungültige Capabilities”?
Für mein logisches, ohne Programmierkenntnisse vorbelastete Verständnis bedeutet das, dass die Capabilitie measure_mod_ho_door_state eine ungültige Capabilitie ist, da diese nicht in Athoms Übersicht gelistet ist. Was für mich wiederum bedeuten würde, dass es Probleme geben wird. Jetzt ist nur die Frage welche Probleme.
Deine Aussage “sollte weiter funktionieren” ist mir ehrlich gesagt zu unsicher um einen Versuch zu wagen…
Nein. Das ist eine gültige Capability (Custom Capability). Denen kann man eigene Namen geben in der App/Gerätedefinition.
Eine ungültige Capability wird auch bereits jetzt nicht funktioniert haben. Genau kann ich das aber nicht sagen. Mir fehlt da ein Beispiele zum Verständnis. Aber vielleicht kann Robert mehr dazu sagen.
Nein, das bedeutet nicht “ungültig”. Die capability, auf die Sie sich beziehen, ist eine “custom capability”, und es gibt dokumentierte und vollkommen gültige.
Bei HomeyKit sehe ich jedoch (in den vielen, VIELEN Absturzberichten), dass einige Geräte capabilities haben, die wirklich ungültig sind, zum Beispiel null oder undefined. Ich nehme an, dass es sich dabei um das handelt, worauf sich Athom bezieht (aber wer weiß, sie sind in der Regel nicht sehr klar in ihren Changelogs).
Übersetzt mit DeepL Translate: The world's most accurate translator (kostenlose Version)
