knx_reply keine Antwort

[mediaimprove]

Hallo zusammen,
nachdem ich nun am Ende des Tages alleine doch nicht mehr weiter weis bitte ich um eure Hilfe, die Suche hat mich leider nicht auf die richtige Spur gebracht. Ich habe auf einem Pi2 sh+eibd+Weinzierl IP 730 laufen (Installiert nach dieser Anleitung, also nicht mit fertigem Image). Funktioniert bisher seit einigen Wochen wunderbar und ohne Probleme.

Nun habe ich aber folgendes Item:
[[[[heizung]]]]
[[[[[ist]]]]]
type = num
visu_acl = rw
knx_dpt = 9
knx_send = 1/4/80
#knx_reply = 1/4/80
sqlite = yes
ow_addr = 28.9257B6050000
ow_sensor = T

Auch das funktioniert soweit, zum Problem kommt es aber wenn ich knx_reply verwenden möchte. Per ETS kann ich die GA genau ein Mal auslesen, (Temperatur wird richtig ausgegeben, auffällig ist nur das der Response vor dem Read erscheint). Alle weiteren Read Requests werden nicht mehr beantwortet, erst nach dem Neustart von eibd wird wieder einmalig ein Response erzeugt. Siehe Bild im Anhang.

Habt ihr einen Ansatzpunkt oder eine Idee in welche Richtung das Problem gehen könnte? Mit welchen Logs kann ich euch versorgen? eibd wird mit folgendem Parameter gestartet: --daemon --Server --Tunnelling --Discovery --GroupCache --no-tunnel-client-queuing --listen-tcp --pid-file=/var/run/eibd.pid --eibaddr=0.0.1 ipt:knx01.xxx.de

sh gibt folgende Debug Meldung beim 1. Request aus, bei den darauf folgenden ist im Log nichts zu finden :
2015-05-20 21:23:34,613 DEBUG Main KNX: 15.15.252 read 1/4/80 -- __init__.pyarse_telegram:203
2015-05-20 21:23:34,619 DEBUG Main knx: 0.0.0 set 1/4/80 to 0c5e -- __init__.pyarse_telegram:181


UPDATE: Wird von ETS aus auf die GA geschrieben ist diese daraufhin wieder einmal mit dem richtigen Wert lesbar.


Vielen Dank für eure Unterstützung!
Daniel bild.PNG

[JanT]

Hallo Daniel,

mir ist nicht ganz klar warum Du knx_reply verwenden möchtest. Der Temperaturwert wird erst dann vom 1-Wire gelesen wenn das onewire Plugin ein neuen Zyklus durchläuft (Konfigurationspunkt cycle= in plugin.conf) und wird - falls sich der Wert geändert hat - dann auf dem KNX-Bus geschrieben. Wenn Du nach jedem Zyklus auf dem KNX-Bus schreiben möchtest, kannst Du das erreichen in dem Du enforce_updates = true setzt. Ein Leseaufforderung wird nur den letzen Wert noch mal schreiben. Hast Du versucht unterschiedlichen Gruppenaddressen für das schreiben und die Rückmeldung zu setzen?

Viele Grüße,

Jan

[callidomus]

Hallo,

das klingt ja komisch.

Ein paar Fragen/Anregungen:
- Siehst Du im Log andere KNX Buskommunikation nachdem Du das Read geschickt hast? Oder 'steht' der Bus aus SH.py Sicht?
- Was passiert wenn Du das --GroupCache weg lässt?
- Hinter knx01.xxx.de steckt schon eine lokale IP-Adresse?

Bis bald

Marcus

[mediaimprove]

Hallo,

mir ist nicht ganz klar warum Du knx_reply verwenden möchtest.

In diesem Anwendungsfall gebe ich dir natürlich Recht, ein einfaches knx_send würde reichen und funktioniert auch soweit, trotzdem zeigt ein knx_reply ganz unanbhängig von 1wire immer das gleiche Verhalten (hab es mit einem einfachen value= im Item gegengeprüft). Und dieses Problem würde ich gerne lösen, ganz unabhängig von diesem Anwendungsfall.

