teichsta

Update: ich habe hier nun eine funktionierende Installation mit dem oben beschriebenen Setup (2 RPis, Anbindung über MQTT Binding) laufen … so weit, so gut.

Da wir im Projekt allerdings allerdings mehrere Installationen (es geht um eine "Maschine" mit lokaler Visualisierung, deren Sensorik wir mit TF realisieren) haben, ist die Einrichtung/Konfiguration leider mit MQTT etwas "nervig", da die UIDs ja im Topicnamen auftauchen, damit auch in den Entities und damit auch in den Automationen. Insofern ist die Konfiguration leider nicht so richtig von der eigentlichen Hardware entkoppelt … jedenfalls habe ich das noch nicht hinbekommen.

Darüber hinaus habe ich vor die Temperatur(en) mit OneWire zu messen, was unglücklicherweise ein recht "kompliziertes" Protokoll ist und sich daher mit der HomeAssistant-Template-Sprache nur recht umständlich implementieren läßt. Insofern wäre eine native Integration schon irgendwie deutlich netter ... aber gut :-)

noch eine kurze Rückfrage, wo genau konfigurierst Du die Sensoren? Es sah für mich danach aus, als würde hier MQTT Sensors als Integration eingebunden werden, aber das scheint so nicht zu gehen, weil sie mir dort nicht angeboten werden. Any hint?

danke für die schnelle Antwort @ngblume … würde man das denn auch auf einem zum Laufen bringen? Ich starte in diesem Projekt gerade erst mit HA und bin noch nicht ganz durchgestiegen was wie geht …

schönen Dank für Deinen sehr ausführlichen Beitrag hier @ngblume … ergänzend nur noch die Frage: hast Du den Brick-Daemon auf dem gleichen RPi laufen wir HA? Welche Installationsmethode hast dafür verwendet?

Hi,

leider lass ich mir nichts mitloggen (logging-persistance) hab ich gerade erst aktiviert. Wenn es wieder auftritt melde ich mich

doch, lässt Du :-)

Schau mal im Verzeichnis "<openHabHome>/log". Dort findest Du eine Datei namens "openhab.log". Wenn Du openHAB über start_debug.xxx gestartet hast, wird noch wesentlich feingranularer gelogged.

Die Logging-Persistence-Extension ist eher dazu gedacht Daten Deiner Items zu exportieren. Die exportierten Daten könntet Du dann in weiteren System verwenden. Hat also mit dem von Theo angesprochenen Logging nichts zu tun.

Gruß,

Thomas E.-E.

hmm ... habe den Code nochmal so geändert, dass der Listener vor dem Aufruf von ipconn.connect() registriert wird. Trotzdem erscheint der zweite MasterB nicht. Unabhängig davon, dass es mit enumerate() funktioniert, würde ich erwarten, dass ich so ebenfalls alle Bricks und Bricklets zu sehen bekomme, oder?

nein

Ich habe bisher einfach zunächst das connect() und dann das addEnumListener aufgerufen, danach ging es dann auch direkt los. Aber die ersten Devices hatte ich dann wohl schon verpasst.

Nun, rufe ich ipcon.enumerate() nochmal extra auf und damit funktioniert alles.

Problem ist nun, dass ich mit doppelten Device-UID umgehen muss. Das kriege ich aber hin ;-)

Danke für die schnelle Antwort!

Gruß,

Thomas E.-E.

Hallo,

habe seit kurzem einen zweiten Masterbrick im Stack, an dann ein Ambientlight-Sensor hängt. Über den BrickViewer bekomme ich sowohl Masterbrick als auch Bricklet angezeigt. Soweit so gut.

Verbinde ich mich allerdings per Java-API mit Stack und registriere einen EmunerateListener erscheint weder der zweite Masterbrick noch das Bricklet. Das müsste doch eigentlich funktionieren, oder?

tinkerforgeConnection.addEnumerateListener(new EnumerateListener() {

@Override
public void enumerate(String uid, String connectedUid, char position,
					short[] hardwareVersion, short[] firmwareVersion,
					int deviceIdentifier, short enumerationType) {
	System.out.println("try to add bricklet with uid '" + uid + "'");
}
}

Gruß,

Thomas E.-E.

an der Extension wären wir auch seeeeehr interessiert. Leider ist das WLAN in unserem Büro relativ instabil, sodass wir im Rahmen der Testautomatisierung schon das ein oder andere Mal nach Phantomfehlern gesucht haben :-/

also: +1 für die Extension

Die muss aus meiner Sicht noch nichtmal PoE haben ...

Zur Problembehebung bei der Ethernetextension wuensche ich viel Erfolg!

+1

wäre auch seeeeeehr an der Ethernetextension interessiert ...

Andererseits - wo bleibt denn bei voll durchengineerten Layers der Bastlerspass?

beim basteln (mit der Hardware) ;-)

danke für die schnelle Antwort!

Hmm ... wäre es denn aufgrund der Gleichförmigkeit der Methoden eventuell eine Lösung generischere Methoden in entsprechenden Superklassen anzubieten und dann nur noch die reine Übergabe der Funktionsidentifier in den speziellen Implementierungen zu haben anstatt immer alles in jeder Klasse implementiert zu haben?

Am Anfang ist das mit dem generieren zwar immer ganz nett, weil es eben noch viele Änderungen gibt, aber am Ende des Tages ist die Vielfalt der Bricklets ja auch beschränkt und ihr haut ja nicht jeden Tag ein Neues raus, oder?!

Hallo,

gibt es möglicherweise Überlegungen, die API um ein paar sinnvolle Abstraktionen zu erweitern?

