Ankündigung

**EPIX** · 06.11.2010, 16:30

frage doch einfach den progammieren Jeff2000...

Auf Sourceforge kannst du die Frage stellen, normalerweise antwortet er immer rel. rasch

**Tru** · 06.11.2010, 19:27

Zitat von lobo Beitrag anzeigen

Hat von Euch jemand dieses Objekt im Einsatz und gibt es da vielleicht einen Trick?

Ja, ich benutze den Multiswitch, allerdings etwas anders als du. Ich verwende ihn um quasi ein Signal zu schicken mit der Folge "Off" - "On" - "Off" z.B. für den Aufruf von Szenen oder zum Stoppen der fahrenden Storen. Auf diese Art wird auf jeden Fall eine Wertänderung erzielt, welche einen Trigger auslösen kann.

Für eine Szene definiere ich ein Objekt z.B. id="szene9" vom Typ "1.001" und verknüpfe es in knxweb mit dem Multiswitch. Zusätzlich benötige ich eine Rule, welche bei einer Werteänderung reagiert, z.B. so:

Code:

    <rule id="exec-szene9">
      <condition type="object" id="szene9" value="on" trigger="true" />
      <actionlist>
        <action type="set-value" id="szene" value="9" />
        <action type="set-value" id="szene9" value="off" />
      </actionlist>
    </rule>

Ich verwende also den Umweg über eine Rule um bei der Betätigung des entsprechenden Multiswitch den Wert 9 an die Gruppenadresse für die Szene zu schicken.

Gruss, Tru

**lobo** · 06.11.2010, 23:55

Zitat von EPIX Beitrag anzeigen

frage doch einfach den progammieren Jeff2000...

Meinst Du irgendwo als Mail? Wenn ich mir die Forums-Seite von Knxweb ansehe, ist da mehr als Sendepause. Da war ich noch nicht so motiviert - aber ein Versuch ist's Wert und vielleicht hilft's auch Anderen.

Zitat von Tru Beitrag anzeigen

Ich verwende also den Umweg über eine Rule um bei der Betätigung des entsprechenden Multiswitch den Wert 9 an die Gruppenadresse für die Szene zu schicken.

OK - ich denke, wenn ich den Multiswitch auf eine 1.001er GA senden lasse, wird wirklich bei jedem Tastendruck gesendet (zumindest ein 1Bit-Signal).

Ich habe das jetzt mal mit einer internen Regel in Linknx versucht:

Bei Objects:

Code:

<!-- Linknx interne Objekte -->
     <object type="1.001" id="Linknx_LZ_Raumpanel_0" flags="crwtuf" init="persist" log="true">Linknx_LZ_Raumpanel_0</object>

<!-- GAs auf Bus -->
      <object type="5.xxx" id="1_3_0_LZRaumpanel" gad="1/3/0" flags="crwtuf" init="persist">(1/3/0)LZRaumpanel</object>

Bei Rules:

Code:

<!-- Umsetzung 1Bit Adressierung intern -> Linknx_LZ_Raumpanel -->
    <rule id="Aufruf_LZ_Raumpanel_0">
      <condition type="or" trigger="true">
        <condition type="object" id="Linknx_LZ_Raumpanel_0" value="on" trigger="true">
        </condition>
        <condition type="object" id="Linknx_LZ_Raumpanel_0" value="off" trigger="true">
        </condition>
      </condition>
      <actionlist>
         <action type="set-value" id="1_3_0_LZRaumpanel" value="0" />
      </actionlist>
    </rule>

Bei Knxweb lautet die design.xml dann:

Code:

      <control type="multi" label="AllesAn" object="Linknx_LZ_Raumpanel_0" x="220" y="500">
        <item value="on" img="AllesAn.gif" />
        <item value="off" img="AllesAn.gif" />

Also - ich kann (wenn ich mir die linknx logs ansehe) eindeutig feststellen, dass knxweb ein "on" oder "off" an das interne Objekt von linknx sendet:

Code:

2010-11-06 23:34:24,677 [ INFO] Object: New value on for object Linknx_LZ_Raumpanel_0 (type: 1.001)
2010-11-06 23:34:24,677 [ INFO] SwitchingObject: SwitchingObject (id=Linknx_LZ_Raumpanel_0): Compare value_m='1' to value='1'
2010-11-06 23:34:24,677 [ INFO] Condition: ObjectCondition (id='Linknx_LZ_Raumpanel_0') evaluated as '1'
2010-11-06 23:34:24,677 [ INFO] SwitchingObject: SwitchingObject (id=Linknx_LZ_Raumpanel_0): Compare value_m='1' to value='1'
2010-11-06 23:34:24,678 [ INFO] Condition: ObjectCondition (id='Linknx_LZ_Raumpanel_0') evaluated as '1'
2010-11-06 23:34:24,678 [ INFO] FilePersistentStorage: Writing 'on' for object 'Linknx_LZ_Raumpanel_0'
2010-11-06 23:34:24,678 [ INFO] FilePersistentStorage: Writing log'on' for object 'Linknx_LZ_Raumpanel_0'
2010-11-06 23:34:25,749 [ INFO] Object: New value off for object Linknx_LZ_Raumpanel_0 (type: 1.001)
2010-11-06 23:34:25,749 [ INFO] SwitchingObject: SwitchingObject (id=Linknx_LZ_Raumpanel_0): Compare value_m='0' to value='1'
2010-11-06 23:34:25,750 [ INFO] Condition: ObjectCondition (id='Linknx_LZ_Raumpanel_0') evaluated as '0'
2010-11-06 23:34:25,750 [ INFO] SwitchingObject: SwitchingObject (id=Linknx_LZ_Raumpanel_0): Compare value_m='0' to value='0'
2010-11-06 23:34:25,750 [ INFO] Condition: ObjectCondition (id='Linknx_LZ_Raumpanel_0') evaluated as '1'
2010-11-06 23:34:25,750 [ INFO] SwitchingObject: SwitchingObject (id=Linknx_LZ_Raumpanel_0): Compare value_m='0' to value='1'
2010-11-06 23:34:25,750 [ INFO] Condition: ObjectCondition (id='Linknx_LZ_Raumpanel_0') evaluated as '0'
2010-11-06 23:34:25,751 [ INFO] SwitchingObject: SwitchingObject (id=Linknx_LZ_Raumpanel_0): Compare value_m='0' to value='0'
2010-11-06 23:34:25,751 [ INFO] Condition: ObjectCondition (id='Linknx_LZ_Raumpanel_0') evaluated as '1'
2010-11-06 23:34:25,751 [ INFO] FilePersistentStorage: Writing 'off' for object'Linknx_LZ_Raumpanel_0'
2010-11-06 23:34:25,751 [ INFO] FilePersistentStorage: Writing log'off' for object 'Linknx_LZ_Raumpanel_0'

Die Regeln werden auch ausgeführt, aber machen tut's halt nichts - und dabei habe ich jetzt schon (aus purer Verzweiflung) alle Flags in meinem Objekt 1_3_0_LZRaumpanel gesetzt.

Warum führt meine Regel nicht dazu, dass der entsprechende Wert auf'n Bus gesendet wird (ach so - ich meine mich erinnern zu können, dass beim allerersten Aufruf tatsächlich ein Wert gesendet wurde, aber dann ist Funkstille)?

Viele Grüße,

Stefan

**Tru** · 07.11.2010, 10:17

Zitat von lobo Beitrag anzeigen

Warum führt meine Regel nicht dazu, dass der entsprechende Wert auf'n Bus gesendet wird (ach so - ich meine mich erinnern zu können, dass beim allerersten Aufruf tatsächlich ein Wert gesendet wurde, aber dann ist Funkstille)?

