[gelöst] RF Error

[eisi]

Ich hatte mal einen zweiten CUL, aber der ist schon lange raus.
Wenn du wieder einen Betatester brauchst, bin da

Hier mal die Lists:

Code Auswählen Erweitern


Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.0.119:2323 0000
   DeviceName 192.168.0.119:2323
   FD         14
   FHTID      0000
   FUUID      5d5e96f5-f33f-f5fa-db57-8598e5a347469b8d
   NAME       cul_oben
   NR         214
   NR_CMD_LAST_H 8
   PARTIAL   
   RAWMSG     Z0F00046010D6BE00000000190E2A00E4FA
   RSSI       -77
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBe (F-Band: 868MHz)
   cul_oben_MSGCNT 3329
   cul_oben_TIME 2019-12-29 17:07:33
   initString X21
Zr
Za123456
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-12-27 17:13:54   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2019-12-29 16:48:19   credit10ms      286
     2018-01-10 12:24:02   raw             21  900
     2019-12-29 17:07:33   state           Initialized
   XMIT_TIME:
     1577632482.79308
     1577634456.02027
     1577634462.55632
     1577634469.0742
     1577634475.11265
     1577634478.65073
     1577634497.58887
     1577634499.09204
Attributes:
   rfmode     MAX
   room       CUL_MAX
   verbose    4


Code Auswählen Erweitern


Internals:
   DEF        123456
   FUUID      5e062454-f33f-f5fa-abd8-cb569bebe49da3f1
   FVERSION   14_CUL_MAX.pm:?/2019-12-27 UNSTABLE
   IODev      cul_oben
   LASTInputDev cul_oben
   MSGCNT     3331
   NAME       CULMAX0
   NR         724
   STATE      Defined
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   cul_oben_MSGCNT 3331
   cul_oben_RAWMSG Z0F00046013880C00000000180B2A00E4
   cul_oben_RSSI -64
   cul_oben_TIME 2019-12-29 17:08:40
   pairmode   0
   retryCount 0
   sq         0
   READINGS:
     2019-12-29 16:48:19   cul_oben_cmd_last_h 7
     2019-12-29 16:48:19   cul_oben_credit10ms 286
     2019-12-29 16:47:58   packetsLost     29
Attributes:
   IODev      cul_oben
   debug      1
   fakeSCaddr 222222
   fakeWTaddr 111111
   room       CUL_MAX
   verbose    5


[Wzut]

ok alles klar :

Code Auswählen Erweitern

initString X21
der ist viel zu kurz, d.h der wird eigentlich durch CUL_MAX  "verlängert".
Ich vermute du benutzt noch meine Beta Versionen. Wenn ja, da steckt noch ein uralter Fehler der MAX Module drin der sich nur bemerkbar macht wenn in der fhem.cfg
das CUL_MAX vor dem CUL Device steht. Beim Start will CUL_MAX den InitString verlängern, das ghet aber schief wenn das Device zu diesem Zeitpunkt noch nicht bekannt ist. Vorschlag :
a. du editierst deine fhem.cfg von Hand und sorgst dafür das die Reihenfolge stimmt.
b. du wartest noch ein paar Minuten und schaust nochmal in den Beta Thread. Ich habe gerade neue Versionen auf mein Produktivsystem geladen und werde jetzt die alten Dateien da oben austauschen. Aber ACHTUNG : die modifizierte MaxCommon wird nicht mehr verwendet, d.h. es muss wieder die alte bisherige genutzt werden und FHEM neu gestartet werden.

[eisi]

Zu a: Das steht richtig rum.
Erst CUL_oben, dann CULMAX0.
Sollen die direkt nacheinander stehen?
Die haben nämlich einigen Abstand.

Zu b. Ich warte gerne

[Wzut]

die neuen Dateien sind verfügbar. Aber mir fällt da noch etwas auf :

Code Auswählen Erweitern

192.168.0.119:2323
du nutzt einen LAN CUL , kein USB , der hat aber z.Z. noch die hässliche Eigenart beim Disconnect bzw. Reconnect den InitString  über Bord zu werfen.
In wie weit das Probleme beim Paring machen kann muss ich selbst noch testen. Ich vermute als CUL_MAX vor Jahren entstand hatte sie nur USB CULs im Einsatz.
Starte dein FHEM mal neu und schau dir den InitString des CUL dann an, er muss vier Zeilen groß sein

[eisi]

Neue Versionen sind drin.

initString X21
Ich habe gerade die V1.26.08 herunter geladen.
Meinst du , die ist besser?