Aktuell setze ich bspw. ein BrickletIndustrialQuadRelay und ein BrickletDualRelay ein. Um einen "Kanal" des BIQR zu schalten rufe ich

relay.setValue(channelMask);

auf. Will ich das gleiche mit dem BDR machen heißt die Methode:

relay.setState(state.relay1, state.relay2);

Schöner wäre es aus meiner Sicht, wenn es vielleicht sowas wie eine Superklasse  "AbstractRelayBricklet" oder "AbstractSwitchableOutput" oder sowas gäbe, worüber man eben beide speziellen Bricklets gleich benutzen könnte. Immerhin will man ja auch das gleiche erreichen ;-).

Die Inputs habe ich mir noch wieder angeschaut, aber da könnte das möglicherweise auch sinnvoll sein?

Was meint Ihr?

Gruß,

Thomas E.-E.

Ich glaube meine Erklärung zum Einsatz von TF war bisher noch sehr lückenhaft und wir sprechen daher aneinander vorbei.

Wir wollen mit den Unit-Tests nicht den TF Stack testen, sonder TF als einen Testtreiber benutzen, um manuelle Interaktion mit externer Hardware zu simulieren und diese im Rahmen von Integrationstests bereitzustellen.

Weil wir im Rahmen der Unit-Tests auf die gleiche Hardware von unterschiedlichen VMs zugreifen, brauchen wir eben den exklusiven Zugriff auf den TF stack.

Hmmm... könnte im Rahmen der Unit-Tests egal sein, dass es WiFi ist... (außer organisatorisch).

hmm, verstehe ich noch nicht so ganz. Im WiFi-Fall nutzen wir doch gar keinen "externen" brickd, können also auch einen Einfluss auf das Connection-Handling nehmen, oder?

Ideal wäre es für Unit-Tests eigentlich, wenn jedes Device ein zugehöriges Interface hätte. Dann könnte man die Devices ganz einfach mocken und ihr wärt nicht auf echte Hardware angewiesen. (Wie wollt ihr testen, ob Methode x mit einer TimeoutException klarkommt?)

da gebe ich Dir recht ... wäre nett :-)

Im Moment lösen wir das organisatorisch. Und zwar so, dass die Tests, denen sicher ein TF stack zur Verfügung steht eine entsprechende Annotation erhalten.

Hi,

Wie wäre es wenn ihr euren eigenen Brickd schreibt (bzw. den originalen modifiziert)

das klingt gut, jedoch nutzen wir nicht den brickd sondern erreichen den TF stack über die WiFi Extension. Das würde bedeuten: Firmware schreiben, oder?! Damit wären wir dann aber ganz schön Lowlevel unterwegs ... jedenfalls mehr, als mir das eigentlich lieb wäre ;-).

Gruß,

Thomas E.-E.

Hallo Zusammen,

wir nutzen die Tinkerforge Module zur Testautomatisierung. Dafür müssen wir beim Ablauf der Tests sicherstellen, dass immer nur ein Test gleichzeitig auf den Tinkerforge Stack zugreift.

Aktuell lösen wir das darüber, dass wir einen Port eines Relay-Bricklet so lange einschalten wie der Stack besetzt ist und ihn am Ende wieder ausschalten. Nicht schön (und vor allem auch nicht Ressourcen-schonend), aber es geht.

Habt ihr vielleicht noch bessere Ideen?

Wir greifen von unterschiedlichen VMs auf den gleichen Stack zu. Das halten einer statischen Variable ist also keine Option. Überhaupt würde wir ungern auf "Clientseite" einen Status einführen, sondern lieber irgendein magischen Register auf dem TF stack setzen :-).

Wäre für jeden Hinweis dankbar,

Thomas E.-E.

ok, danke!

Habe nun eine Wartemethode implementiert ...

Hallo Zusammen,

ich verwende TF (mit Java Bindings 2.0.2) als Hilfsmittel beim automatisierten Testen. Die Konfiguration des Tests (JUnit) soll möglichst generisch erfolgen. Insofern habe ich mich als EnumerationListener registriert und werde dort auch wunderbar über weitere registrierte Komponenten informiert.

Das Problem ist nun, dass der JUnit-Test erst dann loslaufen darf, wenn der komplette Stack initialisiert wurde, also alle Bricks/Bricklets einmal am EnumerationListener vorbei sind.

Wie könnte ich das anstellen? So wie ich das sehe, gibt es kein Event für "enumerate started" bzw. (viel wichtiger) "enumerate finished".

Wäre für jeden Hinweis dankbar,

Gruß,

Thomas E.-E.

push to top :-)

Habe das heute auf heise gelesen und mich auch direkt gefragt in welcher weise das mit TF gepaart werden kann. Vermutlich kann man das TF-Protokoll irgendwie in die Plattform einbinden oder so, habe ich mir aber noch nicht genau angeschaut

bin gerade auf dieses Thema gestoßen worden, da ich mich einerseits mit dem Projekt openHAB ganz gut auskenne (bin einer der Projektowner) und andererseits seit ein paar Wochen einen TF-Stack (mit WLAN Extension) zur Verfügung habe.

Die Anbindung würde vermutlich über die Java-bindings laufen, die von TF ja freundlicherweise bereitgestellt werden. Man müsste sich dann noch ein paar Gedanken machen, wie man am besten die Konfiguration formuliert und ein paar Stunden Zeit geschenkt bekommen ... ;-)

Welche Bricklets habt Ihr denn so im Einsatz?

Gruß,

Thomas E.-E.