Jump to content

StefanOHAN

Members
  • Content Count

    168
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by StefanOHAN

  1. Hallo Eric, es war etwas unglücklich von mir formuliert, ich meinte dass sich beim berühren eines Tab die Ihm umranden Linie nach oben nicht „öffnet“ (und im Log keine Meldung erscheint, welcher Tab berührt wurde). Somit wird mit Deinen Worten die Tab-Leiste "nicht" korrekt gezeichnet, oder ? Ansonsten reagiert das Display wie erwartet, die Rules scheiben Zeichen in verschiedener Größe ... usw. Der Slider reagiert in der Form, dass der "Schieber" des Slider mit der Fingerbewegung sich an die Stelle bewegt auf dem der Finger ihn hin schiebt. Beim Betätigen des Button hab ich
  2. Hallo Eric, zu Deinen Fragen: Ja die Button und Slider sind mit Rule verknüpft und diese funktionieren auch. Neben den 3xTab sind auf dem „Startbildschirm“ des LCD128x64 2xButton konfiguriert. Der eine Button ruft eine Rule zum Neuaufbau des LCD-Screen auf. Dieser wird dadurch komplett gelöscht und anschließend 2xSlider konfiguriert (dies funktioniert). Die beiden Slider zeigen Ihre Rückgabewerte auf dem LCD128x64 an. Wenn die Slider von rechts nach links bewegt werden, werden die entsprechend geänderten Rückgabe-Werte am Display angezeigt. Einzig die Tabs reagieren nicht. Folge
  3. Hallo Eric, heute (09.02.2021) hatte ich wieder den Effekt, dass am LCD128x64 die Tab‘s nicht mehr auf Berührung reagierten. Egal welchen TAB ich berührte (es sind 3 Stück konfiguriert), es änderte sich nichts an der Darstellung auf dem Display. Beim berühren werden mit im Log die Koordinaten angezeigt aber nicht ob ein Tab berührt wurde. Die Buttons und die Slider funktionieren noch. Auch das Löschen des Display‘s per Rule funktioniert. Wie es scheint funktionieren alle anderen Rules / Bricklets. In den Log's sehe ich keine Fehlermeldung bezüglich des Disp
  4. Hallo Erik, ja es ist noch Deine Spezial Version. Seit ich von Dir diese Version bekommen habe, habe ich das System nicht neu konfiguriert / installiert. Bisher hatte ich nur den reconnect des WIFI Dämons (hier hatte ich mit Deiner Spezial-Version keine Probleme), in der letzten Woche war aber mal das komplette Netzwerk für ein paar Stunden nicht verfügbar, da ich meine Verkabelung vom Router zu den Switchen auf LWL umgestellt habe. Das ist der einzige Unterschied der ich zur damaligen Situation hatte. viele Grüße Stefan
  5. Hallo Erik gestern hatte ich wieder den Fehler, dass mein Astro & NTP Binding den Dienst eingestellt hat. Die letzte Meldung in Log war ein Reconnect des WIFI Dämon. Mit Deinem Spezial Binding ist die Konfiguration jetzt einige Monate ohne Fehler gelaufen. Ich weiß nicht ob es damit zusammen hängen kann, in der Woche nach Neujahr habe ich mein internes Netzwerk umgebaut und das Openhab-System war einigen Stunden ohne funktionierendes Netzwerk. Somit war für das Openhab die Brick des WIFI-Dämon und die Bricks des PI2/Hat Dämons nicht erreichbar . Der Ausfall war aber ers
  6. Hallo Erik meinst Du mit dass sich beim berühren eines Tab die Ihm umranden Linie nach oben „öffnet“ ? Darauf habe ich nicht geachtet. Ich kann nur sagen, dass die auf dem Display dargestellten Buttons funktionierten und „Ihre“ Rule aktivierten. Die Rule für den Button löscht per Actions den gesamten Inhalt des Display incl aller Tab/Button und stellt 2 Slider dar. Die Actions scheinen also nicht betroffen zu sein. Ich werde mal aufpassen wie sich die Tab‘s verhalten wenn der Fehler wieder auftritt. Viele Grüße ein frohes Fest und ein ge
  7. Hallo Erik, Mein Test-System läuft seit einigen Monaten ohne Störung. Gestern ist mir jedoch aufgefallen, dass bei berühren eines der 3 im LCD 128x64 konfigurierten Tab, das Item für selected Tab nicht mehr reagiert. Die button's reagieren, auch bekomme ich einen Rückmeldung der Berührungs-Koordinaten. Nach einem Reset über den BrickViewer funktionierte wieder alles. Leider konnte ich keine Fehlermeldung im Log finden. Diesen Effekt hatte ich schon vor einigen Monaten, dachte aber es lag an der alten Firmware des LCD. Weiter werden mir über "configuration/Thing" b
  8. Hallo sihui danke für den Link der Dezember Video Präsentation der neuen Openhab3 Version. Ich habe mir das Video angesehen und es unumstritten dass die neue MainUI sehr viele Möglichkeiten bietet, die das Leben in Openhab erleichtern wird. Ich werde auf jedem Fall die neue MainUI testen, kann durchaus sein, dass ich dann auf Text-Config-File verzichten werde. Ein NOGO für mich wäre, wenn ich keine Rule als Text-File anlegen könnte, denn das wäre für mich ein absoluter Kontrollverlust. So wie ich das verstanden ist dies aber in Openhab3 weiterhin möglich. Es lebe die V
  9. Hallo Sebastian (skober19) bis jetzt habe ich nur in meiner Openhab 1.9 Prod Umgebung die Things über Conf-Dateien angelegt. In meiner Openhab 2.x Testumgebung sind Items / Sitemap und rules über Konfig-Dateien angelegt, jedoch noch nicht die Thinkerforge-Things. Wenn ich mein Prod-System umstelle, würde ich auch soweit als möglich auf Config-Dateien zurückgreifen und die GUI nur dann nutzen wenn es nicht anders geht. Frage: Was hast du außer dem Outdoor Weather Bricklet über die Thing Config Datei schon angelegt ? Deine Sensor-ID ist aktuell fest in der Config Datei "v
  10. Hallo Skober19 Frage: Erscheint nach betätigen des + beim TF Binding Wenn ja : solltest Du über "Manually add Thing" eine Liste der TF Thing öffnen können und darüber den Brick-Dämon hinzufügen. viele Grüsse Stefan
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. Hallo Erik, ich werde heute Abend das Spezial-Test-Binding einspielen und gleich noch das Astro-Binding aktivieren. viele Grüsse Stefan
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Create New...