Längenbeschränkung beim Einlesen von readings aus dem statefile?

[Elektrolurch]

Hallo,

habe folgendes programmiert:
Für die Rolladensteuerung hinterlege ich für die Öffnungs- und Schließzeiten die Programmierung für jeden Wochentag als reading bei den Rolladen. Das sieht dann im statefile (fhem.save) z.B. dann so aus:

setstate Az_FRolladen 2014-08-12 12:12:23 0-Open ab Sonnenaufgang Sperrzeit 7:00 Minuten 0 mode normal
setstate Az_FRolladen 2014-08-12 12:12:25 1-Close Minuten 30 Sperrzeit 18:00 ab Sonnenuntergang mode normal Uhrzeit 20:00
setstate Az_FRolladen 2014-09-08 12:12:58 1-Open ab Sonnenaufgang Minuten 0 Sperrzeit 7:00 mode Sonnenschutz


Am Sonntag ist der mode = normal, am Montag = Sonnenschutz.

Nach einem Neustart (d.h. das statefile wird wieder gelesen, steht in den readings folgendes drin:
     2014-08-12 12:12:23   0-Open          ab Sonnenaufgang Sperrzeit 7:00 Minuten 0 mode normal
     2014-08-12 12:12:25   1-Close         Minuten 30 Sperrzeit 18:00 ab Sonnenuntergang mode normal Uhrzeit 20:00
     2014-09-08 12:12:58   1-Open          ab

Wie man sieht, ist für Montag nun das reading verstümmelt auf den Wert "ab", der Rest ist abgeschnitten.
Das passiert nur für jene readings, die den mode "Sonnenschutz" (und nicht normal) enthalten.
Ich kann hier keinen logischen Unterschied zwischen dem Wort "normal" und "Sonnenschutz" erkennen, das Ganze ist auch eindeutig reproduzierbar und scheint erst beim Einlesen des statefile zu passieren, denn da wurden ja
die Werte noch korrekt abgelegt.
Meine Software hat nach dem Einlesen auf die readings nach dem Neustart weder schreibend, noch lesend zugegriffen, dass erfolgt nur, wenn ich die Zeitberechnung zweimal am Tag anstosse, bzw. neue Werte programmiere.


Also: -> Längenbeschränkung beim Einlesen der readings?


Gruß

Elektrolurch

[betateilchen]

Was passiert denn, wenn Du die Zeile

Code Auswählen Erweitern

setstate Az_FRolladen 2014-09-08 12:12:58 1-Open ab Sonnenaufgang Minuten 0 Sperrzeit 7:00 mode Sonnenschutz

im Frontend eingibst?

Da die zweite setstate Zeile aus Deinem Beispiel ja länger ist als die verstümmelte dritte glaube ich nicht an ein Längenproblem des readings selbst. Zumal fhem.pl die Zeile nicht mehr verändert, sondern komplett in die Ausführung übergibt.

Wie groß ist Dein statefile?

[Elektrolurch]

Hallo Betateilchen,

habe das reading 1-Open mal auf "kein Wert" gesetzt und dann die Zeile

setstate Az_FRolladen 2014-09-08 12:12:58 1-Open ab Sonnenaufgang Minuten 0 Sperrzeit 7:00 mode Sonnenschutz

in der fhem-Befehlzeile eingegeben.

Es passiert nichts, das reading 1-Open bleibt auf "kein Wert"

Gebe ich statt dessen:
setreading Az_FRolladen 1-Open ab Sonnenaufgang Minuten 0 Sperrzeit 7:00 mode Sonnenschutz
ein, so hat das reading wieder den korrekten Inhalt.

Die fhem.save ist 110 k groß.

Die Ablage der Rolladenprogrammierung habe ich schon seit Monaten im Betrieb. Der Modus "Sonnenschutz" ist vor vier Wochen erst dazu gekommen. Und nur jene drei Eintragungen mit "mode Sonnenschutz" sind nach einem Neustart weg, obwohl sie korrekt im statefile stehen.
Ein großes ? schwebt über meinem Kopf, da ich auch keine Systematik erkennen kann, nur dass es halt reproduzierbar ist und der setstate-Befehl, wie oben beschrieben, nicht funktioniert.

Gruß

Elektrolurch

[justme1968]

wenn es schon ein reading gibt dann setzt setstate den wert nur neu wenn die neue zeit größer als die alte war. du musst also beim testen aufpassen.

steht im statefile auch wirklich noch das komplette reading?

gruss
  andre

[Elektrolurch]

Hallo Andre,

danke für den Tipp.
Habe die Uhrzeit etwas erhöht, entgegenüber dem alten Wert und jetzt sehe ich genau das, was auch sonst beim Neustart passiert:
Das Reading wird nur mit dem ersten Wort gesetzt, ist also nicht ganz leer.
Ich kann die Worte/Wertepaare auch vertauschen, im reading ist immer nur das erste Wort vorhanden.

Es muss also einen Unterschied zwischen setstate und setreading geben, letzteres geht ja.
Im übrigen ist im Modul 10_SOMFY.pm keine stateFN definiert, also daran kann es auch nicht liegen und im log gibt es auch keine Fehlermeldung.

fhem hat einfach was gegen das Schlüsselwort "Sonnenschutz", da ich neun Rollos habe mal 14 Zeiten, macht das 126 readings und nur genau die drei mit dem mode = Sonnenschutz gehen nicht. "Sonnenschutz" kling nach Urlaub und das lässt fhem nicht zu

Gruß

Elektrolurch

[justme1968]

ein unterschied wäre das das datum aus der zeile geparsed wird. aber ich glaube nicht das es das ist.

hast du eine eventMap in der Sonnenschutz vorkommt?

gruss
  andre

[Elektrolurch]

Ja, habe ich.
Gerade in die fhem.pl geschaut, in der CommandSetState wird ja ReplaceEventMap aufgerufen, aber dann ja nur SetstateFN und die gibt es ja nicht im Modul, also müsste das reading ja zumindest stupide komplett gesetzt werden.

Sonnenshutz wird zu "pos 80" gemappt. Da liegt wohl das Problem, aber ich verstehe nicht, warum der ganze String, bis auf das erste Wort dann unter den Tisch fällt....

[justme1968]

schau ob es ohne die eventMap geht und schau ob im save file noch alles richtig steht. d.h. ob das problem bei, rausschreiben oder beim einlesen entsteht.

[Elektrolurch]

Im statefile steht es immer richtig, schreiben geht also ohne das eventMap zuschlägt.
Zuweisung per setstate auf einen dummy, der keine eventMap hat, geht auch.
Meiner Meinung nach gibt es da bei fhem einen Fehler im Konzept:
Das Einlesen des statefiles sollte NICHT über setstate erfolgen, da die eventMap dann die Originalwerte der readings verändert und
es auch viel zu lange dauert, bis über setstate und dem ganzen Brumborium darin, die Werte letztendlich auf dem state oder den readings gespeichert werden.
Der ganze  "aktive" Kram ist meiner Meinung nach beim Einlesen überflüssig. Einfach die hashes mit den Zeitstempel aus deer Datei erzeugen und gut wäre es.

Jetzt muss ich erst einmal überlegen, wie ich vernünftiger Weise einen Work-Around hinkriege.
Habe die Werte "schicker Weise" gleich bei den Rollos hinterlegt. Nur für die Programmierung der Öffnungs- und Schließzeiten jeweils noch einen dummy dazwischen zu hängen, wäre ja ziemlich un-cool.
Alles in einem dummy zu speichern, hat auch ein paar Nachteile, da ich dann Rolladennamen+Tag+open als reading Name verwenden müsste und da ich das universell halten wollte (der Rolladen kann ja beliebig heißen) gibt es keinen eindeutigen Trenner, um aus dem reading Nameneine eindeutige Zerlegung zu machen.

Den Modus "Sonnenschutz" anders zu nennen, ginge natürlich auch.
Aber letztendlich bleibt das Problem bestehen, dass das Einlesen über setstate readings verändert.

Oben gesagtes würde ich also als Verbesserungsvorschlag mal zur Diskussion stellen.

@Rudi?
Gruß


Elektrolurch

[Puschel74]

Hallo,

FHEM-Entwicklung -> FHEM Development
oder
FHEM-Entwicklung -> Wunschliste

Wohin soll der Beitrag gehen?
Hier liest Rudi eher selten mit - es sei den betateilchen hat ihn bereits auf diesen Beitrag aufmerksam gemacht.
Sonst würde ich eher dazu raten passend zu verschieben.

Grüße

[rudolfkoenig]

Bin durch den gemeldeten Beitrag aufmerksam geworden, ein Verschieben haette nicht gereicht, ich kriege nur neue Nachrichten mit.

setstate ist eigentlich nur deswegen da, damit die fhem.state Datei mit einem normalen include eingelesen werden kann.
Wieso dabei ein ReplaceEventMap notwendig ist, ist mir inzwischen aber nicht mehr klar. Die Zeile habe ich vor zwei Jahren (r1717, 2012-07-11) mit dem Kommentar "Correct one-time relative at after reboot" eingefuegt, das erklaert aber ReplaceEventMap fuer mich noch nicht.

Wenn keinem ein Argument fuer ReplaceEventMap in setstate einfaellt, dann werde ich es entfernen.

[betateilchen]

Ich würde eher das gesamte Konzept von eventMap überdenken, denn das macht auch noch an ganz anderen Stellen in fhem Probleme. Aus diesem Grund kann ich eventMap in meiner Installation überhaupt nicht mehr einsetzen.

[rudolfkoenig]

Ich würde eher das gesamte Konzept von eventMap überdenken...

Nur zu.
Ich bin mit eventMap zwar auch nicht wirklich gluecklich, aber ich habe z.Zt. keine Motivation es umzubauen, insb. wenn ich an die  (Achtung, Euphemismus) nicht ganz intuitive Event-Verarbeitung durch Dispatch, DoTrigger und Co. denke.

[betateilchen]

insb. wenn ich an die  (Achtung, Euphemismus) nicht ganz intuitive Event-Verarbeitung durch Dispatch, DoTrigger und Co. denke.

Du sagst es

[betateilchen]

[offtopic]
Dieses Thema jetzt in einen Forumbereich zu verschieben, der nur einer geschlossenen Benutzergruppe zugänglich ist, finde ich gegenüber dem ursprünglichen Fragesteller nicht fair.
[/offtopic]