CUL_WS UNDEFINED temp/hum sensor detected, code 6

[roedert]

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:

Code Auswählen Erweitern

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-

[rudolfkoenig]

Diese Meldung kommt dann wiederholt, wenn kein CUL_WS mit Code 6 definiert ist und autocreate abgeschaltet ist.

[roedert]

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

Code Auswählen Erweitern

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

[roedert]

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.

[rudolfkoenig]

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).

[roedert]

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?

[rudolfkoenig]

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.

[roedert]

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

[Puschel74]

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 
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.

[roedert]

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.....

[Puschel74]

Hallo,

Zitat Rudi:

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.

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

[rudolfkoenig]

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.

[Puschel74]

Hallo,

ok.

Danke dir Rudi.

Grüsse