- √ - KNX-Plugin startet manchmal nicht

[JNK]

Hallo,

sh.py 0.9 auf einem Beaglebone Black mit aktuellem Debian Wheezy, plugin.conf relativ simpel:

[knx]
   class_name = KNX
   class_path = plugins.knx
   host = 192.168.0.51
#   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
#   busmonitor = False

host ist die Adresse des Wiregate mit TPUART. Wenn ich sh.py mit

bin/smarthome -n -d

starte, wird die Config eingelesen, und dann passiert (s. Screenshot). sh.py läuft danach weiter, aber es wird nichts vom KNX verarbeitet.

Kann man da was gegen machen? Ich habe ein bisschen die Befürchtung, dass das vielleicht auch mal passiert, wenn ich es nicht auf der Konsole starte und es dann nicht bemerke....

Gruss,

der Jan

[callidomus]

Hi Jan,

kannst Du manchmal nicht evtl. etwas näher spezifizieren? Passiert das nur wenn Du SH.py beendest und direkt neu startest? Oder passiert das auch nach einer Pause von sagen wir mal 30 Sekunden?

Ich habe in github eine kleine Änderung vorgenommen, die in diesem Fall die Verbindung zuverlässig unterbrechen sollte, dann wird sie erneut aufgebaut.
https://github.com/mknx/smarthome/bl...nx/__init__.py

Das eigentliche Problem wird dadurch aber nicht beseitigt :-(

Bis bald

Marcus

[JNK]

KNX-Plugin startet manchmal nicht

Hallo,

nun, "manchmal" ist im Augenblick leider genau das. Ich werde das aber mal im Auge behalten. Aber es ist schon so, dass ich meistens beendet und relativ schnell neu gestartet habe. Ich würde vermuten, in 90% der Fälle in weniger als 10s.

Ich beobachte das morgen nochmal, bevor ich den Fix ausprobiere.

Gruß,

der Jan

[JNK]

So, noch als Nachtrag: das passiert bei mir nach meinen Tests ausschliesslich, wenn ich schnell mit Strg-C beende und sofort neustarte, nicht aber, wenn ich länger warte.

Ich werde jetzt mal den Fix einbauen, testen und berichten.

Gruss,

der Jan

[callidomus]

Hallo Jan,

So, noch als Nachtrag: das passiert bei mir nach meinen Tests ausschliesslich, wenn ich schnell mit Strg-C beende und sofort neustarte, nicht aber, wenn ich länger warte.

danke für das Feedback, dann wird der Socket wohl nicht (richtig) geschlossen und beim nächsten Verbindungsaufbau werden einfach die Daten der alten Session weitergeschickt.

Ich sehe mir das heute Abend noch mal an.

Bis bald

Marcus

[JNK]

Das Problem ist leider nicht wirklich beseitigt. sh.py versucht zwar jetzt neu zu connecten, das geht aber auch immer schief, auch wenn man länger wartet. Das ist ein bisschen "es geht beim ersten mal oder garnicht". Leider reichen meine Python-Kenntnisse von letzter WOche bis heute noch nicht aus, um da wirklich was zu reissen.

Gruss,

der Jan

[callidomus]

Hi Jan,

welche Version setzt Du genau ein? Die erste Zeile nach dem Start zeigt mir das. Ich habe heute noch etwas an dem Code verbessert.

Danke

Marcus

[JNK]

er sagt 0.9:

2013-08-05 09:55:34,709 SmartHome.py INFO     Start SmartHome.py 0.9 -- smarthome.py:__init__:192
2013-08-05 09:55:34,712 SmartHome.py DEBUG    Python 2.7.3 -- smarthome.py:__init__:193
2013-08-05 09:55:34,715 SmartHome.py INFO     Init Scheduler -- scheduler.py:__init__:53
2013-08-05 09:55:34,718 SmartHome.py INFO     Init Plugins -- smarthome.py:__init__:208
2013-08-05 09:55:34,724 Scheduler    DEBUG    creating 5 workers -- scheduler.py:run:59
2013-08-05 09:55:34,729 SmartHome.py DEBUG    Plugin: knx -- plugin.py:__init__:42
2013-08-05 09:55:34,749 SmartHome.py DEBUG    Plugin: visu -- plugin.py:__init__:42
2013-08-05 09:55:34,800 SmartHome.py DEBUG    Plugin: notify -- plugin.py:__init__:42
2013-08-05 09:55:34,806 SmartHome.py DEBUG    Plugin: wettercom -- plugin.py:__init__:42
2013-08-05 09:55:34,847 SmartHome.py DEBUG    Plugin: rrd -- plugin.py:__init__:42
2013-08-05 09:55:34,892 SmartHome.py DEBUG    Plugin: sql -- plugin.py:__init__:42
2013-08-05 09:55:34,908 SmartHome.py DEBUG    SQLite 3.7.13 -- __init__.py:__init__:60

Heute aus dem git/develop gezogen. Macht aber immer noch das gleiche. Wenns einmal schief geht, gehts immer schief. Wenn Du willst, kann ich Dir das Log mal per Mail schicken.

Gruss,

der Jan

[JNK]

So, ich hab nen Fix, zumindest für mich.

lib/my asynchat.py (l. 55):

        try:
            self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
[COLOR=Red]            self.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)[/COLOR]
            self.settimeout(1)

plugins/knx/__init__.py (l. 133):

    def parse_length(self, length):
        self.parse_data = self.parse_telegram
        try:
            self.terminator = struct.unpack(">H", length)[0]
        except:
            logger.error("knx: problem unpacking length: {0}".format(length))
