Logik von virtuellen Kanälen

HMIP lokale Installation

Moderator: Co-Administratoren

Bricoleur
Beiträge: 3
Registriert: 16.01.2020, 19:00

Logik von virtuellen Kanälen

Beitrag von Bricoleur » 16.01.2020, 19:09

Guten Tag,
ich habe erst kürzlich mit Homematic begonnen, habe aber schon einige Programme und Scripte auf der CCU3 und auch Direktverknüpfungen erfolgreich zum Laufen gebracht.
Jetzt habe ich aber ein Problem mit der logischen Verknüpfung der virtuellen Kanäle. Trotz Lesens der Beiträge hier im Forum (Darstellung als Logik-Gatter), der verfügbaren Anleitungen und Ansehens der diversen Videos von den Usertreffen arbeiten die Verknüpfungen nicht so, wie ich danach meinte, dass sie arbeiten sollten.
Die Aufgabe, die ich per Direktverknüpfungen lösen möchte: Das Außenlicht soll eingeschaltet werden, wenn die Helligkeit unterhalb eines Schwellwertes liegt und bei Überschreiten des Wertes wieder ausgeschaltet werden. Allerdings soll das Licht in der Zeit von (frühestens) 16h bis 22h dauerhaft eingeschaltet sein. In der übrigen Zeit soll das Licht nur für 2 min bei erkannter Bewegung durch den Bewegungsmelder eingeschaltet werden. Eingesetzte Geräte: HMIP-PS; HMIP-SWO-B (Helligkeitswert), HMIP-SMO (Bewegungsmelder).
Bei der HMIP-PS ist der ausführende Hauptkanal der Kanal 3 (Wurde mir auf Nachfrage vom EQ-3-Support bestätigt.). Daher habe ich die Direktverknüpfung mit dem HMIP-SWO-B (Helligkeit) auf Kanal 3 gelegt und diesen mit AND verknüpft. Die Direktverknüpfungen mit dem HMIP-SMO und mit dem Zeitprogramm von der CCU liegen auf Kanal 4 und 5, die jeweils OR verknüpft sind.
Nach meinem Verständnis sollte jetzt das Licht wie gewünscht erst angehen, wenn auf Kanal 3 beide Eingangswerte EIN sind. Leider aber schaltet das Zeitprogramm um 16.00h das Licht ein, obwohl sowohl der Bewegungsmelder als auch der Helligkeitswert auf AUS stehen. Ich habe das mal mit CCU-Historian protokolliert (siehe Bild): Das Licht wird vom HMIP-PS zum Zeitpunkt A eingeschaltet, obwohl es nach meinem Verständnis erst zum Zeitpunkt B geschaltet werden sollte.
Wo ist mein Denkfehler?? Was muss ich ändern?
HM Verknüfung1.png
Zuletzt geändert von alchy am 19.01.2020, 19:32, insgesamt 1-mal geändert.
Grund: verschoben aus HomeMatic IP Aktoren und Sensoren

Benutzeravatar
Sammy
Beiträge: 9172
Registriert: 09.09.2008, 20:47
Hat sich bedankt: 15 Mal
Danksagung erhalten: 174 Mal

Re: Logik von virtuellen Kanälen

Beitrag von Sammy » 17.01.2020, 08:41

Hallo,

es gibt keinen "ausführenden Hauptkanal".
Das Einstellen von AND bei Kanal 3 ist absoluter Unfug. Gemäß der Doku wird nämlich "0" AND Kanal 3 gebildet, was IMMER "0" ergibt.
Das Ergebnis DAVON (also "0") hast Du "OR" verknüpft mit Kanal 4, was also als Ergebnis den Wert von Kanal 4 hat.
Diese Ergebnis ist wieder OR verknüpft mit Kanal 5.

Richtig wäre gewesen ein AND zwischen Kanal 3 und 4 (was man bei Kanal 4 konfiguriert) und ein OR mit Kanal 5 (Zeitsteuerung)

Gruß Sammy
Links: CCU-Logik, Tipps für Anfänger, WebUI-Doku, Expertenparameter, virtuelle Aktorkanäle
Inventur vom 22.01.14: 516 Kanäle in 165 Geräten, 132 Programme, 270 Direkte Verknüpfungen
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

Bricoleur
Beiträge: 3
Registriert: 16.01.2020, 19:00

Re: Logik von virtuellen Kanälen

Beitrag von Bricoleur » 17.01.2020, 10:18

Danke Sammy,

für die schnelle Antwort. Ich werde die Logik dann so umstellen.

Mein Problem war ja, dass ich nicht sicher war, in welcher Folge die Kanäle verknüpft sind.

Und die Antwort vom eq-3-Support auf meine diesbezügliche Frage sah so aus:

"Bei der HMIP-PS ist der ausführende Hauptkanal der Kanal 3.
Dieser sollte in Programmen oder direkten Verknüpfungen genutzt werden.
Die Kanäle 4 und 5 sind ebenfalls Aktorkanäle, jedoch nur virtuell und können über die Systemeinstellung mit dem Aktorkanal 3 logisch verknüpft werden."

Daher auch meine Formulierung "ausführender Hauptkanal".

Benutzeravatar
Roland M.
Beiträge: 9787
Registriert: 08.12.2012, 15:53
System: CCU
Wohnort: Graz, Österreich
Hat sich bedankt: 252 Mal
Danksagung erhalten: 1374 Mal

Re: Logik von virtuellen Kanälen

Beitrag von Roland M. » 17.01.2020, 11:09

Hallo!
Bricoleur hat geschrieben:
17.01.2020, 10:18
Mein Problem war ja, dass ich nicht sicher war, in welcher Folge die Kanäle verknüpft sind.
Die Frage hätte leicht über die angebotene Hilfe beantwortet werden können:


------------------------------------
Der Kanalzustand wird durch eine Verknüpfung der virtuellen Kanäle mit dem Realkanal nach folgender Regel bestimmt:

Ausgangspegel = (((0 o A) o B) o C)

Es gilt dabei folgende Definition:

A = Zustand des ersten virtuellen Kanals
B = Zustand des zweiten virtuellen Kanals
C = Zustand des dritten virtuellen Kanals

o = Verknüpfungsregel des dazugehörigen Kanals
Klammern werden von innen nach aussen abgearbeitet.

Bedeutung der einzelnen Verknüpfungsregeln:
Kanal inaktiv: Der Kanal wird bei der Verknüpfung ignoriert.
OR: Das Verknüpfungsergebnis ist EIN, wenn mindestens ein Kanal EIN ist.
AND: Das Verknüpfungsergebnis ist EIN, wenn beide Kanäle EIN sind.
XOR: Das Verknüpfungsergebnis ist EIN, wenn nur genau ein Kanal EIN ist.
NOR: Das Verknüpfungsergebnis ist EIN, wenn beide Kanäle AUS sind.
NAND: Das Verknüpfungsergebnis ist EIN, wenn mindestens ein Kanal AUS ist.
OR_INVERS: Der Zustand des zu verknüpfenden Kanals (rechts vom 'o') wird zuerst invertiert und anschließend die Verknüpfung OR ausgeführt.
AND_INVERS: Der Zustand des zu verknüpfenden Kanals (rechts vom 'o') wird zuerst invertiert und anschließend die Verknüpfung AND ausgeführt.
Beispiel:
A = EIN, B = AUS, C = EIN

Verknüpfung: (((AUS OR A) NOR B) AND_INVERS C)

AUS OR A = EIN
EIN NOR B = AUS
AUS AND_INVERS C = AUS

Der Zustand Aktors ist AUS

------------------------------------

Die Aussage vom eQ-3-Support ist etwas ungeschickt. Jeder der drei virtuellen Kanäle ist gleichberechtigt - durch die Verknüpfungsregel (((0 o A) o B) o C) hat der dritte Kanal sogar die höchste Priorität!


