rtrbt

Bei der E-Paper-Regel fehlt noch ein draw()-Aufruf, so funktioniert es: val ePaper = getActions("tinkerforge", "tinkerforge:epaper296x128:8e8df7e6:Jn6") ePaper.fillDisplay(0) ePaper.drawText(0,0,9,1,0,"test") ePaper.draw() Das ist im Moment ungünstig dokumentiert, aber auch draw(Text/Box/Line) und fillDisplay schreiben nur in den Buffer, damit tatsächlich auf das Display gezeichnet wird muss immer draw() aufgerufen werden. Die Doku passe ich nachher mal an. Die LCD/IO16-Regel war etwas verwirrender, nachdem ich da mal rumgesucht habe, bin ich über diesen Post gestolpert. Da sieht man, dass [item].state dir eine Instanz von State gibt. Wenn die nicht in einen Zahltyp gecastet wird, klappen keine Vergleiche mit Zahlen. So funktioniert es bei mir: LCD128x64_text.sendCommand("1,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-") val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:8e8df7e6:H5r") H5r_EdgeCountPin0A0.sendCommand(REFRESH) if ((H5r_EdgeCountPin0A0.state as Number).intValue > 10) { if(null == ioActions) { logInfo("actions", "Actions not found, for io4v2") } else { logInfo("actions", "Actions found, for io4v2") ioActions.getEdgeCount(0, true) } } LCD128x64_text.sendCommand("2,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-") So wie die Regel da steht, hat sie aber noch ein anderes Problem: Der REFRESH ist asynchron, das heißt, du siehst bei den beiden Ausgaben immer den selben Wert, weil der aktualisierte noch nicht da ist, wenn das zweite LCD128x64_text.sendCommand passiert. Alternativ kannst du folgendes machen, dann verhält es sich eher so, wie man es erwartet: LCD128x64_text.sendCommand("1,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-") val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:8e8df7e6:H5r") if(ioActions === null) { logInfo("actions", "Actions not found, for io4v2") return } val currentEdgeCount = ioActions.getEdgeCount(0, false).get("count") as int if (currentEdgeCount > 10) { val currentEdgeCount = ioActions.getEdgeCount(0, true).get("count") as int } LCD128x64_text.sendCommand("2,0,fl-P0-in-G7y-" + currentEdgeCount + "-") H5r_EdgeCountPin0A0.sendCommand(REFRESH) Da sieht man auch gut, warum ich noch auf meiner TODO-Liste stehen habe, für Actions die nur einen Wert zurückgeben, den direkt rauszuführen und nicht über den Map<String, Object>-Ansatz zu gehen. Dann fällt das ganze ".get("count") as int" weg.

