Homegear mit Openhab sehr unzuverlässig

[homegear_user]

Hallo,

ich bin ein Neuling und versuche folgende Konfiguration zum Laufen zu bringen:
10 x Max! Heizkörper-Thermostat
5 x Max! Fensterkontakt
1 x CUL - USB Stick von busware
Raspberry PI Modell B+
Alle Komponenten angelernt an Homegear
Steuerung über Openhab mit Homematic-Binding).
Zeitsteuerung über Openhab Google-Calender-Binding (Soll-Temperatur der Heizkörper-Thermostaten wird geändert)
Außerdem gibt es einige Rules in Openhab welche die Soll-Temperatur der Heizkörper-Thermostaten ändern z.B. wenn ein Fenster geöffnet wird.

Das Ganze funktioniert “im Prinzip”, ist aber leider total unzuverlässig. Mal bekommt der angesprochene Heizkörper-Thermostat mit dass die Soll-Temp. geändert wurde, aber meistens eben nicht.
Umgekehrt ist es ähnlich. Manchmal merkt openhab dass an einem Thermostat die Temp. (manuell) geändert wurde - meistens aber eben nicht.
In den Openhab-Logfiles kann ich nichts ungewöhnliches entdecken.
Es wurden immer wieder diverse Komponenten als “Unreach” = “Yes” angezeigt. Heute habe ich nochmal alle Komponenten von Homegear abgelernt, von Homegear entfernt, resettet und neu angelernt. Das Anlernen klappt übrigens total easy. nach 2-3 Sekunden sind die Geräte verbunden. Die Funkverbindung scheint also ziemlich gut zu sein. Seitdem bekomme ich kaum noch Komponenten als “Unreach” = “YES”. Trotzdem bleibt das System völlig unzuverlässig.

Kann mir jemand einen Tip geben woran das liegen kann?
Kann ich Homegear irgendwie sagen dass es die Kommunikation mit Openhab in ein Logfile schreiben soll damit ich sehe wo es hängt?
Wie kann ich mit Homegear interaktiv manuell die Solltemperatur eines HK-Thermostaten setzen um zu sehen ob es an der Kommunikation zwischen Homegear und Openhab liegt oder ob die Homegear-Kommandos nicht ankommen?

Bei Bedarf kann ich gerne die Openhab-Logfiles hochladen falls das etwas hilft.

Vielen Dank im Voraus für Eure Hilfe!

Christian

[sathya]

Hallo Christian,

die Infos, warum es unzuverlässig funktioniert, findest du im Homegear-Log. Poste mal die beiden Dateien “/var/log/homegear.log” und “/var/log/homegear.err”. Dann kann ich mehr dazu sagen .

Liebe Grüße

Sathya

[homegear_user]

Hallo Sathya,

vielen Dank für die schnelle Antwort !!
Gut zu wissen wohin Homegear loggt …
Anbei die beiden Files. Da läuft so einiges auf …

Ich habe am 01.03. am frühen Nachmittag begonnen alles neu aufzusetzen (Reset aller Komponenten, alles neu ge-paired, mehrere Reboots). Seitdem habe ich jetzt keine “Unreach”-Komponenten mehr. Ältere Einträge in den Logfiles sind daher vielleicht weniger hilfreich.

Wäre super wenn Du mir einen Tip geben könntest woran es liegen könnte.

Noch eine Frage: Kann ich eigentlich die Shared Libraries für nicht benötigte Module (z.B. Phillips Hue) entfernen? Ich brauche eigentlich nur die MAX-Library.

Schöne Grüße und nochmals vielen Dank für die Unterstützung,

Christian
Logfiles.zip (467 KB)

[sathya]

Hallo,

das Problem ist, dass du die 1%-Grenze erreicht hast. Auf dem 868MHz-Band darf maximal 1% der Zeit gefunkt werden. Die Sendezeit für ein MAX!-Paket ist mit einer Sekunde sehr lang. D. h. du kannst über den CUL (aber auch den MAX!-Cube) maximal 36 Pakete pro Stunde versenden. culfw teilt das meine ich in 15-Minuten-Blöcke (was nicht ganz der Vorschrift entspricht). D. h. du kannst mit der Standard-culfw-Einstellung maximal 9 Pakete in 15 Minuten versenden. Die Fehlermeldung im Log kann definitiv noch verbesssert werden und es darf auch eine Servicenachricht dazu geben… Füg ich gleich mal als GitHub-Issue hinzu.

