Items vom KNX werden nicht geupdated bzw. auf den Bus geschrieben

[Robert]

Hallo!

Habe das (seltsame?) Phänomen, dass alle KNX-Items beim Starten korrekt aus dem Cache des eibd gelesen werden (stimmt mit realem Zustand überein), dann aber im weiteren Verlauf nicht mehr geupdated werden (sprich: ihren Zustand nicht mehr ändern, obwohl in der Realität der Zustand wechselt).

Gleichzeitig werden sie auch nicht mehr geschrieben, wenn sie über eine Visu (hier: smartVISU) geändert wurden.

Die Änderungen über die Visu tauchen im sh-Log korrekt auf, von den "Write" oder "Response"-Telegrammen auf dem KNX nimmt sh auch im Debug-Modus überhaupt keine Notiz.

Unter "implizieren" in der Doku verstehe ich: wenn ich knx_cache angebe, dann muss ich für die gleiche GA nicht noch knx_listen angeben? So oder so sollte dann auch knx_send funktionieren!?

plugin.conf:

[knx]
    class_name = KNX
    class_path = plugins.knx
    host = 127.0.0.1
    port = 6720
#   send_time = 600 # update date/time every 600 seconds, default none
#   time_ga = 1/1/1 # default none
#   date_ga = 1/1/2 # default none
[visu]
    class_name = WebSocket
    class_path = plugins.visu
#    ip='127.0.0.1'
#    port=2424
    visu_dir = /var/www/smarthome
    smartvisu_dir = /var/www/smartVISU
[sql]
    class_name = SQL
    class_path = plugins.sqlite
[ow]
    class_name = OneWire
    class_path = plugins.onewire
    host = 127.0.0.1
    port = 4304

Ausschnitt auf /items/kellergeschoss.conf

[Hobbyraum]
  [[Fenster_verriegelt]]
    type = bool
    visu = yes
    knx_dpt = 1
    knx_cache = 6/0/50
  [[Deckenlicht]]
    type = bool
    visu = yes
    knx_dpt = 1
    knx_send = 1/0/3
    knx_cache = 1/0/4
  [[Steckdosen]]
    type = bool
    visu = yes
    knx_dpt = 1
    knx_send = 3/0/3
    knx_cache = 3/0/4

Hat jemand eine Idee?

Viele Grüße
Robert

[callidomus]

Hi Robert,

kannst Du bitte mal das Logfile im Debugmodus und die Plugin.conf posten?

Ich komme aber frühestens heute Abend dazu mir das näher anzusehen.

Bis bald

Marcus

[TCr82]

Hi Robert,

kannst Du bitte mal das Logfile im Debugmodus und die Plugin.conf posten?

siehe hier: https://knx-user-forum.de/smarthome-...rbehebung.html

[Robert]

Hallo Marcus,

die plugin.conf ist oben schon angegeben! Das Debug-Log hängt an (bitte das pdf wegmachen, ist ein txt!), zeigt aber imho nichts erhellendes. Die Fehler mit dem einem 1W-Sensor kommen schlicht daher, dass dieser nicht angeklemmt ist.

Interessant ist noch: Alle Onewire-Sachen werden auch während der Ausführung kontinuierlich aktualisiert. Es scheint also eher ein spezifisches Problem des KNX-Plugins zu sein.

Vielen Dank!

Robert

[TCr82]

hast du mal

knx_listen = 2/1/130
knx_init = 2/1/130

statt

knx_cache = 1/2/3

gemacht? Evtl. läuft da was mit dem cache schief?

[callidomus]

Hallo Robert,

ja sorry die Plugin.conf habe ich nicht wahrgenommen. Habe den Thread auf dem Handy gelesen und dort nicht gesehen.

Wenn man `knx_cache` oder auch `knx_init`angibt, dann impliziert das `knx_listen`.

Und mit "Gleichzeitig werden sie auch nicht mehr geschrieben, wenn sie über eine Visu (hier: smartVISU) geändert wurden." meinst Du das sie nicht auf den KNX Bus gesendet werden, oder?

Kannst Du bitte mal in der 'plugins/knx/__init__.py' Zeile 105-110 (Methode collect_incoming_data) die '#' entfernen und bitte auf die Einrückung achten.
Siehst Du dann weiterhin KNX Pakete?