Hast Du versucht unterschiedlichen Gruppenaddressen für das schreiben und die Rückmeldung zu setzen

Habe ich gerade versucht, mit identischem Ergebnis.

Siehst Du im Log andere KNX Buskommunikation nachdem Du das Read geschickt hast? Oder 'steht' der Bus aus SH.py Sicht?

Aus meiner Sicht steht der Bus nicht, es werden weiterhin Telegramme empfangen und versendet:

2015-05-21 07:46:20,359 DEBUG    Main         KNX: 15.15.252 read 1/1/2 -- __init__.py:parse_telegram:203
2015-05-21 07:46:20,402 DEBUG    Main         knx: 1.1.4 set 1/1/2 to False -- __init__.py:parse_telegram:190
2015-05-21 07:46:48,606 DEBUG    Main         KNX: 15.15.252 read 1/4/85 -- __init__.py:parse_telegram:203
2015-05-21 07:46:48,611 DEBUG    Main         knx: 0.0.0 set 1/4/85 to 0c68 -- __init__.py:parse_telegram:181
2015-05-21 07:47:26,806 DEBUG    Main         knx: 1.1.126 set 1/7/1 to 401.92 -- __init__.py:parse_telegram:190
2015-05-21 07:47:26,809 DEBUG    Main         Item haus.zentral.wetterstation.helligkeit = 401.92 via KNX 1.1.126 1/7/1 -- item.py:__update:363
2015-05-21 07:48:10,589 DEBUG    Main         KNX: 15.15.252 read 1/4/85 -- __init__.py:parse_telegram:203
2015-05-21 07:48:10,594 DEBUG    Main         knx: 0.0.0 set 1/4/85 to 0c68 -- __init__.py:parse_telegram:181
2015-05-21 07:49:56,569 DEBUG    Scheduler    1w-sen next time: 2015-05-21 07:54:56+02:00 -- scheduler.py:_next_time:289
2015-05-21 07:50:03,140 DEBUG    env_stat     Item env.core.threads = 7 via Logic None None -- item.py:__update:363
2015-05-21 07:50:03,147 DEBUG    env_stat     Item env.core.memory = 19660800 via Logic None None -- item.py:__update:363
2015-05-21 07:50:03,152 DEBUG    env_stat     Item env.system.load = 0.02 via Logic None None -- item.py:__update:363
2015-05-21 07:50:03,505 INFO     1w-sen       1-Wire: problem reading 28.9257B6050000 -- __init__.py:_sensor_cycle:384
2015-05-21 07:50:03,506 DEBUG    1w-sen       1-Wire: sensor cycle takes 7.440896987915039 seconds -- __init__.py:_sensor_cycle:399
2015-05-21 07:50:03,598 DEBUG    Scheduler    env_stat next time: 2015-05-21 07:55:03+02:00 -- scheduler.py:_next_time:289
2015-05-21 07:50:19,153 INFO     autoblind    Updating positions -- __init__.py:update_positions:89
2015-05-21 07:50:19,156 INFO     autoblind    Update position of haus.eg.wohnen.jalosie_links -- AutoBlindItem.py:update_position:155
2015-05-21 07:50:19,184 INFO     autoblind    Update position of haus.eg.wohnen.jalosie_rechts -- AutoBlindItem.py:update_position:155
2015-05-21 07:50:19,212 INFO     autoblind    Update position of haus.eg.wohnen.jalosie_mitte -- AutoBlindItem.py:update_position:155
2015-05-21 07:50:19,655 DEBUG    Scheduler    autoblind next time: 2015-05-21 07:55:19+02:00 -- scheduler.py:_next_time:289
2015-05-21 07:52:12,703 DEBUG    Main         knx: 0.0.0 set 1/3/81 to 01 -- __init__.py:parse_telegram:181
2015-05-21 07:52:12,963 DEBUG    Main         knx: 1.1.10 set 1/3/83 to True -- __init__.py:parse_telegram:190
2015-05-21 07:52:13,960 DEBUG    Main         knx: 1.1.10 set 1/3/84 to 255 -- __init__.py:parse_telegram:190
2015-05-21 07:52:13,962 DEBUG    Main         Item haus.og.schlafen.licht.dim = 255 via KNX 1.1.10 1/3/84 -- item.py:__update:363
2015-05-21 07:52:17,208 DEBUG    Main         192.168.1.247:61527 sent '{"cmd":"item","id":"haus.og.schlafen.licht","val":0}' -- __init__.py:json_parse:270
2015-05-21 07:52:17,211 DEBUG    Main         Item haus.og.schlafen.licht = False via Visu 192.168.1.247:61527 None -- item.py:__update:363
2015-05-21 07:52:17,218 DEBUG    Main         knx: 0.0.0 set 1/3/81 to 00 -- __init__.py:parse_telegram:181
2015-05-21 07:52:17,470 DEBUG    Main         knx: 1.1.10 set 1/3/83 to False -- __init__.py:parse_telegram:190
2015-05-21 07:52:18,474 DEBUG    Main         knx: 1.1.10 set 1/3/84 to 0 -- __init__.py:parse_telegram:190
2015-05-21 07:52:18,477 DEBUG    Main         Item haus.og.schlafen.licht.dim = 0 via KNX 1.1.10 1/3/84 -- item.py:__update:363
2015-05-21 07:52:27,070 DEBUG    Main         knx: 1.1.126 set 1/7/1 to 430.72 -- __init__.py:parse_telegram:190
2015-05-21 07:52:27,074 DEBUG    Main         Item haus.zentral.wetterstation.helligkeit = 430.72 via KNX 1.1.126 1/7/1 -- item.py:__update:363

