Module für pilight (Senden und Empfangen)

[Risiko]

Hi. Habe das Problem erkannt.
Das Protokoll ist etwas eigenwillig. Hat unitcode als Haupt-ID, wo alle anderen Protokolle ID haben.
Ich habe eine neue Version eingecheckt

[Pati_Alpha]

Jetzt läuft es!!!! Top!!!

Riesen Dank an dich!!!

Ich wette bald wird man sich dank dieser Module fragen, wozu man überhaupt noch ein CuL433 braucht!

[Pati_Alpha]

Nachtrag: beim Protokoll "elro_800_contact" passiert das gleiche wie vorher beim ev1527: es bleibt auf defined und sonst passiert nichts. Ist vielleicht der gleiche Bug an anderer Stelle?

[Pati_Alpha]

Noch ein Nachtrag (sorry fürs Spammen):

Es ist wie verhext, jetzt schaltet mein Gartenlicht auch nur noch auf "defined".

Code ist folgender:

Code Auswählen Erweitern

define GartenVorneLampe pilight_switch kaku_switch 19162090 0
attr GartenVorneLampe IODev pilight
attr GartenVorneLampe alias GartenVorne
attr GartenVorneLampe group Licht
attr GartenVorneLampe room Homekit,Garten
attr GartenVorneLampe sortby 1

Ansonsten interagiert absolut nichts mit dem device (DOIFs oder sonstiges). Wenn ich im Webinterface auf "on" klicke geht das Licht zwar an, aber der Status bleibt "defined". Bei anderen "pilight_switch" Geräten, die andere Protokolle nutzen geht es aber und hier ging es vorher auch...! :/

[Risiko]

Ansonsten interagiert absolut nichts mit dem device (DOIFs oder sonstiges). Wenn ich im Webinterface auf "on" klicke geht das Licht zwar an, aber der Status bleibt "defined". Bei anderen "pilight_switch" Geräten, die andere Protokolle nutzen geht es aber und hier ging es vorher auch...! :/

Verbose wieder auf 5  stellen (ctrl und switch) und mal schauen was da ankommt.
Vielleicht ist da doch ein Fehler rein gekommen. Ich selbst habe keine Probleme festgestellt!

[Pati_Alpha]

Code Auswählen Erweitern

2016.11.17 22:45:09 5: Cmd: >set GartenVorneLampe off<
2016.11.17 22:45:09 5: GartenVorneLampe(Set): off 1 of 1
2016.11.17 22:45:09 4: pilight(Write): RCV (pilight_switch) -> GartenVorneLampe,off
2016.11.17 22:45:09 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":19162090,"unit":0,"off":1}}
2016.11.17 22:45:09 5: pilight(SendNonBlocking): queue size 1
2016.11.17 22:45:09 4: BlockingCall (pilight_ctrl_Send): created child (6595), uses telnetForBlockingFn_1479413966 to connect back
2016.11.17 22:45:09 4: name: /fhem?cmd.GartenVorneLampe=set%20GartenVorneLampe%20off&room=Garten&XHR=1&fw_id=813 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.17 22:45:09 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":19162090,"unit":0,"off":1}}
2016.11.17 22:45:09 4: pilight(Send): RCV -> {"status":"success"} 
2016.11.17 22:45:09 4: Connection accepted from telnetForBlockingFn_1479413966_127.0.0.1_49116
2016.11.17 22:45:09 5: Cmd: >{BlockingStart('12378')}<
2016.11.17 22:45:09 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.17 22:45:09 4: pilight(SendDone): message successfully send
2016.11.17 22:45:10 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":19162090,"unit":0,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 22:45:10 5: Triggering pilight (1 changes)
2016.11.17 22:45:10 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":19162090,"unit":0,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 22:45:10 4: pilight(Dispatch): PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 5: pilight dispatch PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 5: Triggering pilight (1 changes)
2016.11.17 22:45:10 5: Starting notify loop for pilight, first event UNKNOWNCODE PISWITCH,arctech_switch,19162090,0,off
2016.11.17 22:45:10 3: pilight: Unknown code PISWITCH,arctech_switch,19162090,0,off, help me!

