nanoCUL868 pairing funktioniert leider nicht

[hgw77]

Hallo,

ich habe eine NanoCul (FW 1.67) bei mir am laufen der bisher einwandfrei über CUL_MAX alle Messages meiner Max Komponenten mitgelesen hat. Weiter habe ich bisher auch eine MaxCube im Einsatz mit dem ich über MAX_LAN die gewünschten Temperaturen etc. setzte. Nun wollte ich Stück für Stück voll auf den NanoCul migrieren um den Cube mit seiner recht eigensinnigen Software loszuwerden.

Um einen ersten Test zu machen habe ich dafür ein Thermostat im MaxCube und Fhem gelöscht und anschliesend dieses zurück gesetzt. Wenn ich dann im CUL_MAX device das paring anwerfe und anschliesend das Thermostat in den Pairing modus versetze sehe ich wie Daten für das Device im Log eintreffen. Doch der Countown am Thermostat läuft von 30-0 durch jedoch sehe ich danach nicht das Antennen Symbol was heist das dass Pairing nicht geklappt hat (zum vergleich wenn ich das gleiche mit dem Cube mache hat er spätestens bei 26 gepairt und das Antennensymbol ist da).
Jedoch wurde beim pairing ein neues Device mit allen üblichen Daten angelegt wo aber im State "waiting for data" steht. Es kommt dann auch nach langen warten keine weiteren Daten rein und auch ein steuern des Thermostat vom Fhem aus schlägt wie erwartet fehl. Es scheint als ob da irgendwo der letze Schritt fehlt um das pairing zu vollenden 

Ich habe hier im Forum zu dem Fehler "waiting for data"  recherchiert aber bin nicht so recht fündig geworden. Für mich scheint es so als ob irgendwie der Rückkanal zu Thermostat nicht aufgebaut wird.

Kann jemand hier weiterhelfen?

[hgw77]

Vielleicht sollte ich erwähnen das ich noch einen zweiten CUL im system habe.

CUL_0 = fs20 = /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1234
CUL_1 = MAX = /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@38400 0000

im Log kann ich beim pairing folgendes finden

Code Auswählen Erweitern


2019.11.03 18:08:46 2: MAX_Parse: Don't know how to interpret Ack payload for
2019.11.03 18:09:47 3: CUL_MAX_Parse: Pairing device 1ba5fb of type HeatingThermostat with serial OEA
2019.11.03 18:09:47 1: Device changed serial from O to OEA
2019.11.03 18:09:48 3: CUL_1: Unknown code ZERR300, help me!


Code Auswählen Erweitern


2019.11.03 21:52:07 4: CUL_Parse: CUL_1 ZERR300
2019.11.03 21:52:07 5: CUL_1: dispatch ZERR300
2019.11.03 21:52:07 3: CUL_1: Unknown code ZERR300, help me!
2019.11.03 21:52:07 5: CUL_MAX_SendQueueHandler: 4 items in queue


[Wzut]

warum machst du es dir so schwer ?
a. es gibt keinen Grund bereits in FHEM vorhandene Geräte wieder zu löschen
b. auch den Werksreset kannst du dir in deinem Fall sparen : deine verwendete ID findest du im MAXLAN Device im Internal addr.

Tipp : gib dem CUL_MAX Device diese ID mit beim define. Dann ändere bei einem MAX Gerät das IODev von MAXLAN auf den CUL_MAX.
Cube vom Netz nehmen bzw. Stromlos machen. FHEM ggf. neu starten. Nun testest du dieses Gerät. Sollte es Probleme geben bist du nur mit Änderung des IODev wieder ganz schnell zurück auf dem bisherigen Stand.

Edit : hat es einen Grund warum du den CULs beim define eine Baudrate mitgibst und dann noch zwei verschiedene ?

[hgw77]

Dank dir für die Antwort.

a. es gibt keinen Grund bereits in FHEM vorhandene Geräte wieder zu löschen

Das die ID immer gleich bleibt und somit das gleiche Gerät nach dem löschen wieder angelegt wird das habe ich mitbekommen (ich dachte nur ich gehe auf nummer sicher wenn ich es vorher lösche ). Dieses Verhalten finde ich sehr angenehm da man so das Device immer sauber identifizieren kann 

b. auch den Werksreset kannst du dir in deinem Fall sparen : deine verwendete ID findest du im MAXLAN Device im Internal addr.