Roland
Zur leichteren Hilfestellung bitte unbedingt beachten:
  • Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
  • Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
  • Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
  • Fehlermeldungen genau abschreiben, besser noch...
  • Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!

-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...

frd030
Beiträge: 3613
Registriert: 14.07.2019, 20:49
System: CCU
Hat sich bedankt: 844 Mal
Danksagung erhalten: 539 Mal

Re: Logik von virtuellen Kanälen

Beitrag von frd030 » 17.01.2020, 11:43

Roland M. hat geschrieben:
17.01.2020, 11:09
Die Aussage vom eQ-3-Support ist etwas ungeschickt. Jeder der drei virtuellen Kanäle ist gleichberechtigt - durch die Verknüpfungsregel (((0 o A) o B) o C) hat der dritte Kanal sogar die höchste Priorität!
Dem ersten Satz stimme ich zu. Der zweite widerspricht sich aber ein wenig in sich selbst: da der dritte Kanal (hinsichtlich der Verknüpfung) Priorität hat, dann sind die Kanäle eben nicht gleichberechtigt. Die Reihenfolge der Auswertung ist entscheidend: zuerst wird der erste Kanal mit "0" verknüpft, dann der zweite mit dem Ergebnis und dann der Dritte wiederum mit diesem Ergebnis. Die Verknüpfung geschieht eben in genau dieser Reihenfolge!

Bricoleur
Beiträge: 3
Registriert: 16.01.2020, 19:00

Re: Logik von virtuellen Kanälen

Beitrag von Bricoleur » 17.01.2020, 13:45

@Roland
Den Hilfetext hatte ich gelesen, aber mir war nicht klar, wie die Bezeichnungen A,B,C mit den Nummern der (virtuellen) Kanäle korrelieren. Sind die Kanäle einfach in aufsteigender Reihenfolge der Kanalnummern verknüpft oder hat Kanal 3 eine Sonderstellung als "ausführender" Kanal? In der Folie 5 (Kanalstruktur eines Aktors) des Vortrags von Frank Graß beim User Treffen in Kassel sind die virtuellen Kanäle bei HMIP-Aktoren in dem Beispiel mit 4-6 bezeichnet und sie wirken auf einen Ausgangskanal 3. Das zusammen mit der oben von mir zitierten Antwort von eq-3 hat mich verwirrt.

Nach den Antworten hier und ein bisschen experimentieren mit dem Zusand des Ausgangs des HMIP-PS bei verschiedenen Zuständen der Kamäle und deren unterschiedlichen logischen Verknüpfungen habe ich hoffentlich das Thema verstanden:
Die Kanäle sind in aufsteigender Reihenfolge ihrer Nummern (3-4-5) verknüpft, wobei Kanal 3 der unterste ist, an dessen einem Eingang immer logisch 0 liegt.

Danke für die Hilfe.

Benutzeravatar
Sammy
Beiträge: 9172
Registriert: 09.09.2008, 20:47
Hat sich bedankt: 15 Mal
Danksagung erhalten: 174 Mal

Re: Logik von virtuellen Kanälen

Beitrag von Sammy » 17.01.2020, 13:52

In der Folie 5 wird als Beipiel ein Markenschalter-Aktor herangezogen, der 2 Taster hat.
0 = Gerät
1, 2 = Tasten
3 = Relais / Realkanal
4, 5, 6 virtuelle Aktorkanäle (4 = A, 5 = B, 6 = C)
Links: CCU-Logik, Tipps für Anfänger, WebUI-Doku, Expertenparameter, virtuelle Aktorkanäle
Inventur vom 22.01.14: 516 Kanäle in 165 Geräten, 132 Programme, 270 Direkte Verknüpfungen
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

dtp
Beiträge: 10658
Registriert: 21.09.2012, 08:09
System: CCU
Wohnort: Stuttgart
Hat sich bedankt: 320 Mal
Danksagung erhalten: 501 Mal

Re: Logik von virtuellen Kanälen

