Fhem2Fhem setreading Problem

[Amenophis86]

Ich habe heute Fhem2Fhem eingerichtet und bekomme ständig einen setreading Fehler. Ich erkenne zwar was das Problem ist, aber kann nicht nachvollziehen woran es liegt. Hier der Stand der Dinge:

1. Remote hat das Device KL.Abfall.Ansicht_r:

Code Auswählen Erweitern

Internals:
   DEF        KL.Abfall_r
   KALENDER   KL.Abfall_r
   NAME       KL.Abfall.Ansicht_r
   NR         21
   NTFY_ORDER 50-Abfall
   STATE      2
   TYPE       ABFALL
   READINGS:
     2017-07-26 20:07:28   KLAbfall_r_EFBAltpapier_datum 09.08.17
     2017-07-26 20:07:28   KLAbfall_r_EFBAltpapier_tage 14
     2017-07-26 20:07:28   KLAbfall_r_EFBAltpapier_text   EFB Altpapier
     2017-07-26 20:07:28   KLAbfall_r_EFBAltpapier_wochentag Mittwoch
     2017-07-26 20:07:28   KLAbfall_r_EFBBioabfall_datum 28.07.17
     2017-07-26 20:07:28   KLAbfall_r_EFBBioabfall_tage 2
     2017-07-26 20:07:28   KLAbfall_r_EFBBioabfall_text   EFB Bioabfall
     2017-07-26 20:07:28   KLAbfall_r_EFBBioabfall_wochentag Freitag
     2017-07-26 20:07:28   KLAbfall_r_EFBGelberSack_datum 28.07.17
     2017-07-26 20:07:28   KLAbfall_r_EFBGelberSack_tage 2
     2017-07-26 20:07:28   KLAbfall_r_EFBGelberSack_text   EFB Gelber Sack
     2017-07-26 20:07:28   KLAbfall_r_EFBGelberSack_wochentag Freitag
     2017-07-26 20:07:28   KLAbfall_r_EFBRestabfall_datum 26.07.17
     2017-07-26 20:07:28   KLAbfall_r_EFBRestabfall_tage 0
     2017-07-26 20:07:28   KLAbfall_r_EFBRestabfall_text   EFB Restabfall
     2017-07-26 20:07:28   KLAbfall_r_EFBRestabfall_wochentag Mittwoch
     2017-07-26 20:07:28   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_datum 05.09.17
     2017-07-26 20:07:28   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_tage 41
     2017-07-26 20:07:28   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_text   EFB Schadstoffmobil im Abfuhrbezirk
     2017-07-26 20:07:28   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_wochentag Dienstag
     2017-07-26 20:07:28   next            KLAbfall_r_EFBGelberSack|KLAbfall_r_EFBBioabfall_2
     2017-07-26 20:07:28   next_datum      28.07.17
     2017-07-26 20:07:28   next_tage       2
     2017-07-26 20:07:28   next_text         EFB Gelber Sack und   EFB Bioabfall
     2017-07-26 20:07:28   next_wochentag  Freitag
     2017-07-26 20:07:28   now             KLAbfall_r_EFBRestabfall
     2017-07-26 20:07:28   now_datum       26.07.17
     2017-07-26 20:07:28   now_text          EFB Restabfall
     2017-07-26 20:07:28   now_wochentag   Mittwoch
     2017-07-26 20:07:28   state           2
Attributes:
   group      Abfall,Kalender
   room       Z_Externe
   verbose    3

2. Local hat einen Dummy KL.Abfall.Ansicht:

Code Auswählen Erweitern

