Schaltaktoren

Guten Tag,

am vorletzten Samstag habe ich den Aufputz-Schaltaktor 1-fach in meiner Garage installiert und an meine CCU2 angelernt.
Dies hat einwandfrei funktioniert.

Ziel ist es, über das Smartphone per App das Garagentor zu bedienen. Das habe ich soweit auch hinbekommen. Anfangs wurden die Befehle auch relativ präzise ausgeführt.
Hin und wieder hatte ich die Servicemeldung zum betreffenden Aktor:"Gerätekommunikation war gestört". Die Meldung konnte ich problemlos bestätigen.

Seit Freitag bekomme ich jedoch die Meldung "Gerätekommunikation gestört", die ich nicht wegklicken kann. Vermutlich weil wohl das Problem nach wie vor besteht. Gestern Abend habe ich den Aktor von der CCU2 abgelernt, zurückgesetzt und für einen Moment vom Strom getrennt. Danach konnte ich den Aktor auf Anhieb wieder erfolgreich anlernen. (CCU2 hatte ich zwischenzeitlich X-Mal neugestartet.) - Die Bedienung hatte ich dann ca. zwei Mal per WebUI getestet. Hat funktioniert. Später wollte ich die Funktionn per App durchführen. Dann ging es wieder mit den Servicemeldungen los... seitdem habe ich wieder permanent die Meldung "Gerätekommunikation gestört".

Ich verstehe das nicht, das Anlernen hat immer gut geklappt und auch die Befehle an sich. Erst seit dem Wochenende ist es so extrem.

Ich bin ratlos. Habt ihr Erfahrungen mit dieser Problematik?
Oder eine Lösung...?

Über eure Antworten würde ich mich sehr freuen.

Viele Grüße
Rouven

Guten Morgen,

gestern Abend habe ich nochmal rumprobiert.

Habe den Schalt-Aktor nochmal neu an die CCU2 angelernt.
Hat wunderbar funktioniert. Auch der Gerätetest in der WebUI (grüne Bestätigung mit entsprechender Uhrzeit) hat geklappt.

Sobald ich jedoch über die App am Smartphone den Schalter betätige bekomme ich wieder die Servicemeldung "Gerätekommunikation ist gestört" und die Meldung "...war gestört". Nur diese Meldung lässt sich bestätigen.
Die "ist gestört"-Meldung bekomme ich komischerweise erst weg, wenn ich über die Geräte-Einstellungen in der WebUI den Geräte-Test durchführe. Das ist merkwürdig...(?)

Könnte mein Problem ggf. an meiner Wenn-Dann...Programmierung im Zusammenhang mit den Mindestverzögerungszeiten der Statusmeldungen 0-15,5 s, aktuell 6s/ Verzögerungszeit 0-7 s, aktuell 1 s. liegen?
Sendeversuche habe ich von 6 auf 10 gesetzt

Das Programm:
Bedingung Wenn:
Torantrieb:1 - bei Schaltzustand ein - bei Änderung auslösen
Aktivität Dann:
Torantrieb:1 - verzögert um 1 Sekunde - Schaltzustand aus

Hat evtl. jemand eine Idee...einen Hinweis?

Viele Grüße
Rouven

Hallo Rouven1982,

die Programmierung ist in diesem Fall nicht optimal. Sie sollten folgendes Programm erstellen:

Wenn...
Gerät - virtuelle Taste 1 der CCU - bei Tastendruck kurz
Dann..
Gerät - Aktor - sofort - Einschaltdauer 1 Sekunde
Gerät - Aktor - sofort - Schaltzustand Ein

Im WebUI/App bedienen Sie dann die virtuelle Taste 1 der CCU und nicht direkt den Aktor.

Hallo Herr Sandhorst,

muss ich dann noch irgendwelche Verknüpfungen erstellen oder reicht es völlig aus, das von Ihnen genannte Programm zu erstellen?

Viele Grüße
Rouven

Hallo Rouven1982,

das u.g. Programm ist für die gewünschte Funktion ausreichend.

Hallo Herr Sandhorst,

ich denke, dass die Fehlermeldung tatsächlich auch aufgrund der Funkverbindung zustande kam. Am Freitagabend habe ich für die CCU2 einen anderen Standort ausgewählt.
Zusätzlich habe ich mir mal ein Tool heruntergeladen, mit dem man sich scheinbar die Funkdaten zu den einzelnen angebundenen Geräten anzeigen lassen kann.

