eBus->USB->Plugin->KNX

[Gast]

ebusd und ebus_send wollen dabei gleichzeitig auf ein Device zugreifen. Ich glaube nicht dass dies funktioniert.
Falls doch so klärt mich bitte auf wie das funktioniert.

Nun kommt aber wieder ebusd ins Spiel.

Wenn das Schreiben ausgereift ist, wird das der daemon erledigen.
Der Zugriff erfolgt dann via Telnet. Damit ist das ganze entkoppelt.

[JuMi2006]

Hallo Roland,

sieht jetzt gut aus. Ich werde das mal in meinem script (für die Kollegen hier WireGate-Plugin) testen.

Besten Dank für Deine Bemühungen!

Grüße!

Edit:
Ich hab das jetzt mal schnell in ein Plugin geschmissen, wobei vieles später im Daemon landen sollte, aber das sieht schonmal verdammt gut aus .
Morgen sehe ich mir die Logs dazu an und schiebe mal ein paar RRDs aus der Visu hinterher.

[Gast]

Stresstest

Hi,

ich habe mit dem angehängten Script mal einen Stresstest durchgeführt.
Das Script sendet die Befehle (Vaillant) für den Energieertrag je Monat des Vorjahres .

Das Script benötigt ebus_send in der SVN Version 1323.

Aufruf mit backup src # ./test.sh 100 0 > result.txt

• Wobei die 100 die Anzahl der Durchläufe ist.
• 0 ist die Wartezeit in Sekunden zwischen ebus Befehlen.

Am Schluss kommt noch eine kurze Zusammenfassung:

    from: 2013-01-13 00:06:37
      to: 2013-01-13 00:09:21
wait (s): 0
 repeats: 100
commands: 12
    send: 1200
  errors: 19

Mit 19 Fehler auf 1200 Befehlen in nicht ganz 3 Minuten bin ich zufrieden.

Das Script kann natürlich einfach für andere Befehle angepaßt werden.

[JuMi2006]

from: 2013-01-13 09:09:19
      to: 2013-01-13 09:18:20
wait (s): 0.25
 repeats: 100
commands: 12
    send: 1200
  errors: 0

Allerdings gab es doch ein paar Fehler, zumindest in der Ausgabe:

35 : Jun :: 15 b5 09 03 0d 85 28 -> 02 64 01
35 : Jul :: 15 b5 09 03 0d 85 30 ->35 : Aug :: 15 b5 09 03 0d 85 38 -> 02 af 00
35 : Sep :: 15 b5 09 03 0d 85 40 -> 02 85 01

"Error" wurde nicht angezeigt.


Meine Logs aus der Nacht sehen auch ganz gut aus, allerdings gab es ein paar mal nicht ausgewertete Daten bzw. wurde 0 Grad berechnet. Ich werde mal die Logs ein wenig erweitern um dann zu sehen was für Bytes ausgewertet wurden. Vielleicht liegt es auch an der Datenpunktumrechnung in meinem Script.

Grüße

[Gast]

Das Script benötigt ebus_send in der SVN Version 1323

Edit: Habe im Script folgendes geändert:

von es='./ebus_send'
auf es='./ebus_send -r 5'

Ergebnis:

    from: 2013-01-13 10:05:56
      to: 2013-01-13 10:08:40
wait (s): 0
 repeats: 100
commands: 12
    send: 1200
  errors: 3

[kleinklausi]

ebusd und ebus_send wollen dabei gleichzeitig auf ein Device zugreifen. Ich glaube nicht dass dies funktioniert.

Hatte ich mir so gedacht. War nur ein Versuch... :-)

Gruß

[MarcusF]

Also bei mir klappt ebus_send nicht, ich bekomme keine Antwort. Das Interface funktioniert mit dem ebusd und serial_write einwandfrei, Hardware ist ein VIA Epia-Board mit 600 MHz, Interface hängt direkt am ttyS0.