Habe nochmal etwas rumprobiert, bei "kaku_switch" und "arctech_switch" passiert das, bei zB elro_800_switch nicht. Kann es sein, dass die Protokolle für die du das pilight_contact erstellt (oder erweitert) hast jetzt diesen Schuss weg haben?
Pilight scheint ja generell kein Problem zu haben, denn das Schalten funktioniert ja, nur das FHEM-Modul ändert den state bei diesen Protokollen nicht.
Ich hoffe das bringt dich weiter?

EDIT:
Ich habe nochmal etwas anderes ausprobiert:

Das hier:

Code Auswählen Erweitern

define TestDing pilight_switch kaku_switch 12 1

ergibt das hier:

Code Auswählen Erweitern

2016.11.17 23:23:01 5: Cmd: >set TestDing off<
2016.11.17 23:23:01 5: TestDing(Set): off 1 of 1
2016.11.17 23:23:01 4: pilight(Write): RCV (pilight_switch) -> TestDing,off
2016.11.17 23:23:01 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"off":1}}
2016.11.17 23:23:01 5: pilight(SendNonBlocking): queue size 1
2016.11.17 23:23:01 4: BlockingCall (pilight_ctrl_Send): created child (21086), uses telnetForBlockingFn_1479421337 to connect back
2016.11.17 23:23:01 4: name: /fhem?cmd.TestDing=set%20TestDing%20off&room=all&XHR=1&fw_id=389 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.17 23:23:01 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"off":1}}
2016.11.17 23:23:01 4: pilight(Send): RCV -> {"status":"success"} 
2016.11.17 23:23:01 4: Connection accepted from telnetForBlockingFn_1479421337_127.0.0.1_44802
2016.11.17 23:23:01 5: Cmd: >{BlockingStart('135')}<
2016.11.17 23:23:01 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.17 23:23:01 4: pilight(SendDone): message successfully send
2016.11.17 23:23:02 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:23:02 5: Triggering pilight (1 changes)
2016.11.17 23:23:02 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:23:02 4: pilight(Dispatch): PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 5: pilight dispatch PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 5: Triggering pilight (1 changes)
2016.11.17 23:23:02 5: Starting notify loop for pilight, first event UNKNOWNCODE PISWITCH,arctech_switch,12,1,off
2016.11.17 23:23:02 3: pilight: Unknown code PISWITCH,arctech_switch,12,1,off, help me!

und es schaltet den Status nicht. Das Selbe bei "arctech_switch".

Wohingegen das hier:

Code Auswählen Erweitern

define TestDing2 pilight_switch elro_800_switch 12 1

das hier ergibt:

Code Auswählen Erweitern