Hm das war ungünstig formuliert. Mit aktualisieren meinte ich, die JAR im Addons-Verzeichnis mit der neuen zu überschreiben. Also was ich mache ist (während openHAB läuft): Die JAR durch die neue ersetzen Warten bis im Log (log:tail) die Reinitialisierung durch ist. Das dauert typischerweise so 20 Sekunden. (Ich habe eine Regel, die eine LED auf Grün setzt wenn System started triggert, das ist alternativ auch ein guter Indikator) openHAB neustarten, wieder auf die grüne LED warten Das hilft typischerweise, ist aber etwas Cargo-Kultesk. Da die anderen Actions bei dir aber funktionieren, vermute ich, dass du nicht das Cachingproblem hast. Das ist auch so. Was ich meinte ist, dass du in deiner ursprünglichen Regel die Action mit false aufgerufen hast, was dir den aktuellen Wert gibt, mit dem hast du dann aber nichts gemacht, deshalb hast du keine Änderung gesehen. Es gibt da 4 sinnvolle Varianten was du in einer Rule machen kannst: ioActions.getEdgeCount(0, true): Das setzt den Zähler zurück, den aktuellen Wert verlierst du dabei. val x = ioActions.getEdgeCount(0, true): Das setzt den Zähler zurück, den alten Wert hast du dann in x und kannst irgendwas damit anfangen. val x = ioActions.getEdgeCount(0, true): Das setzt den Zähler nicht zurück, den alten Wert hast du dann in x und kannst irgendwas damit anfangen. Pin0IO4V2Count.sendCommand(REFRESH): Das aktualisiert den Zähler in openHAB, du hast aber nicht den Wert sofort zur Hand. Damit kannst du aber natürlich eine separate Regel triggern, die auf den Channel-Wert reagiert. Mit ioActions.getEdgeCount(0, true) fragst du nur den Wert ab und verlierst ihn dann, der Zähler wird aber nicht zurückgesetzt, deshalb passiert dann nichts. Perspektivisch kannst du dir das ganze Refreshen aber sparen, dass muss ich sowieso für Werte, die sich nicht automatisch aktualisieren, allgemein lösen, damit wird der Edge Counter dann auch erschlagen. Die Bearbeiten-Funktion des Forums war tatsächlich seltsam, die Standardkonfiguration ist wohl, dass man nur 5 Minuten lang den letzten Post bearbeiten darf. Das habe ich mal geändert. Die LCD/E-Paper-Regeln teste ich mal und melde mich nochmal, eigentlich sehen die funktional aus. Edit: Bei den val x = ioActions.getEdgeCount()-Geschichten muss noch .get("count") as int hinten dran, siehe den nächsten Post

Moin, Das klingt, als ob die Kamera etwas aus ihrem Sockel gerutscht ist. Hilft es, wenn du die Kamera (vorsichtig) wieder in den Sockel drückst?

Moin, Benutzt du die Beta-Version der offiziellen Bindings aus diesem Thread? Dann musst du in der PaperUI von Hand in entweder der Inbox oder Configuration->Things einen Brick Daemon hinzufügen. Die Adresse ist localhost, wenn du openHAB auf dem Raspberry Pi laufen lässt, ansonsten dessen IP-Adresse oder Hostname. Wenn du die von Theo geschriebenen Bindings benutzt, sollte das ähnlich funktionieren. Da müsstest du notfalls mal hier nachlesen oder nachfragen. Gruß, Erik

Moin, Die älteren Bricklets werden unterstützt, nur die Remote Switches fehlen noch (sind aber schon implementiert, kommen mit der nächsten Beta). Das kann ich noch nicht versprechen. Auf der TODO-Liste steht noch, rauszufinden wie ich den Code dafür umbauen müsste Eher nicht. Den AccessPoint-Modus kann man nur ausschalten, indem die ganze Wifi-Konfiguration geschrieben wird, das kostet aber wieder EEPROM-Schreibzyklen, deshalb habe ich das in openHAB nicht eingebaut. Extra API dafür einbauen ist auch nicht sinnvoll, weil man sich dann einen Haufen Probleme für andere Anwendungsfälle einhandelt. Die erste Fehlermeldung bekomme ich auch, das scheint aber nichts relevantes zu sein, die Rules funktionieren trotzdem. Die zweite ist wichtiger, openHAB scheint, wenn man die Bindings-JAR aktualisiert, Teile davon in irgendeinen Cache zu laden, der für die RuleEngine nicht korrekt bereinigt wird, nicht mal wenn openHAB neugestartet wird. Was bei mir zuverlässig hilft ist, die Bindings zu aktualisieren, während openHAB läuft und mit log:tail die Ausgabe zu verfolgen. Nach ~ 20 Sekunden tut sich im Log einiges, weil er die Bindings neugeladen hat, wenn du danach openHAB neustartest, läd er nur die neuen Bindings, danach sollte es funktionieren. Die sieht soweit korrekt aus. Ich gehe mal davon aus, dass das auf das selbe Problem wie oben zurückzuführen ist. So wie du die Action verwendest, fragst du den Edge Counter ab, aber das Ergebnis wird dann verworfen. Wenn du den Wert von openHAB aktualisieren willst, kannst du in der Rule [itemname].sendCommand(REFRESH) aufrufen, wobei [itemname] das EdgeCount-Item ist. Intern ruft das dann auch getEdgeCount(0, false) auf, schreibt das Ergebnis aber in das Item. Stimmt das ist hier egal. Da war ich nur verwirrt, weil ich davor irgendeine andere Sprache benutzt habe. Kein Problem, ist ja freiwillig Habe ich mal weitergegeben.

