Jump to content

peter_tau

Members
  • Gesamte Inhalte

    27
  • Benutzer seit

  • Letzter Besuch

Letzte Besucher des Profils

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

peter_tau's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Hallo Theo, Du warst offensichtlich sehr aktiv, sodass ich wieder einige Snapshots später wieder einsteige. Ist absehbar, wann Du die folgende Bricklets unterstützen kannst? LoadCellV2 PtcV2 RemoteSwitchV2 Viele Grüße Peter
  2. Hallo Theo, das Anlegen einer Sitemap mit den in der PaperUI erzeugten Things und Items hat funktioniert. Mit meiner Frage ist es mir aber darum gegangen, Things und Items nicht unbedingt in der PaperUI anzulegen, sondern in *.things- und *.items-Dateien. Dadurch ist ein Sichern und Wiederherstellen der Konfiguration sehr einfach. Oder wie gehst Du vor, damit bei einem neuen Setup nichts erneut in der PaperUI konfiguriert werden muss? Ich habe übrigens Deinen Snapshot 2.5.0 eingespielt und die zusätzlich unterstützten Bricklets sind sofort in der Inbox aufgetaucht. Allerdings fallen mir folgende Abweichungen auf, wenn ich die Bricklets im Vergleich mit Deinem V1-Binding ansteuere: 1) Die Messwerte von BrickletHumidityV2 und BrickletHumidity werden in der Sitemap um einen Faktor 100 zu groß angezeigt. Dabei verwende ich label="Luftfeuchtigkeit [%.1f %%]". In der PaperUI habe ich das Item als Number:Dimensionless konfiguriert und sehe unter Control den ganzzahligen Prozentwert. Insofern verstehe ich schon, warum ein Faktor 100 entsteht, da die Zahl 1 für 100% steht und dementsprechend zB 20.95 als 2095% Prozent dargestellt werden. Vermutlich müsste ich das Item in der PaperUI anders konfigurieren. Aber bei einer Durchsicht der Datentypen fand ich keinen Wert, der für Prozent stehen könnte. 2) Merkwürdigerweise zeigt BrickletAmbientLightV2 in einem dunklen Raum etwa 231 lx an; wenn ich das Bricklet über das alte Binding ansteuere, erhalte ich plausible 0,01 lx. Ich habe das Bricklet mit den Defaultwerten konfiguriert, ohne irgendwelche Meßbereichezu konfigurieren. 3) Das BrickletBarometer hat mir in der Autodiscovery AirPressure und Altitude angeboten, nicht aber Temperature, welche an und für sich auch verfügbar ist. Ist das bloß noch nicht unterstützt oder ein Fehler? Viele Grüße Peter
  3. Hallo Theo, über die PaperUI von OpenHAB 2.4 konnte ich folgende Bricklets einbinden und erhalte Messwerte: BrickletMotionDetectorV2 BrickletAmbientLightV2 BrickletHumidityV2 BrickletTemperature Darüber hinaus habe ich noch folgende Bricklets angeschlossen, die nicht in der Autodiscovery erscheinen, weil sie vom neuen Tinkerforge-Bindung (noch) nicht unterstützt werden: BrickletSegmentDisplay BrickletBarometer BrickletHumidity BrickletLCD20x4V1.2 BrickletPTCV2 BrickletRemoteSwitchV2 Die Konfiguration in der PaperUI war problemlos. Wie müsste ich das syntaktisch richtig in things- und item-Dateien übertragen? Mir ist nicht klar, wie ich die Parameternamen korrekt aus den Things und Channels errate, damit ich die Konfiguration überführen kann. Viele Grüße Peter
  4. Hallo Theo, verträgt sich das neue OpenHAB2 Binding mit Deinem bisherigen OpenHAB1 Binding? Oder muss ich sicherstellen, dass entweder nur das eine oder das andere Binding aktiv ist? Hintergrund ist der, dass ich einige Bricklets in Betrieb habe, die Du im neuen OpenHAB2 Binding noch nicht unterstützt. Da wäre es natürlich sehr praktisch, wenn ich die Konfiguration splitten könnte. Konkret verwende ich folgende Bricklets und könnte das neue Binding damit testen: AmbientLightV2 Barometer DualRelay Humidity HumidityV2 Lcd20x4V1.2 MotionDetectorV2 NfcRfid Nfc PtcV2 RemoteSwitchV2 SegmentDisplay Temperature Viele Grüße Peter
  5. Hallo Theo, vielen Dank für Deine Hinweise. Gerne werde ich das neue Binding testen und im Thread https://www.tinkerunity.org/forum/index.php/topic,1769.msg26294.html#msg26294 berichten! Viele Grüße Peter
  6. Hallo, ich verwende OpenHAB 2.3.0-1 und adressiere damit zwei unterschiedliche Brickstapel. Der eine Brickstapel mit 6 Sensoren läuft bis auf ein anderweitiges Problem stabil, der andere Brickstapel mit 5 Sensoren ist der hier beschriebene, der die Verbindung verliert. In beiden Fällen sind 2 Master Bricks mit einer Ethernet Master Extension w/o PoE 1.0 verbaut. Es sind jedoch unterschiedliche Bricklets verbaut, und ich greife beim problematischen Brick Stapel via Python Scripts zu, die entsprechend den Code-Beispielen wie folgt aufgebaut sind: ipcon = IPConnection() # Create IP connection ... ipcon.disconnect() Die Logfiles zeigen, dass fortlaufend Messwerte eingelesen werden, bis schließlich ein Fehler bei jeder Messwertabfrage auftritt: File "/etc/openhab2/scripts/motion_detect.py", line 15, in <module> ipcon.connect(HOST, PORT) # Connect to brickd File "/home/openhab/.local/lib/python2.7/site-packages/tinkerforge/ip_connection.py", line 556, in connect self.connect_unlocked(False) File "/home/openhab/.local/lib/python2.7/site-packages/tinkerforge/ip_connection.py", line 756, in connect_unlocked tmp.connect((self.host, self.port)) File "/usr/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 111] Connection refused Leider kann ich aus den OpenHAB Logfiles keinerlei Hinweise finden, was der Auslöser für dieses Verbindungsproblem ist. Was könnte ich denn einbauen, damit ich sehe, ob eine Verbindung nicht richtig gelöst wird und vor allem, was kann man tun, wenn man das erkennt?
  7. Hallo, aktuell nutze ich das Tinkerforge Binding von Chris Carman, das unter https://github.com/openhab/openhab1-addons/wiki/tinkerforge-binding verfügbar ist. Dieses ist nicht mehr auf dem letzten Stand, insbesondere fehlen viele der in den vergangenen zwei Jahren neu hinzugekommen Bricklets. Ich habe mich damit beholfen, dass ich Messwerte von Bricklets via Python Scripts zugänglich mache und die Python Scripts über das Exec Binding (Shell-Aufruf) abfrage. Beispiel: rule "Measure Humidity" when Time cron "0/10 * * * * ?" then createTimer(now, [ | val results = executeCommandLine("/etc/openhab2/scripts/humidity.py", 2000) Measure_Humidity.postUpdate(UNDEF) logInfo("Measure_Humidity_Command", "Result:" + results) val humidityResult = 0 try { humidityResult = Float::parseFloat(results) Measure_Humidity.postUpdate(humidityResult as Number) } catch(Throwable t) { logError("Measure_Humidity_Command", "Result out of range") } ]) end Das erscheint mir jedoch sehr umständlich, vor allem, da in den Rules regelmäßig abgefragt abgefragt werden muss, anstelle eines Triggers, der auf eine Änderung des Messwerts abzielt. Hat jemand eine Best Practice, um Bricklet-Messwerte in OpenHAB abzufragen, ohne ein festes Zeitintervall für Abfragen vorzusehen? Viele Grüße Peter
  8. Hallo, ich habe den Brickstapel gestern erneut via Ethernet Master Extension ans Netzwerk gehängt. Nach weniger als 24 Stunden kamen keine Meßwerte am PC mehr an. Der Brick Viewer kann keine Verbindung aufbauen. Interessanterweise funktioniert noch ping auf die Ethernet Master Extension. arp -a zeigt die korrekte MAC der thernet Master Extension. Nachdem ich bereits die Ethernet Master Extension ausgetauscht habe und der Fehler weiterhin besteht, frage ich mich, was der nächste Schritt ist, um dem Problem auf die Spur zu kommen.
  9. Vielen Dank für die Hinweise! Ich werde meine Tests mit einer aktuellen WiFi Master Extension 2.0 wiederholen bzw. das Barometer Bricklet 1.0 weiter beobachten.
  10. Ich habe bereits folgende Tests gemacht: Gestartet habe ich mit der fertig aufgebauten Originalkonfiguration der Serverraumüberwahung bestehend aus Red Brick / Ethernet Extension with POE / MasterBrick 2.1. In dieser Konfiguration traten die Ausfälle auf. Dann habe ich den Red Brick ausgebaut. Auch ohne Red Brick traten die Ausfälle auf. Im nächsten Schritt habe ich Ethernet Extension with POE gegen eine Ethernet Extension w/o PoE ausgetauscht und noch einen weitere MasterBrick 2.1 hinzugefügt, in der Reihenfolge MasterBrick 2.1 / Ethernet Extension w/o PoE / MasterBrick 2.1. Auch hier kam es zu Ausfällen. Von dem her vermute ich nicht, dass der Fehler an der jeweiligen Ethernet Extension hängt. Als nächstes werde ich den Stapel an den gleichen Switch hängen, an dem bereits der andere Stapel ohne Verbindungsausfälle läuft. Oder gibt es noch weitere Hinweise?
  11. Das werde ich beobachten. Nach einem Neustart des Stapels ist der Effekt jedenfalls verschwunden.
  12. Gibt es noch Hinweise zum Verlieren der WiFi Master Extension 1.0? Sollten die Probleme mit einer aktuellen WiFi Master Extension 2.0 behoben sein? Hat jemand Hinweise zu den fehlenden Temperatur Updates beim Barometer Bricklet 1.0? Braucht es hier das neue Barometer Bricklet 2.0?
  13. Hallo, vielen Dank für die schnelle Antwort. Die Update-Funktion meines Brick Viewers zeigt keine Updates an. Die Master Brick Firmware ist auf Version 2.4.9.
  14. Hallo, vielen Dank für die schnelle Antwort. Die Update-Funktion meines Brick Viewers zeigt keine Updates an. Die Master Brick Firmware ist auf Version 2.4.9.
  15. ...andererseits habe ich einen zweiten Brickstapel, den ich ebenfalls mit Ethernet Master Extension w/o PoE 1.0 betreibe, und bei diesem ist es ebenfalls so wie zuvor bei der WiFi Master Extension 1.0, dass ich diese regelmäßig vom Netz nehmen muss, da die Ethernet-Verbindung verloren geht.
×
×
  • Neu erstellen...