Was passiert dann wenn Du Deine Item-Konfigurationen mal aus dem `items` entfernst? Siehst Du dann noch KNX Output?

Was passiert wenn Du die anderen Plugins mal auskommentierst und nur das KNX-Plugin läuft? Siehst Du dann noch KNX Output?

Sorry für die vielen Fragen, aber es schwer den Fehler nachzuvollziehen.

Bis bald

Marcus

[Robert]

Und mit "Gleichzeitig werden sie auch nicht mehr geschrieben, wenn sie über eine Visu (hier: smartVISU) geändert wurden." meinst Du das sie nicht auf den KNX Bus gesendet werden, oder?

Ja, korrekt.

Kannst Du bitte mal in der 'plugins/knx/__init__.py' Zeile 105-110 (Methode collect_incoming_data) die '#' entfernen und bitte auf die Einrückung achten.
Siehst Du dann weiterhin KNX Pakete?

Anfangs beim Init mit Abfrage des Caches sehe ich nun zusätzlich die bin/hex/dez Darstellung der eingehenden Antworten. Im späteren Verlauf wenn ich über die Visu einen Schalter toggle, sehe ich nun aber nichts mehr!

vorher (ohne Modifikation, nur zu Verdeutlichung!):

2013-05-12 12:25:19,325 SmartHome.py DEBUG    192.168.178.24:49650 sent '{"cmd":"item","id":"Hobbyraum.Deckenlicht","val":"1"}' -- __init__.py:json_parse:257
2013-05-12 12:25:19,341 SmartHome.py INFO     Hobbyraum.Deckenlicht = True via Visu 192.168.178.24:49650 -- item.py:_update:214
2013-05-12 12:25:19,798 SmartHome.py DEBUG    192.168.178.24:49650 sent '{"cmd":"item","id":"Hobbyraum.Deckenlicht","val":"0"}' -- __init__.py:json_parse:257
2013-05-12 12:25:19,805 SmartHome.py INFO     Hobbyraum.Deckenlicht = False via Visu 192.168.178.24:49650 -- item.py:_update:214
2013-05-12 12:25:20,308 SmartHome.py DEBUG    192.168.178.24:49650 sent '{"cmd":"item","id":"Hobbyraum.Deckenlicht","val":"1"}' -- __init__.py:json_parse:257
2013-05-12 12:25:20,316 SmartHome.py INFO     Hobbyraum.Deckenlicht = True via Visu 192.168.178.24:49650 -- item.py:_update:214

Ändere ich die GA über den Bus (realer Lichtschalter) sehe ich so oder so keine Ausgabe.

Was passiert dann wenn Du Deine Item-Konfigurationen mal aus dem `items` entfernst? Siehst Du dann noch KNX Output?

JA! - interesanterweise eben auch die GAs die vorher nicht wollten!

2013-05-12 12:37:44,197 SmartHome.py DEBUG    1.1.24 set 1/0/4 to 1 -- __init__.py:parse_telegram:160

[COLOR=red][COLOR=black]2013-05-12 12:37:44,770 SmartHome.py DEBUG    1.1.110 set 1/0/3 to 0 -- __init__.py:parse_telegram:160[/COLOR]
[COLOR=black]2013-05-12 12:37:44,806 SmartHome.py DEBUG    1.1.24 set 1/0/4 to 0 -- __init__.py:parse_telegram:160[/COLOR]
[COLOR=black]2013-05-12 12:37:45,375 SmartHome.py DEBUG    1.1.110 set 1/0/3 to 1 -- __init__.py:parse_telegram:160[/COLOR]
[COLOR=black]2013-05-12 12:37:45,398 SmartHome.py DEBUG    1.1.24 set 1/0/4 to 1 -- __init__.py:parse_telegram:160[/COLOR]
[COLOR=black]2013-05-12 12:37:45,994 SmartHome.py DEBUG    1.1.110 set 1/0/3 to 0 -- __init__.py:parse_telegram:160[/COLOR]
[COLOR=black]2013-05-12 12:37:46,030 SmartHome.py DEBUG    1.1.24 set 1/0/4 to 0 -- __init__.py:parse_telegram:160[/COLOR]
[COLOR=black]2013-05-12 12:37:46,665 SmartHome.py DEBUG    1.1.110 set 1/0/3 to 1 -- __init__.py:parse_telegram:160[/COLOR]
[/COLOR]

