Probleme Cul-HM-TC VD SC

[fidel]

Hallo,

ich habe seit einiger Zeit genannte Homematic Komponenten und habe arge Probleme diese mit fhem zum laufen zu bekommen.

Ich hatte alle Komponenten nach Wiki und einigen Forum-Themen einmal mit Fhem bzw. dem HM Lan gepairt und auch die peerings unter den Komponenten richtig eingestellt und alles lief, mit der Einschränkung, dass 2 Batteriesätze im SC nach ca 1 Woche leer waren.

Hiernach habe ich alles aus fhem gelöscht und die Komponenten resetet, um sie wieder in Betrieb zu nehmen.

Pairen mit dem HM-Lan Adapter funktioniert mit allen Komponenten ohne Probleme.
Danach setze ich die peerChan Befehle ab:
set sc pperChan tc-WindowRec single und
set tc-climate peerChan vd single.

Nach einiger Zeit erscheinen diese dann auch zumindest in den TC-Kanälen Climate und Window Rec.
Im SC und im VD selbst bekomme ich keine peering Einträge.
Dies hat zumindest beim ersten Mal nach einiger Zeit funktioniert.

Ich habe auch schon die Befehle:
set sc pperChan tc-WindowRec single set actor/remote
set tc-climate peerChan vd single set actor/remote
einzeln probiert und abschließend natürlich noch getconfig.

Trotzdem sind hiernach keine peerings eingetragen.

Grüße

[Rohan]

Hallo fidel,

hast du kürzlich Fhem-Updates installiert?

Ich hatte vor 1 bis 2 Wochen auch den Fall, dass ich 2 TCs neu mit den SCs und VDs manuell peeren musste bevor ich dann die TCs wieder mit Fhem gepairt habe, weil ich mit den gewohnten "set" Befehlen nicht zum Ziel kam.

Hatte aber auch kurz davor wieder erst angefangen, mir Updates zu installieren, da diese ja, vor allem wegen der erforderlichen Einarbeitung der RTs, schnell hintereinander kamen. Evtl. möglich, dass da auch mal was anderes betroffen war.

Ich hatte nach manuellem peeren aber auch nicht nochmals getestet, ob es wieder per "set" geht (habe keine Testumgebung).

Und nach dem getConfig immer schön die Anlerntaste drücken  . Das geht zumindest deutlich rascher.

Gruß
Thomas

Edith: "die" gegen "da" getauscht

[fidel]

Hallo Thomas,

fhem halte ich eigentlich immer ziemlich aktuell.
Was meinst du mit manuell peeren?Nur über den TC?

Das mit der Anlerntaste ist mir klar.

Ich habe auch schon probiert nur mit dem TC zu peeren und habe die dann wieder gelöscht, um danach mit fhem zu pairen und peeren.

Grüße
Steven

[martinp876]

Hi Steven,

sind das tipfehler? Das Kommando sollte lauten

set sc peerChan 0 tc-WindowRec single
set tc-climate peerChan 0 vd single

Die Namen, nehme ich an, sind korrekt...
zu beachten ist, dass VD und SC config mögen. am besten also anlernen drücken. Der VD kann auch wakeup, aber nur wenn er gepeert ist... und das machst du gerade.
Bei beiden sollten in jeden Fall die Kommandos übertragen werden - hoffentlich ohne, ggf. auch mit Fehlern (prot-Einträge prüfen!)
Der VD kann nur einen Peer - wenn also schon etwas eingetragen ist, muss es erst gelöscht werden. Wenn also ein Fehler auftritt, erst einmal auslesen.
Generell ist die Anzahl der Peers IMMER begrenzt - die Schwelle ist bei jedem Device anders.

Nach dem peeren (und jedem register-ändern) würde ich immer rücklesen - oder autoReadReg nutzen. Die Version von heute macht dies bei config-devices immer sofort nach Anlernen und ändern. Alternativ musst du es selbst  triggern.

Nebenbei: wenn du ein/alle devices aus FHEM löschst sind diese immer noch gepairt. einfach einmal anlernen drücken und sie sind wieder bereit. FHEM selbst braucht das pairen nicht.

Gruss Martin

[fidel]

Hallo Martin,

ich habe die Kommandos aus dem Kopf runtergeschrieben. Die 0 hatte ich auch vergessen.
Vom Kommando was ich absetze, sollte es passen.

Wenn ich die peer Befehle absetze, kommt im TC machmal CMD done errors.

Meinst du mit config, getconfig und mit prot-Einträge logs?

Ich probier es heute Abend nochmal und melde mich dann.

[martinp876]

Hi Steven,

es gibt einige Einträge - nur im Device eines Geräts - die "prot..." heissen. Diese sagen an, ob alles gut gegangen ist.
Das "cmds_done_error" sagt: senden ist beendet - es sind Probleme aufgetreten.  Du solltest dies dann prüfen.

Die Config kann man mit "getConfig" auslesen - ja, das meine ich.

Das alles ist recht mühsam über alle devices zu checken - daher gibt es HMinfo. das empfehle ich einzurichten - dann kannst du über die gesamte HM installation:
- protokoll-ereignisse in einer Tabelle darstellen
- vergangene Protokoll-zähler löschen (macht sinn um nicht alten Fehlern nachzujagen)
- peer-referenzen prüfen
- prüfen, on die Konfiguration der Teile gelesen ist, oder ob Infos unvollständig sind (keine 100% ganantie)

schau dir die Hilfe dazu an
oder
set hm help

Gruss Martin

[fidel]

Hi,

ich habe jetzt nochmal alles resetet und gelöscht und noch einmal neu gepairt und gepeert.
Und es hat auf Anhieb funktioniert.

