Was ist denn nun 'ne gute Kopplung?

[MartinH]

Gruß, Bernd, der LCN programmieren anstatt parameterieren möchte :thumbup: !

Ja, so habe ich es auch gesehen, als ich mit LCN anfing. Meine Erwartung war eigentlich, dass ich jedes LCN-Modul programmieren kann (anstatt nur zu parametrieren). Leider ist das ja nicht der Fall und Issendorff bietet bis heute keine eigene Lösung die komplexere Logiken übersichtlich unterstützt.

Deinen Vorschlag so einen Logik-Interpreter zu bauen finde ich sehr interessant. Und wenn das Teil mal auf einer kleinen Linux-Box mitläuft - dann um so besser. Ich habe ja neulich schon geschrieben:
[zitat]Langfristig würde ich mir noch ein Logikmodul (mit vM-Anbindung) für die Fritzbox wünschen, das man graphisch (per webinterface) programmieren kann.[/zitat]
Wenn Dein Logik-Interpreter so was leisten könnte, prima ! Ich melde mich schon gleich als Alpha-Tester.

Bernd schreibt:
[zitat]Ich kann aber wohl auch Skripte ausführen :thumbup: , was aber wiederrum durch ein Ereignis aus dem Bus (= Bus-Befehl) geschieht, oder? Ich möchte aber Logiken ausführen, wenn mehrere Ereignisse eintreffen (komplexe "Summe") und nicht nur ein LCN-Befehl. D.h. ich möchte die Summen durch herkömmliche IF-Anweisungen mit AND und OR ersetzen ...[/zitat]
Die Skripte werden doch von einem Shell-Interpreter ausgewertet. Wenn man das jeweilige Script triggert, so bald sich einer der Eingangsparameter ändert, kann man doch die Logik im Script entsprechend auswerten. Man müsste für ein Script doch nur die Eingangparameter angeben und dafür sorgen, dass die aktuellen Werte alle als Parameter für die Auswertung zur Verfügung stehen.
Ob so was mit LinHK gut klappen kann, muss ich mir auch noch anschauen.
Ansonsten könnte Dein Logik-Interpreter eine ideale Ergänzung zu LinHK sein. Eigentlich hat LinHK all die Bus-Infos intern und bräuchte nur noch eine Logik-Auswertung dazu (bisher macht LinHK nur die Logik-Auswertung, die die LCN-Module auch können.)
Eine solche Zusatz-Lib zu LinHK würde ich sofort nehmen !

[zitat]Läuft sie [LinHK] eigenlich auch auf einem normalen Linux-Rechner (sofern die richtigen Treiber verfügbar wären)?[/zitat]
Theoretisch und Praktisch ja - aber das gibt es nicht am Markt. Es werden nur Fritzboxen unterstützt - nicht x-Linux Versionen.

Gruß, Martin - der merkt, dass es irgendwann und irgendwo doch immer wieder gleiche Wünsche gibt.

[BerndR]

Hi Martin,

genau, bei der LinHK muss man das Script triggern, genau das möchte ich aber komfortabler :thumbup: . Beispiel-Code eines meiner ersten Entwürfe:

Code: Alles auswählen

