Statusänderung von Türkontakt kommt bei IPS nicht an nach längerer Ruhephase

Hallo zusammen,

ich bin noch neu in der Thematik. Habe seit etwa einer Woche ein HomeMatic LAN-Adapter in Betrieb und habe diesen über den BidCos Service mit dem IP-Symcon verbunden. Beides (IPS und BidCos) laufen auf dem selben Windows 2008R2 Server. Als Geräte habe ich momentan einen Türkontakt und einen Rauchmelder angelernt.

Ich konnte beide Geräte im IPS „anlernen“ und sehe auch die Variablen dazu.

Jetzt habe ich aber das Problem, dass der Türkontaktschalter nach längerer Ruhephase (es reichen schon etwa 10 Minuten) seine Meldung nicht an das IPS absetzen kann. Man sieht am Schalter direkt, dass die LED erst orange und dann kurz grün leuchtet. Die Meldung wurde also vom LAN-Adapter bestätigt. Im IPS bleibt die Variable unverändert. Wird daraufhin direkt die Tür wieder geschlossen, wird eine Aktualisierung der Variable angezeigt (mit neuem Datum/Uhrzeit) und dem Status „Tür geschlossen“ vorgenommen.

Im BidCos Log finde ich folgende Fehlermeldung:

04.10.2012 13:20:26 <Error> XmlRpcClient error calling event({[methodName:"event",params:{"IPS","JEQxxxxxxx:1","STATE",true}]}) on http://xxx.xxx.xxx.xxx:5544/RPC2:
04.10.2012 13:20:26 <Error> XmlRpc transport error

Die IP-Adresse entspricht der IP des BidCos/IPS Servers.

Ich habe nach dieser Fehlermeldung gesucht und auch ein paar Infos gefunden. Leider waren diese jedoch alle mit anderen Auswirkungen verbunden als bei mir.

Habt ihr eine Idee oder einen Tipp für mich, was ich noch überprüfen könnte?

Weitere Infos:

  • IPS V2.60
  • BidCos V1.506
  • Türkontakt FW2.0
  • Firewall ausgeschaltet + Portfreigabe für 5544 trotzdem vorher schon erstellt
  • LAN-Adapter und Server sind im gleichen IP-Subnetz und können direkt kommunizieren
  • Wenn wenig Zeit zwischen den Statusänderungen liegt, funktioniert auch alles Problemlos ohne die Meldungen. Es scheint so, als wenn IPS eingeschlafen wäre und die Statusänderung nicht annehmen könnte. Und erst bei der zweiten Änderung wieder aktiv wird.

Gruß Phil

Kommt die Statusmeldung denn im HM Konfigurator(Software) an.

Wo kann ich die Statusänderung denn in der Webconfig Oberfläche sehen?

Das ist eine gute und berechtigte Frage. :smiley:

Ich hab keinen Türkontakt nur Fensterkontakte. Diese werden aber anscheinend nur in der CCU angezeigt. Beim Lanadapter sind es nur die Geräte ohne Stati. :confused:

Die Kommunikation, läuft auch ganz sicher auf „Entfernter Bidcos-Service“.

Eine Anzeige gibt es über den LAN-Adapter nicht, egal, welches Gerät. :cool:

Scheint mir auch kein Problem von IPS zu sein, sondern hängt mit dem BidCos-Service zusammen. Vielleicht mal Bilder einstellen.
Einstellungen siehe HomeMatic — IP-Symcon :: Automatisierungssoftware ab Optional (bitte nicht die alte Software nehmen :D)

Gruß
Bruno

Habe fast die selbe Konfiguration ( nur halt windows xp ) und bei mir funktioniert das problemlos mit dem türkontakt .

Gruß Jens

Hallo zusammen,

danke schon mal für eure schnelle Reaktion.

Da bin ich beruhigt, dass ich nicht zu blöd war um den Status im LAN-Adapter zu finden :slight_smile:

Anbei sende ich euch die gewünschten Screenshots. Das Problem tritt immer nur auf, wenn längere Zeit (etwa 20Minuten) keine Aktion aufgetreten ist. In kurzen Abständen, funktioniert alles wie gewünscht.

