Jump to content

StefanOHAN

Members
  • Content Count

    142
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by StefanOHAN

  1. 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
  2. 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
  3. 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
  4. 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-Rechte hatte fehlten Zugriffsrechte auf die Sound-Datei. Viele Grüsse Stefan
  5. 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 damit in Openhab2. In meiner alten Openhab 1.9 Konfiguration führe ich damit einen Reboot/Shutdown aus. So sieht mein Shutdown aus Die @ Zeichen anstelle der Leerzeichen waren bei mir notwendig, da ansonsten der Befehl nicht sauber ausgeführt wurde. Hierzu gibt es auch Hinweise in der Dokumentation. Dein User hat ja schon sudo Rechte, also sollte es funktionieren. Ich hatte damals Probleme zu erkennen dass die Berechtigungen / Zugriffsrechte für den User nicht korrekt waren, da die Zugriffsberechtigung's Fehler nicht im Openhab-Log erschienen und mein Prod-OpenHab-Service einen anderen User verwendete als der User den ich nutzte wenn ich das "Test"-System über die Kommandozeile startete (also nicht als Service). Viele Grüße Stefan
  6. 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. Die Datei findest Du unter "openhab2-conf/misc/exec.whitelist" viele Grüsse Stefan
  7. 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
  8. Hallo Tamino, schön zu sehen dass hier weitere "Franken" im Forum aktiv sind 🙂 grüsse aus Ansbach Stefan
  9. 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
  10. Hallo Erik nein, ich habe natürlich vor dem Umbau für das komplette System einen shutdown gefahren und Stromlos geschaltet (für beide Stapel, also den WIFI und Raspi mit HAT-Brick). Ein Item für den Draw-Status hatte ich schon angelegt, war also vorhanden. Nach dem physikalischen Umbau (im stromlosen Zustand) und dem Reboot, führte ich über PaperUi den ich Switch vom Stapel WIFI zum Stapel HAT-Brick aus. Nach dem "switch" wurde das Bricklet auch als online angezeigt. Nur die Rule funktionierte nicht. Erst nach dem entfernen und wieder hinzufügen des Bricklet funktioniert die Rule wieder, daher auch meine Vermutung dass Openhab hier irgendwo noch etwas im cache hatte. Ich werde heute Abend einfach mal 3-4 mal einen shutdown laufen lassen, und schaun was passiert. Welche openhab Version nutzt Du ? ich die aktuell freigegebene. Grüsse Stefan
  11. Hallo Erik, ich habe jetzt mit dem Beta 22 die Mini-Konfiguration ca 1 Woche laufen lasse, der Fehler dass NTP & ASTRO Binding ausgestiegen, ist nicht mehr aufgetreten. Allerdings hatte ich einen anderen Effekt. Nachdem ich jetzt für das neue Bedienfeld die Acryl-Zuschnitte (dank Tim) habe, habe ich das e-Paper Bricklet vom Dämon der über WIFI angebunden ist, auf den Dämon gewechselt der für das HAT-Brick zuständig ist. Der Wechsel über paperUi/Things/view ging wie immer problemlos und das Brickelt wechselte wieder auf Online. Probleme gab es aber mit der Rule die für das Bricklet zuständig ist. Um Fehler zu vermeiden, habe ich erst über die Konsole den cache geleert >>openhab-cli stop >>openhab-cli clean-cache >>openhab-cli start Dies behob den Fehler nicht. Anschließend entfernte ich das E-Paper Bricklet aus der Konfiguration und deinstallierte über die Konsole beide Tinkerforge Bindings. Nach dem Hochlaufen wurden nicht alle Bricklets automatisch erkannt (auch das e-Pater nicht). Nach dem ich über PaperUi / Inbox eine manuelle Suche startete, war das e-Paper wieder verfügbar. Nach hinzufügen zur Konfiguration funktionierte die Rule wieder ohne Fehlermeldung. Um sicherzugehen, dass der Fehler behoben ist, habe ich das System mit Init 6 noch einmal komplett neu gestartet, und der Fehler war wieder da. Nach dem Reboot habe ich überprüft ob sich die Zuordnung zum Dämon geändert hat, dies war nicht der Fall (das Bricklet war weiterhin dem Dämon des HAT-Brick zugeordnet und online). Ich musste das E-Paper wieder aus der Konfiguration entfernen, eine manuelle Suche nach neuen Bricklet starten und anschließend das Bricklet wieder zur Konfiguration hinzufügen. Danach arbeitet die Rule wieder fehlerlos. Folgende Befehle rufe ich in der Rule auf (an der Rule kann es nicht liegen). Das ist ein etwas eigenartiger Fehler, oder ? Ich hab so den Eindruck, dass in irgend einem cache noch Werte liegen. Hast Du eine IDEE was ich noch versuchen könnte ? Ich hab anschließend wieder alle meine „anderen Test“ Rule‘s aktiviert, es scheint alles zu funktionieren. Grüße Stefan P.S. Konntest Du schon mal testen wie die Konfiguration der Things über eine „Textdatei“ aussehen müssten ?
  12. Hallo Erik, das ist ein guter Vorschlag. Bis jetzt (also seit Freitag Abend) läuft alles NTP & ASTRO & Tinkerforge Binding Grüsse Stefan
  13. Guten Morgen Erik, kurzer Update. Das Beta 22 Binding läuft bis soweit ohne Fehlermeldung im Log. Einmal gab es (1,5 Tage nach dem Restart von Openhab mit dem Beta 22, am Freitag 1.5 abends) ein Problem mit dem NTP und dem Astro Binding ( wie gesagt ich hatte bisher mit diesen nie Probleme). Das NTP-Binding und das Astro-Binding funktionierten einfach nicht mehr (kein Update), aber auch kein Fehler im Log. Nach einem Openhab-Restart funktionierte alles wieder. Dein Tinkerforge-Binding reagierte aber noch (ich konnte über paper UI / Control die LED-Channel des Dualbutton ein und ausschalten). Um mehr Informationen zu erhalten, habe ich Openhab im Debugger-Modus gestartet, das Tinkerforge-Binding Logging (trace) wieder aktiviert, den NTP-Zeitserver auf den AVM-Router umgestellt sowie das Outdoor-Weather-Bricklet mit dem TH Sensor und den Piezo-Speaker wieder in die Mini-Konfiguration aufgenommen um im Log mehr Meldungen zu sehen (mit Zeitstempel ...). Bis jetzt läuft alles ohne Störung, ich kann mir momentan das Aussteigen des NTP/Astro-Binding nicht erklären. Grüsse Stefan
  14. Hallo Erik ich habe gestern Abend eine Mini-Rule erstellt, die nur auf Thing-Status Änderungen der MasterBricks des HatBrick und der beiden Brick-Dämons reagiert. In dieser Rule werden u.A. auch die LED-Channel des DualButten angesprochen, hat auch alles funktioniert. (4xMasterBrick , 1xHatBrick, 2xBrickDämon) In der Konfiguration waren nur wenige Bricklets (IO-16 / IO-16 V2 / IO-4 V2 / Piezospeaker / e-Paper / Dualbutton) eingebunden (wollte den Log übersichtlich halten). Die Nacht über konnte ich keine „unerklärlichen“ timeout von MasterBricks / Brickles im Log erkennen. Nur das bekannte Timeout wenn die Wifi-Verbindung vom Router optimiert wurde (es ging aber alles wieder online). Um zu prüfen ob das Astro-Binding noch funktioniert, habe ich eine Rule aktiviert, die reagiert wenn sich der Sonnenwinkel ändert und prüft ob er kleiner 4 oder größer 4 Grad ist. Das hat auch alles geklappt, die Rule arbeitet abhängig vom Sonnenwinkel korrekt. In dieser Rule wird auch ein als Output konfigurierter Port des IO-4 V2 und ein als Input konfigurierter Port des IO-16 V1 angesprochen. Beide Ports haben wie erwartet reagiert. Es gibt einen Punkt der mir früher schon aufgefallen ist, hat aber vermutlich nichts mit Deinem Binding zu tun. Die Offline-Meldung eines Thing (egal ob nun BrickDämon, MasterBrick, PiezoSpeaker …) wird immer in das „events.log“ geschrieben. Wenn ein MasterBrick(Thing) wieder online geht wird dies in das "openhab.log" geschrieben und wenn ein Bricklet (Thing) z.B PiezoSpeaker online geht in das „events.log“ geschrieben. Das ist nicht dramatisch, verwirrt etwas wenn man die Log‘s nach Ausfällen durchsucht. Ich werde die nächsten Tag mit dieser Mini-Konfig das ganze weiter beobachten Viele Grüße Stefan
  15. Hallo Erik, habe schnell das Beta-20 deinstalliert und beide File für Beta-22 in das addon-Verzeichnis kopiert. Nach dem Restart konnte ich wieder für das IO16 V1 / IO-16 V2 / IO-4 V2 die Ports auf Output umstellen (ohne Fehlermeldung ) Auch für den Dualbutton konnte ich die LED-Channel auf on setzten und die LED einzeln schalten (ohne Fehlermeldung) Über eine Verlinkung der Channel mit dem passenden Items konnte ich die output-Port der IO's-Briklets und die LED des Dualbutton über paper-ui / Control bedienen (über Rule & Taster kann ich erst heute Abend testen) Zwei Punkte sind mir aufgefallen, auf die ich in der Vergangenheit aber nicht geachtet habe. 1) für das IO-16 V2 und das IO-4 V2 kann ich über deren Thing-Menu Configure-Channel für die INPUT Ports den Update Intervall verändern (die Standard Werte von 1000ms sind etwas lang). Für das IO-16 V1 (also alte Bauart mit 10pol Anschluss) geht das nicht, genauer ich finde da pro Port das "Stift-Symbol" nicht. Frage ist das Absicht ? Hier müsste man auch den Update-Intervall anpassen können. 2) Wenn man über paperui / Control die als Input konfigurierten Ports des IO-16 V2 und IO-4 V2 "fälschlicher" weise betätigt, schaltet sich automatisch das "Switch"-Symbol wieder auf seine Ursprungs-Postionen zurück (Warn-Meldung im Log, korrekt ), dies erwartet man ja. Wenn ich dies hingegen beim IO-16 V1 und dem Dualbutton im Controll-Menü ausführe bleibt das "Switch"-Symbol in der Stellung auf die man es geschoben hat (hier erscheint auch die korrekte Warn-Meldung im Log), erwarten würde ich jedoch das gleiche Verhalten wie für das IO-16 V2. Woran liegt dies ? Test mit Rule und angeschlossenen Taster an einem Input-Port, kann ich erst heute Abend ausführen) Beide Effekte sind auch nach einem Reboot noch vorhanden. viele Grüsse Stefan
  16. Hallo Erik, Du schreibt's Wie gesagt ich hatte aber auch mit dem Beta-21 die Situation dass Bricklets in der Konfiguration nach einer gewissen Zeit als offline angezeigt wurden obwohl sie über den Brickviewer erreichbar waren. Es war aber nicht das Problem das durch das WLAN-Optimierungs-Verhalten der AVM entstanden ist, denn es waren auch Masterbricks /Bricklets betroffen die über USB angebunden sind. Wie siehst Du den Effekt den ich bei der alt-Installation mit der Beta-21 hatte, dass das Astro Binding (ist openhab 2 tauglich) einfach nicht mehr automatisch den Sonnenwinkel update ausführte (funktionierte bis Beta20 da ich bei negativen Sonnenwinkel = Nacht, eine LED einschaltetet ) ? Kann es eine Folge davon sein, dass ich das System seit ca 10-15 Beta-Bindings nicht mehr neu installierte sondern nur die neuen Beta-Bindings einspielte (maximal die Things entfernte und neu hinzufügte) ? viele Grüsse Stefan
  17. Hallo Erik nein keine Angst, es hat mein Entwicklungs -/Test System erwischt. Ich hab heute Abend meinen Pi Komplett neu aufgesetzt Inklusive erzeugen einer SD-Card und update von Openhab2 auf das aktuelle Release. Leider ist das Fehlerbild noch immer vorhanden. Ich konnte nach der Neuinstallation die Ports der IO-16/4 nicht nach Output umstellen, im Edit-Menü wurde es zwar angezeigt, aber nicht im Thing Menü. Hierzu habe ich eine schöne Fehlermeldung für das IO-16, diese hänge ich als Datei an. Auch die LED-Channel des Dual-Button konnte ich nicht auf ON konfigurieren. Anschließend wurde es aber echt wüst, auf einmal wurde der Masterbrick der über die WIFI-Extention angebunden war, laut Log aus der Konfiguration entfernt. Mir ist in der alten Konfiguration zwar aufgefallen dass dort die Anzahl der Elemente in der Inbox sich veränderten, aber auf die Schnelle konnte ich damals im Log nichts erkennen. Jetzt mit den wenigen Komponenten konnte ich diese Meldung im Log sehen. Nach einer gewissen Zeit erscheinen dann wieder alle Tinkerforge-Elemente in der Inbox. Ich hatte bei der alten Installation den Eindruck, dass dies immer passierte wenn der „background-Discovery-Intervall“ aktiv war, dachte mir aber nichts dabei, da ich vermutete das System sei zerschossen. Ich prüfte anschließend ob es mit der Beta20 wieder funktionierte: beide jar-File für das Beta21-Binding über die Console entfernt, das Beta20 Binding wieder ins addon Verzeichnis kopiert und openhab neu gestartet. Ergebnis: Mit der Beta20 konnte ich dann wieder die IO-Ports und die LED-Channel des Dualbutton konfigurieren. Vorerst habe ich keine ITEM Channel Verlinkung ausgeführt. Ob es bei den anderen Brickelt auch im Edit-Menü Probleme gibt hab ich bis jetzt noch nicht getestet. Die Nacht über waren keine „Bricklets“ als „Things“ Konfiguriert, sie waren nur über die Inbox zu sehen (nicht immer!) Allerdings ist auch in der Beta20 der Effekt des Remove der Masterbriks vorhanden. Dies erfolgt alle 5 Minuten (siehe Meldung im Log) Entsprechend sieht es natürlich auch für die Bricklets aus. Eine „Richtige“ Fehlermeldung warum die Masterbrick‘s removed werden sehe ich allerdings nicht (hab aber das erweiterte Logging noch nicht aktiviert) auszug-log-fehlermeldung-IO16.txt Viele Grüße Stefan
  18. Hallo Erik, nachdem ich mein System auf das Beta 21 umstellt habe, kam es sporadisch zu verschiedenen Fehler. Reboot und abschalten/Neustart haben nur temporär geholfen. Daher entschloss ich mich die Konfiguration (Binding/Dämon ...) komplett neu zu erstellen. Jetzt funktioniert die Edit Funktion der Bicklets nicht mehr. Zum Fehlerbild: → verschiedene Bricklets gingen offline, aber nicht mehr online (laut Brickviewer waren diese funktionsfähig) → Bindings ungleich Tinkerforge funktionierten nicht mehr (z.B. Astro-Binding, kein Update des Sonnenwinkels) Aus diesem Grund, habe ich alle Bricklets / Dämon‘s / Bindings aus der Konfiguration entfernt (beide TF-Bindings über die Console). Anschließend führt ich einen Update des kompletten System durch. Nach dem Einbinden der Bindings, anlegen der Dämons und adden der Brickletes kann ich jetzt die Bricklets nicht mehr konfigurieren (Edit-Funktion). Beispiel: → von den IO-4 Bricklet 2.0 / IO-16 Bricklet 2.0 / IO-16 Bricklet V1 können die verschiedenen Ports nicht von Input auf Output umgestellt werden. Das Fehlerbild ist eigenartig, da ich im Edit Menü zwar die Ports von Input auf Output umstellen kann, aber im „Thing-Menü“ wird aber für den Port weiterhin „Input“ angezeigt. Wenn ich wieder in das Edit Menü wechsle wird „output“ angezeigt. → für den Dual Button Bricklet 2.0 kann im Edit-Menu zwar der „left/right LED State Channel“ auf Off umgestellt werden, aber diese Änderung wird nicht im Thing-Menü des Bricklets angezeigt. Wenn ich wieder in den Edit Modus des Bricklets wechsle sehe ich die von mir vorgenommene Änderung. Es handelt sich nicht nur um einen Darstellungsfehler. Ich habe dies mit der letzten Release Version (openhab) also mit den Test / Snapshot Versionen versucht, hatte aber keine Auswirkung. Was ich bis jetzt noch nicht versucht habe, das System komplett neu zu installieren. Ich weiß momentan auch nicht weiter viele Grüße Stefan kurzer Update 1: ich habe eben das ganze mit der Beta20 nochmal versucht, da konnte ich die Port der IO-Bricklets und die LED-Channel des Dual-Button wieder konfigurieren. kurzer Update 2: jetzt wo nur wenige Komponenten in der Konfiguration eingebunden sind, sehe ich DEBUG-Meldungen im Log die mich verwirren (aktuell in der Beta20 da ich mit Beta21 die Bricklets Konfiguration nicht Editieren kann) Diese 3 Meldungen erscheinen sporadisch. Was ich verwirrt dass hier vom "TinkerforgeConfigDescriptionProvider" Meldungen für "Non-Tinkerforge-Bindings" kommen. Ich setzte folgende weiter Bindings ein -> Astro-Binding -> LogReader Binding -> NTP Binding diese Bindings sind bereits in Openhab2 über ... /paperui /Configuration / Bindings abrufbar. ich werde das ganze System jetzt komplett neu installieren.
  19. Hallo Erik, hallo Tinkerforge Team wow das ging ja Fix mit dem "LCDx128x64" Firmaware-Bug-Fix 😉 Ich hab gleich gestern Abend den FW update für das LCD eingespielt, anschließende funktionierte auch der RemoveGuiTab für einzelne Tab's Mit Deinem Vorschlag funktioniert auch das Rücksetzten des EdgeCount für die "alten" IO-16 (mit 10 pol Stecker) Super, danke für die schnelle Hilfe viele Grüsse Stefan
  20. Hallo Erik, ich habe das neue Beta-21 Binding eingespielt, nach einem System (OS/Openhab) update funktioniert „fast“ alles wieder. Folgende Punkte sind mir aufgefallen >> LCD 128x64 Wenn ich einen einzelnen Tab mit der action „lcdActions128x64.brickletLCD128x64RemoveGUITab(3)“ löschen will (es ist egal ob Tab 0 / 1 / 2 oder 3) erhalte ich folgende Fehlermeldung (mit der alten Beta-20 gab es da keine Probleme) Wenn ich hingegen alle Tabs mit „lcdActions128x64.brickletLCD128x64RemoveGUITab(255)“ lösche, gibt es keine Fehlermeldung und alle Tabs werden gelöscht. Remove „GUIbutton“ und Remove „GUISlider“ funktionieren ohne Probleme. >> brickletIO16GetEdgeCount (nur für das alte IO-16 hw-Version 1.1.0) das auslesen des EdgeCount funktioniert, jedoch bekomme ich den alten Fehler wenn ich den EdgeCount zurücksetzen will. Für das IO-16 Bricklet 2.0 / Industrial Digital In 4 Bricklet 2.0 / IO-4 Bricklet 2.0 funktioniert es ohne Probleme. Wo liegt mein Fehler ? (ich habe nach der neuen Doku erst einen short dann auf verdacht mit einen int gearbeitet) >> Aufruf in der Rule Version A mit short >> Aufruf in der Rule Version B mit int >>Fehlermeldung für mich sieht das nach so einen Type-Casting Problem von JAVA aus. Aber wie müsse ich es richtig eintragen ? Noch ein Hinweis zur Deiner neuen Dokumentation: In Deiner neuen Doku für das NFC-Bricklet ist mir bei dem Beispiel ein kleiner Fehler aufgefallen. Dort steht in Zeile 15 müsste es nicht lauten Weiter schreibst du als Kommentar im Beispiel könnte Du im Beispiel noch zusätzlich hinweisen, dass es sich bei „newState“ (in Zeile 15) um diese linked item handelt ? Ansonsten funktioniert soweit alles wie gehabt. Viele Grüße Stefan
  21. Hallo Erik, ich gebe Dir recht man braucht nicht für jedes Bricklet ein Beispiel. Das Remot Switch wäre eines, oder Hinweise wenn zum Ausführen ein Text-String an das Item übergeben werden muss. Beim LCD 128x64 ClearDisplay schreibst Du in Deiner Doku dass ein beliebiger String übergeben werden kann, in dieser Art die Hinweise. viele Grüsse Stefan
  22. Hallo Erik ich habe mir für ein paar meiner Bricklest Deine neue Doku angeschaut, Sie gefällt mir gut. Frage: Hast Du in der Doku auch Beispiele & Besonderheiten vorgesehen ? Ich habe keine gesehen. Hintergrund der Frage anhand des Remote Switch Bricklet betrachtet Du schreibst: Wenn ich jetzt nicht über das Forum Deine Beiträge gelesen hätte, wäre mir nicht klar gewesen dass ich bei dem Channel-verlinktem String-Item (für Socket-A), dem String-Item „on“ oder „off“ übergeben muss. (also als String) Beispiel einer hilfreichen Zusatzinformation in der Dokumentation : Auch Hinweise dass man z.B. einem Channel-verlinktem ITEM eines EdgeCount (der verschiedenen Bricklet) ein „REFRESH“ übergeben kann um einen Update der Werte zu erzwingen wäre nicht schlecht. Generell bin ich für jeden Hinweis dankbar um Fehler zu finden oder zu vermeiden. Ich könnte mir vorstellen, dass diese zusätzlichen Informationen / Beispiele Anfängern oder "Teilzeit" Openhab-Anwendern helfen würden (zumindest geht es mir so). An dieser Stelle nochmal Danke an Deine tolle Arbeit Viele Grüße Stefan
  23. Hallo Erik, kurzer Update ich habe diese Woche meinen zusätzlichen Komponenten bekommen 1 x Air Quality Bricklet 1 x PTC V2 mit Sensor durch den zusätzlichen Masterbrick war ich auch in der Lage ein altes Temperatur Bricklet (HW Version 1.1.0) in die Konfiguration auf zu nehmen. Alle Bricklets funktionieren mit dem Binding und liefern Werte, allerdings habe ich bis jetzt noch keine Action mit diesen Bricklets getestet. Ich vergleich gerade mal wie die verschieden Temperatur-Sensoren Daten liefern. Bist jetzt habe ich den Eindruck dass die Werte des PTC 2 die des Humidty V2 (Temperatur) und die des Air Quallity (Temperatur) sehr nahe zusammen liegen. Die TH-Sensoren liegen näher an den Werten des alten Temperatur Bricklets. Was mir auch gut gefällt ist, dass am PTC V2 ein Offset eingestellt werden kann. Vermutlich werde ich einen Kombination aus Air Quallity Bricklet für innen, PTC & Humidity V2 Bricklet für Außen einsetzten. viele Grüsse Stefan
  24. Hallo Tim, klar macht mehr Sinn das Thema über Privat Nachrichten zu klären, hab Dir hier über die Forum-Funktion einen PV-Nachricht gesendet, ich hoffe Sie ist angekommen. viele Grüsse Stefan
  25. Hallo Tim (Teddy) danke für Dein Angebot bezüglich der „Taster-Abdeckungen“ In meiner aktuellen produktiven Openhab 1.9 Umgebung habe ich ein Bedienfeld mit einem LCD20x4 und einem Multitouch 3x4 Key-Pad. (siehe Bild unten, besteht aus Acryl 5mm, wurde mit einem Laser-Cutter bei einem Lokalen Acryl-Glas Handel hergestellt) Diese Bedienfeld-V1 möchte ich mit der Umstellung meines Prod-System auf OpenHab2 komplett neu aufbauen und aktuelle Tinkerforge Komponenten integrieren. Vom Aufbau würde ich wieder 5mm Acryl nutzen, die Bricklets würde auf einem Basis-UnterRahmen befestigt und mit einem „Abdeckrahmen“ mit entsprechenden Ausschnitt für die Bedienelemente geschützt. Im groben würde folgenden Komponenten in diesem Bedienfeld verbaut sein 1x LCD 128x64 1x Multi-Touch mit 4x3 Key-Pad 1x NFC 1x Dual Button 1x Rotary Encoder 1x Rotary Poti bis auf den Dual-Button sind es im Grunde nur entsprechende Ausschnitte / Bohrungen in der Bedienfeld-Abdeckung. Siehe die Grob-skizze unten. Ich würde vermuten dass mir die reinen Abdeckungen ausreichen würden, hast Du auch ein Bild wie diese Abdeckungen ohne Gehäuse aussehen (evtl wenn sie auf dem Dual-Button liegen) ? Selber steht mir kein 3D Drucker zur Verfügung. Daher würde ich gerne auf Dein Angebot zurück kommen. Jetzt und hier ein große Lob an das gesamte Tinkerforge TEAM 🙂 viele Grüße Stefan
×
×
  • Create New...