Ah ja, das funktioniert so nicht. Du kannst den Channel umkonfigurieren, sodass du bei jedem Refresh resettest, dann bekommst du immer relative Werte. Alternativ kannst du es so lassen und wenn du resetten willst in einer Rule val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:f80007d9:H4y") ioActions.getEdgeCount(0, true) aufrufen.

Am IO16 2.0 habe ich seit 16.09. nichts geändert, nur die Actions hinzugefügt. Was für eine Warnung bekommst du denn?

Beta 13 ist jetzt im Post oben. Der Generator kann jetzt Actions, das heißt, dass alle Geräte in Rules verwendet werden können. Genaueres steht im Readme und der Doku.

Moin, Einen Stack kannst Du nur entweder über USB oder Ethernet oder Wifi anschließen. Du kannst aber mit openHAB mehrere Stacks kontrollieren, indem Du mehrere Brick Daemons hinzufügst. Unterstützung für das E-Paper habe ich gestern eingebaut, kommt mit der nächsten Beta.

Moin, Es gibt im Brick Viewer noch keine explizite Rust-Unterstützung (das steht auf einer der zahlreichen TODO-Listen ), du kannst dein Binary aber als C/C++-Programm hochladen. Wenn du dann in Schritt 3 nicht den "Compile from Source"-Haken setzt, versucht der Brick Viewer nicht zu kompilieren, sondern nimmt das Binary so wie es ist.

Moin, wenn der Brick Viewer auf dem Raspberry Pi läuft, kannst du dich damit nach localhost verbinden. Das HAT sollte dann aufgeführt werden.

Moin, Das funktioniert leider noch nicht automatisch, da der Edge Count kein Callback hat, ich also den Getter benutzen muss. Der wird aber nur ausgeführt, wenn du dem Item ein Refresh-Command schickst. Solche Werte automatisch zu aktualisieren steht noch auf der TODO-Liste. Nur das I0-4 V2 erzeugt eine Fehlermeldung (die IO-16 V1 / V2 nicht) Was mache ich falsch ? Das sollte sendCommand sein, beim Rotary Encoder 2.0 auch. Ist dies Absicht ? Technisch gesehen ja. Das ist der Mechanismus, der prüft ob die Verbindung noch besteht. Die Meldungen hatte ich aber nur testweise auf INFO gesetzt, das sollte eigentlich DEBUG sein, damit es beim normalen Log-Level nicht die Ausgabe überflutet. Repariere ich für die nächste Beta.

Moin, Beta 12 ist jetzt im Post oben. @Wannes: The 12th beta version should fix your wifi problems. The bindings now check periodically if a network connection was lost and then try to reconnect. @StefanOHAN: In der neuen Version ist der Fix für dein IO16-Problem enthalten. Piezo Speaker kommt mit der nächsten Beta, das sollte aber schneller gehen als die letzte Den Speaker als Systemlautsprecher zu benutzen wird nicht gehen, da bräuchte man einen eigenen Treiber oder müsste eine openHAB-AudioSink schreiben.

Moin, Es gibt diverse Drucksensoren, die ein Einheitssignal ausgeben. Z.B. dieser hier, oder dieser. Auslesen kannst du ein Einheitssignal, wenn es ein Spannungssignal ist, mit dem Analog In Bricklet 3.0 oder für genauere Messungen mit dem Industrial Dual Analog In Bricklet 2.0, für Stromsignale mit dem Industrial Dual 0-20mA Bricklet 2.0.

