LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

[Tru]

Ich habe es nicht getestet, aber spricht etwas gegen zwei linKNX-Instanzen, z.B. Lichtsteuerung und Multiroom, mit jeweils eigener linknx.xml?

Noch ein Gedanke dazu: wenn du zwei oder mehrere Instanzen von linknx auf dem gleichen System laufen lassen willst, dann könnte es sich lohnen, das XML zu modularisieren, z.B in einen Teil Objects, einen Teil gemeinsame Settings, verschiedene Rule-Teile etc. Für jede Instanz dann ein eigenes Start-Script, welches sich beim Aufstarten die vordefinierten Module in ein individuelles XML zusammenhängt. So brauchst du die Objects nur an einem Ort zu modifizieren.

Gruss, Othmar

[mumpf]

Hi,

ich nutze für Tests neuerdings auch eine 2. Instanz, funktioniert also.

eine Kommunikation zwischen den beiden Instanzen geht nur über normale KNX-GAs

Theoretisch sollte die Kommunikation zwischen den beiden auch über die XML-Schnittstelle funktionieren, aber GA's sind natürlich einfacher...

Gruß, Waldemar

[Tru]

Ich habe es nicht getestet, aber spricht etwas gegen zwei linKNX-Instanzen, z.B. Lichtsteuerung und Multiroom, mit jeweils eigener linknx.xml?

Ich denke das ist kein Problem. Ich setze selbst neben meinem Haupt linknx ein bis zwei linknx Instanzen auf meinen OpenWrt APs zu Testzwecken ein.

aber gäbe es sonst noch Nachteile?

Die Regelsets auf den verschiedenen Instanzen müssen wohl logisch voneinander unabhängig sein, denn gegenseitig wissen sie ja nichts voneinander, sondern kommunizieren direkt über eibd autonom mit dem Bus. Für meine knxweb Visu führe ich auch einige interne Zustände (also ohne GA), welche halt nur über den Haupt linknx geführt werden. Dafür brauche ich auf den Test linknx gar nicht alle GA zu führen.

Gruss, Othmar

[panzaeron]

Mal eine andere Frage...

Ich habe es nicht getestet, aber spricht etwas gegen zwei linKNX-Instanzen, z.B. Lichtsteuerung und Multiroom, mit jeweils eigener linknx.xml?

Der Hintergrund ist, dass meine Konfiguration mittlerweile sehr mächtig geworden ist und damit leider auch sehr unübersichtlich.
Wenn ich zwei Instanzen laufen hätte, brauche ich

• die Objekte doppelt,
• eine Kommunikation zwischen den beiden Instanzen geht nur über normale KNX-GAs und
• der Ressourcenbedarf ist etwas höher,

aber gäbe es sonst noch Nachteile?

[greentux]

P.S.: Meiner Meinung nach braucht man <during> nicht mehr seit es <condition type="time-counter"> gibt...

Mmmh, sehe ich nicht ganz so.
Time-Counter zählt von Event eine Zeit.
Bei During könnte man sagen, sas für einen Zeitraum geprüft wird.

Das During hätte vermutlich auch eher "after" (da wird das dann nämlich 0) heissen sollen

[mumpf]

Ich dachte ... das für 60s die true action ausgeführt wird...
mmmh.

Um es nochmal exakt auszudrücken: Eine Action wird nie eine gewisse Zeit lang ausgeführt, sondern ist ein kurzfristiges Ereignis, das irgendwann passiert.

Man kann zwar durch LUA-Scripts eine action erzeugen, die wirklich lange läuft, aber das ist (aus der Sicht von LinKNX) nicht abbrechbar und blockiert die Ausführung von anderen LUA-Scripts - ist also sehr schlecht!!!

Gruß, Waldemar

[mumpf]

Hi,

ich glaube - so wie ich Dich verstehe - das es genau das ist, was Du meinst.

Eine timer-condition erlaubt Dir, 2 Zeiten zu beschreiben:

• Wann wird die true-action ausgeführt (die dann z.B. eine 1 sendet)
  Dies kann man als Zeitpunkt mit <at> formulieren oder als Zeitintervall mit <every>.
• Wann wird die false-action ausgeführt (die dann z.B. eine 0 sendet)
  Dies kann man als Zeitpunkt mit <until> oder als Zeitintervall mit <during> formulieren.

Gehe jeden Tag um 15 Uhr für 60 Sekunden an heisst also:

<condition type="timer" trigger="true">
  <at hour="15"/>
  <during>60</during> 
</condition>

Technisch gesehen sendet das <during> eine 0, semantisch betrachtet sagt es "halte die 1 für 60 Sekunden".

Hoffe, das ist jetzt etwas klarer...

Gruß, Waldemar

P.S.: Meiner Meinung nach braucht man <during> nicht mehr seit es <condition type="time-counter"> gibt...

[greentux]

Ich dachte, das "during" eher meint, das für 60s die true action ausgeführt wird...
mmmh.

[mumpf]

Hi,

every ist recht einfach:

<rule id="EveryBeispiel">
  <condition type="timer" trigger="true">
    <every>3600</every>
  <condition>
  <actionlist>
    <action .../>
  </actionlist>
</rule>

Die action wird im obigen Beispiel jede Stunde getriggert. Ich kann es gerade nicht ausprobieren, aber es sollte auch

    <every>1h<every>

gehen. During hab ich noch nicht verwendet, aber so wie ich die Doku verstehe, sollte das folgende every/during

<rule id="EveryDuringBeispiel">
  <condition type="timer" trigger="true">
    <every>3600</every>
    <during>60</during>
  <condition>
  <actionlist>
    <action .../>
  </actionlist>
  <actionlist type="on-false">
    <action .../>
  </actionlist>
</rule>

aussagen, dass jede Stunde die true-action getriggert wird, dann nach 1 Minute die false-action.

Gruß, Waldemar

[greentux]

Viel kann ich noch nicht beitragen. Gerade habe ich mit der Zirkulationspumpe angefangen. Da fehlt aber noch der Teil, der sie laufen läßt, wenn der Puffer geladen wird.

btw. Kann jemand mal ein paar Beispiel für "during" und "every" bringen?
Ich finde da nix zu...

<!-- Zirkulation temperaturgesteuert in fixen Zeitraeumen-->
        <rule id="zirkulation_temp">
                <condition type="and">
                        <condition type="or">
                                <condition type="timer">
                                        <at wdays="1234567" hour="06" min="00" exception="no" />
                                        <until wdays="1234567" hour="09" min="00" exception="no" />
                                </condition>
                                <condition type="timer">
                                        <at wdays="1234567" hour="17" min="00" exception="no" />
                                        <until wdays="1234567" hour="23" min="30" exception="no" />
                                </condition>
                        </condition>
                        <condition type="object" id="ww_temp" op="gt" value="30" />
                        <condition type="object" id="zirkulation_temp" op="lt" value="26" trigger="true" />
                </condition>
                <actionlist>
                        <action type="cycle-on-off" id="zirkulation" on="180" off="20" count="1"/>
                </actionlist>
        </rule>

[Tru]

danke für den Test, bei mir passiert das auch mit der 0.0.1.30. Ich werd das mal auf SF melden, kann ja nicht schaden.

Verbessert sich die Situation wenn mit dem neuen Feature aus 0.0.1.31 die Rules mit init="false" gesetzt werden?

Gruss, Othmar

[netsrac]

Andere Frage, aber vielleicht auch ein Workaround für dieses Problem:

Ich weiß, dass ich mal irgendwo gelesen habe, das man eine Actionlist definieren kann, die beim Start von LinKNX abgearbeitet wird. Nur finden tue ich es jetzt nicht mehr...

Gruß, Netsrac

[mumpf]

Hi Netsrac,

danke für den Test, bei mir passiert das auch mit der 0.0.1.30. Ich werd das mal auf SF melden, kann ja nicht schaden.

Ich hab durch diese Erkenntnis schon an mehreren Stellen meine config angepasst und bereits 2 Probleme gelöst, die in die Kategorie "mystic" fallen:

• Mein Schlüsselbrett und Abwesend-Modus
  Immer nach dem restart von LinKNX musste ich alle Schlüssel mal abgenommen und wieder drangehängt haben, damit der Abwesend-Modus richtig ging.
  Jetzt ist klar: Abwesend wurde durch mehrere interne LinKNX-Objekte ermittelt. Bei allen war in den Flags kein r gesetzt und deren initiales read schlug fehl, dann lief die Abwesend-Rule nicht. Durch Schlüssel ab und dran wurden die internen Objekte beschrieben und dann lief alles wieder.