[Wzut]

Sorry , wer lesen kann ist klar im Vorteil :

initString X21
Zr
Za123456
Zw111111

dadurch das er CR enthält stehen die im list natürlich unter einander - also alles gut bei dir.

aber da du nun die neuen Versionen hast :
Ich habe das logging nochmal angepasst um bei dem obern beschrieben Fehler zu sehen warum dein CULMAX Device der Meinung ist nicht auf seine eigen ID regaieren zu müssen.
Aber zurück nochmal zum rf error : Setz doch bitte beim CULMAX und bei dem rf error Device jeweils das Attribut debug auf 1.
Nach ein paar Stunden (bzw morgen) sieht man dann anhand der neuen Readings mit wem es reden möchte. Du must dann natürlich schauen ob diese Geräte bei dir auch vorhanden sind oder ob da irgend ein Phantom dabei ist. 

EDIT : in der 14_CUL_MAX die du runter geladen hast war noch ein Tippfehler , bitte nochmal austauschen , sorry
Und ich habe eine Möglichkeit gefunden wie es zu deinem Problem kommen kann :
Wenn es das Device bereits gibt und das Attribut dummy auf 1 sitzt , dann findet kein repairing/pairing statt !!!
   

[eisi]

Also:
Neue Version ist installiert.
Debug steht auf 1 bei Culmax0 und beim Thermostat.
Beide haben keinen Dummystatus. Wäre ja irgendwie blöd

Log des Thermostats:

Code Auswählen Erweitern


019-12-30_09:55:45 MAX_138816 sendTo_000000: 317
2019-12-30_09:57:50 MAX_138816 temperature: 18.8
2019-12-30_09:57:50 MAX_138816 deviation: 1.3
2019-12-30_09:57:50 MAX_138816 valveposition: 10
2019-12-30_09:57:50 MAX_138816 17.5°C (rf error)
2019-12-30_09:57:50 MAX_138816 desiredTemperature: 17.5
2019-12-30_09:57:50 MAX_138816 RSSI: -65.5
2019-12-30_09:57:50 MAX_138816 battery: ok
2019-12-30_09:57:50 MAX_138816 batteryState: ok
2019-12-30_09:57:50 MAX_138816 rferror: 1
2019-12-30_09:57:50 MAX_138816 gateway: 1
2019-12-30_09:57:50 MAX_138816 mode: manual
2019-12-30_09:57:50 MAX_138816 panel: unlocked
2019-12-30_09:57:50 MAX_138816 sendTo_000000: 318
2019-12-30_10:04:07 MAX_138816 temperature: 18.9
2019-12-30_10:04:07 MAX_138816 deviation: 1.4
2019-12-30_10:04:07 MAX_138816 valveposition: 0
2019-12-30_10:04:07 MAX_138816 17.5°C (rf error)
2019-12-30_10:04:07 MAX_138816 desiredTemperature: 17.5
2019-12-30_10:04:07 MAX_138816 RSSI: -67.5
2019-12-30_10:04:07 MAX_138816 battery: ok
2019-12-30_10:04:07 MAX_138816 batteryState: ok
2019-12-30_10:04:07 MAX_138816 rferror: 1
2019-12-30_10:04:07 MAX_138816 gateway: 1
2019-12-30_10:04:07 MAX_138816 mode: manual
2019-12-30_10:04:07 MAX_138816 panel: unlocked
2019-12-30_10:04:07 MAX_138816 sendTo_000000: 319
2019-12-30_10:39:41 MAX_138816 temperature: 18.2
2019-12-30_10:39:41 MAX_138816 deviation: 0.7
2019-12-30_10:39:41 MAX_138816 valveposition: 14
2019-12-30_10:39:41 MAX_138816 17.5°C (rf error)
2019-12-30_10:39:41 MAX_138816 desiredTemperature: 17.5
2019-12-30_10:39:41 MAX_138816 RSSI: -67
2019-12-30_10:39:41 MAX_138816 battery: ok
2019-12-30_10:39:41 MAX_138816 batteryState: ok
2019-12-30_10:39:41 MAX_138816 rferror: 1
2019-12-30_10:39:41 MAX_138816 gateway: 1
2019-12-30_10:39:41 MAX_138816 mode: manual
2019-12-30_10:39:41 MAX_138816 panel: unlocked
2019-12-30_10:39:41 MAX_138816 sendTo_000000: 320


[Wzut]

Log des Thermostats:

Sorry, aber das ist kein Log sondern eine Kopie aus deinem Event Monitor
Aber anyway, behalte mal von dem Ding die Readings im Auge die mit sendTo beginnen. Die _000000 sind Broadcasts an alle, hier wird sich der rf status nie ändern, da ka keine Rückmeldung von irgendwem erwartet wird. Interessant sind alle die ein echtes Ziel haben, meldest sich hier ein Partner nicht so erzeugt dies den rf error.

[eisi]

Nein, das ist der letzte Rest von : FileLog_MAX_138816
Das einzige Sendto-Reading geht nach 000000

[Wzut]

jaaaa und in diesen File_Logs stehen die Meldungen vom Event Monitor
Wenn ich Log schreibe dann meine ich damit

Code Auswählen Erweitern

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m-%d.log FakeLog
denn nur da landet alles was die Module intern mit Log3 an Logging Ausgaben prodizieren.

Nimm mal bei deinem HT für min. eine Minute die Batterien raus und wieder rein und schau im Log  ob es direkt neu kommt.

[eisi]

Achso Sorry.

Also Batterie raus und mach einer Minute wieder rein:

Code Auswählen Erweitern


2019.12.30 17:20:53 4: CUL_Parse: cul_oben V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBe (F-Band: 868MHz)
2019.12.30 17:21:17 4: CUL_Parse: cul_oben Z0F00046013881600000000590B2300B70F -66.5
2019.12.30 17:21:17 5: CULMAX0, IO cul_oben, len 15, msgcnt 00, msgflag 04, msgType ThermostatState, src 138816, dst 000000, group 0, payload 590B2300B7, rssi -66.5
2019.12.30 17:21:17 5: CULMAX0: dispatch MAX,0,ThermostatState,138816,590B2300B7
2019.12.30 17:21:17 5: MAX_Parse, MAX,0,ThermostatState,138816,590B2300B7
2019.12.30 17:21:17 5: MAX_138816, bat 0, rferror 1, panel 0, langateway 1, dstsetting 1, mode 1, valveposition 11, desiredTemperature 17.5, curTemp 18.3
2019.12.30 17:21:31 4: CUL_Parse: cul_oben Z1700000013880C123456001001A04D45513133343235363111 -65.5
2019.12.30 17:21:31 5: CULMAX0, IO cul_oben, len 23, msgcnt 00, msgflag 00, msgType PairPing, src 13880c, dst 123456, group 0, payload 1001A04D455131333432353631, rssi -65.5
2019.12.30 17:21:31 4: CULMAX0, PairPing (dst 123456, pairmode 0), firmware 16, type HeatingThermostat, testresult 160, serial MEQ1342561
2019.12.30 17:21:31 3: CULMAX0, device MAX_13880c want to be re-paired to 123456, not to us [123456] - ignoring !
2019.12.30 17:21:31 4: CUL_Parse: cul_oben Z0A000A0313880C1234560011 -65.5
2019.12.30 17:21:31 5: CULMAX0, IO cul_oben, len 10, msgcnt 00, msgflag 0A, msgType TimeInformation, src 13880c, dst 123456, group 0, payload , rssi -65.5


[eisi]

Noch was :

Ich habe mal ein anderes Thermostat auf Debug gestellt:

Code Auswählen Erweitern


sendTo_000000 20 2019-12-30 17:18:06
sendTo_123456  1  2019-12-30 14:13:09


Auch das will eine Menge Daten an 000000 senden, sehe ich das richtig?

[Wzut]

Das senden an 000000 ist völlig ok, das machen die Dinger immer wenn sie der Meinung sind irgend jemand müsste jetzt Werte von ihnen wissen.
Deine sendTo_123456 ist eine Nachricht die direkt an dein cm Device ging , z.B. wenn es seine interne Uhr neu stellen möchte

Ich versteh noch immer nicht so ganz warum aber bei dir das repairing scheitert, es gibt jetzt nur noch eine Stelle in 14_CUL_MAX wo das passieren kann :

Code Auswählen Erweitern

$isToMe    = 0 if (exists($modules{MAX}{defptr}{$src}) && IsDummy($modules{MAX}{defptr}{$src}->{NAME}));
Kannst du bitte mal diese Zeile suchen und auskommentieren / löschen und 14_CUL_MAX mit reload neu laden oder FHEM neu starten.

[eisi]

Jetzt ist es weg.
Es funktioniert.

Edit:
Ich habe den Cube auch auf die neueste Firmware gebracht.

[Wzut]

OK, THX dann ist schon mal klar wo ich nachbessern muß BTW: das Thema fehlende off Anzeige habe ich auch gefunden.