Zustandsdarstellung Visuwin verzögert und/oder fehlerhaft

[Reini]

Hallo,

wie bereits schon vorher beschrieben habe ich die gleichen Probleme. Da ich das Homematic-System mit der CL-Box von Contronics mit einem LAN-Adapter und der Homeputer Studio-Software nutze, kann ich feststellen, dass die fehlerhaften Darstellungen in der Visuwin auch ohne dem Problem mit der "Automatischen Zuordung" beim Interface auftreten.

Treten Kommunikationsstörungen auf, werden diese durch normalwerweise eine rote Umrandung in der Visuwin angezeigt. Die habe ich aber ganz ganz selten - meistens wenn durch Stromabschaltung ein Aktor nicht mehr angeschlossen ist (z. B. Schaltsteckdose rausgezogen).

Hier schein aber keine Kommunikationsstörung gemeldet worden zu sein. So wird in der Visunwin der korrekte Wert z.B. Rollo soll oben sein, tatsächlich ist das Rollo unten. Dabei tritt keine Fehlermeldung auf. Auch in der Syslog ist kein Fehler dokumentiert. Dies Software geht davon aus, dass der Schaltvorgang korrekt funktioniert hat. Nur die Praxis sieht anders aus.

Über ein Makro habe ich die Möglichkeit den Befehl "Abfrage()" für die Rollos auszulösen. Sobald dieser gesendet worden ist, werden die korrekten Werte angezeigt - in dem Beispiel: Rollo ist unten.

So enteht für mich der Eindruck, dass die Bidirektonale Abfrage im System (Bidcos) nicht funktioniert. Offensichtlich wird das Rollo als "hochgefahren gemeldet" ist aber tatsächlich nicht angesteuert worden oder hat das Funksignal nicht erreicht.

Unverständlich: gerade das Homematic-System sollte durch die Bidirektonale Kommunikation solche Fehler vermeiden.

Ich denke, dass hier ein Prüfungsbedarf besteht.


Mit freudlichem Gruß
Rini

[Herbert_Testmann]

Hallo

Ich nutze HP Studio CL auf einer CCU und habe keine Lan Adapter.
Letzte Woche hatte ich einen Rollladen, der laut Status runter gefahren sein sollte, in der Realität aber oben geblieben ist. Wegen dem einen Aussetzer hatte ich mir keine Gedanken gemacht, werde solche Dinge jetzt aber stärker beobachten.
Dann kann ich auch genauer sagen, wie der Status in der CCU ist und ob ein kurzer Tastendruck den Rolladen komplett fährt, oder nur ein Stück, weil selbst der Aktor meint, der Rollladen sei unten.

[Mister2]

Hallo,

das Problem trat bei mir am Anfang auch alle paar Tage mal auf.
Insbesondere bei Rollladenaktoren.

Nach einigem probieren und testen, bin ich zu folgender Vermutung gekommen:

Beispiel eine Fahrt von oben nach unten (von offen auf geschlossen)
Die Homputer-Engine gibt den gewünschten Status an die CCU und diese sendet dann an den Aktor.
Der empfängt das Signal und bestätigt es in dem er seinen aktuellen Status zurückmeldet. Dieser ist aber noch = oben weil er die Fahrt gerade erst begonnen hat.
In VisuWin sieht man auch das das Symbol kurz nach dem tatsächlichen Start des Rollladenmotor auf unten springt und dann erst mal wieder auf oben wechselt.
Der eigentlich Zustand unten wird dann erst durch die Rückmeldung des Aktor am Ende der Fahrt aktualisiert.
Falls diese Rückmeldung am Ende der Fahrt aber irgendwie untergeht, ist der Status in der Homputer-Engine / VisuWin = oben weil es ja keine Meldung des Aktor nach dem Ende der Fahrt gab.

Für die CCU ist dies auch keine Kommunikationsstörung weil der erste Befehl zum runter fahren ja vom Aktor bestätigt wurde.
Und wenn die Fahrt nach z.B. 30 Sekunden beendet ist, ist es ja nur ein Senden des Aktor mit seinem aktuellen Status.
Wenn das nicht an der CCU ankommt, ist es kein Kommunikationsproblem, weil die CCU ja nicht weiß das der Aktor gesendet hat.

