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
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
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
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
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.
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
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
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
Hallo Martin,
kann man dem vd irgendwie beibringen, dass er bei uns unterschrittener Temperatur weniger stark aufdrehen soll?
Grüße Steven
kenne ich nichts...
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).
Jetzt habe ich keine Einträge mehr unter configCheck...
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
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
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
Danke für die Antwort,
ist es dir möglich mal den Strom zu messen?
Meine Batterien sind schon sehr leer, das Ding blinkt bloß rot und hat eine Meldung übertragen und es sind ca 4,3mA kurzzeitig springt der Wert hoch auf 9-12mA beim senden. In Ruhe ist es etwas über 1,1mA.
Ich habe mal kurz gegockelt und gesehen das die Knopfzellen mit ner Kapazität von 125mAh angegeben sind (pro Zelle).
Das erklärt auf jeden Fall die knappe Woche Laufzeit.
kann ich heute Abend einmal probieren, Betoning liegt auf Abend ;D
Ich habs jetzt einmal mit meinem Fluke Messgerät gemessen
Power on lag zw 11 und 17 mA
Griff betätigung 11 und 14 mA
Ruhe bei 0.00 mA
mit einem Digitalen Messgerät ist das echt ne Schätzerei, weil die Stromaufnahme schwankt
die Messungen waren von einem RHS, auch mit 2 Knopfzellen, :)
ich verwechsle Rhs un SC immer, sorry
Hast du vielleicht die günstigen Zink-Kohle- statt Silberoxid Zellen gekauft?
Die haben nicht nur eine geringere Kapazität sondern auch eine niedrigere Spannung...