Fhem2Fhem setreading Problem

[Amenophis86]

Im ersten Moment sah es aber so aus, als ob bei den anderen das state Reading komplett ignoriert wird und nur bei CALVIEW es komisch angezeigt wird. Habe es jetzt nochmal getestet und bei den anderen kommt es auch ähnlich an, fiel mir nur nicht direkt auf. Diese hatten ein : im Reading, damit wurden sie geteilt. Das state Reading von CALVIEW hatte kein :, daher sah es anders aus.

[Grinsekatze]

Die Doppelpunkte wirst Du mit diesem Zusatz los (wie bei deinem Notify ja schon benutzt):

Code Auswählen Erweitern

$EVENT=~s/://;;

Die muss ich bei allen meinen Notifys, die mit F2F oder RFHEM arbeiten verwenden.

Ich bin bei mir auch weiter gekommen. Nun funktioniert der Notify für RFHEM wieder - zumindest solange ich den Fernseher nicht aus mache und danach wieder an machen will - was vorher ging.
Auch habe ich in meinem Fall einen unschönen Nebeneffekt, wenn ich den Dummy so benenne, wie das Original-Device und zum befüllen darum keinen Notify nutze: Der State des Dummys weicht vom Original ab. Immer, wenn ich am Dummy schalte (und diese Befehle mittels RFHEM an das Original-Device weiterreiche), dann ist der State meines Dummys hinterher trotzdem nicht "on" bzw. "off" (wie beim Original-Device), sondern beinhaltet den letzten Befehl - z.B. "volume 10" oder "Input hdmi1". Da suche ich noch nach einer gescheiten Lösung, denn bis jetzt wirkt bestricht das Gleichbenennen mit seiner Einfachheit.

[rudolfkoenig]

Kannst du bitte im Problemfall alle Events auf dem Quellsystem aufzeichnen und hier anhaengen?

[Amenophis86]

Kann es sein, dass FHEM2FHEM keine Löschung von Readings weitergibt?

Das Problem ist, dass ich ja meine Kalender Devices ausgelagert habe auf eine zweite FHEM Instanz. Nun legt das Calview Modul Readings an für die Termine und löscht diese, wenn der Termin vorbei ist. Ich habe die beiden FHEM mittels FHEM2FHEM Verbunden und sowohl mittels cloneDummy, als auch, wenn ich einfach das Device mit gleichem Name auf dem Host anlege, werden die Readings auf dem Host nicht gelöscht. Das Event des löschen kommt auch nicht im EventMonitor an.

[CoolTux]

Das ist korrekt so. Es werden lediglich die Events des Devices übertragen. Das Löschen eines Devices ist ein globales Event.

[Amenophis86]

ich meinte aber das Löschen eines Reading, nicht des Device an sich.

[CoolTux]

Da gilt das gleiche. Schau doch einfach mal im Eventmonitor nach. Lösch mal ein Reading und schaue welches Device das löschen meldet. Es wird global sein.

[Amenophis86]

Ok, danke. Dann muss ich mich wohl wirklich dran setzen und cloneDummy dem entsprechend anpassen.

[CoolTux]

Ich habe lediglich Kalender genommen wo es reicht zu wissen das ein Termin an liegt. Feiertage und Ferien. Auf der anderen Seite setze ich dann einfach 2 Dummy mit 0 oder 1.

[Amenophis86]

@CoolTux, ich möchte aber auch die Calview Daten in meiner Hauptinstanz sehen um diese mittels TabletUI und Alexa abfragen zu können.

Ich komme einfach nicht weiter. Vielleicht hat jemand eine Idee.

Wie bereits erklärt, habe ich meine Kalenderdevice ausgelagert, da diese FHEM blockieren. Jetzt wollte ich mittels clonedummy und fhem2fhem dafür sorgen, dass diese Daten von einer anderen Instanz auf der Hauptinstanz geschrieben werden. Das schreiben klappt auch soweit. Was nicht klappt, ist, dass die nicht mehr benötigten bzw automatisch gelöschten Readings auch auf der Hauptinstanz gelöscht werden.

Das Attr deletebeforupdate bringt mir leider nichts, weil die Readings nicht im Paket kommen, sondern, weil sie einzeln kommen. Damit werden alle Readings gelöscht und nur noch das letzte Reading wird geschrieben. Hat irgendjemand eine Idee, wie ich dieses Problem gelöst bekomme? Hatte überlegt Clonedummy so zu ändern, dass ich erst alle Readings lösche und dann einfach alle Readings mir wieder ziehe. Hier ist aber das Problem, dass ich dazu auf die andere Instanz zugreifen müsste um alle Readings zu bekommen.

Dann habe ich überlegt, ob es eine Möglichkeit gibt, dass die Readings nicht einzeln rein kommen, sondern als Paket. Dafür fehlt mir aber das Verständnis und Calview arbeitet schon mit readingsbulkupdate etc.

