- √ - Linknx: Problem beim gleichzeitigen Lesen von >10 GA

[mode]

Hallo,

ich habe ein Problem mit meinem Linknx.
Meine Rule, die vor dem Schlafen gehen prüft, ob alle Fenster zu sind, wird durch Event "Nacht" getriggert.
Die Objekte für die Fenster sind im Linknx auf init=request parametriert. Nach einem Neustart des Linknx tritt folgender Fehler auf:

In der og. Rule befinden sich mit ca 20 ConditionalActions die Abfragen ob die Fenster offen sind (Objektwert = 0). Dann wird eine Nachricht an mein Handy verschickt.

        <rule id="check_nacht">
            <condition type="object" id="stat_nacht_aktiv" value="on" trigger="true"/>
            <actionlist type="if-true">
                <action type="conditional">
                    <condition type="object" id="tk_keller_aussen" value="off"/>
                    <action type="shell-cmd" cmd="message_knx.py Kellertuer West"/>
                    <action type="set-value" id="warnung_nacht" value="on"/>
                </action>
                <action type="conditional">
                    <condition type="object" id="tk_ht" value="off"/>
                    <action type="shell-cmd" cmd="message_knx.py Haustuer offen"/>
                    <action type="set-value" id="warnung_nacht" value="on"/>
                </action>
...
        </actionlist>
        </rule>

Alle Anfragen werde auch korrekt auf den Bus gesendet und zeitnah und korrekt beantwortet.

2013-01-22 09:12:54.926,A_GroupValue_Read,1.1.200,4/1/30,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:54.966,A_GroupValue_Read,1.1.200,4/1/40,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.007,A_GroupValue_Read,1.1.200,4/1/80,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.024,A_GroupValue_Response,1.1.150,4/1/30,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.048,A_GroupValue_Read,1.1.200,4/1/81,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.090,A_GroupValue_Read,1.1.200,4/1/82,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.108,A_GroupValue_Response,1.1.150,4/1/40,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.131,A_GroupValue_Read,1.1.200,4/1/83,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.149,A_GroupValue_Response,1.1.150,4/1/80,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.172,A_GroupValue_Read,1.1.200,4/1/90,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.190,A_GroupValue_Response,1.1.150,4/1/81,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.213,A_GroupValue_Read,1.1.200,4/1/110,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.231,A_GroupValue_Response,1.1.150,4/1/82,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.254,A_GroupValue_Read,1.1.200,4/1/111,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.272,A_GroupValue_Response,1.1.150,4/1/83,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.295,A_GroupValue_Read,1.1.200,4/1/120,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.313,A_GroupValue_Response,1.1.150,4/1/90,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.336,A_GroupValue_Read,1.1.200,4/1/121,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.375,A_GroupValue_Response,1.1.150,4/1/110,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.398,A_GroupValue_Read,1.1.200,4/1/122,00,0,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.416,A_GroupValue_Response,1.1.150,4/1/111,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.457,A_GroupValue_Response,1.1.150,4/1/120,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.556,A_GroupValue_Response,1.1.150,4/1/121,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.639,A_GroupValue_Response,1.1.150,4/1/122,01,1,DPT_Switch,1.001,0,low,7,T_DATA_XXX_REQ,0
2013-01-22 09:12:55.657,A_GroupValue_Response,1.1.150,4/1/122,01,1,DPT_Switch,1.001,1,low,7,T_DATA_XXX_REQ,0

Leider scheinbar nicht zeitnah für Linknx. Bei einigen Abfragen fehlt im Log der Eintrag "Object: New value on for object" dh Linknx hat den Wert, den es requestet hat nicht mitbekommen und geht daher von 0 aus, was Fenster auf bedeutet und die Nachricht rausschickt. Sehr unschön

Linknx ist über eibd und TP uart an den Bus angebunden. Auf dem Bus sieht alles gut aus. Nur linknx scheint zu ungeduldig zu sein. Ist das vielleicht ein Bug? Kann sonst noch was eingestellt werden?
@Linknx Gott Mumpf - hast du noch eine Idee?

Vg

Mode

[mode]

Schön, dass es Open Source gibt. Ich konnte das Problem selber finden und lösen.
Und zwar läuft die Response vom Lesen in einen Timeout. Der kann leicht hochgesetzt werden.
Datei objectcontroller.cpp
Zeile 304
von while (cnt < 100 && readPending_m)
nach while (cnt < 500 && readPending_m)
ändern.
Somit hat das Telegramm bis zu 5 Sekunden Zeit anzukommen. Eine Sekunde kann bei viele Anfragen schon zu wenig sein, wie mein Test zeigte.

VG

Mode

[greentux]

Wenn du das dem Maintainer noch mails

[mode]

Ob diese 5 Sekunden Timeout jetzt für jeden das Richtige sind kann ich aber nicht sagen. Kommt immer sehr auf die Umgebung und das, was man umsetzen will an. Am besten wäre es, den Wert in der XML Datei konfigurierbar zu machen.

[greentux]

Das können die bestimmt einbauen...