LinKNX: Diskussionen zu Tipps, Tricks und Beispiele

[greentux]

Fallback ist gut

Aeh, Jumi, das sollte doch vermutlich ein 3 Zeiler in Perl werden oder?
Im Grunde muss aus der eibga.conf die "object" Sektion in der linknx config gemacht werden.
Ein paar Sachen muss man dann händisch ggf. anpassen (flags, log).

Gruß

[mumpf]

Hi,

ich hab alles manuell erfasst, immer nur die GA's, die ich in den Regeln brauche. Inzwischen sind das fast alle, aber ich hab das nach und nach aufgebaut.
Bei mir liegt das aber auch daran, dass ich noch FHEM nutze, und dadurch habe ich in linKNX auch Objekte, die nicht vom Bus versorgt werden. Ein Export würde bei mir somit nur einen Teil der Objekte abdecken.

Gruß, Waldemar

[JuMi2006]

Wie habt ihr euer DPTs und GAs aus dem Wiregate in in die linknx bekommen?

Es gibt ja einmal die Exportvariante der ETS und dann mit dem Excel-Tool, da fehlen mir dann aber die DPTs und die ganzen GAs für die 1-Wire-Sensoren.

Am besten gepflegt ist bei mir momentan die eibga.conf vom WireGate. Dort sind die GAs und auch DPTs eben am aktuellsten.

So eine riesige Tipporgie wollte ich mir eigentlich ersparen aber das ein oder andere Plugin langsam mal auf linknx testen, kann gerade als Fallback-Lösung sehr interessant sein, schließlich läuft das nun wirklich auf jeder Büchse

[greentux]

Du könntest Dir auch ein paar links auf linknx machen und diese dann starten ("linknx_outside", "linknx_heating"). Dann würdest Du im ps die verschiedenen Instanzen auseinanderhalten können.

[panzaeron]

@panzaeron: Coole idee, ein script zum mergen der Dateien...

Aber: So wie ich es verstanden habe, machst Du das doch primär der Übersicht wegen, oder? Und wenn man schon Dateien parsed und zusammenschmeisst, sollte man dann nicht verschiedene Teil-Configs in eine finale linknx.xml zusammenmergen und dann EINE linknx-Instanz mit dieser linknx.xml starten?

Das Skript eignet sich auch für eine linknx.xml, einfach diese erzeugen und die übrigen "Teil-XML"-Dateien mit einem Unterstrich versehen und jede in einer Zeile einbinden. Ich habe es in der aktuellen Version nicht getestet, aber ich meine es war mal so, dass es nur einen objects, rules und services Bereich geben darf, deshalb müsste man die Configs trennen (oder das Skript erweitern)...
Allerdings habe ich mich bewusst für die Multiinstanz-Lösung entschieden, weil ich momentan noch viel "Spiele" und wenn eine Konfiguration nicht stabil (kommt sehr selten vor) arbeitet, dann funktioniert der Rest weiter...

Noch besser wäre es, wenn linknx ein include-Konzept hätte, aber das gibt es nun mal nicht... Ich hab mit mehreren Instanzen immer das Problem, dass man dann doch jedesmal suchen muss, welche man restarted, weil sich die Logik geändert hat etc.

Für debug-Zwecke ne 2. Instanz - das mach ich auch, und die läuft nur so lange ich teste, aber mehrere produktiv?

Aber klar, soll jeder machen, wie er das will. Wär cool, wenn Du mal ab und zu berichtest, wie das so im Alltag klappt.

Gruß, Waldemar

Eine reguläre include-Möglichkeit wäre super.
Das Skript generiert alle configs und startet alle linKNX-Instanzen neu. Ursprünglich wollte ich noch eine zusätzliche Abfrage machen, ob sich eine config nach dem letzten Start geändert hat und nur diese neu starten, hab ich dann aber doch nicht implementiert...

Seit einer Woche funktioniert es problemlos, werde berichten wie es weiter klappt...

[mumpf]

Zu: Mehrere Instanzen von LinKNX starten

@panzaeron: Coole idee, ein script zum mergen der Dateien...

Aber: So wie ich es verstanden habe, machst Du das doch primär der Übersicht wegen, oder? Und wenn man schon Dateien parsed und zusammenschmeisst, sollte man dann nicht verschiedene Teil-Configs in eine finale linknx.xml zusammenmergen und dann EINE linknx-Instanz mit dieser linknx.xml starten?

Noch besser wäre es, wenn linknx ein include-Konzept hätte, aber das gibt es nun mal nicht... Ich hab mit mehreren Instanzen immer das Problem, dass man dann doch jedesmal suchen muss, welche man restarted, weil sich die Logik geändert hat etc.

