Jump to content

StefanOHAN

Members
  • Posts

    173
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by StefanOHAN

  1. Hallo Eric, kürzlich habe ich für das LCD 128x64 die neue Firmware eingespielt (2.0.10) leider ist das Problem mit dem Tab noch immer nicht behoben. Nach einer gewissen Zeit reagieren diese nicht mehr und nur ein Reset über den Brick Viewer schafft Abhilfe Meine Bitte wäre, wenn Du wieder Zeit hast am Binding zu arbeiten, eine Art "Rest-Funktion" mit einzubauen. Dies sollte doch möglich sein oder ? Über den Brick Viewer kann man ja einen Rest für das Bricklet ausführen. Viele Grüße Stefan
  2. Hallo Eric, kein Problem, das ist jetzt nicht so dringend. Wenn es geht wären Beispiele für folgende Bricklets optimal - IO 16, als Input & Output - LCD 20x4 incl Button - Industrial Quadrelais - Temperatur - Humidity den Rest versuche ich mir daraus abzuleiten. Aber was anderes, ich hab noch immer das sporadisch auftretende Problem mit den Tabs des LCD128x64. Per Rule kann ich das Thing off und online zu setzten, das ändert aber nicht am Problem, meine Hoffnung war dass dies wie ein Reset wirkt. Gleichzeitig lass ich mir per lcdActions128x64.brickletLCD128x64GetSPITFPErrorCount() die Errors anzeigen, bis jetzt kam immer 0,0,0,0. Einzig ein Reset über den BrickViewer hilft. Frage: Wie kann ich den Reset auslösen ohne den Brickviewer nutzen zu müssen (per Befehl oder Openhab) ? Viele Grüße Stefan
  3. Hallo Eric, Ich würde gerne einmal ein System mit einer tinkerforge.cfg testen und die Autoerkennung nicht nutzen. Du hast ja bereits geschrieben, dass bei Dir die Things dann immer doppelt angezeigt wurden, das stört mich aber momentan nicht. Kannst Du mir bitte bei Gelegenheit ein Muster, wie diese Datei für ein IO-16 / LCD Display aussehen müsste, zukommen lassen ? Danke im Voraus viele Grüße Stefan
  4. Hallo Eric, danke für die schnelle Antwort. viele Grüsse
  5. Hallo Eric, ich wollte nur am Fragen ab wann Du wieder Zeit hast das OH2 Binding zu finalisieren und dann das ganze Binding OH3 tauglich umzustellen ? viele Grüße Stefan
  6. 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 jetzt nicht aufgepasst ob sich optisch was ändert, der Button hat auf jedem Fall die passende Rule an getriggert. Viele Grüße Stefan
  7. 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. Folgendes ist aktuell auf dem OpenHAB-System (PI3) konfiguriert: openHAB 2.5.8-1 (Release Build) 3 x OpenHAB-Tinkerforge-Dämon (Spezial-Version 23b) >> Ja es sind 3 Dämon konfiguriert Linux armhf Tinkerforge Brick-Dämon 2.4.1 (19.12.2019) Kernel = Linux 5.4.51-v7+ Der aktuelle Testaufbau sieht wie folgt aus: PI3 mit Zero-Head-Brick, hier läuft das Openhab-System PI2 mit Head-Brick sowie ein Stapel von 3xMasterbrick und 2xRS485-Extemtion die per USB angeschlossene sind. Auf dem PI2 läuft nur Linux und der Linux-Tinkerforge-Dämon, kein Openhab Masterbrick per WIFI Extention angebunden Du schreibst: Frage: Kann es sein, dass man das LCD-Thing nicht im Log sieht, da es am PI2 über ein HeadBrick angeschlossen ist (und nicht am "OpenHAB"-Pi3), und dieser PI2 über das Netzwerk mit dem zugehörigen BrickDämon auf dem "OpenhHab"-PI3 kommuniziert ? An dem PI3 (auf dem das OpenHab-System läuft) ist aktuell nur ein Zero-Brick-Head aufgesteckt an dem ein Clock-Bricklet angeschlossen ist, mehr nicht. Ich füge eine Zeichnung der Konfiguration bei, ich hoffe dass es dadurch etwas übersichtlicher wird. (siehe PDF, hier sind auch Details zu den TF-Brick-Dämon Versionen und den konfigurierten Bricklets enthalten.) Aktuell bin ich mir jetzt nicht sicher, es kann aber durchaus sein, dass die Probleme mit den LCD-Tabs erst aufgetreten sind, nachdem ich im letzten Jahr die Konfiguration auf die 2 verschiedene PI3 / PI2 aufgesplittet habe. Heute habe ich auf dem PI3 und dem PI2 einen Update des Linux-armhf-Brick-Dämon auf die neueste Version 2.4.3 ausgeführt und anschließend beide neue gebootet. Für das Linux und Openhab-System habe ich keinen Update ausgeführt. Frage: Nachdem das LCD nicht an dem PI3 mit der OpenHab-Installation angeschlossen ist, gibt es andere Log-Quellen des PI2 die Dir helfen könnten ? Hinweis: In diesem etwas kleinteiligen OpenHab Aufbau (PI3 + PI2 + WIFI-Extention) versuche ich die möglichen Grenzen auszutesten. Wenn ich mein Prod-System umstelle, wird das System wieder einfacher aufgebaut sein (die WIFI-Extention wird keine Verwendung finden, ggf. werden auch wieder alle Bricklets an dem OpenHab-Pi angeschlossen da ein P4 dafür vorgsehen ist. Beibehalten werde ich aber die RS485 Extention). viele GrüßSkizze-konfig-202101.pdfe Stefan
  8. 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 Display. Ich füge mal die Thread aus der Console an. Nachdem ich über den BrickViewer einen Reset für das LCD-Bricklet ausführte, funktionierten die Tabs wieder. Viele Grüße Stefan P.S. ich arbeite noch immer mit Deinem Spezial-Binding 202102210-21Uhr.txt
  9. 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
  10. 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 erst Gestern. Aktuell läuft die Konfiguration mit 3 Dämons 1 x WIFI (Masterbrick mit WIFI Extension) 1 x Remote für Pi2 mit BrickHat & USB angebunden Masterbricks (auf dem Pi2 läuft nur der BrickDämon kein OpenHab) 1 x auf dem Openhab Pi (4) mit ZeroHat Wenn ich mir das Ergebnis des trace aus der Konsole anschaue, sehe ich dass auf jedem Fall sehr viele Prozesse vorhanden waren. (siehe begefügten trace)Thread-openhab-20210107.txt Nach dem Reboot des Openhab-System funktionierte wieder alles. Viele Grüße Stefan
  11. 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 gesundes neues Jahr Stefan
  12. 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" bei vielen Bricklets "Current firmware version: 2.0.3 Unknown" angezeigt. z.B. Tinkerforge Industrial Quad Relay Bricklet 2.0 Tinkerforge Outdoor Weather Bricklet Tinkerforge Remote Switch Bricklet 2.0 Tinkerforge Real-Time Clock Bricklet 2.0 Tinkerforge LCD 128x64 Bricklet Das ist nicht für alle Bricklets der Fall, aber für die meisten. (Tinkerforge Humidity Bricklet 2.0 meldet >> Current firmware version: 2.0.6 Up to date " Mal von den Rules für die LCD-Tab's abgesehen, funktioniert aber soweit alles. Sind Dir diese beiden Effekte schon mal aufgefallen ? viele Grüße Stefan
  13. 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 Vielfalt :-) viele Grüße Stefan
  14. 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 "verdrahtet", oder ? Hast Du schon eine Idee wie Du mit der neuen ID des Sensor beim Tausch der Batterie umgehen willst ? viele Grüsse Stefan
  15. 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
  16. 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 aber auch keine Fehlermeldungen im Log zu sehen. Das Thing "Tinkerforge Remote Switch Bricklet 2.0" war online. Alles andere funktionierte (IO / Sensoren / Piezo .... / LCD 128x64 / .. ) soweit ich es sehen konnte Als ich dann über den Brickviewer das Bricklet zurück setzte, funktionierte alles wieder und die Steckdose schaltete sich mehrfach ein und aus, als ob alle "aufgestauten" KDO für die Steckdose von Bricklet abgearbeitet wurden. Nach dem Reset sah ich im Log auch wieder Meldungen wenn ich die Fernbedienung betätigte. Frage kann es sein dass sich hier das Bricklet selber aufgehängt hat ? viele Grüsse Stefan
  17. 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. Baust Du diese Korrektur noch in das 2.5 Binding ein (oder erst in die 3) ? Planst Du auch noch das Thema der IO-Brickets die als Input konfiguriert sind wieder als "Contact" und nicht mehr als Switch in das 2.5-Binding einzubauen bevor Du dann nach 3.x umstellst ? Es wäre gut wenn beides noch im 2.5-Beta integriert wird. viele Grüsse Stefan
  18. 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 nicht sicher ob das mit dem Binding zu tun hat, das mir Erik zum testen gab als ich Probleme in meiner Konfig hatte. Hast Du schon mal versucht den cache über die Konsole zu löschen, dann dauert zwar das nächste laden etwas länger aber das hat bei mir oft wunder bewirkt. viele Grüsse Stefan
  19. 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 ist der brickd Dämon und Openhab installiert → openhab/Things hat 1x Brickdämon lokal (des Pi3 für HAT-Zero), 1xBrickdämon remote (Pi2 mit HAT-Brick), 1xBrickdämon für WIFI-Extention. WIFI-Extention mit 1xMasterBrick → die Konfiguration hat sich hier nicht verändert (das WIFI wird später kein Bestandteil des Prod-System sein) Soweit läuft das System, jedoch hab ich zur RealtimeClock eine Frage. Ich hab Zeit & Datum über den BrickViewer eingestellt. Wenn ich jedoch über Openhab das ITEM für Zeit/Datum anschaue, sehe ich dass dort +2 Stunden zu der Zeit die ich eingestellt habe angezeigt werden. Auf dem Pi-OS (openhabian) ist der NTP-Zeitservice deaktiviert. Der Pi hat unter System-timezone > Europa/Berlin eingestellt. (hat auch den gleichen Effekt wenn der NTP-Zeitservice dort aktiv ist) In Openhab ist der NTP-Zeitservice aktiv, weiter ist dort Timezone=Europa/Berlin (GTM+1) konfiguriert. Die Zeiten des OpenHab NTP sowie die per Exec abgefragte Zeit des Pi, weisen ein Delta von 2 Stunden zu dem der Realtime-Clock auf. Woher kann diese Delta von 2 Stunden kommen ? Was und wo müsste ich in der Config noch ändern ? viele Grüsse Stefan P.S mit Deinem Spezial-Binding ist bis jetzt der Fehler mit dem hängenden Astro & NTP Binding nicht mehr aufgetreten.
  20. 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 ich noch testen) Ich könnte mir aber auch vorstellen dass ich HAT&USB MasterBrick über den PI2 anbinde und den WIFI in der Konfig lassen. Dann hätte ich zwei Dämons die über das Netz-Angebunden sind. Was meist Du was für das Test-System besser ist (es sollen ja passenden Test-Rückmeldungen für Dich erzeugt werden) ? Grüsse Stefan
  21. 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
  22. 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 "paperui/index.html#/configuration/things" wieder online, die Rules der betroffen Bricklets funktionieren wieder ,keine weiteren Fehlermeldungen im Log Das System läuft weiterhin ohne Ausfall des Astro/Ntp/Exec Binding Viele Grüsse Stefan Nr1-20200831-shell_threads-vor-ausfall.txt Nr2-20200831-shell_threads-connection_lost-1.txt Nr3-20200831-shell_threads-connection_lost-2.txt Nr4-20200831-shell_threads-reconnect.txt
  23. 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
  24. 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
  25. 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 oder nicht. Zu meiner Frage Pi2 und Abfrage FT Koponenten die über einen anderen PI in Openhab eingebunden ist. Nachdem ich feststellen muss, dass der P4 doch relativ warm wird (mit montierten Kühlkörper) werde ich beim Umbau die Konfiguration entzerren. Das HAT-Brick kommt auf dem PI2, dort wird nur ein minimalisiertes Raspian und der FT-Treiber laufen. Auf dem PI4 wird dann openhab installiert. Der Zugriff auf das HAT erfolgt remote, die anderen MasterBrick werden wie bisher per USB am Pi4 mit der Openhab Installation angeschlossen. Das werde ich aber erst mal bei Gelegenheit testen. noch mal Danke für deine schnelle Reaktion viele Grüsse Stefan
×
×
  • Create New...