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:
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:
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:
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:
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?
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
Schau an, hab es nach dem Wiki gemacht, da stand es so. Hast du dann das Problem mit den zwei : bei der Variante?
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
Werde es später mal testen, dank dir für die Info. Frage mich allerdings immer noch, wieso das state verschluckt wird :D am $EVENT=~s/://;; dürfte es ja eigentlich nicht liegen.
Ich nehme für sowas komplettes immer cloneDummy. Ausser das state werden alle Readings kopiert. Ohne weiteres zu tun.
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.
ZitatAber wieso wird state entfernt?
Damit "lamp on" nicht als "lamp state on" ankommt.
Es sei denn, man aktiviert beim notify addStateEvent (https://fhem.de/commandref.html#addStateEvent)
Zitatwenn 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.
Ok kopiert ist bisschen falsch. Für jeden Event der über FHEM2FHEM rüber kommt wird das Reading automatisch in den cloneDummy gesetzt.
Danke Rudi, die Erklärung macht Sinn. Danke an den Rest für die Tipps
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.
Zeig doch mal bitte die Events die ankommen. Also auf der Seite wo Dein cloneDummy oder dummy ist.
Hihi, da lese ich etwas rum, und finde gleich diesen Thread. :D
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 :)
Zitat von: CoolTux am 27 Juli 2017, 05:20:01
Zeig doch mal bitte die Events die ankommen. Also auf der Seite wo Dein cloneDummy oder dummy ist.
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:04Interssant ist die Zeile
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.
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.
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.
:)
Die Doppelpunkte wirst Du mit diesem Zusatz los (wie bei deinem Notify ja schon benutzt):
$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.
Kannst du bitte im Problemfall alle Events auf dem Quellsystem aufzeichnen und hier anhaengen?
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.
Das ist korrekt so. Es werden lediglich die Events des Devices übertragen. Das Löschen eines Devices ist ein globales Event.
ich meinte aber das Löschen eines Reading, nicht des Device an sich.
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.
Ok, danke. Dann muss ich mich wohl wirklich dran setzen und cloneDummy dem entsprechend anpassen.
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.
@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.
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.
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 :D
Zu deiner Frage:
Hier ein Beispiel ähnlich einem List :)
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:
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.
Hast Du bei Deinem Kalender in der Slaveinstanz ein event-on* gesetzt? Wenn ja nimm das mal raus und setze noch mal deletebevorupdate
Ne, hatte ich nicht. Hier mal ein List der Device, hilft ja alles nix ;)
Slave:
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:
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
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 ;D
c-today = 0
also alle today_ Readings löschen
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:
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.
Na Du kannst Dir ja Sachen vornehmen ;D
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
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
Einmal zum rumspielen
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
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??
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.
Das setzen habe ich mit meiner Methode geschafft gehabt. Bei dir hat vermutlich die GetNet_cloneDummy gefehlt welche vorher geprüft wird:
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.
Gern geschehen. Macht ja auch Spaß