Was passiert wenn Du das --GroupCache weg lässt?

GroupCache weglassen zeigt ebenfalls ein identisches Ergebnis, siehe Bild.

Hinter knx01.xxx.de steckt schon eine lokale IP-Adresse?

Hier steckt eine lokale IP dahinter, richtig.


Interessant ist wiederrum der Gruppentelegrammauszug aus der ETS. Wert wird wieder einmal richtig gelesen (nun unter 1/4/85). Der PM im Wohnzimmer sendet den aktuellen Lichtwert, danach ist wieder ein erfolgreiches lesen der 1/4/85 möglich. Aber anschließend nicht mehr. Das Verhalten lässt sich reproduzieren in dem man beliebige Telegramme sendet.



bild2.JPG

Grüße
Daniel

[callidomus]

Hallo Daniel,

für mich ist es sehr schwer Dir zu helfen. Da ich ein Problem bei dem eibd im Zusammenhang mit Deiner Schnittstelle vermute.
Ich teste hier ein neues KNX Plugin, das den eibd überflüssig macht. Dauert aber noch bis zum Release...

Bis bald

Marcus

[mediaimprove]

Hallo Marcus,

kein Problem, trotzdem vielen Dank! Es hilft mir schon mal weiter wenn du aus sh Sicht keine Problemursache siehst. Dann werden ich weiter im Bereich eibd suchen und bin auf das neue KNX Plugin gespannt.

Viele Grüße
Daniel

[Stefan BaWue]

auffällig ist nur das der Response vor dem Read erscheint

Das habe ich, wenn als Interface für den ETS Gruppenmonitor eibd wähle.
Wähle ich im ETS Gruppenmonitor meinen MDT-KNX-Router als Interface stimmt die Reihenfolge.

[Glotzkowski]

Hallo zusammen,

sorry für das aufwärmen dieses alten Threads.
Ich habe ein ähnliches Problem mit knx_reply.

