Gleichzeitige Verbindungen zum brickd

Hallo,

ich habe mir einen Gebäudeautomatisierung auf Tinkerforge Basis gebaut. Das ganze ist aktuell noch in kleinem Masstab, aber es läuft gut. So gut, dass ich es ausbauen werde.

Im Zuge des Aufbaus habe ich mir auch einen kleinen Softwarelayer um die API herum geschrieben - hierzu habe ich ein Frage, aber zum besseren Verständnis, vielleicht erstmal das Setup.

Im Haus sind von allen Schaltern 24V Steuerleitungen und zu allen Lampen einzelne 3x1,5 - 230V Leitungen gezogen. Im Schaltschrank sind diese Steuerleitungen (im Moment nur 4, später "alle") auf Eingänge von IndustrialDigitialIn-Bricklets gezogen.

Ein IndustrialDigitalOut-Bricklet steuert Relais an, welche wiederum die Lampenleitungen (und später auch Leitungen zu Rolladenmotoren) steuern.

Die Bricklets sind über eine Master-Brick per USB an einen Raspberry Pi angeschlossen.

Auf dem Raspberry Pi läuft eine von mir in Python geschriebe Software, welche die Interrupts der Eingänge verwaltet, die Ausgänge schaltet und eine WebGUI zur Verfügung stellt.

Der Softwarelayer zwischen eigentlicher Applikation und Tinkerforge API besteht aus nur zwei Klassen.

Einer Klasse für IN und einer für OUT.

Für jeden Pin an einem DigitalIn-Bricklet erzeuge ich ein solches IN Objekt. Dieses baut eine Verbindung zum brickd auf, registiert für den PIN einen Callback und führt im Aufrufsfall eine externe Funktion aus.

Gleiches gilt für das DigitalOut-Bricklet. Auch dort gibt es pro Pin ein Objekt. Das macht die Ansteuerung der Pins einfacher. Ich kann dann sagen: "licht_arbeitszimmer.on()" statt eine Binärmaske schicken zu müssen (diese wird von dem Objekt übernommen).

Das funktioniert aktuell 1a, allerdings bedeutet das auch, dass ich pro PIN ein Verbindung aufbaue - und diese im Fall der In-Objekte auch nicht sofort wieder abbauen kann, da ich ja den Callback sonst verliere.

Ich habe gelesen dass die Ethernet und WLAN Module nur 7 bzw. 15 parallele Verbindungen können. Beim brickd habe ich nichts gelesen dass es eine solche Einschränkung gibt. Gibt es da irgendwo ein Limit?

Achja: Ich hatte ursprünglich versucht, eine einzige Verbindung zu nutzen, aber das klappt nicht sauber. Wenn ich eine Verbinung aufbaue und dann Pin 1 schalte, dann Pin 2 und dann wieder versuche Pin 1 zu schalten, dann erhalte ich einen Timeout. Ich vermute dass, wenn man ein IndustrialDigitalIn oder Out Objekt erzeugt irgendetwas im IPConnection-Objekt geändert wird, so dass über eine Verbindung nicht mehrer das "alte" Bricklet findet. Insofern schied diese Lösung aus. Falls da noch jemand eine Idee hat, wäre das natürlich sogar die bessere Lösung.

Gruß

Ben

Ich kann dir nur den letzten Teil beantworten:

Die IPConnection verwaltet ei Dictionary (wie heißt das in Python? Map? Hash?) von UID auf Device-Objekt. Wenn du also mehrere Device-Objekte pro UID haben möchtest, dann musst du tatsächlich auf mehrere IPConnections ausweichen.

Das ist allerdings eher eine architekturelle Einschränkung der Bindings als eine Einschränkung des Übertragungsprotokolls. Dennoch bin ich mir nicht sicher welche Implikationen es hätte pro UID eine Liste von Devices zu verwalten... Zumal es dann vermutlich auch in allen Bindings gleich sein sollte... Ich denke da mal drüber nach ^^

Danke für die Antwort, das erklärt dann schon mal einiges - und ich brauch nicht zu suchen ob ich in meinem Softwarelayer irgendwo noch einen Bug habe.

Falls jemand an dem gleichen Problem arbeitet.

Ich konnte das Problem lösen in dem ich mir eine zusätzliche Pythonklasse geschrieben habe. Diese dient als "Brick(let)register".

Die In und Out Objekte erzeugen jetzt kein eigenes Deviceobjekt mehr, sondern fordern eines beim Brickregister an. Wenn das Brickregister schon ein Objekt für das Bricklet hat, liefert es dieses Objekt zurück, ansonsten erzeugt es ein neues und speichert sich dieses Objekt in einer Liste.

Damit habe nur noch eine Verbindung pro laufendem Pythonprozess.

Ich werde den Code auch noch veröffentlichen, sobald ich dazu komme ein wenig mehr Doku zu schreiben.

Hi Ben,

was Du geschrieben hast hört sich sehr interessant für mich an.

Hattest Du schon Gelegenheit den entsprechenden Code zu veröffentlichen?

Doku wäre gut, ist aber nicht so wichtig - den Quelltext verstehe ich auch so. Nur mit dem selber schreiben habe ich es nicht so.

Gruß

September