Allgemeine MQTT Frage

Dann müssten sie auch im MQTT ankommen…

Nimm dir mal sowas wie mqtt-spy oder mqtt.fx, connecte auf den Broker und abonier mal #. Schau dann mal ob meldungen kommen, wenn sich an den CCU-Geräten was ändert.
Denk dran, nicht jede “Aktion” wir direkt gesendet.

Hab ich gemacht. Kommt nichts.
Gibt es eine mqtt Log?

sugo homegear -r
dl 5

Setzt das Debuglevel im Laufenden Betrieb auf 5, damit siehst du jeden Publish von Homegear an MQTT im Log.

Was sagt dieser Eintrag aus?
06/27/19 15:57:32.574 IPC Server: Warning: RPC method not found: event

Im Log sind nun schon einmal folgende Zeilen drin:
06/28/19 11:13:56.695 Debug: MQTT packet received: D000
06/28/19 11:13:56.695 MQTT Client: Debug: Packet received: D000
06/28/19 11:13:56.695 MQTT Client: Debug: Received ping response.

Also es kommt nun nachdem ein neuen Datenpaket kam folgendes im Log

06/28/19 11:17:32.306 RPC Server (Port 2001): Info: Client number 17 is calling RPC method: system.multicall (2) Parameters:
(Array length=2)
[
(Struct length=2)
{
[methodName] (String) event
[params] (Array length=4)
[
(String) hm-rpc.0
(String) JPTH10I001:1
(String) TEMPERATURE
(Float) 24
]
}
(Struct length=2)
{
[methodName] (String) event
[params] (Array length=4)
[
(String) hm-rpc.0
(String) JPTH10I001:1
(String) HUMIDITY
(Integer) 35
]
}
]
06/28/19 11:17:32.306 IPC Server: Warning: RPC method not found: event
06/28/19 11:17:32.307 IPC Server: Warning: RPC method not found: event
06/28/19 11:17:32.307 RPC Server (Port 2001): Response:
(Array length=2)
[
(Struct length=2)
{
[faultCode] (Integer) -32601
[faultString] (String) Requested method not found.
}
(Struct length=2)
{
[faultCode] (Integer) -32601
[faultString] (String) Requested method not found.
}
]

Könnte dies an einer defekten Installation liegen? Habe ja nun schon einiges ausprobiert…

RPC hat nichts mit MQTT zu tun. Wenn du von io.Broker aus per MQTT verbindest, benötigst du RPC nicht: https://ref.homegear.eu/rpc.html

RPC heißt Remote Procedure Call und ist eine der Schnittstellen die homegear zur Verfügung stellt - hat aber eben in deinem Fall nichts mit MQTT zu tun. Ob jetzt dein io.Broker dazu irgendwie connected kann ich - da ich deine Installation nicht kenne - nicht sagen.
Irgendwas versucht da per RPC die Methode event aufzurufen, die es nicht gibt.

Was ich nicht verstehe ist, warum obwohl deine mqtt.conf offensichtlich richtig ist, keine Nachrichten per MQTT gepublished werden.

Was ein RPC ist, ist mir bewusst. Ich kenne den internen Aufbau nicht von Homegear. Hätte ja sein können, dass die interne Kommunikation per RPC gelöst ist. Also Homegear verbindet sich mit 2 Connections mit dem Broker. Das CCU Modul sendet auch per mqtt?
Hatte irgendwo gelesen, dass z.B. das HUE Mudel es noch nicht macht. Dann werde ich wieder io.Broker direkt mit der CCU verbinden. :frowning:

Mir ist kein Homegear-Modul bekannt was nicht auf MQTT landet, wenn es aktiviert ist. Ich betreibe Homematic, EnOcean, Hue und Max! über Homegear seit mehreren Jahren komplett per MQTT: https://allgeek.de/2017/07/09/homematic-mit-node-red-ueber-homegear/
Ich denke immer noch, dass du ein Konfigurationsproblem hast.

Was kann ich denn noch prüfen? An den nightly build kann es nicht liegen?
Der Versuch auf das stabile build zu gehen schlug fehl wegen irgendwelchen Abhängigkeiten.

Anhand der Seriennummer “JPTH…” gehe ich davon aus, dass dies eine Selbstbauversion eines HM-WDS40-TH-I wie unter https://github.com/jp112sdl/Beispiel_AskSinPP/blob/master/examples/HM-WDS40-TH-I-BME280/HM-WDS40-TH-I-BME280.ino zu finden ist.
Nur um mögliche Inkompatibilitäten aufgrund der nicht originalen Hardware auszuschließen: Hast Du vielleicht auch ein “echtes” Homematic Gerät, mit dem man testen könnte?
Grundsätzlich sollte auch diese Selbstbauversion funktionieren, da sie das Original nachbildet, aber man sollte bei Problemen erst mal alle möglichen weiteren Fehlerquellen auschließen.

