HPCL HM+FS20 mit Pc HM-SCI-3-FM

[buempi]

Hallo Herr Krapoth

Hat der BidCoS-Service vielleicht etwas wie einen Zeitstempel, wo man feststellen könnte, ob er erst kürzlich gestartet wurde? Auch die CCU oder CL-Box muss ja von Zeit zu Zeit neu gestartet werden (z.B. Update von Software), und dann tritt dort der Fehler ja ebenfalls auf.

Oder könnte man eine Möglichkeit schaffen, welche die Abfrage des BidCoS-Service beim Start verhindert?

Als Workaround könnte man auch die Zustände der kritischen Module entweder bei jedem Zustandswechsel oder mindestens in einem END_Makro über SCHREIBEDATEI() sichern und erst 30 Sekunden nach dem Neustart der ExecEngine in einem INIT_Makro wieder laden.

Viele Grüsse
Bümpi

[Daimler]

Hallo Herr Krapoth,

sorry, wenn ich da jetzt nicht ganz mitkomme.

Sie schreiben und zitieren:
Die Zustände eines Sensors stimmen nur dann nicht wenn der BidCos-Service beim letzten Empfang einer Meldung für den Sensor nicht aktiv war. Dann stehen die Zustände auf dem Default-Wert des BidCos-Services.

Der Zustand des Sensors hat sich aber zwischenzeitlich nicht geändert, infolgedessen wurde auch keine Meldung verpasst!

Als Lösung schlagen Sie vor:
.....kann ich nur raten eine CCU oder CL-Box statt eines PCs als Zentrale zu verwenden. Dort läuft der BidCos-Service ständig...
Erklären aber gleichzeitig:
...wird nur bei einem Reboot beendet. Dann allerdings würde der derselbe Effekt auftreten können...

Wo ist jetzt der Unterschied zu der PC-Lösung bzw. die Lösung?

[contronics-RK]

Hallo,

einen speziellen Zeitstempel hat der BidCos-Service nicht.
Die Abfrage optional zu machen wäre zwar möglich, aber es wäre vollkommen falsch wenn das auch für normale Aktoren gemacht würde, diese Zustände werden ja korrekt aktualisiert da die Hardware abgefragt werden kann. Dann müsste man es also so machen, dass es diese Option für einzelne Module gibt. Das heisst aber auch neben dem Aufwand das ins Programm einzubauen einen entsprechenden Aufwand bei der Konfiguration. Zusätzliche Optionen machen die Konfiguration nicht übersichtlicher und die Gefahr von Fehlkonfigurationen steigt. Benutzer von externen Zentralen hätten keinerlei Nutzen, sondern nur die Möglichkeit mit dieser Option einen Fehler einzubauen. Da würde dann zu Recht die Frage kommen warum es diese Fehler-Option überhaupt gibt.
Zudem muss man auch wirklich die Frage stellen ob der Aufwand für die wenigen in Frage kommenden Batteriesensoren und den (Ausnahme-)Fall dass der BidCos-Service auf dem PC zwischendurch beendet wird überhaupt gerechtfertigt ist.
Dabei ist auch zu bedenken, dass eine solche Option nur funktionieren könnte wenn die ExecEngine kontrolliert beendet wird, bei einem Neustart durch Reboot gibt es sowieso keine Datei, in der die letzten Werte stehen.

Ich meine eine gute Idee und ein akzeptabler Workaround wäre die von Bümpi vorgeschlagene Lösung die Werte der fraglichen Batteriesensoren mit SCHREIBEDATEI zu sichern und nach Neustart verzögert wieder einzulesen.

Nachträglicher Zusatz zum Beitrag von Daimler:
@Daimler
Man kann doch nicht grundsätzlich davon ausgehen, dass der Zustand sich nicht geändert hat, und ob nun eine Meldung "verpasst" wurde und ob der Zustand des BidCos-Services der Default-Zustand oder der aktuelle ist kann man nicht unterscheiden.
Bei einem Reboot gibt es grundsätzlich sowieso keine andere Möglichkeit als die Werte aus dem BidCos-Service auszulesen, da ja dann keine WERTE-Datei existiert. Vollkommen egal mit welcher Hardware.

[Tobias78]

Hallo Contronics,
der Fehler, dass Tür-Kontakte immer geschlossen melden, wenn die Homeputer Software neu gestartet wird, trifft auch auf die CCU Konfiguration zu und nervt mich auch schon seit geraumer Zeit, da eine Tür überwacht wird die immer offen stehen muss.
In der WebUI wird der Zustand richtig angezeigt...
Alle Versuche, den Türsensor per Start-Makro auf "offen" zu setzen, oder den Zustand manuell abzufragen oder per lesewerte zu setzen sind bei mir gescheitert. Vielleicht klappt es ja mit der besagten Zeitverzögerung.
In der Homeputersoftware kann man doch bereits einen Startwert vorgeben, der allerdings nicht berücksichtigt wird?!? Konsequenterweise müsste diese Option rausgenommen werden, oder funktionierend gemacht werden.
Gruß, Tobias.