Ich habe das selbe gemacht wie die Tage zuvor... Fhem habe ich noch nicht geupdatet...

Naja dann bin ich ja mal gespannt wie lange die Batterien vom SC diesmal halten...

Gruss Steven

[martinp876]

Hallo Steven,

ein Batterieaustausch sollte eigentlich kein Problem sein - die konfigurationsdaten der devices sollten alle in einem EEPROM/Flash stehen - davon gehe ich aus.
jedenfalls kannst du die Register eines Device auch erst einmal sichern  - und dann zurückschreiben. Sollte der SC tatsächlich alles vergessen haben musst du NUR den SC neu programmieren - falls vorhanden mit den gesicherten Daten aus "saveConfig"

Zum "sauberen" arbeiten sichere alles durch HMinfo - und kontrollieren es vorher mit "checkConfig" in HMinfo. Ist keine 100% garantie - aber den Test sollte es bestehen - das beruhigt ein wenig.

Gruss Marin

[fidel]

Hallo Martin,

kann man dem vd irgendwie beibringen,  dass er bei uns unterschrittener Temperatur weniger stark aufdrehen soll?

Grüße Steven

[martinp876]

kenne ich nichts...

[fidel]

Hi,

so jetzt bringt mein SC wieder Batteriestörung... Und von der Led her flackert es schon ziemlich, also sind die Btterien wieder bald platt.
HM-Info habe ich eingerichtet.
Unter peerXref erscheint folgendes:

peerXref done:
x-ref list
    CUL_HM_HM_CC_TC_1F5AE0_Climate =>CUL_HM_HM_CC_VD_1F4F7E_chn:01
    CUL_HM_HM_CC_TC_1F5AE0_WindowRec =>CUL_HM_HM_SEC_SC_1E331E_chn:01
    CUL_HM_HM_CC_VD_1F4F7E =>CUL_HM_HM_CC_TC_1F5AE0_Climate
    CUL_HM_HM_SEC_SC_1E331E =>CUL_HM_HM_CC_TC_1F5AE0_WindowRec

unter configCheck:

configCheck done:

missing register list
    CUL_HM_HM_CC_TC_1F5AE0_Climate:   .RegL_06:
incomplete register list
    CUL_HM_HM_CC_TC_1F5AE0_Climate:   .RegL_05:
peer list not read
peer list incomplete
peer not verified

Bis auf die Batteriestörung arbeitet eigentlich alles wie es soll.
Der Kontakt muss wenn es hoch kommt 3-4mal am Tag senden (Balkontür).

[fidel]

Jetzt habe ich keine Einträge mehr unter configCheck...

[martinp876]

Hallo Steven,

HMInfo sollte dir bei default settings den Batterie-alarm anzeigen. Spätestens wenn du ein "update" in HMinfo machst. HMinfo macht den update automatisch, wenn dass Attribut autoUpdate gesetzt ist.

wenn bei configCheck jetzt keine Einträge mehr sind wurde wahrscheinlich über autoReadReg die config verfollständigt. Jetzt sollten alle konfigurationsdaten in FHEM aktuell sein (es wird kein Datum geprüft...)

der SC sollte sich einmal an Tag automatisch melden. Sollte man über cyclicInfoMsg steuern können.

ein Batteriewechsel sollte kein Problem sein - und keine re-config notwendig machen.

Sicherheitshalber kannst du aber die config der Devices retten. Mit saveConfig - in CUL_HM je device oder in HMInfo für alle devices (oder mit Filter...)

Gruss Martin

[fidel]

Hallo Martin,

mein eigentliches Problem ist das ich in den letzten 3 Wochen 3 Batteriesätze durch den SC gejagt habe. Jetzt ist er wieder tot. Der TC meldet die Batteriestörung, in fhem steht unter Batteriestatus ok. Fhem bekommt dies nicht einmal mit. Der Kontakt macht jedoch gar nichts mehr.
Laut hminfo scheint er jedoch nicht sonderlich viele Meldungen abgesendet zu haben:

protoEvents done:
    name                :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    CUL_HM_HM_CC_TC_1F5AE0: done_Errors:1  | -        |150:      | -        #163       |32:       |1:        | -       
    CUL_HM_HM_CC_VD_1F4F7E:  -             | -        | -        | -        # -        | -        | -        | -       
    CUL_HM_HM_LC_SW4_PCB_19BBEE: done           | -        |181:      | -        # -        | -        | -        | -       
    CUL_HM_HM_OU_LED16_1AC6BE: done           | -        |2131:     |14:       #69        |2:        | -        | -       
    CUL_HM_HM_SEC_SC_1E331E: done_Errors:1  | -        |55:       | -        #1         |1:        | -        | -       

    CUL_HM queue:0
    autoRegRead pending:
    autoRegRead wakeup pending:
    status request pending:
    IODevs:HOMEMATIC:opened pending=0 condition:ok
            msgLoadEst: 1hour:0% 10min steps: 0/0/0/0/0/0

Was mir vielleicht noch auffällt ist, dass unter den Readings nur RegL_00,RegL_01 und RegL_04 auftauchen. Fehlen da noch Register? Oder ist das so?
Irgendwie würde ich gerne der Ursache für diese starke Entladung auf die Schliche kommen. Oder ist es ratsam den Kontakt umzutauschen?

Gruß
Steven

[LuckyDay]

Die Batterien in meinem Sc hält ca 1 Jahr, die Tür geht bestimmt am Tag 20 mal auf und zu.
Ich würde das Teil umtauschen! das ist kapput, bzw hat einen zu hohen Stromverbrauch