Liebe Grüße

Sathya

[homegear_user]

Hallo Sathya,

Wahnsinn - kaum eine Frage gestellt - schon beantwortet! Super! Vielen Dank dafür!

Somit habe ich jetzt wohl ein größeres Problem oder?
Wenn das beim Einrichten oder beim Start passiert ist es ja nicht so schlimm.
Aber die LOVF - Meldungen kommen ja auch beim normalen Betrieb?!
Und das bei gerade mal 15 Komponenten …
Was passiert denn mit den Paketen die nicht gesendet werden? Werden die aufgeschoben oder verworfen?
Kann ich das Limit irgendwie erhöhen (auch wenn das eigtl. nicht erlaubt ist) ohne die CUL- Firmware zu ändern und neu zu kompilieren?
Da wo ich wohne störe ich sicherlich niemand anderen …

Schöne Grüße

Christian

[sathya]

Hallo Christian,

der einzige legale Weg, das Limit zu erhöhen, ist die Anschaffung eines weiteren CUL oder eines anderen Funk-Moduls. eQ-3 hat die Funk-Kommunikation von MAX! etwas doof implementiert. Dadurch ist das 1%-Limit wirklich schnell erreicht - zu schnell.
Allerdings sollte so oder so die Funkkommunikation nicht übertrieben werden, weil auch die Batterien der Geräte darunter leiden.

Was passiert denn mit den Paketen die nicht gesendet werden? Werden die aufgeschoben oder verworfen?

Aufgeschoben. Bei mehreren Änderungen der gleichen Variablen wird nur der letzte Wert gesendet. Gesendet werden die wartenden Pakete nach Empfang eines Pakets vom Gerät oder beim nächsten “setValue”.

Kann ich das Limit irgendwie erhöhen (auch wenn das eigtl. nicht erlaubt ist) ohne die CUL- Firmware zu ändern und neu zu kompilieren?

Du kannst es theoretisch erhöhen, allerdings nicht ohne Neu-Kompilieren.

Liebe Grüße

Sathya

[homegear_user]

Hallo Sathya,

ich habe jetzt mal testweise das Limit in der culfw erhöht. Seitdem gibt es keine “LOVF” -Einträge mehr im Logfile.
Es sieht aber so aus als ob das nicht das einzige Problem war.
Jedenfalls gibt es immer noch die alten Probleme wenn auch anscheinend etwas weniger.
Ich werde das jetzt mal eine Zeit lang beobachten und versuchen ein Muster zu erkennen.

Eine Möglichkeit Airtime zu sparen wäre es die Heizkörper im Wohnzimmer an den Wandthermostat zu binden und diesen die Heizkörper regeln zu lassen. Openhab soll dann nur die Solltemperatur des Therm. setzen und “mitlesen” was die Heizkörper so an Infos rauslassen. Das hat außerdem den Vorteil, dass die Raumtemperatur an einem festgelegten Ort gemessen wird und nicht jeder HK das sich selbst direkt am HK misst.
Kann ich mit Homegear die Geräte direkt verbinden?
Ich habe es mit der HomeMatic-Software versucht aber die scheint nicht mit MAX-Komponenten zu funktionieren. Das Einzige was damit geht ist das pairing zu aktivieren und Messages anzeigen zu lassen. Ansonsten heißt es überall nur dass keine Komponenten existieren.

Ist es eigentlich normal dass die Client-Server - Verbindung dauernd geschlossen und wieder neu aufgebaut wird?
Das Homegear-Logfile ist voll mit solchen Messages:

03/03/15 13:16:30.582 RPC Server (Port 2001): Info: Connection to client number 10038 closed (3).
03/03/15 13:16:30.601 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58174 accepted. Client number: 10039
03/03/15 13:16:30.603 RPC Server (Port 2001): Info: Client number 10039 is calling RPC method: getDeviceDescription Parameters:
(String) BidCoS-RF
03/03/15 13:16:30.607 RPC Server (Port 2001): Info: Connection to client number 10039 closed (3).
03/03/15 13:16:30.627 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58175 accepted. Client number: 10040
03/03/15 13:16:30.630 RPC Server (Port 2001): Info: Client number 10040 is calling RPC method: getAllValues Parameters:
(Boolean) 1
03/03/15 13:16:30.825 RPC Server (Port 2001): Info: Connection to client number 10040 closed (3).
03/03/15 13:16:31.234 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58176 accepted. Client number: 10041
03/03/15 13:16:31.237 RPC Server (Port 2001): Info: Client number 10041 is calling RPC method: getAllSystemVariables Parameters:
03/03/15 13:16:31.241 RPC Server (Port 2001): Info: Connection to client number 10041 closed (3).
03/03/15 13:16:31.249 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58177 accepted. Client number: 10042
03/03/15 13:16:31.251 RPC Server (Port 2001): Info: Client number 10042 is calling RPC method: init Parameters:
(String) binary://192.168.11.50:9123
(String) Homegear
03/03/15 13:16:31.254 RPC Server (Port 2001): Info: Connection to client number 10042 closed (3).
03/03/15 13:16:41.252 Info: Calling XML RPC method "system.listMethods" on server binary://192.168.11.50 and port 9123.
03/03/15 13:16:41.252 Info: Connecting to host 192.168.11.50 on port 9123...
03/03/15 13:16:41.254 Info: Connected to host 192.168.11.50 on port 9123. Client number is: 10043
03/03/15 13:17:31.276 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58179 accepted. Client number: 10044
03/03/15 13:17:31.279 RPC Server (Port 2001): Info: Client number 10044 is calling RPC method: init Parameters:
(String) binary://192.168.11.50:9123
03/03/15 13:17:31.283 RPC Server (Port 2001): Info: Connection to client number 10044 closed (3).
03/03/15 13:17:31.287 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58180 accepted. Client number: 10045
03/03/15 13:17:31.289 RPC Server (Port 2001): Info: Client number 10045 is calling RPC method: getAllValues Parameters:
(Boolean) 1
03/03/15 13:17:31.307 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58181 accepted. Client number: 10046
03/03/15 13:17:31.315 RPC Server (Port 2001): Info: Client number 10046 is calling RPC method: getDeviceDescription Parameters:
(String) BidCoS-RF
03/03/15 13:17:31.324 RPC Server (Port 2001): Info: Connection to client number 10046 closed (3).
03/03/15 13:17:31.333 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58182 accepted. Client number: 10047
03/03/15 13:17:31.337 RPC Server (Port 2001): Info: Client number 10047 is calling RPC method: getAllValues Parameters:
(Boolean) 1
03/03/15 13:17:31.580 RPC Server (Port 2001): Info: Connection to client number 10045 closed (3).
03/03/15 13:17:31.662 RPC Server (Port 2001): Info: Connection to client number 10047 closed (3).
03/03/15 13:17:32.071 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58183 accepted. Client number: 10048
03/03/15 13:17:32.072 RPC Server (Port 2001): Info: Client number 10048 is calling RPC method: getAllSystemVariables Parameters:
03/03/15 13:17:32.076 RPC Server (Port 2001): Info: Connection to client number 10048 closed (3).
03/03/15 13:17:32.086 RPC Server (Port 2001): Info: Connection from 192.168.11.50:58184 accepted. Client number: 10049
03/03/15 13:17:32.088 RPC Server (Port 2001): Info: Client number 10049 is calling RPC method: init Parameters:
(String) binary://192.168.11.50:9123
(String) Homegear
03/03/15 13:17:32.092 RPC Server (Port 2001): Info: Connection to client number 10049 closed (3).
03/03/15 13:17:42.089 Info: Calling XML RPC method "system.listMethods" on server binary://192.168.11.50 and port 9123.
03/03/15 13:17:42.090 Info: Connecting to host 192.168.11.50 on port 9123...
03/03/15 13:17:42.091 Info: Connected to host 192.168.11.50 on port 9123. Client number is: 10050