DEFINE lcn_access = LCN-Seriell { com 50 OR LampeDeckeKüche > 75: [
    SLEEP 1.0;
    APPLY LampeEckeKüche = 100;
];

EVENT !LampeEsstischKüche AND !LampeDeckeKüche: [
    APPLY LampeEckeKüche = 0;
];

Das ist ein kurzes Beispiel, was ein Relais mit 1 Sekunde Verzögerung schaltet sofern 2 Lampen einen bestimmten Helligkeitswert überschritten haben. Gehen die beiden Lampen aus, wird auch das Relais wieder ausgeschaltet :w00t: . Der Treshold bei einem Relais soll bewirken, dass er sich genau so wie ein Ausgang verhält. Im Beispiel wird bei einer Zuweisung großer 50 das Relais eingeschaltet und alles was drunter liegt ausgeschaltet. So braucht man sich nicht drum zu kümmern, ob etwas per Relais oder Ausgang angesteuert wird. Diese Info ist nur beim Erzeugen einer entsprechenden Variable wichtig.

Mal sehen, wann ich die erste kleine Demo laufen habe ... am Wochenende geht's ersmal zur Photokina :thumbup: .

Gruß, Bernd.

[BerndR]

Ich hab da noch 'n Beispiel:

Code: Alles auswählen

DEFINE lcn_access = LCN-Seriell { com<<1, baud<<19200 };

DEFINE ModulKücheTür = LCN-Module { lcn<<lcn_access, id<<50 };
DEFINE ModulKücheFenster = LCN-Module { lcn<<lcn_access, id<<51 };
DEFINE ModulHaustür = LCN-Module { lcn<<lcn_access, id<<51 };

DEFINE JemandKommt = LCN-Binary { mod<<ModulHaustür, nr<<2 };
DEFINE MeldungNurLoggen = LCN-Relais { mod<<ModulHaustür, nr<<1 };

DEFINE peeper_1 = LCN-Peeper { mod<<ModulKücheTür, count<<5, type<<'N' };
DEFINE peeper_2 = LCN-Peeper { mod<<ModulKücheFenster , count<<10, type<<'S' };
DEFINE peepers = [ peeper_1, peeper_2 ];

DEFINE f = File { name<<"C:\temp\log.txt", access<<"w" };

EVENT JemandKommt:
[
    IF MeldungNurLoggen:
    [
        APPLY f = "Es kam jemand um " || Now{} || ".";
    ]
    ELSE:
    [
        EXECUTE peepers DoPeep;
    ];
];

Hier wird entweder etwas ins Log-File geschrieben oder bestimmte Peeper peepen ... kann man - glaub ich - verstehen, oder? Man könnte hier die Peeper-Liste auch noch dynamisch verkleinern oder vergrößern (z.B. könnte man nachts die Peeper in den Schlafräumen rausnehmen .

Gruß, Bernd, der noch am Grammatik-finetunen ist ...

[Philipp]

[zitat]da man in ihnen IDs anstatt klar lesbarer Namen angeben muß [/zitat]

Das ist so nicht ganz korrekt.
Es werden IDs verwendet, welche man ber per Übersicht (mit Modulname) auswählt. Und im Script wird auch automatisch die Instanzbeschreibung als Kommentar dynamisch dazugeladen. Von daher ist das in meinen Augen ganz übersichtlich.

Und PHP ist eigentlich auch nicht das Problem, da man wohl kaum mehr als 10 verschieden Funktionen nutz. Da smeiste sind wohl IF und Switch abfragen.

Aber das musst du selbst wissen, ob du auf ein erprobtes bestehendes Produkt gehst, oder dir selbst eine Software strickst.

IPS wird sicherlich auf einer langsamen kleinen Kiste laufen, solange du nicht mit Multimedia und dicken Visualisierungen los legst.

Gruß Philipp

[BerndR]

...
Es werden IDs verwendet, welche man ber per Übersicht (mit Modulname) auswählt. Und im Script wird auch automatisch die Instanzbeschreibung als Kommentar dynamisch dazugeladen. Von daher ist das in meinen Augen ganz übersichtlich.
...

Okay. Danke für die Aufklärung. Ich hab nur ein paar Beispiel-Skripte gesehen und da tauchten immer Zahlen als ID auf, was ich nicht ganz übersichtlich fand. Es macht trotzdem Copy und Paste nicht ganz einfach. PHP ist eigentlich auch OK und sollte nicht das Problem sein .

Unter Linux ist es aber leider nur mit Wine zu betreiben und die Triggerung der Scripte ist für mich (noch) nicht transparent. Ich habe gesehen, dass man eine Variable zum Triggern eines Scriptes angeben kann. Und was ist mit komplexen Bedingungen?

Was mich an IPS ebenso stört ist das neue Lizenzmodell. Da soll sie auf einmal fast 500,- Euro kosten !?!?! Die günstigere Variante funzt bei mir wahrscheinlich nicht aufgrund der begrenzten Anzahl von Variablen. Ich hab schon einiges an Modulen und wenn jedes Relais, Ausgang und Binärsensor eine Variable benötigt, habe ich die 1000 schnell erreicht ...

Gruß, Bernd, der wahrscheinlich seinen eigenen Weg gehen wird ... ich erfinde nicht das Rad neu, sondern erweiter es etwas .

[MartinH]

Deinen Beispielcode kann man so verstehen ..

bei der LinHK muss man das Script triggern, genau das möchte ich aber komfortabler :thumbup:

Irgendwie muss die Auswertung dieser EVENT-Logik ja auch getriggert werden ! ?
Wer oder was triggert die Auswertung oder willst Du dies regelmäßig immer wieder neu auswerten ?
Und so ein Event soll ja nur einmal aktiv werden, wenn sich etwas geändert hat - richtig ?

Gruß, Martin - der nicht weiss, wie teuer es ist, für jede Auswertung immer ein shell-script zu starten

[Philipp]

Hallo Bernd,

also das Triggern der Scripte ist über Variablen oder Timer möglich. Um komplexe Events abzubilden, triggert man das Script einfach über jede beinflussende Variable. Die Logik wird dann im Script über If oder Switch Bedingungen erzeugt und können so kemplex wie du sie gerne hättest sein.
Sollte beim triggern dann die Logik nicht werfüllt sein, wird das script ohne Ergebnis einfach beendet.

Zum Thema Lizenzmoddel kann ich euch nur folgende Anhalstpunkte geben:

Meine Anlage (80 Module mit sehr viel Sensorik) belegt zur Zeit in IPS 509 Variablen. Damit ist aber jegliche Automation welche ich in IPS habe (und das ist jede Menge) abgedeckt. Von daher sehe ich bei der 1000 Varaiblen lizenz eher ein Psychisches wie reales "Begrenzungsproblem";)

Und ich kann nur sagen, die Software ist mit den 249 Euro IMO jeden einzelnen Euro absolut wert.

Gruß Philipp - bei dem IPS LCN, Mobotix, Denon, Dreambox, Anwesenheitsmoul,..... steuert:)