[Daimler]

Hallo contronics-RK,

Die Abfrage optional zu machen wäre zwar möglich, aber es wäre vollkommen falsch wenn das auch für normale Aktoren gemacht würde, diese Zustände werden ja korrekt aktualisiert da die Harwdare abgefragt werden kann. Dann müsste man es also so machen, dass es diese Option für einzelne Module gibt. Das heisst aber auch neben dem Aufwand das ins Programm einzubauen einen entsprechenden Aufwand bei der Konfiguration. Zusätzliche Optionen machen die Konfiguration nicht übersichtlicher und die Gefahr von Fehlkonfigurationen steigt. Benutzer von externen Zentralen hätten keinerlei Nutzen, sondern nur die Möglichkeit mit dieser Option einen Fehler einzubauen. Da würde dann zu Recht die Frage kommen warum es diese Fehler-Option überhaupt gibt.
Wo wäre das Problem, diese Option standardmäßig zu deaktivieren und deren Funktion evtl. in der Anleitung zu erklären?

Zudem muss man auch wirklich die Frage stellen ob der Aufwand für die wenigen in Frage kommenden Batteriesensoren und den (Ausnahme-)Fall dass der BidCos-Service auf dem PC zwischendurch beendet wird überhaupt gerechtfertigt ist.
Ob das wirklich so wenige HM-SeC-SC, HM-Sec-RHS und HM-SwI-3-FM... sind, wage ich zu bezweifeln - aber dies wird wohl nur EQ-3 beantworten können.

Ich meine eine gute Idee und ein akzeptabler Wordaround wäre die von Bümpi vorgeschlagene Lösung die Werte der fraglichen Batteriesensoren mit SCHREIBEDATEI zu sichern und nach Neustart verzögert wieder einzulesen.
Dabei tritt aber doch der gleiche Effekt wie hier auf - für den Fall des harten Reboots gibt es m. E. keine Lösung:
Bei einem Reboot gibt es grundsätzlich sowieso keine andere Möglichkeit als die Werte aus dem BidCos-Servive auszulesen, da ja dann keine WERT-Datei existiert. Vollkommen egal mit welcher Hardware.

Man kann doch nicht grundsätzlich davon ausgehen, dass der Zustand sich nicht geändert hat, und ob nun eine Meldung "verpasst" wurde und ob der Zustand des BidCos-Services der Default-Zustand oder der aktuelle ist kann man nicht unterscheiden.
Wäre aber m. E. bei den genannten Sensoren, Sendern immer noch die bessere Alternative.

P.S.
Sehe gerade beim Verfassen des Beitrages, daß sich endlich auch ein CCU-User zu Wort meldet.
Dann sind doch alle in einem Boot!

[buempi]

für den Fall des harten Reboots gibt es m. E. keine Lösung

... doch; deshalb habe ich empfohlen, kritische Module bei jedem Zustandswechsel zu sichern.

Viele Grüsse
Bümpi

[Daimler]

Hi Bümpi,

sorry - hatte ich überlesen.
Aber zu dem Workaround werde ich Dich bestimmt nochmal nerven, wenn hier von anderer Stelle nichts kommt.

[Tobias78]

Sehe gerade beim Verfassen des Beitrages, daß sich endlich auch ein CCU-User zu Wort meldet.
Dann sind doch alle in einem Boot!

...die Überschrift ist reichlich kryptisch. Hatte mich eigentlich verklickt, sonst wäre ich wohl auch nicht hierauf gestoßen.
Gruß, TObias.

[contronics-RK]

Hallo,

auf der CCU werden definitiv sowohl die aktuellen Zustände der Fensterkontakte wie auch die Zustände des Moduls HM-SCI-3-FM aus dem BidCos-Service ausgelesen wenn die ExecEngine neu startet. Das haben wir jetzt aufgrund dieser Beiträge extra noch einmal ausgiebig getestet.
Wenn die Zuständen dieser Module auf der CCU nach einem einem Neustart der ExecEngine nicht korrekt sind gibt es nur zwei Möglichkeiten:

- Seit dem letzten Start des BidCos-Services wurde der aktuelle Zustand noch nicht vom Modul übertragen, ist also im BidCos-Service nicht aktuell. Das ist natürlich bei einem Reboot der CCU immer der Fall.

