Probleme bei sehr geringer Entfernung zwischen Geräten

[Xel66]

Nein, ich betreibe sogar zwei unterschiedliche Gerätegenerationen untereinander. IP-Geräte kommunizieren grundsätzlich "verschlüsselt". Das hat auch zur Folge, dass die Funkpakete länger und theoretisch empfindlicher gegen Störungen sind. Bei mir hat aber gerade der Umstieg auf IP die Verbesserung gebracht. Beachten muss man immer auch noch, dass Rollladenaktoren relativ geschwätzig sind. Meist setzen sie noch mal eine Quittung an die CCU ab, wenn sie losgelaufen sind und dann noch mal, wenn sie ihre Sollpostition erreicht haben. Am besten mit der zeitlichen Entzerrung testen.

Gruß Xel66

[Matsch]

Beachten muss man immer auch noch, dass Rollladenaktoren relativ geschwätzig sind. Meist setzen sie noch mal eine Quittung an die CCU ab, wenn sie losgelaufen sind und dann noch mal, wenn sie ihre Sollpostition erreicht haben. Am besten mit der zeitlichen Entzerrung testen.

Eben. Genau das ist zu beachten. Der Funkverkehr findet halt nicht nur beim Start des Vorgangs statt, sondern auch nach Erreichen der Zielposition (Zeitpunkt eher unbekannt). Und dieser Zeitpunkt kann nun wieder mit der Anforderung an den zweiten Aktor kollidieren ...

Ich gebe zu, in meinen Fällen benachbarter Aktoren arbeite ich mit einer state machine. D.h. erst wird der erste Aktor gefahren und gewartet, bis dieser das Ende der Bewegung meldet und erst danach wird der zweite Aktor gefahren und der erste bekommt nicht eher einen Folgebefehl, bevor der zweite nicht wieder steht. Zumindest diese beiden kommen sich so beim Verfahren nie in die Quere.

[olivercj]

Sorry, ich muss da aber noch mal nachhaken...

Ich sitze im Obergeschoss in meinem Büro, Die beiden Rolladen, um die es geht, sind um 6 Uhr morgens hochgefahren (worden). Mittlerweile haben wir 10 Uhr. Ich melde mich auf der WebUI an und einer der beiden meldet mir Kommunikationsstörungen.

Das kann doch nichts mehr mit zeitlicher Entzerrung zu tun habe oder das man den zweiten am besten erst ansteuert, wenn der erste mit seiner Fahrt fertig ist.

So rein interessenhalber versuche ich in diesen Momenten eine Fahrt auszulösen... manchmal geht es mit einiger Verzögerung (ich drücke und 10 Sek später fährt er dann mal los) und manchmal eben auch nicht.

Das Thema mit der state machine würde mich trotzdem interessieren. Kannst Du mehr dazu schreiben?

Danke!

[Matsch]

Das Thema mit der state machine würde mich trotzdem interessieren. Kannst Du mehr dazu schreiben?

Dann müßte ich jetzt einen Vortrag über die Grundlagen der Automatentheorie halten (wenn ich das könnte). State machines (früher: Zustandsautomaten) sind quasi ein wichtiges Element komplexerer digitaler Verarbeitungsstrukturen. So weisen wahrscheinlich alle Geräte der HM-/ HmIP-Serie intern mindestens eine solche (gleiche) state machine auf, die die Ablaufreihenfolge steuert (zu sehen in den Expertenprofilen der DVs).

Ganz allgemein gesagt: In einer state machine werden alle gewünschten und denkbaren Schritte eines Automaten in Zuständen definiert sowie die Bedingungen, die zum Wechsel in jeweils einen anderen Zustand führen können. Man braucht zum Verlassen eine Zustands bestimmte Ereignisse/Trigger, um zum jeweils nächsten Zustand zu gelangen.

So wären hier z.B. die Zustände
- Rollladen_in_Ruhe
- Fahrt_Rollladen
- Fahrtende

denkbar. Der erste Zustand wird verlassen, wenn der Rollladen verstellt werden soll (z.B. Änderung der Helligkeit). Der Automat startet den Aktor und wechselt in den Zustand "Fahrt_Rollladen" bis der Aktor meldet, die Fahrt beendet zu haben. Dann wechselt er in den Zustand "Fahrtende". Dann werden wieder Bedingungen definiert, wodurch und wohin er diesen Zustand verlassen soll/darf.