[BerndR]

Deinen Beispielcode kann man so verstehen ..
[zitat=BerndR]bei der LinHK muss man das Script triggern, genau das möchte ich aber komfortabler :thumbup:

Irgendwie muss die Auswertung dieser EVENT-Logik ja auch getriggert werden ! ?
Wer oder was triggert die Auswertung oder willst Du dies regelmäßig immer wieder neu auswerten ?
Und so ein Event soll ja nur einmal aktiv werden, wenn sich etwas geändert hat - richtig ?

Gruß, Martin - der nicht weiss, wie teuer es ist, für jede Auswertung immer ein shell-script zu starten[/zitat]

:thumbup: . Genau das möchte ich! Ich hab schon ein erstes Design erstellt. Darin wird das EVENT genau einmal getriggert, wenn sich die drunterliegende (komplexe) Bedingung geändert hat.

Gruß, Bernd.

[BerndR]

...
Meine Anlage (80 Module mit sehr viel Sensorik) belegt zur Zeit in IPS 509 Variablen. Damit ist aber jegliche Automation welche ich in IPS habe (und das ist jede Menge) abgedeckt. Von daher sehe ich bei der 1000 Varaiblen lizenz eher ein Psychisches wie reales "Begrenzungsproblem";)

Und ich kann nur sagen, die Software ist mit den 249 Euro IMO jeden einzelnen Euro absolut wert.
...

Okay. Mein Ansatz wäre gewesen alle Relais, Variablen, Binärsensoren etc. in der IPS anzulegen. Du hast wahrscheinlich nicht alles als Variable hinterlegt ... braucht man vielleicht auch nicht ... hmmmm .... 249,- Euronen wären dann wahrscheinlich OK ... is so meine momentane Schmerzgrenze ...

Bauchschmerzen habe ich trotzdem noch etwas weil wegen Linux und meiner knappen Rechner-Ressourcen ... werde ich auf der IPS-Seite nochmal etwas wühlen ...

Gruß, Bernd.

[Uwe]

Wir schauen uns das am Koffer und probieren mal mit IPS, Bernd
Ich bringe etwas Zeit mit ...

Es ist nicht so, dass ich deinen Lösungsansatz nicht sehen möchte

Grüße, Uwe - der auf einen Termin hinarbeitet