Für den Schaltaktor werden mir am neuen Standort Werte wie folgt angezeigt:
RX ca. -80 bis -83 dBm
TX ca. -83 bis -86 dBm
Beim ursprünglichen CCU2-Standort hatte ich jeweils Werte um -94 bis -96 dBm. Hier konnte ich keine Schaltung des Aktors vornehmen. Die Test-Funktion hatte sporadisch nur funktioniert.

Kennen Sie sich mit den Werten aus???
Kann ich mit den Werten um -80 bis -85 dBm gut leben??? Näher kann ich die CCU2 und den Aktor in der Garage leider nicht zueinander bringen.
Zumindest lässt sich der Aktor jetzt bedienen ohne, dass eine Servicemeldung erzeugt wird.

Meine Heizkörper-Thermostate haben Werte um die -40 bis -57 dBm
(CCU2 und die Thermostate befinden sich auf einem Stockwerk.)

Ihren Programmvorschlag habe ich konfiguriert. Allerdings ist es nun so, dass keine Schaltung des Aktors stattfindet oder wenn, dann nur sehr zeitversetzt eine "Ein-Schaltung". Der Aktor bleibt dann eingeschaltet. Aber meist wird nur der "kurze Tastendruck" durchgeführt/protokolliert.
Das verstehe nich nicht. Ihr Programm scheint mir doch eigentlich plausibel. Schließlich soll ja der Aktor für mich den Tastendruck eines normalen Tasters vornehmen.
Oder muss ich noch irgendwelche Verzögerungswerte einstellen...(?)

Viele Grüße
& einen schönen Sonntag
Rouven

Hallo Rouven1982,

die Werte sind nur bedingt aussagekräftig, da die Signalstärke von verschiedenen Faktoren (z.B. auch Witterungseinflüsse) abhängt.

Wenn eine sehr zeitversetzte Reaktion stattfindet und ggf. auch Signale ausbleiben, scheinen Sie immer noch im Grenzbereich der Funkreichweite zu liegen. Die Datenpakete kommen dann meist nur nach mehreren Wiederholungen durch, welches eine Verzögerung zur Folge hat.

Wir raten dazu, dass Sie einen Homematic Repeater auf halber Strecke hinzufügen.

Hallo Herr Sandhorst,

Danke für Ihre Information. Gut zu wissen, dass es das gibt.
Vor drei Tagen habe ich meinen Torantrieb nun "scharf geschalten" sozusagen. So wie ich jetzt die CCU2 positioniert habe, funktionieren die Befehle wunderbar und ohne große Verzögerungen. Wenn es so bleibt, bin ich absolut zufrieden.

Zur Programmierung:
Hier habe ich lediglich eine direkte Verknüpfung angelegt.
Sender: Der virtuelle Taster (kurzer Tastendruck) der CCU2
Empfänger: der Schaltaktor (Torantrieb)
Beim Empfänger habe ich eingestellt:
Schalter ein/aus
Einschaltverzögerung - keine
Einschaltdauer - 1s
Ausschaltverzögerung - keine
Verweildauer im Zustand "aus" - unendlich

So scheint es bei mir zu funktionieren.
Mal sehen, in wie weit sich die Witterungsverhältnisse noch bemerkbar machen werden.

Einen schönen 3. Advent :-)

Viele Grüße
Rouven

Hallo und ein gutes Neues an alle Experten und Mitleser!

Möchte das Thema gestörte Gerätekommunikation noch mal aufgreifen. Ganz offensichtlich scheint das ja kein völlig unbekanntes Problem zu sein. In meinem konkreten Fall handelt es sich offensichtlich nicht um ein Feldstärken/Reichweitenproblem. Jetzt zu den Fakten:
Fall 1
Ich habe eine Alarmanlage mit HM Komponenten realisiert. Hierzu gehört auch ein Buzzer, der durch einen HM-LC-Sw1-Ba-PCB gesteuert wird. Dieser Schaltaktor für Batteriebetrieb befindet sich durch 3 Rigipswände getrennt in ca. 6 m Entfernung von der CCU2. Steuere ich den Schalter jetzt manuell beliebig oft per WebUI "Status und Bedienung" - "Geräte" mit je einem Mausklick, so reagiert der verbundene Buzzer prompt mit 100%iger Zuverlässigkeit.
Wird jetzt ein Alarm ausgelöst, so stoppt der Buzzer entweder nach der programmierten Zeit oder Eingabe einer entsprechenden Codefolge an einem AP-6-fach Taster. Soweit die Theorie. Das stoppen durch den Timer funktioniert immer. Löse ich aber einen Alarm versehentlich aus und möchte den Alarm durch Eingabe des entsprechenden Codes abschalten, so erhalte ich zuverlässig einen Gerätekommunikationsfehler und der Buzzer macht bis zum programmierten Timeout weiter Krach.
Erst das Umstellen der Programmierung verbunden mit einem Restart der CCU scheint das Problem gelöst zu haben.