Ach ja und nochmal die Frage:
Kann ich eigentlich die Shared Libraries für nicht benötigte Module (z.B. Phillips Hue) entfernen? Ich brauche eigentlich nur die MAX-Library.

Schöne Grüße

Christian

[sathya]

Hey Christian,

Kann ich mit Homegear die Geräte direkt verbinden?

Na klar. Entweder über die RPC-Funktion addLink oder den HomeMatic-Manager. Mit dem HomeMatic-Konfigurator geht’s leider nur mit HomeMatic-Geräten.

Ist es eigentlich normal dass die Client-Server - Verbindung dauernd geschlossen und wieder neu aufgebaut wird?

Das ist zwar bescheuert aber normal. Ich hatte probiert die Verbindung zum Binding nicht zu trennen, das macht das Binding aber nicht mit (findest du hier irgendwo im Forum). In der OpenHAB2-Version des Bindings wird die Verbindung offen gehalten werden.

Kann ich eigentlich die Shared Libraries für nicht benötigte Module (z.B. Phillips Hue) entfernen? Ich brauche eigentlich nur die MAX-Library.

Ja, kannst du. Einfach die so-Datei in /var/lib/homegear/modules löschen.

Wenn du das Problem näher beschreiben kannst, schick mir das Log von dem Zeitpunkt, dann kann ich schauen, was los ist.

Liebe Grüße

Sathya

[homegear_user]

Hallo Sathya,

mit dem Homematic-Manager bekomme ich die Direktverknüpfung nicht hin.
Unter dem entsprechenden Menüpunkt kommt nur eine leere Liste.

Über die RPC-Konsole und mit dem Script tue ich mir auch schwer.
In der Doku steht:
Void addLink(Integer senderID, Integer senderChannel, Integer receiverID, Integer receiverChannel)
Ich will einen Wandthermostaten mit einem Heizkörper-Therm. verbinden.
Ist es egal in welcher Reihenfolge ich die zu verbindenden IDs übergebe? Wenn nicht: wer ist Sender - wer Empfänger?
Welche Channels muss ich für Sender- und Empfänger verwenden ?

Grüße

Christian

[sathya]

Hallo Christian,

Sendergerät ist der Wandthermostat. Senderkanal ist 1. Empfängerkanal am Stellantrieb ist 3. Das muss dringend auf die Wikiseite - ich dachte, das hätte ich da schon dokumentiert. Ob die Reihenfolge egal ist, bin ich mir gerade nicht mehr sicher (letztlich ist sie es nicht, aber es kann sein, dass ich eine falsche Reihenfolge automatisch korrigiere).

Komisch, dass es mit dem HomeMatic-Manager nicht geht, muss ich mir mal anschauen.

Liebe Grüße

Sathya

[homegear_user]

OK - vielen Dank. Diese Info ist doch ziemlich wichtig. Wo kann man die denn finden?

Ich habe jetzt versucht das Binding über die RPC-Konsole des Homematic-Managers zu machen.
Keine Ahnung ob es geklappt hat. Die Funktion gibt ja keine Rückmeldung (void) und die Liste unter “Direktverknüpfungen” bleibt leer
Wie kann ich testen ob es geklappt hat? Wahrscheinlich nur indem ich die Openhab-Rules vorübergehend deaktiviere und schaue ob die Stellantriebe auf Kommandos vom Thermostaten reagieren oder?

Eine Frage noch:
Ist es denn so dass ein System wie bei mir eigentlich problemlos funktionieren sollte oder gibt es viele User mit ähnlichen Problemen?

Grüße

Christian

[sathya]

Hallo Christian,

OK - vielen Dank. Diese Info ist doch ziemlich wichtig. Wo kann man die denn finden?

Die Info mit den Kanälen fehlt noch. Die muss ganz dringend rein! Alle Variablen und Parameter sind hier [1] dokumentiert.

Die Funktion gibt ja keine Rückmeldung (void)