2016.11.17 23:26:35 5: Cmd: >set TestDing2 off<
2016.11.17 23:26:35 5: TestDing2(Set): off 1 of 1
2016.11.17 23:26:35 4: pilight(Write): RCV (pilight_switch) -> TestDing2,off
2016.11.17 23:26:35 4: pilight(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":12,"unitcode":1,"off":1}}
2016.11.17 23:26:35 5: pilight(SendNonBlocking): queue size 1
2016.11.17 23:26:35 4: BlockingCall (pilight_ctrl_Send): created child (22493), uses telnetForBlockingFn_1479421571 to connect back
2016.11.17 23:26:35 4: name: /fhem?cmd.TestDing2=set%20TestDing2%20off&room=all&XHR=1&fw_id=387 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.17 23:26:35 5: pilight(Send): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":12,"unitcode":1,"off":1}}
2016.11.17 23:26:35 4: pilight(Send): RCV -> {"status":"success"} 
2016.11.17 23:26:35 4: Connection accepted from telnetForBlockingFn_1479421571_127.0.0.1_37692
2016.11.17 23:26:35 5: Cmd: >{BlockingStart('7')}<
2016.11.17 23:26:35 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.17 23:26:35 4: pilight(SendDone): message successfully send
2016.11.17 23:26:35 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":12,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:26:35 5: Triggering pilight (1 changes)
2016.11.17 23:26:35 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":12,"unitcode":1,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.17 23:26:35 4: pilight(Dispatch): PISWITCH,elro_800_switch,12,1,off,12
2016.11.17 23:26:35 5: pilight dispatch PISWITCH,elro_800_switch,12,1,off,12
2016.11.17 23:26:35 4: pilight_switch_Parse: RCV -> PISWITCH,elro_800_switch,12,1,off,12
2016.11.17 23:26:35 5: Triggering TestDing2 (1 changes)
2016.11.17 23:26:35 5: Starting notify loop for TestDing2, first event off

und der Status schaltet.
Was hat es mit dem "UNKNOWNCODE PISWITCH" auf sich?

In der Kommandozeile mit "pilight-send" ist er mit beidem zufrieden, aber wie gesagt: die Gartenlampe schaltet ja auch, trotz "UNKNOWNCODE"...

[Risiko]

Hallo Pati_Alpha,

das ist ein typisches Problem von pilight. Für ein und das selbe Protokoll gibt es unterschiedliche Namen (brands) Für kakau_switch z.B. intertechno_switch, dio_switch,coco_switch, arctech_switch, etc.
Senden tust du entsprechenden deiner switch definition mit dem kaku_switch Protokoll

Code Auswählen Erweitern


pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":19162090,"unit":0,"off":1}}

Antworten tut pilight aber mit arctech_switch

Code Auswählen Erweitern


pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":19162090,"unit":0,"state":"off"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}

Für das arctech_switch Protokoll wird aber nun keine Schalter-Definition\Modul gefunden -->Unknown code....
Es gibt dafür zwei Lösungen:
1. Du definierst den Schalter mit dem Protokoll arctech_switch
2. Du nutzt das Attribut 'brands' in pilight_ctrl archtech:kaku --> Jetzt wird archtech zu kaku umbenannt

Hast du evtl. die pilight Version gewechselt? Kann eigentlich sonst nie funktioniert haben. Es hat also nichts mit den Änderungen bezüglich der Kontakte zu tun.

Risiko

[Pati_Alpha]

Hey,

das kann eigentlich nicht sein. Ich habe nur deine Module geupdated. Pilight selbst habe ich seit Beginn meines FHEM Projekts vor 6 Wochen nicht wieder angefasst.
Davon ab bin mir SICHER (!!), dass es vorher funktioniert hat. :/


Außerdem habe ich ja folgendes getestet:

Code Auswählen Erweitern

define TestDing pilight_switch kaku_switch 12 1

ergibt

Code Auswählen Erweitern

2016.11.18 23:16:16 5: Cmd: >set TestDing on<
2016.11.18 23:16:16 5: TestDing(Set): on 1 of 1
2016.11.18 23:16:16 4: pilight(Write): RCV (pilight_switch) -> TestDing,on
2016.11.18 23:16:16 4: pilight(Write): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:16:16 5: pilight(SendNonBlocking): queue size 1
2016.11.18 23:16:16 4: BlockingCall (pilight_ctrl_Send): created child (569), uses telnetForBlockingFn_1479507231 to connect back
2016.11.18 23:16:16 4: name: /fhem?cmd.TestDing=set%20TestDing%20on&XHR=1&fw_id=404 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.18 23:16:16 5: pilight(Send): {"action":"send","code":{"protocol":["kaku_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:16:16 4: pilight(Send): RCV -> {"status":"success"} 
2016.11.18 23:16:16 4: Connection accepted from telnetForBlockingFn_1479507231_127.0.0.1_60874
2016.11.18 23:16:16 5: Cmd: >{BlockingStart('8424')}<
2016.11.18 23:16:16 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.18 23:16:16 4: pilight(SendDone): message successfully send
2016.11.18 23:16:17 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.18 23:16:17 5: Triggering pilight (1 changes)
2016.11.18 23:16:17 5: Starting notify loop for pilight, first event rcv_raw: {"origin":"sender","protocol":"arctech_switch","message":{"id":12,"unit":1,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-77622d"}
2016.11.18 23:16:17 4: pilight(Dispatch): PISWITCH,arctech_switch,12,1,on
2016.11.18 23:16:17 5: pilight dispatch PISWITCH,arctech_switch,12,1,on
2016.11.18 23:16:17 4: pilight_switch_Parse: RCV -> PISWITCH,arctech_switch,12,1,on

und

Code Auswählen Erweitern

define TestDing pilight_switch kaku_switch 12 1

ergibt

Code Auswählen Erweitern

2016.11.18 23:17:59 5: Cmd: >set TestDing on<
2016.11.18 23:17:59 5: TestDing(Set): on 1 of 1
2016.11.18 23:17:59 4: pilight(Write): RCV (pilight_switch) -> TestDing,on
2016.11.18 23:17:59 4: pilight(Write): {"action":"send","code":{"protocol":["arctech_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:17:59 5: pilight(SendNonBlocking): queue size 1
2016.11.18 23:17:59 4: BlockingCall (pilight_ctrl_Send): created child (1306), uses telnetForBlockingFn_1479507454 to connect back
2016.11.18 23:17:59 4: name: /fhem?cmd.TestDing=set%20TestDing%20on&room=all&XHR=1&fw_id=386 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.18 23:17:59 5: pilight(Send): {"action":"send","code":{"protocol":["arctech_switch"],"id":12,"unit":1,"on":1}}
2016.11.18 23:17:59 4: pilight(Send): RCV -> {"status":"failed"} 
2016.11.18 23:17:59 4: Connection accepted from telnetForBlockingFn_1479507454_127.0.0.1_41572
2016.11.18 23:17:59 5: Cmd: >{BlockingStart('8435')}<
2016.11.18 23:17:59 5: Cmd: >{pilight_ctrl_SendDone('pilight|1')}<
2016.11.18 23:17:59 4: pilight(SendDone): message successfully send


Du hast natürlich recht, das obere ist länger, weil er da separat etwas mit dem Namen "arctech" empfängt und unten nicht (da es ja schon von vornherein arctech ist), aber in beiden Fällen schaltet der status des device nicht!
Wohingegen es mit "elro_800_switch" zB funktioniert.

Funktioniert das "TestDing" denn bei dir mit beiden Protokollen?

[JPP88]

Hallo,

ich wollte kurz nachfragen, ob man den zuvor besprochenen Problem schon auf die Schliche gekommen ist, denn ich habe das selbe Problem.

Habe vorgestern eine JeeLink mit LaCrose installiert und in dem Atemzug ein Update von FHEM gemacht. Seit dem kann ich keine Kaku Switch Funksteckdosen mehr schalten, weder mit FHEM oder Pilight direkt.

Wenn aber FHEM nicht läuft, sondern nur Pilight, dann kann ich die Kaku Switch Funksteckdosen schalten. Habe noch drei weitere Funksteckdosen die mit dem Elro 800 Protokoll angesteuert werden, bei diesen gibt es wiederum keine Probleme.

Darüber hinaus lasse ich noch einen DHT22 über Pilight laufen, der spinnt jetzt auch rum, kann aber auch andere Gründe haben.

Würde mich sehr über Antworten freuen

[Risiko]

Funktioniert das "TestDing" denn bei dir mit beiden Protokollen?

Es funktioniert nur

Code Auswählen Erweitern

define TestDing pilight_switch kaku_switch 12 1
wenn man wie bereits erwähnt das Attribut brands setzt. "attr <name> brands arctech:kaku"
Mit "arctech_switch" senden, akzeptiert pilight wohl doch nicht mehr.

Code Auswählen Erweitern


pilight-send -p arctec_switch -i 12 -u 1 -t

Geht ja auch nicht (mehr).
Ich habe heute explizit noch mal auf einen alten Stand der Module zurück gewechselt und das "TestDing" probiert. Es geht auch wie erwartet in den alten Versionen nicht ohne dem Attribut brands.
Sorry, ich kann keinen Fehler feststellen!!

[Pati_Alpha]

Kannst du hier nochmal die alten Module für "ctrl" und "switch" anhängen? Dann teste ich das bei mir auch nochmal. Irgendwie müssen wir dem Fehler ja auf die Schliche kommen, denn vorher ging der Kram ja.

Du hast allerdings recht: mit dem brands Attribut funktionieren die Kakus wieder, aber ich garantiere dir, dass ich das Argument vorher nie benutzt hab und es trotzdem funktionierte.
Komisch, komisch...! :/

Ich teste trotzdem gerne die alten Module nochmal!

[Weisswurstverkäufer]

Nochmal zu meinem Problem:

ich habe ein Problem mit dem Modul - und zwar kann ich immer nur *einmal* schalten. Danach muss ich neu verbinden, um erneut schalten zu können. Empfangen geht allerdings immer. Auch, wenn ich nicht mehr schalten kann.

Der pilight-daemon (pilight-daemon version v7.0) läuft auf einem Raspberry Pi, fhem läuft auf Freeebsd.

Mein pilight_ctrl device hat ignoreProtocol * gesetzt, wenn ich das raus nehme ändert es aber auch nichts.

Die pilight_switch devices scheinen korrekt konfiguriert zu sein (empfangen und einmal schalten funktioniert ja auch), z. B. "elro_800_switch 5 1", "... 5 2" etc.

Ich habe verbose jetzt mal auf 5 gesetzt.

Beim 1. Schalten sieht eigentlich fast alles normal aus:

Code Auswählen Erweitern

2016.11.28 10:52:59 5: Steckdose3(Set): on 1 of 1
2016.11.28 10:52:59 4: pilight(Write): RCV (pilight_switch) -> Steckdose3,on
2016.11.28 10:52:59 4: pilight(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":6,"unitcode":4,"on":1}}
2016.11.28 10:52:59 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:52:59 5: pilight(Send): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":6,"unitcode":4,"on":1}}
2016.11.28 10:52:59 4: pilight(Send): RCV -> {"status":"success"} 
2016.11.28 10:52:59 1: Connection refused from 192.168.42.200:61267
2016.11.28 10:53:00 5: pilight(Parse): RCV -> {"origin":"sender","protocol":"elro_800_switch","message":{"systemcode":6,"unitcode":4,"state":"on"},"repeat":1,"uuid":"0000-b8-27-eb-a356b8"}
2016.11.28 10:53:00 4: pilight(Dispatch): PISWITCH,elro_800_switch,6,4,on,6
2016.11.28 10:53:00 5: pilight dispatch PISWITCH,elro_800_switch,6,4,on,6
2016.11.28 10:53:00 4: pilight_switch_Parse: RCV -> PISWITCH,elro_800_switch,6,4,on,6

bis auf das

Code Auswählen Erweitern

2016.11.28 10:52:59 1: Connection refused from 192.168.42.200:61267

zwischendurch. 192.168.42.200 ist der Rechner (bzw. das FreeBSD jail) auf dem FHEM läuft. Pilight läuft wie gesagt auf einem anderen Rechner.

Ab dem 2. Mal schalten passiert dann das:

Code Auswählen Erweitern

2016.11.28 10:53:33 5: Steckdose3(Set): off 1 of 1
2016.11.28 10:53:33 4: pilight(Write): RCV (pilight_switch) -> Steckdose3,off
2016.11.28 10:53:33 4: pilight(Write): {"action":"send","code":{"protocol":["elro_800_switch"],"systemcode":6,"unitcode":4,"off":1}}
2016.11.28 10:53:33 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:53:33 5: pilight(Write): Blocking Call running - will try it later
2016.11.28 10:53:33 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:53:33 5: pilight(Write): Blocking Call running - will try it later
2016.11.28 10:53:34 5: pilight(SendNonBlocking): queue size 1
2016.11.28 10:53:34 5: pilight(Write): Blocking Call running - will try it later
2016.11.28 10:53:34 5: pilight(SendNonBlocking): queue size 1

die "queue size" wird mit jedem Schaltversuch erhöht. Die Logausgabe läuft so lange, bis ich mich neu mit dem Pi verbinde ("reset").

Vielleicht jetzt jemand eine Idee?

[Risiko]

Hi Weisswurstverkäufer
Das Senden der 1. Nachricht ist nicht komplett abgeschlossen. Deswegen herhöht sich bei allen weiteren Versuchen die Queue.
So richtig kann ich es mir auch nicht erklären. Versuch mal mit dem Attribut "SendTimeout" z.B. 2,3 etc. das Timeout zu erhöhen!

[Weisswurstverkäufer]

Versuch mal mit dem Attribut "SendTimeout" z.B. 2,3 etc. das Timeout zu erhöhen!

Ändert leider auch nichts. Habe auf bis zu 10 Sekunden erhöht.

[Weisswurstverkäufer]

Ok, ich habe den Fehler gefunden.

Das Problem lag nicht direkt an dem Pilight Modul, sondern am Blocking.pm bzw. TcpServerUtils.pm(?).

Mein FreeBSD Jail hat(te) keine IP Adresse 127.0.0.1. Irgendetwas scheint aber davon auszugehen dass es diese IP Adresse gibt. Ich habe meinem Jail nun zusätzlich 127.0.0.1 zugewiesen und nun funktioniert es.