Fall 2

Ein HM-LC-Bl1PBU-FM Rolladen Unterputzschalter ist ca. 2m und eine Rigipswand von der CCU entfernt montiert. Der Rolladen ist Zeit- und Sonnenstand - gesteuert. Durch eine Verknüpfung mit dem Zustand des betroffenen Fensters ist die Programmierung etwas komplexer. Alles funktioniert prächtig. Nur morgens, wenn der Rolladen per Uhr oder Sonnenaufganggesteuert hochfährt, gibt es 2-4 mal pro Woche einen Kommunikationsfehler. Meist fährt der Rolladen dann trotzdem hoch. Hier scheidet ein HF-Problem mit grosser Wahrscheinlichkeit aus. Auch habe ich bewusst darauf geachtet, dass unterschiedliche Rolläden nicht zeitgleich betätigt werden. Alle anderen Rolläden zeigen diese Problem nicht.

Ich muss also davon ausgehen, dass es sich hier um ein Problem in der Ablaufsteuerung handelt, das vermutlich die CCU am korrekten Arbeiten hindert. Besonders bei einer komplexen Steuerung wäre das besonders ärgerlich und würde die HM ggf für kritische Projekte disqualifizieren.

Daher die Frage in die Runde:

Wer weiß was? Gibt es WebUI Programmierungen, die so etwas verursachen können. Wie kann ich dem Problem diagnostisch auf die Pelle rücken. Wäre toll, wenn jemand helfen könnte.

Gruss,

Uli

Nachtrag zu meinem vorherigen Posting.

Habe noch mal etwas im Forum gestöbert. Dabei wurde mir klar, dass es besonders um die Rolladensteuerung Probleme zu geben scheint. So konnte ich erkennen, dass es bedingt durch die Verwendung der Steuerung per Sonnenaufgang unter bestimmten Konstellationen zu zeitgleichen Kommandos kommen kann. Habe deshalb Verzögerungen im Minutenbereich eingefügt und werde das jetzt noch einmal beobachten.

Sollte das für mich die Lösung sein, so sollten die Meldungen für den Rolladenaktor verschwinden. Trotzdem bliebe mir das Verhalten unverständlich. Alle Rolläden werde bei mir per CCU2 gesteuert. Wenn die zeitgleich zu sendenden Befehle nicht in eine Queue eingereiht werden, so sollte der verantwortliche Codeschreiber vielleicht den Job wechseln.

Oder haben wir es doch alle nur mit einen Hobbyisten Bastelprojekt zu tun, das nie für einen professionellen Einsatz gedacht war?

Hallo mototeacher,

Homematic verwendet ein bidirektionales Funkverfahren, bei dem jeder Aktor eine Rückmeldung zum Sender liefert. Des Weiteren übermittelt jeder Aktor auch eine Zustandsmeldungen an die Homematic Zentrale CCU1/CCU2. Bei einer gleichzeitigen Ansteuerung von mehreren Aktoren können, in ungünstigen Konstellationen, Kollisionen im Funkverkehr entstehen und unerwartete Verhaltensweisen als Folge auftreten.

Eine Abhilfemaßnahme, bei Verwendung einer Zentrale, ist die zentrale Steuerung von Aktoren mit einer zeitlichen Trennung zu versehen. Diese zeitliche Trennung kann in einem Programm mit der Funktion „verzögert um…“ realisiert werden und muss an die jeweilige Installation angepasst werden.

Bitte beachten Sie hierzu auch unser Hinweisblatt "Mögliche Ursachen für eine gestörte Funk-Kommunikation im Homematic System".

Hallo @all,

zuerst einmal Danke Eurer Beiträge. Damit war es mir möglich, meine installation wieder zum "Leben" zu erwecken.
Daher auch mein Beitrag an der Stelle, sozusagen als kleines Dankeschön zurück für alle diejenigen, die auch in diese Situation kommen. Ich vermute, da gibt es einige.

Die Situation am 20.04.2017:
Alle Homematic-Geräte waren nicht mehr steuerbar, CCU2-Zentrale meldet für alle Geräte "Gerätekommunikation gestört"