Was passiert wenn Du die anderen Plugins mal auskommentierst und nur das KNX-Plugin läuft? Siehst Du dann noch KNX Output?

Stell ich erst mal zurück. Ich kommentier jetzt einzeln die Item-Dateien wieder ein... (hatte das ganze Verzeichnis umbenannt/neu erstellt).

Vielen Dank für Deine Hilfe!

Grüße
Robert

[Robert]

Das Einfügen einer Datei mit Onewire-Items ändert nichts - funktioniert dann (ich sehe KNX-Traffic!)

Das Einfügen einer weiteren Datei "uebergeordnet.conf" mit KNX-Items führt dann dazu, dass kein KNX-Traffic mehr angezeigt wird...

uebergeordnet.conf (vollständig!)

[Wetterstation]
  [[Stoerung]]
    type = bool
    visu = yes
    knx_dpt = 1
    knx_cache = 6/4/201
 
[DALI_Gateway]
  [[Stoerungen]]
    [[[DALI]]]
      type = bool
      visu = yes
      knx_dpt = 1
      knx_cache = 6/4/202
    [[[Lampen]]]
      type = bool
      visu = yes
      knx_dpt = 1
      knx_cache = 6/4/203
    [[[EVG]]]
      type = bool
      visu = yes
      knx_dpt = 1
      knx_cache = 6/4/204
 
[EA_Konzentrator]
  [[Stoerung]]
    type = bool
    visu = yes
    knx_dpt = 1
    knx_cache = 6/4/205

Scheinbar geht da was kaputt?

Grüße
Robert

[callidomus]

Hallo Robert,

post bitte mal das Debug-Log mit dem Hex-Output.

Danke

Marcus

[Robert]

Wie gesagt, es wird dann nichts ausgegeben. Die KNX-Pakete werden einfach ignoriert und tauchen im Log nicht auf.

Weiter:

Ersetze ich alle knx_cache gegen knx_listen ODER knx_init (ja, sogar das!) funktioniert es. Schreibe ich nur ein mal knx_cache, funktioniert es nicht mehr.

Was ist der Unterschied? (klar, also das Nutzen des eibd-Cache... - aber wie?)

Kann es sein, dass der parallel laufende wiregated da rumpfuscht?

Grüße
Robert

/edit:

Habe jetzt in der __init__.py vom KNX-Plugin die Zeilen 74/75 auskommentiert, die abhängig von "cache" das an den eibd zu sendende Paket modifiziert. Dann funktioniert es - natürlich wird dann nicht der Cache benutzt... Überlege mittlerweile, ob der eibd irgendwie spinnt?

//edit:

Bevor Nachfragen kommen: eibd 0.0.5, mit Groupcache. Der ist auch enabled und funktioniert (mit Busmonitor und groupcacheread bzw. groucachedis/enable getestet...).

[2ndsky]

Items vom KNX werden nicht geupdated bzw. auf den Bus geschrieben

Das hört sich nach dem gleichen Problem an, das ich mal hatte (siehe Github Issues). Marcus hatte das mal gefixt und ein kurzer Test hat auch funktioniert. Aber um ehrlich zu sein hab ich das nach dem Test nicht weiter verfolgt und auch nicht mehr verwendet.

[Robert]

Hi Nico, da finde ich nur 3 Issues - keiner davon klingt passend?

Also, wenn ich im Plugin "knx_cache" wie "knx_init" behandeln lasse (kein "pkt[1] = 116" beim groupread), funktioniert ALLES - schreiben, lesen. Sprich ich kann über die Visu mein Licht ein- und ausschalten bzw. die Änderungen per realem Taster werden nachvollzogen.
Es hängt definitiv an dieser Stelle!

Grüße
Robert

[callidomus]

Hallo Robert,

danke für den Input. Ich werde mir das mal näher ansehen. Allerdings erst heute Abend.

bis bald

Marcus

[Robert]

weiter:

hab mir EIBConnection.py vom BCUSDK angeschaut - stimmt ja überein. Teilweise blick ich nicht ob 116 oder 117. Paar Debug-Ausgaben - passt aber alles.

Aber: Wenn ich bei laufendem smarthome.py den eibd neustarte, und nach der Unterbrechung die Verbindung wieder hergestellt wird, funktioniert alles wieder. Irgendwie wird also der eibd durcheinander gebracht. Muss evtl. der Cache erst je nach Verbindung eingeschaltet werden?

Grüße
Robert

[Robert]

So, habe es jetzt - mehr oder minder schön - gelöst.

Blick ins Debug-Log des eibd (Layer 3 & 4 reichen):

mit der 116 (Cache)

Layer 4(0010B7C0,518FB3FA) OpenGroupSocket RW
Layer 3(00064B50,518FB3FA) registerGroup 0010B7C0
Layer 3(00064B50,518FB3FA) registerGroup 0010B7C0 = 1
[B][COLOR=Red]Layer 4(0010B7C0,518FB3FA) CloseGroupSocket
Layer 3(00064B50,518FB3FA) deregisterGroupCallBack 0010B7C0 = 1[/COLOR][/B]
Layer 4(000B6298,518FB3FA) GroupCacheRead 1/1/14 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.31
Layer 4(000B6298,518FB3FA) GroupCacheRead 6/2/6 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.165
Layer 4(000B6298,518FB3FA) GroupCacheRead 6/4/205 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.41
Layer 4(000B6298,518FB3FA) GroupCacheRead 6/4/204 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.11
Layer 4(000B6298,518FB3FA) GroupCacheRead 6/4/203 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.11
Layer 4(000B6298,518FB3FA) GroupCacheRead 6/4/202 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.11
Layer 4(000B6298,518FB3FA) GroupCacheRead 6/4/201 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.230
Layer 4(000B6298,518FB3FA) GroupCacheRead 1/2/14 1 0
Layer 4(000B6298,518FB3FA) GroupCache found: 1.1.31

ohne die 116:

Layer 4(0011A8F0,518FB5FF) OpenGroupSocket RW
Layer 3(00064B50,518FB5FF) registerGroup 0011A8F0
Layer 3(00064B50,518FB5FF) registerGroup 0011A8F0 = 1
Layer 4(0011A8F0,518FB5FF) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(00064B50,518FB5FF) Send L_Data low from 0.0.0 to 1/1/15 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(00064B50,518FB5FF) Recv LPDU: BC 11 00 09 0F F1 00 00 A5 :L_Data low from 1.1.0 to 1/1/15 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(00064B50,518FB5FF) Recv L_Data low from 1.1.0 to 1/1/15 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 4(0011A8F0,518FB5FF) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(00064B50,518FB5FF) Send L_Data low from 0.0.0 to 1/1/14 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 4(000B8110,518FB5FF) Recv GroupSocket(002): 00 00
Layer 4(0011A8F0,518FB5FF) Recv GroupSocket(002): 00 00
Layer 3(00064B50,518FB5FF) Recv LPDU: CC :ACK
Layer 4(0011A8F0,518FB5FF) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(00064B50,518FB5FF) Send L_Data low from 0.0.0 to 6/2/6 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 4(0011A8F0,518FB5FF) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(00064B50,518FB5FF) Send L_Data low from 0.0.0 to 6/4/205 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 4(0011A8F0,518FB5FF) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read

Irgendwie wird der überfahren...

Wenn ich jetzt im KNX-Plugin am Ende von "handle_connect" ein wiederholtes init sende, funktioniert es, da er einen neuen Socket? aufmacht. Dann funktioniert alles wie gewünscht...

    def handle_connect(self):
        self.discard_buffers()
        init = [0, 38, 0, 0, 0]
        self._send(init)
        self.terminator = 2
        self.parse_data = self.parse_length
        if self._init_ga != {}:
            if self.is_connected:
                logger.debug('knx: read init/cache ga')
                for ga in self._init_ga:
                    self.groupread(ga, self._init_ga[ga])
                self._init_ga = {}
[B][U][COLOR=Red]        self._send(init)[/COLOR][/U][/B]

Grüße
Robert