KNX/EIB SA/S 8.16.6.1 -> Stromschwelle mit PM verbinden.

[Basti]

Als erstes mal Sorry für den nicht wirklich aussagefähigen Titel, mir ist ncihts passenderes eingefallen.

Also, als erstes mal die Problemstellung:

Im Wohnzimmer hab ich einen Merten Argus 630919, der meine Frau leider nicht immer erkennt, wenn sie auf der Couch surft oder entspannt TV schaut. Trotz einer Treppenhauszeit von 25 Minuten (was mir eh eigentlich zu lang ist) schaltet er dementsprechend ab. Sie muss dann mit den Armen winken, damit er das Licht wieder an macht.
Da ich den TV an einem SA/S 8.16.6.1 hab wollte ich nun den Schaltausgang vom Stromschwellwert zyklisch senden lassen und mit dem Triggereingang des Merten verbinden. (Den Sperreingang kan ich nicht verwenden, da ich den schon für diverse andere Dinge benutze und er beim Sperren das Licht aus macht).

Leider kann der SA/S nur den Stromwert zyklisch senden, nicht aber das Bit vom Schwellwert.

Habt ihr ne Idee, wie ich das Problem angehen kann, da meine Frau langsam genervt ist. (eibPC hab ich zwar, ist aber noch jungfräulich in seiner Verpackung und sollte da auch nciht raus, bis ich erstmal das grundgerüst an Funktionen umgesetzt habe... kann mich im Moment nicht an noch eine Baustelle dran machen *g*)

[enertegus]