Noch als Info vorab die IP-Adressen:

  • LAN-Adapter = 192.168.0.31
  • IPS Server / BidCos Svc = 192.168.0.30

service.JPG

TestBidCos.JPG

hm-socket.JPG

tuerkontakt.JPG

Was mir noch aufgefallen ist - im WebConfig gibt es einen Haken „Zyklische Statusmeldungen“. Das hat aber scheinbar auch keine Auswirkungen. Ich habe bisher keine regelmäßigen Statusrückmeldungen gefunden. Hat das beim Türkontakt keine Auswirkungen?

Hier noch das Logfile mit dem genauen Ablauf von öffnen und schließen:
log.txt (2.14 KB)

Ich habe die Seriennummern, etc. unkenntlich gemacht. Falls ihr dazu noch Infos braucht, bitte kurz melden.

Gruß Phil

Was steht dort bei dir (Bild 1), das war meine Frage mit Bidcos-Service.

Dort steht bei mir „BidCos Service“ und als IP habe ich dann den Server (192.168.0.30) angegeben mit dem Port 2001. Und dann bekomme ich Zugriff auf die Verwaltung.

Ich hatte aber direkt nach dem Auspacken erstmal normal auf das Gerät zugegriffen und auch den Türkontakt verbunden. Aber das dürfte ja kein Problem sein, oder? Ich hatte den Türkontakt dann zurückgesetzt und nochmal neu angelernt über den BidCos Service.

Hier noch die Config aus der BidCos.conf


# TCP Port for XmlRpc connections
Listen Port = 2001

# Log Level: 1=DEBUG, 2=WARNING, 3=INFO, 4=NOTICE, 5=WARNING, 6=ERROR
Log Level = 1

# If set to 1 the AES keys are stored in a file. Highly recommended.
Persist Keys = 1

Device Description Dir = ${Bindir}\devicetypes
Device Files Dir = ${CommonAppData}\Bidcos-Service\devices
Key File = ${CommonAppData}\Bidcos-Service\keys
Address File = ${CommonAppData}\Bidcos-Service\ids

Log Destination = File
Log Filename = ${CommonAppData}\Bidcos-Service\log\bidcos-%Y-%m-%d.log

[Interface 0]
Type = Lan Interface
Serial Number = IEQ02xxxxx
# The encryption key is found on a sticker on the lan interface
Encryption Key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Description = First Lan Interface

# IP Addess is optional. If not specified, the Lan Interface is 
# detected by its serial number.
# You may have to use the IP address if your lan interface is behind a
# router or a firewall.

#IP Address = 192.168.0.31

#[Interface 1]
#Type = Lan Interface
#Serial Number = IEQxxxxxxx
#Description = Second Lan Interface
#IP Address = 192.168.1.189

IP-Adresse habe ich weggelassen, da der BidCos den LAN-Adapter ja selbst findet.

Gib die IP-Adresse in der Config noch mit an. Damit hast Du wesentlich weniger Probleme. :wink:

Nach Übernahme, musst Du den Bidcos Neu starten.

Okay habe ich abgeändert. Ich beobachte ob sich dadurch was ändert - ich vermute mal aber nicht, da mir das BidCos Log die Statusänderung ja anzeigt und die RPC Meldung nicht loswird an den IPS.

Aber warten wirs ab :slight_smile:

Das Problem besteht leider auch mit eingetragener IP-Adresse in der bidcos.conf weiterhin.

Aber ich habe noch was herausgefunden. Nach dem Dienst-Neustart hat es einmalig richtig funktioniert. Danach geht es allerdings nicht mehr.

17:23:00 Uhr - Dienst neugestartet
17:57:20 Uhr - Tür geöffnet => Status wurde korrekt an IPS gemeldet (kein Fehler im Log)
17:57:48 Uhr - Tür geschlossen => Status korrekt gemeldet
18:16:25 Uhr - Tür geöffnet => Status NICHT gemeldet (Fehler im Log!)
18:16:52 Uhr - Tür geschlossen => Status korrekt gemeldet

Hat noch jemand eine Idee wo man ansetzen könnte?

Bringt es etwas, wenn ich alle Komponenten auf Auslieferungszustand zurücksetze?