Sie gibt aber einen Fehler zurück, falls es nicht geklappt hat. Wenn keine Fehlermeldung zurückgegeben wurde und keine “CONFIG_PENDING” Servicemeldung sichtbar ist, hat es geklappt. Du kannst dir die Direktverknüpfungen auch über die RPC-Funktion “getLinks” [2] anzeigen lassen.

Ist es denn so dass ein System wie bei mir eigentlich problemlos funktionieren sollte oder gibt es viele User mit ähnlichen Problemen?

Es sollte problemlos funktionieren. Ein guter Freund von mir nutzt in seinem ganzen Haus nur MAX!-Komponenten und das seit etwa einem halben Jahr ohne Probleme - allerdings nicht in Verbindung mit OpenHAB. Was genau geht denn nicht? Bedenke, dass die MAX!-Geräte selbst sich auch an das 1%-Limit halten müssen. Das heißt, ein Fensterkontakt kann maximal 36 Mal in der Stunde auf und wieder zu gemacht werden.

Liebe Grüße

Sathya

[1] https://www.homegear.eu/index.php/MAX!_Device_Reference
[2] https://www.homegear.eu/index.php/GetLinks

[homegear_user]

Hallo Sathya,

vielen Dank nochmal für die ganzen Infos.
Die RPC-API hatte ich mir schon angeschaut aber als Neuling blickt man da nicht so leicht durch.

Habe es jetzt mit getLinks im Homematic-Manager gecheckt und es sieht gut aus. Meine Update-Regel habe ich auch deaktiviert und die Heizkörper reagieren auch brav auf Änderungen der Solltemperatur am Thermostat. Einer hat allerdings erst mal “Config_Pending” angezeigt und nicht reagiert. Ich habe nicht wirklich rausfinden können wie man das weg bringt ?! Irgendwo auf Deinen Seiten steht man soll das Gerät nochmals in den Pairing Mode bringen aber das hat erst mal nichts geändert. Muss ich das Gerät aus Homegear entfernen und komplett neu pairen? Habe das erst mal nicht gemacht und heute morgen war das Config_Pending dann auf einmal verschwunden und der HK reagiert jetzt. Auch zeigt der Homematic-Manager jetzt die direkt verbundenen Geräte unter “Direktverknüpfungen” an was er gestern nicht tat (vermutlich weil einer der HK “Conig_Pending” war?).

Auch komisch: Es sind ab und zu einzelne Geräte unreachable obwohl die RSSI-Werte OK sind.

Was genau sollte man denn bei Config_Pending bzw. Unreach tun damit das wieder verschwindet? Abwarten scheint zu klappen aber das ist relativ unbefriedigend da man nicht weiß wie lange es dauert …

Grüße

Christian

[sathya]

Hallo Christian,

Einer hat allerdings erst mal “Config_Pending” angezeigt und nicht reagiert. Ich habe nicht wirklich rausfinden können wie man das weg bringt ?!

Das sollte verschwinden, wenn du irgendetwas am Gerät machst (z. B. die Temperatur verstellst). Es dauert dann manchmal ein kleines bisschen, bis das Gerät ein Paket versendet. Die Anlerntaste funktioniert bei MAX! nicht immer (ich bin mir gerade nicht einmal sicher, ob es überhaupt mit Anlerntaste funktioniert). Bei (älteren) HomeMatic-Geräten ist die Anlerntaste aber Mittel der Wahl .

Es sind ab und zu einzelne Geräte unreachable obwohl die RSSI-Werte OK sind.

Das UNREACH hat nicht unbedingt etwas mit den RSSI-Werten zu tun. Das tritt bei MAX! leider ziemlich schnell auf, weil die Sendezeiten für ein Paket so lang sind. UNREACH bekommst du ganz leicht bei Kollisionen, z. B. wenn du die Temperatur an zwei Wandthermostaten gleichzeitig setzt. Aber auch wenn Geräte gleichzeitig versuchen zu senden. Ich habe irgendwo im Hinterkopf, Pakete an mehrere Geräte automatisch nacheinander zu queuen. Das ist schon ein wichtiges Feature finde ich, aber eine ganze Menge Arbeit.

