Man sieht das in den LogBildern unten angehängt oberes >Log vom CloneDummy, unteres Log von normalen Dummy mit Notify Events kommen also,
Mein Hauptfhem bekommt über F2F Events von meiner Heizung , die dann über cloneDummy dargestellt/eingesammelt werden.
Die Events kommen alle 3 Minuten
Als Beispiel
define Hz_c cloneDummy 2_Heizung_anschaltung
attr Hz_c event-on-change-reading .*
attr Hz_c room Hz_syt
Das normale Dummy und Notify hab ich erst gestern angelegt um zu zeigen dass die Events über F2F kommen.
define THz_c dummy
attr THz_c event-on-change-reading .*
attr THz_c room test3
define TN_Hz_c notify 2_Heizung_anschaltung.* {fhem("setreading THz_c $EVENT")}
attr TN_Hz_c disable 0
attr TN_Hz_c room test3
das CloneDummy hab ich auch mal mit verbose 4 geloggt, und da sieht man auch, dass da knapp eine halbe Stunde keine Events verarbeitet werden.
2016.12.10 16:08:18.825 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: ID-Vito: 20c8
2016.12.10 16:08:18.826 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <ID-Vito: 20c8>
2016.12.10 16:08:21.828 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Aussentemp: 4.6
2016.12.10 16:08:21.829 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Aussentemp: 4.6>
2016.12.10 16:08:24.826 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: WW: 52.9
2016.12.10 16:08:24.827 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <WW: 52.9>
2016.12.10 16:08:27.824 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Kessel: 48
2016.12.10 16:08:27.825 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Kessel: 48>
2016.12.10 16:08:30.832 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Brennerleistung: 0
2016.12.10 16:08:30.833 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Brennerleistung: 0>
2016.12.10 16:08:33.833 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStarts: 6331
2016.12.10 16:08:33.834 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStarts: 6331>
2016.12.10 16:08:33.851 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStartsToday: 1.00
2016.12.10 16:08:33.852 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStartsToday: 1.00>
2016.12.10 16:08:33.866 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStartsDayStart: 6330.00
2016.12.10 16:08:33.867 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStartsDayStart: 6330.00>
2016.12.10 16:08:36.829 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Speichereladepumpe: off
2016.12.10 16:08:36.829 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Speichereladepumpe: off>
2016.12.10 16:08:39.829 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Umwaelzpumpe: off
2016.12.10 16:08:39.829 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Umwaelzpumpe: off>
2016.12.10 16:31:14.049 3: CUL_HM set wz_Roll3 78 %
2016.12.10 16:31:14.597 3: CUL_HM set wz_Roll2 43
2016.12.10 16:35:18.938 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: ID-Vito: 20c8
2016.12.10 16:35:18.939 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <ID-Vito: 20c8>
2016.12.10 16:35:21.945 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Aussentemp: 3.7
2016.12.10 16:35:21.945 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Aussentemp: 3.7>
2016.12.10 16:35:24.948 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: WW: 52.7
2016.12.10 16:35:24.949 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <WW: 52.7>
2016.12.10 16:35:27.946 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Kessel: 47
2016.12.10 16:35:27.947 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Kessel: 47>
2016.12.10 16:35:30.947 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Brennerleistung: 0
2016.12.10 16:35:30.948 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Brennerleistung: 0>
2016.12.10 16:35:33.958 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStarts: 6331
2016.12.10 16:35:33.959 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStarts: 6331>
2016.12.10 16:35:33.976 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStartsToday: 1.00
2016.12.10 16:35:33.976 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStartsToday: 1.00>
2016.12.10 16:35:33.991 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStartsDayStart: 6330.00
2016.12.10 16:35:33.991 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStartsDayStart: 6330.00>
2016.12.10 16:35:36.955 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Speichereladepumpe: off
2016.12.10 16:35:36.955 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Speichereladepumpe: off>
2016.12.10 16:35:39.961 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Umwaelzpumpe: off
2016.12.10 16:35:39.961 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Umwaelzpumpe: off>
2016.12.10 16:35:42.966 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: HZ_Status: WW
2016.12.10 16:35:42.967 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <HZ_Status: WW>
2016.12.10 16:35:45.978 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStunden: 1218.32
2016.12.10 16:35:45.978 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStunden: 1218.32>
2016.12.10 16:35:46.004 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStundenToday: 0.36
2016.12.10 16:35:46.004 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStundenToday: 0.36>
2016.12.10 16:35:46.018 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStundenDayStart: 1217.96
2016.12.10 16:35:46.019 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStundenDayStart: 1217.96>
2016.12.10 16:35:48.990 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStunden2: 498.38
2016.12.10 16:35:48.991 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStunden2: 498.38>
2016.12.10 16:35:49.005 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStunden2Today: 0.24
2016.12.10 16:35:49.006 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStunden2Today: 0.24>
2016.12.10 16:35:49.020 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: BrennerStunden2DayStart: 498.14
2016.12.10 16:35:49.021 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <BrennerStunden2DayStart: 498.14>
2016.12.10 16:35:51.993 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: SystemZeit: Sa,10.12.2016 16:35:48
2016.12.10 16:35:51.994 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <SystemZeit: Sa,10.12.2016 16:35:48>
2016.12.10 16:35:55.019 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: HZ-Kennlinie-Neigung: 0.3
2016.12.10 16:35:55.020 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <HZ-Kennlinie-Neigung: 0.3>
2016.12.10 16:35:58.028 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: HZ-Kennlinie-Niveau: 29
2016.12.10 16:35:58.029 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <HZ-Kennlinie-Niveau: 29>
2016.12.10 16:36:01.033 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: Rl: 41.3
2016.12.10 16:36:01.034 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <Rl: 41.3>
2016.12.10 16:36:01.072 4: cloneDummy: HASH(0x2c24e88) D: 2_Heizung_anschaltung R: UpdateTime: 2016-12-10_16:36:00
2016.12.10 16:36:01.073 4: cloneDummy: publish unique <2_Heizung_anschaltung> <Hz_c> <UpdateTime: 2016-12-10_16:36:00>
Die Linien im SVG werden mit Steps gemalt.
2016.12.08 14:02:05.132 0: Server started with 277 defined entities (fhem.pl:12519/2016-11-07 perl:5.014002 os:linux user:fhem pid:3435)
Meine Tests ergaben bis jetzt
Bis
fhem.pl:11922/2016-08-08 perl:5.014002 os:linux user:fhem pid:2979
funktioniert
fhem.pl:12519/2016-11-07 und
fhempl vom 17.12, wieder fehlende Einträge über ConeDummy
2016.12.17 22:02:34.023 0: Server started with 283 defined entities (fhem.pl:12804/2016-12-17 perl:5.014002 os:linux user:fhem pid:4617)
Auf einem zweiten System, zeigt sich das gleiche Verhalten von CloneDummy und fhem.pl .
Das ganze Konstrukt lief seit 1.2014 bisher "fehlerfrei"
Hat irgendjemand Ideen, was ich noch bieten könnte
cloneDummy funktioniert nicht mehr korrekt, also umgestellt auf dummy und notify.
ist total ärgerlich :(
sind ja nur ca 30 Stück. und stelle gerade fest das eine nichtsortierte fhem.cfg scheixxe zum bearbeiten ist,
über das Webif geht es garnicht , bzw nur über löschen und neu anlegen, also so langweilig ist es mir nun auch nicht
schade dass sich Rudi der fhem.pl Modul Autor ist , sich nicht angesprochen fühlt.
Zitat von: fhem-hm-knecht am 18 Dezember 2016, 20:02:11
Hat irgendjemand Ideen, was ich noch bieten könnte
- Die genaue fhem.pl Version ermitteln ab der der Fehler autritt.
- Für jede der beiden Instanzen eine minimale fhem-demo.cfg bereit stellen, mit denen man das Problem nachvollziehen kann. Events dabei ggf. über ein at erzeugen lassen.
Zitat von: fhem-hm-knecht am 25 Dezember 2016, 01:31:14
schade dass sich Rudi der fhem.pl Modul Autor ist , sich nicht angesprochen fühlt.
Auch für Rudi ist gerade Weihnachten.
Ausserdem deutet der von Dir vergebene Thread-Titel eher auf ein cloneDummy Problem hin, und dafür würde ich mich an Rudis Stelle auch nicht angesprochen fühlen.
Wie betateilchen schreibt, ich habe mich beim ersten Posting nicht betroffen gefuehlt habe, und deswegen die Diskussion nicht abonniert. Ich fuehle mich immer noch nicht dafuer zustaendig Module zu reparieren wenn sie nach fhem.pl Aenderungen nicht funktionieren, es sei denn der Modul-Maintainer bittet mich um konkrete Hilfe.
Vermutlich liegt das Problem daran, dass bei Verwendung von NOTIFYDEV in fhem.pl ab Rel 12386 nur definierte Geraete beachtet werden, und keine temporaer (wie von FHEM2FHEM) angelegte. Ein Workaround ist alle per cloneDummy ueberwachten Geraete auch mit define anzulegen.
Ich bin bereit Alternativen in fhem.pl anzubieten, will aber cloneDummy nicht fixen/uebernehmen/testen/etc.
Wenn das Modul keinen Maintainer hat und nicht funktioniert, dann sollte es nach contrib geschoben werden.
Vermutlich waere die bessere Loesung in FHEM2FHEM readingsSingleUpdate() statt DoTrigger() aufzurufen, dann koennte man cloneDummy sparen, und einfach ein dummy verwenden. Uebersehe ich etwas?
Zitat von: rudolfkoenig am 27 Dezember 2016, 11:23:28
Vermutlich liegt das Problem daran, dass bei Verwendung von NOTIFYDEV in fhem.pl ab Rel 12386 nur definierte Geraete beachtet werden, und keine temporaer (wie von FHEM2FHEM) angelegte. Ein Workaround ist alle per cloneDummy ueberwachten Geraete auch mit define anzulegen.
Ich bin bereit Alternativen in fhem.pl anzubieten, will aber cloneDummy nicht fixen/uebernehmen/testen/etc.
Wenn das Modul keinen Maintainer hat und nicht funktioniert, dann sollte es nach contrib geschoben werden.
Es gibt zwar einen Maintainer (ich stand auch vor einiger Zeit schon wegen eines anderen Problems im Modul in Kontakt mit ihm) er scheint aber ziemlich im Streß zu sein.
Da cloneDummy ursprünglich auf einer Idee von mir beruht, werde ich mich des Themas (vorübergehend) wieder annehmen. Auf die Sache mit dem NOTIFYDEV war ich schon gestoßen, ich werde mal schauen, ob ich mit Deinen gegebenen Tipps schon weiterkomme.
Danke Rudi , dass du trotzdem mal geschaut hast.
Die Beitrag war auch nicht gedacht, dass du es reparieren sollst, sondern dass der auftretende Fehler erkannt wird,
ZitatVermutlich liegt das Problem daran, dass bei Verwendung von NOTIFYDEV in fhem.pl ab Rel 12386 nur definierte Geraete beachtet werden, und keine temporaer (wie von FHEM2FHEM) angelegte.
Der Satz von dir wirft bei mir neue Fragen auf, bzw wie man das verstehen darf.
Heißt das , dass auch FileLog davon betroffen ist?
Ich habe z.B. auch auf einer anderen Instanz FileLog Definitionen, die sich aus F2F Events ernähren. und es auch keine Defines des zu loggenden Device haben
z.B.
define banane FHEM2FHEM 192.168.2.104:7072 LOG:.*
define FileLog_AussenTemp FileLog ./log/AussenTemp-%Y.log AussenTemp:T:.*
define FileLog_og_Wohnzimmer FileLog ./log/og_Wohnzimmer-%Y.log og_Wohnzimmer:T:.*
.....
ZitatHeißt das , dass auch FileLog davon betroffen ist?
Nur in speziellen Faellen: falls man im FileLog Regexp explizit zwischen 2 und 5 Geraete per | definiert hat, und einige/alle auf dem FileLog-FHEM nicht angelegt sind. Das habe ich jetzt in fhem.pl hoffentlich gefixt.
Ich habe meine "Drohung" war gemacht: FHEM2FHEM verwendet statt DoTrigger jetzt readingsSingleUpdate, falls lokale Geraete mit dem passenden Namen existieren. D.h. statt clonedummy kann man fuer FHEM2FHEM:LOG ein dummy mit dem gleichen Namen verwenden (nach dem morgigen update).
Zitat von: rudolfkoenig am 04 Januar 2017, 16:01:43
Ich habe meine "Drohung" war gemacht: FHEM2FHEM verwendet statt DoTrigger jetzt readingsSingleUpdate, falls lokale Geraete mit dem passenden Namen existieren. D.h. statt clonedummy kann man fuer FHEM2FHEM:LOG ein dummy mit dem gleichen Namen verwenden (nach dem morgigen update).
Gilt das nur für TYPE=dummy oder für gleichnamige devices aller Typen?
Es wäre ziemlich fatal, wenn ein device xy in fhem Installation (A) jedesmal neue Werte bekäme, wenn das device xy in fhem Installation (B) diese per FHEM2FHEM an (A) überträgt.
Gilt fuer alle Typen, statt DoTrigger wird readingsSingleUpdate aufgerufen. Ob es fatal oder endlich intuitiv ist, ist Ansichtssache, ist aber definitiv eine Aenderung, und damit potentiell problematisch.
Ich bin aber der Ansicht, dass es nur fuer die fatal ist, die einen extremen Spezialfall ausnutzen:
- FHEM2FHEM:LOG wird verwendet
- auf dem FHEM2FHEM Rechner sind Geraete mit dem Namen der Weitergeleiteten angelegt
- Man legt auf unterschiedliche Readings dieser Geraete Wert. Von wem die Events kommen, konnte auch bisher nicht unterschieden werden. Manchmal war ReadingsVal != $EVENT, aber nicht immer, ein Plot fuer diese Geraete hat nie was Sinnvolles geliefert.
Zitat von: rudolfkoenig am 08 Januar 2017, 12:41:25
- Man legt auf unterschiedliche Readings dieser Geraete Wert. Von wem die Events kommen, konnte auch bisher nicht unterschieden werden.
Es gibt Geräte in fhem-Installationen, die immer gleich heißen und die durchaus unterschiedliche readings haben müssen, um ihren Sinn nicht zu verlieren. Bei Homematic ist das z.B. der ActionDetector.
Genau DAS ist in cloneDummy nämlich der Grund, warum das Quell- und das Zieldevice nicht gleich heißen
dürfen. Aus dem "nicht gleich heißen dürfen" hast Du jetzt einfach so ein "gleich heißen müssen" gemacht. Das halte ich schon für "fatal".
Über die Änderung von DoTrigger() zu ReadingsSingleUpdate() bin ich nach wie vor nicht glücklich, weil es sich völlig anders verhält als vorher.
Dann sollte man ActionDetector per FHEM2FHEM:LOG nicht weiterleiten, die Events generieren ja nur Verwirrung.
Da ich die Aenderung weiterhin fuer sinnvoll finde, und du nicht, ist es unentschieden. Ich lasse mich aber beeinflussen: wie sehen andere das Problem?
:o es geht doch nicht nur um den ActionDetector, sondern um ein prinzipielles Problem.
- Deine Änderung ist insoweit eigentlich überflüssig, weil ich ja schon gesagt hatte, mich um cloneDummy zu kümmern. Wir haben quasi parallel an einer Lösung an unterschiedlichen Stellen gearbeitet und Du bist Deiner eigenen Ungeduld zum Opfer gefallen.
- Die Änderung an cloneDummy ist fertig und läuft bei mir aktuell im Testmodus (bisher fehlerfrei, aber ich habe noch nicht alle Testszenarioen durch)
- Deine Lösung ist völlig unnütz für vorhandene Anwendungen von cloneDummy.
- Einen tatsächlichen Nutzen Deiner Änderung kann ich bisher immer noch nirgends erkennen.
Ausserdem kann man cloneDummy auch innerhalb einer einzigen fhem-Installation anwenden. Und ob Du es glaubst oder nicht, ich hatte sogar schon einen Fall, in dem ich darüber froh war, dass ich ein device einfach klonen konnte.
Zitat von: rudolfkoenig am 08 Januar 2017, 16:28:35
Dann sollte man ActionDetector per FHEM2FHEM:LOG nicht weiterleiten
Du weisst doch genausogut wie ich, dass Anwender, die mit FHEM2FHEM:LOG arbeiten, in der Mehrzahl der Fälle einfach alles weiterleiten...
ZitatDeine Lösung ist völlig unnütz für vorhandene Anwendungen von cloneDummy.
Das will ich gar nicht bestreiten. Aber man braucht damit bei FHEM2FHEM kein cloneDummy, dummy reicht, und ist effizienter. Dass cloneDummy auch seine Berechtigung hat, ist mir auch klar. Ich habe die Wahl, kompatibel bei bestimmten merkwuerdigen Faellen zu bleiben, oder intuitiver zu werden. Solange ich ueberzeugt bin, dass es merkwuerdige Faelle sind, hat intuitiver Vorrang. Angebaut: ich baue in FHEM2FHEM ein exclude Regexp rein. :)
ZitatDu weisst doch genausogut wie ich, dass Anwender, die mit FHEM2FHEM:LOG arbeiten, in der Mehrzahl der Fälle einfach alles weiterleiten...
Keine Ahnung, wie die Leute es verwenden, ich staune immer wieder, wenn ich konkrete, groessere fhem.cfg's sehe, was Leute da zusammenbauen. Waere ein nettes Statistics-Forschungsprojekt, sowas zu visualisieren.
Zitat von: rudolfkoenig am 08 Januar 2017, 20:10:27
Angebaut: ich baue in FHEM2FHEM ein exclude Regexp rein. :)
Ich nehme an, dass sollte Angebot heißen ;)
Dann hätte ich lieber ein Attribut, mit dem ich in FHEM2FHEM zwischen readingsSingleUpdate() und DoTrigger() wählen kann.
Zurück zum eigentlichen Thema dieses Threads:
Zitat von: fhem-hm-knecht am 25 Dezember 2016, 01:31:14
cloneDummy funktioniert nicht mehr korrekt, also umgestellt auf dummy und notify.
Teste mal bitte, ob sich cloneDummy ab morgen wieder so verhält, wie Du es gewohnt warst.
Und kann mal bitte jemand diesen Thread in den richtigen Forumbereich für cloneDummy verschieben? Danke.
ZitatTeste mal bitte, ob sich cloneDummy ab morgen wieder so verhält, wie Du es gewohnt warst.
Test läuft
ZitatIch nehme an, dass sollte Angebot heißen
Richtig. Doofe Finger-Autokorrektur.
Habe die Attribute eventOnly und excludeEvents hinzugefuegt.
Zitat von: fhem-hm-knecht am 09 Januar 2017, 12:22:23
Test läuft
cloneDummy funktioniert wieder ohne Aussetzer , danke
die neue Funktionen von FHEM2FHEM mit ReadingsSingleUpdate , werde ich noch für mich austesten .. danke ebenfals