Gruß Phil

Denke nicht, daß das was bringt. Kannst Du aber probieren.

Bild 5: Mach mal den Haken bei „Status emulieren“ raus.

Gruß
Bruno

Hallo,
genau die Probleme hatte ich mit meinen neuen Fensterkontakten auch. Sie blinkten kurz grün, aber in IPS kam nichts an - dafür war im BidCos-Log ein „XmlRpcClient error calling event…“ Eintrag.

Irgendwo wurde dann erwähnt, dass dies vermehrt mit der 1.506 Version auftritt. Ich habe dann den BidCos-Service und den Homematic-Konfigurator deinstalliert und dafür die alte 1.504 aufgespielt. Seit dem funktionieren die Sensoren wie sie sollen.

Allerdings hatte ich danach viele Disconnect/Reconnect-Meldungen. Am zweiten Tag war es dann noch eine einzige, und danach war ruhe. Keine Ahnung ob das ein einmaliger Verschlucker war (habe zudem zur Empfangsverbesserung den Adapter an ein anderen Switch gehängt), oder ob dies nun demnächst bei jedem neustart des BidCos-Service auftreten wird.

Bye,
Norman

Haken rausnehmen bei „Status emulieren“ hat nichts gebracht.

Ich werde jetzt mal die V1.504 verwenden und testen ob das etwas bringt.

@JensNRW: du hast geschrieben, du hättest bis auf Windows XP die selbe Konfiguration. Was hast du für eine Version des BidCos Service? Auch die V1.506?

Gruß Phil

Gibt’s denn die V1.504 noch irgendwo als Download? Ich dachte ich würde die bei EQ-3 noch finden. Aber da gibt’s nur noch Change Logs und die Version für die CCU. Ich brauche aber die Version für den LAN-Adapter oder kann man auch teile der CCU Software verwenden?

Gruß Phil

Umgebung: Win7 (64Bit), Netbook, nur BidCos-Funksensoren/Aktoren, HomeMatic Firmware 1.506, IP-Symcon 2.5

Hallo,

ich betreibe seit einigen Monaten meine Umgebung mit dem USB-Konfigurationsadapter (Neuer Form als USB-Stick).
Am 18.11.2012 traten gehäuft Fehlermeldungen auf, ich meine aber, keine Änderungen zu der Zeit am System vorgenommen zu haben (keine Updates, keine neuen HomeMatic-Komponenten etc.).
Es handelt sich um folgende Fehlermeldungen, die mit unterschiedlichen Sensoren auftreten:

Siehe BidCos-Logfile zum USB-Adapter:
24.11.2012 03:39:56 <Debug> Event: JEQ0009xxx:1.STATE=true
24.11.2012 03:39:56 <Debug> HSSXmlRpcEventDispatcher::Handle send 1 events
24.11.2012 03:39:56 <Error> XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„JEQ0009xxx:1“,„STATE“,true}]}) on http://192.168.178.26:5544/RPC2:
24.11.2012 03:39:56 <Error> XmlRpc transport error
24.11.2012 03:40:04 <Debug> RX for JEQ0009xxx: @810105862 AES(0) RSSI=-63dB 0x190C26 -> 0x13978E CONDITIONAL_SWITCH [JEQ012xxxx]:
CNT=120,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x41
COUNTER = 119
CHANNEL = 1
LOWBAT = 0
DURATION = 0
CONDITION = 0
TIMES = 0

Ursache und Workaround:
Werden länger als zwei Minuten keine BidCos-Funksignale empfangen, so schläft „Etwas“ ein, d.h. ein dann folgendes Funksignal wird im BidCos-File angezeigt, kann aber nicht an IPS weitergereicht werden. Erst ein kurz darauf folgendes Signal wird korrekt verarbeitet.
Damit „Etwas“ nicht einschläft, kann man eine BidCos-Kommunikation erzwingen, in dem man z.B. Mit dem Befehl „HM_RequestStatus“ die schaltbaren Steckdosen abfragt. (Geht nicht mit Batteriebetriebenen Komponenten!). Und dies in einem Abstand von weniger als zwei Minuten, z.B. alle 110 Sekunden, damit gehts bei mir.