Moin, Die Ethernet-Extension ist ein Brick Daemon, d.h. den musst du nicht auf der cRIO installieren, sondern kannst dich mit LabVIEW auf die IP-Adresse der Ethernet-Extension verbinden.

@Wannes: The problem with the WiFi Extension seems to be, that openHAB does not notice the lost connection caused by the restart of the stack. openHAB then still assumes, that the connection is established, but the Wifi Extension has no open connection because of the restart. Currently the Tinkerforge Protocol has no heartbeat mechanism, so to fix this, I have to query the device state periodically in the openHAB bindings (this will fail if the connection was lost) and then try to restablish lost connections. I think this fix will be in the next beta version. @StefanOHAN Das IO-16-Problem lag an einer fehlerhaften Konfiguration, die Getter, die openHAB für REFRESH-Commands verwenden sollte, hatte ich als Callback eingetragen, was dann später von den richtigen Callbacks überschrieben wurde. Deshalb funktionierte nur das initiale Abfragen des Zustands nicht, die Aktualisierungen aber schon. Brauchst du den Fix dringend oder reicht es, wenn ich den in die nächste Version packe? Bezüglich dem Piezo Speaker: Support dafür kommt auf jeden Fall noch, ich bin mir nur noch unschlüssig, wie ich den modelliere. Was wäre dein Anwendungsfall dafür/Welche Features hättest du gerne?

Nur, dass die Initialisierung mehr als 5 Sekunden gedauert hat. Ansich sollte das deutlich schneller gehen, was openHAB auch erwartet, deshalb die Warnung. Kannst du also ignorieren. Möglich. Das sehe ich mir nochmal an. Das kannst du ignorieren, die Bridge der Things ist der Brick Daemon. Aus irgendeinem Grund zeigt die PaperUI das dort aber nicht korrekt an, steht schon auf meiner TODO-Liste rauszufinden, was da kaputt ist. ich hatte meine Konfiguation wie unten eingestellt, bekam aber dennoch alle 10 sec einen Wert im Log Averaging Humidity Moving Average Length 20 Temperature Moving Average Length 20 Sample Rate 0.1 SPS hätte da nicht alle 200 Sekunden nur werte erscheinen dürfen ? Das ist etwas subtil, es gibt (ältere) Bricklets, bei denen wäre das so, da sie nicht einen gleitenden Mittelwert (= Moving Average) sondern einfach nur einen Mittelwert (= Average) ausgeben. Das Humidity berechnet aber einen gleitenden Mittelwert. Das heißt, dass das Bricklet die letzten "Moving Average Length" Werte speichert, bei dir also 20 pro Messwert und dann pro neuem Messwert, bei dir alle 10 Sekunden, den jeweils letzten Wert vergisst, den neuen dazu nimmt, den Durchschnitt berechnet und dann ausgibt. Dadurch hast du alle 10 Sekunden einen neuen Wert, der aber über die letzten 20 echten Messwerte geglättet wurde. Bezüglich der ganzen Dinge, die so aufgelaufen sind: Ich muss mich in der Firma gerade noch um ein paar andere Dinge kümmern, d.h. die nächste Beta wird vermutlich noch ein paar Tage dauern.

Das sehe ich mir mal an, sollte so nicht sein. one ist eine der "Einheitenlos"-Einheiten, wie auch z.B. Prozent oder PPM, das ist so korrekt. Ich kann aber mal nachsehen, ob man das nicht sinnvollerweise ganz ohne Einheit rausgibt. I was on vacation the last two weeks, but will take a look at this soon. Hatte ich, danke Das ist der (automatisch generierte) Name des Brick Daemons. D.h. wenn du dem Daemon beim Anlegen einen festen Namen gibst, sollten den alle Items als dritte Gruppe haben. Das sollte natürlich prinzipiell nicht notwendig sein, aber du kannst mit smarthome:send [itemname] REFRESH ein Refresh-Command schicken, dann sollte der Zustand aktualisiert werden. Das ist etwas seltsam, weil der HAT-Handler eigentlich nicht viel tut, aber wenn das Initialisieren klappt, sollte das kein Problem sein. Hast du die aktuelle Firmware (2.0.1) auf dem HAT? PS: Danke für die Urlaubsvertretung

