JSON in Reading umwandeln

herrmannj · 02 März 2020, 13:27:48

also ehrlich. Steht doch da: "update finished, "shutdown restart" is needed to activate the changes.". Lesen und verstehen kann ein system dem Benutzer nicht abnehmen

rudolfkoenig · 02 März 2020, 13:52:06

Es gibt ein Interessenskonflikt:
- Benutzer, die lange mit dem System arbeiten, und keine Fehler (mehr) machen, moegen es, wenn das System nicht nervt. Ich bin zunehmend von (anderen) Systemen genervt, die meinen mir die Verantwortung abnehmen zu muessen, und mich deswegen gaengeln. Ein Popup nach update empfinde ich als Gaengelung.
- Neulinge wissen noch nicht, worauf sie achten sollen, es gibt zu viel Info, was man nicht einordnen kann. Da hilft es, wenn bestimmte Sachen hervorgehoben werden.

Beiden recht zu machen heisst, alles mit Option zum Abschalten implementieren => Code/Doku wird zunehmend unleserlich.

D.h. einer der drei Gruppen (Ehrfahrene, Neulinge oder Maintainer) verliert.

frank · 02 März 2020, 15:28:44

ZitatD.h. einer der drei Gruppen (Ehrfahrene, Neulinge oder Maintainer) verliert.

wenn eine gruppe verliert, muss ja mindestens auch eine andere gruppe gewinnen. jetzt könnte man die grösse der beiden gruppen heranziehen, um einen saldo zu erzielen.

ein gewinn in summe müsste doch alle 3 gruppen erfreuen.

- popups, die man immer bestätigen muss, empfinde ich auch als gängelung. da lese ich die info ziemlich bald auch nicht mehr.

- die popups wie beim löschen von attributen mit option zum abschalten wären allerdings noch ok.

- ein einfärben von "wichtigen" messages würde den eventmonitor auch etwas "aufpeppen", oder wäre das auch schon eine gängelung?
besonders bei einer grossen anzahl "durchrauschender" events können wichtige farbige logmeldungen auch weniger übersehen werden.

Beta-User · 02 März 2020, 15:58:11

Bei der nach wie vor geringen Zahl der Fälle, in denen das usern nicht klar zu sein scheint, wäre meine Meinung: Bitte lassen, wie es ist...

(Wer noch eine kleine Installation hat, sollte die Hinweise auf den restart unter den noch wenigen Meldungen wahrnehmen können, die kommen, nachdem man ein update anschubst).

herrmannj · 02 März 2020, 18:11:18

Ehrlicherweise bin ich nicht grundsätzlich dagegen, ich habe nur Angst das jetzt in einem Schnellschuss irgendwo drei Zeilen Code dran gebastelt werden die dann zwar irgendwie und -wo was anzeigen ohne das Benutzerfreundlichkeit oder Nachhaltigkeit da eine Rolle spielen.

Ich würde mich anbieten _bei Gelegenheit(!)_ ein Modul dafür zu entwickeln. So in der Art wie die Notifikation Bereiche bei mobiles würde mir da vorschweben. Mit der Idee dass erfahrene Benutzer das deaktivieren/deinstallieren können und so das man die einzelnen Mitteilungen selektiv deaktivieren und anpassen kann. So ein modul könnte dann auch die motd Mitteilungen aufnehmen und sollte auch offen für Mitteilungen anderer Module sein.

Wäre so etwas konsensfähig?

rudolfkoenig · 02 März 2020, 19:03:54

Ich haette damit kein Problem.
Wir haben auch noch das notice Modul, aber das ist ungefaehr das Gegenteil davon, was ich mir wuensche.

frank · 03 März 2020, 11:29:42

ZitatIch würde mich anbieten _bei Gelegenheit(!)_ ein Modul dafür zu entwickeln. So in der Art wie die Notifikation Bereiche bei mobiles würde mir da vorschweben.

hört sich vielversprechend an.

"cannot fork"-notifications fände ich dann zb auch ganz nützlich.

Beta-User · 03 März 2020, 13:00:02