Internals:
   CFGFN
   NAME       KL.Abfall.Ansicht
   NR         4928
   STATE      In 2 Tagen EFB Bioabfall und   EFB Gelber Sack
   TYPE       dummy
   READINGS:
     2017-07-26 20:14:59   KLAbfall_r_EFBAltpapier_datum 09.08.17
     2017-07-26 20:14:59   KLAbfall_r_EFBAltpapier_tage 14
     2017-07-26 20:14:59   KLAbfall_r_EFBAltpapier_text EFB Altpapier
     2017-07-26 20:14:59   KLAbfall_r_EFBAltpapier_wochentag Mittwoch
     2017-07-26 20:14:58   KLAbfall_r_EFBBioabfall_datum 28.07.17
     2017-07-26 20:14:58   KLAbfall_r_EFBBioabfall_tage 2
     2017-07-26 20:14:58   KLAbfall_r_EFBBioabfall_text EFB Bioabfall
     2017-07-26 20:14:58   KLAbfall_r_EFBBioabfall_wochentag Freitag
     2017-07-26 20:14:59   KLAbfall_r_EFBGelberSack_datum 28.07.17
     2017-07-26 20:14:58   KLAbfall_r_EFBGelberSack_tage 2
     2017-07-26 20:14:59   KLAbfall_r_EFBGelberSack_text EFB Gelber Sack
     2017-07-26 20:14:59   KLAbfall_r_EFBGelberSack_wochentag Freitag
     2017-07-26 20:14:58   KLAbfall_r_EFBRestabfall_datum 26.07.17
     2017-07-26 20:14:58   KLAbfall_r_EFBRestabfall_tage 0
     2017-07-26 20:14:58   KLAbfall_r_EFBRestabfall_text EFB Restabfall
     2017-07-26 20:14:58   KLAbfall_r_EFBRestabfall_wochentag Mittwoch
     2017-07-26 20:14:59   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_datum 05.09.17
     2017-07-26 20:14:59   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_tage 41
     2017-07-26 20:14:59   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_text EFB Schadstoffmobil im Abfuhrbezirk
     2017-07-26 20:14:59   KLAbfall_r_EFBSchadstoffmobilimAbfuhrbezirk_wochentag Dienstag
     2017-07-26 20:14:59   next            KLAbfall_r_EFBBioabfall|KLAbfall_r_EFBGelberSack_2
     2017-07-26 20:15:00   next_datum      28.07.17
     2017-07-26 20:15:00   next_tage       2
     2017-07-26 20:15:00   next_text       EFB Bioabfall und   EFB Gelber Sack
     2017-07-26 20:15:00   next_wochentag  Freitag
     2017-07-26 20:14:59   now             KLAbfall_r_EFBRestabfall
     2017-07-26 20:14:59   now_datum       26.07.17
     2017-07-26 20:14:59   now_text        EFB Restabfall
     2017-07-26 20:14:59   now_wochentag   Mittwoch
     2017-07-26 20:15:00   state           In 2 Tagen EFB Bioabfall und   EFB Gelber Sack
Attributes:
   group      Kalender