[CoolTux]

Ist es möglich hier ein list des Devices ein zu stellen. Ich kann mir das gerade schwer vorstellen.

Im Grunde bleibt Dir wenn dann nur die Möglichkeit eine eigene sub Routine zu bauen. Hier könntest Du dann bei einem entsprechenden Event einfach die Gegenseite abfragen und die Daten nachträglich holen. Damit befüllst Du dann einen Dummy. Ist komplex ich weiß, aber was anderes fällt mir da auch nicht ein. Dir fehlt eine Kontrollinstanz. Du lässt alles cloneDummy machen und kannst halt nicht eingreifen.

[Amenophis86]

Da bin ich gerade dabei jedoch fehlt mir noch das Verständnis, wie ich eine Verbindung aufbaue und mir die Daten hole. Hatte mal irgendwo etwas von Json Abfragen gelesen oder Telnet. Suche es mir gerade zusammen bzw. lese mich ein und hoffe, dass ich es verstehe

Zu deiner Frage:
Hier ein Beispiel ähnlich einem List

Code Auswählen Erweitern

RemoteInstanz hat das Device Kalender mit den Readings:
Reading1 - Inhalt 1
Reading2 - Inhalt 2

Hauptinstanz hat den cloneDummy mit den Readings:
Reading1 - Inhalt 1
Reading2 - Inhalt 2

Nun wird durch ablaufen des Termins in Reading2 das Reading2 auf Remote Instanz gelöscht und alle Readings neu geschrieben. Das hat zur Folge, dass es nun wie folgt aussieht:

Code Auswählen Erweitern

RemoteInstanz Kalender:
Reading2 - Inhalt 2

Hauptinstanz:
Reading1 - Inhalt 1
Reading2 - Inhalt 2

Das Löschen kommt bei der Hauptinstanz nicht an. Warum hattest du mir ja bereits erklärt, dass dies von FHEM2FHEM nicht übertragen wird. Gleiches Problem, wenn ich mittels des Attr deletbeforupdate arbeite. Hier hat dies zur Folge, dass auf der Hauptinstanz alle Readings gelöscht werden, sobald ein Update der Readings entsteht. Dann bleibt nur noch das Readins übrig, welches zuletzt aktualisiert wurde und alle anderen sind weg. Warum ist das so? Weil cloneDummy bei jedem Readingsupdate getriggert wird und immer erst alle Readings löscht und nur das Reading, welches triggert schreibt.

[CoolTux]

Hast Du bei Deinem Kalender in der Slaveinstanz ein event-on* gesetzt? Wenn ja nimm das mal raus und setze noch mal deletebevorupdate

[Amenophis86]

Ne, hatte ich nicht. Hier mal ein List der Device, hilft ja alles nix

Slave:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        KL.Etienne.Arbeit_r
   INTERVAL   43200
   KALENDER   KL.Etienne.Arbeit_r
   NAME       KL.Etienne.Arbeit.Ansicht_r
   NR         30
   NTFY_ORDER 50-KL.Etienne.Arbeit.Ansicht
   STATE      t: 3 td: 0 tm: 0
   TYPE       CALVIEW
   Readings:
     2017-07-31 13:33:23   c-term          3
     2017-07-31 13:33:23   c-today         0
     2017-07-31 13:33:23   c-tomorrow      0
     2017-07-31 13:33:23   state           t: 3 td: 0 tm: 0
     2017-07-31 13:33:23   t_001_bdate     07.09.2017
     2017-07-31 13:33:23   t_001_btime     18:00:00
     2017-07-31 13:33:23   t_001_daysleft  38
     2017-07-31 13:33:23   t_001_daysleftLong in 38 Tagen
     2017-07-31 13:33:23   t_001_edate     07.09.2017
     2017-07-31 13:33:23   t_001_etime     19:00:00
     2017-07-31 13:33:23   t_001_mode      next
     2017-07-31 13:33:23   t_001_source    KL.Etienne.Arbeit_r
     2017-07-31 13:33:23   t_001_summary   Urlaub Ende
     2017-07-31 13:33:23   t_002_bdate     14.09.2017
     2017-07-31 13:33:23   t_002_btime     00:00:00
     2017-07-31 13:33:23   t_002_daysleft  45
     2017-07-31 13:33:23   t_002_daysleftLong in 45 Tagen
     2017-07-31 13:33:23   t_002_edate     15.09.2017
     2017-07-31 13:33:23   t_002_etime     00:00:00
     2017-07-31 13:33:23   t_002_mode      next
     2017-07-31 13:33:23   t_002_source    KL.Etienne.Arbeit_r
     2017-07-31 13:33:23   t_002_summary   Dienststellenausflug
     2017-07-31 13:33:23   t_003_bdate     16.11.2017
     2017-07-31 13:33:23   t_003_btime     11:00:00
     2017-07-31 13:33:23   t_003_daysleft  108
     2017-07-31 13:33:23   t_003_daysleftLong in 108 Tagen
     2017-07-31 13:33:23   t_003_edate     16.11.2017
     2017-07-31 13:33:23   t_003_etime     13:00:00
     2017-07-31 13:33:23   t_003_mode      next
     2017-07-31 13:33:23   t_003_source    KL.Etienne.Arbeit_r
     2017-07-31 13:33:23   t_003_summary   Fahrlehrer
