MacDuff

sollte im großen und ganzen funktionieren, außer wenn du python-features verwendest hast, die in 3.5.3 noch nicht implementiert waren - zb f-strings (f'{variable}'). das kann nicht klappen, da müsstest du auf eine ältere art von stringformatierung ausweichen. wie man in spyder bestimmte python-versionen auswählt, weiß ich nicht. md

ja genau, so haut es hin. danke. mit drei zeilen in der python-app kann man sich den manuellen start der MQTT-Bindings sparen: import subprocess mqtt_exec = 'C:/Python39/Scripts/tinkerforge_mqtt.bat' subprocess.Popen([mqtt_exec, '--broker-host=192.168.20.42']) md

danke erstmal. ich starte also die mqtt-bindings (bei mir in c:/python39/scripts, ebenso das angepasste bat-file). das nimmt allerdings keine kommandozeilen-parameter an und liefert nur die message: "Starting TF MQTT bindings 2.0.15" - und dann nix mehr. ich kann also broker usw nicht definieren... und deswegen komme ich wohl mit den beispielen nicht weiter. EDIT: ich kann die Bindings so starten: python.exe tinkerforge_mqtt --broker-host '192.168.20.42', dann funktioniert es. stimmt was mit den .bat nicht? Sieht so aus: @"C:\Python39\python.exe" "C:\Python39\Scripts\tinkerforge_mqtt" merci, md

tinkerforge, openhab3, paho-mqtt und meine python-scripts funktionieren prima zusammen. jetzt wollte ich die mqtt-bindings näher unterrsuchen - die direkte ansprache von bricklets etc per publish/subscribe sieht schon ganz attraktiv aus - aber ehrlich gesagt, ich versteh bei der sache bloß bahnhof. wie, wenn überhaupt, krieg ich das mit meinen python-programmen zusammen? kann mich da bitte jemand aufs richtige gleis setzen? danke. md

Ich würde gerne von dem auf dem Red-Brick-Image 1.15 verfügbaren Python 3.5.3 auf Python 3.8 aktualisieren -- auch was die Versionsauswahl im "New Program"-Wizard betrifft (Step 3). Mit gewisser Mühe habe ich Python 3.8.6 auf dem Red Brick installiert, aber wie kriege ich das hin, dass diese aktuelle Version im Wizard neben 2.7.13 und 3.5.3 angeboten wird? Andernfalls wünsche ich mir ein Red-Brick-Image, das Python3 in einer Version >= 3.6 bringt... f-Strings und aktuelles Pandas brauchen mindestens diese Version. md

Ich kann da sekundieren: meine kleine App, die Abfahrtszeiten von Bussen an verschiedenen Haltestelle anzeigen soll, habe ich mit dem LCD 128/64 realisiert. 6 Tabs, 6 Haltestellen. Ob nach 12, 24, 48 h -- irgendwann jedenfalls kann ich nicht mehr die Abfrage wechseln: Die Tabs springen zwar um, aber offenbar schlägt das nicht auf die App durch, weil die Abfahrtszeiten nicht mehr entsprechend aktualisiert werden. Hilft nur ein Neustart. md

@ StefanOHAN Danke für den Tipp. Es macht tatsächlich einen Unterschied, ob Item-Namen nur Großbuchstaben sind oder nicht. Die Doku ist ungenau: "Every word of the Item name starts with an uppercase letter" -- und auch das ist nur eine "recommendation". Sie geben sogar das Beispiel: "Names that reoccur frequently, such as the names of rooms or appliances, may be abbreviated to reduce overall name length. (Example: Bathroom = BR)" Und damit hätte man sich wohl ins Knie geschossen... Versuch & Irrtum... md