- Die Moduldefinition ist ziemlich alt. Es ist lange her (ca. 1-1,5 Jahre) dass ein Fehler in den Modultabellen berichtigt wurde, der bewirken konnte, dass Fensterkontakt und HM-SCI-3-FM beim Start der ExecEngine nicht abgefragt wurden.
Falls das die Ursache ist, kann es folgendermassen berichtigt werden:
Das Modul in der Liste der verwendeten Module mit recher Maustaste anklicken, das Beschreibungsfeld wird daraufhin gelb.
Dann den Import-Knopf anklicken, jetzt werden die Werte aller derart markierten Module komplett upgedatete und alte Einstellungen überschrieben (Achtung: Dabei kann auch der Objekttyp überschrieben werden wenn dieser angepasst wurde!).

Nochmal zu Erklärung:
Bei Start der ExecEngine werden die aktuellen Zustände, die der BidCos-Service momentan von den einzelnen Modulen hat beim BidCos-Service abgefragt (ausser bei Tastern, Fernbedienungen und Bewegungsmeldern). Der BidCos-Service entscheidet dann im Einzelfall ob er eine erneute Abfrage bei den Modulen macht. Das geht natürlich grundsätzlich nicht bei batteriebetriebenen Sensoren.

[Daimler]

Hallo zusammen,

auch wenn es einigen nicht passen mag - ich hole den Fred nochmal hoch.

@Bümpi
Noch einmal besten Dank für diese Tips - die helfen zum., die Auswirkungen dieses Bugs zum. bis zur Behebung halbwegs zu umgehen:

@mikewolf99: Du könntest das dadurch entschärfen, dass du im INIT_Makro bevor du deine Wert einliest ein entsprechendes WARTE() einbaust.
Trotzdem könnte dieses Verhalten dazu führen, dass durch das Umschalten gewisse Makros bzw. Aktionen ausgeführt werden, die eigentlich nicht ausgeführt werden sollten. Das wiederum lässt sich vermeiden, indem am Anfang des INIT_Makros eine Variable "Programmstart" auf 1 gesetzt und ganz am Schluss auf 0 zurück gestellt wird. In den Makros der Fensterkontakte fügt man dann ganz oben ein VERLASSEN ein, wenn Programmstart = 1 ist

Wobei bei mir das 'Verlassen' im TFK-Makro dazu führte, daß der gesamte Init ('LESEWERTEDATEI') nicht mehr ausgeführt wurde.
Abhilfe: Ich habe den kompletten Makro im TFK in eine Wenn-Bedingung (wenn Programmstart = 1) eingeschlossen - dann ging es.

Aber jetzt noch einmal zum eigentlichen Thema, welches abs. nicht begründbar und nachvollziehbar ist.
Und noch einmal zum allgemeinen Verständnis: Bei meinen Tests wurde nur das Projekt beendet - HPCL, BidCos und Konsorten liefen weiter.

Nachfolgend ein paar Screenshots der Visuwin aus einer Testansicht, die auf die wesentlichen Komponenten reduziert wurde.
DGK steht für HM-Sec-RHS Funk-Fenster-Drehgriffkontakt
TFK steht für HM-Sec-Sc Funk-Tür-Fensterkontakt
SK3 steht für HM-SCI-3-FM Schließerkontakt-Interface
Und die Anzeigen sind eine HM-OU-LED16 Statusanzeige.

Da ich es nicht hinbekomme, die Pics in den Text zu integrieren - in der Reihenfolge:
Edit - irgendwie stmmt die Reihenfolge der Uploads nicht
Nach erneutem Projektstart
Vor Projekt beenden
90 Sekunden nach Projektstart
und 30 Sekunden nach Projektstart

Die 'Wartezeit' im INIT-Makro habe ich auf 2 Minuten gestellt.

Wie man erkennen kann:
Nach dem Start ist alles außer dem SK3_2 korrekt.
30 Sekunden nach dem Start ist Alles korrekt.
90 Sekunden nach dem Start sind die SK3s, DGKs und die korrespondierenden LED korrekt - Alle TFKs und dazu korrespondierenden LEDs sind falsch.

Soweit ich das bisher in meinen Versuchen beobachten konnte:
Die HM-Sec-Sc Funk-Tür-Fensterkontakt werden immer falsch gesetzt.
Bei den HM-SCI-3-FM Schließerkontakt-Interfaces und HM-Sec-Sc Funk-Tür-Fensterkontakt ist es willkürlich - mal ist alles korrekt, dann stimmt einer und beim nächsten Start u. U. keiner.

Noch paradoxer wird es, wenn zusätzlich zum Projekt auch noch HPCL beendet wird.......

Sorry, aber von dem vielbepriesenen Funk-'BidCos' hatte ich doch mehr erwartet und da kann mir niemand beibringen wollen, daß dies keine Bugs sind.