Aktuell nur 2 Selbstbau Sensoren. Es wird ja noch nicht einmal eine Statusmeldung gesendet.
Im Broker ist nur zu sehen, dass 2 Verbindungen hergestellt werden.

Nimm testweise mal die Stable, nur um auszuschließen, dass sich in der nightly nicht doch irgendwas eingeschlichen hat.

apt remove homegear* libhomegear* evtl. apt purge...

Danach Quellen wie unter https://homegear.eu/downloads.html?version=0.7 beschrieben hinzufügen und installieren.

Die stable hatte ich ja schon versucht. Nach remove / neuinstallation kam beim Starten immer seg fault. Habe nun die neue nightly installiert und die Geräte / Gateway über die UI noch einmal entfernt. Dann wieder neu hinzugefügt und plötzlich kommen topics an. Ich kann da zwar noch nichts mit anfangen, aber mal sehen…

Leider hörte das “Publishing” dann aber sofort auch wieder auf. Es waren nur Statusmeldungen des Kern.
So in etwa
homegear/1234-5678-9abc/plain/1/-1/
Nachdem ich homegear noch einmal neugestartet habe, tut sich wieder nichts. Nun startet auch die UI nicht mehr. Irgendwie ist der Wurm drin. Es wird auch wieder eine core Datei im Log Verzeichnis erstellt.

Ich habe in den Logs einen Hinweis gefunden, dass Port 9000 durch das CCU Modul benutzt wird. Kann dies sein? Auf dem Port läuft aber auch schon der Javascript Adapter vom iobroker. Eventuell ist hier auch ein Problem vorhanden.

Dann solltest Du mal prüfen, ob es mit Homegear alleine läuft. Dafür musst Du dann vermutlich einen alternativen MQTT Broker aufsetzen. Oder wenn Dir das zu kompliziert ist, deaktivierst Du einfach mal den Javascript Adapter in IOBroker und schaust ob es läuft.
Ich persönlich würde die erste Variante wählen, da damit eine weitere potenzielle Fehlerquelle ausgeschaltet ist.

Ich habe nun den frei gewordenen RasPi genommen auf dem Homegear nach dem gleichen Schema installiert. Also nightly. Auf dem war noch Raspbian Jessie installiert. Hier scheint eine Datei (homegear-ui), welche der Installer herunterladen will, nicht zu existieren.
Aber auch hier kommen zwar nach der Konfiguration ein paar Status-Topics an, aber danach ist Still ruht der See.
Muss ich eigentlich noch Datenpunkte definieren?

Die Datenpunkte der Geräte sind in den device description files definiert. Was dort drin steht findest du hier: https://ref.homegear.eu/devices/

Denk dran, die Geräte senden so wenig wie möglich, da sie Energie (Batterien) sparen wollen und sich an die 1%-Regel halten müssen.
Wenn du einen Zustand an deinen Sensoren änderst sollten sie natürlich direkt senden.

Tja…
Was soll ich sagen, ich habe auf dem Raspi nun wieder das Nightly runtergeworfen und die Stable installiert und es funkt nun mqtt Werte…
Ist also in den nightly etwas faul?

Ich versuche nun den Zustand zu portieren. Nur der Rechner ist ein X64 und kein ARM.

Kann ich denn in der ccu.conf den Port-Range anpassen? auf z.B.
eventServerPortRange = 9100 - 9110

Ok. Nun läuft es tatsächlich auch dem richtigen Rechner. Ich trage mal die Unterschiede zusammen:

  1. Bei den Nightly-Installationen habe ich alles über die Admin UI eingestellt
  2. Die CCU wurde als CCU-AUTO Konfiguriert
  3. Build - Stand

[Nachtrag]
Ich habe nun auf dem RasPi das Nightly wieder installiert, aber die komplette Konfig aus dem Stable genommen und was soll ich sagen, mqtt funktioniert.

2 Likes

06/27/19 15:57:32.574 IPC Server: Warning: RPC method not found: event

Das ist komisch. Ich schaue am Dienstag mal, ob da tatsächlich im Nightly was faul ist.

Nachtrag: Ich hatte deinen Nachtrag nicht gesehen… :roll_eyes:. Taucht die Warnung noch auf?

Entschuldigt die verspätete Antwort. Das System MAX! und Homematic per CCU2 läuft nun ohne Fehlereinträge. Die Frage ist nur, was war an der Konfiguration faul. Oder geht dies per Admin Oberfläche noch nicht, bzw. hat das “Auto CCU” Modul einen Fehler?

Da war etwas in der CCU-Konfiguration schief, denn die CCU hat ihre Ereignisse an Port 2001 der Homegearinstallation gesendet. Das kann nicht funktionieren. Eine Möglichkeit ist zum Beispiel, dass in der ccu.conf die Einstellung eventServerPortRange auf 2001 - ... gesetzt war.

Viele Grüße

Sathya