Beta 11 ist jetzt im Post oben. Das LCD 128x64 hat jetzt einen Backlight-Channel. Außerdem können jetzt Decimal, Quantity oder PercentTypes in Channel gegeben werden, die Zahlen erwarten (wie z.b. den Backlight-Channel). Ich bin erstmal zwei Wochen im Urlaub, werde aber immer mal in den Thread sehen, falls Fragen auftauchen.

Der Sensor liefert alle 45 Sekunden Daten. Ich habe das mal an die Channel-Dokumentation angehangen. Da das Outdoor-Weather-Bricklet handgeschrieben ist, erscheint das aber noch nicht in meinem improvisierten Dokumentationsgenerator. Stimmt, der Channel will StringTypes, in Regeldateien brauchst du deshalb die Anführungszeichen. Hm, das sehe ich mir mal an, eigentlich sollte das ein Channel sein. Das könnte eventuell gehen. Rausfinden, ob ein Master Brick offline ist, ist nicht ganz trivial, aber da kann ich eventuell was bauen.

Beta 10 ist jetzt im Post oben.

Da ich habe beim Umbauen der Channelrekonfiguration eine Feinheit für Trigger-Channel übersehen, das wird mit Beta 10 (heute Nachmittag) wieder funktionieren. Nein, da das der Sensor selbst nicht meldet. Geplant ist, für das NFC-Bricklet die API für einfache Anwendungsfälle zu erweitern und dann mit openHAB diese API zu verwenden, da die aktuelle API zu komplex ist um sie abbilden zu können. Das wird aber noch eine Weile dauern.

Beta 9 mit Support für das Outdoor Weather Bricklet ist jetzt im Post oben.

Ah die Frage hatte ich übersehen. Du kannst ja beim Humidity Bricklet die Sample-Rate konfigurieren, wenn die wie bei dir auf 0.1 steht, dann misst das Bricklet alle 10 Sekunden. Damit weniger Rauschen auf den Daten ist, gibt das Bricklet aber nicht den Rohwert aus, sondern mittelt die letzten n Werte. Dieses n ist der Humidity Moving Average Length. Standardmäßig sind das 5, d.h. das Bricklet gibt den Durchschnitt über die letzten 5 Messwerte, also 50 Sekunden aus. Wenn du das Bricklet auf eine so niedrige Sample-Rate stellst, ist es vermutlich sinnvoll, die Durchschnittsberechnung abzuschalten (also den Moving Average auf 1 zu setzen), damit der Wert nicht ganz so träge ist.

Moin, Freut mich, dass so viel schon funktioniert. Danke nochmal für die rigorosen Tests [quote name="maxico 2019-09-23 21:49:42.792 [nt.ItemStatePredictedEvent] - RD9_MonoflopPin3 predicted to become TRIGGER "PredictedEvents" habe ich sonst keine. Ist das normal? Das ist ein "fancy new feature" wie es die openHAB-Entwickler hier nennen. Der Hintergrund ist wohl, dass openHAB vorhersagt, das Zustandsänderungen funktionieren werden, falls das entsprechende Thing nicht offline ist. Das wird hier genauer erklärt. Das muss ich mir nochmal genauer ansehen, ob das für alle Geräte eine gute Idee ist, oder ich es eventuell im Generator wegkonfiguriere. Ja, das ist egal. Hintergrund ist, dass ich ein StringItem mit CommandOptions benutze, da damit in der PaperUI Buttons erzeugt werden. Für Channel, bei denen es nur eine mögliche Aktion gibt ist mir dann aber egal, was der genaue Text ist, sobald ein Item reinkommt, löst die Aktion aus.