Auch mein Einwand war nicht so zu verstehen, dass ich prinzipielle Einwände hätte, wenn jemand da was ändert - ich will nur möglichst als user nicht mit Dingen behelligt werden, die eigentlich "klar" sind, wenn man die Mechanismen verstanden hat. Werde mich daher darauf konzentrieren, diese Mechanismen bei Gelegenheit für "noobs" besser verständlich zu machen...

[etwas OT]
Ich habe jüngst in RandomTimer eine Änderung vorbereitet, die ab featurelevel 6.1 dann teils zu einem etwas anderen Verhalten führen kann (und dafür aber z.B. den Umgang mit Gruppen-HUEDevices vereinfacht). Nachdem das jetzt einige Zeit bei mir stressfrei gelaufen zu sein scheint, würde ich das einchecken, aber eben nach Möglichkeit so, dass alle (potentiell betroffenen) User das möglichst einfach mitbekommen, und zwar spätestens aber deutlich bei einem Update, das featurelevel 6.1 zum default macht. Denn dann führt das ggf. (erst) zu Irritationen. Dann sind die Änderungen aber voraussichtlich bereits viele Monate her, und ich habe dann evtl. schon vergessen, dass da was war...

Frage daher: Wo ist der richtige Ort, um "sowas" publik zu machen bzw. für eine Art "changelog zu 6.1" vorzuhalten?
[/OT]

rudolfkoenig · 03 März 2020, 13:10:22

ZitatFrage daher: Wo ist der richtige Ort, um "sowas" publik zu machen bzw. für eine Art "changelog zu 6.1" vorzuhalten?

Es gibt eine UPGRADE Datei im Root-Verzeichnis

Beta-User · 03 März 2020, 13:23:38

Zitat von: rudolfkoenig am 03 März 2020, 13:10:22
Es gibt eine UPGRADE Datei im Root-Verzeichnis

Thx, da hätte ich auch selber draufkommen können...

Zwei Anmerkungen dazu noch:
- Vermutung: Kaum ein User wird da reinsehen, da ist auch kaum Bewegung drin, was aber damit zu tun haben dürfte, dass
- grep nach featurelevel nicht eben viele Ergebnisse liefert. Genauer gesagt war ich tendenziell (in Vorbereitung auf das RandomTimer-Thema) überrascht, wie wenige Developer anscheinend von der Möglichkeit Gebrauch machen, Änderungen erst über dieses feature zunächst testweise einzubringen bzw. für die, die bestimmte features vorab haben wollen. Gerade für potentielle "breaking changes" erscheint mir das aber eine geeignete Vorgehensweise zu sein, oder übersehe ich (mal wieder) was wesentliches? Oder wird die Unterscheidung dann besser wieder ausgebaut, wenn der relevante Update bereits länger durch ist? (Ist ja auch wieder fehleranfällig und verhindert dann ein "downgrade durch software" mit aktiv gesetztem niedrigerem featurelevel).

rudolfkoenig · 03 März 2020, 14:04:20

Vermutlich planen die meisten Entwickler so gruendlich, dass sie nie breaking changes benoetigen.
Oder sie pfeifen einfach auf Kompatibilitaet

HeikoGr · 03 März 2020, 14:29:09

So, ich habe die letzten 2 Tage die Updates installiert um zu gucken, was ich da verpasse (und warum ich das nicht gelesen habe).

Zum Hintergrund:
Ich nutze FHEM meistens auf dem Smartphone (iPhone) und habe mir daher eine übersichtliche Startseite gebastelt (f18 Style).
die Befehle "update check" und "update" habe ich als Weblinks auf dieser Seite.

bis hier im Eventmonitor etwas passiert (nach ca. 2 Sekunden), hab ich schon ein neues Tab aufgemacht oder den Browser schon wieder geschlossen.
Als Nutzer sagen mir die meisten Meldungen doch eh nix...

Wobei ich auch das Gefühl habe dass hier bei einem Update auch mal keine Eventmeldungen angezeigt werden. Aber das kann ich nicht reproduzieren.

Insofern hätte auch ein Hinweis in rot und blinkend bei mir nichts gebracht...