[ebus_wait_syn]		 skip: 0 found: 1
[ebus_get_bus]		 write: 0.000042
[ebus_get_bus]		 wait : 0.004175 
[ebus_send_data]	 got bus
[ebus_send_data]	 <<<  15 b5 09 03 0d 85 28
[ebus_get_ack]		 tmplen: 8 tmp [0]: 15 - buf [0]: 15
[ebus_get_ack]		 tmplen: 8 tmp [1]: b5 - buf [1]: b5
[ebus_get_ack]		 tmplen: 8 tmp [2]: 09 - buf [2]: 09
[ebus_get_ack]		 tmplen: 8 tmp [3]: 03 - buf [3]: 03
[ebus_get_ack]		 tmplen: 8 tmp [4]: 0d - buf [4]: 0d
[ebus_get_ack]		 tmplen: 8 tmp [5]: 85 - buf [5]: 85
[ebus_get_ack]		 tmplen: 8 tmp [6]: 28 - buf [6]: 28
[ebus_get_ack]		 tmplen: 8 tmp [7]: f0 - buf [7]: f0
[ebus_get_ack]		 tmplen: 5 tmp [0]: 00 - buf [8]: 00
[ebus_get_ack]		 j: 8 buflen: 8 tmp[0]: 00
[ebus_send_data]	 ret: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [4]: aa esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [0]: aa - msg [5]: aa esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [1]: 10 - msg [6]: 10 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [2]: 08 - msg [7]: 08 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [3]: b5 - msg [8]: b5 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [4]: 11 - msg [9]: 11 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [5]: 01 - msg [10]: 01 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [6]: 03 - msg [11]: 03 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [7]: 8b - msg [12]: 8b esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [0]: 00 - msg [13]: 00 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [1]: 0a - msg [14]: 0a esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [2]: 97 - msg [15]: 97 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [3]: 01 - msg [16]: 01 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [4]: 74 - msg [17]: 74 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [5]: 08 - msg [18]: 08 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [6]: 60 - msg [19]: 60 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [7]: 03 - msg [20]: 03 esc: 0
[ebus_recv_data]	 tmplen: 7 tmp [0]: 03 - msg [21]: 03 esc: 0
[ebus_recv_data]	 tmplen: 7 tmp [1]: 2c - msg [22]: 2c esc: 0
[ebus_recv_data]	 tmplen: 7 tmp [2]: 02 - msg [23]: 02 esc: 0
[ebus_recv_data]	 tmplen: 7 tmp [3]: 00 - msg [24]: 00 esc: 0
[ebus_recv_data]	 tmplen: 7 tmp [4]: 3b - msg [25]: 3b esc: 0
[ebus_recv_data]	 tmplen: 7 tmp [5]: 00 - msg [26]: 00 esc: 0
[ebus_recv_data]	 tmplen: 7 tmp [6]: aa - msg [27]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [28]: aa esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [0]: aa - msg [29]: aa esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [1]: 10 - msg [30]: 10 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [2]: 08 - msg [31]: 08 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [3]: b5 - msg [32]: b5 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [4]: 11 - msg [33]: 11 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [5]: 01 - msg [34]: 01 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [6]: 02 - msg [35]: 02 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [7]: 8a - msg [36]: 8a esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [0]: 00 - msg [37]: 00 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [1]: 05 - msg [38]: 05 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [2]: 00 - msg [39]: 00 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [3]: 00 - msg [40]: 00 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [4]: c8 - msg [41]: c8 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [5]: 00 - msg [42]: 00 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [6]: c8 - msg [43]: c8 esc: 0
[ebus_recv_data]	 tmplen: 8 tmp [7]: ca - msg [44]: ca esc: 0
[ebus_recv_data]	 tmplen: 2 tmp [0]: 00 - msg [45]: 00 esc: 0
[ebus_recv_data]	 tmplen: 2 tmp [1]: aa - msg [46]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [47]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [48]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [49]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [50]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [51]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [52]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [53]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [54]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [55]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [56]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [57]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [58]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [59]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [60]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [61]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [62]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [63]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [64]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [65]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [66]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [67]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [68]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [69]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [70]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [71]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [72]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [73]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [74]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [75]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [76]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [77]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [78]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [79]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [80]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [81]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [82]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [83]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [84]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [85]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [86]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [87]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [88]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [89]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [90]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [91]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [92]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [93]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [94]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [95]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [96]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [97]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [98]: aa esc: 0
[ebus_recv_data]	 tmplen: 1 tmp [0]: aa - msg [99]: aa esc: 0
[ebus_recv_data]	 msg: aa msglen: 100 msg[1]: 71 113
[ebus_send_data]	 ret: -3

EDIT: Mit dem Interface am Lantronix Ethernet Device Server gehts auch nicht:

[ebus_wait_syn]		 skip: 0 found: 1
[ebus_get_bus]		 write: 0.000022
[ebus_get_bus]		 wait : 0.004185 
[ebus_get_bus]		 retry: 1
[ebus_wait_syn]		 skip: 1 found: 1
[ebus_get_bus]		 write: 0.000013
[ebus_get_bus]		 wait : 0.004157 
[ebus_get_bus]		 retry: 2
[ebus_wait_syn]		 skip: 1 found: 1
[ebus_get_bus]		 write: 0.000012
[ebus_get_bus]		 wait : 0.004156 
[ebus_get_bus]		 retry: 3
[ebus_send_data]	 got bus
[ebus_send_data]	 <<<  15 b5 09 03 0d 85 28
[ebus_get_ack]		 tmplen: 1 tmp [0]: aa - buf [0]: 15
[ebus_send_data]	 ret: -2

Marcus

[Gast]

Welche SVN Version verwendest Du ?

[JuMi2006]

So ich hab jetzt genug getestet

Wiederholzeit 0.25 Sekunden -> 12/1200 fehlerhaft -> 1.00 %
Wiederholzeit 0.50 Sekunden -> 10/1200 fehlerhaft -> 0.83 %
Wiederholzeit 1.00 Sekunden -> 6/1200 fehlerhaft -> 0.50 %

Grüße

[MarcusF]

Welche SVN Version verwendest Du ?

Heute frisch aus dem Repo gezogen, Revision 1323.

Marcus

[Gast]

So ich hab jetzt genug getestet

Wiederholzeit 0.25 Sekunden -> 12/1200 fehlerhaft -> 1.00 %
Wiederholzeit 0.50 Sekunden -> 10/1200 fehlerhaft -> 0.83 %
Wiederholzeit 1.00 Sekunden -> 6/1200 fehlerhaft -> 0.50 %

Grüße

Sieht ja sehr gut aus. Die Fehlerrate steigt, wenn sich zu viel am Bus abspielt.

Zur Vollständigkeit habe ich noch den Skipparameter rausgezogen.

Möglich Parameter zum Testen

-r --retry max retry getting bus. (3)
Die Anzahl der Versuche den Buszugriff zu bekommen. Dass QQ byte muss so gelesen werden wie wir es geschrieben haben.

-s --skip skipped ACK bytes after get-bus error. (1)
Falls das gelesen QQ byte nicht unserem entspricht, wird die Anzahl der AA bytes abgewartet bis ein neuer Versuch unternommen wird.

-w --wait wait time for QQ compare. (~4100 usec)
Wartezeit bis das geschrieben QQ byte mit dem gelesenen verglichen wird. (lt. Doku zwischen 4127 und 4227 usec)

@MarcusF:
Leider kann ich das mangels Hardware nicht nachstellen. Ich habe aber noch ein paar Debugs eingebaut.

@all:
Änderungen fürs compilieren ab SVN 1324. (immer make clean ausführen)
Normales Build: make
Build mit Debug: make DEBUG=1

[Gast]

@MarcusF: Der aktuelle Commit sollte Dein Problem behebe.

svn commit -m "ebus_recv_data: preset tmp buffer with unread bytes from get_bus rewritten."
Sende          tools/ebus.c
Sende          tools/ebus.h
Übertrage Daten ..
Revision 1327 übertragen.

[Fry]

Ich versuche das mal. So könnte das CSV für ein "get" also das Auslesen von Werten aussehen, für "set" und "cycle" wäre das nahezu identisch.
...

Hallo yuhu, Jumi, kleinklausi und die anderen,

sorry, dass ich hier nur hin und wieder poste, bin aktuell viel unterwegs und habe auch von den Wölfen bisher noch keine Rückmeldung (außer den offiziellen Dokumenten, die ihr alle schon kennt).

Erstmal ein Riesenkompliment an euch alle - ich finde eure Arbeit ganz fantastisch. Gerne würde ich mehr helfen, aktuell scheitert es an Zeitnot, aber was nicht ist...

Jumi, deine Anforderung, dass der Daemon decodieren soll, sehe ich offen gesagt anders. Das ist eine klassische Pattern-Matching-Aufgabe, und auch wenn das natürlich in C _geht_, ist es doch viel eleganter (sprich: leichter an steigende Anforderungen anzupassen) in Perl zu realisieren (Perl-Daemon oder WG-Plugin, der mit ebusd kommuniziert).

Genauso wie im Wiregate eibd und wiregated.pl sich die Arbeit teilen - da dekodiert ja auch nicht der eibd.

Aber: der ebusd sollte m.E. die Pruefung der CRC vornehmen und ggf. erneutes Sende- oder Request-Telegramme selbstaendig absetzen. Das gehoert in diese Kommunikationsschicht.

Oder seht ihr das anders?

VG, Fry

[Gast]

Leistungsumfang ebusd

Jumi, deine Anforderung, dass der Daemon decodieren soll, sehe ich offen gesagt anders. Das ist eine klassische Pattern-Matching-Aufgabe, und auch wenn das natürlich in C _geht_, ist es doch viel eleganter (sprich: leichter an steigende Anforderungen anzupassen) in Perl zu realisieren (Perl-Daemon oder WG-Plugin, der mit ebusd kommuniziert).

Genauso wie im Wiregate eibd und wiregated.pl sich die Arbeit teilen - da dekodiert ja auch nicht der eibd.

Ich finde den Ansatz mit der Arbeitsteilung ganz gut. Es muss nicht alles der Daemon machen.

Aber: der ebusd sollte m.E. die Pruefung der CRC vornehmen und ggf. erneutes Sende- oder Request-Telegramme selbstaendig absetzen. Das gehoert in diese Kommunikationsschicht.

Finde ich ebenfalls gut.

Auf meiner TODO Liste für den Daemon sind nun
* Schreibfunktion übernehmen.
* Configfile erstellen/einbinden. (nicht zu verwechseln mit den ebus csv Befehlsdateien)
* Telnet Zugriffs Methoden implementieren ..... get/set/cycle/help..(welche noch?)
* fehlt hier noch was?


Damit ich mein ureigenes Ziel nicht aus den Augen verliere.
Anfangs wollte ich "nur" ein paar Werte der neuen Heizung aufzeichnen, damit ich die Anlage "optimieren" kann.
Vom Aufzeichnen bin ich im Moment noch ein ganzes Stück entfernt und das Ganze hat sich doch zu einem kleinen Projekt ausgewachsen.
Da ich den wiregate Server nicht kenne, kann der solche grafische Aufbereitungen machen und darstellen, bzw. müsste ja dazwischen noch eine Dekodierung stattfinden.
Die Dekodierung und Aufzeichnung sollte, wenn es geht, unabhängig der wiregate Software sein.
Damit kann auch mit anderer Software auf die Daten zugegriffen werden.

Habe ich die Puzzleteile richtig verstanden? Irgendwie fehlt mir gerade das Bild wie es nachdem Daemon weitergehen soll.

[JuMi2006]

Jumi, deine Anforderung, dass der Daemon decodieren soll, sehe ich offen gesagt anders. Das ist eine klassische Pattern-Matching-Aufgabe, und auch wenn das natürlich in C _geht_, ist es doch viel eleganter (sprich: leichter an steigende Anforderungen anzupassen) in Perl zu realisieren (Perl-Daemon oder WG-Plugin, der mit ebusd kommuniziert).

Nunja meinetwegen, ich hab da grundsätzlich nichts dagegen. Ich habe ja Momentan schon ein WireGate-Plugin was mit dem ebus_send kommuniziert. Das liest 3 Werte pro Minute aus, decodiert Sie und sendet Sie auf den Bus.
Ehrlich gesagt würde ich das aber trotz WireGate gern so haben wollen dass man nicht auf dieses angewiesen ist. Sicherlich auch kein Problem dass dann via groupswrite und eibd zu machen. Die rrds kann man auch abfrühstücken, auch kein Thema. Wenn Arbeitsteilung dann so dass man nicht auf ein WireGate angewiesen ist. Roland hat ja als non-KNX-WireGate-Besitzer hier beträchtlich viel Zeit reingesteckt und es zu einem respektablem Tool geschafft, diesen Weg sollten wir nun unterstützen.
Der Vorteil bei Perl wäre dass ich auch weiter mithelfen könnte.

Aber: der ebusd sollte m.E. die Pruefung der CRC vornehmen und ggf. erneutes Sende- oder Request-Telegramme selbstaendig absetzen. Das gehoert in diese Kommunikationsschicht.

Sicherlich gehört die CRC Berechnung/Kontrolle in den ebusd, was wir jetzt aber auch nicht vergessen dürfen ist dass wir in einem weiteren Perl-Daemon dann wieder die ganze Datenkonvertierung durchführen. Im Paket betrachtet ist das natürlich total Suppe wer jetzt was macht. Für mich bleibt dennoch die Vorstellung eines einfachen "get HK_soll" via UDP an den ebusd sehr attraktiv.

Ich will mal kurz ein mögliches Endziel nennen:
eBus-Adapter + RaspberryPi (o.ä.) an/in der Wärmepumpe/Heizung als autarkes System ohne Abhängigkeiten. Wer will darf sich dafür dann noch ein web-frontend basteln. Darauf läuft dann eben der ebusd und ein entsprechender Pearl-Daemon der sich um die Userwünsche kümmert (UDP/RRDs/eibd). Wenn das WireGate in der Nähe steht kann es sich ja darum kümmern, muss es aber eben nicht zwangsläufig.

Grüße