Jump to content

MacDuff

Members
  • Content Count

    67
  • Joined

  • Last visited

Everything posted by MacDuff

  1. 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
  2. @ 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
  3. 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
  4. ich hab das mal mit einem kleinen usb-hub realisiert...
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. ... 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
  20. Ich hab da eine kleine Python-Flask-Webapp, die einige Messwerte aus TF-Sensoren auf eine Webseite bringt. Was auf dem Windows- und dem Linux-Computer einwandfrei funktioniert. Nur auf dem Redbrick nicht. Der Server verweigert die Ausgabe -- "Internal Server Error" und zwar laut Apache Error Log wegen der misslingenden Initialisierung einer Basisklasse: super( ).__init__(), referer: http://[iP Adresse...] ... TypeError: super() takes at least 1 argument (0 given), Die App ist Python 3.52, aber an dem Error Log kann man sehen, dass das Web Interface des Bricks mit 2.7-Modulen arbeitet ('/usr/local/lib/python2.7/dist-packages/flask/app.py). Ich habe versucht, die Initialisierung in "alter", Python-2-Schreibweise, unter anderem: super(TemperatureBricklet, self).__init__() zu bewerkstelligen, bislang ohne Erfolg. Mal abgesehen davon, wäre es natürlich besser, wenn auch das Web-Interface wenigstens mit 3.42 arbeitete. Die Wahl hat man da -- anders als bei Skriptausführung -- offenbar nicht. Nur wegen ein paar abgeleiteten Klassen auf 2.7 zurückzugehen, finde ich eine schlechte Lösung. - md
  21. Hallo Theo, ich habe die Online-Distro als Standardversion (nicht Demo) auf meinem Win 8.1 Rechner installiert. Dann in der Paper UI die Tinkerforge-Bindings dazu installiert, aber sie scheinen halt nicht in der Liste der Bindings auf, und demzufolge wohl auch keine TF Komponenten... Versuchsweise habe ich aus der Liste der Extensions das eine oder andere weitere Binding installiert; hängen geblieben sind in der Regel aber nur die "echten" 2.0-Bindings. merci, md
  22. Das meldet sich mit "already installed" zurück; gefolgt von einem error, dass irgendwelche bundles nicht neu gestartet werden konnten... ich habe auch keine alten konfigurationen von oha 1.x mehr, das ist alles mit einem computer-crash dahingegangen, sondern starte einen neuen versuch mit 2.0. vielleicht am besten, auf 2.0 bindings zu warten... danke & ciao md
  23. Hallo, nach einer Weile Abstinenz habe ich mich mal wieder mit Openhab und TF beschäftigt -- OH2 diesmal. Das macht ja einen recht guten Eindruck; meine MaxCube-Teile hat's praktisch von allein gefunden und eingebunden. Mit TF habe ich allerdings Probleme. Das Binding kann ich installieren (via Extensions), aber es erscheint nicht bei "Bindings", und auch keine TF-Hardware im Überblick. Im openhab.log finde ich dann errors und warnings dieser Art: 2016-08-16 17:07:23.706 [ERROR] [org.openhab.binding.tinkerforge ] - FrameworkEvent ERROR - org.openhab.binding.tinkerforge org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tinkerforge [198] Another singleton bundle selected: osgi.identity; osgi.identity="org.openhab.binding.tinkerforge"; type="osgi.bundle"; version:Version="1.8.3"; singleton:="true" Legacy bindings sind "true" im addons.cfg. tinkerforge.cfg hat "hosts = localhost". Was läuft hier schief? merci, macduff
  24. Mein 800x480 Touch Screen von TF hat den Geist aufgegeben; es zeigt nur mehr ein sehr helles mit ein paar Streifen durchzogenes "Bild" an - kaum dass man das TF-Logo erahnen kann. Das muss im laufenden, unangetasteten Betrieb passiert sein. Ich habe es testweise an mein Notebook angeschlossen -- gleiches Resultat. Der RedBrick, an den es bis dahin angeschlossen war, liefert durchaus noch einen Grafikoutput (mit einem anderen Monitor getestet). Kennt jemand eine Reset-Möglichkeit für das Ding? Beim Googlen einen Post gefunden, in dem über einen wohl gleichgelagerten Fall berichtet wurde. Dem hat der Adafruit-Support geraten, das Display einzuschicken... md
×
×
  • Create New...