Hallo,
ich habe gestern Abend mein System weiter umgestellt. Ziel soll sein, dass FHEM von der FBF weg zu bekommen. Das neue Master-FHEM läuft in einer virtuellen Umgebung, auf einem Multimedia PC. Der CUL und panStick sind noch an der FBF, dem Slave-FHEM angeschlossen. Diese möchte ich per FHEM2FHEM im RAW Modus dem Master-FHEM zur Verfügung stellen.
Das hat gestern auch soweit alles funktioniert. Die CULs sind am Slave-FHEM (FritzBox) und über das Master-FHEM (VM) kann ich meine FS20 Komponenten steuern, nachdem ich überall das DevIO umgestellt habe, von dem CUL Device auf die FHEM2FHEM Instanz.
Was mir dann nur später aufgefallen ist: Das Betätigen von FS20 Aktoren wird im Master-FHEM gar nicht bemerkt. Im Event Monitor sehe ich auch keine Events.
Sehr komisch, ich bin davon ausgegangen, dass im RAW Modus sozusagen alle "Daten" durchgetunnelt werden.
Gestern ist mir die Idee gekommen, dass ich ggf. noch eine zusätzliche FHEM2FHEM Instanz benötige, die nicht im RAW Modus, sondern im LOG Modus arbeitet. Diese würde mir dann ja die Event vom Slave-FHEM an das Master-FHEM weiterleiten. Voraussetzung wäre vermutlich, dass im Slave-FHEM die FS20 Devices angelegt sind? Ist das richtig?
Die FS20 Devices auf dem Slave-FHEM habe ich gestern aber gelöscht, war das vielleicht der Fehler? Nachdem ich eine zusätzliche FHEM2FHEM Instanz für LOG angelegt habe, wurden mir auf dem Master-FHEM neue Devices angelegt, obwohl alle Devices schon angelegt sind. Sehr skurril. Dann war leider Schlafenszeit ;-)
Ich dachte, dass der RAW Modus eben alles einfach glatt tunnelt und der CUL für den Slave-FHEM transperent/nicht vorhanden ist. Ich denke, dass ich einen grundlegenden Fehler mache.
Konfiguration im Slave-FHEM (Nur die relevanten Teile)
define CUL_0 CUL /dev/ttyACM0@9600 1034
attr CUL_0 icon cul_cul
attr CUL_0 model CUL
attr CUL_0 rfmode SlowRF
attr CUL_0 room System
Konfiguration Master-FHEM (Nur die relevanten Teile)
define CUL_0 CUL none 1034
attr CUL_0 dummy 1
attr CUL_0 icon cul_cul
attr CUL_0 model CUL
attr CUL_0 rfmode SlowRF
attr CUL_0 room System
attr CUL_0 verbose 3
define nn_F2F_FBF_CUL FHEM2FHEM fritz.box:7072 RAW:CUL_0
attr nn_F2F_FBF_CUL verbose 3
Noch ein Beispiel zu den neuen Devices:
Angelegt ist ein s300th Sensor:
Internals:
CODE 1
CUL_0_MSGCNT 16
CUL_0_TIME 2015-02-04 22:37:42
DEF 1 -0.4 -1.8
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 16
NAME wz_Thermometer
NR 29
STATE T: 20.4 H: 41
TYPE CUL_WS
corr1 -0.4
corr2 -1.8
corr3 0
corr4 0
Readings:
2015-02-04 22:37:42 DEVFAMILY WS300
2015-02-04 22:37:42 DEVTYPE S300TH
2015-02-04 22:37:42 dewpoint 6.7
2015-02-04 22:37:42 humidity 41
2015-02-04 22:28:51 humidity_avg_day 39.1
2015-02-04 22:28:51 humidity_avg_month 38.9
2015-02-04 22:28:51 humidity_cum_day 3160747.5
2015-02-04 22:28:51 humidity_cum_month 16604587.5
2015-02-04 22:28:51 humidity_max_day 41.0
2015-02-04 22:28:51 humidity_max_month 41.0
2015-02-04 19:43:39 humidity_min_day 38.9
2015-02-04 19:43:39 humidity_min_month 38.9
2015-02-04 22:37:42 state T: 20.4 H: 41
2015-02-04 22:37:42 temperature 20.4
2015-02-04 22:37:42 temperature_avg_day 21.1
2015-02-04 22:37:42 temperature_avg_month 21.1
2015-02-04 22:37:42 temperature_cum_day 1717874.7
2015-02-04 22:37:42 temperature_cum_month 9010034.7
2015-02-04 20:36:45 temperature_max_day 21.5
2015-02-04 20:36:45 temperature_max_month 21.5
2015-02-04 22:37:42 temperature_min_day 20.4
2015-02-04 22:37:42 temperature_min_month 20.4
2015-02-04 22:37:42 trend_temperature -0.200000000000003
Attributes:
alias Wohnzimmer
event-min-interval state:900
event-on-change-reading .*
group Temperatur
icon temp_inside
model S300TH
room Wohnzimmer
userReadings trend_humidity:humidity difference {ReadingsVal($name,"humidity",0)}, trend_temperature:temperature difference {ReadingsVal($name,"temperature",0)}
Nachdem ich das FHEM umgezogen habe, auf dem Master, und auf dem Master ein FHEM2FHEM Device angelegt habe mit LOG wurde im Master-FHEM ein neues Device angelegt, was nun das Thermometer ist:
Internals:
CFGFN
CODE 1
CUL_0_MSGCNT 170
CUL_0_TIME 2015-02-05 08:18:53
DEF 1
IODev nn_F2F_FBF_CUL
LASTInputDev CUL_0
MSGCNT 170
NAME CUL_WS_1
NR 489
STATE T: 20.6 H: 41.1
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2015-02-05 08:18:53 DEVFAMILY WS300
2015-02-05 08:18:53 DEVTYPE S300TH
2015-02-05 08:18:53 dewpoint 6.9
2015-02-05 08:18:53 humidity 41.1
2015-02-05 08:18:53 humidity_avg_day 42.3
2015-02-05 08:18:53 humidity_avg_month 42.8
2015-02-05 08:18:53 humidity_cum_day 1267130.8
2015-02-05 08:18:53 humidity_cum_month 19756236.9999999
2015-02-05 00:00:18 humidity_max_day 42.7
2015-02-04 22:40:39 humidity_max_month 42.8
2015-02-05 07:43:29 humidity_min_day 41.0
2015-02-05 07:43:29 humidity_min_month 41.0
2015-02-05 08:18:53 state T: 20.6 H: 41.1
2015-02-05 08:18:53 temperature 20.6
2015-02-05 08:18:53 temperature_avg_day 19.6
2015-02-05 08:18:53 temperature_avg_month 20.7
2015-02-05 08:18:53 temperature_cum_day 585509.7
2015-02-05 08:18:53 temperature_cum_month 9569263.49999999
2015-02-05 08:12:59 temperature_max_day 20.6
2015-02-04 22:40:39 temperature_max_month 20.8
2015-02-05 05:33:41 temperature_min_day 19.1
2015-02-05 05:33:41 temperature_min_month 19.1
Attributes:
room CUL_WS
FHEM2FHEM:RAW haengt sich an dem "echten" CUL auf dem Slave, und meldet alles an Rohdaten, was dieser bekommt (d.h. noch vor der Interpretation durch die FS20/EM/etc Module), auf dem Master. Auf dem Master werden diese Rohdaten durch die logischen Module (FS20 & co) interpretiert und diese generieren die Events auf dem Master.
Auf dem Slave werden die gleichen Events auch generiert.
FHEM2FHEM:LOG ist nichts anderes wie ein "inform timer" bzw Event-Monitor, nur dass es die empfangenen Zeilen als Event weitergibt.
Zwei FHEM2FHEM Instanzen (RAW+LOG) zwischen Master und Slave ist im Normalfall unnoetig und problematisch, man muss dafuer sorgen, dass die jeweiligen Geraete auf den zwei Instanzen nicht gleich benannt sind.
ZitatDas Betätigen von FS20 Aktoren wird im Master-FHEM gar nicht bemerkt.
Das ist zu ungenau fuer mich.
Hallo und danke für die Antwort. Also brauche ich kein zusätzliches F2F Device mit LOG und das FS20 Device muss nicht zwingend im Slave angelegt sein, das hilft mir schon einmal.
Was dann nicht funktioniert ist folgendes:
Ich betätige eine Taste am FS20 S6A (on). Dieser Tastendruck wird nicht im Master-FHEM angezeigt. Es gibt kein Event im Event Monitor und das zugehörige Device (Eine Lampe) schaltet nicht auf on. Wenn ich heute Abend zu Hause bin, poste ich ein Log mit Verbose 5. Reicht das von folgenden Devices, oder wird mehr gebraucht?
Slave-FHEM: CUL
Master-FHEM: CUL (dummy), FHEM2FHEM
Falls ggf. noch etwas aus der fhem.cfg fehlt bitte auch bescheid geben. Ich wollte nicht die komplette cfg posten, das würde den Rahmen sprengen ;-)
Ich habe ein FHEM2FHEM Mini-Master gebaut fuer fhem.cfg.demo:
attr global logfile -
attr global modpath .
define telnetPort telnet 7172 global
define WEB FHEMWEB 8183 global
define CUL_0 CUL none 0000
define f2f FHEM2FHEM localhost:7072 RAW:CUL_0
define Office FS20 1234 12
Damit sieht man, dass Set Events im Master(!) gemeldet werden, im Slave aber nicht.
Works as designed.
Hm..sehr seltsam. Ich bin gespannt, ob die verbose Ausgaben mehr verraten. Denn der set on befehl, abgesetzt von dem FS20 S6A Taster, macht bei mir im Master nichts.
So, es hat sich schon erledigt. Beim Loggen ist mir aufgefallen, dass bereits am Slave-FHEM das FS20 Protokoll nicht richtig erkannt wurde. Warum auch immer.
Ein verbose 5 hat angezeigt:
2015.02.05 18:32:54 5: CUL/RAW: /F12341E11EC
2015.02.05 18:32:54 4: CUL_Parse: CUL_0 F12341E11EC -84
2015.02.05 18:32:54 5: CUL_0 dispatch 810b04xx0101a00112341e0011
2015.02.05 18:32:54 5: Triggering CUL_0 (1 changes)
2015.02.05 18:32:54 5: Notify loop for CUL_0 UNKNOWNCODE 810b04xx0101a00112341e0011
2015.02.05 18:32:54 4: et: CUL CUL_0 UNKNOWNCODE 810b04xx0101a00112341e0011 -> UNKNOWNCODE 810b04xx0101a00112341e0011
2015.02.05 18:32:54 5: nn_tempOverview: not on any display, ignoring notify
2015.02.05 18:32:54 3: CUL_0: Unknown code 810b04xx0101a00112341e0011, help me!
Im Master-FHEM kam gar nichts an. Logisch, war ja ein unbekanntes Protokoll. Ein einfaches shutdown restart hat dazu geführt, dass nun im slave-FHEM der Tastendruck vom FS20 S6A richtig erkannt wird:
2015.02.05 18:41:04 5: CUL/RAW: /F12341E11EE
2015.02.05 18:41:04 4: CUL_Parse: CUL_0 F12341E11EE -83
2015.02.05 18:41:04 5: CUL_0 dispatch 810b04xx0101a00112341e0011
2015.02.05 18:41:04 3: FS20 Unknown device 1234 (12131421), Button 1e (1243) Code 11 (on), please define it
2015.02.05 18:41:04 5: Triggering global (1 changes)
2015.02.05 18:41:04 5: Notify loop for global UNDEFINED FS20_12341e FS20 1234 1e
2015.02.05 18:41:04 5: nn_tempOverview: not on any display, ignoring notify
2015.02.05 18:41:04 5: Cmd: >iowrite CUL_0 04 01010112341100<
2015.02.05 18:41:04 5: CUL_0 sending F12341100
2015.02.05 18:41:04 5: SW: F12341100
Und im Master-FHEM passiert ganz wunderbar:
2015.02.05 18:41:14 4: FS20 sz_indirekt1 on
2015.02.05 18:41:14 5: Triggering sz_indirekt1 (1 changes)
2015.02.05 18:41:14 5: Notify loop for sz_indirekt1 on
2015.02.05 18:41:14 4: et: FS20 sz_indirekt1 on -> on
2015.02.05 18:41:14 4: et: FS20 sz_indirekt1 state: on -> state: on
2015.02.05 18:41:14 5: Triggering n_sz_LampeNachttischLiToggle
2015.02.05 18:41:14 4: n_sz_LampeNachttischLiToggle exec {
my $val = Value("sz_LampeNachttischLi");;
if ($val eq "off") {
fhem("set sz_LampeNachttischLi on");;
} else {
fhem("set sz_LampeNachttischLi off");;
}
}
2015.02.05 18:41:14 5: Cmd: >{
my $val = Value("sz_LampeNachttischLi");
if ($val eq "off") {
fhem("set sz_LampeNachttischLi on");
} else {
fhem("set sz_LampeNachttischLi off");
}
}<
2015.02.05 18:41:14 5: Cmd: >set sz_LampeNachttischLi off<
2015.02.05 18:41:14 3: FS20 set sz_LampeNachttischLi off
2015.02.05 18:41:14 5: Triggering sz_LampeNachttischLi (1 changes)
2015.02.05 18:41:14 5: Notify loop for sz_LampeNachttischLi off
2015.02.05 18:41:14 4: et: FS20 sz_LampeNachttischLi off -> off
2015.02.05 18:41:14 4: et: FS20 sz_LampeNachttischLi state: off -> state: off
Jetzt habe ich nur noch ein anderes Problem. Meine 2 s300th Sensoren werden nicht erkannt, sondern als neues Device angelegt.
So sieht die Definition aus von meinem eigentlichen s300th, was schön über attribute konfiguriert ist:
Internals:
CODE 1
CUL_0_MSGCNT 16
CUL_0_TIME 2015-02-04 22:37:42
DEF 1 -0.4 -1.8
IODev nn_F2F_FBF_CUL
LASTInputDev CUL_0
MSGCNT 16
NAME wz_Thermometer
NR 748
STATE T: 20.4 H: 41
TYPE CUL_WS
corr1 -0.4
corr2 -1.8
corr3 0
corr4 0
Readings:
2015-02-04 22:37:42 DEVFAMILY WS300
2015-02-04 22:37:42 DEVTYPE S300TH
2015-02-04 22:37:42 dewpoint 6.7
2015-02-04 22:37:42 humidity 41
2015-02-04 22:28:51 humidity_avg_day 39.1
2015-02-04 22:28:51 humidity_avg_month 38.9
2015-02-04 22:28:51 humidity_cum_day 3160747.5
2015-02-04 22:28:51 humidity_cum_month 16604587.5
2015-02-04 22:28:51 humidity_max_day 41.0
2015-02-04 22:28:51 humidity_max_month 41.0
2015-02-04 19:43:39 humidity_min_day 38.9
2015-02-04 19:43:39 humidity_min_month 38.9
2015-02-04 22:37:42 state T: 20.4 H: 41
2015-02-04 22:37:42 temperature 20.4
2015-02-04 22:37:42 temperature_avg_day 21.1
2015-02-04 22:37:42 temperature_avg_month 21.1
2015-02-04 22:37:42 temperature_cum_day 1717874.7
2015-02-04 22:37:42 temperature_cum_month 9010034.7
2015-02-04 20:36:45 temperature_max_day 21.5
2015-02-04 20:36:45 temperature_max_month 21.5
2015-02-04 22:37:42 temperature_min_day 20.4
2015-02-04 22:37:42 temperature_min_month 20.4
2015-02-04 22:37:42 trend_temperature -0.200000000000003
Attributes:
IODev nn_F2F_FBF_CUL
alias Wohnzimmer
event-min-interval state:900
event-on-change-reading .*
group Temperatur
icon temp_inside
model S300TH
room Wohnzimmer
userReadings trend_humidity:humidity difference {ReadingsVal($name,"humidity",0)}, trend_temperature:temperature difference {ReadingsVal($name,"temperature",0)}
Aus irgendeinem Grund wird nun aber dafür ein neues Device angelegt, kann man erklären warum?
Internals:
CFGFN
CODE 1
CUL_0_MSGCNT 1
CUL_0_TIME 2015-02-05 18:59:04
DEF 1
IODev nn_F2F_FBF_CUL
LASTInputDev CUL_0
MSGCNT 1
NAME CUL_WS_1
NR 1092
STATE T: 21.1 H: 40
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2015-02-05 18:59:04 DEVFAMILY WS300
2015-02-05 18:59:04 DEVTYPE S300TH
2015-02-05 18:59:04 dewpoint 7.0
2015-02-05 18:59:04 humidity 40
2015-02-05 18:59:04 humidity_avg_day 40
2015-02-05 18:59:04 humidity_avg_month 40
2015-02-05 18:59:04 humidity_cum_day 2733760
2015-02-05 18:59:04 humidity_cum_month 20013760
2015-02-05 18:59:04 humidity_max_day 40
2015-02-05 18:59:04 humidity_max_month 40
2015-02-05 18:59:04 humidity_min_day 40
2015-02-05 18:59:04 humidity_min_month 40
2015-02-05 18:59:04 state T: 21.1 H: 40
2015-02-05 18:59:04 temperature 21.1
2015-02-05 18:59:04 temperature_avg_day 21.1
2015-02-05 18:59:04 temperature_avg_month 21.1
2015-02-05 18:59:04 temperature_cum_day 1442058.4
2015-02-05 18:59:04 temperature_cum_month 10557258.4
2015-02-05 18:59:04 temperature_max_day 21.1
2015-02-05 18:59:04 temperature_max_month 21.1
2015-02-05 18:59:04 temperature_min_day 21.1
2015-02-05 18:59:04 temperature_min_month 21.1
Attributes:
room CUL_WS
Und wenn ich das CUL_WS_1 Device einfach lösche, wird es später durch autocreate neu erstellt.
CUL_WS hat beim gesetzten IODev ein spezielles Verhalten: es "gehoert" nur diesem Empfaenger, d.h. damit kann mehrere mit dem gleichen ID haben, um die Addressgrenze (8 Stueck) austricksen zu koennen.
Ja, ähm. Ok. Bei den 2 Stück mache ich mir einfach die Mühe und kopiere alle Attribute zu dem neuen Device um :-)
Ich denke dass war es dann. Es ist zwar komisch, dass das FS20 Protokoll nicht ordentlich erkannt wurde, aber das ist jetzt ja weg.
Danke für die Hilfe...
Ok, was dazu gelernt: Áugenscheinlich kann man das Device nicht umbenennen. Denn dann wird wieder ein neues Device CUL_WS_1 angelegt.
Was kann ich denn machen, damit ich das ganze wieder wz_Thermometer nennen kann? Oder ist das gar nicht möglich, weil immer DevIO verwendet wird in Verbindung mit FHEM2FHEM?
Warum willst du fuer ein CUL_WS ein DevIO vergeben?
Habe ich nicht mehr, das war nur im ersten Thread so. Nach deiner Information habe ich DevIO als attr entfernt, was aber trotzdem nicht zu meinem Ziel geführt hat. Trotzdem wird das CUL_WS_1 Device immer neu angelegt.
Habe alles einmal Schritt für Schritt gemacht:
Das Device wird durch autocreate angelegt:
Internals:
CFGFN
CODE 1
CUL_0_MSGCNT 1
CUL_0_TIME 2015-02-06 14:42:05
DEF 1
IODev nn_F2F_FBF_CUL
LASTInputDev CUL_0
MSGCNT 1
NAME CUL_WS_1
NR 392
STATE T: 21.6 H: 39
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2015-02-06 14:42:05 DEVFAMILY WS300
2015-02-06 14:42:05 DEVTYPE S300TH
2015-02-06 14:42:05 dewpoint 7.1
2015-02-06 14:42:05 humidity 39
2015-02-06 14:42:05 humidity_avg_day 39
2015-02-06 14:42:05 humidity_avg_month 39
2015-02-06 14:42:05 humidity_cum_day 2064075
2015-02-06 14:42:05 humidity_cum_month 22281675
2015-02-06 14:42:05 humidity_max_day 39
2015-02-06 14:42:05 humidity_max_month 39
2015-02-06 14:42:05 humidity_min_day 39
2015-02-06 14:42:05 humidity_min_month 39
2015-02-06 14:42:05 state T: 21.6 H: 39
2015-02-06 14:42:05 temperature 21.6
2015-02-06 14:42:05 temperature_avg_day 21.6
2015-02-06 14:42:05 temperature_avg_month 21.6
2015-02-06 14:42:05 temperature_cum_day 1143180
2015-02-06 14:42:05 temperature_cum_month 12340620
2015-02-06 14:42:05 temperature_max_day 21.6
2015-02-06 14:42:05 temperature_max_month 21.6
2015-02-06 14:42:05 temperature_min_day 21.6
2015-02-06 14:42:05 temperature_min_month 21.6
Attributes:
room CUL_WS
Dann mache ich ein:
rename CUL_WS_1 wz_Thermometer
Ist auch erfolgreich:
Internals:
CFGFN
CODE 1
CUL_0_MSGCNT 2
CUL_0_TIME 2015-02-06 14:45:02
DEF 1
IODev nn_F2F_FBF_CUL
LASTInputDev CUL_0
MSGCNT 2
NAME wz_Thermometer
NR 392
STATE T: 21.6 H: 39
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2015-02-06 14:45:02 DEVFAMILY WS300
2015-02-06 14:45:02 DEVTYPE S300TH
2015-02-06 14:45:02 dewpoint 7.1
2015-02-06 14:45:02 humidity 39
2015-02-06 14:45:02 humidity_avg_day 39.0
2015-02-06 14:45:02 humidity_avg_month 39.0
2015-02-06 14:45:02 humidity_cum_day 2070978
2015-02-06 14:45:02 humidity_cum_month 22288578
2015-02-06 14:42:05 humidity_max_day 39
2015-02-06 14:42:05 humidity_max_month 39
2015-02-06 14:42:05 humidity_min_day 39
2015-02-06 14:42:05 humidity_min_month 39
2015-02-06 14:45:02 state T: 21.6 H: 39
2015-02-06 14:45:02 temperature 21.6
2015-02-06 14:45:02 temperature_avg_day 21.6
2015-02-06 14:45:02 temperature_avg_month 21.6
2015-02-06 14:45:02 temperature_cum_day 1147003.2
2015-02-06 14:45:02 temperature_cum_month 12344443.2
2015-02-06 14:42:05 temperature_max_day 21.6
2015-02-06 14:42:05 temperature_max_month 21.6
2015-02-06 14:42:05 temperature_min_day 21.6
2015-02-06 14:42:05 temperature_min_month 21.6
Attributes:
room CUL_WS
Jetzt möchte ich das define ändern, damit Korrekturwerte greifen und folgende Attribute setzen:
attr wz_Thermometer alias Wohnzimmer
attr wz_Thermometer event-min-interval state:900
attr wz_Thermometer event-on-change-reading .*
attr wz_Thermometer group Temperatur
attr wz_Thermometer icon temp_inside
attr wz_Thermometer model S300TH
attr wz_Thermometer room Wohnzimmer
attr wz_Thermometer userReadings trend_humidity:humidity difference {ReadingsVal($name,"humidity",0)}, trend_temperature:temperature difference {ReadingsVal($name,"temperature",0)}
Und irgendwas davon führt dazu, dass plözlich wieder der selbe sensor als CUL_WS_1 angelegt wird.
Ich werde jetzt mal empirisch jeden Befehl durchführen und gucken ab wann das neue Device angelegt wird...
Ich kann mir nicht erklären, wieso das 3 mal nicht funktioniert hat in den Tagen zuvor. Jetzt funktioniert es. Sehr seltsam
Hallo Rudi, es tut mir leid, dass ich das Thema doch noch einmal aufwärmen muss.
Ich habe vor 4 Tagen nun das CUL_WS_2 Device umbenannt, mit allen Attributen. Das hat auch alles funktioniert. Und heute Mittag wurde durch autocreate das ganze wieder neu angelegt.
2015.02.10 12:45:45 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1
2015.02.10 12:45:45 2: autocreate: define CUL_WS_1 CUL_WS 1
2015.02.10 12:45:45 2: autocreate: define FileLog_CUL_WS_1 FileLog ./log/CUL_WS_1-%Y.log CUL_WS_1:T:.*
2015.02.10 12:45:45 2: autocreate: define SVG_CUL_WS_1 SVG FileLog_CUL_WS_1:temp4hum6:CURRENT
Was führt denn dazu, dass auf einmal das Device als neu erkannt wird?!
Das CUL_WS Modul hat keine Definition mit diesem Code (1) gefunden.
Falls eine CUL_WS FHEM-Definition ein IODev Attribut hat, dann wird es nur genommen, wenn dieses Geraet die Nachricht empfangen hat.
Kannst du bitte pruefen, ob dein definiertes CUL_WS ein IODev Attribut hat?
Dann wird da irgendwo ein Bug sein, dass es gibt eine Definition mit dem Code 1, das hat ja auch tagelang funktioniert.
IODev Attribut ist nirgends gesetzt, da habe ich, nach deinem Hinweis, drauf geachtet.
Dieses Device lief jetzt Tagelang:
Internals:
CFGFN
CODE 1
CUL_0_MSGCNT 1781
CUL_0_TIME 2015-02-10 12:42:48
DEF 1
IODev nn_F2F_FBF_CUL
LASTInputDev CUL_0
MSGCNT 1781
NAME wz_Thermometer
NR 392
STATE T: 21.1 H: 45
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2015-02-10 12:42:48 DEVFAMILY WS300
2015-02-10 12:42:48 DEVTYPE S300TH
2015-02-10 12:39:51 dewpoint 8.7
2015-02-10 12:42:48 humidity 45
2015-02-10 12:31:00 humidity_avg_day 45.7
2015-02-10 12:31:00 humidity_avg_month 40.4
2015-02-10 12:31:00 humidity_cum_day 2061473.7
2015-02-10 12:31:00 humidity_cum_month 36740608.7
2015-02-10 00:01:39 humidity_max_day 46.6
2015-02-09 23:41:00 humidity_max_month 46.6
2015-02-10 11:29:03 humidity_min_day 43.8
2015-02-07 08:41:51 humidity_min_month 37.6
2015-02-10 12:42:48 state T: 21.1 H: 45
2015-02-10 12:42:48 temperature 21.1
2015-02-10 12:39:51 temperature_avg_day 20.3
2015-02-10 12:39:51 temperature_avg_month 21.2
2015-02-10 12:39:51 temperature_cum_day 925236.6
2015-02-10 12:39:51 temperature_cum_month 19282897.9
2015-02-10 10:56:36 temperature_max_day 21.5
2015-02-06 16:16:29 temperature_max_month 22.4
2015-02-10 07:33:02 temperature_min_day 19.4
2015-02-07 09:29:03 temperature_min_month 18.7
2015-02-10 12:31:00 trend_humidity 0.5
2015-02-10 12:39:51 trend_temperature -0.0999999999999979
Attributes:
alias Wohnzimmer
event-min-interval state:900
event-on-change-reading .*
group Temperatur
icon temp_inside
model S300TH
room Wohnzimmer
userReadings trend_humidity:humidity difference {ReadingsVal($name,"humidity",0)}, trend_temperature:temperature difference {ReadingsVal($name,"temperature",0)}
Und nun wurde durch Autocreate das folgende Device angelegt:
Internals:
CFGFN
CODE 1
CUL_0_MSGCNT 372
CUL_0_TIME 2015-02-11 08:08:07
DEF 1
IODev nn_F2F_FBF_CUL
LASTInputDev CUL_0
MSGCNT 372
NAME CUL_WS_1
NR 5094
STATE T: 20.2 H: 47.6
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
Readings:
2015-02-11 08:08:07 DEVFAMILY WS300
2015-02-11 08:08:07 DEVTYPE S300TH
2015-02-11 08:08:07 dewpoint 8.7
2015-02-11 08:08:07 humidity 47.6
2015-02-11 08:08:07 humidity_avg_day 47.7
2015-02-11 08:08:07 humidity_avg_month 45.1
2015-02-11 08:08:07 humidity_cum_day 1396432
2015-02-11 08:08:07 humidity_cum_month 44210124.7000006
2015-02-11 01:15:05 humidity_max_day 48.3
2015-02-11 01:15:05 humidity_max_month 48.3
2015-02-11 02:17:03 humidity_min_day 47.6
2015-02-10 12:48:42 humidity_min_month 45
2015-02-11 08:08:07 state T: 20.2 H: 47.6
2015-02-11 08:08:07 temperature 20.2
2015-02-11 08:08:07 temperature_avg_day 20.1
2015-02-11 08:08:07 temperature_avg_month 21.1
2015-02-11 08:08:07 temperature_cum_day 588526.3
2015-02-11 08:08:07 temperature_cum_month 20648065.4
2015-02-11 00:01:20 temperature_max_day 21.2
2015-02-10 20:55:29 temperature_max_month 21.8
2015-02-11 07:29:46 temperature_min_day 19.5
2015-02-11 07:29:46 temperature_min_month 19.5
Attributes:
room CUL_WS
Attribut IODev ist nirgends gesetzt, oder übersehe ich in dem list etwas? Lediglich das INTERNAL IODev ist gesetzt, aber da kann ich keinen Einfluss drauf nehmen?!
Und beide Geräte haben den Code 1, wie auch im list zu sehen ist.
Sprachlos?! ;)
Dass du den Fehler nicht nachstellen kannst ist natürlich problematisch. Ich biete natürlich an, alles Mögliche bei mir zu machen/loggen/ändern.
Ja, sprachlos.
Ich habe etwas ueber CUL_WS.pm und FHEM2FHEM.pm gebruetet, und folgendes festgestellt:
- der AssignIoPort($hash) Aufruf (der den IODev Eintrag anlegt) in CUL_WS_Define ist ueberfluessig/verwirrend, da CUL_WS nur empfangen wird, und das IODev "Internal" nur beim Senden verwendet wird. Ich glaube aber nicht, dass er als Ursache herhalten kann.
- UNDEFINED (und damit der autocreate Aufruf) wird erzeugt, wenn der Eintrag $modules{CUL_WS}{defptr} fuer Code 1 in CUL_WS_Parse nicht gefunden wird. Das kann passieren, wenn (temporaer?) ein IODev Attribut gesetzt wird, oder nach dem Loeschen (z.Bsp. durch rereadcfg) der Eintrag nicht sofort angelegt wird, sondern z.Bsp. erst nachdem FHEM2FHEM eine CUL_WS Nachricht empfangen hat. Ich habe letzteres im Verdacht (verwendest du rereadcfg bzw. "Edit files->fhem.cfg"?), allerdings sehe ich trotzdem nicht konkret, wie das passieren kann, weil FHEM2FHEM erst nach dem kompletten Einlesen der fhem.cfg mit Abarbeitung der Nachrichten anfaengt.
Um das Problem zu lokalisieren koennte man in FHEM/CUL_WS.pm vor jede Zeile, wo defptr modifiziert wird (CUL_WS_Define, CUL_WS_Undef, CUL_WS_Attr) eine Debugausgabe (Log 1, "Zeile XX") einfuegen, und darauf warten, dass das Problem auftritt.
fhem.cfg bearbeite ich nicht. Reicht dir die logausgabe Zeile xxx, oder soll noch irgendwas mit rein. Inhalt einer Variable oder so?
Dann setzte ich mich gleich mal dran und füge die log Einträge Ein
Ich habe jetzt folgende LOG Meldungen eingefügt und das Modul neu geladen:
Line 54: Log 3, "DEBUG CUL_WS: CUL_WS_Define(), Zeile 54";
Line 65: Log 3, "DEBUG CUL_WS: CUL_WS_Undef(), Zeile 65";
Line 66: Log 3, "DEBUG CUL_WS: CUL_WS_Undef(), Zeile 66" if($hash && $hash->{CODE});
Line 360: Log 3, "DEBUG CUL_WS: CUL_WS_Attr(), Zeile 360";
Die CUL_WS Devices haben ich nun wieder alle konfiguriert und richtig umbenannt. Mal schauen wann etwas im Log zu sehen ist.
Der Fehler ist gerade wieder passiert. Ich vermute, ich weis nun auch, wann der Fehler genau auftaucht. Ich habe die alten Devices (Die ja eigentlich schon seit 3 Jahren funktionieren) gerade gelöscht und siehe da, auf einmal werden neue CUL_WS angelegt.
Noch einmal zur Erläuterung: 2 Devices funktionierten seit 3 Jahren. Das sind die "alten". Die 2 neuen Devices wurden plötzlich angelegt, als ich FHEM2FHEM eingerichtet habe. Das sind für mich die "neuen". Seit der Umstellung auf FHEM2FHEM wurden die Sensordaten nur für die neuen Devices erkannt, nicht für die alten. Damit ich mir die ganzen Einstellungen von Attributen nicht merken muss habe ich die alten Devices angelegt gelassen. Natürlich hatten die alten Devices auch die Sensor ID der jeweiligen Sensoren.
Die alten devices habe ich gerade gelöscht. Dabei taucht im Log das folgende auf:
2015.02.21 18:55:28 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 65
2015.02.21 18:55:28 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 66
2015.02.21 18:55:37 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 65
2015.02.21 18:55:37 3: DEBUG CUL_WS: CUL_WS_Undef(), Zeile 66
Direkt danach haben die Sensoren wieder Daten gesendet...die ja eigentlich bei den neuen Devices angezeigt werden sollen. Ich vermute jedoch, dass das nicht passiert ist, da die alten Devices ja die selbe Sensor ID haben, wie die neuen Devices. Und beim löschen der alten Devices wurde vermutlich die Sensor ID komplett entfernt, so dass das Modul denkt, es gibt gar kein Device, mit der passenden Sensor ID?!
Auf jeden Fall kam im Log folgendes:
2015.02.21 18:56:19 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1
2015.02.21 18:56:19 2: autocreate: define CUL_WS_1 CUL_WS 1
2015.02.21 18:56:19 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 18:56:19 2: autocreate: define FileLog_CUL_WS_1 FileLog ./log/CUL_WS_1-%Y.log CUL_WS_1:T:.*
2015.02.21 18:56:19 2: autocreate: define SVG_CUL_WS_1 SVG FileLog_CUL_WS_1:temp4hum6:CURRENT
2015.02.21 18:56:32 1: CUL_WS UNDEFINED temp/hum sensor detected, code 2
2015.02.21 18:56:32 2: autocreate: define CUL_WS_2 CUL_WS 2
2015.02.21 18:56:32 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 18:56:32 2: autocreate: define FileLog_CUL_WS_2 FileLog ./log/CUL_WS_2-%Y.log CUL_WS_2:T:.*
2015.02.21 18:56:32 2: autocreate: define SVG_CUL_WS_2 SVG FileLog_CUL_WS_2:temp4hum6:CURRENT
Zum Testen habe ich nun mal folgendes gemacht.
Die gerade erstellen Devices CUL_WS_1 und CUL_WS_2 gelöscht. Danach ein "save" und dann ein restart shutdown.
Durch den Restart dürften eigentlich nur richtigen 2 Sensoren als Device erkannt werden.
Beim restart kommen die folgenden Meldungen (Wieso eigentlich 5 mal ein Define?!)
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
2015.02.21 19:02:26 3: DEBUG CUL_WS: CUL_WS_Define(), Zeile 54
Wenn man mit dem gleichen Code mehrere CUL_WS Geraete definiert, und dann eins davon loescht, dann geht die modul-interne Zuordnung auch zum nicht-geloeschten Geraet (mit dem gleichen Code) verloren, und deswegen wird beim Eintreffen einer Nachricht ein neues Geraet angelegt. Das koennte man als Bug bezeichnen, ich will aber nicht mehrere CUL_WS mit dem gleichen ID unterstuetzen, und fixe es deswegen erstmal nicht.
Das urspruengliche Problem wird aber damit mAn noch nicht erklaert.
Als bug würde ich es auch nicht bezeichn n. Ist ja eher Ein Zustand gewesen, der so nicht vorgesehen ist.
Ein Workarounds ist ja ebenfalls beschrieben, falls es mal einen trifft.
Aber warum das Device einmal neuangelegt wurde kann ich auch nicht nachvollziehen. Ich möchte auch nicht meine Installation noch einmal umstellen ;-)
Danke für die Unterstützung. Ohne wäre ich nie auf dieses Verhalten gekommen