Folgende Konstellation:
BananaPi mit smarthomeNG 1.2 und smartVISU 2.8, sowie knxd 0.12.14 und am Bus ein MDT IP Interface.

knxd läuft mit folgenden Parametern:
/usr/bin/knxd -e 1.1.240 -E 1.1.230:232 -c -b ipt:192.168.0.30

Prinzipiell funktioniert bisher alles einwandfrei, wenn ich über smarthomeNG Telegramme via IP Interface auf den Bus schicke.
Temperaturdaten und Schaltzustände vom Bus werden auch einwandfrei vom Bus zu smarthomeNG übertragen.
Wenn ich allerdings Gruppenadressen im smarthomeNG definiere und diese vom Bus aus (z.B. von einer MDT LED-Anzeige) auslesen lassen möchte, kommt keine Antwort.
Im ETS ist die Anfrage zur entsprechenden GA zu sehen.
Wenn ich smarthomeNG im Debug laufen lassen, kommt von der Anfrage auf dem Bus nichts im smarthomeNG an.
Mit dem knxtool (auf dem BananaPi) und dem busmonitor1 kann ich sehen, dass die Anfrage vom Bus beim BananaPi ankommt.
Hier z.B. eine entsprechende Item-Konfiguration:

[[Alarmanlage]]
[[[Status]]]
type = bool
cache = yes
knx_dpt = 1
knx_send = 10/1/0
knx_reply = 10/1/0
[[[Alarm]]]
type = bool
cache = yes
knx_dpt = 1
knx_send = 10/1/10
knx_reply = 10/1/10

Wenn ich die Alarmanlage aktiviere wird dies auf den Bus übertragen, wenn ich dann allerdings vom Bus aus den Status der Alarmanlage abfragen möchte kommt keine Antwort.
Das Problem ist auch unabhängig vom IP Interface, da ich vorher eine ROT-Schnittstelle am BananaPi hatte und da das gleiche Problem bestand.

Hat dazu jemand einen Tip für mich?

Danke vorab!

Grüße
Mike

[Msinn]

Mir ist nicht ganz klar was Du erreichen willst. Du hast aber eine ungewöhnliche Kombination der knx Parameter gewählt.

Wenn ich von SmartHomeNG z.b. Auf einen Aktor zugreifen will (mit Rückmeldung), nehme ich knx_send und knx_listen (oder knx_init bzw. knx_cache).

Wenn ich vom KNX Bus auf SmartHomeNG zugreife und dabei SmartHomeNG wie einen Aktor nutze (z.B. um Philips Hue zu steuern), nehme ich knx_status und knx_reply.

[Glotzkowski]

Deine Vermutung ist schon richtig, smarthomeNG soll in diesem Fall als "KNX Gerät" genutzt werden.
Ich möchte eine GA aus smarthomeNG lesen und den Status auf einer LED Anzeige ausgeben.
Ich habe im smarthomeNG eine Logik für eine Alarmanlage definiert und auf der LED Anzeige soll signalisiert werden, ob diese an oder aus ist.
Wenn ich die Alarmanlage über smarthoneNG aktiviere oder deaktiviere wird ein entsprechendes Telegramm auf den Bus gesendet und die LED Anzeige zeigt den korrekten Status.
Wenn nun aber die LED Anzeige z.B. durch Spannungsausfall oder Reprogrammierung neu gestartet wird, soll diese ja wieder den korrekten Status anzeigen und muss dazu die GA abfragen. Die funktioniert auch für Stati welche die LED Anzeige von anderen KNX Geräten abfragt, nur eben nicht für Stati vom smarthomeNG.
Ich konnte auch feststellen, dass ich andere GA wie z.B. Uhrzeit auch nicht von smarthomeNG abfragen kann, wenn diese als Item definiert werden.
Mir scheint es so, als ob knxd bestimmte Telegramme oder GA nicht an smarthomeNG weiter reicht.

Deinen Vorschlag habe ich getestet, es kommt leider weiterhin keine Antwort.