Global Attributes zur Lokalisierung

[Loredo]

Zur Info:

Die aktualisierte Version 2 von Astro berücksichtigt einige Attribute, die derzeit zwar nicht in der globalen Attributliste stehen, dort aber stehen könnten (über userAttr oder wenn wir sie dort offiziell aufführten):


- lc_numeric
- lc_time
- timezone


Wie man sieht, haben diese Einstellungen alle mit der Lokalisierung zu tun und ermöglichen das Übersteuern jener Einstellungen vom Betriebssystem. Bisher ist Astro glaube ich das einzige Modul, welches eine Lokalisierung anbietet. Sofern es jedoch einmal weitere Module geben sollte, dann wäre es natürlich gut, wenn die selben Attribute verwendet würden und man diese nicht zwingend am Device explizit setzen müsste.

[justme1968]

diese attribute zu standardisieren und pro device zu haben wenn ein device dir möglichkeit braucht finde ich gut.

global sollte es die attribute aber nicht geben. dazu müsste man auch einbauen das fhem selber sie auswertet. und das ist unnötig. es gibt ja standards wie ein prozess damit umgehen sollte. und dazu sollte man das environment des fhem prozesses passend setzen. das muss ja nicht der system default sein.

[justme1968]

ps: wie wäre es gleich ein paar routinen zu standardisieren die mit den device attributen umgehen können?

[CoolTux]

Willst Du sie dann in $readingFnAttributes haben?
Die Idee zur  Standardisierung gefällt mir.

[justme1968]

nein. die attribute sind nur für bestimmte module sinnvoll die dann auch explizit support dafür einbauen müssen.

[CoolTux]

nein. die attribute sind nur für bestimmte module sinnvoll die dann auch explizit support dafür einbauen müssen.

ah ok.

[Loredo]

global sollte es die attribute aber nicht geben. dazu müsste man auch einbauen das fhem selber sie auswertet. und das ist unnötig. es gibt ja standards wie ein prozess damit umgehen sollte. und dazu sollte man das environment des fhem prozesses passend setzen. das muss ja nicht der system default sein.

Ich finds halt immer vorteilhaft im Sinne von Backup+Restore, wenn man sämtliche Einstellungen, die zu FHEM gehören, auch in FHEM abspeichern kann. Wenn ich aber die Information über die Lokalisierung, die ja vielleicht wichtig für den Rest in meiner FHEM Konfiguration sein kann, extern ablege und mich bei einem Restore nicht daran erinnere, dies auch wieder so einzurichten, dann ist der Restore von FHEM unvollständig.


Du hast aber sicher recht, dass das nicht der Standardfall ist, zumindest im Bezug auf die Zeitzone. Bei der lokalisierten Darstellung von Werten sieht es schon anders aus: Ich möchte in der Regel mein OS gerne in Englisch behalten und auch die Readings in FHEM sollen ja keine regionalisierten Separatoren bei nummerischen Werten nutzen. In der Darstellung möchte ich das aber vielleicht, besonders bei großen Zahlenwerten kann auch die Darstellung mit DezimaltrennzeichenTausender Separator sehr hilfreich sein, was aber nicht zum Standard gehört.


Ich mag jetzt gar nicht die alten Diskussionen über Darstellung, Units, Reading Typen etc. wieder aufwärmen... mir ging es nur darum zu sagen, dass Astro diese Einstellung unterstützt und einen Fallback auf ein evtl. in irgendeiner Weise gesetztes globales Attribut erlaubt. Ob man das nun in der Liste mit anzeigt oder nicht, sei mal dahin gestellt (gut und richtig fände ich es, gehört für mich zu den vollständigen Standortdaten dazu).


Ich wollte es nur nicht automatisch ins userattr aufnehmen, weil die Attribute zur Lokalisierung ein anderer Usecase sind. Ich möchte ja nicht etwas an alle FHEM Attribute ausrollen, sondern ich möchte ein Attribut nur im global Device aufgeführt haben, weil es auch nur dort Sinn macht und andere Module, die auf Device Ebene diese Einstellung nutzen, es eben in ihren eigenen Attributen dann auch separat aufführen müssen, wenn sie diese Funktion unterstützen.

[Loredo]

ps: wie wäre es gleich ein paar routinen zu standardisieren die mit den device attributen umgehen können?

Welche Routinen schweben dir da vor? Mir fällt gerade keine ein.

[justme1968]

ich finde es immer schlecht wenn es zwei stellen gibt an denen etwas konfiguriert werden kann. und für die globalen einstellungen gibt es ja standardisierte prozess spezifische möglichkeiten die auch von den system routinen automatisch verwendet werden.

wenn man diese globalen einstellung nicht verwendet und statt dessen fhem spezifisch etwas globales einbaut hat das den nachteil das keine der normalerweise verwendeten system routinen davon etwas mit bekommt.