Vermutlich löst die Condition nur aus weil beim ersten Mal kein Wert bekannt ist. Nachher passiert wahrscheinlich nichts mehr, weil die Condition immer noch erfüllt ist: Keine Änderung - keine Action.

Probier doch mal mein Beispiel konsequent nachzubauen: nur eine Condition auf On und in der Action auf Off setzen. Was halt nicht geht ist, in der Visu die Aktivierung anzuzeigen, weil der Wert quasi immer auf Off ist. Auf der anderen Seite stimmt die Anzeige "Alles Ein" auch nicht mehr, wenn du einzelne Lampen löschst oder wenn du "Alles Aus" aktivierst.

Gruss, Tru

**lobo** · 07.11.2010, 11:39

Zitat von Tru Beitrag anzeigen

Vermutlich löst die Condition nur aus weil beim ersten Mal kein Wert bekannt ist. Nachher passiert wahrscheinlich nichts mehr, weil die Condition immer noch erfüllt ist: Keine Änderung - keine Action.

Ja, aber dafür gibt es doch den Schalter trigger="True" - und zudem habe ich bei den Flags das "f" gesetzt, um auch den selben Zustand neu zu übertragen

Zitat von Tru Beitrag anzeigen

Probier doch mal mein Beispiel konsequent nachzubauen: nur eine Condition auf On und in der Action auf Off setzen.

Ich fand es halt eleganter, beide Zustände auszuwerten, denn ich brauche auch an anderer Stelle die Umsetzung 1bit in 8bit Szenen (Stichwort: Taster mit geringer Intelligenz auch zum Auslösen von Szenen verwenden - auch mit Auswertung eines langen Tastendrucks).

Zitat von Tru Beitrag anzeigen

Was halt nicht geht ist, in der Visu die Aktivierung anzuzeigen, weil der Wert quasi immer auf Off ist.

Eine Szene zu bestätigen (und ggf. auch wieder "auszuschalten") ist meiner Meinung nach auch ganz großer Quatsch - eben weil eben eine Szene nur einen von vielen möglichen Zuständen abbildet. Zudem habe ich an einigen Stellen auch die manuelle Verstellung vorgesehen (Dimmer) und entgegen der "reinen Lehre" benutze ich die auch. Um so schöner ist es ja dann auch, dass ich einzelne Dimmer per Visu ändern kann (allerdings nicht beim IPOD - der kann das "lange Tastendrücken" auf das + oder - Symbol nicht

)

OK - ich habe daher mal versucht, die "oder"-Verknüpfung in 2 Regeln aufzuteilen:

Code:

<!-- Umsetzung 1Bit Adressierung intern -> Linknx_LZ_Raumpanel -->
    <rule id="Aufruf_LZ_Raumpanel_01">
      <condition type="object" id="Linknx_LZ_Raumpanel_0" value="on" trigger="true">
      </condition>
      <actionlist>
        <action type="set-value" id="1_3_0_LZRaumpanel" value="0" />
      </actionlist>
    </rule>

    <rule id="Aufruf_LZ_Raumpanel_00">
      <condition type="object" id="Linknx_LZ_Raumpanel_0" value="off" trigger="true">
      </condition>
      <actionlist>
        <action type="set-value" id="1_3_0_LZRaumpanel" value="0" />
      </actionlist>
    </rule>

... und diese Regel funktioniert! IMMER! Ich vermute mal, wenn ich das interne Objekt "Linknx_LZ_Raumpanel_0" auch auf eine GA auf den Bus schicke, wird die Regel auch beim Empfang eines Wertes vom Bus ausgeführt (wie gesagt, um "dumme" Taster "aufzuschlauen"

)

Zusammenfassung des Geschreibsels:
Ich kann jetzt mit dem Multiswitch Szenen aufrufen :freu:, indem ich wechselweise 1 oder 0 an eine interne LInknx-Variable schicke. Die Umsetzung in 8-Bit erfolgt über 2 Regeln.