Beitrag von dtp » 26.04.2020, 11:06

Hat man eine Chance, mittels der virtuellen Kanäle die Tastenfunktion der Tasterkanäle unverändert zu belassen (also z.B. das Hoch- und Runterfahren), aber die ausgegebenen Istwerte zu invertieren? Also, dass hochgefahren 0 % und das runtergefahren 100 % entspricht?

Ich frage das mit dem Hintergrund einer Markisensteuerung über einen HmIP-BROLL, bei dem mir die vorgegebenen Werte des Aktors nicht unbedingt logisch erscheinen.

Derzeit behelfe ich mir damit, den Motor am Aktor zu verpolen und den Aktor entsprechend über Kopf einzubauen. Aber so richtig gefallen tut mir das nicht. Ich hätte den Aktor lieber so angeschlossen und eingebaut, wie die Beschriftung es vorgibt, und intern das Verhalten entsprechend umprogrammiert.
CCU3 mit stets aktueller FW und den Addons "CUxD" und "Programmedrucken", ioBroker auf Synology DiskStation DS718+ im Docker-Container;
einige Projekte: zentrales Push-Nachrichten-Programm zPNP, DoorPi-Videotürsprechanlage, An- und Abwesenheitsdetektion per Haustürschloss, zentrales Programm zur Steuerung von Beschattungsgeräten zBSP.

Matsch
Beiträge: 5427
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 114 Mal
Danksagung erhalten: 734 Mal

Re: Logik von virtuellen Kanälen

Beitrag von Matsch » 26.04.2020, 12:38

Eigentlich stören die "vertauschten" Richtungen doch nur auf einer Anzeige des Istzustands (Monitor). Wenn man dazu eine App benutzt, kann man doch in der App (oder vorher in der CCU) die Werte einfach konvertieren. Dann stehen die Werte in der Anzeige genau andersrum als im Aktor. Du wirst doch nicht die WebUI als Anzeige benutzen?
Mache ich bei Rollläden so (weil mir die Definition in IP-App/AP mit 0% = offen, 100% = geschlossen logischer ist als im Aktor definiert).

Pihero
Beiträge: 238
Registriert: 02.08.2019, 21:24
Wohnort: Pforzheim
Hat sich bedankt: 1 Mal
Danksagung erhalten: 3 Mal

Re: Logik von virtuellen Kanälen

Beitrag von Pihero » 17.12.2020, 14:59

Servus,

ich hab da auch ein Thema.

Wir haben ein Wohnzimmer in das ich über eine Treppe gelange. Die Brüstung der Treppe hat einen LED-Streifen am DRD3.

Folgendes Ziel:

Ich komme die Treppe hoch und der LED-Streifen macht 80% Pegel über -SPI. Falls ich nur was hole geht das Ding dann wieder aus (Treppenhauslicht).

Bleibe ich dort betätige ich einen Taster der den gleichen LED-Streifen auf 25% setzt (dimmen nach oben soll möglich sein).

Problem: das funktioniert so nicht da ich zwei Kanäle verwende und diese mit AND verknüpfen müsste um den 25% Pegel bei eingeschaltetem Treppenhauslicht zu bekommen.
Nehme ich allerdings das AND funktioniert das Treppenhauslicht nie da der zweite Kanal mit 0 (bei ausgeschalteter Ambientebeleuchtung) dann Priorität
hat.

Zudem sollte sich natürlich das Ambientelicht nicht mehr verändern wenn ich wieder durch den BWM laufe...

Ich hab grad auf mehreren Seiten Papier verschiedenste logische Verknüpfungen zusammenkombiniert aber erhalte nie den gewünschten Effekt. Hat jemand eine Idee das mit DV's umzusetzen?

Ich würd mir wünschen das einer der Kanäle einfach unabhängig vom Pegel als Priorität gesetzt werden könnte.

Vielen Dank schonmal für die Unterstützung bei der Denksportaufgabe.
Gruß, Philipp

Antworten

Zurück zu „HomeMatic IP mit CCU“