Hallo zusammen,
da ich teilweise Daten nicht empfangen habe wegen zu geringer Reichweite/zu viele Wände, habe ich zusätzlich zur COC-Erweiterung auf dem Pi noch einen CUNOv2 im Netzwerk installiert.
Seitdem bekomme ich im Log häufig o.a. Meldung.
Die entsprechenden CUL_WS mit Adresse 1-6 sind jedoch in FHEM definiert (es sind S300TH) ... und haben soweit auch aktuelle Daten.
Irgendeine Idee, woran dies liegen könnte?
Anbei noch die CUNO-Definition:
Internals:
CMDS mBCFZiAGMRTVWXOefltuHxEcq
CUNO_MSGCNT 4875
CUNO_TIME 2014-01-23 07:33:58
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:
DEF 192.168.xxx.xxx:2323 4321
DeviceName 192.168.xxx.xxx:2323
FD 21
FHTID 4321
NAME CUNO
NR 338
NR_CMD_LAST_H 4
PARTIAL
RAWMSG T084C00A6801B
RSSI -60.5
STATE Initialized
TYPE CUL
VERSION V 1.55 CUNO868
initString X21
CHANGETIME:
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......$
Readings:
2014-01-22 23:02:49 ccconf freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB
2014-01-22 23:02:04 cmds m B C F Z i A G M R T V W X O e f l t u H x E c q
2014-01-23 07:33:58 state Initialized
Softbuffer:
XMIT_TIME:
1390436503.08776
1390436511.81888
1390436517.00806
1390436521.6474
Attributes:
DbLogExclude .*
group IOdev
room -Admin-
Diese Meldung kommt dann wiederholt, wenn kein CUL_WS mit Code 6 definiert ist und autocreate abgeschaltet ist.
Das ist schon klar, jedoch sind ja wie geschrieben einsprechende 6 CUL_WS definiert ... die auch Daten empfangen. Vorher mit nur der COC-Erweiterung gabs ja auch keine Logeinträge.
Die Logeinträge kommen nicht nur für Code 6, sondern für alle von mit benutzten Codes 1...6
Internals:
COC_MSGCNT 32
COC_RAWMSG K518611601B
COC_RSSI -60.5
COC_TIME 2014-01-23 05:43:45
CODE 6
CUNO_MSGCNT 74
CUNO_RAWMSG K5187815931
CUNO_RSSI -49.5
CUNO_TIME 2014-01-23 07:25:32
DEF 6
IODev CUNO
LASTInputDev CUNO
MSGCNT 79
NAME Schlafzimmer.Temperatur
NR 1559
STATE T: 18.7 H: 59.8
TYPE CUL_WS
corr1 0
corr2 0
corr3 0
corr4 0
CHANGETIME:
Helper:
Dblog:
Data:
Dblog:
TIME 1390458332.70358
VALUE T: 18.7 H: 59.8
Humidity:
Dblog:
TIME 1390458332.70358
VALUE 59.8
Temperature:
Dblog:
TIME 1390458332.70358
VALUE 18.7
Readings:
2014-01-23 07:25:32 DEVFAMILY WS300
2014-01-23 07:25:32 DEVTYPE S300TH
2014-01-23 07:25:32 humidity 59.8
2014-01-23 07:25:32 state T: 18.7 H: 59.8
2014-01-23 07:25:32 temperature 18.7
Attributes:
IODev CUNO
fm_view 1,0
fp_Floorplan 500,1170,4
room Schlafzimmer
Hab mal Autocreate aktiviert, wenn die Meldung danach das erste mal kommt, wird ein neuer CUL_WS_x angelegt ... die Meldung für diesen Code x kommt aber weiterhin, nochmal wird von autocreate dann nichts mehr angelegt, Device mit diesem Namen existiert ja schon.
Sehr komisch, und ich kann es z.Zt. nicht erklaeren. Ich habe auch mehrere Empfaenger (das ist in FHEM Umfeld nicht ungewoehnlich), habe aber das Problem nie gesehen.
Das Modul prueft, ob eine globaler Eintrag mit 6 existiert, und generiert die Meldung, falls nicht. Der Eintrag wird angelegt, falls man ein Geraet mit Code 6 definiert. D.h. entweder ist 6 nicht gleich 6, oder ist dieser Eintrag in deinem Fall nicht global (wuesste aber nicht wie das gehen soll).
Bei manchen Devices zeigt er jetzt als Reading DEVTYPE PS50 statt S300TH an?
Unterscheidet das Modul bei der Prüfung nach bestehenden Definitionen evtl. nach dem Devicetyp?
Ich glaube ich habs:
da manche Leute die Begrenzung auf 8 Geraete durch den Emfang ueber unterschiedliche Empfaenger umgehen wollten (z.Bsp. durch Umbau der S300TH auf 433MHz), gibt es einen Feature bei CUL_WS: Wenn man IODev gesetzt hat (was normalerweise nur beim Senden sinnvoll ist), dann wird der Sensor exklusiv diesem Empfaenger zugeordnet, und nicht fuer Daten, die ueber ein anderes Interface empfangen kommen, in Betracht gezogen.
Loesung: IODev loeschen.
Danke für deine Hilfe! :)
Ein deleteattr TYPE=CUL_WD IODev hat zwar noch nicht geholfen, nach einem shutdown restart kamen aber bisher keine Logmeldungen mehr.
Gruß Tilo
Hallo,
@Rudi
Habe ich deine Lösung bzw. die Analyse des Problems richtig verstanden?
Indem ich einem CUL_WS ein IODEV zuordne kann ich mehr als 8 CUL_WS verwenden muss aber dann mit den Meldungen im FHEM-LogFile leben?
Oder trifft das nur zu wenn ich den CUL_WS auf 433 MHz umbaue (original sendet der ja auf 868 MHz)?
Warum ich Frage: Ich habe seit einiger Zeit (Monaten) auch "Undefined CUL_WS x please define it" im FHEM-LogFile.
Erst habe ich das meiner FHEM2FHEM-Installation zugeschrieben da der Versuchs-RasPi auch einen CUL bekommen hat - zu Versuchszwecken.
Diese FHEM2FHEM-Definition habe ich auf meiner Haupt-FHEM-Installation aber wieder entfernt - die Meldungen sind aber geblieben.
Ich habe dem aber weiter keine Beachtung geschenkt.
Nun habe ich soeben diesen Beitrag und deine Analyse gelesen.
Logisch - ich habe meine CUL_WS auch per IODEV auf meine CUNO aufgeteilt.
Bevor ich das nun lösche würde mich eben interessieren ob ich mit IODEV die Beschränkung von 8 CUL_WS (868 MHz) umgehen kann.
Dann würde ich nämlich meine 2 "Reserve-CUL_WS" aktivieren und diese ihrem Zwecke zuführen bis ich die HM-Sensoren geliefert bekomme (was noch etwas dauern kann - ich muss mal bei ELV nachfragen was da los ist).
Danke schonmal für deine Antwort.
Grüße
P.S.: Ich weiß - probieren geht über studieren ;D
Wenn du aber sagst - nö, das kann nicht klappen - dann lösch ich die IODEV Zuordnung und lass meine Reserve-CUL_WS im Schank liegen.
Einem CUL_WS kann man zwar in der Konfiguration ein IODev zuordnen - es ist aber unsinnig.
Das IODev bedeutet ja nicht über welchen Weg Daten empfangen werden, sondern über welches Device sie gesendet werden.
Und der CUL_WS nur Daten sender und nicht empfängt, wird FHEM ihm ja niemals Daten senden.....
Hallo,
Zitat Rudi:
Zitatgibt es einen Feature bei CUL_WS: Wenn man IODev gesetzt hat (was normalerweise nur beim Senden sinnvoll ist), dann wird der Sensor exklusiv diesem Empfaenger zugeordnet, und nicht fuer Daten, die ueber ein anderes Interface empfangen kommen, in Betracht gezogen.
Zitat Ende.
Ich weiß das ein CUL_WS nur! sendet.
Aber laut Zitat wird per IODEV der Sensor exklusive diesem Empfänger zugeordnet.
Grüße
WENN du sicherstellen kannst, dass ein bestimmtes S300TH jeweils nur von EINEM CUL empfangen wird (z.Bsp. durch Umbau auf 433MHz, oder weit auseinanderliegende CULs oder Richtantenne usw.), dann kann man durch setzen des IODevs in FHEM mehrere S300THs mit dem gleichen ID betreiben. Sonst ist das Setzen dieser Variable kontraproduktiv, da FHEM versucht 2 Instanzen fuer das gleiche Geraet anzulegen.
Wenn die Bedingung nicht erfuellt wird, dann hilft IODev auch nicht, und es gibt vermischte Messergebnisse.
Hallo,
ok.
Danke dir Rudi.
Grüsse