Ich probiere nun auch die 2.5 Bindings -- mit gemischten Resultaten. Nach vollständigem Start von openhab (auf einem Jetson Nano) soll eine Meldung auf dem LCD20x4 erscheinen: rule "STARTUP" when System started then logInfo("System Startup", "now") LCDBacklight.sendCommand(ON) LCD.sendCommand("1,1, OpenHab started") end LCD und Backlight sind als Items so definiert: String LCD "LCD" (t47, tinkerforge){channel="tinkerforge:lcd20x4:71e71e18:rXd:LCD20x4Text"} Switch LCDBacklight "LCDBacklight" (t47, tinkerforge) {channel="tinkerforge:lcd20x4:71e71e18:rXd:LCD20x4Backlight"} Das Backlight kann ich im PaperUI Control ein-/ausschalten; auch über den Switch im Basic UI. Den gewünschten Effekte beim Hochfahren des Maschinchens hatte ich bisher nur zweimal (von vielleicht zwei Dutzend Versuchen.) Auch das Beschreiben des LCDs ist in anderen Konstellationen fehlgeschlagen. Ah ja, und öfters heißt es bei den TF-Komponenten "OFFLINE-BRIDGE_OFFLINE". Was ist hier faul? merci, macduff

ich hab das mal mit einem kleinen usb-hub realisiert...

nach schneller durchsicht fiel mir das auf: if Hühner_Stall.ipcon != None: Hühner_Stall.ipcon.disconnect() kann es sein, dass hier (z 239) deine ip connection verfrüht und fälschlich gekappt wird, weil du statt "==" irrtümlich "!=" getippt hast? md

Danke -- das ging gut bis: git reset --hard brickd-2.4.0 worauf folgte: fatal: ambiguous argument 'brickd-2.4.0': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' Hab ich mal ignoriert und weiter probiert. Das cd .. aus /src heraus ist glaub ich nicht nötig, denn das file build_pkg.py ist in /src. pm-utils musste ich nachinstallieren, danach lief es glatt. brickd.conf ist in /etc und die Version meldet korrekt mit 2.4.0., Brick Viewer läuft und zeigt angeschlossene Bricks/Bricklets. Die Sache ist nämlich die, dass der Desktop vom Jetson Nano soviel Speicher frisst, dass man jede halbwegs anspruchsvolle KI-App vergessen kann. Für visuelle und andere Interaktion kann ich jetzt TF-Komponenten (20x4 LCD zB) benutzen. Danke nochmal, macduff

Ich wollte das Jetson Nano Developer Kit (kleine KI-Maschine mit Quadcore ARM A57 CPU und NVidia GPU + adaptiertes Ubuntu Linux) mit TF-Komponenten kombinieren, bin aber an der Installation des Brick Daemon gescheitert: dpkg: Fehler beim Bearbeiten des Archivs brickd_linux_latest_armhf.deb (--install): Paket-Architektur (armhf) passt nicht zum System (arm64) Fehler traten auf beim Bearbeiten von: brickd_linux_latest_armhf.deb Gibt es vielleicht doch noch eine Möglichkeit? danke, md

Danke - es funktioniert nun mit: Desktop Einvironment aktiviert + app = QApplication() oder Desktop deaktiviert + app = QCoreApplication QApplication ist für Anwendungen mit GUI, QCoreApplication für Konsolenanwendungen ohne GUI Ich versteh allerdings nicht das "Desktop"-Konzept. Könnte man das evtl in der Doku präzisieren? Ist GUI == Desktop? Beim LCD128x64 ist ja auch die Rede von "GUI"... macduff

Ich baue mir gerade einen kleinen Info-Screen mit dem LCD 128*64 (Air Quality, Abfahrtszeiten des Busses vor meiner Haustüre). Wegen Letzterem läuft es in einer PyQt-Schleife, damit ich den bequemen QTimer nutzen kann, sowie Pyqtsignals - und auf dem Windows-Rechner ist auch alles ok. Sobald ich die App auf dem RED starte bricht es jedoch ab, mit der Meldung: "QXcbConnection: Could not connect to display" Das kleine LCD qualifiziert ja wohl nicht als GUI-Display im Sinne einer GUI-App, oder? Hab's dennoch im Environment mal als DISPLAY :0 und :1 angemeldet, ging trotzdem nicht. Eine frühere Version meiner App (ebenfalls mit PyQt-Timer) auf dem LCD20*4 lief problemlos. Qt bzw PyQt auf dem RED (1.13) sind auf 5.7 bzw 5.7.1 upgedatet (auf dem Win-Rechner 5.12). Nebenbei: Ich hatte mich schon so an die f-Strings gewöhnt, die ab Python 3.6 funktionieren... Leider war ich total erfolglos, das 3.5.3 auf dem Brick auf 3.6+ zu bringen - scheint in den Debian repositories nicht zu existieren? Hoffentlich kann jemand weiterhelfen... macduff