Ich vermute, es besteht ein Problem (Bug??) in der Oder-Auswertung der Regeln - oder ich habe die noch nicht richtig verstanden

Auf alle Fälle erst mal vielen Dank für die Hilfe. Vielleicht fällt Dir ja noch was zu der Oder-Verknüpfung (mit trigger="true") ein - oder ich frage da dann noch mal im SF-Forum.

Viele Grüße,

Stefan

**Tru** · 08.11.2010, 21:48

Zitat von lobo Beitrag anzeigen

Ich vermute, es besteht ein Problem (Bug??) in der Oder-Auswertung der Regeln - oder ich habe die noch nicht richtig verstanden

Auf alle Fälle erst mal vielen Dank für die Hilfe. Vielleicht fällt Dir ja noch was zu der Oder-Verknüpfung (mit trigger="true") ein - oder ich frage da dann noch mal im SF-Forum.

Ich habe unter SourceForge.net: Linknx: Topic: <actionlist type="on-false"> not working noch was gefunden. Mindestens hat das Problem mal bestanden, aber ich weiss nicht ob es in der Zwischenzeit tatsächlich verbessert worden ist. Der Punkt ist also nicht, ob der Trigger zündet, sondern ob das Resultat der Bedingung effektiv wechselt, was bei deinem ersten Versuch mit "true OR false" nie der Fall war.

The problem is probably that the "on-true" and "on-false" action lists are only executed when the condition result changes from true to false and from false to true. At program startup, the variable containing the actual condition value is set to false, then if the condition is evaluated as false, the rule doesn't see a change and the on-false actions are not executed.

I'm currently working on an improvement for the action-lists (for release 0.0.1.27). This improvement will allow to set type="if-false" instead of "on-false" and the same with "if-true". In that case, the corresponding action-list will be executed every time the condition is evaluated.

Ich habe damals mit Version 0.0.1.26 die gleichen Probleme angetroffen wie du jetzt. Sowohl dein Ansatz wie meiner umgehen diese Einschränkung. Deine Lösung mit zwei Regeln löst bei On-zu-Off wie auch bei Off-zu-On aus. Meine Lösung nur beabsichtigterweise bei Off-zu-On.

Mit dem Eintrag 'actionlist type="if-true"' könnte dein erster Versuch mit der Oder-Verknüpfung allenfalls klappen, wenn ich Jef2000 richtig verstehe.

Gruss, Tru

**lobo** · 09.11.2010, 00:11

OK - den Post auf SF hatte ich gelesen - aber leider nicht verstanden, weil die Dokumentation auf der Action Wiki-Seite nicht so viel hergibt.

Ich verwende linknx 0.0.1.27:

Code:

debian:~# linknx --version
linknx 0.0.1.27
- E-mail gateway enabled (with pthread support)
- MySQL support enabled
- LUA scripting support enabled
- Log4cpp logging enabled

... von daher handelt es sich zumindest um eine aktuelle Version. Die Trigger-Geschichte scheint aber noch nicht zuverlässig zu funktionieren.

Ich habe auch festgestellt, dass ich meine 2 aufgeteilten Regeln so nur für den Mulitswitch verwenden kann (weil die halt immer nacheinander 1 und 0 senden). Mittlerweile hören die Regeln auch auf eine Busadresse. Wenn ich da jetzt immer den selben Wert über den Busmonitor sende, wird die Regel auch nicht ausgeführt

Ich probiere mal die type="if-false" Option aus (morgen hoffentlich) und berichte dann wieder.

Vielen Dank, dass Du Dich da noch mal gemeldet hast

Viele Grüße,

Stefan

**Tru** · 11.11.2010, 22:26

Zitat von Tru Beitrag anzeigen

Mit dem Eintrag 'actionlist type="if-true"' könnte dein erster Versuch mit der Oder-Verknüpfung allenfalls klappen, wenn ich Jef2000 richtig verstehe.

