HmIP-DRSI4 manuelle Bedingung Rückmeldung

[GeMa]

Für das Schalten verschiedener Verbraucher habe ich mir zwei DRSI4 geleistet und in zwei verschieden Schaltschränke eingebaut. Die Stabilität der Funkverbindung ist durchaus zufriedenstellend trotz der Blechkästen (5 Meter +24 Kalksandsteinwand + 2mal 12 Porenbeton + Verteilerkasten Blech).
Die Funktionen (Direktschaltung der Kanäle über CCU oder eine APP als auch Direktkopplungen mit WTH2) funktionieren.

Jetzt wollte ich noch die "Notfallbedienung" dokumentieren und bin auf einen verblüffenden Effekt gestoßen. Bei Schaltungen direkt am DRSI4 - die funktionieren - aber die CCU bekommt das nicht mit. Dort kann man den den Kanal immer noch mal ausschalten bzw. anschalten.
Mein DRSI4 - alle internen Direktverknüpfungen sind gelöscht und die Eingänge stehen auf Kontakt, die Statusmitteilung Schaltausgang steht auf 500/300 ms.
Ich bin etwas ratlos, alle Experimente führten zu keinem Ergebnis - inzwischen vermute ich einen BUG.

[Baxxy]

Bei Schaltungen direkt am DRSI4 - die funktionieren - aber die CCU bekommt das nicht mit.

Ist mir bei der Installation und lokalem Test auch aufgefallen.
Fand das auch "unschön" das der Aktor lokal eingeschaltet werden kann und man auf der Zentrale davon nichts mitbekommt.
Ist ja auch völlig unklar wie das intern abläuft. Wird da einer der 3 virtuellen Kanäle geschaltet oder direkt der Ausgang...

Die Fragen müsste man wohl direkt an eQ-3 richten.

[Roland M.]

Hallo!

Wird da einer der 3 virtuellen Kanäle geschaltet oder direkt der Ausgang...

Da wird offensichtlich der Ausgang direkt geschaltet und ja, unschön, wenn nicht einmal der Statuskanal aktualisiert wird.
Ich sehe aber auch keinen wirklich sinnvollen Einsatz dieser Schaltmöglichkeit, außer für den Elektriker zum Funktionstest.
Und als "Notfallbedienung" muss man sich über dieses Verhalten eben im Klaren sein.


Roland

[Baxxy]

Da wird offensichtlich der Ausgang direkt geschaltet

Naja, so offensichtlich ist das nicht... man hat ja kein Feedback.
Ich würde eher vermuten das diese Taste den 1. virtuellen Kanal bedient. So wie z.B. bei ner PSM mit der Systemtaste die ja per default auch mit dem 1.virt. Kanal verknüpft ist.
Das könnte man testen indem man mal die Verknüpfungslogik auf AND stellt so das ein virt. Kanal nicht reicht um den Ausgang zu aktivieren.
Mein DRSI4 ist aktuell physisch unerreichbar, also aktuell keine Chance für Test's.

Bin aber auch der Meinung das bei lokaler Bedienung (so unsinnig die auch sein mag) eine Rückmeldung an die Zentrale erfolgen sollte.

Grüße, Baxxy

[Roland M.]

Hallo!

man hat ja kein Feedback.

Ich weiß jetzt nicht, was ich sagen soll, seit wann, wieso, warum, aber die lokale Bedienung schaltet jetzt den ersten virtuellen Kanal und das wird in der WebUI auch so angezeigt!

Nachdem ich mich an kein FW-Update des Aktors erinnern kann, muss das in einer CCU-FW behoben worden sein.

CCU-FW: Raspberrymatic 3.61.7.20220115
Geräte-FW: 1.4.2

Die Darstellung in der WebUI ist da um einiges umfangreicher, als ich es in Erinnerung habe...

Früher konnte man den Aktor einschalten, WebUI waren alle VK aus, einen beliebigen (!) VK ein und wieder aus und man war wieder synchron.

Bin aber auch der Meinung das bei lokaler Bedienung (so unsinnig die auch sein mag) eine Rückmeldung an die Zentrale erfolgen sollte.

Ja, das sehe ich auch so. Aber wenn es nun ohnehin angezeigt wird...


Roland

[Roland M.]

Nachtrag:

Jetzt gibt es dafür wieder einen anderen Schönheitsfehler, der gerade bei der "Notbedienung" zum Tragen komme: es wird wirklich nur der erste virtuelle Kanal geschaltet. Wenn man aber einen der anderen VK eingeschaltet hat, ist die lokale Bedienung wirkungslos...


Roland

[Roland M.]

2. Nachtrag:

Wenn man etwas genauer schaut:

drsi4-2.png (17.54 KiB) 377 mal betrachtet

Aktuelle Betriebsspannung: 0.0 V
Betriebsspannung in V: 0.0 V
Status Betriebsspannung: normal


Roland

[Baxxy]

Interessant!

Ich hatte DRSI4 und DRSI1 im letzten Oktober eingebaut und mich da noch gewundert das bei lokaler Bedienung eben keine Rückmeldung in der Zentrale zu sehen war.
Da auch ne RaspberryMatic passend zu dem Zeitraum läuft (Nightly-3.59.6.20211019) könnte ich beim nächsten Besuch die Sache nochmal begutachten.

Auf jeden Fall schön zu lesen das sich da was getan hat.

einen anderen Schönheitsfehler, der gerade bei der "Notbedienung" zum Tragen komme

Das ist natürlich ein Zweischneidiges Schwert. Wenn ich es richtig lese wird sich also an die Verknüpfungsregeln gehalten.
Demzufolge kann man auch aus Versehen oder mit Absicht eine lokale Bediensperre etablieren.

Die Darstellung in der WebUI ist da um einiges umfangreicher, als ich es in Erinnerung habe...

Ist das orig. CCUx?
Hmm, 2 Doppelungen "(Aktuelle) Betriebsspannung" [OPERATING_VOLTAGE] und "Status Betriebsspannung" [OPERATING_VOLTAGE_STATUS]
Dafür fehlt theoretisch [ERROR_POWER_FAILURE].

Wenn ich mein System dann irgendwann mal update muss ich mal gucken wie das bei RM nun aussieht.

Grüße, Baxxy

[Roland M.]

Hallo!

Demzufolge kann man auch aus Versehen oder mit Absicht eine lokale Bediensperre etablieren.

Ja, durch die Verknüpfungsregel ((A o B) o C) lege ich die manuelle Bedienung immer auf den 3. Kanal mit der höchsten Priorität. Schalten am ersten Kanal würde mir dann eine Zeitsteuerung oder An-/Abwesenheit über den Haufen werfen... Nachdem ich für den geplanten Einbau ohnehin noch zwei Eingänge frei habe, werde ich vielleicht noch Hutschienentaster einplanen.

Ist das orig. CCUx?

Nein, wie oben schon geschrieben aktuelle (stable) Raspberrymatic.


Roland

[Baxxy]

wie oben schon geschrieben

hab ich doch glatt überlesen...

Hutschienentaster einplanen

Gar keine schlechte Idee, werde ich mal im Hinterkopf behalten. Da gibt's ja auch welche mit 0,5TE, die machen sich dann nicht ganz so breit im Verteiler.

Grüße, Baxxy