‐ ALLE Temperaturen, Feuchte, Rauch, Sensoren werden nicht mehr oder falsch in App "PocketControl" angezeigt,
keine Steuerung mehr möglich

Rekonstruktionsversuch der Änderungen der letzten Wochen ergab:
‐ App "PocketControl" mit Update am 13.04.17
‐ am 09.04.2017 CCU2 mit Update auf FW 2.27.8 versorgt
> Hintergrund für Durchführung des Updates von FW 2.25.15 war, das mit 2.25.15
1. es ständig zu Dienstprobemen für "virtuelles Device" und "Homematic IP" kam, die Dienste terminierten (ich
nutze bisher keine Homematic IP‐Komponenten)
2. Diagramme wurden nicht mehr dargestellt, die WegGui zeigte
nichts mehr an, Daten wurden vermutlich auch nicht mehr gesammelt
‐ nach Update und CCU Reboot: anderes Verhalten (Adminanmeldefenster wurde angezeigt, es war schon immer so
eingestellt, was aber nie funktionierte)
‐ autonome Wetterstation erhielt seit ca.20.04.17 keine Daten der Sensoren mehr ("wait for Transmission")
‐ Routerkonfig am 09.04.2017 verändert (neue Router und Repeater aktiviert) + DECT auf ECO‐Dect und Leistungsreduktion umgestellt
‐ Nachbar seit 20.04.17 zurück

vermutete Ursachen:
> zentrale CCU defekt / Softwarefehler?
> Funktstörungen? (Router?, Nachbar?)
> App "PocketControl" Softwarefehler?

Massnahmen und Auswirkungen:
1. Reboot CCU2 > keine Veränderung

2. Test weiterer Homematic App > gleiche Anzeigen (nur Fehler)

3. Reboot autonome Wetterstation > Sensoren nicht mehr erkannt

4. Check Funkfrequenzen aller Router (2.4 + 5 GHz) und mögliche Störeinflüsse > nix zu erkennen / finden

5. Websuche, hier gelandet
(https://www.elv.de/topic/ccu2‐meldet‐bei‐saemtlichen‐geraeten‐geraetekommunikation‐gestoert.html)

Feststellung: gleiche Probleme mit Firmware 2.19.9 >
> 2.15.5 sollte 06/2016 stabil gewesen sein

6. Backup CCU2 erstellt (WebUI)

7. Installation Firmware 2.21.10 (Downgrade von FW 2.27.8)

8. Batterietausch Sensoren Wetterstation + 2 andere

Ergebnis:
alles funktioniert wieder mit FW 2.21.10

‐ es kommen auch keine Fehlermeldungen der Geräte von Homematic‐IP und Virtuellen Devicedrivern mehr

‐ werden die Diagramme wieder angezeigt (meine Vermutung, das mit der "neuen Superfirmware" (ab 2.25.xx)
Daten nicht mehr gesammelt wurden, hat sich bestätigt

‐ das das Anmeldefenster angezeigt wurde, lag am auf der WebGUI, dort hatte ich bisher immer die alte SID des
Adminkontos mitgeführt
> an der Stelle gibt es also auch noch ein Sicherheitsleck in der WebGUI

All des Dilemma wohl weil die ganze Homematictechnik nie wirklich zum Produkt mit professionellem Support gewachsen ist.

Dilemma ist wohl nahe verwandt mit dilettantisch.

Das Dilemma, verursacht durch dilettanschtische Programmierung und Qualitätskontrollen (= Tests), was die Kunden ausbaden dürfen!

Hallo,

ich finde die Kommunikationsstörungen auch ziemlich nervig und beunruhigend.
Wenn dann folgende Aussagen vom Service kommen (siehe vorletzten post):
'Bei einer gleichzeitigen Ansteuerung von mehreren Aktoren können, in ungünstigen Konstellationen, Kollisionen im Funkverkehr entstehen und unerwartete Verhaltensweisen als Folge auftreten. Eine Abhilfemaßnahme, bei Verwendung einer Zentrale, ist die zentrale Steuerung von Aktoren mit einer zeitlichen Trennung zu versehen. Diese zeitliche Trennung kann in einem Programm mit der Funktion „verzögert um…“ realisiert werden und muss an die jeweilige Installation angepasst werden.'

Das ist ein Armutszeugniss!. Es sollte ja wohl die Aufgabe des Steuerungssystemes (CCU2) sein, die zeitliche Abfoge der Gerätekommunikation sicherzustellen und nicht dem Anwenderprogramm dise Aufgabe überzuhelfen.