Ich habe schon mehrfach an anderen Stellen geschrieben, das die von EQ3 angepriesene bidirektionale Kommunikation nur halbherzig umgesetzt wurde.
Gut wäre es gewesen, wenn die Kommunikation immer erst durch eine Empfangsbestätigung der Gegenseite beendet würde.
Beispiel:
Aktor sendet an CCU. Bestätigung von CCU kommt am Aktor an. Alles ok.
Aktor sendet an CCU. Nach 5 Sekunden ist noch keine Bestätigung am Aktor angekommen. Aktor sendet erneut an CCU. Nach 5 Sekunden ist noch keine Bestätigung am Aktor angekommen. Aktor sendet erneut an CCU. Bestätigung von CCU kommt am Aktor an. Alles ok.

Zur Zeit sendet der Aktor und damit ist das Thema für ihn erledigt. Ob die CCU das auch empfangen hat interessiert nicht.
Nur bei z.B. Sensoren kann man einstellen das diese bis zu 10 Mal senden.
Und eine Kommunikationsstörung gibt es immer nur wenn die CCU als erstes gesendet hat und auf eine erwartete Rückmeldung des Aktor nichts kommt.

Ich hatte damit sehr wahrscheinlich insbesondere mit den Rollladenaktoren Probleme, weil hier sehr oft viele Aktoren zur gleichen Zeit angesprochen wurden.

Wenn ich z.B. bei allen 8 Aktoren in der Zeitsteuerung Hochfahren bei Sonnenaufgang und Runterfahren bei Sonnenuntergang stehen habe, schickt die CCU innerhalb kürzester Zeit die Befehle an die Aktoren raus. Diese kommen auch alle an.
Wenn einige Rollläden die gleiche Laufzeit haben, kommt es am Ende der Fahrt zu einem "Funkstau" an der CCU weil die Aktoren ihren neuen Status melden.
Und dabei bleibt dann schon mal der eine oder andere auf der Strecke.

Möglichkeit zur Lösung:
1. Die Rollläden mit einem Makro steuern anstatt die Zeitsteuerung zu verwenden.
Dort dann mit Sonnenuntergang für den ersten Rollladen, Sonnenuntergang + 2 Minuten für den zweiten Rollladen, ... arbeiten.
Dadurch wird das gleichzeitige Rückmelden ausgeschlossen.
Aber es kann trotzdem immer mal wieder vorkommen das eine Rückmeldung auf der Strecke bleibt weil auch gerade ein anderer Aktor sendet.

2. Man fragt den Status des Aktor gezielt ab.
ABFRAGE(Objektname)
Mit dieser Anweisung kann der aktuelle Zustand/Wert der Hardware eines Objekts abgefragt werden. Normalerweise ist das nicht nötig, da Änderungen automatisch aktualisiert werden. In speziellen Anwendungen kann es sinnvoll sein diese Anweisung zu verwenden, sie sollte jedoch nicht zu häufig und möglichst nur bei sicherheitsrelevanten Objekten benutzt werden, da sie relativ zeitintensiv ist und es bei zu häufiger Verwendung zu Verzögerungen bei der normalen Kommunikation kommen kann,

Ich habe mich für die Rollladen für die Möglichkeit 2 entschieden und seit dem ist das Problem weg.

Beispiel für Rollladen
(Geht analog auch für andere Aktoren. Man sollte es aber nicht übertreiben weil es zusätzlichen Funkverkehr verursacht. Und je mehr Funkverkehr umso mehr Probleme):

Einmal das Makro für die Abfrage (Die Wartezeit muss so gesetzt sein, das es etwas mehr ist als die längste Laufzeit des größten Rollladen):

Code: Alles auswählen

//! ============================================================
//! OBJEKT EG_RL_Abfrage
//! ============================================================
//! OBJEKT-TYP              : Makro
//! BEZEICHNUNG             : EG_RL_Abfrage
//! STARTWERT               :
//! ------------------------------------------------------------
//! AUSFÜHRUNGSINTERVALL    : nein
//! AUSFÜHRUNG BEI EINGABE  : nein
//! AUSFÜHRUNG BEI EMPFANG  : nein
//! AUSFÜHRUNG BEI ÄNDERUNG : nein
//! ------------------------------------------------------------
//!
//! ============================================================
//! VARIABLENDEFINITIONEN
//! ============================================================
//! NAME                TYP                 STARTWERT
//! ------------------------------------------------------------
//! BadFenster          Zahl                0
//! BüroFenster         Zahl                0
//! KücheGarage         Zahl                0
//! KücheStrasse        Zahl                0
//! SchlafzimmerFenster Zahl                0
//! TechnikFenster      Zahl                0
//! WohnzimmerGarage    Zahl                0
//! WohnzimmerTerasse   Zahl                0


WARTE("00:01:30")

wenn EG_RL_Abfrage.BadFenster = 1 dann
  ABFRAGE(EG_RL_BAD_FEN)
  EG_RL_Abfrage.BadFenster := 0
endewenn

wenn EG_RL_Abfrage.BüroFenster = 1 dann
  ABFRAGE(EG_RL_BU_FEN)
  EG_RL_Abfrage.BüroFenster := 0
endewenn

wenn EG_RL_Abfrage.KücheGarage = 1 dann
  ABFRAGE(EG_RL_KU_GAR)
  EG_RL_Abfrage.KücheGarage := 0
endewenn

wenn EG_RL_Abfrage.KücheStrasse = 1 dann
  ABFRAGE(EG_RL_KU_STR)
  EG_RL_Abfrage.KücheStrasse := 0
endewenn

wenn EG_RL_Abfrage.SchlafzimmerFenster = 1 dann
  ABFRAGE(EG_RL_SZ_FEN)
  EG_RL_Abfrage.SchlafzimmerFenster := 0
endewenn

wenn EG_RL_Abfrage.TechnikFenster = 1 dann
  ABFRAGE(EG_RL_TE_FEN)
  EG_RL_Abfrage.TechnikFenster := 0
endewenn

wenn EG_RL_Abfrage.WohnzimmerGarage = 1 dann
  ABFRAGE(EG_RL_WZ_GAR)
  EG_RL_Abfrage.WohnzimmerGarage := 0
endewenn

wenn EG_RL_Abfrage.WohnzimmerTerasse = 1 dann
  ABFRAGE(EG_RL_WZ_TER)
  EG_RL_Abfrage.WohnzimmerTerasse := 0
endewenn

In jedem Rollladenobjekt wird dann die lokale Variable auf 1 gesetzt und danach das Abfrage-Makro gestartet.

Code: Alles auswählen

//! ============================================================
//! OBJEKT EG_RL_BAD_FEN
//! ============================================================
//! OBJEKT-TYP              : Rolllade
//! BEZEICHNUNG             : EG-Rollladen-Bad
//! STARTWERT               :
//! ------------------------------------------------------------
//! AUSFÜHRUNGSINTERVALL    : nein
//! AUSFÜHRUNG BEI EINGABE  : ja
//! AUSFÜHRUNG BEI EMPFANG  : nein
//! AUSFÜHRUNG BEI ÄNDERUNG : ja
//! ------------------------------------------------------------
//!
//! ============================================================
//! ZEIT-TABELLE (kann [noch] nicht im Editor verändert werden)
//! ============================================================
//! WERT                TAG             UHRZEIT
//! ------------------------------------------------------------
//! oben                Täglich         Sonnenaufgang
//! unten               Täglich         Sonnenuntergang
//!
//! ============================================================
//! VARIABLENDEFINITIONEN
//! ============================================================
//! NAME                TYP                 STARTWERT
//! ------------------------------------------------------------

EG_RL_Abfrage.BadFenster := 1
STARTE(EG_RL_Abfrage)

Da es dann auch eine Abfrage von der CCU an den Aktor ist, erwartet die CCU auch auf jeden Fall eine Rückmeldung und falls diese nicht ankommt gibt es eine Kommunikationsstörung welch man z.B. mit dem Script von Teddy abhandeln kann so da der Status auf jeden Fall aktuell ist.

Besser wäre es natürlich wenn die CCU selbst sich merken würde das sie einen Rollladenaktor angesprochen hat und dann nicht nur auf die erste Rückmeldung am Anfang der Fahrt warten würde, sondern auch auf die Rückmeldung am Ende. Und wenn diese nicht kommt, gäbe es eine Kommunikationsstörung.

