Jump to content

StefanOHAN

Members
  • Content Count

    156
  • Joined

  • Last visited

  • Days Won

    4

StefanOHAN last won the day on May 13

StefanOHAN had the most liked content!

Community Reputation

6 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. Hallo Erik, ich werde heute Abend das Spezial-Test-Binding einspielen und gleich noch das Astro-Binding aktivieren. viele Grüsse Stefan
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • Create New...