Am einfachsten läßt sich so was hier umsetzen, wenn man für die Zustände eine SV als Werteliste erstellt, für jeden Zustand ein Programm definiert, das nur ausgeführt wird, wenn der Zustand richtig ist und unter den festgelegten Bedingungen zum nächsten Zustand wechselt.
Ich realisiere solche Zustandsautomaten inzwischen wegen der besseren Übersichtlichkeit in nur einem Programm mit einem großen Script.

Zum Thema: Hast du denn mal versucht, einen der Aktoren tot zu legen (Abklemmen), ob dann der andere, der bisher Störungen produziert hat, immer störungsfrei läuft - oder ob er prinzipiell Verbindungsprobleme hat, auch ohne extra gestört zu werden? Vielleicht liegt's ja gar nicht an dem anderen. Was sagt denn der RSSI-Wert?

[olivercj]

Vielen Dank für die Erklärung! Das ließe sich in der Tat relativ einfach in openHAB abbilden...

Wochenende ist bei uns immer Familienzeit... daher werde ich morgen mal ein wenig rumprobieren, den funktionierenden ausbauen, mal untereinander tauschen, etc... mal sehen wie sich das auswirkt. Wobei ich jetzt schon seit gestern nichts mehr feststellen konnte.

Welcher rssi-Wert wäre denn der wichtige/richtige???

rssi.JPG (23.94 KiB) 274 mal betrachtet

Was auffällig ist, ist der rssi-peer am linken Fenster. Der ist mit -89 nicht mehr ganz so dolle...

[Xel66]

.. und einer der beiden meldet mir Kommunikationsstörungen.

Ja welche? IST gestört oder WAR gestört? Schon mal die Kommunikationsparameter (Eventverzögerung, Zufallsanteil etc.) entsprechend angepasst und so für weitere Entzerrung gesorgt? Hast Du zyklische Statusmeldungen abgeschaltet oder auf untaugliche Werte hochgesetzt? Bei mir laufen die Rollladen im 1-2 sekündigen Abstand. Nur einen weiter entfernten habe ich mit einem Workaround ausgestattet, weil er ab und zu mal mit seinem Status nicht "durchkam".

Dieser Workaround besteht aus einem Script und schaut nach dem Datenpunkt "WORKING". Dieser ist wahr, wenn ein Rollladenaktor losgelaufen ist und die CCU auf die Statusrückmeldung mit der Zielbehanghöhe wartet. Ersichtlich ist dieses am Zahnrad in der Statusanzeige der WebUI. Ist dieser nach einer Minute (Verzögerung des Scripts) noch WAHR, wird noch mal ein STOP gesendet und der Aktor somit "gezwungen", seinen aktuellen Status zu übermitteln (und diese Korrektur als Protokolleintrag im Systemprotokoll hinterlegt). Das Script ist für klassische Rollladenaktoren (HM-LC-Bl1-FM). Die Datenpunkte müssten für IP-Aktoren entsprechend angepasst werden.

Code: Alles auswählen

! Script zur Erkennung einer fehlenden Erfolgsmeldung mittels WORKING +++++++++++++++
if (dom.GetObject("Besucherklo").DPByHssDP("WORKING").Value()==true){
dom.GetObject("Besucherklo").DPByHssDP("STOP").State(1);
dom.GetObject("Protokolleintrag").State("Status Besucherklo korrigiert");}

Gruß Xel66

[olivercj]

Guten Morgen zusammen,

ich wollte noch mal kurz eine Rückmeldung geben und mich für die bisherigen Antworten bedanken.

Kurz: Ich habe bis jetzt nichts weiter unternommen.
Warum? Weil tatsächlich seit dem Wochenende keine Kommunikationsstörungen am HmIP-BROLL (linkes Fenster im Wohnzimmer) mehr aufgetreten sind.

Die rssi-Werte von dem Gerät sind zwar immer noch nicht top, haben sich aber auf einem Level eingependelt, wo es zumindest nicht mehr zu Kommunikationsstörungen kommt. Ich habe fast das Gefühl, die Geräte mussten sich erstmal "eingrooven".

Damit kann ich leben. Und sollte ich doch mal wieder etwas feststellen (irgendwann wird die CCU3 vom Obergeschoss ins Erdgeschoss ziehen und dort meine Innogy Zentrale ersetzen), dann weiß ich ja jetzt, was ich alles noch testen kann/sollte, um den Fehler einzugrenzen.

Also, Vielen Dank noch mal!
Oliver