im global device haben die attribute meiner meinung nach nichts zu suchen da sie nicht das globale verhalten von fhem beeinflussen sondern immer dann sinnvoll sind wenn ein device mit anderen einstellungen laufen soll als der rest von fhem.

deshalb: wenn fhem grundsätzlich mit anderen einstellungen als der rest des systems laufen soll dann gehört das meiner meinung nach in das fhem start script. und das gehört mit in den backup. wenn ein device mit andren einstellungen als der rest von fhem laufen soll (z.b. mehrere astro devices) dann gehört es ins device.

wenn ein modul nur durch lokale attribute zu konfigurieren ist und den normalen weg der system konfiguration komplett ignoriert ist das nicht gut. die konfiguration über das environment sollte der einheitliche minimal standard und grundsätzliche fallback sein.

die diskussion ist meiner meinung nach auch komplett unabhängig von darstellung, units und typen. da bin ich sowieso weitgehend bei dir

[justme1968]

Welche Routinen schweben dir da vor? Mir fällt gerade keine ein.

alle (fhem) routinen die etwas mit zeiten tun könnten eine variante haben die einen device hash bekommen und darüber die attribute berücksichtigen könnten.

das wären die system routinen wie mktime, ...
das wären fhem spezifische: time_str2num, SVG_time_to_sec, ...

und vielleicht sogar alle routinen die readings anlegen. wobei das ein ganz anderes fass ist... eigentlich sollten readings intern immer in utc gespeichert werden und nur bei der anzeige konvertiert werden.

[Loredo]

die diskussion ist meiner meinung nach auch komplett unabhängig von darstellung, units und typen. da bin ich sowieso weitgehend bei dir

Ich wollte nur vermeiden, dass hier evtl. vom Thema abgewichen wird 

ich finde es immer schlecht wenn es zwei stellen gibt an denen etwas konfiguriert werden kann. und für die globalen einstellungen gibt es ja standardisierte prozess spezifische möglichkeiten die auch von den system routinen automatisch verwendet werden.

Naja, möchtest du denn deine Geo-Koordinaten bei jedem Device separat setzen _müssen_? Eben. Soweit ich weiß nutzt fhem.pl diese Daten auch in keiner Weise, sondern andere Module (inkl. 99_SUNRISE_EL, ja). Ich sehe da keinen Unterschied, nur, dass es früher eben noch nicht "hipp" war, dass ein Betriebssystem selbst wissen konnte, wo es sich gerade befindet. Sonst könnte Perl das heute sicher auch genauso auslesen wie die Infos zur Lokalisierung.
Ich sag ja auch überhaupt nicht, dass man das zwingend setzen muss - muss man ja auch bei keinem anderen Attribut des global Device.


Wenn du also sagst, dass du im global Device nur Einstellungen vornehmen möchtest, du fhem.pl betreffen, dann hast du absolut recht. Aber die Situation ist heute ja eine andere, es wurden schon unterschiedliche Use Cases vermischt (was dann ja auch dazu geführt hat, dass Rudi userattr eingeführt hat für Attribute, die man bei jedem Device setzen können soll).
Trotzdem ist eine Unschärfe bei den Attributen des global Device da und IMHO muss/sollte man sie dann auch so weiterführen.

wenn man diese globalen einstellung nicht verwendet und statt dessen fhem spezifisch etwas globales einbaut hat das den nachteil das keine der normalerweise verwendeten system routinen davon etwas mit bekommt.

Diese Einstellungen werden ja (bei Astro) auch per Default verwendet - ist kein Attribut gesetzt, gilt die Einstellung der übergeordneten Instanz. So ist das in FHEM an vielen Stellen ja schon (Beispiel Geokoordinaten eben), die Betriebssystem Einstellungen für die Lokalisierung zu verwenden oder zu übersteuern (auf FHEM "global" ebene oder Device Ebene) ist da nur logisch:


OS > fhem.pl > FHEM global Device > FHEM Module > FHEM Device

alle (fhem) routinen die etwas mit zeiten tun könnten eine variante haben die einen device hash bekommen und darüber die attribute berücksichtigen könnten.

und vielleicht sogar alle routinen die readings anlegen. wobei das ein ganz anderes fass ist... eigentlich sollten readings intern immer in utc gespeichert werden und nur bei der anzeige konvertiert werden.

das wäre toll, aber ich befürchte dafür gibt es keine breite Zustimmung. Letztlich würde es wahrscheinlich zu einem Chaos an Inkonsistenzen führen, weil viele Module nicht die FHEM Funktionen verwenden, sondern localtime() etc selbst aufrufen und dabei aber tzset() und LC_TIME berücksichtigen. Dann haben wir Zeiten in UTC und andere sind lokal und niemand weiß mehr welche Uhrzeit nun wie zu interpretieren ist.


Das wollte ich mit meinem Beitrag auch gar nicht erreichen, im Grunde war es kaum mehr als eine Information (so lautete ja auch der Einstiegssatz  ).