Die gleichen Probleme treten natürlich auch auf wenn man z.B. einen Aktor mit einschalten für "00:10:00" eingeschaltet hat und nach 10 Minuten schaltet der Aktor sich selbst aus aber die Rückmeldung geht unter. Dann steht in der CCU / Execengine / VisuWin der Status immer noch auf eingeschaltet.
Ein neues Einschalten aus VisuWin geht dann nur wenn man den Aktor dort erst aus und neu einschaltet.

[Reini]

Hallo
@ Mister2,

ich habe den Einruck, dass hier zwei verschiedene Probleme gemeint sind.

Ich hatte den Fehler so beschrieben, dass in der Visuwin ein geänderter Wert korrekt angezeigt wird
z.B. Rollo soll von oben nach unten fahren - angezeigt wird in der Visuwin: Rollo unten.

Tatsächlich ist aber das Rollo noch weiterhin oben - es hat also gar nicht gefahren.

Sicherlich kann per Abfrage der korrekte Rollostaus in der VisuWin abgefragt werden. Das ist aber eigendlich nicht sinn und Zweck eines Bidirektonalen Systems.

Bei deiner Beschreibung habe ich es so verstanden, dass das Rollo gefahren ist, aber der alte Wert in der Visuwin angezeigt wird. Das wäre dann ein anderes oder 2. Problem.


mfg Reini

[Mister2]

Hallo Reini,

du hast Recht.
Wobei ich die 2 Konstellation (Zustand in VisuWin ist korrekt, aber der Rollo ist nicht gefahren) noch nie hatte.
Wenn der Rollo bei mir nicht gefahren ist, war auch der Zustand in VisuWin dazu passend.

[Herbert_Testmann]

Hallo

Ich hatte den Zustand , rollladen nicht gefahren, Anzeige in CCU und VISUWIN entspricht aber dem Wunschzustand ... Genau ein mal. Ich habe das für eine Fehlfunktion des Rollladens gehalten.

[joesch]

Bitte nicht aus den Augen verlieren, dass das Problem auch bei anderen als den Rolladenaktoren besteht

VG - Joesch

[Familienvater]

Moin,

jetzt hat mich das leidige Thema auch erwischt (HPCL auf CCU, die Zeitsteuerung/Logik liegt in HPCL):
Rolladen soll zeitgesteuert runterfahren, Befehl wird per Funk an den Aktor übertragen, neuer Zustand in Visu ist jetzt unten. Direkt danach schaltet der Rolladenaktor und der Rolladen fängt an sich zu bewegen, was auch sofort wieder freudig vom Aktor mitgeteilt wird: neuer Zustand in Visu ist jetzt wieder oben. Und der Rolladen fährt runter und ist in echt unten.

Jetzt kommt die systemschwäche von dem tollen BidCos-System:
Die CCU merkt nicht, das da eigentlich eine Rückmeldung vom Rolladenaktor nach der eingestellten Fahrzeit fehlt!
-> Keine Kommunikationsstörung! Keine Fehlermeldung!
Der Rolladen in echt ist unten, die Visu zeigt oben. Folge: Am nächsten morgen fährt der Rolladen nicht hoch, weil er ja laut letzter bekannter Meldung schon oben ist. Ich war nicht da, und die Familie wundert sich, warum von 5 Rolläden einer nicht fährt. Wenn alle zu bleiben haben die schon gelernt, das wohl was abgestürzt sein muss...

Nach 24h klappt dann wieder alles, und der Rolladen fährt wie gewünscht...

Der Familienvater

[EnergyStar]

Hallo,

ich kann dem Familienvater hier nur zustimmen. Genau dieses Verhalten hab ich bei meinen Rollläden auch schon mehrfach beobachten müssen.

Gruß
EnergyStar

[mikewolf99]

Hi habe selbiges Problem erst heute wieder,
diesmal war es am mal nicht ein Rolladen sondern meine Keymatic die nicht verriegelt war in der Visu jedoch schon,
keine Kommunikationsstörung !!

mfg
mikewolf