Hallo!
Ich habe vor einiger Zeit das erste mal FHEM auf einer kleinen Tux-Buechse unter Debian installiert. Das funktionierte auch recht gut und recht schnell hatte ich die ersten Komponenten angelernt und mir FHEM so konfiguriert, wie ich es haben wollte. Allerdings traten dann vor einiger Zeit ein paar Probleme auf, als ich einen zweiten LAN-Adapter in das System eingebunden habe. Beispielsweise konnte ich die desired-temp des von mir verwendeten Heizungsthermostats nicht mehr setzen. Ich suchte nach einer Loesung fuer mein Problem, fand aber bisher keine, stiess aber bei meiner Suche auf den Hinweis, dass man doch das Pairing der Komponenten ueberpruefen solle. Das tat ich und bekam folgende Ausgabe:
configCheck done:
missing register list
Actuating_Drive_HS6: RegL_00:
Beamer_Contact_HS6: RegL_00:
Beamer_Gyro_HS6: RegL_00:
Door008: RegL_00:
DoorHS6: RegL_00:
Thermostat: RegL_00:
Thermostat_HS6: RegL_00:
Thermostat_HS6_Climate: .RegL_05:,.RegL_06:
peer list not read
empty: Actuating_Drive_HS6
empty: Beamer_Contact_HS6
empty: Beamer_Gyro_HS6
empty: Door008
empty: DoorHS6
empty: Thermostat
empty: Thermostat_HS6_Climate
empty: Thermostat_HS6_WindowRec
PairedTo missing/unknown
Actuating_Drive_HS6
Beamer_Contact_HS6
Beamer_Gyro_HS6
Door008
DoorHS6
Thermostat
Thermostat_HS6
PairedTo mismatch to IODev
Smoke_HS6 paired:0x1DB85D IO attr: 1A1A1A
Hoert sich erstaml nicht wirklich gut an, aber ich habe leider keinerlei Ahnung, was das nun eigentlich genau bedeutet und wie ich das Problem beheben kann. Eine Dokumenation zu diesem Thema habe ich leider nicht gefunden und eine Suche nach beispielsweise "fhem PairedTo missing/unknown" blieb erfolglos. Daher meine Fragen:
1) Was bedeutet diese Ausgabe fuer mich?
2) Wie kann ich dieses Problem beheben?
3) Wie kann ich diese Probleme in Zukunft vermeiden?
Vielen Dank fuer eure Hilfeund viele Gruesse
Andi
Hallo Andi,
Das meiste sind erst einmal hinweise, nicht unbedingt fehler.
configCheck done:
Zitat
missing register list
peer list not read
PairedTo missing/unknown
mache ein getConfig fuer die Devices, dann sollten die Daten zu Verfügung stehen. FHEM kennt aktuell einfach die Programmierung der Devices nicht.
ZitatPairedTo mismatch to IODev
Smoke_HS6 paired:0x1DB85D IO attr: 1A1A1A
das könnte dein Problem sein.
du hast 2 HMLAN
- habe diese die gleiche HMId?
- welches Konzept willst du nutzen - gleiche ID oder 2 unterschiedliche Segmente mit getrenner ID?
- hast du in allen devices das Attribut IODev auf den gewünschten Adapter gesetzt? Rate ich in jeden Fall dazu.
Gruss Martin
Hallo Martin!
Erst einmal vielen Dank für deine Antwort. Ich habe bereits probiert mit
set DoorHS6 getConfig
die Konfiguration zu laden, doch das war leider nicht von Erfolg gekröhnt. Gibt es hier noch etwas auf das ich achten müsste? Oder gibt es vielleicht noch eine Andere Möglichkeit diesen Prozess anzustoßen?
An dem folgenden Abschnitt wundert mich im übrigen am meisten, dass mir diese ID (
0x1DB85D) nicht bekannt ist. Sie kommt kein einziges mal in der fhem.cfg auf.
ZitatPairedTo mismatch to IODev
Smoke_HS6 paired:0x1DB85D IO attr: 1A1A1A
Die zwei LAN-Adapter, die ich verwende haben nicht die gleiche HMID. Ist es denn möglich beiden Adaptern die selbe ID zuzuweisen? Das wäre sehr praktisch, da es bei weitem nicht bei zwei Adaptern bleiben wird. Und ja IODev ist bei allen Geräten gesetzt worden, damit es nicht zu Problemen kommt, da es sein kann, dass sich die Funkgebiete der Adapter überschneiden. Welche vor und Nachteile haben denn die von dir angesprochenen Konzepte?
Viele Grüße
Andi
Zitatdie Konfiguration zu laden, doch das war leider nicht von Erfolg gekröhnt
beachte, dass einige Devices nur mit uns reden, wenn du config drückst. Das sind meist Batteriebetriebene.
Die ID 0x1DB85D ist eigentlich 1DB85D. "0x" ist ein üblicher Hinweis, dass es sich um eine hex-zahl handelt.
ZitatIst es denn möglich beiden Adaptern die selbe ID zuzuweisen?
ja.
Du kannst ein 'getrenntes' system bauen. Dann musst du die Devices jeweils mit den IO (also dem Adapter) pairen. Genau genommen hast du zu FHEM Zentralen mit je einem IO...
Oder du gibts allen die gleiche HMId. Dann hast du ein System mit einer Zentrale, welche 2 IOs hat.
In beiden Fällen solltest du jedem Device das Attribut IODev zuweisen. FHEM sucht andernfalls mehr oder weniger glücklich ein IO aus.
Empfangen werden in beiden Fällen alle IOs und die Infos werden verarbeitet. Nur senden wird immer das Device, das in Internals:IODev steht. So du das Attribut IODev vergeben hast wird dies auch in Internals verwendet!
HMLAN/USB senden auch automatisch ACKs, wenn ihnen das Device zugewiesen ist....
Gruss Martin
Hallo Martin,
Zitatbeachte, dass einige Devices nur mit uns reden, wenn du config drückst. Das sind meist Batteriebetriebene.
Danke fuer deine Antwort. Hatte nun endlich mal wieder Zeit mich damit zu beschaeftigen.Das Konfigurieren der Devices hat nur teilweise geklappt, obwohl ich beispielsweise bei den Tuerkontakten den Anlernknopf kurz gedrueckt habe.
ZitatOder du gibts allen die gleiche HMId. Dann hast du ein System mit einer Zentrale, welche 2 IOs hat.
Hier sollte ich aber dennoch das IODev in der Konfiguration explizit angeben, richtig?
Leider sind nun zwei neue etwas merkwuerdige Fehler aufgetreten. Der Rauchmelder liefert nun keine Fehlermeldung mehr und scheint auch korrekt angelernt zu sein (laut readings), aber er ist nicht ansprechbar. Zudem taucht ein neuer mir unbekannter Fehler auf, wenn ich einen Config-Check durchfuehre:
configCheck done:
missing register list
Beamer_Gyro_HS6: RegL_00:
Door008: RegL_00:
DoorHS6: RegL_00:
Thermostat: RegL_00:
peer list not read
empty: Beamer_Gyro_HS6
empty: Door008
empty: DoorHS6
empty: Thermostat
empty: Thermostat_HS6_Climate
empty: Thermostat_HS6_WindowRec
PairedTo missing/unknown
Beamer_Gyro_HS6
Door008
Thermostat
Thermostat_HS6_A2
PairedTo mismatch to IODev
Thermostat_HS6_A1 paired:invalid IO attr: 1A1A1A
Bei
Thermostat_HS6_A1 handelt es sich nicht um ein Wandthermostat, sondern um einen mit dem Wandthermostat
Thermostat_HS6 verbundenen Stellantrieb. Mich wundert es, dass zwar eine Fehlermeldung fuer
Thermostat_HS6_A1, aber nicht fuer
Thermostat_HS6_A2 ausgegeben wurde. Beide wurden automatisch von FHEM angelegt, als ich
HMLAN2 mit
Thermostat_HS6 gepaired habe. Ausserdem wurden zwar
Thermostat_HS6_A1 und
Thermostat_HS6_A2, aber nicht
Thermostat_HS6_A3 angelegt, obwohl drei Stellantriebe angeschlossen sind (im Thermostat ueberprueft).
Wodurch koennten diese neuen Fehler verursacht worden sein und wie kann ich sie beheben?
Viele Gruesse Andi
Hallo Andi,
ZitatHier sollte ich aber dennoch das IODev in der Konfiguration explizit angeben, richtig?
das sind 2 Verschiedene Dinge, da gibt es mehr Möglichkeiten, zu mindest für größere Systeme.
Einmal grundsätzlich
- ein device sollte immer gepairt sein
- das attr IODev muss man nicht setzen, sollte man aber. Beim pairen wird es automatisch gesetzt. Wenn man es nicht setzt ist es eine Lotterie - hat man nur ein IODev für HM ist es einfach. Besser immer sauber arbeiten...
- man kann mehrere IO devices in FHEM haben. Diese können diese die selbe oder unterschiedliche HMId haben, beides zulässig
- Das IO device legt fest, über welches IO gesendet wird. Empfangen kann jedes IO, es wird immer verarbeitet. Nur das Senden wird kanalisiert.
- senden sollte man immer über ein IO, das auch die HMId hat, mit der gepairt wurde.
=> man kann somit Einstellungen vornehmen, die Lastteilung oder Reichweitenprobleme berücksichtigen
ZitatPairedTo mismatch to IODev
Thermostat_HS6_A1 paired:invalid IO attr: 1A1A1A
HMInfo geht von strikter implementierung aus. Es wird gekrüft,dass das Attibut IODev mit dem übereinstimmt, welches im Register pairCentral steht. Bei dir ist das Register nicht gelesen - daher der Fehler - keine Übereinstimmung.
Dein SD sollte immer noch ansprechbar sein... wenn schicke einmal logs - mache ein statusRequest und ein getConfig. Das sollte gehen
Gruss Martin
Danke fuer deine Hilfe. Konnte dank deiner Erklaerung nun auch den Fehler von Thermostat_HS6_A1 loesen, indem ich ein getConfig auf Thermostat_HS6 ausgefuehrt habe.
Soweit ich das nun mit den zwei moeglichen Varianten IOs zu nutzen verstanden habe, macht es schon Sinn allen HMLAN-Adaptern die gleiche ID zuzuweisen. Frage ist nun, ob ich dann alle Geraete, die aktuell an einen Adapter angelernt sind, dessen ID ich aendere, wieder neu angelernt werden muessen oder ob es dafuer eine einfachere Moeglichkeit gibt.
Danke und Viele Gruesse
Andi
EDIT: Habe gerade festgestellt, dass Tuer-/Fensterkontakte nach ca. ein bis zwei Tagen einen IOerr anstatt ihres aktuellen Zustands anzeigen. Ein einfaches clear msgEvents hilft hier fast immer und zur Not macht man die entsprechende Tuer einmal auf und wieder zu. Trotzdem stoert es. Kann man dieses Problem irgendwie durch eine regelmaessige Statusabfrage beheben?
IOerr bedeuted, das IO hat einen Error. Genauer: Das Device kann nicht senden, da das IO einen Error hat. Aktion: schaue im IO nach (also CUL oder HMLAN/USB) was für Probleme vorliegen.
Wenn so ein Problem vorliegt gibt die Daten des IO einmal durch. Auch die message statistiken aus HMInfo könnten interessant sein.
Prinzipiell könnte
- HMLAN disconnected sein (verschiedenen Ursachen möglich)
- HMLAN in overload sein
Ein clear msgEvents sollte hier nicht helfen - es ist wohl eher die Zeit, die dies braucht. Dann hat sich das IO wieder erholt.
Gruss Martin