peter_tau

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

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

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

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

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

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?

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

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.

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.

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?

Das werde ich beobachten. Nach einem Neustart des Stapels ist der Effekt jedenfalls verschwunden.

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?

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.

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.

...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.

Hallo, ich habe eine Serverraumüberwachung bestehend aus MasterBrick 2.1 / Ethernet Master Extension w/o PoE 1.0 im Einsatz, die zunächst einen Red Brick beinhaltete. Leider lief der Stapel nicht stabil. Nach ein paar Tagen war der Stapel vom Netzwerk aus nicht erreichbar; weder konnte man mit einem BrickViewer zugreifen noch erhielt man mit ping eine Antwort von der Ethernet Master Extension. Zur Fehlereingrenzung entfernte ich den Red Brick und habe stattdessen einen weiteren Master Brick 2.1 hinzugefügt: MasterBrick 2.1 / Ethernet Master Extension w/o PoE 1.0 / MasterBrick 2.1. Leider läuft der Stapel dennoch nicht stabil. Nach ein paar Tagen fällt weiterhin die Ethernet-Verbindung aus. Erst wenn ich den Stapel kurz vom Strom trenne, ist er danach wieder erreichbar. Hat jemand einen Hinweis, woran diese Ausfälle liegen können? Am Steuer-PC habe ich via Ethernet Extension zwei Brickstapel im gleichen LAN angeschlossen. Der andere Brickstapel bleibt erreichbar. Beim problematischen Brickstapel ist lediglich noch ein Switch dazwischen, an dem sonst auch unser Server hängt. Mit diesem Netzwerk-Setup haben wir sonst keine Probleme. Hat jemand eine Idee, wie ich hier weiterkommen könnte? Vielen Dank für Eure Hinweise! Peter Viele Grüße Peter

Hallo, ich habe die WiFi Master Extension 1.0 durch eine Ethernet Master Extension w/o PoE 1.0 ersetzt und habe seither keine Verbindungsprobleme mehr, ohne die Software zu ändern. Der Brickstapel ist seit dem Austausch der WiFi Master Extension 1.0 durch die Ethernet Master Extension w/o PoE 1.0 bereits seit über eine Woche erreichbar, ohne dass ich den Stapel kurz vom Netz nehmen muss. Viele Grüße Peter

Hallo, ich habe ein Stapel bestehend aus MasterBrick 2.1 / MasterBrick 2.1 / Ehternet Extension w/o PoE 1.0 in genau dieser Reihenfolge im Einsatz und nutze dabei ein Barometer Bricklet 1.0, das auch Temperaturmessung ermöglicht. An und für sich läuft der Stapel stabil. Allerdings kommt es nach einigen Tagen vor, dass der Barometer Bricklet 1.0 keine Temperatur-Updates mehr liefert. Die Temperatur "friert" auf einem bestimmten Wert ein. Alle anderen Bricklets einschließlich des vom Barometer Bricklet 1.0 gemessenen Luftdrucks kommen weiterhin an. Alle Bricks und Bricklets befinden sich auf dem letzten Firmware-Stand von November 2018. Hat jemand einen Hinweis, woran dieses Einfrieren liegt? Sind Einschränkungen beim Barometer Bricklet 1.0 bekannt, die mit dem neuen Barometer Bricklet 2.0 behoben sind? Viele Grüße Peter

Hallo, vielen Dank für die Hinweise. Ich verwende zwei Python-Skripte, die beide mit ipcon.disconnect() enden. Darüber hinaus ist das ganze in OpenHAB 2.3.0 eingebunden und daher die IP-Adresse in der tinkerforge.cfg des Tinkerforge Binding hinterlegt. Wenn der Brick-Stapel nicht mehr von den Brick Daemons erreichbar ist, funktioniert auch kein ping. Bislang hatte ich Zugriff von drei Brick Daemons, da der Brick-Stapel von drei Rechnern abgefragt wurde. Ich habe testweise den Zugriff auf einen einzelnen Brick Daemon reduziert und beobachte das Verhalten. Viele Grüße Peter

Dear @iia, I used the configuratio example from @theo which you will find at: https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/tree/master/weatherstation However, the weather station was not neither directly connected to the red brick nor via USB, but over a WiFi connection established by a WiFi Master Extension connected to the weather station. In my setup, after the first run of OpenHAB 2 which took about as long as described in your post, the system was extremely slow so that I could see second after second how the LCD was updated. After a reboot, the system was still quite slow but at least usable with the weather station. However, this situation did not remain for long. After some hours, the red brick was still responding but the weather station was stuck. Due to these severe performance issues, I already moved OpenHAB 2 to a more powerful hardware. Now I am experiencing long-term performance problems (single rules stop working) which seem to be related to threads that are not ended correctly. But this is an issue for a different forum. Best regards, Peter

Hallo, ich habe einen Brick-Stapel mit WiFi Master Extension 1.0 im Einsatz. Die WiFi Master Extension ist im WLAN unseres Routers angemeldet. Das Setup ist grundsätzlich lauffähig. Leider geht im Durchschnitt einmal am Tag die Drahtlosverbindung zwischen Brick Daemon auf externem PC und dem Brick-Stapel verloren. Eine Auswertung am Router zeigt, dass die Drahtlosverbindung zum Brick-Stapel nicht mehr besteht. Dadurch ist der Brick-Stapel nicht mehr auf Netzwerkebene erreichbar; ein ping-Kommando schlägt fehl. Nach kurzem Unterbrechen der Spannungsversorgung zum Brick-Stapel funktioniert alles wieder. Die Entfernung zwischen Brick-Stapel und Router beträgt etwa 12 Meter. Es besteht Sichtverbindung mit entsprechend starkem Signal. Ich habe testweise neben dem Brick-Stapel einen PC mit WLAN-Verbindung laufen lassen. Während der PC weiterhin nach mehr als 24 Stunden über das WLAN extern erreichbar war, hat sich der Brick-Stapel bereits "aufgehängt" gehabt. Hat jemand Erfahrungen mit der Verbindungsstabilität der WiFi Master Extension 1.0? Was kann gegebenenfalls an Log-Dateien aufgezeichnet werden, um den Fehler zu finden? Vielen Dank für Eurre Unterstützung. Peter

THank you very much for your support.

Thank you very much for your comment. Clearly, switching between 432 MHz and 1 GHz would increase processor speed by more than a factor of 2. However, the described issue does not concern an optimization problem where a factor 2 gives quite a boost. When I talk about of slowdown, you might assume a required factor of much more than 10, probably factor 100, to come into acceptable regions. The speed of the system is such slow that OpenHAB 2 is definitely not running, even with a simple configuration of four sensors displaying their measurement values on an LCD (Weatherstation). At present, I would like to know whether anybody else succeeded in running OpenHAB 2.2.0/2.3.0 on a Red Brick taking Image 1.11 and 1.12 as a basis? For testing purposes, I installed the items/rule/sitemap example from the Weatherstation kit. The system is far too slow that it works. It took me a while to re-test the setup with cpufreq-set -g performance as the Ethernet PoE Master Extension connected to the red brick lost its configuration after shutting down the red brick last time. The Brick Viewer showed the red brick, but no interface at all. I needed to shutdown the red brick again and redo it. After another start, the Ethernet PoE Master Extension was visible again. However, I needed to manually connect again. Very strange. I speeded up the CPU with the given command. Even with a factor 2, everything is much too slow... Does not work at all. Originally, I operated the red brick with power obtained from the Ethernet PoE Master Extension. I realized that the Ethernet PoE Master Extension got extremely hot. Right now, I ensure that no power comes across the Ethernet cable and I power the red brick directly. Could the excessive heat be a source of these problems? At present, I would be glad to find out whether red brick images 1.11/1.12 with Open HAB can be considered as broken or whether the behavior of my red brick is unexpected? Thank you very much for your support.

Hi, I recently flashed the new red brick image 1.12 and started the red brick. After activating Open HAB via Brick Viewer, I noticed that Open HAB was starting very slowly. It took several minutes until the system was up and running. It also took quite a time to run through the initial setup of Open HAB 2.3.0. I installed a working configuration of items/rules/sitemap of a particular Tinkerforge setup moved from another site that also runs Open HAB 2.3.0. So I knew that this configuration is all right. However, Open HAB is such slow that the sitemap did not show any values. After a reboot of the red brick and a restart of the separate Tinkerforge hardware, the result was better: The Tinkerforge hardware was initialized from the red brick, I could watch how the LCD content was painted one after another, but nevertheless it is still very slow. Does anybody else have these issues with a fresh install of Image 1.12? Do you know any counter-measures to speed up? I realized that the brickd consumes permanently 30% CPU time, while another red brick based on a much earlier image has a brickd at around 12% as the strongest process. Best regards, Peter

Hallo, ich habe ein red-brick mit Firmware 1.11 in Betrieb und habe die Serverraumüberwachung konfiguriert. Allerdings ist in der aktuellen Hardware zur Serverraumüberwachung ein Humidity Bicklet 2.0 enthalten, welches die Daten in 1/100 % ausgibt anstelle von 1/10 %, wie es noch im Humidity Bricklet der ersten Generation der Fall war. Dadurch stimmen die Nagios Alerts des Humidity Bricklets 2.0 nicht mehr, weil die Serverraumüberwachung noch von einem alten Humidity Bricklet ausgeht. Bisher habe ich die Konfiguration der Serverraumüberwachung ausschließlich über den BrickViewer gemacht. Wo kann ich das direkt im System machen und dabei gleich die Meßwertkorrektur 1/10 <-> 1/100 anpassen? Vielen Dank für Eure Hinweise. Viele Grüße Peter