ich musste mich heute mal wieder fragen warum homee es sich mit dem Tagebuch eigentlich so schwer macht - und warum das so schön gepflegte Tagebuch nachträglich noch geändert wird.
Das Tagebuch war seit seiner Einführung für mich nach der anfänglichen Euphorie eher ein Grund zum Frust als tatsächlicher Nutzen. Ladezeiten von 2 und mehr Minuten sind bei meinem System die Regel. Wenn man dann auch noch filtern will dauert es sogar noch länger und man guckt dem Ladekreis gefühlt eine halbe Std beim drehen zu. Nicht selten verliert die App dann zwischendurch auch noch kurz die Verbindung (Was man aber nicht immer mitbekommt, denn wer guckt schon tatsächlich 5 Minuten lang auf sein Handy während so was lädt) was dazu führt, dass der Ladekreis unendlich weiter dreht ohne das Ergebnisse präsentiert werden. So eine schnelle Fehleranalyse durchführen zu können ist ein Ding der Unmöglichkeit.
Ich hab mich immer gefragt warum so eine simple Auflistung an Ereignissen so lange braucht um angezeigt zu werden - Bis mir durch einen Zufall aufgefallen war woran es liegt.
homee schreibt nicht brav auf was passiert und legt es in der DB/Tabelle ab, sonder macht sich quasi nur kurze Stichpunkte und sammelt sich dann die restlichen Informationen erst beim Öffnen zusammen.
Aufgefallen war mir das weil ich eine Bedingung in einem HG geändert habe und danach nochmal im Tagebuch gucken wollte ob die Bedingung wirklich der Grund war warum das HG nicht wie erwartet gelaufen ist. Und siehe da: Im Tagebuch steht nicht der Ursprünglich Wert für die Bedingung, sondern der neue, just von mir geänderte Wert. Das macht die Suche nach Fehlern im Nachhinein noch schwerer und für ein Tagebuch (auch im übertragenen Sinne) überhaupt keinen Sinn. Zudem scheint es massiv Ressourcen zu fressen, weil ja zu jedem Ereignis erst die Daten aus den jeweiligen Gruppen, Geräten und HGs dazu geladen werden müssen, was bei größeren Installationen zu deutlichen Verzögerungen führt.
Daher stellt sich mir die Frage wäre ein einfach “mit plotten” der Ereignisse ohne diese “Dynamik” nicht deutlich effizienter/zielführender für ein Tagebuch? @Thomas@Patrik Wäre super wenn es dazu eine kurze Rückmeldung gäbe.
Ja, das kann schon sein. Wir nutzen das bei unserer Software auch so (haben ich allerdings mit Absicht so programmieren lassen). Und auch ich kann bestätigen, dass das bei unserer Software verdammt viele Ressourcen frisst und wir genau deswegen ständig mit Wartezeiten leben müssen. Und in diesem Fall macht es aus meiner Sicht echt keinen Sinn das Tagebuch dynamisch zu machen, im Gegenteil es scheint mir sogar kontraproduktiv.
Bei jedem Aufruf werden die zusätzlichen Daten der HGs neu geladen.
Übrigens: Das Laden und Filtern des Tagebuches hat jedes mal ca 6 Minuten gedauert. Aus irgend einem mir nicht nachvollziehbaren Grund dauert es nämlich erheblich länger, wenn auf eine geringe Schnittmenge gefiltert wird als auf eine Große. @Thomas/@Patrik könnt ihr das evtl auch erklären?
Sehe ich das richtig, dass schon bei deinem ersten Screenshot steht, dass du Aktion um 0:34:54 Uhr nicht ausgeführt wurde, weil die Bedingung “zwischen 19:00 Uhr und 23:… Uhr” nicht zugetroffen hat? Vermutlich auch schon eine Änderung? Da wird es dann ja mal richtig komisch.
EDIT: Ich meine übrigens irgendwo mal gelesen zu haben, dass die App mit Angular programmiert wurde (übrigens genau wie unsere Software auch). Bite nicht falsch verstehen, ich halte grundsätzlich sehr viel von Angular, ich sehe nur gerade soooo viele Parallelen Die Teile, die bei uns mit Angular 2 programmiert wurden laufen übrigens flüssig.
Nee in dem Fall war das ja sogar korrekt.
0:34 Uhr ist ja schließlich nicht zwischen 19:00 und 23:45 Uhr.
Aber genau so einen Fall hatte ich, weshalb ich ja so stutzig wurde.
Das war aber gegen 18 Uhr bei einem anderen HG Die Zeitrahmen waren aber ähnlich. Ursprünglich sollte das HG auch nicht vor 19 Uhr auslösen. Um 18 kam dann der Trigger. Da hab ich für mich erkannt, das ich möchte das das HG schon um 17 Uhr auslöst, und habe entsprechend angepasst. Im Tage buch stand dann tatsächlich die widersprüchliche Meldung, das um 18 nicht ausgelöst wurde, weil die Bedingung "zwischen 17:00 Uhr und 23:00 Uhr " nicht erfüllt gewesen sei.
Um das konkrete Beispiel aus dem Tagebuch raus zu suchen hätte ich aber wahrscheinlich ne halbe Stunde Warten müssen, worauf ich aber keine lust hatte.
Ja das stimmt, es werden nicht einfach stur Texte in die Tagebuch-Datenbank geschrieben.
Im Grunde besteht jeder Tagebucheintrag aus genau 7 Zahlen, die dann einer Zeile in der Datenbank entsprechen - und davon bis zu 50.000!
Das hat vor allem den Grund, weil unsere Objekte (Geräte, Homeegramme, Gruppen…) in ID`s aufgebaut sind und entsprechende Abhängigkeiten besitzen, die dem Nutzer das Springen auf die entsprechende Stelle ermöglichen. Des Weiteren ist es auch ganz klar eine Frage des benötigten Speichers und die Möglichkeit die Informationen individuell aufzubereiten.
Wie @Caphi schon erkannt hat wurde damals entschieden die WebApp in Angular zu programmieren, welches aus heutiger Sicht und den neuen Technologien nicht die performanteste Lösung darstellt.
Alles in allem sollte die Aufbereitung trotzdem recht zügig gehen, sodass wir eher einen Bug vermuten. Daher bitte ich @cru8602 mir mal den Support-Zugang als PN zukommen zu lassen, sodass wir uns das anschauen können.
@Volker hat sich die Sache angeguckt und für sich gemessen.
und ich habe es dann auch nochmal gemacht:
PC mit WebApp:
im Schnitt 40 sek.
Handy mit AndroidApp:
2x ca. 4 Sek (was mich aus meinem persönlichen Gefühl heraus wirklich überrascht hat.)
2x nach ca. 2 Minuten abgebrochen ohne das ein Ergebnis angezeigt wurde
Handy mit WebApp 4G:
1x 1:16 Minuten
1x 1:25 Minuten
4x nach 2 Min. abgebrochen. Es kam hier jeweils nach ca. 1 Minuten Wartezeit zu einem reconnect, obwohl die Verbindung ansonsten stabil ist
Auch das Filtern auf das HG von oben habe ich nochmal gemessen:
PC mit WebApp
1x nach 7:30 Minuten abgebrochen
1x ca. 3:30 Minuten
Handy mit WebApp
konnte ich nicht mehr messen, weil sich das Tagebuch nicht mehr geöffnet hat.
Ich muss mich also zumindest dahin gehend korrigieren, das die gefühlte Wartezeit nicht immer der echten Zeit entspricht, wobei die Situation am Handy trotzdem bei weitem nicht befriedigend ist. Und über 3 Minuten Wartezeit um auf ein Ereignis, das ca 15 Std zurückliegt zu Filtern ist auch bei weitem kein Spitzenwert, sondern lässt einen wahrscheinlich des öfteren denken „das hat wohl nicht geklappt“.
Ich habe gerade auch spaßeshalber mal gemessen:
WebApp geöffnet -> Tagebuch angeklickt -> Stoppuhr gestartet -> so schnell ich kann runter gescrollt bis heute Mitternacht (immer wieder beim nachladen gewartet) -> Stoppuhr gestoppt -> 4:41 Minuten
Ich habe mich gerade zwar über ein HG geärgert, welches eindeutig zu oft geprüft wurde und da auch nochmal ein wenig etwas angepasst, damit es morgen hoffentlich deutlich weniger oft geprüft werden muss, aber das ist dennoch mal recht lange, wie ich finde.
Ein Problem ist es allerdings für mich derzeit zumindest nicht wirklich, da ich selten im Tagebuch bin und wenn dann nur zur Fehlerbehebung, da kann ich mir dann schonmal ein paar Minuten Zeit nehmen. Und ohne Filter blickt da eh kein Mensch durch. Aber @cru8602 hat schon recht, mal eben schnell nachgucken, ist da echt nicht drin.
Achja da kommen ja auch noch die ca 40 Sekunden dazu die das Tagebuch selbst braucht um sich zu öffnen, bevor man in die Filtereinstellungen gelangt. Dann das öffnen der HG liste usw.
Gerade wenn, sagen wir morgens, es etwas hektischer zugeht, die Familie aber wissen will warum irgendwas nicht geklappt hat kann einem das schon den Puls ein wenig hoch treiben.
Oh dazu fällt mir noch ein Verbesserungsvorschlag ein:
Es sollte möglich sein aus der normalen HG Ansicht direkt in ein entsprechend gefiltertes Tagebuch zu springen. Für Geräte, Pläne und Gruppen wäre das dann genauso sinnvoll.
Weiß nicht so recht, ob es hier rein passt aber bei mir stehen zB immer wieder Aktionen die angeblich nicht ausgeführt wurden, aber eigentlich ausgeführt wurden. zB soll nicht Push gesendet werden, laut Tagebuch wurde die Aktion nicht ausgeführt aber die Pusk kam trotzdem.
Für mich hakt das ganze Tagebuch, nutze es auch kaum noch…
Die Teile, die bei uns mit Angular 2 programmiert wurden laufen übrigens flüssig.
