Gehäufte Kommunikationsprobleme mit HM-CC-RT-DN

Hallo Zusammen,

ich bin gerade von FHEM auf Homegear und Openhab umgestiegen und insgesamt super zufrieden. Es gibt nur einen Punkt der mich stört, bzw. den ich gerne verstehen möchte.
Ich sehe im homegear.err regelmäßig (pro Std. ca. 30 -50 mal) Kommunikationsprobleme in der folgenden Form:

04/21/15 19:57:40.783 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C70B011FD062928E146860409
04/21/15 19:57:42.651 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C70B011FD062928E146860409
04/21/15 19:57:45.301 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C17B011FD062928EE27860409
04/21/15 19:57:46.052 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C17B011FD062928EE27860409
04/21/15 19:57:46.438 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C78B011FD062928EF35860409
04/21/15 19:57:47.189 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C17B011FD062928EE27860409
04/21/15 19:57:48.330 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C70B011FD062928E146860409
04/21/15 19:57:48.709 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C70B011FD062928E146860409
04/21/15 19:57:49.081 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C78B011FD062928EF35860409
04/21/15 20:07:07.013 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "hmlan1": Info: No response to packet after 3 tries: 0C0AA011FD0629273B9C0201C8

Da die Homematic Software bei der Verbindung mit Homegear immer unter Servicemeldungen meine drei Heizkörperthermostate anzeigt (Gerätekommunikation war gestört oder Gerätekommunikation aktuell gestört ). Scheinbar ist die Kommunikation aber immer noch ausreichend für Steuerung.
Kann mir jemand sagen, wie ich mich dem Problem nähere? Hier noch die openhab Item Definition eines HKT’s:

Group gInnenEGWohnzimmerHKTLinks
	"Heizkörper Wohnzimmer links" 
	<heating> 
	(gEGWohnzimmer)
Number InnenEGWohnzimmerHKTLinksTargetTemp
	"Gewünschte Raumtemperatur [%.1f °C]" 
	<temperature> 
	(gInnenEGWohnzimmerHKTLinks,gWohnbereichTargetTemp)
	{homematic="address=XXX, channel=4, parameter=SET_TEMPERATURE, forceUpdate=true"}
Number InnenEGWohnzimmerHKTLinksCurrTemp
	"Aktuelle Raumtemperatur [%.1f °C]"
	<temperature>
	(gInnenEGWohnzimmerHKTLinks,gWohnbereichCurrTemp)
	{homematic="address=XXX, channel=4, parameter=ACTUAL_TEMPERATURE" }
String InnenEGWohnzimmerHKTLinksBattery
	"Batterie Status [MAP(battery.map):%s]"
	(gInnenEGWohnzimmerHKTLinks,gSysBatteryState)
	{homematic="address=XXX,channel=0,parameter=LOWBAT"}
Number InnenEGWohnzimmerHKTLinksRSSI
	"Feldstärke am Device [%d dbm]"
	(gInnenEGWohnzimmerHKTLinks)
	{homematic="address=XXX,channel=0,parameter=RSSI_DEVICE"}
Number InnenEGWohnzimmerHKTLinksValve
	"Ventilöffnung [%d]%"
	(gInnenEGWohnzimmerHKTLinks)
	{homematic="address=XXX,channel=4,parameter=VALVE_STATE"}
Number InnenEGWohnzimmerHKTLinksBatteryState

Ich würde mich sehr über HIlfe freuen und stelle bei Bedarf natürlich weitere Logs oder Infos zu Verfügung.
Danke und Grüße …

Hallo seppy,

schick mir mal die ganze homegear.log an meine E-Mail-Adresse (sathya@laufers.net). Dann kann ich dir hoffentlich mehr zu dem Problem sagen. Zumindest ist da definitiv etwas faul… Die Pakete im Error-Log sind Solltemperaturänderungs-Pakete. Die sollten nicht so oft hintereinander gesendet werden. Kann es sein, dass die Solltemperatur aus irgendeinem Grund mehrfach hintereinander gesetzt wird?

Liebe Grüße

Sathya

Hallo zusammen

Hatte diese Einträge in den letzten Tagen bei mir auch mal gesehen… scheint sich aber bei mir wieder gefangen zu haben. War aber auch ziemlich am rumbasteln zu der Zeit. Leider habe ich die Logs davon nicht mehr. Falls es nochmals auftaucht, melde ich mich.

