Jump to content

StefanOHAN

Members
  • Content Count

    100
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

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

  1. Hallo Erik Die Abfrage der Alarm-Action mit GetAlarm und der Auswertung des Value mit .get("durationRemaining") as long hat wunderbar geklappt. Mir ist allerdings zufällig aufgefallen das der Brick-Dämon der für die per USB angeschlossen Masterbricks und des HAT zuständig ist kurz ausgefallen ist. Aufgefallen ist mir das nur, da eine meiner Test Rule‘s ohne mein Zutun das DualRelais on und off schaltet. Ich vermutet es hing damit zusammen dass alle Button des LCD128x64 „triggerd RELEASED meldeten alle Bricklets die über diesen Dämon angesprochen werden, meldeten dass Sie wieder online gingen Dieser Effekt ist nicht so schön, denn es könnte sich auf Rules auswirken. (z.B. es reagierte auch die Rule die als Channel-Trigger die TouchPosition nutzt) Gesehen habe ich dies bis jetzt nur einmal. Im Event-Log der letzten 2 Tage (in diesem Zeitraum habe ich das System nicht gebootet) fand ich keine weitere Meldung für dieser Art des brick-Dämon. Frage: gibt es irgend einen TimeOut der evlt. zu schnell reagierte und daher diesen Fehler verursachte ? Wenn du den Zeitstempel anschaust ist das gerade mal im 200ms Bereich abgelaufen. Viele Grüße Stefan
  2. Hallo Erik zum getEdgeCount IO-16 V1 ich habe mal versucht mit short das ganze zu testen. Es kommt aber noch immer der Fehler. . Um sicher zu gehen, dass mir kein Config Fehler unterlaufen ist, habe ich noch mal unter Things geprüft, wie der korrekte Channel / Port lautet. Mit long hatte ich gestern anstelle von int getestet, das hat auch nicht geklappt. Zum Piezo Alarm, Ja das Item „PiezoAlarm“ nutze ich für den Alarm Channel. Kaum habe ich den SendCommand für das Einschalten des AlarmChannel entfernt und nur die SetAlarm Action in der Rule aufgerufen, hat es wunderbar geklappt. Ich dachte, ich muss den Alarm erst über den AlarmChannel „einschalten“, das war mein Fehler Super jetzt passt meine Rule Abschalten einer laufenden Alarm-Action geht einfach indem ich den AlarmChannel per SendCommand auf OFF setzte. Frage, kann ich eigentlich abfragen ob gerade eine „Alarm“-Action aktiv ist ? Oder muss ich mir selber über Variablen einen Merker setzten ? Viele Grüße Stefan
  3. Hallo omiT anbei mein Beispiel für den Motion Detector V2 Test Die LED habe ich über eine ITEM-Datei verlinkt, ich nutze diese in meiner Test-Rule für die Anzeige wann einen Bewegung erkannt wurde und diese wieder beendet wurde. Eintrag in "meiner" Item-Datei Zum spielen gibt es 2 Rules, eine die bei Bewegung „erkannt“ die LED erst mit 25% dann mit 100% Leistung einschaltet. Und eine die bei „Ende“ Bewegung die LED in umgekehrter Reihenfolge wieder auf Leistung 0% abschaltet. Der Thread::sleep(100) dient nur dazu, dass ich erkennen kann ob ein Unterschied zwischen 25% und 100% Leistung bei den LED zu erkennen ist. Der sleep ist hier etwas uncool, da Du Gefahr läufst, dass die erste Rule noch einen Sleep abwartet während bereits ein Trigger für die zweite Rule gestartet wurde. Aber zum testen geht´s 😉 Die Channel-Information für BrickletMotionDetectorV2MotionDetected / DetectorV2DetectionCycleEnded findest Du wie die channel‘s für die LED‘s unter paperui / Configuration / Things / MotionDetector Wenn Du die Items & Rule‘s entsprechende Deinen Channel-Thing-Daten anpasst, sollte es klappen. Grüsse Stefan
  4. Hallo Erik heute habe ich mal versucht alle meine angeschlossenen Bricklets mit dem B16-Binding zu testen (aber nicht alle möglichen Actions). Folgendes ist mir dabei aufgefallen. >>„Industrial Digital In 4 Bricklet 2.0“ Frage: Kann es sein, dass Du keine Action für „getEdgeCount(int channel, boolean resetCounter)“ mehr vorgesehen hast ? Bei den IO-16-V1 / IO-16-V2 / IO-4-V2 & „Industrial Digital In 4 V2“ hatte der mit dem EdgeCount verlinkte Number-Item immer den Werte 0 Ich vermute es ist noch das Problem das Du in Deinem Post vom 28.10.2019 beschrieben hast, oder ? Die Action getEdgeCount funktionierte für das IO-4 V2 und das IO-16-V2 (es wurde ein Wert ausgegeben), für das IO-16 V1 hingegen nicht. Basis der Rule war ein Vorschlag den Du am 15.11.2019 auf meine Frage zur getEdgeCount Action gemacht hast. Diesen habe ich entsprechend für die 3 verschieden IO-Bricklets angepasst Hier das Beispiel für das IO-16-V1 Ich bekomme (nur) für das IO-16 V1 folgende Fehlermeldung im Log Technische Daten zu meinem IO-16-V1 Zum den Action (Alarm) des Piezo Speaker V2 hätte ich eine Frage Die Grundkonfiguration für den Beep und den Alarm sind doch unabhängig von Action‘s „brickletPiezoSpeakerV2SetBeep“ und brickletPiezoSpeakerV2SetAlarm, oder ? Ich habe mit dem „brickletPiezoSpeakerV2SetAlarm“ in den Rules ein Problem. Aber komischerweise nur mit dem Alarm nicht mit dem Beep. Wenn ich in einer Rule über brickletPiezoSpeakerV2SetAlarm versuche den Alarm zu verändern, ändert sich nur kurz die „Startfrequenz“ auf dem Wert den ich mit der Action übergebe, aber nach ca 0,1-0,2 Sekunden kommt der Alarm so wie er über der Thing „Configure channel“ voreingestellt ist. Ich hätte einen Alarm mit 1000Hz Startfrequenz, der jede Sekunde in 100 Hz Schritten bis 2500 Hz ansteigt und dies 10 Sekunden lang andauert. Es kommt aber nur ein kurzer 1000 Hz Ton dann fällt er wieder auf die Channel-Konfiguration zurück (Startfrequenz = 200Hz, Endfrequenz = 1000Hz, StepSize = 100 , StepDelay = 100 , DefaultVolumen = 1 , Duration = 5000) Wo liegt der Fehler in meiner Rule ? Einen Frage zu den Channel des MultiTouch V2 Generell funktionieren bei mir die mit ITEM-Verlinken Channel, diese kann ich auch problemlos in Rules verwenden. Kann es sein, dass die Channel nicht direkt in einer Rule als Trigger genutzt werden können ? Ich sehe auch im Log keine Meldung wenn ich eine der Tasten berühre (ich nutze Eurer 3x4 Tastenfeld). Ich habe in der Rule Channel verwendet die mit einem Item verlinkt waren und Channel die nicht mit einem Item verlinkt waren. Was ich auch echt gut finde ist die Firmware/Update und HW Info die das neue Binding bereitstellt. Viele Grüße Stefan Anbei meine Testliste Binding Version B16 Typ Item-Channel-Verlinkung Item in Rule Channel in Rule Action in Rule E-Paper296x128 ok nicht getestet nicht getestet FillDisplay / DrawText Multitouch V2 ok ok keine Funktion nicht getestet Rotary Poti V2 ok ok nicht getestet nicht getestet Rotary Encoder V2 ok ok nicht getestet nicht getestet Humidity Bricklet V2 ok ok nicht getestet nicht getestet Outdoor Weather Bricklet ok (mit 2 x TH6148) ok nicht getestet nicht getestet Motion Detector V2 ok ok ok nicht getestet LCD 128x64 ok ok ok verschiedene LCD 20x4 ok ok ok brickletLCD20x4ClearDisplay Dual Relay V2 ok ok nicht getestet nicht getestet Industrial QuadRelay V2 ok ok nicht getestet nicht getestet Industrial Digital In4 V2 ok ok nicht getestet kein getEdgeCount ? IO-16 V1 ok ok nicht getestet Problem mit getEdgeCount IO-16 V2 ok ok nicht getestet getEdgeCount IO-4 V2 ok ok nicht getestet getEdgeCount Piezo Speaker V2 ok ok nicht getestet Problem PiezoSpeakerV2SetAlarm
  5. Hallo Erik kurze Rückmeldung zum neuen B16 Binding Gestern abend habe ich das Binding eingespielt, zuvor alle Things aus der Konfiguration entfernt und erneut hinzugefügt. Alle verlinkten Items und "Channel"-Aufrufen in Rules usw angepasst. Auf dem ersten Blick funktionieren alle Rules und alle (angepassten) verlinkten Items. Das Problem mit den "vergessenen" ID der Sensoren ist auch behoben (habe 3 x ,incl Spannung-Abschaltung, rebootet). Zusätzlich habe ich einen weiteren TH-6148-Sensor in die Konfiguration aufgenommen und verlinkt, hat wunderbar geklappt. Auch die Fehlermeldung (No value present) die ich in meinem letzten Post beschrieben habe ist nicht mehr aufgetaucht. Nachdem ich aktuell 2 Tinkerforge-Stack angeschlossen habe ( 1x WIFI-Extention , 1xUSB) , habe ich auch das Umstecken des Piezo-Speaker vom Masterbrick-USB-angeschlossen, zum Masterbrick-WIFI-Extention angeschlossen, getestet. Nachdem Boot nur die Konfiguration angepasst ("configuration/things/edit/tinkerforge:brickletpiezospeakerv2" über die Auswahl der "Bridge Selection") und der Speaker war wieder online ohne dass ich Verlinkungen der Items ändern musste (super Funktion). Zwei Fragen hätte ich noch 1) Bezüglich "Schema für ThingUID" : Ich habe die beiden Brick-Daemons (für WIFI & USB angeschlossene Master-Bricks) nicht "entfernt und neu hinzugefügt", nur die restlichen Tinkerforge-Things. Frage: könnte dies evtl später zu Problemen führen, bis jetzt funktioniert alles. 2) wie oft/wann wird denn der "Sensor/Station Identifiers" des OutDoor Weather aktualisiert ? Nachdem ich den zweiten TH-6148-Sensor aktiviert hatte, könnte ich zwar über den Brickviewer dessen ID lesen, und mit dieser dann den Sensor in die Konfiguration einbinden, jedoch zeigte mir "Sensor Identifiers" nur die ID des bereits aktiven an. Nach ca 10 min habe ich das System 1 x rebootet (incl Stromabschaltung), danach wurden beide ID angezeigt. Wie gesagt den zweiten Sensor konnte ich funktionsfähig einbinden obwohl dessen ID noch nicht im Sensor-Identifier angezeigt wurde. Deine Binding-Funktionen sind echt super, danke nochmal Am WE werde ich weiter Testen viele Grüsse Stefan
  6. Hallo Erik ich habe heute Abend das neue B15 Binding eingespielt. Nach dem Neustart erschienen anschließend im Log viele Fehlermeldungen diverser actions, diese waren nach einem reboot mit trennen der Spannungsversorgung aber behoben. Das Backlight des LCD20x4 kann jetzt per Rule wieder ein uns ausgeschaltet werden Die umgebaute Funktion für das Outdoor Weather Bricklet funktioniert (teilweise). Ich konnte das neue Thing „Tinkerforge Outdoor Weather Temperature/Humidity Sensor TH-6148„ hinzufügen, sowie den Sensor mit der passenden ID konfigurieren. Die Freude war aber nur von kurzer Dauer, nach einem Reboot incl. Stromabschaltung, wurde mir das Thing als „UNINITIALIZED - BRIDGE_UNINITIALIZED “ angezeigt. Wenn ich unter configuration / things/edit/tinkerforge:outdoorweathersensor >>Bridge Selection<< nachschaue, wird das Outdoorweather-Bricklet mit korrekter Thing-ID und Bricklet-ID im Menü angezeigt. Auch ein erneutes Abspeichern in diesem edit Menü änderte nicht am Status. Als nach ca. 10 Minuten noch immer die „ UNINITIALIZED – BRIDGE_UNINITIALIZED“ für das Thing angezeigt wurde, habe ich dieses aus der OpenHAB Konfiguration entfernt und neu hinzugefügt. Danach wurde das Thing als online angezeigt und die Sensor-Daten wurden an die „neu“ mit den Channel verlinkten Items übertragen. Das ganze habe ich 2x ausgeführt, der Fehler war reproduzierbar. Frage: Kannst du mal schauen, wie sich das System bei Dir verhält ? Das neu verlinken der Items konnte ich im zweiten Versuch zwar vermeiden, ich musste aber ebenso das Thing aus der Konfiguration entfernen und neu hinzufügen (hierbei habe ich dann die alte Thing-ID wieder eingetragen). Es wäre unschön, wenn man nach einem Reboot mit „abschalten der Spannungsversorgung“ so eingreifen müsste. Die beiden neuen String-Item des Outdoor Weather Bricklet funktionieren, ich habe je ein String-Item für die Sensor und Station Identifiers angelegt. Nachdem ich keine Station habe wurde auch keine ID anzeigt, für den Sensor wurde die ID korrekt angezeigt. Ich vermute das String-Item, das ich für den Station-Identifier anlegte und verlinkte habe, verursachte diese Fehlermeldung in Log (ich habe nur einen Sensor, aber für Sensor und Station je ein verlinktes Item). Oder wie interpretierst Du diese Meldung im Log ? Viele Grüße Stefan
  7. Hallo Erik die Auswertung der brickletLCD128x64GetTouchPosition hat wunderbar geklappt. Es kam nur ein kleiner Fehler für "age" Hab dann nochmal bei Euch in die Java-Beispiele geschaut >>age – Typ: long, Einheit: 1 ms, Wertebereich: [0 bis 232 - 1]<< und long hat es geklappt. Ich sehe schon, ich muss mich etwas mehr mit Java beschäftigen 🙂 Nochmals Danke 🙂 viele Grüsse Stefan
  8. Hallo Erik, dieses Woche habe ich nicht soviel getestet, eine Frage hätte ich aber zu einer Action für das LCD128x64 Wie kann ich die Daten aus der Action .brickletLCD128x64GetTouchPosition() nutzen ? Was müsste ich im Aufruf ändern, dass ich die 4 Rückgabewerte in rule‘s nutzen kann ? Ich habe versucht die Daten einer String Variablen oder einem String Item zu zuweisen, es kam immer ein Fehler. Wenn ich die Action ohne eine Zuweisung (String/Variablen) aufrufe kommt kein Fehler, allerdings sehe ich auch kein Ergebnis. Meine beiden Aufrufen : a) mit Variablen Fehler im Log: b) mit Item-String Fehler im Log Hinweis zu Eurer Dokumentation: Kann es Sein dass Euch in der Java-Beispiel Doku ein kleiner Fehler unterlaufen ist ? In der Parameter-Liste steht als Wertebereich für den Index 0-5 (also 6 Slider) in der in der Textbeschreibung steht dass bis zu 8 Slider benutzt werden können Index 0-7 Zitat aus Euer Beschreibung: Viele Grüße Stefan
  9. Hallo Erik, ich habe über die Feiertage mit dem B14 Binding etwas weiter getestet (hauptsächlich Actions). Abgesehen mit dem Backlight LCD20x4 Problem und der Sensor TH-6148 unschärfe ist das System stabil durchgelaufen. Folgende Action habe ich getestet. LCD128x64 : alle unten aufgelisteten Action haben funktioniert brickletLCD128x64SetGUIButton / brickletLCD128x64RemoveGUIButton brickletLCD128x64SetGUISlider / brickletLCD128x64RemoveGUISlider brickletLCD128x64DrawText / brickletLCD128x64ClearDisplay brickletLCD128x64RemoveAllGUI Piezo V2: alle unten aufgelisteten Action haben funktioniert brickletPiezoSpeakerV2SetBeep / brickletPiezoSpeakerV2SetAlarm brickletPiezoSpeakerV2UpdateVolume / brickletPiezoSpeakerV2UpdateFrequency Zwei unschöne Sachen sind mir beim „Outdoor Weather Bricklet“ in Verbindung mit dem „Outdoor Weather Temperature/Humidity Sensor TH-6148“ aufgefallen. Beide Punkte scheinen bei Euch bekannt zu sein (hab verschiedene Einträge im Forum gefunden), machen es aber problematisch das Weather Bricklet und den TH-6148 sinnvoll in Openhab einzusetzen. 1) Der Sensor ändert willkürlich nach einem Batterie-tausch seine ID. Dies hat zur Folge, dass man Channel-Verlinkung zu Items oder Rules anpassen muss. Dies ist ein echtes KO Kriterium. >>„never touch an running system“<< 2) Das „Outdoor Weather Bricklet“ merkt sich die alte ID des TH-6148 und zeigt somit den TH-6148 jeweils mit der alten und neuen ID als eigenständiges Thing an. Die alte-ID lässt sich nur entfernen wenn man das System stromlos macht und zuvor das „Outdoor Weather Bricklet“ samt Sensor & Sensor-Leichen aus der Openhab Konfiguration entfernt und das System erneut neu startet. Dazu hätte ich drei Fragen: 1) gibt es kompatiblen Sensor zum TH-6148 dessen ID man Konfigurieren kann ? (ich vermute der TH-6148 wurde nicht von Euch entwickelt, sondern zugekauft) 2) Im Post „https://www.tinkerunity.org/topic/4543-id-des-th-6148-temperatursensors/?tab=comments#comment-26305“ wird auf das Problem der „Sensor Leichen“ hingewiesen. „Borg“ meinte er würde es auf seine ToDo Liste setzten (das Löschen der Sensor Leichen). Ist Dir Bekannt ob nach 24h diese Leichen automatisch weg sind ? (hat bei mir nicht geklappt) 3) siehst Du eine Möglichkeit das Binding so umzubauen, dass zumindest keine neue Verlinkung / Rule Anpassung statt finden muss, wenn die Batterie des Sensor getauscht wurde ? Aktuell wird der Sensor als eigenständiges Thing angezeigt, eventuell wäre es eine Option dass die 3 Channel des Sensor als Channel‘s direkt über das „Outdoor Weather Bricklet“-Thing dargestellt und erst dort mit den ID des Sensoren verknüpft werden (ähnlich dem IO-16, dort können auch die 16-Ports einzeln konfiguriert werden). Sicher müsste man dann die Anzahl der möglichen Sensoren die über diese Methode eingebunden werden, auf eine kleiner Stückzahl reduzieren (5-10?) um das ganz bedienbar zu halten. Eigentlich wollte ich mit dem „Outdoor Weather Bricklet“ und dem TH-6148 ein etwas schwierig zu erreichenden Masterbrick ablösen. Das müsste ich nicht, wenn der „FW-Update“ nicht das betätigen der Boot und Reset-Taste am Masterbrick erfordern würde. Frage: Gibt es eine Planung den FW-Update des Masterbrick zukünftig anderes zu gestalten, ähnlich dem es HAT ? (also ohne betätigen des beiden Tasten) Den Masterbrick könnte ich auch ablösen wenn es längere Leitungen geben würde. In einem alten Post (aus dem Jahr 2012) ist zu lesen, dass die Leitungslänge abhängig vom Bus ist und daher begrenzt ist. Hat sich da mit den neuen 7 Pol Bricklets etwas geändert (mir würden 3 Meter lange Leitungen reichen) siehe Archiv Post https://www.tinkerunity.org/topic/40-maximale-l%C3%A4nge-f%C3%BCr-ein-bricklet-kabel/#msg192 dort wird von möglichen 4x3m am Masterbrick gesprochen (leider kann man nicht mehr erkennen von wem der Post stammt) --- Den Punkt mit dem nicht ausschaltbaren Backlight es LCD 20x4 habe ich ja bereits vor ein paar tagen gepostet (lässt sich ein aber nicht mehr ausschalten) Viele Grüße Stefan
  10. Hallo Erik, gestern habe ich etwas mit dem neuen 14er Binding getestet und die Actions Cleardisplay für LCD20x4 und 128x64 in eine Rule eingebaut, hat funktioniert. Kannst Du Dir aber bitte noch mal das 20x4 LCD anschauen ? Aktuell kann ich zwar das Backgroundlight einschalten aber nicht mehr ausschalten (über den Brickviewer lässt es sich ausschalten). Es macht keinen Unterschied ob ich dies per Rule oder ../paperui/control versuche.(ich hoffe nicht dass ich einen Tippfehler hatte) Mein Item sieht wie folgt aus Mir ist aufgefallen, dass in Deiner Binding-Doku zwar eine Action für >>brickletLCD20x4IsBacklightOn<< gibt, aber keine für OFF. In der Tinkerforge Doku mit dem Java-Beispielen gibt es jedoch eine. >>BrickletLCD20x4.backlightOff() Kann dies die Ursache sein ? Ich werde über die Feiertage weiter testen @KlausGünther : ich hatte ein ähnliches Problem, nachdem Hinzufügen des "Masterbrick"-Things waren diese mehrfach unter Things vorhanden (immer die gleiche ID). Als ich den Dämon gelöscht, das Binding über die "openhab-cli console" deinstalliert und openhab zurück gesetzt hatte, war der Fehler weg und ist nicht mehr aufgetreten (dies ist jetzt 3 Tage her). Ich hätte mal vermutet dass sich openhab irgendwo "verschluckt" hatte. viele Grüsse und frohes Fest Stefan
  11. Hallo Erik, ich werde mich dieses WE gleich mal ans Testen machen. Das mit der mehr Schreibarbeit ist ok, Hauptsache man kann die Actions nutzen. Viele Grüsse, ein frohes Fest und ein gesundes und glückliches Jahr 2020 Stefan
  12. Hallo Erik, Danke für die schnelle Antwort Gut zu wissen, dann werde ich bei der nächsten Bestellung ein RedBrick in den Warenkorb legen. 😀 viele Grüsse
  13. Hallo Erik, wie sieht Eure Planung bezüglich des RedBrick aus ? Ihr stellt doch momentan noch die Openhab 1.8x version für Ihn bereit, oder ? (ich meine diese schönen kleine Funktion über den Brickviewer Openhab zu aktivieren) Wenn Dein neues Binding mal fertig ist, plant Ihr dann auch die Openhab 2.x Version für den RedBrick so bereit zu stellen ? Ich hätte ein mini Projekt, da wäre RedBrick & Masterbrick ideal (klein und kompakt) viele Grüsse Stefan
  14. Hallo Erik, nachdem ich Deinen Post zu dem Rule-Engine Problem gelesen habe, dachte ich mir nur mal so zum Spaß, es mit anderen Bricklet-Actions zu testen. Bei mir hat sich das IO-16 und IO-4 angeboten denn beide haben die getValue action. Also wenn ich mich nicht vertippt habe, kann ich mit der getValue Action Deine Erkenntnis zur Auswirkung des RuleEngine Problem bestätigen. Interessant war, als ich anfangs nur die IO-16 actions nutze (ohne dass ich für das IO-4 getAction in der Rule hatte), die IO-16 getValue action funktionierte. Erst als ich dann beim zweiten Versuch ebenfalls getAction für das IO-4 in der rule hatte, kam es immer zur Fehlermeldung. Auch als ich anschließend aus der Rule das getAction und getvalue für das IO-4 entfernte, blieb es bei der Fehlermeldung für das IO-4 wenn ich für das IO-16 das getValue nutzte. Ich bin ja gespannt was Du als Antwort auf Deinen Post bei den Openhab Entwicklern bekommst (ob es ein bekanntes Problem ist, oder nicht) Fehlermeldung wenn für das IO16 die getValue Action in der Rule enthalten ist. viele Grüße Stefan
  15. Hallo Erik das Thema mit dem 6 Stunden Zyclus des off und online gehen der WIFI-Extension hat sich jetzt geklärt. Es liegt an einer Funktion der AVM, der "Optimierung der genutzten WLAN Kanäle". Kurz die AVM optimiert die WLAN Kanäle, daher kann es vorkommen dass die WLAN Devices ab und wieder angemeldet werden. Nachdem ich im AVM Log noch die Zusatzinformationen für WLAN aktiviert habe, konnte ich folgende zusammenhänge auslesen ---LogMeldung der Basis-Station AVM7590 ---LogMeldung Repeater ----LogMeldung Openhab Der Zeitliche Ablauf in den verschiedenen Logfile zeigt dass diese Optimierungs-Funkion der "Übeltäter" ist. Leider hatte ich nicht den vollen Logging-Umfang in der AVM aktiviert, daher konnte ich erst nachträglich den Zusammenhang erkennen 😞 Sorry viele Grüsse Stefan
×
×
  • Create New...