Konfigurationsproblem ioBroker auf RPi mit CCU2 mit HM- und FS20-Aktoren?
-
Hallo Werner und Willkommen im Forum.
Hast du auch noch den hm-rega Adapter installiert und konfiguriert?
Bitte Screenshots davon und vom rpc.1
Mit dem alten RasPi1 wirst du sehr bald an die Grenzen kommen.
Gruß
Rainer
-
Hallo Rainer,
mit dem RasPi1 hast du sicherlich Recht - sollte auch nur ein erster Test werden und ich hatte das Ding da ungenutzt rumliegen. Hälst du den RasPi3 für ausreichend?
Ich nehme an, du meinst den HM ReGaHSS-Adapter der dann die Instanz hm-rega.0 ergibt, oder gibt es da noch was anderes? Ich habe mal die Screenshots angehängt. Mir ist noch aufgefallen, dass der hm-rpc.1 sich regelmäßig disconnected und dann wieder connected. Ist das normal? Ich hänge auch mal einen log-Auszug dran.
Danke und Gruß, Werner
1617_hm-rega0.jpg
1617_hm-rpc1.jpg
1617_log.jpg
1617_iobroker-instanzen.jpg -
Hallo Werner,
kannst du die Bilder bitte als jpg oder png direkt hier einbinden?
Ist besonders unterwegs blöd immer alles vorher runterladen zu müssen.
@kwb:Mir ist noch aufgefallen, dass der hm-rpc.1 sich regelmäßig disconnected und dann wieder connected. Ist das normal? `
nein das ist nicht normal, deswegen funktioniert auch das schalten von cuxD-Geräten nicht.Auf die Schnelle finde ich keine Ursache für das Problem
lediglich die 56MB freies RAM könnten ein Problem darstellen, dass der rpc.1 mehr benötigt.
da bleiben nur die üblichen dummen Ratschläge wie neustarten des ioBroker oder reboot des RasPi
Gruß
Rainer
PS Wenn du den HMM nicht unbedingt benötigst würde ich den komplett rauswerfen - bringt vielleicht etwas mehr RAM
-
Hallo Rainer,
danke für deine Mühe. Die pdf's habe ich gelöscht und durch jpg-Dateien ersetzt.
Die HMM einzubinden war nur eine Verzweifelungstat. Das Problem bestand auch vorher. Ich werfe sie aber trotzdem wieder raus.
Vielleicht sollte ich auch noch ein paar von den VIS-Modulen rausschmeißen.
Werner
PS: Beim löschen von HMM habe ich wieder eine Fehlermeldung bekommen, die ich sporadisch auch bei der Installation bekommen hatte. Gibt die eventuell einen Hinweis?
Nachtrag: Nach Aktualisierung war das Löschen dann problemlos möglich.
1617_fehlermeldung.jpg -
Was zeigt die CUxD Statusseite oben an (verbunden / angefordert) ?
Evtl. mal CUxD neu starten.
-
Ich bin etwas verwirrt - hatte da noch nie reingeschaut.
"Erfolgreich mit HomeMatic-CCU 127.0.0.1:8181 verbunden!". Hier irritiert mich die IP-Adresse.
HM-SCRIPTHOST und RPCHOST haben die IP-Adr. '127.0.0.1'. Ist das korrekt?
als RPC-Server(INIT) von 192.168.2.115:8701 (hm-rpc.1) angefordert!
als RPC-Server(INIT) von HomeMatic-CCU (1900) angefordert!
Müssten diese beiden Zeilen auf verbunden statt auf angefordert stehen?
1617_cuxd-status.jpg -
@kwb:"Erfolgreich mit HomeMatic-CCU 127.0.0.1:8181 verbunden!". Hier irritiert mich die IP-Adresse. `
Das ist in Ordnung. Es handelt sich um die Verbindung zur ReGa der CCU.
@kwb:als RPC-Server(INIT) von 192.168.2.115:8701 (hm-rpc.1) angefordert! `
Das ist die INIT-Anforderung des hm-rpc.1.Meiner Meinung nach müsste noch ein "Erfolgreich mit hm-rpc.1 192.168.2.115 verbunden!" oder so ähnlich erscheinen.
CUxD Restart versucht ?
-
Meiner Meinung nach müsste noch ein "Erfolgreich mit hm-rpc.1 192.168.2.115 verbunden!" oder so ähnlich erscheinen. `
Das ist auch meine Meinung (gewesen).Habe gerade bei mir nachgesehen, da sieht es aber ähnlich aus.
Habe aber keine "aktiven" CuxD-Geräte, nur exec und Timer.
Gruß
Rainer
-
Wenn das alles soweit ok zu sein scheint, stellt sich mir die Frage, ob es irgend eine Möglichkeit gibt, wenigstens einen Teil der Übertragungskette auszuschließen.
Wenn ich das richtig verstehe, greift der RasPi mit der ioBroker-Software auf die CCU2 zu und bezieht von dort alle Status-Daten bzw. übergibt dorthin alle Änderungen. Die CCU2 ihrerseits holt diese über den CUxDaemon von der FHT2000 und ihren FS20-Geräten. Wenn das so korrekt ist, kann man m.E. diesen Teil der Hard- und Software als Fehlerursache ausschließen weil ich z.B. mit der "mobil control CL"-App von Contronics über den gleichen Weg auf alle HM, FS20 und FHT80B Geräte zugreifen und diese steuern kann. Dass der Status alle HM-Geräte problemlos erkannt und auch manipuliert werden kann deutet m.E darauf hin, dass in der Hardware des RasPi wohl auch nicht Quelle des Übels zu suchen ist.
Um die Problematik weiter einzukreisen habe ich versucht, das STATE-Objekt eines HM-Gerätes unter hm-rpc.0 und das eines FS20-Gerätes unter hm-RPC.1 manuell zu ändern und die Änderung zu bestätigen. Ergebnis: der HM-Schaltaktor reagiert korrekt, der FS20-Schaltaktor läßt zwar die Änderung seines Status zu, allerdings reagiert die Hardware darauf in keiner Weise. Auch eine externe Statusänderung wird von dem rfd-Daemon erkannt während der CUxD-Daemon davon allem Anschein nach nichts mitbekommt. Gleiches zeigt sich auch in der ioBroker-Ergebnisliste - den Eintrag einer Statusänderung des FS20-Aktors sucht man vergeblich.
Falls jemandem noch etwas einfällt womit wir dem Übeltäter auf die Schliche kommen könnten, wäre ich sehr dankbar.
Mit besten Grüßen und vor allem herzlichen Dank an alle, die sich bisher bemüht haben mir weiterzuhelfen.
Werner
-
Nachdem eine Neuinstallation auf einem zweiten RasPi exakt das gleiche Ergebnis gebracht hat, habe ich versucht etwas detailierter in das Zusammenspiel zwischen CCU2 und FHZ2000 zu schauen. Dabei ist mir aufgefallen, dass dabei offensichtlich ein anderer Kommunikationspfad verwendet wird als über CUxD. Ich hatte zwar CUxD installiert, alle Geräte waren dort zwar gelistet aber nicht korrekt konfiguriert.
Ich werde jetzt versuchen, durch den Einsatz eines CUL an der CCU2 alle FS20/FHT80B-Geräte auf die FHZ2000 gänzlich zu verzichten und dann noch mal einen neuen Anlauf mit ioBroker zu machen.
Nachtrag:
Na ja, schön wäre es gewesen. Leider scheint es keine Kommunikationsmöglichkeit zwischen Homeputer CL und CUxD zu geben, außer über Systemvariablen. Diese Möglichkeit schließt sich aber leider aufgrund der Menge an Geräten und Macros aus. Falls jemand noch eine Alternative kennen sollte, wäre ich sehr interessiert.