• Meldung Waschmaschine fertig
  Die funktionierte nach einen Restart von LinKNX auch erst ab dem 2. Waschgang. Hier war es der Schaltaktor der Waschmaschine, der einen Read auf der Schaltadresse nicht beantwortet hat. Hier half ein read="true" im listener, um das Problem zu beheben.

Man kann somit, wenn man den Fehler kennt, durchaus Lösungen finden, den zu umgehen. Ich find es nur blöd, dass es passieren kann, dass man irgendwann eine neue rule einfügt, um was neues zu machen, und dadurch versehentlich andere rules, die bereits funktionierten und womöglich nichts mit der neuen zu tun haben, dann kaputt macht. Und da meine config bereits knapp 3000 Zeilen hat, kann man das auch nicht so einfach rausfinden

Gruß, Waldemar

[netsrac]

Hab's auch mal probiert...wenn ich die beiden Rules in der Reihenfolge vertausche, dann klappt es so, wie's soll...sprich zuerste die Rule "Fehlerbeispiel" und dann "FunktionierendesBeispiel".

Schickt man mehrmals eine "1" auf dynamic1, so wird der Read Request zwar nicht mehr gesendet, die zweite Rule wird aber dennoch nicht getriggert.

Wenn ich die condition mit "dynamic2" auskommentiere, dann geht es problemlos.

Sende ich vorher auf "dynamic2" eine "0", so funktioniert es auch.

Scheinbar liegt das Problem wirklich daran, dass man von "dynamic2" keinen Init-Wert hat.

Sollte aber wirklich nicht so sein...klingt nach einem Bug. Meine Version ist auch die aus dem CVS:

linknx 0.0.1.31
- Clickatell SMS gateway enabled
- E-mail gateway enabled (with pthread support)
- MySQL support enabled
- LUA scripting support enabled

Netsrac

[mumpf]

Hallo Othmar,

Kann es sein, dass dieses Verhalten nur nach dem Daemon-Start auftritt, aber nicht mehr beim nächsten 0->1 ?

Das hab ich natürlich auch ausprobiert... Es bleibt beim gleichen Verhalten, nur wird das READ nicht mehr abgesetzt.

2012-10-14 16:34:32,852 DEBUG > KnxConnection  - Write from 1.0.254 to 11/0/121: 01
2012-10-14 16:34:32,852 DEBUG > Object  - Object (id=dynamic1): get
2012-10-14 16:34:32,852  INFO > Object  - New value on for object dynamic1 (type: 1.001)
2012-10-14 16:34:32,853 DEBUG > Object  - Calling onChange on listener for dynamic1
2012-10-14 16:34:32,853  INFO > Rule  - Evaluate rule FunktionierendesBeispiel
2012-10-14 16:34:32,853 DEBUG > Object  - Object (id=dynamic1): get
2012-10-14 16:34:32,853  INFO > ObjectValue  - SwitchingObjectValue: Compare value_m='1' to value='1'
2012-10-14 16:34:32,853  INFO > Condition  - ObjectCondition (id='dynamic1') evaluated as '1'

Weiter geht es nicht... Wenn ich aber dynamic1 von 1->0 setze, dann werden beide Rules getriggert, da ja bei der and-condition nur ein Objekt evaluiert wird. Somit haben auch beide rules einen gültigen Zustand, das Ganze ist unabhängig vom Startup.

Wie sieht das Verhalten aus, wenn die beiden Rules in umgekehrter Reihenfolge definiert sind? Oder nur das Fehlerbeispiel?

"Fehlerbeispiel" alleine funktioniert natürlich, hab ich auch getestet. Es klappt auch, wenn sie in umgekehrter Reihenfolge stehen, weil dann "Fehlerbeispiel" zuerst evaluiert wird, danach erst "FunktionierendesBeispiel".

Meine Vermutung würde in die Richtung gehen, dass das init nicht richtig funktioniert oder dass bei Fehlerbeispiel der Wert der Condition von unknown auf true geht.

Wie schon gesagt, ich habe es mehrmals ausprobiert, sollte also nicht am init liegen, ferner habe ich bei 1->0 im Protokoll gesehen, dass "Fehlerbeispiel" mit false evaluiert wird.

Ich kann das Problem lösen, wenn ich dynamic2 auch das r-Flag gebe, dann beantwortet linknx selbst den READ-Request und dann geht es weiter. Aber wenn mal ein Gerät kein READ-Request beantwortet, dann gehen viele rules nicht mehr, das find ich nicht so lustig.

Sollte man das als Bug auf SF melden?

Gruß, Waldemar