Gruss
Thomas

N’Abend Zusammen,

ich schicke gleich das Log. Macht es Sinn das Loglevel noch zu erhöhen?

Mein System läuft komplett auf einem RasPI mit einem HMLan mit aktuell ca 15 Devices. Ich würde gerne schneller wachsen [emoji12]

Danke für die schnelle Hilfe

Sent from my iPhone using Tapatalk

Loglevel 4 ist erst einmal ausreichend :wink:.

LG Sathya

Hallo Sathya,

ich habe gerade zusätzlich noch einmal mit höherem Loglevel erstellte Logfiles an Dich per Email versandt.
Ich würde mich freuen von Dir zu hören.

Viele Grüße,
Sebastian

Hi Sathya,
hattest Du schon Chance in das Log zu schauen?
Viele Grüße,
Seppy

Sent from my iPhone using Tapatalk

Hey Seppy,

Jetzt ja, sorry für die späte Antwort…

Das Problem ist vermutlich, dass du die Werte aller Stellantriebe gleichzeitig setzt. Es gibt zwei Lösungsmöglichkeiten:

[ul]
[li] Eine Pause von etwa zwei Sekunden nach jedem Wertsetzen einbauen.[/li]
[li] Den Konfigurationsparameter BURST_RX auf “false” zu setzen.[/li][/ul]

Ich würde letzteres machen. BURST_RX bewirkt, dass die Geräte immer direkt ansprechbar sind. Das wird realisiert über sogenannte Wake-on-Radio-Pakete. Diese haben aber zwei Nachteile: Zum einen wachen immer ALLE Geräte auf, welche Wake-on-Radio unterstützen (also nicht nur das angesprochene). Bei vielen Geräten im Haus und vielen Wake-on-Radio-Paketen kann sich das gewaltig auf die Batterielebensdauer auswirken. Zum anderen braucht das Wake-on-Radio selbst pro Paket etwa 360ms Sendezeit. Bei maximal 36 Sekunden erlaubter Sendezeit pro Stunde ist das Sendelimit schnell erreicht.
Wenn BURST_RX ausgeschaltet ist, wartet Homegear auf ein Wake-me-up-Paket. Nach Empfang dieses Pakets werden dann die neuen Daten übertragen. Das Wake-me-up-Paket wird alle 2 bis 3 Minuten gesendet. Der Nachteil von ausgeschaltetem BURST_RX ist also, dass die Reaktionszeit des Stellantriebes 2 bis 3 Minuten beträgt.

Ich bin gespannt, ob’s mit einer der beiden Lösungen klappt!

Liebe Grüße

Sathya

Hi Sathya,

danke für das Feedback. Nur für mein Verständnis, das Abschalten von BURST_RX bewirkt also indirekt auch eine längere Lebensdauer der Batterien, richtig?
Ich habe den Parameter jetzt per PHP Script gesetzt, da dies ja scheinbar nicht über die Homematic Oberfläche geht.

print_r($Client->send("putParamset", array(8, 0, "MASTER", array(""BURST_RX"" => 0))));

Ist das so korrekt? Über die homegear cli kann ich solche Parameter nicht setzen, oder?

Aber mir gefällt homegear immer besser… :smiley:

Grüße,
Seppy

Hey seppy,

Genau.

Nein, leider nicht.

Vielleicht. Schreib lieber:

Ich hoffe, klappt :wink:! Ich bin gespannt auf dein Feedback…

Liebe Grüße

Sathya

Hi Sathya,

danke für das Feedback. Scheinbar hat mein putParamset nicht funktioniert, ich habe jetzt die drei HKTs noch einmal mit BURST_RX = false anstatt BURST_RX = 0 versorgt und werde das Ganze weiter beobachten.

Ich melde mich wieder. Danke und Grüße,

Seppy

Hallo Zusammen,

nach einigen Monaten, wollte ich nur ein kurzes Feedback zu der von mir geschilderten Problematik loswerden.

Es läuft! :mrgreen:

Soll heißen, der Tipp BURST_RX auf false zu setzen hatte den gewünschten Effekt!.

Danke und Grüße,
Seppy