Moin,
der folgende Bug könnte auch als Feature-Request betrachtet werden, allerdings ist ein uneinheitliches Verhalten verwirrend und daher erst einmal in der Kategorie „Bugs“:
Bei der inoffiziellen Nutzung von vhih ist aufgefallen, dass die Apps sehr unterschiedlich auf „*Alarm“-Attribute reagieren. Auch wenn dies als Ursache eine fehlende API-Spezifikation hat, da dies kein offiziell unterstützter Weg für eure Kunden darstellt, eigene Geräte (Saugroboter, Rasenmäher, Wechselrichter, *) auf eigene Verantwortung einzubinden, würde mich eine Lösung des daraus entstehenden Problems in den Apps und den HGs freuen.
Folgende Konstellation: Ein Nutzer (@whoami) hat einen MalfunctionAlarm konfiguriert, der als current_value den meines Erachtens nicht unterstützten Wert 19 erhält. Ferner wurde als data ein eigener Fehlertext übergeben.
Interessant ist das Verhalten der unterschiedlichen Apps:
- Android: Hier erhält das Tagebuch den Wert 42.0 in der Übersicht.
- Web-App
- iOS
Als Bug betrachte ich das uneinheitliche Verhalten auf den ungültigen Wert 19 (bzw. ich selbst habe es mit42getestet). Meines Erachtens müsste entweder die API die Wertänderung verwerfen oder die UI generell z.B. undefined oder nullpräsentieren.
Sehr schön ist das Verhalten der iOS-App, darauf würde sich auch mein Feature-Wunsch beziehen:
Im Zuge der Einbindung von WLAN/externen Schnittstellen wäre es hilfreich, wenn „*Alarm“-Attribute offiziell in allen Apps als data-Property anzuzeigende Fehlermeldungen enthalten könnten und diese auch im Tagebuch erscheinen. Dies würde auch bei offiziellen Schnittstellen wie myStrom oder Nuki usw. eine leichtere Fehleranalyse als ein einfaches „Fehler!“ als Wertinformation erlauben.