Beispiel ohne Workaround:
Hier ein Test, wo jeweils drei Minuten lang kein Funkverkehr erzeugt wurde, nach der kurzen Funkpause habe ich jeweils einmal die Tür auf- und wieder zu gemacht.
Das Öffnen der Tür (erstes Signale nach der Funkpause) wurde empfangen, aber nicht korrekt an IPS weiter gegeben, das Schliessen der Tür wurde immer korrekt verarbeitet.

02.12.2012 14:55:02 <Debug> Event: JEQ0009xxx:1.STATE=true
02.12.2012 14:55:02 <Debug> HSSXmlRpcEventDispatcher::Handle send 1 events
02.12.2012 14:55:02 <Error> XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„JEQ0009xxx:1“,„STATE“,true}]}) on http://192.168.178.26:5544/RPC2:
02.12.2012 14:55:02 <Error> XmlRpc transport error
02.12.2012 14:55:04 <Debug> RX for JEQ0009xxx: @1541806121 AES(0) RSSI=-88dB 0x190C26 -> 0x13978E CONDITIONAL_SWITCH [JEQ012xxxx]:
CNT=29,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x41
COUNTER = 28
CHANNEL = 1
LOWBAT = 0
DURATION = 0
CONDITION = 0
TIMES = 0

02.12.2012 14:55:04 <Debug> Event: JEQ0009xxx:1.STATE=false
02.12.2012 14:55:04 <Debug> HSSXmlRpcEventDispatcher::Handle send 1 events
02.12.2012 14:58:02 <Debug> RX for JEQ0009xxx: @1541983890 AES(0) RSSI=-86dB 0x190C26 -> 0x13978E CONDITIONAL_SWITCH [JEQ012xxxx]:
CNT=30,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x41
COUNTER = 29
CHANNEL = 1
LOWBAT = 0
DURATION = 0
CONDITION = 200
TIMES = 0

02.12.2012 14:58:02 <Debug> Event: JEQ0009xxx:1.STATE=true
02.12.2012 14:58:02 <Debug> HSSXmlRpcEventDispatcher::Handle send 1 events
02.12.2012 14:58:02 <Error> XmlRpcClient error calling event({[methodName:„event“,params:{„IPS“,„JEQ0009xxx:1“,„STATE“,true}]}) on http://192.168.178.26:5544/RPC2:
02.12.2012 14:58:02 <Error> XmlRpc transport error
02.12.2012 14:58:05 <Debug> RX for JEQ0009xxx: @1541987141 AES(0) RSSI=-87dB 0x190C26 -> 0x13978E CONDITIONAL_SWITCH [JEQ012xxxx]:
CNT=31,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x41
COUNTER = 30
CHANNEL = 1
LOWBAT = 0
DURATION = 0
CONDITION = 0
TIMES = 0

02.12.2012 14:58:05 <Debug> Event: JEQ0009xxx:1.STATE=false
02.12.2012 14:58:05 <Debug> HSSXmlRpcEventDispatcher::Handle send 1 events
02.12.2012 15:01:02 <Debug> RX for JEQ0009xxx: @1542163400 AES(0) RSSI=-84dB 0x190C26 -> 0x13978E CONDITIONAL_SWITCH [JEQ012xxxx]:
CNT=32,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x41
COUNTER = 31
CHANNEL = 1
LOWBAT = 0
DURATION = 0
CONDITION = 200
TIMES = 0

Ich habe mich zwei Wochen damit beschäftigt und alles Mögliche an Umkonfigurationen, Ab- und Anlernen von Komponenten, Batteriewechsel etc. ausprobiert, konnte dem Problem aber nicht endgültig den Garaus machen.
Mit dem Workaround sind diese Fehlermeldungen nun bei mir verschwunden, ich hoffe dass dies bei Euch auch der Fall ist, wenn Ihr meinen Tipp umsetzen könnt. Vielleicht habt Ihr dazu ja noch eine einfachere Lösung.
Es wäre aber noch schöner, wenn ein evtl. folgendes Update diese Probleme beheben könnte.

Mit freundlichen Grüßen
Acki