ALeider kann der SA/S nur den Stromwert zyklisch senden, nicht aber das Bit vom Schwellwert.
Habt ihr ne Idee, wie ich das Problem angehen kann, da meine Frau langsam genervt ist. (eibPC hab ich zwar, ist aber noch jungfräulich in seiner Verpackung

Raus aus der Verpackung damit und dann !!!!!!!!

[bmx]

Moin Basti,

Michael hat recht. EibPC anklemmen und los geht's:

[highlight=epc]
[EibPC]
if event( SchwellwertGA ) then {
write( MertenTriggereingang, SchwellwertGA > StromBeiTVan );
}endif
[/highlight]

So wird bei jedem Telegramm der Stromerkennung ein Triggertelegramm für den Merten generiert.

Gruß,
Bernd

PS: Bitte die Telegrammrate Deines Aktors begrenzen.

[Basti]

Ja, warscheinlich habt ihr recht... irgendwann muss ich ja dran. Gibts aktuell ne Empfehlung welche IP-Schnittstelle man nehmen soll?

[bmx]

Wenn Du nicht zufällig noch 'ne RS232 FT1.2 rumliegen hast würde ich vermutlich auf die IP-Schnittsteller von enertex warten. Ich habe derzeit ABB IP/R 2.1 Router und Siemens IP-Schnittstelle im Einsatz.

Gruß,
Bernd

[Basti]

Wenn Du nicht zufällig noch 'ne RS232 FT1.2 rumliegen hast würde ich vermutlich auf die IP-Schnittsteller von enertex warten.

Gibts da schon nen Termin und nen ca. Preis?

[enertegus]

Gibts da schon nen Termin und nen ca. Preis?

Q1/2012, ca. 260 €.

[Patholog]

Hallo Basti,

natürlich ist das mit der zentralen Programmierung wie EibPC am leichtesten, es ist auch ausbaufähig und flexibel. Aber:

1. ich bin ein Freund davon, zunächst die Basics dezentral zu programmieren. Kostet meistens etwas mehr Hirnschmalz, ist aber noch sicherer als nur zentral.

2. Zyklisches Senden ist meistens gar nicht notwendig. Event-basierte Programmierung (wenn sich was ändert, passiert was auf dem Bus mit entsprechenden Reaktionen) passt besser zu KNX. In deinem Fall sowohl bezüglich PM als auch Stromerkennung.

3. Ich habe selbst mehrere Merten Argus (z.T. eingebunden in komplexe dezentrale Logiken) und musste noch nie den Sperreingang verwenden. Intuitiv muss es da bessere Lösungen (Logiken) geben, als den PM zu sperren (= "lahmzulegen"). Vielleicht brauchst du die Information dieses PM's ja noch an ganz anderer Stelle deines Hauses.

4. Die Stromerkennung löst wahrscheinlich nur ein Teil deines Problems und hat weitere Konsequenzen. Solange der TV an ist, wird das Licht nicht ausgehen, ob man anwesend ist oder nicht. Außerdem wird das Surfen nicht erkannt, falls ein Laptop mitr Akku benutzt wird. Und wie ist es mit dem gemütlichen Lesen eines Buchs auf der Couch?

5. Vor der Umsetzung mit der Stromerkennung sollte deshalb die Physik und Programmierung des PM ausgereizt werden. Unmittelbar über der Couch wäre natürlich der beste Platz. Ich gehe davon aus, dass du den PM auf die beste Erkennungsrate parametriert hast (Empfindlichkeit, Radius). Vielleicht gibt es noch ein anderes Sensorprinzip, um Anwesenheit auf der Couch festzustellen (z.B. über Druck/Gewicht)?

6. Unabhängig von den letzten obigen Punkten könnte dein Problem am Aktor mit einer ODER-Logik realisiert werden: auf das Schaltobjekt des Aktorausgangs für die Lichtschaltung sendet der PM, wenn eine Anwesenheit registriert wird (nicht zyklisch), auf das ODER-Objekt dieses Aktorausgangs sendet der Aktorausgang, der mit dem TV verbunden ist, einen 0/1-Wert, wenn der Strom eine Schwelle unter/überschreitet. So ist gewährleistet, dass der Aktorausgang für das Licht geschlossen ist (Licht an), solange entweder der PM Präsenz gemeldet hat (eine 1 gesendet hat), oder der TV läuft. Wenn der TV an ist und der PM keine Anwesenheit mehr registriert, dann sendet der PM nach einer Treppenlichtzeit (5 Minuten sind da aber ausreichend) eine 0. Das Licht bleibt trotzdem an. War der TV auch aus, als der PM eine 0 für "nicht anwesend" gesendet hatte, dann geht das Licht aber wirklich aus (siehe dazu Punkt 4).

Trotzdem viel Spaß mit dem EibPC, du wirst ihn sicherlich noch gut brauchen.

Gruß

Harald

[Basti]

Hallo Basti,

1. ich bin ein Freund davon, zunächst die Basics dezentral zu programmieren. Kostet meistens etwas mehr Hirnschmalz, ist aber noch sicherer als nur zentral.

Hallo Harald,
als Erstes mal vielen Dank für deine ausführliche Antwort. Ich werd mal zu Allen Punkten einzeln Antworten, das ist übersichtlicher

Seh ich ganz genau so, deswegen liegt der EibPC ja eigentlich noch in seiner Box, grundsätzlich wollte ich erst alles "normal" in der ETS aufbauen und danach dann noch mittels Logikmaschine ein bissen optimieren und erweitern.

2. Zyklisches Senden ist meistens gar nicht notwendig. Event-basierte Programmierung (wenn sich was ändert, passiert was auf dem Bus mit entsprechenden Reaktionen) passt besser zu KNX. In deinem Fall sowohl bezüglich PM als auch Stromerkennung.

Ich sende fast nichts zyklisch, außer Statuswerte (Fenter, Türen, Helligkeiten) der PM sendet bei mir auch nicht zyklisch, lediglich der Slave-PM auf das Triggerobjekt, aber das muss laut Applikationshandbuch auch so sein.

3. Ich habe selbst mehrere Merten Argus (z.T. eingebunden in komplexe dezentrale Logiken) und musste noch nie den Sperreingang verwenden. Intuitiv muss es da bessere Lösungen (Logiken) geben, als den PM zu sperren (= "lahmzulegen"). Vielleicht brauchst du die Information dieses PM's ja noch an ganz anderer Stelle deines Hauses.

Die PMs zu sperren ist für mich einfach das Logischste, da ich sie nachts und bei Abwesenheit sperre um eine Lightshow durch die Haustiere zu vermeiden.
Dementsprechend hab ich es so parmetriert, dass die PMs beim Sperren schalten die Beleuchtung gleich mit ab, was ich sehr gut finde. Aber ich bin da für andere Lösungen offen.

4. Die Stromerkennung löst wahrscheinlich nur ein Teil deines Problems und hat weitere Konsequenzen. Solange der TV an ist, wird das Licht nicht ausgehen, ob man anwesend ist oder nicht. Außerdem wird das Surfen nicht erkannt, falls ein Laptop mitr Akku benutzt wird. Und wie ist es mit dem gemütlichen Lesen eines Buchs auf der Couch?

Ist zwar wahr, aber wenn wir im Wohnzimmer sind läuft der TV... IMMER... (und wenns nur als Hintergrundgedudel ist) außer wir haben Gäste, aber dann ist ebenfalls immer genug Bewegung, dass der PM anschlägt.

5. Vor der Umsetzung mit der Stromerkennung sollte deshalb die Physik und Programmierung des PM ausgereizt werden. Unmittelbar über der Couch wäre natürlich der beste Platz. Ich gehe davon aus, dass du den PM auf die beste Erkennungsrate parametriert hast (Empfindlichkeit, Radius). Vielleicht gibt es noch ein anderes Sensorprinzip, um Anwesenheit auf der Couch festzustellen (z.B. über Druck/Gewicht)?

Der PM hängt ca. 1,5m von unserer Sitzposition entfernt und ist auf volle Reichweite eingestellt. Wenn ich ehrlich bin verstehe ich auch nciht wirklich, warum er da so Probleme hat. Ok, die FB-Heizung ist an und auch recht warm, aber ich hatte mir da schon mehr erwartet.
Für andere Sensoren müsste ich halt erst mal ein Buskabel in der Nähe haben, oder eine Funklösung nehmen, was ich eigentlich nicht möchte.

6. Unabhängig von den letzten obigen Punkten könnte dein Problem am Aktor mit einer ODER-Logik realisiert werden: auf das Schaltobjekt des Aktorausgangs für die Lichtschaltung sendet der PM, wenn eine Anwesenheit registriert wird (nicht zyklisch), auf das ODER-Objekt dieses Aktorausgangs sendet der Aktorausgang, der mit dem TV verbunden ist, einen 0/1-Wert, wenn der Strom eine Schwelle unter/überschreitet. So ist gewährleistet, dass der Aktorausgang für das Licht geschlossen ist (Licht an), solange entweder der PM Präsenz gemeldet hat (eine 1 gesendet hat), oder der TV läuft. Wenn der TV an ist und der PM keine Anwesenheit mehr registriert, dann sendet der PM nach einer Treppenlichtzeit (5 Minuten sind da aber ausreichend) eine 0. Das Licht bleibt trotzdem an. War der TV auch aus, als der PM eine 0 für "nicht anwesend" gesendet hatte, dann geht das Licht aber wirklich aus (siehe dazu Punkt 4).

Das klingt doch schon vielversprechend, allerdings wird es da wohl ein Problem, dass der PM kein Bit sendet, sonder direkt eine Szene, oder? Oder kann ich mit einer "normalen" Logik auch sowas machen wie wenn (E1 oder E2) = 1 dann sende Szene x (oder auch Byte) und wenn 0 dann Szene y.

?

Trotzdem viel Spaß mit dem EibPC, du wirst ihn sicherlich noch gut brauchen.

Gruß

Harald

Das glaub ich auch *g* Vielen Dank für die Hilfe!

[Patholog]

Hallo Basti,

Ich sende fast nichts zyklisch, außer Statuswerte (Fenter, Türen, Helligkeiten)

Warum bei Statuswerten? Wenn das Fenster offen ist, wird "offen" eingeloggt (z.B. eine 1 für true). Erst wenn das Fenster wieder geschlossen wird, wird "geschlossen" eingeloggt (im Beispiel eine 0 für false). Zyklisches Abfragen dazwischen ist eine Spielerei. Der Binäreingang fragt ständig zyklisch (sauschnell, ohne Bus-Aktivität) den Status ab. Nur bei einer Änderung lasse ich den Binäreingang auf den BUS senden und damit eine Statusänderung kommunizieren. Das ist meiner Meinung nach sauberer.

Die PMs zu sperren ist für mich einfach das Logischste, da ich sie nachts und bei Abwesenheit sperre um eine Lightshow durch die Haustiere zu vermeiden.

Ich mache sowas eben durch eine Logik, z.B. PM sendet 1 UND Tag-GA ist 1, dann ... (statt Tag auch Anwesenheit im Haus oder eine Kombination von beiden oder...).

Der PM hängt ca. 1,5m von unserer Sitzposition entfernt und ist auf volle Reichweite eingestellt.

.
Na, das sollte aber wirklich klappen. Die FBH ist nur ein marginales Problem. Schwieriger wird es, wenn ein Leuchtmittel mit viel Wärmeabstrahlung ("Glühlampe") in der Nähe hängt. Auch dann kann man dem Merten helfen.

Das klingt doch schon vielversprechend, allerdings wird es da wohl ein Problem, dass der PM kein Bit sendet, sonder direkt eine Szene, oder? Oder kann ich mit einer "normalen" Logik auch sowas machen wie wenn (E1 oder E2) = 1 dann sende Szene x (oder auch Byte) und wenn 0 dann Szene y.

Aber sicher sendet der PM auch ein Bit oder Vieles andere (natürlich ist auch ein Byte mit einer Szenennummer möglich)! Unter "Telegramme" kann man das wunderbar parametrieren mit Möglichkeiten bis zum Abwinken! Poste doch mal deine Einstellungen und deine genauen Anforderungen/Wünsche. Mit dem Argus kann man manchmal richtig "zaubern".
Und eine Frage: wo hängt der Slave? Vielleicht ist in der Konfiguration Master/Slave-PM der Hund begraben!

Ich habe mit meinen Argus von Merten und ein paar Aktor-Logiken richtig komplexe Dinge gebaut, noch bevor das Wiregate mit seinen Plugin-Möglichkeiten mich beglückt hat.

Harald

[Basti]

Warum bei Statuswerten? Wenn das Fenster offen ist, wird "offen" eingeloggt (z.B. eine 1 für true). Erst wenn das Fenster wieder geschlossen wird, wird "geschlossen" eingeloggt (im Beispiel eine 0 für false). Zyklisches Abfragen dazwischen ist eine Spielerei. Der Binäreingang fragt ständig zyklisch (sauschnell, ohne Bus-Aktivität) den Status ab. Nur bei einer Änderung lasse ich den Binäreingang auf den BUS senden und damit eine Statusänderung kommunizieren. Das ist meiner Meinung nach sauberer.

Hmmm, gute Frage, eigentlich einfach nur, weil ich es sehr praktisch finde mir nach einem BUS-Reset (was im Moment noch gelegentlich vorkommt, da wir noch am Bauen sind) keinen Kopf machen zu müssen, dass die ganzen Status richtig auf dem Bus sind, aber eigentlich hast du recht. Außerdem wollte ich später einfach ne Fehlermeldung raus werfen, wenn von den Sachen mal nix mehr kommt.

Na, das sollte aber wirklich klappen. Die FBH ist nur ein marginales Problem. Schwieriger wird es, wenn ein Leuchtmittel mit viel Wärmeabstrahlung ("Glühlampe") in der Nähe hängt. Auch dann kann man dem Merten helfen.

Nein, eigentlich nicht, das Problem dürfte aus vielen einzel Faktoren zusammengebaut sein. Die FBH, die Form und Lage der Couch, die "Liegeposition meiner Frau",... An Beleuchtung ist eigentlich nix in der Nähe und wenn dann nur Deckenspots, die er eigentlich nicht sehen sollte.

Aber sicher sendet der PM auch ein Bit oder Vieles andere (natürlich ist auch ein Byte mit einer Szenennummer möglich)! Unter "Telegramme" kann man das wunderbar parametrieren mit Möglichkeiten bis zum Abwinken! Poste doch mal deine Einstellungen und deine genauen Anforderungen/Wünsche. Mit dem Argus kann man manchmal richtig "zaubern".

Klar, da hast du mich falsch verstanden... im Moment sendet er bei an ein Byte (Szenennummer) und bei Aus eine andere Szenennummer. Meine Frage war eher, wie ich das mit der Logik verwurschtel, ob das ODER dann auch eine Szenennummer senden kann, oder nur ein Bit.

Und eine Frage: wo hängt der Slave? Vielleicht ist in der Konfiguration Master/Slave-PM der Hund begraben!

Das Problem ist auch schon aufgetreten, als der Slave noch nicht da war, der ist an einer komplett anderen Stelle und kann auch nicht auf die Couch sehen. Im Busmonitor kann ich da aber auch keine Probleme erkennen (Dachte erst, dass evt. der Slave abschaltet, weil der nix mehr sieht, aber das passiert nicht.)

Ich hab allerdings nicht viele Aktoren die Logik enthalten, um nicht zu sagen eigentlich ist der SA/S und der Merten fast alles :-(

[Patholog]

Klar, da hast du mich falsch verstanden... im Moment sendet er bei an ein Byte (Szenennummer) und bei Aus eine andere Szenennummer. Meine Frage war eher, wie ich das mit der Logik verwurschtel, ob das ODER dann auch eine Szenennummer senden kann, oder nur ein Bit.

OK sorry. Trotzdem gibt es da eine Lösung. Zunächst: UND/ODER/NICHT...-Logiken funktionieren nach der Boolschen Algebra. Erlaubt sind demnach nur die Zustände 1 und 0 als Logik-Eingang. Aktoren mit Logikfunktionen (und dein SA hat solche Möglichkeiten) am Logikausgang haben eine Schaltfunktion, d.h. wieder 2 Zustände 1 und 0. Mit deinem EibPC kannst du natürlich beliebige Logiken (oder besser: Algorithmen) zusammenbasteln, sowohl im Eingangs- als auch im Ausgangsbereich.

Und jetzt zur Lösung: dein Argus hat mehrere separat konfigurierbare Blöcke. Neben der Szenennummer, die er beispielsweise aus dem Block 1 heraus sendet, kannst du ihn zusätzlich (fast zeitgleich) aus Block 2 eine 1 für Anwesenheit und eine 0 für Abwesenheit senden lassen über eine separate GA. Diese GA legst du dann auf den Eingang der ODER-Logik des Aktorkanals, der das Licht schaltet. Für diesen Kanal brauchst du dann nicht mehr die Ansteuerung über die Szene, die der Argus sendet. Um jetzt aber genau Tipps geben zu können, müsste man wissen, was der Argus mit der einzigen Szenennummer so alles bewirkt. Die Schlüssigkeit deines Programmierkonzepts (Argus und Szenennummer) erschließt sich mir noch nicht richtig.

Damit Argus und Szenennummer zur Hochform auflaufen können, hier noch eine Idee/Tipp: der Argus kann Szenennummern variabel (also in Abhängigkeit anderer Faktoren wie z.B. Tageszeit) senden. Dazu muss nur bei den Telegrammen eingestellt werden "sendet seinen Wert" (und nicht definierten, also starren Wert). Der PM stellt dann ein Schalt/Wertobjekt zur Verfügung, das man auch von außen über eine separate GA beschreiben, also manipulieren kann (z.B. Szenennummer setzen). Ganz ohne Logik geht dann bei mir z.B. folgendes:

Die Schaltuhr sendet zu einer bestimmten Zeit (7 Uhr) einen bestimmten Wert (z.B. 100%) über GA1. Mit diesem Wert beschreibt die GA1 das Wertobjekt des Argus. Bei Präsenz sendet der Argus seinen Wert (also 100%) direkt an den Dimmer über GA2. Folge: ab 7 Uhr 100% Helligkeit. Zu anderen Zeiten sendet die Schaltuhr andere Werte und füttert den Argus entsprechend. So wird z.B. ab 23 Uhr noch mit 10% gedimmt.

Es gibt bestimmt eine ganze Reihe von Möglichkeiten, und das schon ohne großartige Logiken, alleine durch den Argus.

Harald

[Basti]

Um jetzt aber genau Tipps geben zu können, müsste man wissen, was der Argus mit der einzigen Szenennummer so alles bewirkt. Die Schlüssigkeit deines Programmierkonzepts (Argus und Szenennummer) erschließt sich mir noch nicht richtig.

Naja, das eigentlich ganz einfach, durch die Szene wird die Standardbeleuchtung geschaltet, diese beinhaltet unterschiedliche Dimmwerte auf 9 Dali-EVG, einen Dimmerwert auf einem KNX-Dimmaktor und 2 Einschaltbefehle auf geschaltete Steckdosen. Hier erschien mir das Arbeiten über eine Szene am sinnvollsten, oder hast du da eine bessere Idee?

Naja, wird schon werden... ich in der Variante mit "sendet seinen Wert" könnte ein ganz interessanter Ansatz liegen... muss ihc mal ein bisschen hirnen *g*

Vielen Dank schonmal.

[Patholog]

Multiple Geräte mit unterschiedlichen Werten zu versorgen: da ist eine Szene sicher die beste Idee. Das schließt ja die oben genannten Möglichkeiten nicht aus, im Gegenteil. Der Argus kann ja, wie beschrieben, "gleichzeitig" aus mehreren unterschiedlich konfigurierten Blöcken feuern und dabei neben einem Szenen-Byte auch weitere Bits für Logiken absetzen. Solche Bits kann auch dein EibPC, entsprechend gefüttert mit Algorithmen, gut verwerten. Auch deine Aktor-Logiken würden sich darüber freuen.

Nur: erst einmal sollte die Bewegung/Präsenz auch schnell und präzise ermittelt werden. Und da kann man auch bei der Parametrierung des Argus einiges unternehmen, zumindest testen.

Harald