Jump to content

rtrbt

Administrators
  • Content Count

    230
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by rtrbt

  1. 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.
  2. 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?
  3. 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.
  4. 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.
  5. Moin, Beta 18 ist jetzt im Post oben. Es sollte damit nicht mehr nötig sein, Channels Refresh-Commands zu schicken. Falls das doch irgendwo noch hängt, bitte einmal Bescheid sagen. @StefanOHAN In der neuen Beta habe ich mehr Debug-Meldungen eingebaut, mit denen wir hoffentlich deinen Verbindungsproblemen auf den Grund gehen können. Außerdem habe ich noch ein paar Bugs in die Richtung behoben, vielleicht funktioniert es ja jetzt einfach. Lass das ganze bitte nochmal mit log:set TRACE org.eclipse.smarthome.binding.tinkerforge laufen. Gruß, Erik
  6. Moin, Weiter unten auf der Programmseite gibt es einen Logs-Abschnitt. Steht in den Logs etwas hilfreiches?
  7. Ja, zumindest die Auswirkungen davon: Da Timeouts auftreten können, während ein Device konfiguriert wird, muss ich, wenn ein Device wieder online geht, es neu konfigurieren. Das ist dann auch der Grund, weshalb bei dir das Backlight angeht. Das bekommst du dann in den Griff, indem du die Default-Helligkeit auf aus stellst und nur wieder an machst, wenn du es brauchst.
  8. Das kannst du ignorieren, die Ausgabe kommt, weil openHAB immer alle ChannelTypeProvider nach ChannelTypes fragt, selbst wenn die ChannelTypeUID offensichtlich nichts mit dem Binding zutun hat. Der TinkerforgeChannelTypeProvider (den ich für das dynamische Anlegen von Channels brauche) beschwert sich da nur, dass er mit dem system:rawbutton-Typ nichts anfangen kann, das ist ja einer von openHAB selbst. Bezüglich der Ausfälle: Ich vermute, dass das Binding da noch zu aggressiv ist, wenn mal einzelne Pakete verloren gehen. Das habe ich mal etwas entschärft, kommt mit der nächsten Beta. Interessant wäre, welche Bricklets du an den Master Bricks und dem HAT hast. Bei dem Aufbau meinst du, dass sowohl HAT als auch Master Brick am selben Raspberry Pi hängen? In den alten Versionen den Fehler zu suchen dürfte nichts bringen, das Verhalten habe ich sowieso mehrfach umgeworfen.
  9. Die Intenso ist die 8 GB große Karte? Ich habe hier leider keine 32GB Karte, aber habe es sicherheitshalber mit einer 64GB großen getestet und es funktionierte. So wie die Fehlermeldung aussieht, ist das bei dir vermutlich kein Problem mit der Größe: Die Fehler fliegen schon beim Initialisieren der Skripte, nicht beim Ausführen. Sowas kommt vor, wenn die Karte zu langsam ist, da der RED-Brick dann die ganze Zeit mit IO beschäftigt ist. Wenn das bei dir eine Class 10 Karte ist, sollte sie aber auf jeden Fall schnell genug sein. Das tritt eher bei Class 4 Karten auf. Ich halte es für am wahrscheinlichsten, dass deine Karte hinüber ist. Wenn du ganz verzweifelt bist, kannst du die Karte mal mit h2testw testen.
  10. Was ist das genau für eine Karte und was für eine Class hat sie?
  11. Sorry, deinen Post hatte ich übersehen. Was klappt dabei noch nicht? Die Command-Channels sind Strings statt Switches, da es keinen Rückkanal von den Steckdosen gibt: openHAB kann nicht abfragen, ob eine Dose gerade an oder aus ist, also kann ich bei einem Switch nicht den Initialzustand setzen. Command-Channels (die in der PaperUI Buttons erzeugen) sind intern String-Channels. Du kannst z.b. aus Rules StringCommands "ON" oder "OFF" schicken um die Dose zu schalten.
  12. Moin, Ich habe den RED-Brick hier mal getestet, aber alles hat funktioniert. Hast du den Austausch-Brick schon getestet? Viell stört da ja doch einfach irgendwas in der Umgebung drauf.
  13. Moin, Kannst du das Image nochmal mit Etcher schreiben, wie hier beschrieben? Eventuell ist das Image von Windiskimager nicht richtig geschrieben worden.
  14. Moin, Das ist der FirmwareProvider, der holt sich von downloads.tinkerforge.com die aktuellen Firmwareversionen ab und zeigt Updates an. Ich habe das bei mir auch gerade im Log, sehe ich mir mal an. Das null sollte eigentlich eine hilfreichere Fehlermeldung sein, aber da fliegt scheinbar eine Exception, die keine Nachricht hat. Benutzt du zum Auslesen dann den Channel? Falls ja, musst du aktuell immer mal REFRESH-Commands schicken, damit der Wert sich bewegt. Das liegt daran, dass ich die Elektroden jetzt als Trigger-Channel behandle, aber das Bricklet selbst nur ein Callback für alle Elektroden hat, dieses aber bei jeder Änderung auslöst. Da muss ich mir mal was einfallen lassen. Das sollte kein Problem sein, da die Callbacks alle nur auslösen sollten, wenn sich Werte ändern. Das kannst du z.B. mit einer Rule und einem time-based-trigger machen. Sehe ich mir nochmal an. Du kannst mal in der Karaf-Konsole log:set TRACE org.eclipse.smarthome.binding.tinkerforge ausführen. Dann sollten im Log alle 90 Sekunden solche Ausgaben erscheinen: [DEBUG] [rforge.internal.handler.DeviceHandler] - Checking reachability of 6esErP [DEBUG] [rforge.internal.handler.DeviceHandler] - Done checking reachability of 6esErP Falls da was schiefgeht kommen eventuell hilfreiche Informationen raus.
  15. Moin, Wir haben hier noch einen Brick, den können wir dir zuschicken. Falls du mehr brauchst: bei Mouser noch drei Stück. Der Nachfolger wird das Servo Bricklet, das ist gerade in Entwicklung. Das sieht dann so aus.
  16. Moin, Beta 17 ist jetzt im Post oben. Die Remote Switch Bricklets sind jetzt deutlich einfacher benutzbar: Es gibt, ähnlich wie beim Outdoor Weather Bricklet jetzt eigene Devices für die Typ-A bis C Dosen und Typ-B Dimmer, die auf die entsprechende Adresse usw. konfiguriert werden können. Der Handler stellt dabei automatisch sicher, dass immer nur ein Schaltvorgang gleichzeitig stattfindet. Das ganze funktioniert ohne Rules schreiben zu müssen, die Actions werden aber alle weiterhin unterstützt. Damit Rules einfacher zu schreiben sind, habe ich mal das Java-Typ-Schema umgebaut: Bisher hatte ich die Java-Bindings unverändert benutzt, weshalb für ältere Bricklets die Actions oft byte und short für Parameter und Rückgabewerte verwendet haben. Das habe ich rausgeschmissen, jetzt werden nur noch int und long verwendet. Das ist jetzt erstmal etwas verwirrend, da die Java-Doku nicht mehr passt, behebt sich dann aber wenn ich dazu komme einen richtigen openHAB-Doku-Generator zu schreiben. Für die Übergangszeit: alles was short oder byte war ist jetzt int, man kann aber in den Rules anscheinend auch einfach "as Number" casten, das sollte immer gehen. Die minimale Firmware-Version wird jetzt anhand der von den Bindings verwendeten Features gesetzt, das dürfte aber nicht auffallen, weil mit der Information im Moment nichts angefangen wird. Die Bindings sollten jetzt robuster sein, wenn die Verbindung zum Brick Daemon oft verloren geht, da fehlte eine Neuinitialisierung der Devices, weshalb dann manchmal Callbacks nicht mehr ankamen. @StefanOHAN Deine Rules sollten jetzt nicht mehr beim Initialisieren oder wenn die Verbindung wiederhergestellt wird triggern. Die IO16-Sache hatte ich hier nochmal getestet, das funktionierte. Ist das mit der neuen Beta bei dir noch kaputt? Gruß, Erik
  17. Moin, mit dem Dual Relay V2 meinst du das Industrial Dual Relay? Sehe ich mir mal an. Jupp Das geht mit allen 7-Pol-Bricklets. Nein, da kannst du die vollen 4 (also 2+2) Meter benutzen. Ja, und das hat gegenüber der Variante zwei Kabel zu schlachten den Vorteil, dass es wie ein Repeater wirkt, also das Signal aufgefrischt. Du kannst aber nicht, falls du noch längere Kabel brauchst, zwei Isolatoren hintereinander benutzen, das würde den Master Brick verwirren.
  18. Moin, Du hast da zwei unabhängige Probleme: 1. ist meine Reconnectlogik da anscheinend zu aggresiv, das muss ich mir nochmal ansehen. 2. versuche ich, wenn ein Device initialisiert wird, alle Channel in einen definierten Zustand zu bringen, indem ich ein REFRESH-Command schicke. Das sollte ich aber nur bei nicht-Trigger-Channels machen, damit es nicht so aussieht als gäbe es Zustandswechsel, die nicht wirklich da sind. Das habe ich hier gerade mal testweise eingebaut und es scheint zu funktionieren. Kommt in die nächste Beta.
  19. Moin, In den Bindings ist kein anderes Ausgabeformat vorgesehen, also kannst du das nicht einfach durch einen Kommandozeilenparameter ö.Ä. lösen. Ohne das ich mich jetzt mit ioBroker konkret auskenne: Warum ist es ein Problem JSON zu verarbeiten? Ich habe bei kurzem Suchen das hier gefunden. Andere Ausgabeformate wären schwierig, weil ja teilweise strukturierte Daten rausgegeben werden. Gruß, Erik
  20. Hm, bei den Callbacks war das noch anderweitig kaputt, sorry dafür! Die angehangene Variante sollte funktionieren. tinkerforge_perl_bindings_2_1_25.zip
  21. Eventuell. Versuche mal das wie hier beschrieben zu installieren. Alternativ kannst du den Tinkerforge-Ordner aus source/lib rauskopieren, neben das Beispiel legen und dann ganz oben im Beispiel use lib './'; einfügen. Dann sollte auf jeden Fall die lokale Variante benutzt werden.
  22. Moin, Teste mal bitte die angehangene Version der Bindings. tinkerforge_perl_bindings_2_1_25.zip
  23. Moin, Die IO-16-Geschichte sehe ich mir gleich nochmal an, das sollte eigentlich funktionieren (die letzten Worte des Informatikers ) Beim Piezo kannst du die getAlarm-Action benutzen, die gibt nicht nur die Gesamt-Duration des aktuellen Alarms zurück, sondern auch durationRemaining, also wie lange der aktuelle Alarm noch läuft (falls einer läuft).
  24. Moin, @StefanOHAN Hm, die fehlt. Mir ist dabei ein strukturelles Problem aufgefallen: Eigentlich sind nur die Teile der Java-API als Actions rausgeführt, die den Zustand des Bricks/Bricklets nicht ändern (mit Ausnahme einiger Bricklets wie z.b. der Remote-Switches, die nicht gut auf das Channel-Modell mappen), damit nicht die openHAB-Sicht des Bricklets und der tatsächliche Zustand auseinanderlaufen. Ich hatte jetzt den Gedanken, dass ich Actions, die den Zustand ändern erlauben kann, wenn ich im Generator hinterlege, welche Channels dann aktualisiert werden müssen. Da muss ich die API nochmal durchgehen, aber in dem Zuge wird dann die getEdgeCount-Action kommen. Das liegt daran, dass ich im Moment die Java-Bindings unverändert benutze. Die wiederum haben aus Legacy-Gründen bei älteren Bricklets andere Parameter- und Rückgabetypen. Die IO-16 gibt dir da einen Short (also eine 16-Bit-Zahl) zurück. Wenn du das so machst: val currentEdgeCountIO16V1 = ioActions16v1.brickletIO16GetEdgeCount(0, false).get("count") as short sollte es eigentlich funktionieren. Ist PiezoAlarm das Item mit dem du den Alarm-Channel benutzt? Dann passiert in deiner Rule folgendes: Du schickst das Command an den Alarm-Channel, das ist etwas langsam, weil die Nachricht einmal quer durch openHAB muss. Direkt danach startest du einen weiteren Alarm von Hand (die Action heißt zwar SetAlarm, aber konfiguriert nicht nur, sondern löst den Alarm auch direkt aus). Das geht schneller, weil die Action direkt an die Java-Bindings gekoppelt ist. Der zweite Alarm geht jetzt los, danach kommt das Command am Channel an, der intern auch SetAlarm benutzt und damit den Alarm aus deiner Rule überschreibt. Stimmt, da ist die Modellierung nicht gut: Das ist im Moment ein normaler Channel mit State pro Elektrode, mit dem Switch-Typ. Sinnvoller ist ein Trigger-Channel. Das konfiguriere ich mal um. @omiT Das sind die LEDs die auf dem Bricklet verbaut sind. Du kannst da Zahlen bis 255 reingeben, dann leuchten die LEDs entsprechend hell. Ich baue eventuell noch ein, dass auch PercentType-Kommandos akzeptiert werden, dann kann ich das in der PaperUI schöner anzeigen. Mal wieder danke für's Testen! Erik
×
×
  • Create New...