Attributes:
   group      Kalender
   modes      next
   room       Kalender

CloneDummy:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        KL.Etienne.Arbeit.Ansicht_r
   NAME       KL.Etienne.Arbeit.Ansicht
   NDEV       KL.Etienne.Arbeit.Ansicht_r
   NR         34
   NTFY_ORDER 50-KL.Arbeit.Etienne.Ansicht
   STATE      active
   TYPE       cloneDummy
   Readings:
     2017-07-31 13:33:24   c-term          3
     2017-07-31 13:33:24   c-today         0
     2017-07-31 13:33:24   c-tomorrow      0
     2017-07-31 13:33:24   state           active
     2017-07-31 13:33:24   t               3 td: 0 tm: 0
     2017-07-31 13:33:24   t_001_bdate     07.09.2017
     2017-07-31 13:33:24   t_001_btime     18:00:00
     2017-07-31 13:33:24   t_001_daysleft  38
     2017-07-31 13:33:24   t_001_daysleftLong in 38 Tagen
     2017-07-31 13:33:24   t_001_edate     07.09.2017
     2017-07-31 13:33:24   t_001_etime     19:00:00
     2017-07-31 13:33:24   t_001_mode      next
     2017-07-31 13:33:24   t_001_source    KL.Etienne.Arbeit_r
     2017-07-31 13:33:24   t_001_summary   Urlaub Ende
     2017-07-31 13:33:24   t_002_bdate     14.09.2017
     2017-07-31 13:33:24   t_002_btime     00:00:00
     2017-07-31 13:33:24   t_002_daysleft  45
     2017-07-31 13:33:24   t_002_daysleftLong in 45 Tagen
     2017-07-31 13:33:24   t_002_edate     15.09.2017
     2017-07-31 13:33:24   t_002_etime     00:00:00
     2017-07-31 13:33:24   t_002_mode      next
     2017-07-31 13:33:24   t_002_source    KL.Etienne.Arbeit_r
     2017-07-31 13:33:24   t_002_summary   Dienststellenausflug
     2017-07-31 13:33:24   t_003_bdate     16.11.2017
     2017-07-31 13:33:24   t_003_btime     11:00:00
     2017-07-31 13:33:24   t_003_daysleft  108
     2017-07-31 13:33:24   t_003_daysleftLong in 108 Tagen
     2017-07-31 13:33:24   t_003_edate     16.11.2017
     2017-07-31 13:33:24   t_003_etime     13:00:00
     2017-07-31 13:33:24   t_003_mode      next
     2017-07-31 13:33:24   t_003_source    KL.Etienne.Arbeit_r
     2017-07-31 13:33:24   t_003_summary   Fahrlehrer
     2017-07-31 12:34:01   t_004_bdate     16.11.2017
     2017-07-31 12:34:01   t_004_btime     11:00:00
     2017-07-31 12:34:01   t_004_daysleft  108
     2017-07-31 12:34:01   t_004_daysleftLong in 108 Tagen
     2017-07-31 12:34:01   t_004_edate     16.11.2017
     2017-07-31 12:34:01   t_004_etime     13:00:00
     2017-07-31 12:34:01   t_004_mode      next
     2017-07-31 12:34:01   t_004_source    KL.Etienne.Arbeit_r
     2017-07-31 12:34:01   t_004_summary   Fahrlehrer
     2017-07-31 12:34:00   today_001_bdate heute
     2017-07-31 12:34:00   today_001_btime 12:34:00
     2017-07-31 12:34:00   today_001_daysleft 0
     2017-07-31 12:34:00   today_001_daysleftLong heute
     2017-07-31 12:34:00   today_001_edate 31.07.2017
     2017-07-31 12:34:00   today_001_etime 12:35:00
     2017-07-31 12:34:00   today_001_mode  next
     2017-07-31 12:34:00   today_001_source KL.Etienne.Arbeit_r
     2017-07-31 12:34:00   today_001_summary Test
Attributes:

Wie du siehst sind die Readings "today..." noch vorhanden

[CoolTux]

Na das sieht doch gut aus. Musst nur bisschen nacharbeiten lassen mittels Notify und/oder myUtils.

c-term
c-today
c-tomorrow

In meinem jugendlichen Leichtsinn würde ich diese Readings überprüfen lassen und je nach dem was sie sagen können Readings gelöscht werden.
Beispiel c-term = 3

Also löschst Du einfach alle t_004 Readings in der Hoffnung das die Reinfolge passt 

c-today = 0
also alle today_ Readings löschen