Jump to content

teichsta

Members
  • Gesamte Inhalte

    20
  • Benutzer seit

  • Letzter Besuch

Über teichsta

  • Geburtstag 28. Dezember

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

teichsta's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • Collaborator Rare
  • First Post
  • One Month Later
  • One Year In

Recent Badges

0

Reputation in der Community

  1. 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 :-)
  2. 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?
  3. 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 …
  4. 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?
  5. Hi, 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.
  6. 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?
  7. 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.
  8. 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.
  9. 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 ...
  10. +1 wäre auch seeeeeehr an der Ethernetextension interessiert ...
  11. 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?!
  12. 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.
  13. 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.
  14. 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? 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.
×
×
  • Neu erstellen...