Für debug-Zwecke ne 2. Instanz - das mach ich auch, und die läuft nur so lange ich teste, aber mehrere produktiv?

Aber klar, soll jeder machen, wie er das will. Wär cool, wenn Du mal ab und zu berichtest, wie das so im Alltag klappt.

Gruß, Waldemar

[mumpf]

Hi,

ich hab mal im Coding nachgeschaut: Man muss noch das Property var="true" setzen. Dann sollte es klappen!

Gruß, Waldemar

[greentux]

Mmmh,

leider steht in meiner Mail
<code>
${zirkulation_temp} laeuft... Siehe Logs.
</code>

Zum gleichen Zeitpunkt ist zirkulation_temp bei 29°C

Im Code steht

 <actionlist type="if-true">
           <action type="cycle-on-off" id="zirkulation" on="120" off="180" count="1"/>
           <action type="send-email"  to="root@localhost" subject="Zirkulation"> ${zirkulation_temp} laeuft... Siehe Logs.</action>
 </actionlist>

[mumpf]

Hi,

habe gerade mal im Changelog nachgesehen:

Release 0.0.1.28:
* Allow to insert object values in some actions (shell, e-mail, SMS, io-port, set-string)

Für set-string ist das auch dokumentiert:

<action type="set-string" id="lcd_text" value="T° ext: ${ext_temp}°C" />

sprich: ein ${object-id} im String wird durch den Objektinhalt des Objektes mit der id="object-id" ersetzt.

Sollte nach changelog auch für e-mail gehen, ausprobiert hab ich es noch nicht. Wenn Du das aber ausprobierst und es funktioniert, wäre es was für die Tipps und Tricks

Gruß, Waldemar

[greentux]

Emailihalte

Weiss jemand, ob man in den versendeten Emails noch Inhalte platzieren kann (beispielsweise Variablen, GAs, usw)?

Gruß

[mumpf]

Hi,

Was passiert, wenn ich das trigger="true" weglasse? Wird die Rule evaluiert?

Wenn Du trigger weglässt, dann führt diese condition nicht dazu, dass die rule, in der sie steht, beim Eintritt der Bedingung evaluiert wird. Wenn eine andere condition in dieser rule ein trigger ist, dann wird diese condition beim triggern auch evaluiert. Ist in einer rule kein trigger, wird die rule nie evaluiert.

Wann passiert die "Action"? Nur einmal 5.50Uhr?

Diese Frage ist - so wie die condition da oben steht - schwer zu beantworten.
Zum einen gibt es nicht DIE action, sondern 2 actionlist’s, eine für condition = true und eine für condition = false.
Zum anderen (ohne trigger) kann man nur sagen, nie...

Mit trigger="true" wird dann wann und wie oft ausgelöst?

Mit trigger ist es einfach: Die true-actionlist wird um 5:50 Uhr, die false-actionlist um 7:15 Uhr Ausgeführt. Dies passiert täglich Mo-Fr sofern es kein Feiertag ist.

Gruss, Waldemar

[greentux]

<condition type="timer" >
       <at wdays="12345" hour="05" min="50" exception="no" />
       <until wdays="12345" hour="07" min="15" exception="no" />
</condition>

Was passiert, wenn ich das trigger="true" weglasse? Wird die Rule evaluiert?
Wann passiert die "Action"? Nur einmal 5.50Uhr?

Mit trigger="true" wird dann wann und wie oft ausgelöst?

Grüße

[netsrac]

So brauchst du die Objects nur an einem Ort zu modifizieren.

Gruss, Othmar

Nun gut, das mache ich beim Debuggen absichtlich nicht, denn jede Statusänderung auf einer im XML definierten Objektes wird dann auch im Log gezeigt. damit geht mir ja die Möglichkeit verloren, hier einfach zu Debuggen...

[Tru]

Geht das eigentlich bei linknx, XML's zusammenhängen? Und wenn ja, wie?

linknx selbst kann das nicht. Ich dachte an etwas Selbstgestricktes wie

cat head.xml services.xml objects.xml rules1.xml log1.xml tail.xml > linknx1.xml
cat head.xml services.xml objects.xml rules2.xml log2.xml tail.xml > linknx2.xml
cat head.xml services.xml objects.xml rules3.xml log3.xml tail.xml > linknx3.xml

Ganz ausgeklügelt wäre z.B. alles noch in einem Makefile abzubilden, welches dann auch gleich noch die Abhängigkeiten auflöst und die Services neu startet wo nötig.

Gruss, Othmar

[Bodo]

Für jede Instanz dann ein eigenes Start-Script, welches sich beim Aufstarten die vordefinierten Module in ein individuelles XML zusammenhängt.

Hoi Othmar

Geht das eigentlich bei linknx, XML's zusammenhängen? Und wenn ja, wie?