da muss ich auch passen... md

Ich habe letztens mit buildozer/kivy gearbeitet - ganz schön tricky. hast du in der buildozer.spec (application requirements) die tinkerforge-module deklariert? es gibt auch einen abschnitt # (str) Android logcat filters to use android.logcat_filters = *:S python:D darin, den du aktvieren solltest. dann bekommst du beim debug eine exakte auskunft, an welcher stelle genau und warum dein programm abstürzt. -md

Danke, so funktioniert es. Mein Setup ist ein Red, auf dem OHA2 läuft, und eine separate Bedienungs- und Display-Einheit mit LCD20x4, MultiTouch-Bricklet mit Keypad und ein AmbientLightV2. Die Einheit wird über eine WIFI2.0-Extension angesprochen. Anfangs hatte ich den Red via EthernetPoE 1.0 und PowerLan im Netz - da kam es zu ständigen Timeouts in der Kommunikation mit der separaten Einheit. Sowas: 2017-04-05 07:23:09.328 [ERROR] [rnal.model.impl.MultiTouchDeviceImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 1 Als ich auf die Ethernet-ohne-PoE umstieg, wurde das etwas besser, aber immer noch nicht zuverlässig. Jetzt ist der Red direkt an einer LAN-Buchse der FritzBox, und ein Timeout passiert nur so ca alle zwei Tage, laut openhab.log. Übrigens war's auch mit USB-Wifi am Red nicht besser. md

hallo Theo et al, mein openhab schreibt nicht aufs LCD20x4... hier die getesteten befehlszeilen in .rules: sendCommand(LCD, String::format("TFNUM<10>WZ-FENSTER AUF")) und so auch nicht: sendCommand(LCD, "TFNUM<10>WZ-FENSTER AUF") Hier die Fehlermeldung: 2017-03-19 08:58:00.030 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Exception during event dispatch [org.osgi.service.event.Event [topic=openhab/command/LCD] {bridgemarker=true, item=LCD, command=TFNUM<10>WZ-FENSTER AUF} | {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.tinkerforge, component.name=org.openhab.binding.tinkerforge.binding, component.id=4, service.id=290, service.bundleid=192, service.scope=bundle} | Bundle(org.openhab.binding.tinkerforge_1.9.0 [192])] java.lang.UnsupportedOperationException at org.openhab.binding.tinkerforge.internal.model.impl.MBrickletLCD20x4Impl.write(MBrickletLCD20x4Impl.java:1035)[192:org.openhab.binding.tinkerforge:1.9.0] ... An-/abschalten des backlights geht. Das LCD ist wohl richtig konfiguiriert, oder? String LCD "LCD" { tinkerforge="uid=rXd"} Switch LCDBacklight "LCDBacklight" {tinkerforge="uid=rXd, subid=backlight"} Im übrigen habe ich festgestellt, dass häufiges Editieren der tinkerforge.cfg die datei /var/lib/openhab2/config/org/openhab/tinkerforge.config korrumpieren kann. Dann bekommt man allerlei fehlermeldungen von wegen irgendwelche devices mit subid sowieso seien unbekannt, etc. ich lösche dann tinkerforge.config und starte neu... -md

OPENHAB 2.0 auf dem RED BRICK Wollte mal kurz berichten... Ich hatte früher schon mit OH1.x eperimentiert, mich dann aber entschlossen, mit der "ernsthaften" Arbeit auf OH2 zu warten. Zuerst probierte ich mit der aktuellen OH2 Release auf meinem Windows-Rechner herum, gestern habe ich das Ganze dann auf den Red Brick übertragen. Und es funktioniert. Etwas lahm, aber geht. Folgt man der Anleitung auf der Doku-Seite von openhab.org, sollte die Installation von OH2 mittels apt-get auf dem Red problemlos vonstatten gehen. Für die Einrichtungsarbeit mit dem OH-Web-Interface verwende ich puTTY, TightVNC, für den Datei-Upload FileZilla. Was mir erst spät klar wurde: Die "Paper-UI" ist eine reine Setup-Umgebung; im Betrieb nehme ich die "Basic UI" mit sitemap und allem anderen. Ja, nach wie vor braucht es Items-, Rules-, Sitemaps- und die anderen Dateien für die Konfiguration. Falls man die noch aus der OH1-Installation hat, kann man sie für die Verwendung in OH2 an die entsprechenden Stellen kopieren. Für den Zugriff auf meine OH2-Homepage benutze ich die Android-App. Da muss man schonmal 15 bis 20 Sekunden warten, bis eine Fenster-Auf/Zu-Meldung von meinen max!-Komponenten durchgereicht wird, aber das war vorher glaube ich auch nicht viel besser. Das Installieren von Bindings ist jetzt viel einfacher; und, falls es sich um ein 2.0-Binding handelt, werden zugehörige Komponenten automatisch im Netz ermittelt. Trotzdem muss man die Dinge ("Things" heißen die Komponenten wie zB Heizkörperthermostaten, Schalter oder Fensterkontakte jetzt) nach wie vor manuell in der '.items-Datei einbinden und mittels *.sitemap sichtbar machen. Das ist ok, aber das heißt auch, das Openhab bis auf weiteres eher was für Ingenieure und Informatiker bleiben wird. Allerdings versprechen die OH2-Macher für künftige Versionen mehr Komfort. Das Tinkerforge-Binding ist noch auf Stand 1.9, d.h., die im lokalen Netzwerk auffindbaren Bricklets etc müssen per *.items-Datei deklariert werden. Funktionierte in meinen Tests aber einwandfrei. Vielleicht sollte TF den Versionsschritt auf 2.0 mitgehen und vorinstalliert auf dem Red anbieten? -md

Jeder Sensorwert lässt sich zu jedem Zeitpunkt abfragen; sieh dir dazu die API des jeweiligen Sensors an (da wo das Beispielprogamm kopiert hast). Jede Callbackfunktion wird bei Änderung eines Zustands aktiv, aber auch bei fest eingestellten Callback Periods. Im Code unten machen die beiden Callback-Funktionen nichts anderes als die Funktion output() aufzurufen, und die aktualisiert die Sensorwerte auf die beiden Variablen, die dann (warum bloß) auf x addiert werden, und das x wird per print() ausgegeben... Hier bitte: PORT = 4223 UID2 = "co2" UID3 = "Temp" from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_co2 import BrickletCO2 from tinkerforge.bricklet_temperature import BrickletTemperature def cb_temperature(temperature): output() def cb_co2_concentration(co2_concentration): output() def output(): co2_concentration = co2.get_co2_concentration() temperature = t.get_temperature() x = co2_concentration + (temperature/100) print (x) if __name__ == "__main__": ipcon = IPConnection() co2 = BrickletCO2(UID2, ipcon) t = BrickletTemperature(UID3, ipcon) ipcon.connect(HOST, PORT) co2.register_callback(co2.CALLBACK_CO2_CONCENTRATION, cb_co2_concentration) co2.set_co2_concentration_callback_period(1000) t.set_temperature_callback_period(1000) t.register_callback(t.CALLBACK_TEMPERATURE, cb_temperature) input("Press key to exit\n") ipcon.disconnect() Mehr folgt erst wieder, wenn du nachweislich einen Python-Kurs absolviert hast... md

Na, das ist doch simpel: Du musst nur von jeder involvierten Callback-Funktion einen Aufruf zu der Funktion setzen, die die erwünschte Ausgabe produziert (wie in meinem Beispiel). Da holst du per xxx.get_temperature() oder yyy.get_co2() oder zzz.get_wasauchimmer() aktuelle Werte von den Sensoren, verarbeitest die und gibst sie per print() aus. Eh voila. Oder du lässt das mit den callbacks ganz und machst es mit Timer. md

Tja, ich fürchte, ich kann nicht ganz folgen. 'PMV' kenne ich nicht; aber klar kannst du bei jedem Callback auch andere Messdaten abfragen (wie z.B. mit t.get_temperature()) und dann deine Berechnungen machen und die Resultate ausgeben. Minima und Maxima etc. aus Wetterdaten zu extrahieren ist nicht schwierig -- in Python gibt es die eingebauten Funktionen min() und max() --, aber dafür brauchst du halt ein gewisses Python-Handwerkszeug... du musst die Daten aufbereiten, aufzeichnen, auswerten. Eine Ruckzuck-Komplett-Lösung für so etwas kann dir hier niemand geben. Also hol dir ein gutes Lehrbuch und ran. In Detailfragen wird man dir hier gerne weiterhelfen. md

Ja mei, da fügst du halt eine kleine Funktion ein, die den Durchschnittswert errechnet, jedes Mal, wenn der Callback einen neuen Wert liefert. Python hat im statistics- Modul (https://docs.python.org/3/library/statistics.html) die Funktion mean() zur Ermittlung des Durchschnitts. Also zuerst bei den imports einfügen: from statistics import mean mean() nimmt als Parameter eine Liste von Daten, also kannst du unten in deinem Programm, nach der Definition der Callbacks eine Zeile wie diese einfügen: temp_vals = [t.get_temperature()/100] Damit hast du den Startwert gleich in die Liste eingefügt. Dann die Callback-Funktion wie hier abändern: def cb_temperature(temperature): print(temperature/100) temp_curr = (temperature / 100) temp_vals.append(temp_curr) calc_avg(temp_vals) Der aktuelle Wert der Temperatur bekommt eine Variable und die wird an die Liste gehängt. Danach der Aufruf der folgenden Funktion, die den Durchschnitt aus dem alten Durchschnitt und dem aktuellen Wert errechnet: def calc_avg(temp_vals): temp_avg = mean(temp_vals) temp_vals = [temp_avg] print('Durchschnitt:', temp_avg) Der aktuelle Durchschnitt überschreibt anschließend die Liste für Verwendung im nächsten Callback. Soweit im Ansatz. Die Frage ist allerdings, wie sinnvoll so ein mitlaufender Durchschnittswert ist. Sinnvoller wäre es vielleicht, die letzten x Werte zur Berechnung zu verwenden, oder die aus einem bestimmten Zeitraum. Das hier geht allerdings gar nicht: ## dieser Wert X soll sich zum Beispiel an die callbacks anpassen X = co2_concentration+ (temperature/100) print (x) x und X passen nicht zusammen, und co2 und temperatur zu addieren ist unsinnig. Ich denke, du musst programmiermäßig und mathematisch (was die Durchschnittsgeschichten betrifft) noch etwas (oder einiges) an Basisarbeit leisten... md

Dann warte ich zunächst mal auf die Doku -- denn ich bekomme das einfach nicht hin, obwohl ich früher schon eine laufende OHAB 1.x Installation hatte und nun versuche, die alten Rezepte auf 2.0 anzuwenden, aber was ich auch anselle, das TF-Binding erscheint nicht unter Configuration > Bindings; so geht's schon mal los. Naja. Danke jedenfalls für euren Einsatz! macduff

... dem würde ich gerne die Frage (an Theo) anschließen, ob und wann mit 2.0-Tinkerforge-Bindings für oHAB 2.0 zu rechnen ist? MacDuff