StefanOHAN

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

Hallo Erik, ich werde heute Abend das Spezial-Test-Binding einspielen und gleich noch das Astro-Binding aktivieren. viele Grüsse Stefan

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.tinkerforge org.openhab.binding.exec org.openhab.core.binding.xml es war noch das Binding für den LogReader installiert, hierfür habe ich aber den Trace nicht aktiviert. Um 23 Uhr erfolgte dann der restart des System. Sobald der Fehler wieder auftaucht, werde ich nochmal das Ergebnis des shell:thread und den Auszug der Logfile's senden. Bis jetzt sind noch immer keine Rules aktiv. Eine andere Frage: Ich hab noch einen PI2 rum liegen und hab mir überlegt dort auch Openhab für ein minimalisiertes Notfallsystem zu installieren. Wenn ich auf diesem Pi den TF Dämon installiere und remote auf die TF Komponenten zugreife die an einem anderen Pi aktiviert sind auf dem ebenfalls Openhab läuft, sollte es doch kein Problem sein die Sensor / channel-trigger Daten zu überwachen. Also nicht über den zweiten Pi aktiv Aktionen auf den TF Komponenten shellthreads-von-20200825-2236.txtausführen sondern nur "lauschen" oder ? viele Grüsse Stefan

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 verhindern, dass durch das erhöhte Log Aufkommen nicht die SD-CARD Probleme verursacht). Kannst Du bitte mal Deinen Kollegen Fragen (der mit der PI / Astro / LAN-Masterbrick) arbeitet, welche OS-Version und Openhab-Version einsetzt ? Danke im Voraus viele Grüsse Stefan

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 Problem des ASTRO und EXEC-Binding (NTP Bindings war zu diesem Zeitpunkt nicht installiert), alle 6-8 Stunden auf. Der Fehler tritt bei mir auf, wenn nach einigen Stunden Betrieb das TF-Binding versucht den Masterbrick, der über WIFI angeschlossen ist, wieder online zu nehmen (also wenn die AVM mal wieder eine Kanal-Optimierung durchführt), ob das die Ursache ist weiß ich aber nicht. Aktuell sind keine Rule's aktiv, es wird nur über das Astro-Binding der Sonnen-Winkel ermittelt, und über das EXEC-Binding wird die PI-Temperatur alle 60 Sec abgefragt. Konfiguriert sind nur die 4 Bricklet die über das WIFI/Masterbrick und die 8 Bicklets die über das HAT-Brick angebunden sind, keine Bricklets/Masterbrick die über USB angeschlossen sind, sind konfiguriert. Die ersten Stunden nach einem Neustart gibt es keine Probleme auch wenn der WIFI/Masterbrick off/online geht. Ein Temperatur Problem des PI kann es nicht sein, der Pi3 hat einen Kühlkörper und einen aktiven Lüfter (per Exec überprüfte CPU-Temperatur ca 36Grad) Ich konnte den Fehler jetzt soweit eingrenzen, dass anscheinend innerhalb von Openhab die interne zeitliche Steuerung, die in wiederkehrenden Intervallen, Aktionen in Bindings steuert, nicht mehr funktioniert. Alle drei betroffen Binding‘s (ASTRO/NTP/EXEC) führen in definierten Zeitintervallen Aktivitäten aus. Es hilft nur ein Restart von Openhab. Im Log sind keine Fehlermeldungen außer dem des TF-Binding zu lesen. Irgendwie scheinen sich die verschieden Bindings gegenseitig zu beeinflussen Hast Du einen IDEE was die Ursache sein könnte, oder welches Modul in Openhab diese Zeitintervalle steuert ? Welche Linux Konfiguration nutzt Du (Pi mit HAT-Brick?), hast Du neben den TF-Binding noch andere Binding's aktiviert ? Hast Du auch Systeme die über einen längern Zeitraum laufen ? Ich werde jetzt mal das ASTRO-Binding deaktivieren, mal schaun was passiert. Eines ist mir noch aufgefallen: Bei Konfiguration nach der Neuinstallation ist mir ist aufgefallen, dass die beiden Taster des Dualbutton-Bricklet (V2) sich nicht wie Taster sondern wie Schalter verhalten. Also wenn man den Taster (rechts oder links) 1x betätigt dann bekommt man im Log die Meldung „right_button predicted to become ON“ wenn man den Taster ein zweites mal betätigt bekommt man die Meldung „right_button predicted to become OFF“ Ich bin mir nicht mehr sicher ob dies nun so gewollt war oder nicht ? viele Grüsse Stefan

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-GPU/CPU-Temperatur ca 33 Grad (mit aktiven Lüfter auf den Gehäuse) Damit der Pi4 auch unter Last bei diesen Temperaturen einen kühlen "Kopf" bewahren kann, werde ich beim Umstellung auf den PI4, eine temperaturabhängige Lüftersteuerung für den Kühlkörper vorsehen. viele Grüsse Stefan

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 Stefan

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 angeschossen) Somit dürfte die Versorgung des des Pi4-8GBHS über das HAT-Brick kein Problem sein. Thema Kühlung: Seit ein paar Wochen hat mein PI3 & HAT-Brick Testsystem einen Kühlkörper vom Typ „Armor-Case-BLOCK-für-Raspberry-Pi3B-Kühlkörper“ (analog wie einer für den Pi4 Eures Partner Rasppishop vertrieben wird). Um das Hat-Brick noch aufstecken zu können und genügend Abstand zwischen Kühlkörper und HAT-Brick zu haben, habe ich einen "40 poliger GPIO Steckverbinder, durchsteck- und stapelbar" im Einsatz. (so ein 40 polige GPIO Steckverbinder wäre eventuell was als addon für Euren Shop) Ich musste allerdings etwas kreativ werden um einen festen Sitz des HAT-Brick sicher stellen zu können. Dieser Aufbau läuft seit gut 6 Wochen ohne Störung und ermöglicht es mir bei Bedarf auch einen Lüfter einzusetzen. Dieser Aufbau sollte mögliche TemperaturProbleme eines PI4-8GB lösen, vor allem da ich auf dem PI nur Openhab laufen lasse und als OS das optimierte Openhabian zum Einsatz kommt Grüße Stefan

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 Leitfaden erstellen ? Die Konfiguration über eine Thing-Datei würde ein "Neu-Aufsetzten" des System (wenn ein Recovery nicht möglich ist) vereinfachen. 3) Es gehört jetzt nicht unbedingt hier zu diesem Themenblock. Aktuell gibt es einen neuen Raspi 4 mit 8 GB HS, dieser hat einen etwas höheren Leistungsbedarf als der Raspi 4 mit 4 GB HS. Frage: Ist Dir bekannt, ob es zu Problemen kommen kann, wenn die Spannungsversorgung des neuen Pi-4 mit 8GB-HS über das HAT-Brick erfolgt ? Bei Euch in der Beschreibung des HAT-Brick finde ich nur die Aussage Ich vermute es sollte kein Problem sein, oder ? (ich habe an den USB-Ports nur 5 Masterbricks mit diversen TF Bicklets angeschlossen) viele Grüsse Stefan

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