[COLOR=Red]            self.discard_buffers()[/COLOR]
            self.handle_close()

Damit passiert es zwar immer noch, dass beim Start der parse_length-Error auftaucht, aber der automatische zweite Versuch connected sauber. Jedes Mal.

Gruss,

der Jan

[callidomus]

Hallo Jan,

kannst Du bitte noch mal kurz gegen develop checken?

Ich haben Deinen Fix so ähnlich umgesetzt.
Das discard_buffers rufe ich im handle_close der my_asynchat auf, davon profitieren dann auch noch anderer Plugins.
https://github.com/mknx/smarthome/co...e94fc72dd0f5a9

Das socket.SO_REUSEADDR ist eigentlich für (Server-)Sockets hilfreich die ich selbst binde. Bei unserer Clientverbindung wird eigentlich ein freier Port verwendet um die Verbindung zum Server aufzubauen. Dieser wird nicht mehrmals verwendet.

Danke!

Marcus

[JNK]

Funktioniert genauso, habe ich dann auch so übernommen.

Gruss,

der Jan

[JNK]

Nachtrag:

2013-08-09 03:10:44,579 SmartHome.py DEBUG    knx: 1.1.254 set 5/2/1 to 20.25 -- __init__.py:parse_telegram:185
2013-08-09 03:10:45,041 SmartHome.py INFO     KNX: connection to 192.168.0.51:6720 closed -- my_asynchat.py:handle_close:103
2013-08-09 03:10:45,050 sh.con       DEBUG    knx: enable group monitor -- __init__.py:handle_connect:110
2013-08-09 03:10:45,062 sh.con       INFO     KNX: connected to 192.168.0.51:6720 -- my_asynchat.py:connect:69
2013-08-09 03:10:45,075 SmartHome.py CRITICAL Unhandled exception: (9, 'Bad file descriptor')
<class 'select.error'>
  File "bin/smarthome.py", line 493, in <module>
    sh = SmartHome()
  File "bin/smarthome.py", line 244, in __init__
    asyncore.loop(timeout=1, count=1, map=self.socket_map)
  File "/usr/lib/python2.7/asyncore.py", line 220, in loop
    poll_fun(timeout, map)
  File "/usr/lib/python2.7/asyncore.py", line 145, in poll
    r, w, e = select.select(r, w, e, timeout)
 -- smarthome.py:_excepthook:377
2013-08-09 03:10:53,358 Scheduler    DEBUG    wettercom next time: 2013-08-09 03:25:53+02:00 -- scheduler.py:_next_time:238

Unschön, danach hatte sich das mit dem KNX erledigt bis zum Neustart.

Gruss,

der Jan

Nachtrag:

1) Niko hatte das Problem wohl auch schon mit dem Russound
2) Asyncore select statement problem - Python
3) Python, asyncore, asynchat, error on Python 2.7.3 Mac ONLY Bad file descriptor - Stack Overflow

Ich werde das mit dem use_poll=True in asyncore.py mal probieren

[callidomus]

- √ - KNX-Plugin startet manchmal nicht

Hi Jan,

welche lib/my_asynchat und Plugin/knx verwendest Du? Aus dem develop branch?

Wie lauten den die Startparameter des eibd auf dem WG?

Bis bald

Marcus

[JNK]

lib/plugin: ja, aus dem develop branch

/usr/bin/eibd -e 1.1.254 -c -S -D -i -T --tpuarts-disch-reset --tpuarts-ack-all-group -d -u --pid-file=/var/run/eibd.pid -c tpuarts:/dev/ttyS0

[JNK]

Im Allgemien recovered das auch ganz gut:

2013-08-09 18:42:13,211 Scheduler    DEBUG    series next time: 2013-08-09 18:42:23+02:00 -- scheduler.py:_next_time:238
2013-08-09 18:42:14,809 SmartHome.py DEBUG    knx: 1.1.254 set 5/2/1 to 20.0 -- __init__.py:parse_telegram:185
error: uncaptured python exception, closing channel <plugins.knx.KNX connected 192.168.0.51:6720 at 0x472f80> (<type 'exceptions.IndexError'>:bytearray index out of range [/usr/lib/python2.7/asyncore.py|readwrite|108] [/usr/lib/python2.7/asyncore.py|handle_read_event|449] [/usr/lib/python2.7/asynchat.py|handle_read|140] [/usr/local/smarthome/plugins/knx/__init__.py|found_terminator|131] [/usr/local/smarthome/plugins/knx/__init__.py|parse_telegram|183] [/usr/local/smarthome/plugins/knx/__init__.py|decode|145] [/usr/local/smarthome/plugins/knx/dpts.py|de11|183])
2013-08-09 18:42:18,647 SmartHome.py INFO     KNX: connection to 192.168.0.51:6720 closed -- my_asynchat.py:handle_close:103
2013-08-09 18:42:23,258 Scheduler    DEBUG    series next time: 2013-08-09 18:42:33+02:00 -- scheduler.py:_next_time:238
2013-08-09 18:42:24,092 sh.con       DEBUG    knx: enable group monitor -- __init__.py:handle_connect:110
2013-08-09 18:42:24,105 sh.con       INFO     KNX: connected to 192.168.0.51:6720 -- my_asynchat.py:connect:69
2013-08-09 18:42:28,027 SmartHome.py DEBUG    knx: 1.1.254 set 5/3/200 to 78.431372549 -- __init__.py:parse_telegram:185
2013-08-09 18:42:28,069 SmartHome.py DEBUG    knx: 1.1.254 set 5/3/202 to 15.56 -- __init__.py:parse_telegram:185