Probleme mit Tür-/Fensterkontakt

Hi
Ich habe einige Fenstertürkontakte HM-Sec-SC-2 in Betrieb mit HomeMatic. Jetzt, da ich die „Logik“ nach IP-Symcon verschieben möchte, fällt mir auf, dass der Status des (aller) Kontakte (des Typs) nicht aktualisiert werden.

Auf HomeMatic’s CCU2 gehts wunderbar.

Irgendein Ansatz woran das liegen könnte ?

Besten Dank
Michael Lurie

Der/die benötigten Ports in der Firewall des IPS-Servers sind „offen“?

Alle anderen Geräte funktionieren einwandfrei. Oder brauchen die Türkontakte nen speziellen Port ?
Nicht wirklich, oder ?

Der Ereignisserver braucht einen.
Bei Aktoren fällt das nicht so schnell auf, wenn der Haken Status emulieren gesetzt ist.
Einfach mal kontrollieren, ob der Port wirklich offen ist.
Michael

Okay - welcher Port ?

Danke im voraus
Michael

Hattet Recht: 82, 2000,2001, 5544

Vielen Dank an alle
Michael

5544 reicht.
2000 & 2001 ist abgehend.
82 ist vermutlich dein Webfront, hat mit Homematic nix zu tun.
Michael

Sorry, für das „dahingeblööökte“ „Port offen“? War im Vorbeiflug und da die Frage schon gefühlte 300x kam … :wink:

Um es zu finalisieren, wie es Nall chan schon beschrieben hat, wird als Minimalkonfiguration für die Ereignisse von der CCU in Deinem Fall nur „TCP 5544“, eingehend mit der Source „IP Deiner CCU“ benötigt.

Cheers
/Jens

Komisch, funktioniert immer noch nicht - also für Dummies wie mich: Wenn ich ne Tür mit Kontakt öffne, dann müsste doch im State eine Änderung sichtbar sein.

Scheint aber doch am Port zu liegen… Kein einziger State wird korrekt angezeigt.

Also auf dem Rechner auf dem IP-Symcon läuft den Port 5544 TCP freigeben. Hab ich… und jetzt ?

Muss ich noch was auf dem Homematic machen ? XML-API ist vollzugriff und Version 1.1

Hab nochmals die Installationsanleitung für HomeMatic durchgearbeitet und kann keinen Fehler feststellen. Auch den Tip mit der Freigabe der Anwendung für die Firewall berücksichtigt.

Nochmals Danke im voraus
Michael Lurie

Xml-api ? Denn brauchst du nicht.
Meinst du XML-RPC-Api ? Der muss mindestens auf eingeschränkt und die IP bzw. Das Subnetz eingetragen haben. Vollzugriff geht auch, bin da aber eher auf der weniger ist sicherer Spur.
Der Ereignisport empfängt Events von der CCU. Also wenn du per Taster am Aktor schaltest oder eine Tür auf machst, kommt das darüber zu IPS.
ccu2.png

Der Debug der HM Socket Instanz zeigt das auch in IPS an, dort steht dann ganz vorne Event.


Michael

PS: Den XML-API Patch würde ich gar nicht mehr installieren :wink:

Immer noch alles tot…Hab die Firewall zu Testzwecken deaktiviert - erfolglos.
Was bei IPS im Debug ankommt wirkt auch nicht vertrauensfördernd… siehe Screenshot

Michael

Doch das ist ok. Es fehlen nur die Events…
(Das bin hatte ich rausgeschnitten)
Wie sehen denn die Einstellungen des HM-Socket passend zur HW aus ?
Welche CCU mit wired oder ohne ?
Michael

CCU2, Funk ohne Wired.

Konfiguration siehe Screenshot.

Danke im voraus
Michael

Wenn die 30er IP dein IPS ist, sollte das so korrekt sein.
Noch irgendeine eine andere ‚Internet-Schutz-SW‘ installiert, die vielleicht dazwischenhaut ?

Hier noch mal wie die Anmeldung von IPS an der CCU aussieht; wo IPS die Ziel-Adresse des Ereignisservers mitgibt; und die Antwort der CCU.

Kannst du nachstellen; wenn du zuerst das Debug aktivierst; dann in der Konfig den Haken bei ‚Socket öffnen‘ raus und wieder reinnimmst; anschließen auf Übernehmen klickst.
Dann sollte das so im Debug aussehen (bei mir ist die Anmeldung & Rückmeldung doppelt, da ich auch wired habe).

Du mußt um im Debug ein Event zu sehen natürlich auch eins erzeugen; also ein TFK mal auslösen.
Oder einfach mal einen Aktor per Hand (direkt angeschloßener/eingebauter Taster/Schalter) bedienen.
Wie schon gesagt liegt es zu 99% an der Firewall bzw. einer Sicherheits-Zusatz-SW.
Michael

Vielleicht mal neu starten und dann weitersehen.

Gruß
Bruno

Um wirklich sicher zu sein, dass der Port 5544 auch „hört“ bzw. verbunden ist, mal in einer CMD auf dem IPS-Server eingeben …

netstat -n -a | find "5544"

Der Output sollte dann so aussehen:

TCP    <IP_des_Servers>:5544    0.0.0.0:0           ABHÖREN
TCP    <IP_des_Servers>:5544    <IP_der_CCU>:53837  HERGESTELLT

Die 1. Zeile bedeutet: der Server lauscht auf dem Port 5544, die 2.: die Verbindung zwischen Server und CCU ist hergestellt. Statt „53837“ kann da natürlich irgendein High-Port stehen.
Wenn nichts kommt blockiert entweder immer noch eine „Sicherheitssoftware“ die Verbindung oder es ist etwas anderes in Deinem Netz faul.

Ich habe die Zeile mit „ABHOEREN“, aber die zweite Zeile fehlt…

Hilft das bei der Suche weiter ?

Danke
Michael

Yep! Jetzt wissen wir, dass der Server, sprich IPS, den Port „offen“ hält, also zu 99,9% funktionieren sollte.

Das Problem liegt also auf jeden Fall unterhalb der Applikation. Den „netstat“ so erweitern:

netstat -n -a [b]1[/b] | find "5544"

Die „1“ sorgt einfach nur dafür, dass der Befehl jede Sekunde ausgeführt wird, Du musst also nicht ständig selbst tippen.

Wenn Du nach einer der folgenden Aktionen Änderungen durchführst, mal den FK auslösen und schauen ob jetzt die 2. Zeile im „netstat“ auftaucht:

1 - die Firewall nochmals komplett für ALLE angezeigten Netzwerktypen deaktivieren (es sind mindestens zwei: „privat“ und „öffentlich“)
2 - AV und evtl. installierte Security Software deaktivieren (Avira, Symantec, McAfee… was auch immer da so laufen könnte)
3 - Netzwerkparameter checken: Wer ist der DHCP-Server? Gibt es mehrere? Stimmt die Subnetz-Maske? Stimmt das Default Gateway? Gibt es doppelte IPs im internen Netz? Evtl. einfach mal der CCU eine feste IP, Subnetz-Maske und Gateway verpasssen.
4 - Wie sind die Geräte vernetzt? Direkt an den Switchports eines Routers? Zusätzlicher Switch? PowerLine?

… was mir auf die Schnelle so einfiel ohne Deine Infra zu kennen :wink:

Vielen Dank an Euch alle, die sich bei der Lösung beteiligt haben.

Die Mischung Eures Inputs hat letztlich zur Lösung geführt: Firewall, Ports, Restart

Werd mich jetzt in die Programmierung einarbeiten. Also auf bald in einem anderen Subforum :wink:

Michael