Da bin ich jetzt ein wenig verwirrt im Wiki (https://wiki.fhem.de/wiki/MAX#CUL_MAX) steht zum anlernen mit CUL:

Das Anlernen funktioniert nur mit zurückgesetzten (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostat betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können nicht an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Weshalb oder in welchem Fall muss nun zurück gesetzt werden oder ist der Eintrag im Wiki nicht mehr aktuell?
Ist es am Ende egal wo gepairt wurde (ob am Cube oder CUL)? Und da ich das pairing am Cube durchgeführt habe muss ich nur das IODev ändern den Cube abklemnmen und alles ist gut?

EDIT:ich habe gerade mal das IODev auf CUL_MAX umgestellt und es geht tatsächlich, das Thermostat das vorher über den Cube gepairt wurde lässt sich über den CUL ansprechen und die Temperatur ändern Also scheint die Doku im Wiki falsch zu sein? hatte noch den Cube angesteckt und der Befehl ging wohl doch darüber

Dem Verhalten nach zu urteilen ist das pairen also am Ende nichts weiter als das dass Thermostat in einem Modus versetzt wird indem es seinen Zustand sendet und Befehle entgegennimmt, dabei ist es Egal ob vom Cube oder CUL?

Tipp : gib dem CUL_MAX Device diese ID mit beim define. Dann ändere bei einem MAX Gerät das IODev von MAXLAN auf den CUL_MAX.

was meinst du damit? bei mir werden die geräte mit autocreate direkt angelegt, sprich ich muss dann eigentlich nur noch das IODev ändern.

hat es einen Grund warum du den CULs beim define eine Baudrate mitgibst und dann noch zwei verschiedene ?

das ist wohl historisch so gewachsen, der CUL_0 ist ein originaler Busware CUL und der CUL_1 ist ein nanoCUL. Ich habe versucht den nano mit 9600 baut zu betreiben aber das geht gar nicht aber ich sehe gerade in der Fhemref das die bautrate optional ist. Danke für den Tip

[Wzut]

Das Wiki ist nicht ganz am Puls der Zeit , u.a. gibt es auch Aussagen die schlichtweg falsch sind, leider.

Faktory Reset ist ok, wenn man die Dinger gebraucht gekauft hat und auf Nummer sicher gehen will.
Oder sie waren an einem Cube und man hat die ID nicht mehr zur Hand.
Du hast aber das Glück das z.Z. ja die Dinger noch mit MAXLAN laufen also kannst du dir die aktuelle ID (addr) anschauen und diese beim define des CUL_MAX Device benutzen -> das ist im Wiki das cm mit der blöden 123456 und genau diese 123456 verwendest du nicht sondern wie ich geschrieben habe die sechstellige Zahl des MAXLAN unter Internals addr
Lies zur Einstimmung mal https://forum.fhem.de/index.php/topic,104084.0.html , da ging es auch um einen Mischbetrieb und mehr Arbeit als nötig gewesen wäre.

Dem Verhalten nach zu urteilen ist das pairen also am Ende nichts weiter als das dass Thermostat in einem Modus versetzt wird indem es seinen Zustand sendet und Befehle entgegennimmt, dabei ist es Egal ob vom Cube oder CUL?

Nein beim parring bekommt das Ding gesagt wer sein Chef ist und den muss er intern speichern und immer auf ihn hören.

[hgw77]

Ok das ist ja genial

die Frage die sich mir dann noch stellt ist, wieso funtzt das Pairing mit dem CUL nicht? habe jetzt das besagte Thermostat wieder mit dem Cube gepairt. Ging wunderbar

Ich vermute jetzt echt das meine Credits das Problem sind denn wenn ich versuche einen Befehl an ein Thermostat abzusetzen bekomme ich

CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 110. Waiting 102 seconds. Currently 8 messages are waiting to be sent.

Kann es sein das dass der Grund ist weshalb das pairen mit dem CUL nicht ging?

wenn ich ein "list CULMAX0" mache bekomme ich

Internals:
   CULMAX0_MSGCNT 1
   CULMAX0_TIME 2019-11-03 22:43:38
   CUL_1_MSGCNT 12792
   CUL_1_RAWMSG Z0BEF06301A0B861701FD0010
   CUL_1_RSSI -78.5
   CUL_1_TIME 2019-11-04 18:46:22
   DEF        1701fd
   FUUID      5db9f007-f33f-7280-31c1-4474042d7c728c5c
   IODev      CUL_1
   LASTInputDev CUL_1
   MSGCNT     12793
   NAME       CULMAX0
   NR         603
   STATE      Defined
   TYPE       CUL_MAX
   addr       1701fd
   cnt        0
   pairmode   0
   retryCount 0
   READINGS:
     2019-11-04 18:41:28   packetsLost     7
   sendQueue:
     HASH(0x2d73c68)
     HASH(0x2b5cd70)
     HASH(0x2c725d8)
     HASH(0x27a3570)
     HASH(0x2a9a690)
     HASH(0x2cecf90)
     HASH(0x2c48590)
     HASH(0x2791f18)
     HASH(0x2704000)
Attributes:
   IODev      CUL_1
   room       __BackendConfig,___max

ich verstehe nicht wo diese lange Queue herkommt denn ich sende da nichts und die queue wird auch nach langen warten nicht wirklich kleiner. Sie verringert sich immer mal um eins zwei und dann kommt wieder was dazu obwohl ich nichts vom Fhem geschickt habe. Kann man die sendQueue löschen?

Vielleicht sollte ich erwähnen  das bei mir das ganze Haus mit Max ausgerüstet ist und da kommen ca. 60 Komponenten zusammen. Wenn ich in den Event Monitor schauen ist da ständig was los aber das ist ja nur empfangen und nicht senden. Oder geht das auch auf kosten der Credits?

[Wzut]

Leider gibt es keinen Befehl zum löschen der sendQueue, da hilft nur FHEM neu starten.
Und ja wenn da noch Aufträge drin sind die wie auch immer gar nicht abgearbeitet werden können ist das mit den Credits ein Teufelskreis und u.a. wird das pairing auch nicht gehen da die dafür nötigen Telegramme hinten in der Queue anstehen.
Credits werden praktisch ständig verbraucht und sei es "nur" als Quittung für ankommende Meldungen, bei 60 Geräten sind da schon ein paar, aber mach dir doch ein SVG dafür dann siehst du immer schnell was los ist. Und bei der Gelgenheit autocreate auf disable, das ist sonst auch so ein Credit Fresser wenn mal wieder durch ein defektes Telegramm ein fiktives Device angelegt wurde und CUL_MAX meint ständig damit reden zu müssen.

[hgw77]

OK ich weis jetzt wieso die Queue so voll war, der MaxScanner hat da auch noch reingehauen. Da muss ich mir mal die Credits Geschichte genauer anschauen. Ich hoffe nur das durch den Empfang der Daten nicht alle Credits aufgefressen werden. Man kann sich da ja nicht dagegen wehren, die werden ja von den Geräten gesendet ob man will oder nicht

Und noch eine kleine Frage: ich habe aufgrund der Menge der Geräte zwei Cubes im Einsatz. Jetzt muss ich also wenn ich nicht einen Teil neu anlernen will noch einen Zweites CUL_MAX device mit der Adresse des zweiten Cube anlegen. Kann das auch über den gleichen CUL laufen? Vorrausgesetzt ich bekomme das Problem mit den Credits in den Griff.

[Wzut]

ah bei zwei MAX Inseln sieht das mit den Credits natürlich besser aus, da ja jede ihr eigenes Konto hat.
Natürlich kannst du die zu einer machen, ich würde es aber bei der großen Anzahl nicht tun. Also entweder noch einen CUL kaufen oder auch den CUBE den du nun nicht mehr brauchst umflashen. (Vorteil USB+ LAN )  Oder im Martplatz mal nach einem Maple schauen, da hat man mit 4 +1 genug Sende Geräte.
Hängt aber von deinem Haus ab, beide via USB am gleichen Platz (CUL) oder doch besser verteilt im Haus via LAN (CUBE,Maple)

[hgw77]

hmmm irgendwie zu früh gefreut, die Credits sind jetzt wieder soweit OK aber jetzt bekomme ich wenn ich am Thermostat (das mit IODev auf dem CULMAX0 zeigt) etwas einstellen will

CUL_MAX_SendQueueHandler: Missing ack from 1ba5fb for 0b0704401701fd1ba5fb074a

dem CUL_MAX habe ich die Adresse des Cube mit "defmod CULMAX0 CUL_MAX 1701fd" verpasst und da steht dann auch unter addr die entsprechnden Adresse. Also sollte das Schalten eigentlich gehen. Aber anscheinend akzeptiert das Thermostat den Befehl von Fhem nicht

[hgw77]

OK ich glaube ich gebe an dieser Stelle erst einmal auf, die Probleme sind doch größer als gedacht und ich habe hier schon viel zu viel Zeit verbraten ohne zum Ziel zu kommen 

Das obige Problem plus das Problem mit den Credits plus dem Umstand das ich ein neues Device nicht mit dem CUL gepairt bekomme lassen mich zu dem Schluss kommen das ich da doch mal das ganze in einem kleineren kontrollierten Umfeld testen sollte. Gerade Teste ich auf meinem produktiven Fhem (eigentlich keine gute Idee) und da ist neben dem MAX auch noch einige anderes los.

Sprich um das Problem einzugrenzen werde ich mir nochmal wenn ich zeit  habe einen Raspi mit neuem Fhem aufsetzen und dort mit einem CUL und einem Thermostat testen

Ansonsten nutze ich einfach die Kombi Cubes zum Schalten und CUL um live Änderungen mitzubekommen. Damit kann ich auch erst mal leben. Ich mag eben nur nicht diese Hackelige und  proprietäre Software der Cubes, da würde ich trotzdem gerne wegkommen

[Wzut]

Hattest du den CUBE noch am Netz als du das mit seiner ID auf dem CUL_MAX versucht hast ?
Wenn ja , keine gute Idee , dann gibt es zwei Chefs ...
Aber generell : Ist natürlich immer einfacher klein anzufangen und dazu muss es kein extra Raspi sen, es kann auch eine zweite FHEM Instanz auf anderen Ports sein.