FB_CALLLIST connection-mapping geht nach Neustart verloren

Begonnen von dolittle, 31 Dezember 2017, 09:27:16

Vorheriges Thema - Nächstes Thema

dolittle

Hallo zusammen,
mein Problem ist, dass ich für meine Anruferliste ein recht umfangreiches Mapping für die Klartextanzeige der genutzten Endgeräte gemacht habe. Und weil ich gerne automatisiere sieht das bei mir so aus.


attr Anrufliste connection-mapping
{ 'DECT_1' => ReadingsVal("FritzBox", "dect1", "DECT_1"), 'DECT_2' => ReadingsVal("FritzBox", "dect2", "DECT_2"),
'DECT_3' => ReadingsVal("FritzBox", "dect3", "DECT_3"), 'DECT_4' => ReadingsVal("FritzBox", "dect4", "DECT_4"),
'DECT_5' => ReadingsVal("FritzBox", "dect5", "DECT_5"), 'DECT_6' => ReadingsVal("FritzBox", "dect6", "DECT_6"),
'Answering_Machine_1' => ReadingsVal("FritzBox", "tam1", "Answering_Machine_1"),
'Answering_Machine_2' => ReadingsVal("FritzBox", "tam2", "Answering_Machine_2") }

Die Zeilenumbrüche sind im Original nicht enthalten, das ist hier nur für die bessere Lesbarkeit gemacht.

Das funktioniert grundsätzlich auch prima (Screenshot 2017-12-31 09_08_39-fbcallist_error.png), aber nach dem FHEM Neustart scheint das Modul die Einstellung zu vergessen, denn dann findet das mapping nicht mehr statt (Siehe screenshot 2017-12-31 09_08_39-fbcallist_error.png), obwohl das Attribut noch wie oben angezeigt wird.
Setzt man das attribut mit den exakt selben Werten erneut, z.B. in der Weboberfläche durch Anklicken von connection-mapping und anschließender Bestätigung über den Button attrib, dann ist wieder alles wie es sein soll.

Komisch ist dabei auch, dass dies mit dem external Mapping nicht passiert. Das ist aber auch nicht dynamisch.
attr Anrufliste external-mapping { 'SIP1' => 'Telekom','SIP2' => 'Telekom' }

Vielleicht stehen ja die Fritzbox Daten zu dem Zeitpunkt an dem das Modul geladen wird nicht zur Verfügung. Wenn ja, hätte da jemand vielleicht eine Idee, wie man das lösen könnte. Schön wäre, wenn man nicht einen Event dafür bräuchte.

Vielen Dank im Voraus für Eure Ideen und einen guten Rutsch nach 2018

Markus Bloch

Das liegt daran, dass beim Start die Readings erst nach dem Define geladen werden. Zum Zeitpunkt des Define stehen also die Readings noch nicht zur Verfügung, weswegen das Mapping so dann nicht funktioniert.

Ein variables Mapping war eigentlich nicht vorgesehen von meiner Seite. Wenn man das Mapping variabel gestalten möchte, so müsste ich das Parsen erst dann durchführen, wenn die Initialisierung beendet ist.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dolittle

Zitat von: Markus Bloch am 31 Dezember 2017, 16:14:06
Das liegt daran, dass beim Start die Readings erst nach dem Define geladen werden. Zum Zeitpunkt des Define stehen also die Readings noch nicht zur Verfügung, weswegen das Mapping so dann nicht funktioniert.

Ein variables Mapping war eigentlich nicht vorgesehen von meiner Seite. Wenn man das Mapping variabel gestalten möchte, so müsste ich das Parsen erst dann durchführen, wenn die Initialisierung beendet ist.

Vielen Dank für die Erklärung. So etwas in der Richtung habe ich mir schon gedacht, auch wenn ich es nicht so schön hätte sagen können.

Ich finde den Mechanismus sehr schön. Wenn es keine Abwärtsinkompatibilitäten gibt und die Änderung einfach zu machen wäre, dann würde ich mich darüber sehr freuen.

Vielen Dank noch einmal für die schnelle Antwort.

Dolittle

Markus Bloch

Hallo Dolittle,

ich habe soeben eine Änderung im SVN eingecheckt, wodurch sämtliche Mapping-Tables erst nach dem Abschluss der Initialisierung von FHEM evaluiert werden. Dadurch stehen dann die Readings von anderen Definitionen bereits zur Verfügung und können verwendet werden.

Gibt es ab morgen via update.

Viele Grüße

Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dolittle