Mal eine Ketzerische Frage eines ahnungslosen:
Wenn ein Neustart sowieso notwendig ist - wieso macht es FHEM dann nicht automatisch?

Und jetzt steinigt mich bitte nicht...

Beta-User · 03 März 2020, 14:35:33

"Automatisch" shutdown+restart hieße: eventuelle zwischenzeitliche config-Änderungen sind weg...

Weitergedacht: Automatisches "save" vorneweg? MMn. ein "Unding". (Da können auch mal Devices bei "hops gehen", weil irgendwas aus irgendeinem kühnen Grunde nicht ging, z.B. weil ein Modul "kaputt" war, und man das update genau deswegen durchführt...).

Tipp: Updates NIE von "weit weg" machen; meistens ist es kein Problem, aber man sollte nach einem Update immer prüfen bzw. prüfen können (!) ob es ein Problem gibt => ins log schauen => geht nicht "nebenbei".

Just my2ct.

Zitat von: rudolfkoenig am 03 März 2020, 14:04:20Vermutlich planen die meisten Entwickler so gruendlich, dass sie nie breaking changes benoetigen.

YMMD

(Ich sollte wohl den Developer-Status "zurückgeben", weil ich jedenfalls nicht sooooo weitsichtig in der Planung bin...
...bzw. was Randomtimer angeht: nicht verstehe, was Dietmar sich in grauer Vorzeit dazu an Gedanken gemacht hatte oder welchen Vorteil es bot, Value() abzufragen und den user auf stateFormat am abgefragten Device zu verweisen statt ReadingsVal+state zu nehmen... Vermutlich konnte "man" das damals einfach noch nicht wissen, oder man hätte rechtzeitig den fhem.pl-Entwickler fragen sollen, wie es "richtig" und zukunftsweisend ist...
Wie dem auch sei: es ist, wie es ist

.)

HeikoGr · 03 März 2020, 14:46:51

Zitat von: Beta-User am 03 März 2020, 14:35:33
hieße: eventuelle zwischenzeitliche config-Änderungen sind weg...

Stimmt, das ist ein Argument.

Zitat von: Beta-User am 03 März 2020, 14:35:33
Tipp: Updates NIE von "weit weg" machen; meistens ist es kein Problem, aber man sollte nach einem Update immer prüfen bzw. prüfen können (!) ob es ein Problem gibt => ins log schauen => geht nicht "nebenbei".

das ist für mich kein Problem: Ich kann ja immer noch per ssh (via VPN, kein Portforwarding) auf den Raspi zugreifen.
Die Logs lese ich (auch bei funktionierendem FHEM) lieber in einer anderen APP auf dem Smartphone (App "Documents", greift per SFTP auf den Raspi zu).

Wenn ich mein FHEM abschieße ist es für mich auch kein Drama. Es hängen keine lebenswichtigen Systeme daran :-D - Ich nutze das System ausschließlich zum Daten erheben - nicht zum steuern.

Und das wichtigste: Ich habe in der S-Bahn Zeit (und Nerven) dafür. Zuhause nicht.

Beta-User · 03 März 2020, 15:07:42

Zitat von: HeikoGr am 03 März 2020, 14:46:51
Es hängen keine lebenswichtigen Systeme daran :-D - Ich nutze das System ausschließlich zum Daten erheben - nicht zum steuern.

...wollen wir wetten, das sich das irgendwann ändert...?

ZitatUnd das wichtigste: Ich habe in der S-Bahn Zeit (und Nerven) dafür. Zuhause nicht.

Das ist völlig ok, du "kannst" also "prüfen", mehr hatte ich ja gar nicht als "erforderlich" genannt... Spätestens, wenn du auch was (vielleicht*) wichtiges steuerst, solltest du hin und wieder das log checken. (*vielleicht will sagen: manchmal findet man selbst Dinge nicht so wichtig, die andere als sehr wichtig ansehen, weil sie die Möglichkeiten anders nutzen - wird insbesondere dann lustig, wenn der Nachwuchs etwas größer ist und einen auch zuhause meistens in Ruhe läßt...)