Hab heute Abend mal Zeit gefunden, mit linknx Release 0.0.1.27 Tests durchzuführen und siehe da: es funktioniert nun so wie Jef2000 angekündigt hatte.

Im Klartext:
Eine klassische Rule wie diese löst auch mit 0.0.1.27 noch immer wie von mir beschrieben die Actionlist genau 1mal auf: nämlich beim ersten Trigger.

Code:

    <rule id="test1">
      <condition type="or">
        <condition type="object" id="steckdose_z1" value="on" trigger="true" />
        <condition type="object" id="steckdose_z1" value="off" />
      </condition>
      <actionlist>
        <action type="shell-cmd" cmd="echo test1 >> /tmp/out.log" />
      </actionlist>
    </rule>

Grund: die Actionlist wird definitionsgemäss nur aktiviert, wenn von Trigger zu Trigger das Resultat der Condition ändert. Was hier nie mehr der Fall ist, weil das Resultat jedes mal wahr ist.

Mit dieser neuen Erweiterung wird die Actionlist bereits beim Start zum ersten Mal ausgeführt, und dann bei jedem einzelnen Trigger wieder.

Code:

     <actionlist type="if-true">

Und noch etwas hab ich verifiziert: Wird für ein Objekt hintereinander jeweils der gleiche Wert auf den Bus geschickt, dann löst in linknx der Trigger nur aus, wenn in der Objekt-Definition das Flag "u" gesetzt ist.

Ich hoffe, das hilft weiter.

Gruss, Tru

**lobo** · 11.11.2010, 22:44

Super, danke!

Ich habe noch keine Zeit gefunden (ich muss wohl morgen schon die Folien für einen Vortrag abgeben, den ich erst am Donnerstag halten muss --- und habe das Montag erfahren

) - daher bin ich gerade zeitlich ein wenig gebunden ...

... ich habe aber bestimmt am Wochenende mal Zeit.

Viele Grüße,

Stefan

**lobo** · 15.11.2010, 22:28

Nee, nee, nee,

entweder ich bin zu doof (kann ja wirklich sein ...) oder da funktioniert was nicht.

Also ich habe jetzt folgende Konfigurationsdatei (nur das Wichtige):

Objects:

Code:

     <object type="1.001" id="1_7_50_LZ_Raumpanel_0" gad="1/7/50" flags="cwtuf" init="off" >(1/7/50)LZ_Raumpanel_0</object>
      <object type="5.xxx" id="1_3_3_LZRaumpanel" gad="1/3/3" flags="ctuf" init="persist">(1/3/3)LZRaumpanel</object>

Rules:

Code:

    <rule id="Aufruf_LZ_Raumpanel_01">
      <condition type="object" id="1_7_50_LZ_Raumpanel_0" value="on" trigger="true">
      </condition>
      <actionlist type="if-true">
        <action type="set-value" id="1_3_3_LZRaumpanel" value="0" />
      </actionlist>
    </rule>
    <rule id="Aufruf_LZ_Raumpanel_00">
      <condition type="object" id="1_7_50_LZ_Raumpanel_0" value="off" trigger="true">
      </condition>
      <actionlist type="if-true">
        <action type="set-value" id="1_3_3_LZRaumpanel" value="0" />
      </actionlist>
    </rule>

Jetzt schicke ich einfach immer wieder eine "1" an die 1/7/50 ... und möchte, dass Linknx immer mit "0" (8bit, also eigentlich 0x00) auf die 1/3/3 antwortet.

Das funktioniert aber leider nicht. Nur wenn zwischendurch irgendein anderes Telegramm kommt, wird die Regel wieder ausgeführt. Selbst wenn ich einfach eine Leseanforderung schicke, funktioniert es. Nicht jedoch, wenn KEIN Telegramm dazwischen ist:

Busmonitor:

Code:

#	Zeit		Service	Flags	Prio	Quelladr	Quelle			Zieladr	Ziel	Rout	DPT	Typ	Daten	
1	22:12:36.630	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
2	22:12:36.631	vom Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
3	22:12:36.660	vom Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/3/3	frei	7	1 Byte	Write	$00 | 0 %	
4	22:12:38.077	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
5	22:12:39.199	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
6	22:12:40.138	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
7	22:12:41.113	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
8	22:12:42.422	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
9	22:12:43.696	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
10	22:12:45.207	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	-	Read		
11	22:12:45.208	vom Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	-	Read		
12	22:12:46.732	zum Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
13	22:12:46.733	vom Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/7/50	LZ_Raumpanel_0	6	1 bit	Write	$01	
14	22:12:46.770	vom Bus	 	L	0.0.0	Keine gültige Quelladresse.	1/3/3	frei	7	1 Byte	Write	$00 | 0 %

... das zweite Telegramm ist übrigens eine Widerholung - das habe ich noch nicht gerafft, wie ich die vermeiden kann --- das ist aber ein anderes Thema.

Also bei mir klappt's einfach nicht --- Tru, hast Du noch eine Idee? Oder sonst jemand?

Viele Grüße,

Stefan

**Tru** · 17.11.2010, 22:15

Zitat von lobo Beitrag anzeigen

Also bei mir klappt's einfach nicht --- Tru, hast Du noch eine Idee? Oder sonst jemand?

Ich habe versucht deinen Code bei mir nachzubauen und bei mir funktionierts. Ich habe mit einem groupswrite auf das Trigger-Object sowohl einem 1.001 alsauch einem 5.xxx Objekt jedes Mal erfolgreich den Wert 0 schicken können, auch unmittelbar hintereinander. Ich sehe keinen Unterschied zu deinem Setup und verstehe es auch nicht.

Zu Debugging-Zwecken schlage ich vor, dass du in der Actionlist noch einen zusätzlichen Command einbaust wie

Code:

<action type="shell-cmd" cmd="echo test >> /tmp/out.log" />

Damit kannst du im linknx-log besser verifizieren, ob die Actionlist tatsächlich ausgeführt wird oder nicht. Ich blicke bei den Object-Flags nicht wirklich durch, aber vielleicht liegt es dort.

Gruss, Tru

**lobo** · 18.11.2010, 08:07

Danke, dass Du das getestet hast. Ich habe auch einen recht interessanten Thread auf SF (klick) eröffnet.

Wenn ich jetzt Deine Tests mit den Aussagen von Jens falte, schließe ich gerade linknx als "Schuldigen" aus. Verbleiben noch:

eibd
Weinzierl 750
Dockstar

... bzw. die Kombination daraus - z.B. dass die Version des eibd, die ich für die Dockstar habe, diesen Fehler macht. Ich habe gestern noch mit Makki kurz gechattet (war ja Mittwoch) und er hat auch eine von ihm getestete Version des eibd für Arm Architektur kompiliert. Ich werde jetzt folgendes testen:

Verwendung eines anderen eibd auf der Dockstar (aus dem Wiregate Repo)
Testweise installation des eibd auf einem anderen Rechner (x86-Laptop mit Ubuntu)
Die Geschichte mal vom Bus aus testen (Taster programmieren und dann damit triggern)

Viele Grüße,

Stefan

**lobo** · 20.11.2010, 01:09

Hallo,

die von Makki auf seinem wiregate-Repo zusammengestellten Dateien funktionieren tatsächlich viel besser bei mir (und das quasi auf Anhieb, nachdem ich erst mal dpkg nachinstalliert habe ...)

Damit war der Schuldige tatsächlich ein (warum auch immer) fehlerhafter eibd, der bei wiederholt gleichen Telegrammen diese wohl nicht weiter gab.

Vielen Dank nochmals für die Unterstützung!

Die nächsten Tage gehören dann mal der Regel-Erstellung

Ankündigung

- √ - Knxweb: Multiswitch sendet nicht!

- √ - Knxweb: Multiswitch sendet nicht!

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar