Jump to content

StefanOHAN

Members
  • Content Count

    158
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by StefanOHAN

  1. Hallo Erik, ich hatte diese WE einen eigenartigen Effekt für das "Tinkerforge Remote Switch Bricklet 2.0". Diese steuert eine Funksteckdose vom Typ A. Bisher hat es immer gut funktioniert (wobei ich ehr selten die Dose ansteuerte). Gestern konnte ich über Openhab und über den Brickviewer die Steckdose nicht mehr ein und aus schalten. Über die zugehörige Fernbedienung konnte ich die Steckdose jedoch schalten. Auch konnte ich im Openhab-Log keine Meldung sehen wenn das "Tinkerforge Remote Switch Bricklet 2.0" eigentlich ein Signal von der Fernbedienung hätte empfangen sollen. Es waren
  2. Hallo Erik, sorry dass ich erst jetzt auf Deine Frage Antworte. Ich bin der Meinung von Jerome, dass es das Beste wäre gleich auf Openhab 3 zu wechseln. Mein Prod-System habe ich noch nicht auf OH2.5 migriert, daher würde ich es gleich auf OH3 umstellen. Ich plädieren wie Jerome dafür, dass Du gleich das Binding dann OH-3 konform umstellst (Bitte kurze Info wenn das 2.5 Binding dann nicht mehr zum download bereit steht, dass ich mir ein Backup ziehen kann) Frage: Du hast mir ja die spezial-Version wegen meines Recconect Problem der 2-Dämon's bereitgestellt. Baus
  3. Hallo MiRo, als ich Deine Nachricht sah, habe ich heute mal schnell auf meinen Testsystem geprüft ob meine IO16 & IO16V2 Status-Änderungen von Openhab dargestellt werden. Meine HW / FW der Bricklets & Masterbrick ist Identisch, nur nutze ich als OS-Openhabian ebenfalls mit OH 2.5.8. Die Status Änderungen werde bei mir beim betätigen der Taster angezeigt und die entsprechenden Rules reagieren. Ich sehe momentan bei mir einen Unterschied wenn ich openhab> bundle:list -s | grep ink ausführe erhalte ich Du hast bei Dir eine Version 2.1.28. Ich bin mir aber
  4. Hallo Erik, ich habe jetzt meine Konfiguration umgestellt und nochmal erweitert und bin bei meinem neuesten Bricklet (realtime-Clock) auf einen eigenartigen Effekt gestoßen. Config neu (die Bricklets sind nicht umgesteckt worden) Raspberry Pi 2b → hat das HAT-Brick aufgesteckt und die MasterBrick die per USB angeschlossen sind → es ist dort nur ein minimal Raspian installiert sowie der brickd Dämon, kein openhab Raspberry Pi3b → hat ein Hat-Zero-Brick (neu) aufgesteckt → an dem Hat-Zero ist nur die Realtime-Clock 2.0 (neu) angeschlossen → es
  5. Ah ok, verstehe. Mein Prodsystem hat aktuell nur USB-Masterbrick und nach dem Umbau auf Openhab2 USB-Masterbrick und Hatbrick. Nur das TestSystem Openhab2 hat diese beiden Anbindungs-Versionen. Ich bin gerade am überlegen ob ich das WIFI komplett aus der TestKonfig raus schmeiße, das HatBrick und die USB-MasterBrick's über einen PI2 anbinden. Das Openhab-System würde dann auf einen Pi3/4 laufen an dem kein MasterBrick/Hat-Brick direkt angeschlossen ist. Ich würde die Dämonen dann Remote mit dem PI2 verbinden. (ob das mit dem PI2 als Remote-Server sauber funktioniert muss i
  6. Hallo Erik, was meist Du mit "du hast ja mehrere Verbindungen zu Brick Daemons" ? aktuell habe ich folgenden Aufbau 1x BrickDämon USB/HAT, über diesen Dämon sind die Masterbrick die über USB an den Pi angeschlossen sind und das HAT-Brick das auf dem selben Pi aufgesteckt ist , erreichbar. 1x BrickDämon der per WIFI-Extention für die Anbindung einen Masterbrick zuständig ist. viele Grüsse Stefan
  7. Guten Morgen Erik ich habe gestern 4 shell:thread erzeugt Nr1-20200831-shell_threads-vor-ausfall >> hier war alles noch funktionsfähig Nr2-20200831-shell_threads-connection_lost-1 >> Status kurz nach Ausfall WIFI, erste Meldungen im Log dass Things nicht erreichbar sind Nr3-20200831-shell_threads-connection_lost-2 >> Status ca 2-3 min nach Ausfall WIFI, jetzt sind auch über "paperui/index.html#/configuration/things" die Things als offline markiert Nr4-20200831-shell_threads-reconnect >> Status nach erfolgreichen reconnect, alle Things in "paperu
  8. Guten Morgen Erik, Update: Jetzt ist das ganze System problemlos über das komplette Wochenende gelaufen. Ich hatte pro Tag mehrfach die Reconnect des MasterBrick/WIFI. Frage: den shell:threads, soll der unmmittelbar nach dem connection-Lost oder dem reconnect sein ? Dann würde ich mal einen reconnect provozieren um den die Info zur passenden Situation zu bekommmen. viele Grüsse Stefan
  9. Guten Morgen Erik, kurzer StatusUpdate Das System läuft jetzt seit über einen Tag ohne Ausfallerscheinungen des Astro/NTP/Exces, alle FT Komponenten funktionieren, die Rules laufen, und das Masterbrick(WIFI) wurde mehrfach ohne Probleme reconneted. Viele Grüsse Stefan
  10. Guten Morgen Erik, ich hab gestern Abend Dein Spezial-Test-Binding eingespielt. Um zu sehen ob alles funktioniert, habe ich wieder alle TF-Bricklets, das NTP / ASTRO / EXEC Binding in die Konfiguration aufgenommen. Ebenfalls alle Rule's die ich im Frühjahr zum Testen der verschieden Funktionen erstellt habe sind wieder aktiv. Seit gestern Abend (ca 22Uhr) läuft wieder alles. Bis jetzt habe ich keine Fehler gesehen. Ich hatte heute auch schon ein paar WLAN-Kanal-Wechsel und damit WIFI/Masterbrick reconnect, bis jetzt ohne Probleme. Ich werde Dir berichten ob es Probleme gibt
  11. Hallo Erik, ich werde heute Abend das Spezial-Test-Binding einspielen und gleich noch das Astro-Binding aktivieren. viele Grüsse Stefan
  12. Hallo Erik, hallo Batti @ Danke Batti für die Info, ich muss mal schaun ob ich evtl auf Ubuntu umsteige. Erik, als am Astro liegt es anscheinend auch nicht, gestern Abend nach ca 16 Laufzeit hat der Exec wieder den Dienst eingestellt. Ich füge den output des shell:thread bei (ich hab den output per copy & paste in Notepad+ eingefügt und als txt abgespeichert wenn es Probleme beim Öffen geben sollte) Nachdem ich den shell:thread erstellt habe, habe ich log:set TRACE für folgend Bindings aktiviert (ASTRO ist noch nicht installiert), org.openhab.binding.tinkerfo
  13. Hallo Erik, danke für die schnelle Antwort und Deine Vorschläge. Ich test gerade mal ohne dem Astro Binding und schau wie lange das problemlos funktioniert. Aktuell (also auch als das ASTRO-Binding noch aktiv war) waren keine Rules aktiv, die hab ich bewusst weg gelassen. Ich werde das mit dem log:set TRACE [binding-name] für die beteiligten Bindings in ein oder zwei Tagen testen, ich will vorerst mal sehen wie sich das System ohne Astro verhält. Von der Log Menge sehe ich jetzt kein Problem, da ich zwischenzeitlich über eine usb-SSD arbeite (ich will damit v
  14. Hallo Erik, nach dem FW-Update des HAT-Brick trat mein alt bekanntes "sporadische" auftretenden Problem, dass das Astro- & NTP Binding den Betrieb einstellten, häufiger als bisher auf. Aus diesem Grund führte ich einen OS (openhabian 1.5) und Openhab (stabel-Version) Update aus. Leider trat danach der Fehler mehrfach täglich auf und ich entschloss mich das Test-System komplett neu aufzusetzen (jetzt mit Openhabian 1.6 und neuer SD-Card, das Testsystem läuft auf einem PI3, das root-System liegt jetzt auf einer USB-HDD). Auf auf dem komplett neu installierten System, trat das
  15. Hallo Erik nur wenn es von Interesse ist, die Leerlauf Temperaturen auf dem PI4 B mit 8GB RAM. Es ist nur das Openhabian-OS mit Openhab installiert. Über einen "Exec"-Channel werden die GPU & CPU Temperaturen abgefragt (analog dem Link den Du gepostet hast), es laufen keine Rules. Der Pi ist in ein Armor-Case-Block Alu-Kühlkörper-Gehäuse eingebaut. Raumtemperatur => 29 Grad >> Pi-GPU/CPU-Temperatur ca 46 Grad (ohne Lüfter) Raumtemperatur => 26 Grad >> Pi-GPU/CPU-Temperatur ca 42 Grad (ohne Lüfter) Raumtemperatur => 29 Grad >> Pi
  16. Hallo Erik, dann warte ich mit dem Umbau/Umstellung des Prod-System noch etwas, bis klar ist ob Du den Generator hierfür anpassen kannst. Danke für den Link für einen Channel zur Temperaturüberwachung der GPU/CPU. Auf ähnlicher Basis hab ich für mein OpenHAB 1.8 System eine Überwachung am Laufen, ich sehe aber an dem Beispiel, dass meine Version noch Verbesserungspotential hat 🙂 Zufällig ist heute mein neuer P4 8GB gekommen, ich werde versuchen diese WE mal sein Temperaturverhalten mit dem Kühlkörper zu testen (noch ohne HAT-Brick). viele Grüsse St
  17. Hallo Erik, danke für Deine Rückmeldung, bin schon gespannt was bei Deinem Test heraus kommt. Thema HAT-Brick & Pi4 Stromversorgung Ich habe kurz überschlagen was die verschieden TF Komponenten in Summen (MAXIMAL) an Strom ziehen würden >>HATBrick angeschlossene Bricklets ca 300mA >>per USB am Pi angeschlossenen MasterBricks (2) ohne eigenes StepDown-Power-Supply & Bricklets MAXIMAL 250mA >>per USB am Pi angeschlossenen MasterBricks (3) mit eigenem StepDown-Power-Supply & Bricklets MAXIMAL 600mA. (nur hier habe ich 2x Dual-Relais
  18. Hallo Eric, ich hätte drei kurze Fragen: 1) Du schreibt auf die Frage von rasby am 25.05.2020 Wie sieht hier Deine Planung aus ? Hintergrund meiner Frage, ich will mein Prod-System umbauen. Wenn ich die Item Anlege, müsste ich wissen, ob es hier in Zukunft ein Binding geben würde, dass bei dem IO-16 / IO-4 / Industrial In-Bricklets die als Input konfigurierten Channel als Contact darstellen. 2) Ich hatte schon mal das Thema Konfiguration der TF Komponenten über eine "Thing-Datei" angesprochen, hattest Du schon die Zeit/Möglichkeit einen kleinen Leitfade
  19. Hallo Eric, kurze Frage das Beta-Binding ist doch noch die Version 23, oder ? Nur das Java-Binding hat die Nummer 26, oder ? viele Grüsse Stefan
  20. Hallo Alex, Vorschläge für Rule's habe ich keine mehr. Vermutlich hast Du auch schon in den System-log's nachgeschaut. Mein Erfahrung mit Zugriffs/Berechtigung Fehler im Zusammenhang mit executeCommandline und Exec war, dass diese selten in den Openhab Logs zu finden waren sondern meist nur in den verschiedenen System log's (/var/log/ ...). Dies mir nur durch Zufall aufgefallen, als der "Openhab playSound" nicht funktionierte. Erst als ich in den verschiedenen Linux System-logs suchte, fand ich eine Fehlermeldung die mir half das Problem beseitigen. Obwohl der Openhab-User sudo-Rec
  21. Hallo Alex (Tamino) stimmt jetzt wo ich Deine Frage nochmal genau gelesen habe, sehe ich dass du auf den Punkt mit der Whitelist schon hingewiesen hast. Einen Vorschlag hätte ich noch, und zwar mit executeCommandLine(String commandLine) Kannst du Du Deinen Skript auf eine Befehl reduzieren ? Eventuell kann man mit exceuteCommandLine auch ein Shell Skript aufrufen. Die Syntax in Openhab2 scheint ähnlich zu sein wie in Openhab 1.9. Ich bin leider mit meiner Migration von Openhab1.9 auf Openhab2 noch nicht beim exexuteCommandLine angekommen und habe daher noch keine Erfahrung
  22. Hallo Tamino, Ich hatte kürzlich versucht mit dem Exec-Binding "/bin/date" aufzurufen und es funktionierte nicht (in meiner Openhab 1.9 Konfiguration funktioniert das ohne Probleme) . Ich fand dann in der Doku des EXEC-Binding den Hinweis, dass seit Openhab2 alle Befehle die über das Exec-Binding ausgeführt werden sollen, in die Datei "exec.whitelist" eintragen werden müssen. Nachdem ich die Datei "/bin/date" eingetragen hatte und einen neustart ausführte, klappte der Aufruf wieder. Eventuell gilt dies auch für Shell-Skripte die Du über das Exec-Binding aufrufen willst.
  23. Hallo Erik ich habe heute das neu Bindings (23) installiert. Leider kam es wieder zur gleichen Fehlermeldung für das Bricklet das ich beim HW-Umbau von WIFI-Dämon auf Dämon-USB/HAT umgestellt hatte. Nach erneutem leeren des openhab-cache sowie 2 x System Neustart (per Init-6), war der Fehler weg. Jetzt scheint wieder alles zu funktionieren. Viele Grüsse Stefan
  24. Hallo Tamino, schön zu sehen dass hier weitere "Franken" im Forum aktiv sind 🙂 grüsse aus Ansbach Stefan
  25. Hallo Erik, so habe jetzt noch 3 x das ganze System neu gestartet, einmal stoppen uns starten des Service, einmal mit init 6 einmal mit init 0 Glaub es oder nicht, der Fehler ist weg (schon nach dem 2ten roboot). Vermutlich doch ein cache-Problem von Openhab. Sorry wenn ich Dir da Stress bereitet habe. viele Grüsse Stefan
×
×
  • Create New...