Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Last week
  3. Hallo Zusammen, ich habe mir eine RGB LED Wall mit https://github.com/frankred/tinkerforge-living-wall gebaut (17x28 rgb leds). Gibt es für das Ansteuern der Pixel ein Framework welches das ganze Vereinfacht. Ich habe schon ein paar Animationen umgesetzt, via BrickletLEDStrip.setRGBValues(int index, short length, short[] r, short[] g, short[] b) scheint mir das jedoch sehr Low-Level und umständlich vorzukommen. Kennt jemand vielleicht eine gute Bibliothek mit vielen Features? Vielen Dank schon mal an die Community!
  4. Hallo Maxicko, ich will mich nicht mit fremden Federn schmücken, die Berechnung für die absolute Luftfeuchte habe ich im OpenHAB Forum gefunden. Den Link selber hab ich nicht mehr, aber den Org Text. Diese Rule ist die Basis meiner Rule, ich hab sie nur noch um einige funktionen erweitert. das ganze war noch für openhab1, vermutlich kannst Du jetzt die meisten Imports weg lassen. Um sicher zu gehen dass dies Berechnung korrekt ist, habe ich mit verschiedenen Temperatur und Luftfeuchte Werten über einen Website (die Berechnung der absoluten Luftfeuchte anbot) die Ergebnisse überprüft. Es waren nur vernachlässigbare Abweichungen fest zu stellen. viele Grüsse Stefan
  5. Hallo, heute wieder :-( Zunächst war das Display "eingefroren". Als ich es dann nochmals berührt habe, ging der wilde Wechsel wieder los: Zuerst mit Pressure-Werten um 165, dann konstant ca. 30 mal 70, dann einige Male gewechselt zwischen 121 und 167, anschließend über 100 mal den Wert 160. Ich vermute, dass die wechselnden Werte durch weitere Berührungen verursacht wurden, die konstanten Werte ohne Berührung. Konntet ihr es mittlerweile nachstellen?
  6. We will receive the new products on Thursday this week. We will need a little time to prepare all the modules for shipping but next week I expect to have everything in stock.
  7. Hi Stefan, hab das Humidity 2 auch im Einsatz und leider das gleiche Problem. Ich verwende die Werte dennoch und rechne über eine rule die Werte nach unten. Was mir inzwischen mehr Sorgen bereitet, sind die Werte des Air Quality Bricklet. Dort habe ich ebenfalls zu hohe Werte. Wobei mich da mehr stört, dass der Luftdruck deutlich zu niedrig (60hPa Differenz) ausgegeben wird. An der Stelle wollte ich allerdings vorsichtig fragen, ob du deine Berechnung zur absoluten Luftfeuchte hier als open-source preisgeben kannst, bzw. willst? Bin grad an der gleichen Sache und es würde mir zumindest ein paar graue Haare ersparen... Vielen Dank im Voraus und VG Max
  8. Moin, @StefanOHAN Da würde ich mich eher auf die TH-6148 verlassen, zumindest wenn sie weniger messen als das Humidity. Temperatur-Messung ist überraschend schwierig und das Humidity hat prinzipiell ein Problem mit der Selbsterwärmung des Prozessors. @riro Verlass dich da mal nicht 100%ig auf die Java-Doku. Ich habe das für openHAB so gebaut, dass möglichst immer in der Basis-SI-Einheit ausgegeben wird, das vereinfacht die Generation der Bindings. Bei der Regenmenge ist das leider etwas unhandliche Meter. Du kannst in der Sitemap aber auch mit einem Transformation-Service umrechnen, vermutlich mit der JavaScript-Transformation, es sei denn dir reicht es, ein paar Intervalle auf jeweils einen Wert umzubiegen, dann tuts auch die Scale-Transformation. Das liegt daran, dass das Binding die Callbacks des Bricklets benutzt. LastChange ist dann der Zeitpunkt, wann auch immer das letzte Callback ankam. Ich überlege mir mal, ob ich ins Binding noch eine Möglichkeit einbaue, das als relative Zeit zu bekommen, aber ich fürchte, du musst dir mit einer Rule mit Time-Based-Trigger behelfen. Das ist nichts kritisches, du hast da noch einen alten Handler rumfliegen, der versucht die Station/Sensor-IDs zu aktualisieren, obwohl das entsprechende Thing gelöscht ist. Das ist ein Bug, der mit der nächsten Beta behoben sein sollte. Gruß, Erik
  9. Hi! Any update on this? GPS is still out of stock. Thanx
  10. Hallo Riro, (hallo Erik) freut ich dass meine mini Anleitung geholfen hat 🙂 Ich selbst nutzte nur lieber Rules als .js Bezüglich Deiner Fehlermeldung, da müsstest Du Dich hier im Post an "Erik" wenden, er erstellt das Binding (ist ja noch in der BETA-Phase) . Er kann besser beurteilen ob diese WARN Meldung kritisch ist oder nicht. Ich gehe da manchmal brute-force vor und lösche den Dämon und richtig Ihn wieder neu ein (nur aufpassen dass du Dir die alte Dämon - ID merkst, dass du diese beim neu Anlegen des Dämon eintragen kannst, sonst würden alle Deine LinkChannel nicht mehr funktionieren >> ID ist Bestandteil des Channel). Viele Grüsse Stefan
  11. Earlier
  12. Hallo Stefan, vielen Dank für die phantastische Anleitung! Habe das so umgesetzt: // .items für das TF OutdoorWeatherBricklet via Tinkerforge2.0 Binding String TF_OutdoorWeather_SensorID "TF OutdoorWeather: Sensor ID [%s]" {channel="tinkerforge:brickletoutdoorweather:xyz:BrickletOutdoorWeatherSensorIdentifiers"} Number:Temperature TF_OutdoorWeatherSensorTemperature "Temperatur Balkon [%.1f °C]" <temperature> {channel="tinkerforge:outdoorweathersensor:a40752e8:OutdoorWeatherSensorTemperature"} Number:Dimensionless TF_OutdoorWeatherSensorHumidity "Luftfeuchte Balkon [%.0f %%]" <humidity> {channel="tinkerforge:outdoorweathersensor:a40752e8:OutdoorWeatherSensorHumidity"} DateTime TF_OutdoorWeatherSensorLastChange "Letzte Meldung FunkSensor [%1$tA, %1$td.%1$tm.%1$tY %1$tT]" <date> {channel="tinkerforge:outdoorweathersensor:a40752e8:OutdoorWeatherSensorLastChange"} String TF_OutdoorWeather_StationID "TF OutdoorWeather: Stations ID [%s]" {channel="tinkerforge:brickletoutdoorweather:xyz:BrickletOutdoorWeatherStationIdentifiers"} Number:Temperature TF_OutdoorWeatherStationWS6147OutdoorWeatherStationTemperature "Temperatur Hof [%.1f °C]" <temperature> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationTemperature"} Number:Dimensionless TF_OutdoorWeatherStationWS6147OutdoorWeatherStationHumidity "Luftfeuchte Hof [%.0f %%]" <humidity> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationHumidity"} Number:Speed TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindSpeed "Windgeschwindigkeit" <wind> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationWindSpeed"} Number:Speed TF_OutdoorWeatherStationWS6147OutdoorWeatherStationGustSpeed "Windböengeschwindigkeit" <wind> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationGustSpeed"} String TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindDirection "Windrichtung" <wind> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationWindDirection"} Number:Length TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall "Niederschlag [%.1f]" <rain> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationRainFall"} Number:Dimensionless TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall_test "Niederschlag 1/10 mm [%s]" {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationRainFall"} Switch TF_OutdoorWeatherStationWS6147OutdoorWeatherStationBatteryLow "Batterie Wetterstation ist leer" <lowbattery> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationBatteryLow"} DateTime TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange "Letzte Meldung FunkStation [%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS]" <date> {channel="tinkerforge:outdoorweatherstation:8fa165af:OutdoorWeatherStationLastChange"} und die passende Sitemap: Frame label="Tinkerforge OutdoorWeatherStation und Sensor" { // Paper UI: Autodetect von Bricklets // Sensor und Station via Brick Viewer ermitteln oder per OH und String Item anzeigen lassen // via PaperUI: Manually add Thing, als Bridge OutdoorWeatherBricklet wählen, Sensor oder StationID eintragen // Damit ist ein Thing angelegt. Daraus Items erzeugen und eine Sitemap anpassen Default item=TF_OutdoorWeather_SensorID Default item=TF_OutdoorWeatherSensorTemperature valuecolor=[TF_OutdoorWeatherSensorLastChange=="NULL"="lightgray", TF_OutdoorWeatherSensorLastChange>90="lightgray", >=25="red", >=15="orange", >=10="green", 0="silver", <0="purple", <10="blue"] Default item=TF_OutdoorWeatherSensorHumidity Text item=TF_OutdoorWeatherSensorLastChange valuecolor=[TF_OutdoorWeatherSensorLastChange>120="orange", TF_OutdoorWeatherSensorLastChange>300="red"] //visibility=[TF_OutdoorWeatherSensorLastChange>30] Default item=TF_OutdoorWeather_StationID Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationTemperature valuecolor=[TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange=="NULL"="lightgray", TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>90="lightgray", >=25="red", >=15="orange", >=10="green", 0="silver", <0="purple", <10="blue"] Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationHumidity Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall label="Niederschlag [%.1f mm]" //Automatische Konvertierung m in mm via UOM, Achtung 1/10 mm? Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationRainFall_test label="Niederschlag [%s]" Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindSpeed Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationGustSpeed Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationWindDirection Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange valuecolor=[TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>120="orange", TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>300="red"] //visibility=[TF_OutdoorWeatherStationWS6147OutdoorWeatherStationLastChange>30] Default item=TF_OutdoorWeatherStationWS6147OutdoorWeatherStationBatteryLow } Die Regenmenge und die Geschwindigkeiten müssen noch passend umgerechnet werden. Z.B. wird die Regenmenge laut Doku (https://www.tinkerforge.com/de/doc/Software/Bricklets/OutdoorWeather_Bricklet_Java.html) in 1/10 mm ausgegeben. Das bekommt OpenHAB natürlich nicht mit. Leider braucht man dafür wieder eine Rule oder JS Function ... wenn das das Binding selbstständig machen würde. 😉 Bisher habe ich die Wetterstation (oder alle Tinkerforge Sensoren) per MQTT angebunden. Die Werte umformatieren sowie die Werte umrechnen ist sehr aufwendig. Das liegt aber an meiner fehlenden Erfahrung und der sehr "lockeren" Doku über Variablentypen und Konversion von OH. Dieses Binding macht das auf jeden Fall einfacher und übersichtlicher. Jede Rule weniger in OH ist toll! Vielen Dank! PS: Beim Text Item "OutdoorWeatherSensorLastChange" soll die Textfarbe gemäß der Zeit seit der letzten Aktualisierung gesetzt werden. Das Binding gibt diese Zeit aber als Zeitstempel und nicht in Sekunden seit der letzten Aktualisierung aus (wie es das Bricklet selber eigentlich laut BrickViewer tut.) Deswegen kann das so noch nicht funktionieren. PS: Habe heute morgen OpenHAB neu gestartet. Nun flirrt diese Meldung durch die Logs, obwohl alles funktioniert ... ==> /var/log/openhab2/openhab.log <== 2020-02-21 09:42:17.959 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed. 2020-02-21 09:42:17.966 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed. 2020-02-21 09:42:18.961 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed. 2020-02-21 09:42:18.967 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed. 2020-02-21 09:42:19.962 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed. 2020-02-21 09:42:19.969 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed. 2020-02-21 09:42:20.963 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed. 2020-02-21 09:42:20.970 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BrickletOutdoorWeatherHandler of thing tinkerforge:brickletoutdoorweather:Es8 tried accessing its bridge although the handler was already disposed.
  13. Hallo riro ich habe das Outdoor Weather Bicklet gemeinsam mit dem TH-6148 Sensor von Tinkerforge im Einsatz. Der Sensor liefert Temperatur & relative Luftfeuchte und einen String wann der letzte Datensatz empfangen wurde. Wenn Du die Outdoor Weather Station hast, dürfte das vorgehen ähnlich sein, nur dass diese mehr Daten übermittelt als der TH-6148 Sensor. Als erstes muss Du den Sensor Identifier (für den TH-6148) oder den Station Identifier (für die WS-6147) ermitteln. Das kannst Du über den Brickviewer oder du legt ein entsprechendes „String-Item“ mit dem passenden Channel des Outdoor Weather bricklet an. Die benötigten Channel findest Du im Konfigurations-Menue des Outdoor Weather Brickelt (Thing) Es kann etwas dauern bis dir dann über das Sting-Item der passende Identifier angezeigt wird. Beispiel meines ITEM‘s zum auslesen der Sensoren ID Weiter mit anlegen/erzeugen des Sensor als „Thing“ Unter Paperui / Configuration / Thing, analog als ob du einen weitern Thinkerforge Dämon anlegen willst („MANUALLY ADD THING“) Hier werden dir alle möglichen Thing-Optionen des Tinkerforge-Binding aufgelistet. (siehe Bild unten) Wenn Du wie ich den TH-6148 Sensor hast, wähle diesen aus. Über das folgende Menü kannst Du nun die Grundkonfiguration des Sensor ausführen. 1) unter Bride Selection / Select a Bridge >> „brickletoutdoorweather ….“ auswählen 2) unter Configuration Parameter die ID des Sensor eintragen 3) speicher und schon wirst du ein neues Thing unter Configuration finden. Wenn Du nur Temperatur / Humidity / Last Change Daten haben möchtest benötigst Du keine Action da reichen entsprechende ITEM-Channel Verlinkungen in der ITEM Datei aus. Beim TH 6148 Sensor gibt es etwas zu beachten. Nach einem Batterie Tausch erzeugt er eine neu ID (gibt hierzu einen Post von Erik), und diese musst du dann über das „Konfiguraion‘s Menue“ des Thing TH-6148 anpassen (siehe oben Punkt2). An den rules oder der Item-Channel-Verlinkung musst Du nichts anpassen. Ich hoffe diese mini Anleitung hilft Dir viele Grüsse Stefan
  14. Hello Has anyone a solution to use the NFC reader bricklet outside ? I do not want to use a standard grey box, i'm looking for something visually more appealing but that can reside outside in the heat, dust, rain, snow,..
  15. OK, ich versteh dafür dein Problem nicht. Daten können einfach auf die SD geschrieben werden oder bei Bedarf auf einen externen Speicher.
  16. Hallo Forum, habe den Thread gelesen und vielleicht einen Link zu einer Anleitung übersehen. 🙂 Ich würde gerne das Outdoor Weather Bricklet in Betrieb nehmen. Anhand den Beispielen von anderen Bricklets erahne ich wie das geht. Bevor ich Stunden lang rumprobiere hier meine Frage: Hat jemand das Outdoor Weather Bricklet in Betrieb genommen und könnte seine items für OH hier posten? (Das Bricklet ist im Paper UI schon online. Es wird sich wohl um diese Actions drehen: brickletOutdoorWeatherGetStationData, brickletOutdoorWeatherGetSensorData). Dankeschön!
  17. Hallo zusammen, ich soll Sensordaten vom RED-Brick persistieren. Kann mir da wer weiterhelfen? Ich stehe gerade voll auf dem Schlauch.//Edit hat sich erledigt: package com.company; import com.tinkerforge.IPConnection; import com.tinkerforge.BrickletAccelerometer; import java.io.*; public class Main { private static final String HOST = "localhost"; private static final int PORT = 4223; // Change XYZ to the UID of your Accelerometer Bricklet private static final String UID = "Cge"; // Note: To make the example code cleaner we do not handle exceptions. Exceptions // you might normally want to catch are described in the documentation public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); // Create IP connection BrickletAccelerometer a = new BrickletAccelerometer(UID, ipcon); // Create device object ipcon.connect(HOST, PORT); // Connect to brickd // Don't use device before ipcon is connected // Add acceleration listener a.addAccelerationListener(new BrickletAccelerometer.AccelerationListener() { public void acceleration(short x, short y, short z) { PrintWriter outputfile = null; try { outputfile = new PrintWriter((new BufferedWriter(new FileWriter("Beschleunigung.txt",true)))); //replace your System.out.print("your output"); outputfile.println(+x/1000.0+";"+y/1000.0+";"+z/1000.0+";"); outputfile.println(""); }catch (IOException ioe) { ioe.printStackTrace(); }finally { if (outputfile != null){ outputfile.flush(); outputfile.close(); } } } }); // Set period for acceleration callback to 1s (1000ms) // Note: The acceleration callback is only called every second // if the acceleration has changed since the last call! a.setAccelerationCallbackPeriod(1000); System.out.println("Press key to exit"); System.in.read(); ipcon.disconnect(); } }
  18. Hallo Erik ich habe jetzt auf Basis Deines Vorschlag bezüglich „Thing-Status“ meine StartUp-Rules umgebaut. Es hat sich einfach umsetzen lassen 🙂 Meine Rule reagieren jetzt auf Zustands-Änderungen von >> Thing Bricklet >> Thing Masterbrick >> Thing Dämon Es klappt sowohl der Thing Trigger um eine Rule zu aktivieren, als auch die Status-Abfrage mit „getThingStatusInfo“. Mit Deiner Vorgehensweise ist man viel flexibler und kann individueller auf „Ausfälle“ und "Ladezeiten" (beim StartUp) reagieren. Ich ziehe offizielle meine Anfrage nach einer Dämon Initialisierung-Channel zurück 🙂 Weiter mit meiner „Temperatur Mess-Differenz“ Problematik Ich habe jetzt die beiden TH-6148 und das Humidity 2.0 über die letzten Tage verschiedenen Temperaturen ausgesetzt (15 Messzeitpunkte). Die Temperatur-Differenz ist nicht linear und ich kann keine kläre Linie erkennen. Der Unterschied liegt zwischen 0 und 1,5 Grad. Hintergrund meiner Frage: Ich berechne mit den Messwerten (Temperatur / relative Luftfeuchte) die absolute Luftfeuchte innen/außen und eine Rule steuert darüber das Lüftungsverhalten. In meiner Rule habe ich eine Messtoleranz (innen/außen Sensor) von 2,5% berücksichtigt. Kannst Du sagen welche Sensoren-Typen genauer sind, ich vermute mal der Humidity 2.0, oder ? Viele Grüße Stefan
  19. Hallo Hat sich eigentlich mit dem Update der Bosch Software (BSEC) auf v1.4.7.4 eigentlich was geändert/verbessert? Gruß Raphael
  20. Hallo Erik ich glaub ich hab das ganze viel zu kompliziert erklärt. Dein Vorschlag ist wesentlich eleganter als mein ursprüngliches Ansinnen. Ich wollte einfach nur verhindern, dass während der Hochlauf-Phase viele Fehlermeldungen produziert werden und gleichzeitig meine „brute-force“ Lösung mit dem Wait-Timer nicht mehr benötigt wird. Deine Idee gefällt mir echt gut, ich werde Sie am Wochenende mal in den Rules mit Action versuchen einzubauen. Eigentlich könntest Du das mit dem Dämon Initialisierungs-Channel jetzt schon von Deiner To-Do Liste streichen, denn Dein Vorschlag gefällt mir viel besser als mein Ursprungs-Gedanke. Zum neuen Binding B18 Bis jetzt habe ich keine Error‘s im Log gefunden. Es gab nur eine Warn-Meldung, die aber unkritisch ist Einen TimeOut des Dämon hab ich bis jetzt auch noch keinen gesehen, nachdem der letzte Reboot aber erst gut 24 Stunden her ist, werde ich das Thema noch weiter beobachten. Zum Thema Mess-Unterschiede Humidity Bricklet vs TH-6841, ich hab meinen zweiten TH-6841 neben das Humidity Bricklet gelegt, muss aber noch abwarten bis sich dieser an die Raumtemperatur angepasst hat (war bis eben noch im Kühlschrank 😉 ) Viele Grüße Stefan
  21. Hm das robust zu bauen ist schwierig. Ich würde bei deinem Humidity+LCD-Beispiel folgendes versuchen: Ein Switch-Item, das du mit einer Rule schaltest, wenn der Humidity-Threshold zu hoch ist oder wieder darunter fällt. Dann dazu eine Rule, die sowohl darauf reagiert, wenn das LCD initialisiert ist, als auch wenn das Humidity-Item schaltet und in der Regel mit der Thing-Status-Action als erstes prüft, ob das LCD online ist, und wenn nicht den Wert anzeigt: rule "LCD-Humidity" when Thing <LCD-UID> changed from INITIALIZING to ONLINE or Item <humidity-threshold-item> changed then var thingStatusInfo = getThingStatusInfo("lcd-uid") if ((thingStatusInfo == null) || (thingStatusInfo.getStatus().toString() != "ONLINE")) { return } //lcd-actions holen, wert anzeigen end Vorteil ist, dass du dann sofort einen aktuellen Wert auf dem LCD bekommst, wenn es online ist (oder wieder neu online kommt weil die Verbindung kurz weg war, oder Stromausfall oder was auch immer), aber die Rule auch nur dann läuft. Das ist natürlich je nach Menge der Bricklets relativ viel Rule-Code den du schreiben/kopieren musst.
  22. Hallo Erik zu Deiner Frage: wie formuliere ich meinen Gedanken am besten. Eigentlich wollte ich nur so eine Art „Statusmeldung“ dass der Dämon nach einem „Neustart/Reboot“ seinen Startup Prozess abgearbeitet hat. Beispiel: Das Humidity-Bricklet 2.0 ist über Dämon-A (z.B. WIFI) angebunden und liefert sehr früh nach einem Startup schon Daten. Die zugehörige Rule soll ab einem Schwellwert auf dem LCD128x64 Daten ausgeben. Das LCD128x64 ist über Dämon-B angebunden (z.B. Masterbrick per USB angeschlossen). In der Hochlaufphase kommt es vor, dass Dämon-A schon fertig alle Komponenten initialisiert hat, und dessen Brickles schon Daten lieferten, während Dämon-B noch beim initialisieren ist (da dieser für mehr Bricklets zuständig ist). Folge ist, dass Unmengen an Fehlermeldungen durch die Rules in das Log geschrieben werden. Ein ähnliches Problem hatte und habe ich auch bei meiner Openhab1 Konfiguration (ca 15 TF Komponenten ). Um diesen „Log-Spam“ zu umgehen und die Lesbarkeit des Log zu erhalten, habe ich damals (openhab1) einfach eine Timer-Rule eingebaut, die 60 Sekunden nach der „System Started“ Meldung ein ITEM mit Namen „SystemOnline“ vom Typ CONTACT auf Closed gesetzt hat. Alle anderen Rule‘s fragten ab, ob „SystemOnline“ den Status CLOSED hat und nur wenn dieses den Status CLOSED hatte, durften die Rules „loslegen“. Mit dieser Regel konnte ich zwar den Log-Spam beseitigen, aber gerade während der Test-Phase hat dies zu laaaaaaaangen Wartezeiten geführt. Bei meiner Frage an Dich, war mein Hintergedanken diese statischen langen Wartezeiten durch den Timer verhindern zu können, in dem das Binding melden würden, wenn es seine Startup Routine abgearbeitet hat. Deine Idee auf den Thing-Status zur reagieren, finde ich aber echt gut. Beispiel wie ich meine Rule‘s „warte bis der TF-Dämon den Init-Lauf abgeschlossen hat“ aufbauen würde. (so ähnlich funktioniert es mit meiner Timer-Rule in openhab1). Mein Gedanke hat allerdings einen Haken. Die Rückmeldung des Binding darf nicht auf die Vollständigkeit der Komponenten mit Status-Online ausgelegt sein, sondern darf nur melden dass der Initialisierungs-Prozess durchgelaufen ist, auch wenn Komponenten „offline“ sind. Beispiel: Ein Dämon kennt ein Bricklet das über eine Masterbrick der per RS485 Extention an den Masterbrick der per USB an das System angeschlossen ist. Wenn nach einem Reboot die Spannungsversorgung des „abgesetzten Masterbrick-Stapel“ nicht mehr funktioniert und der Dämon nur eine Meldung absetzten würde wenn alle Bricklets die er kannte und kennt online sind, würde es bedeuten dass obige Rule „Rückmeldung Dämon Init ausgeführt“ erst aktiv wird, wenn ALLE Komponenten wieder online sind. Somit würden alle Rule‘s die diese positive Rückmeldung benötigen, auf ewig inaktiv bleiben. Da stellt sich die Frage, was und wann soll der Dämon nun melden ? Ich bin mir jetzt echt nicht sicher ob Dein Vorschlag in der Hochlauf-Phase auf die Online-Meldungen der Bricklets zu reagieren nicht sinnvoller wäre. Das ist jetzt viel Text zu lesen, ich wusste aber nicht wie ich es (Inklusive der möglichen Probleme) beschreiben soll. Viele Grüße Stefan
  23. Moin, 0.1 ist defintiv nicht hoch. Alles über dem Default von 1 hätte ich verstanden, so ists seltsam. Hast du eventuell ein drittes Thermometer, mit dem du messen kannst? Vielleicht liegt es ja garnicht am Humidity Bricklet, sondern an dem TH-6841. Zu der RemoteSwitchActions-Sache: Da habe ich wohl nach dem Testen noch einen Bug eingebaut. Die Bricklets haben eigene Actions, der RemoteSwitchHandler meldet aber openHAB, dass sie nur die DefaultActions (also nichts) unterstützen. Der Fix kommt in die nächste Beta, sorry dafür. Nur aus Interesse und damit ich weiß wie ich das eventuell modelliere: Was würdest du in Rules laufen lassen, die beim ersten Initialisieren vom Binding ausgeführt werden, aber nicht, wenn sich ein Device neu initialisiert?
  24. Gerade mit der Beta 18 und einem Remote Switch Bricklet V1 getestet: funktioniert einwandfrei. Allerbesten Dank. Dann kann ich jetzt bald mein Produktionssystem auf das neue Tinkerforge Binding umstellen .... 😀
  25. Hallo Erik ich habe soweit meine Test-Rules angepasst. Jetzt kommen nach dem System Reboot keine Fehlermeldungen mehr. Nach dem der System-based trigger „System startet“ meldet, läuft ein Timer an der nach 60 sec das Item „Online“ vom Typ Contact auf Closed setzt. Alle relevanten Rules prüfen nun ab, ob das ITEM Online den Status Closed hat. Nur dann dürfen sie los legen. Um keine „Error-Meldungen“ zu verpassen, habe ich noch das Add-ON „LogReader“ eingebunden und konfiguriert. Wenn eine neue Error-Meldung im Log erscheint gibt der Piezo Speaker einen kurzen Beep ab. Ich muss mal schauen dass ich auch die "offline-Meldungen" für den Dämon mit erfasse (aktuell werden nur "ERROR" berücksichtigt). Zum Thema Temperatur Mess-Differenz zwischen HumidityBricklet 2.0 und Sensor TH-6841 Ja das Humidity-Bricklet gibt die um ca 1.2 Grad höher Temperatur als der TH-6841 Sensor aus. Frage, was verstehst Du unter „hohen“ Sampel Rate ? Ich habe aktuell eine SampeRate von 0.1 und eine „Temperatur Moving Average Length“ von 5. Zu Meiner Frage „Funksteckdosen Fernbedienung“ für Rule Steuerung nutzen. Nachdem ich sah, dass beim betätigen der Fernbedienung im Log erscheint, wollte ich die Daten per Action „brickletRemoteSwitchV2GetRemoteStatusA“ auslesen. Meine Rule sieht wie folgt aus: leider funktioniert die Rule nicht. Siehe Fehlermeldung in Line 228 steht Ich weiß leider auch nicht wo mein Fehler liegt. Zu Deinem Vorschlag Das habe ich noch nicht probiert, ich denke dann müsste ich aber alle relevanten Bricklet auf diese Weise in einer Rule abfragen und über eine "Merker-Varialben / Item" den Status vorhalten. Das muss ich mal testen, ob ich damit in den Rules klar komme. Deutlich einfacher wäre es wenn diese über den Dämon gemeldet wird 😉 Ich werde das mal auf meine Wochenende Test-To-Do Liste setzten Viele Grüße Stefan P.S Die Log-Meldungen kann ich erst heute Abend in aller Ruhe kontrollieren
  26. Anschlussfrage zu dem Initialisierungs-Channel: Würde es nicht reichen, wenn du in den Rules Thing-basierte Trigger benutzt? Zum Beispiel: Thing "tinkerforge:brickletrgbledbutton:Enx" changed from INITIALIZING to ONLINE Das sollte sowohl mit dem Brick Daemon, als auch mit den eigentlichen Devices funktionieren und hat den Vorteil, dass es auch passiert, wenn die Verbindung verloren ging und neu aufgebaut wurde. Also wenn du z.B. einen RGB LED Button hast, der immer eine Farbe haben soll, wenn gerade nichts anderes los ist, kannst du den Trigger benutzen um die Farbe zu setzen. Dann repariert sich das auch, wenn du das Bricklet (oder den ganzen Stack) vom Strom trennst und wieder anschließt.
  27. Moin Das geht nur über eine Rule, du kannst aber (z.b.) ein Switch-Item anlegen, dass du über die Rule steuerst, und das dann normal an Channels koppeln oder in anderen Rules verwenden. 1,2°C heißt, dass das Humidity Bricklet wärmer misst als der TH-6148? Dann liegt es eventuell an der eingestellten Sample Rate des Humidity Bricklets. Wenn die zu hoch ist, heizt es sich selbst auf. Das geht, ich setze es mal auf die TODO-Liste. Was ich übrigens vergessen hatte zu erwähnen: Die Elektroden der Multi Touch Bricklets sind jetzt wieder state-basierte Channel, d.h. du musst wieder Items anlegen, wenn du in Regeln auf sie reagieren willst. Aufgrund der Art und Weise wie die Java-API intern funktioniert, bekomme ich das nicht sauber auf Trigger-Channel gemappt.
  1. Load more activity
×
×
  • Create New...