ReGaHSS liefert keine Klarnamen und Infos

[Sandhase]

Hallo Sigi,
ja, beide Adapter sind grün.
Die Zeile aus dem Log resultiert aus verschiedenen Tests. So habe ich z.B. beim hm-rpc den Versuch mit bin-rpc anstatt xml-rpc probiert. Außerdem hab ich dann auch das eine oder andere Mal die Adapter angehalten und neu gestartet, um sicher zu sein, dass das nicht ggf. helfen könnte.
Da beide Adapter funktionieren, gehe ich auch nicht davon aus, dass die FW nicht die Ursache ist.
Sandhase

[sigi234]

@Sandhase
Wenn du keine Klarnamen hast stimmt die Verbindung nicht--------

[foxriver76]

Zeig am Besten mal ein Screen der Rega Adapter Einstellungen.

[debianatoe]

Je nach dem, auf welcher Ebene man die Klarnamen, Räume und Gewerke definiert hat, kann es sein, daß man den Baum noch weiter aufklappen muß, um sie zu sehen.
Bei mir ist es allerdings auch nicht ganz konsistent: für ältere Objekte sind alle Klarnamen, Räume und Gewerke in IObroker vorhanden. Bei neueren Objekten fehlen sie allerdings auch bei mir. Gibt es da vielleicht eine Refresh-Funktion, mit der sich alles neu einlesen läßt?

[Homoran]

@debianatoe sagte in ReGaHSS liefert keine Klarnamen und Infos:

Bei neueren Objekten

Neu auf der CCU angelegt?

-> entsprechende hm-rpc Konfiguration - Haken bei neu einlesen (einmalig) setzen und speichern
-> wenn dann immer noch nicht -> hm-rega neu starten

[debianatoe]

@Homoran sagte in ReGaHSS liefert keine Klarnamen und Infos:

@debianatoe sagte in ReGaHSS liefert keine Klarnamen und Infos:

Bei neueren Objekten

Neu auf der CCU angelegt?

Ja

-> entsprechende hm-rpc Konfiguration - Haken bei neu einlesen (einmalig) setzen und speichern

Danke, das hat geklappt.

[Sandhase]

So, bin wieder da und hab mal ein paar Screenshots erstellt.

rfd ist ist im regahss aktivert und im hm-rpc hab ich auch nochmal nen Versuch gemacht und das Häkchen für das "neu laden" gesetzt.
Leider kein Effekt. Ich hab aktuell keine Idee, woran das liegt.

[foxriver76]

@Sandhase laut Log sind da ja auch response Timeouts, zeig mal alle Seiten der Konfig am besten auch rpc, benutzt du auth zb musst du in der CCU die entsprechenden Ports freischalten.

[Sandhase]

Ich hab jetzt mal den Versuch gemacht und die Firewall der Synology komplett ausgeschaltet und danach hm-rpc neu suchen lassen. Das Ergebnis findet ihr im angehängten Screenshot aus dem Logfile (stoppen, starten, suchen, finden, verbinden.

wie man sieht im folgenden sieht, sind immer noch keine Klarnamen im iobroker:

Somit können wir die Firewall der Synology wohl als Fehlerquelle ausschließen.

Hier auch, wie gewünscht, die Screenshots vom ReGaHss:

Feuer frei für weitere Ansätze, bitte!

[Sandhase]

@Sandhase Keiner ne Idee???

[Homoran]

@Sandhase sagte in ReGaHSS liefert keine Klarnamen und Infos:

wie man sieht im folgenden sieht, sind immer noch keine Klarnamen im iobroker

du zeigst aber auch nicht den Kanal:1 in dem die Namen stünden.

Wo hast du sie denn in der CCU vergeben?
im Gerät oder in den Kanälen?

Wie sieht denn die Konfig des HM-RPC aus?

ist da die korrekte Callback-Adresse drin?

In den logausschnitten steht nix von hm-rega

[Sandhase]

@Homoran said in ReGaHSS liefert keine Klarnamen und Infos:

Callback-Adresse

Hallo Rainer,
vielleicht kommen wir der Sache jetzt näher, auch wenn ich es selber noch nicht lösen kann.
Hier die Namensvergabe in der CCU:

Hier das LOG-File von heute, in dem vielleicht der Zeitstempel 2019-04-19 10:30:29.656 interessant sein könnte:
iobroker log 190419.txt
Hier die Konfig des hm-rpc1:

Da scheint was mit den IP-Adressen bzw. den Ports nicht zu stimmen?!?
Vielleicht kannst Du mir auf Basis dieser Infos helfen
Danke,
Sandhase

[Homoran]

@Sandhase

2019-04-19 10:30:29.656 - error: hm-rega.0 post request error: connect ETIMEDOUT 192.168.178.76:8181
2019-04-19 10:30:29.656 - error: hm-rega.0 CCU 192.168.178.76 unreachable
2019-04-19 10:30:59.694 - info: hm-rega.0 ReGaHSS 192.168.178.76 up
2019-04-19 10:32:27.469 - info: host.ioBroker object change system.adapter.hm-rpc.1
2019-04-19 10:32:27.470 - info: host.ioBroker stopInstance system.adapter.hm-rpc.1
2019-04-19 10:32:28.470 - info: host.ioBroker stopInstance timeout "1000 

Wo ist der Screenshot der hm-rega konfig?

Was hast du für eine ccu?
Ist der port in der firewall freigegeben?

[Sandhase]

Meinst Du den der Haupteinstellungen?

Die zweite Seite zur Synchronisation ist oben schon drin?
Ich hab auch, wie oben schon mal geschrieben, die Firewall vom NAS ausgeschaltet, aber keinen Effekt erzielt.
Auf der CCU3 ist keine FW aktiviert.

[Homoran]

@Sandhase sagte in ReGaHSS liefert keine Klarnamen und Infos:

Auf der CCU3

Doch, ist standardmäßig
Bei ccu3 bin ich aber raus, die habe ich nicht.

[foxriver76]

@Sandhase zeig mal die fw Einstellungen der CCU, wie definierst du nicht aktiv?

[Sandhase]

@foxriver76
hier ein Screenshot der FW-Einstellungen, ich hab - zumindest für die Testphase alle Ports offen und der XML-RPC API Vollzugriff gegeben:

Sandhase

[foxriver76]

@Sandhase ja Rega ist die Remote Skript api auf die du kein Zugriff gewährst.

[Sandhase]

@foxriver76: danke für den Tipp, habs ausprobiert, aber sowohl mit als auch ohne die Freigabe sieht die Meldung für die regahss im iobroker so aus:

und in der hm-rpc beispielhaft so:

Also leider erst mal keine Verbesserung.

[Homoran]

@Sandhase
Hast du danach hmrpc nach anhaken des punkts Geräte neu einlesen neu gestartet und hmrega ebenfalls?