UNREACH verschwindet nach dem Empfang eines Pakets vom Gerät von alleine wieder.

Liebe Grüße

Sathya

[homegear_user]

Hallo Sathya,

sieht so aus als ob es jetzt so weit läuft und ich einigermaßen kapiert habe wie die Zusammenhänge sind.
Nochmals vielen Dank für Deine Hilfe. Das hat viel Licht ins Dunkel gebracht !!

Schöne Grüße,

Christian

[homegear_user]

Hallo Sathya,

nachdem jetzt alles mehrere Tage weitgehend problemlos funktioniert hatte habe ich gestern Abend festgestellt dass keine Reaktion mehr auf das Öffnen der Fenster erfolgt und heute morgen waren alle Heizkörper kalt. Die Überprüfung der Ursache heute morgen ergab, dass fast alle Komponenten unreachable waren (siehe Screenshot).

Ich habe dann ca. 1h gewartet und nochmal gecheckt => immer noch …
Also neu gebootet (gegen 8:35 falls da Änderungen im Logfile zu sehen sind) => alle Komponenten bis auf einen Wandthermostat sind jetzt wieder erreichbar. Ich nehme daher an dass es so weit wieder funktioniert bis auf den Thermostaten (Kann ich aber vom Büro aus gerade nicht checken).

Das Error Logfile ist vom 04.03. und von diesem Tag sind auch die letzten Einträge. Macht das Sinn??
Das Homegear Logfile enthält aktuelle Einträge aber ich sehe da nichts von den Problemen (siehe Anhang).

Hast Du eine Erklärung dafür oder - noch besser - eine Lösung??

Ich vermute dass der CUL “spinnt” oder wie sonst kann das auf einmal passieren?

Schöne Grüße,

Christian
homegear.log (647 KB)

[homegear_user]

Nachtrag:

Es sind schon wieder etliche Komponenten unreachable!
Der Reboot hats also wohl doch nicht getan. Muss wohl den Stecker ziehen …

Grüße

Christian

[sathya]

Hallo Christian,

da ist absolut keine Kommunikation im Log. Das spricht für irgendein Problem mit dem CUL. Beende mal Homegear und schau mal, ob du in Screen irgendetwas siehst (prüf auch, ob der CUL noch ttyACM0 ist)? Also:

screen /dev/ttyACM0 9600
Zr

Jetzt solltest du ankommende MAX!-Pakete sehen. Wichtig auch: Es darf kein anderes Programm auf ttyACM0 zugreifen.

Liebe Grüße

Sathya

[homegear_user]

Hallo Sathya,

vielen Dank mal wieder für Deine Hilfe!

Ich habe screen installiert und geschaut was ankommt. Das Terminal bleibt völlig schwarz => da kommt nix an.
Habe dann nochmal mit dem mir eher vertrauten minicom getestet und festgestellt, dass die Baudrate meines CUL 38.400 und nicht 9600 ist. Das muss aber homegear auch wissen denn sonst hätte es ja nie funktionieren können.
Bei Verbindung mit minicom und 38.400 baud wird auf Eingabe eines “V” brav die culfw - Version angezeigt (1.68 - von mir modifiziert hinsichtlich der 1%-Regel).
Dann nochmal mit screen und 38.400 versucht => bleibt immer noch alles schwarz.
Dann nochmal mit minicom und 38.400 versucht => Zr [Enter] => bleibt immer noch alles schwarz.

Also “hängt” der CUL oder die Frequenz wird “zugespammt” oder was meinst Du?
Ich werde heute Abend mal den Stecker ziehen und sehen was sich dann tut.

Schöne Grüße

Christian

[sathya]

Hallo Christian,

funktionieren sollte es mit allen validen Baudraten. Die bestimmst du. Es kann natürlich eine Weile dauern, bis du ein MAX!-Paket empfängt, aber wenn nach Betätigung z. B. eines Fensterkontaktes nichts sichtbar ist, stimmt definitiv irgendwas mit dem CUL nicht. Mal schauen, was das “Stecker ziehen” ergibt.

Liebe Grüße

Sathya