3. Und ein notify um den Dummy zu befüllen NO.KL.Abfall.Ansicht:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        KL.Abfall.Ansicht_r {$EVENT=~s/://;; fhem("setreading KL.Abfall.Ansicht $EVENT");; my $tag = ReadingsVal("KL.Abfall.Ansicht","next_tage","error");; my $text = ReadingsVal("KL.Abfall.Ansicht","next_text","error");; fhem("setreading KL.Abfall.Ansicht state In $tag Tagen $text");;}
   NAME       NO.KL.Abfall.Ansicht
   NR         4591
   NTFY_ORDER 50-NO.KL.Abfall.Ansicht
   REGEXP     KL.Abfall.Ansicht_r
   STATE      active
   TYPE       notify
   READINGS:
     2017-07-26 20:07:48   state           active
Attributes:
   group      Kalender
   room       Z_Notify
   verbose    3

Nun bekomme ich immer folgenden Fehler im Log:

Code Auswählen Erweitern

2017.07.26 20:07:30 3: setreading KL.Abfall.Ansicht 2 : Usage: setreading <name> <reading> <value>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.

Das Problem ist wohl, dass beim Reading "state" von KL.Abfall.Ansicht_r das state entfernt wird und somit in "$EVENT" nur noch die 2 drinnen steckt. Damit ist der Befehle "setreading KL.Abfall.Ansicht 2" und nicht "setreading KL.Abfall.Ansicht state 2". Aber wieso wird state entfernt?

[Otto123]

Hi,

ich habe keine Antwort auf Deine Frage. Aber ich habe letztens gelernt, wenn Du einen dummy mit gleichen Namen hast wie im Remote System wird per F2F alles einfach in den dummy kopiert.

Ob das Dein Problem löst weiß ich nicht, aber wenn ist es einfacher als Dein Konstrukt.

Gruß Otto

[Amenophis86]

Schau an, hab es nach dem Wiki gemacht, da stand es so. Hast du dann das Problem mit den zwei : bei der Variante?

[Otto123]

Keine Ahnung, ich habe es nur mit presence devices gemacht. Hatte da vorher auch ein kompliziertes Konstrukt mit notify. Und früher nahm man dafür clonedummy, hatte dann mal gelesen braucht man nicht mehr.


Gruß Otto

[Amenophis86]

Werde es später mal testen, dank dir für die Info. Frage mich allerdings immer noch, wieso das state verschluckt wird am

Code Auswählen Erweitern

$EVENT=~s/://;; dürfte es ja eigentlich nicht liegen.

[CoolTux]

Ich nehme für sowas komplettes immer cloneDummy. Ausser das state werden alle Readings kopiert. Ohne weiteres zu tun.

[Amenophis86]

Hätte mir clonedummy genauer anschauen sollte undvdas Wiki muss ich wohl auch mal überarbeiten und drauf hinweisen, der scheint ja alles automatisch zu machen. Werde es später mal versuchen, danke.

[rudolfkoenig]

Aber wieso wird state entfernt?

Damit "lamp on" nicht als "lamp state on" ankommt.
Es sei denn, man aktiviert beim notify addStateEvent

wenn Du einen dummy mit gleichen Namen hast wie im Remote System wird per F2F alles einfach in den dummy kopiert.

Um genau zu sein, irgendetwas mit dem gleichen Namen.

[CoolTux]

Ok kopiert ist bisschen falsch. Für jeden Event der über FHEM2FHEM rüber kommt wird das Reading automatisch in den cloneDummy gesetzt.

[Amenophis86]

Danke Rudi, die Erklärung macht Sinn. Danke an den Rest für die Tipps

[Amenophis86]

kann es sein, dass das Modul Abfall anders mit dem Reading state umgeht, als die anderen? Nur hier kommt nämlich der Fehler und state wird auch automatisch mit übertragen.

[CoolTux]

Zeig doch mal bitte die Events die ankommen. Also auf der Seite wo Dein cloneDummy oder dummy ist.

[Grinsekatze]

Hihi, da lese ich etwas rum, und finde gleich diesen Thread. 

Ich optimiere gerade mal wieder meine TV-Schaltung (hab ich an anderer Stelle hier im Forum ja öfters mal behandelt): Ich clone (mittels Notify) ein Device einer zweiten FHEM-Instanz. Mittels eines zweiten Notifys (und RFHEM) kann ich dann das Device über den Dummy des Hauptsystems steuern.

Den von Amenophis86 ursprünglich angesprochenen "Fehler" hatte ich in meiner Konfiguration zunähst auch. Da es bei mir aber nur "on" und "off" als state gibt, habe ich in meinem Notify zum befüllen des Dummys eine Bedingung eingefügt: "unless (($EVENT eq "on") | ($EVENT eq "off")) { [...] }". So konnte ich den Fehler unterdrücken.

Das ist leider alles ziemlich umständlich (und ohne ein event-on-change) bekomme ich eine endlosschleife der beiden Notifys. Da freut es mich zu lesen, dass ich mir den ersten Notify sparen kann, wenn ich Dummy und Ur-Device gleich benenne (zzt. hat der Dummy ein "_remote" hinter dem Namen).

Das probiere ich heute Abend gleich mal aus

[Amenophis86]

Zeig doch mal bitte die Events die ankommen. Also auf der Seite wo Dein cloneDummy oder dummy ist.

Code Auswählen Erweitern

2017-07-27 11:05:04 Calendar KL.Abfall retrieved
2017-07-27 11:05:04 Calendar KL.Abfall parsed
2017-07-27 11:05:04 Calendar KL.Abfall lastUpdate: 2017-07-27 11:05:04
2017-07-27 11:05:04 Calendar KL.Abfall nextUpdate: 2017-07-27 12:05:04
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBBioabfall_tage: 1
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBBioabfall_text:   EFB Bioabfall
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBBioabfall_datum: 28.07.17
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBBioabfall_wochentag: Freitag
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBGelberSack_tage: 1
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBGelberSack_text:   EFB Gelber Sack
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBGelberSack_datum: 28.07.17
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBGelberSack_wochentag: Freitag
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBRestabfall_tage: 13
2017-07-27 11:05:04 dummy KL.Abfall.Ansicht KLAbfall_EFBRestabfall_text:   EFB Restabfall
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBRestabfall_datum: 09.08.17
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBRestabfall_wochentag: Mittwoch
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBAltpapier_tage: 13
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBAltpapier_text:   EFB Altpapier
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBAltpapier_datum: 09.08.17
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBAltpapier_wochentag: Mittwoch
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBSchadstoffmobilimAbfuhrbezirk_tage: 40
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBSchadstoffmobilimAbfuhrbezirk_text:   EFB Schadstoffmobil im Abfuhrbezirk
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBSchadstoffmobilimAbfuhrbezirk_datum: 05.09.17
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht KLAbfall_EFBSchadstoffmobilimAbfuhrbezirk_wochentag: Dienstag
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht next: KLAbfall_EFBBioabfall|KLAbfall_EFBGelberSack_1
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht next_tage: 1
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht next_text:   EFB Bioabfall und   EFB Gelber Sack
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht next_datum: 28.07.17
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht next_wochentag: Freitag
2017-07-27 11:05:05 dummy KL.Abfall.Ansicht 1
2017-07-27 11:05:05 Calendar KL.Abfall modeUpcoming: 149182525749muellmaxde;149182525753muellmaxde;149182525751muellmaxde;149182525727muellmaxde;149182525746muellmaxde;149182525710muellmaxde;149182525742muellmaxde;149182525764muellmaxde;149182525744muellmaxde;149182525728muellmaxde;149182525745muellmaxde;149182525760muellmaxde;149182525711muellmaxde;149182525716muellmaxde;149182525766muellmaxde;149182525763muellmaxde;149182525765muellmaxde;149182525712muellmaxde;149182525768muellmaxde;149182525747muellmaxde;149182525754muellmaxde;149182525750muellmaxde;149182525726muellmaxde;149182525743muellmaxde;149182525724muellmaxde;149182525715muellmaxde;149182525759muellmaxde;149182525713muellmaxde;149182525725muellmaxde;149182525761muellmaxde;149182525717muellmaxde;149182525748muellmaxde;149182525762muellmaxde;149182525740muellmaxde;149182525718muellmaxde;149182525752muellmaxde;149182525719muellmaxde;149182525714muellmaxde;14918252579muellmaxde;149182525741muellmaxde
2017-07-27 11:05:05 Calendar KL.Abfall modeEnd: 14918252573muellmaxde;14918252578muellmaxde;149182525730muellmaxde;149182525756muellmaxde;149182525723muellmaxde;14918252576muellmaxde;14918252575muellmaxde;149182525755muellmaxde;149182525739muellmaxde;149182525734muellmaxde;149182525733muellmaxde;149182525767muellmaxde;149182525722muellmaxde;14918252577muellmaxde;149182525720muellmaxde;149182525758muellmaxde;149182525737muellmaxde;149182525721muellmaxde;149182525731muellmaxde;149182525729muellmaxde;14918252571muellmaxde;149182525732muellmaxde;149182525735muellmaxde;14918252574muellmaxde;149182525757muellmaxde;149182525736muellmaxde;14918252572muellmaxde;149182525738muellmaxde
2017-07-27 11:05:05 Calendar KL.Abfall triggered
2017-07-27 11:05:05 Calendar KL.Abfall nextWakeup: 2017-07-27 12:05:04

Interssant ist die Zeile

Code Auswählen Erweitern

2017-07-27 11:05:05 dummy KL.Abfall.Ansicht 1 Diese hatte ich bereits zu beginn des Thread gesehen und mich gewundert, wieso hier "state" fehlt. Somit sieht es für mich aus, dass bei diesem Modul das Reading state übertragen wird, aber das Wort "state" rausgefiltert wird. Schaue ich mir andere Devices und die Events an, dann fehlt die komplette state Zeile.

[Grinsekatze]

Wenn Du F2F benutzt, wie im Wiki beschrieben, dann wird kein state an den Dummy übergeben. Darum ist in den Beispielen im Wiki auch ein eigener State aus den übergebenen Werten zusammengebaut worden.

Ich habe eben mal ausprobiert, Ursprüngliches Device und den "Clone"-Dummy gleich zu benennen. Dann werden alle Readings übergeben, auch der state und ganz ohne einen Notify o.Ä. nutzen zu müssen.

Bei mir funktioniert nun lediglich der RFHEM-Notify nicht mehr (auch nachdem ich dort das zu triggernde Device/Dummy angepasst habe. Keine Ahnung warum.


Warum bei Dir nur die 1 ankommt hat Rudi doch schon geschrieben.

[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

[Amenophis86]

Das hatte ich auch schon überlegt so zu machen und ist wahrscheinlich die einfachste Variante. Aber jetzt hat mich so ein bisschen der Ehrgeiz gepackt cloneDummy entsprechend anzupassen, dass er die Readings vom Slave holt und reinschreibt.

Bin inzwischen auch soweit, dass ich verstanden habe, wie ich mittels jsonlist2 die Abfrage mache. Bekomme es nur noch nicht in eine Variable. So mein entsprechender Code aktuell:

Code Auswählen Erweitern

if(AttrVal($hn,'GetAllReadings',0) == 1)
  {
   my $host = AttrVal($hn,'Host','error');
   my $hostport = AttrVal($hn,'Port','error');
   my $password = AttrVal($hn,'Password','error') if(AttrVal($hn,'Password',0));
   my $abfrage = "jsonlist2 $dn";
   
   my $socket = IO::Socket::INET->new('PeerAddr' => $host,'PeerPort' => $hostport,'Proto' => 'tcp') ;
   my @values =  cloneDummy_GetNet($hash,$host);
if ( $values[1] eq "present")
{
# Log3 $hash->{NAME}, 3, "Host present, executing command...";
syswrite($socket, $password . "\n")if($password);
    my $ergebnis = print $socket $abfrage;
# Log3 $hash->{NAME}, 3, "Command executed.";
Log3 $hash->{NAME}, 3, $ergebnis;
}
else { Log3 $hash->{NAME}, 3, "Error: host not present!"; }

Allerdings ist $ergebnis nur 1 und nicht der Json string.

[CoolTux]

Na Du kannst Dir ja Sachen vornehmen 

Versuch als fhem Befehl erstmal ein dummy zu setzen um zu schauen das überhaupt was passiert.
Und bei beim telnet Aufruf auf alle Fälle ein Timeout ein sonst kann es passieren das FHEM ewig hängt.

Ich schau mal ob das ganze telnet gedöns soweit passt

[CoolTux]

Code Auswählen Erweitern


my $socket = new Net::Telnet ( Host=>$host,
        Port => 7072,
        Timeout=>5,
        Errmode=>'return')
        or return Log3 $hash->{NAME}, 3, "Can't connect";


Versuch mal bitte. Habe leider nicht die Möglichkeit gerade mal eben zu testen

[CoolTux]

Einmal zum rumspielen

Code Auswählen Erweitern


use Net::Telnet;
sub telnetLeon($) {

     my $cmd = shift;
     my $socket = new Net::Telnet ( Host=>'localhost',
        Port => 7073,
        Prompt => '/\$ $/i',
        Errmode=>'return')
        or return Log3 'ich', 3, "Can't connect";

     $socket->open;
     my $ergebnis = print $socket->cmd($cmd);

     return $ergebnis;
}


Auf telnet Port 7073 läuft eine zweite FHEM Instanz. den darin enthaltenen Dummy konnte ich mit
{ telnetLeon('set testdummy on')}
schalten. Aber es dauert recht lange. Das kann aber am return liegen. ich arbeite nun an den Feinheiten

[Amenophis86]

Ich habe als Grundlage das RFHEM Modul genommen und mir das die Sachen rausgesucht. Das klappt auch soweit. ist Net::Telnet besser, als IO::Socket::INET??

[CoolTux]

Kann ich Dir nicht beantworten.
Ich kann Dir nur sagen das ich es geschafft habe damit einen Dummy zu schalten. Was ich mit Deiner Variante nicht geschafft habe. Hänge aber nun auch bei der Rückgabe der jsonlist2 Ausgabe.

[Amenophis86]

Das setzen habe ich mit meiner Methode geschafft gehabt. Bei dir hat vermutlich die GetNet_cloneDummy gefehlt welche vorher geprüft wird:

Code Auswählen Erweitern

sub cloneDummy_GetNet($$)
{
my ($hash, $hostname) = @_;
my $name  = $hash->{NAME};
my $netstate ;
my @return ;
my @a ;
my $ip ;
my $erg = `ping -c 1 -w 2 $hostname` ;
if( $erg =~ m/100%/)
{
$ip = "0.0.0.0";
$netstate = "absent";
@return =($ip,$netstate);
return @return;
}
elsif( $erg =~ m/ping: unknown host/)
{
$ip = "0.0.0.0";
$netstate = "unknown";
@return =($ip,$netstate);
return @return;
}
elsif( $erg =~ m/0%/ )
{
@a = split(" ", $erg);
$ip = $a[2];
$ip =~ tr/(//ds;
$ip =~ tr/)//ds;
$netstate = "present";
@return =($ip,$netstate);
return @return;
}
}

hänge aber auch an der Rückgabe. Kann leider auch nicht weiter machen heute, sonder erst wieder die Tage. Werde mit den Notify erstmal arbeiten müssen und die Tage schauen, ob ich es mit cloneDummy weiter bearbeiten kann. Reizt mich ja eigentlich schon Ich danke dir schon mal für die Hilfe bisher.

[CoolTux]

Gern geschehen. Macht ja auch Spaß