Jump to content

MacDuff

Members
  • Gesamte Inhalte

    72
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von MacDuff

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. Bingo! Das hilft in der Tat, vielen Dank. Vielleicht ist das einen Hinweis auf der RedBrick/Web-Interface Dokseite wert? Auf die Spur gebracht, habe ich jetzt auch noch in der Flask-Doku nachgesehen, wo es heißt: http://flask.pocoo.org/docs/0.10/deploying/mod_wsgi/ md
  7. Das Miniprogramm funktioniert. Inzwischen habe ich auch gelernt, dass es explizit application = Flask(__name__) heißen muss (also "application"), damit der WSGI server das richtig verdaut. Ansonsten behauptet er -- etwas irreführend --: The requested URL /programs/miniflask/bin/index.py was not found on this server. Es funktioniert auch noch viel mehr: Bootstrap, WTFform, SQLAlchemy... Was aber nicht geht, ist sowas: from flask import Flask from classfile import Klasse application = Flask(__name__) app = application @app.route('/') def hello_world(): return '<html><body>Hello World!</body></html>' classfile.py liegt im selben Verzeichnis neben index.py und sieht so aus: class Klasse: def __init__(self): pass Mit dieser Importanweisung gibt es einen Server Error 500 - auf dem Red. Beim Testen mit Flask/Werkzeugs eingebauten Developmentserver (in PyCharm): kein Problem. Verlege ich die Klasse nach index.py und mache myclass= Klasse() funktioniert es auch. Ich will nur keine 500+ Zeilen langen index.px-Dateien schreiben... verstehe aber nicht, warum der Import von allen möglichen flask.ext. usw keine Probleme bereitet.
  8. ein paar seltsamkeiten mit einer kleinen und einer großen python-flask anwendung fürs red-brick web-interface: * die kleine besteht aus einer index.py und den dazu gehörenden templates/static-ordnern. wenn ich die auf den red hochlade, bekomme ich bei klick auf "bin": "The requested URL /programs/wc5/bin/index.py was not found on this server." sorry, aber index.py liegt genau in dem pfad. * die große applikation generiert sofort nach aufruf einen 500er server error ohne genaue spezifikation. beide laufen auf meinem linux- und windowsrechner ohne probleme. die kleine funktionierte zuvor auch auf dem brick - solange in index.py kein lokaler modul-import (zB eine klasse mit tinkerforge-messwert-abfragen) stattfand. schon der import einer leeren klasse (!) produzierte den 500er error, wie ich nach langem trial & error herausfand. kommt mir alles ziemlich seltsam vor... macduff
  9. da ist irgendein fehler im script. schau mal im brick viewer > programs > [dein programm] > logs > continuous ins log. da müsste ja ein hinweis zu finden sein. dann kann man weitersehen. md
  10. Timer-gesteuerte Dinge sind in Python etwas tricky. Ich habe kürzlich ein Modul entdeckt, mit dem regelmäßige/wiederkehrende etc Aktionen recht simpel zu programmieren sind -- siehe: https://github.com/dbader/schedule Das sieht dann so aus: import schedule import time def job(): print("I'm working...") schedule.every(10).minutes.do(job) schedule.every().hour.do(job) schedule.every().day.at("10:30").do(job) schedule.every().monday.do(job) schedule.every().wednesday.at("13:15").do(job) while True: schedule.run_pending() time.sleep(1) Vielleicht hilft dir das ja. md
  11. Danke für den tipp mit xset; hat zwar nicht direkt (auf der kommandozeile) geholfen, aber mit der Lösung des Problems zu tun. In /home/tf/.config/lxsession/LXDE befindet sich eine datei "autostart", die normalerweise diese 3 zeilen beinhaltet: @lxpanel --profile LXDE @pcmanfm --desktop --profile LXDE @xscreensaver -no-splash (ein gleichnamige datei befindet sich auch /etc/xdg/lxsession/LXDE/, aber mir scheint, diejenige im tf-home ist die wichtige.) Auf einen hinweis im netz (http://raspberrypi.stackexchange.com/questions/752/how-do-i-prevent-the-screen-from-going-blank) habe ich die Datei folgendermaßen abgeändert: @lxpanel --profile LXDE @pcmanfm --desktop --profile LXDE # @xscreensaver -no-splash @xset s noblank @xset s off @xset -dpms Das heißt, "@screensaver -no-splash" auskommentiert und die folgenden drei zeilen angehängt. Voila: funktioniert. der monitor bleibt an, wie gewünscht.
  12. Wonach ich suche, ist eher sowas wie die Energieoptionen von Windows, mit denen man ja all diese Dinge (sleep, Monitor aus, etc) einstellen kann. Im GUI vom redbrick, menü preferences unter unterabteilungen, ist nichts Entsprechendes zu finden. Was ich so ergooggelt habe, ist halt linux-typisch vielfältig, und deshaln die Frage, ob's nicht schon jemand hier ultimativ-autoritativ für den redbrick in den Griff bekommen hat. Oder die Herren von Tinkerforge stehen mir in dieser Frage bei? merci macduff
  13. MacDuff

    HDMI Display - Backlight

    Hat schon jemand herausbekommen, wie man die Hintergrundbeleuchtung des HDMI-Displays aus dem Tinkerforge-Shop ein-/ausschaltet, bzw. die Zeit bis zum Sleep definiert? Ich hatte es bisher immer als Touchscreen im Einsatz; da ging es wieder an, sobald man den Screen berührte. Nun, nur als Display (also ohne die USB-Verbindung zum redbrick) verwendet, finde ich keinen Weg, es wieder zurückzuholen, nachdem es dunkel wurde, obwohl die "Touch"-LED auf der Rückseite des Displays hektisch blinkt, wenn man es berührt. danke, macduff
  14. Hallo Theo, das Problem konnte ich jetzt aktuell nicht weiter verfolgen, weil ich umziehe und erstmal alles abbauen muss. Evtl war da auch ein wild laufender Timer mit im Spiel... Bin sehr gespannt auf openhab2 und alles, was da mitkommen soll. Die Einbettung von Python wäre cool, mit Python kenn ich mich ganz passabel aus. Sicher fragt man sich immer wieder mal, wie man selbst mithelfen kann, wenn man sich schon so großzügig an der Arbeit anderer bedient... Zeit und Kompetenz sind die begrenzenden Faktoren, fürchte ich. Umsomehr Respekt für dein Engagement! schönes Wochenende, md
  15. Ging doch schneller als erwartet - und funktioniert. Ich verwende das Dual-Button-Bricklet zur Anzeige geöffneter Fenster. Ein max!-Fensterkontakt ist über eine openhab-Regel mit dem DB-Bricklet gekoppelt: rule "Window Contacts" when Item WZ_FK_1 changed or Item CB_FK_1 changed then if (WZ_FK_1.state == OPEN) { sendCommand(TF_LCD, String::format("TFNUM<10>WZ-FENSTER AUF")) sendCommand(TF_DB_1_LEDleft, ON) ... Das LCD 20x4 ist auch dabei. Das LCD-Backlight wird über das Motion Detector Bricklet getriggert, für einige Sekunden eingeschaltet und über einen Timer wieder ausgeschaltet. Allerdings geht das Backlight auch an, wenn der in meinem Aufbau ebenfalls integrierte Temperaturfühler (TF-Bricklet) einen neuen Wert liefert. Das legt zumindest das event.log nahe. Kann das sein? Generell ein paar Worte zu openhab auf dem Red Brick: Ich hatte anfangs mit FHEM auf fritzbox und Raspberry experimentiert, fand aber Performance und das GUI ziemlich furchtbar. Mit Openhab kriegt man natürlich wesentlich mehr Hardware unter einen Softwarehut. Super auch die direkte Integration von TF-Bricks und Bricklets mit dem RedBrick. Nach einigen Wochen Probieren mit RedBrick & openhab bereue ich den Umstieg nicht... aber Frustrationen gibt's natürlich auch. Ich denke, wenn openhab richtig abheben will, muss dringend was für die Dokumentation getan werden. Das Zusammenspiel von items, rules & sitemaps (plus anderem) kann durchaus komplex werden. Wenn man aber dauernd verstreute Beispiel-Dateien durchsuchen muss, um den gewünschten Funktionalitäten durch Trial & Error auf die Spur zu kommen (speziell bei rules), dann kostet das unheimlich viel Zeit und Nerven. Klar gibt es Hinweise auf xtend und xbase als Grundlagen für Rule-Syntax und Funktionen/Eigenschaften, aber die sind auch eher lausig dokumentiert. Naja -- das hat jetzt nix direkt mit TF zu tun. Nur ein Beispiel, in welche Abgründe einen die Begeisterung führen kann... jedenfalls mich als Nicht-Informatiker... - md
  16. sehr schön! danke. ich werde das die tage mal testen und getreulich berichten, wie es mir damit ergangen... md
  17. MacDuff

    Red Brick

    confirm. I had a raspi in use, and now I use a Red.
  18. Dem Lob darf ich mich anschließen. Ich baue mir gerade ein Openhab-System aus TF und Max!-Komponenten (Heizungssteuerung) zusammen. Auf TF-Seite sind Temperatur-, AmbientLight-, LCD-, Motion-, Remote-Switch-Bricklets im Einsatz. Funktioniert alles einwandfrei. Nun... würde ich gerne Max!-Fensterkontakte mit dem Dual-Button-Bricklet zusammenschalten -- wir sind unterm Dach und ich stelle mir eine Warnlampe vor, die beim Verlassen der Wohnung leuchtet, falls eines der Dachfenster geöffnet ist. Besteht die Chance, dass dieses Bricklet zu den bestehenden TF-Bindings hinzugefügt wird? beste Grüße, macduff
  19. danke für die nachforschungen. dazu kann ich noch ergänzen: der sprung von 600/480 auf 1280/720 ist zum ersten mal passiert, als ich die usb-verbindung zum display vom redbrick auf eines eurer usb-netzteile umgesteckt habe. also quasi im laufenden betrieb, denn hdmi blieb ja dran. falls das was bedeutet.
  20. ja, das display hängt beim booten des redbrick an hdmi und usb. erst flimmerts ein bisschen, dann kommt der splash und schließlich ein stabiles bild -- 1280x720. EDIT: nach einigem suchen fand ich dieses: https://bugs.launchpad.net/ubuntu/+source/x11-utils/+bug/1078695 kanns aber nicht genau einordnen. das "failed to get size of gamma" ist wohl in der tat ein hinweis auf nicht erkanntes EDID. NOCH EIN EDIT: Wenn ich das Display an ein WIN 8.1 Asus Notebook anschließe, klappt's sofort mit dem Umschalten auf 800x480. Denke mal deswegen, dass die EDID schon übergeben wird.
  21. Mit dem Touchdisplay aus dem TinkerShop fing es recht gut an. Jetzt aber ist der Wurm drin. Irgendwann im Verlauf diverser Kalibrierungsversuche hat es (oder der RED?) seine native Auflösung von 800x480 vergessen und kommt jetzt mit jedem Neustart des RED hartnäckig mit einem Desktop 1280x720 daher. Hab's mit frischen RED-Images probiert, mit xrandr, und sonstwas. Touchpräzision ist natürlich völlig daneben. xrandr liefert einen fehler (failded to get size of gamma), und meldet ansonsten "screen 0 minimum 1280x720, current 1280x720" "default connected 1280x720+0+0 0mmx0mm" "1280x720" 60.0*" newmode/addmode usw brachten keine änderungen. Ein reset oder sowas habe ich für das Display nicht gefunden. Tja wie immer: keine Rose ohne Dornen. -- md
  22. Ich hab das Display auch seit kurzem. Die Touch-Funktion (als Pseudo-Maus) war quasi "out-of-the-box" verfügbar -- allerdings musste ich auch einen Kalibrierungsdurchgang veranstalten, weil die Berührungspunkte teilweise arg abseits der Mausposition lagen (bzw umgekehrt). Um die Kalibrier-SW zu starten, war allerdings eine Menge lästiger Arbeit wegen .Net nötig (.Net 4 entfernen, zurück auf 3.5. Allerdings hat Windows sich das .Net 4 eigenmöchtig wieder geholt... arhhhggh!). Viel Freude habe ich an dem Display danach aber nicht mehr gehabt - siehe anderen Beitrag im Forum, den ich gleich noch schreibe... macduff
  23. ok, Asche auf mein Haupt, und zwar reichlich. Ich habe immer "Video :0" statt "Display :0" eingetippt... manchmal sieht man den Wald vor lauter Bäumen nicht. Aber dafür habe ich mir jetzt das HDMI-Display bestellt. danke allen, md
  24. Ok, jetzt wollte ich es doch mal wissen (siehe auch den Thread "PyQt5 Bindings") -- ob das mit den GUI-Apps auf dem Redbrick funktioniert. Leider nicht. * Bin zurück auf Image 1.3 (Full), um irgendwelche Settings-Fehler auszuschließen. PyQt4, Qt4, alles standard. * Hab das Red-Brick-Tutorial mit dem Abschnitt zur GUI-Entwicklung getreulich befolgt. * erster Start vom Programm Tab: Fehlermeldung: "Error: Log file is not UTF-8 encoded". Wie das? * Na, egal, den u-Marker (unicode) aus der label.setText-Anweisung entfernt. * zweiter Start, immerhin: "guitest.py: cannot connect to X server" * ich seh den TF Desktop vor mir. aber gut. gehe zu console, "startx". neustart desktop. * neuer versuch, das programm zu launchen: selber fehler. also entweder bin ich komplett aum falschen dampfer, oder da ist was faul? -md
×
×
  • Neu erstellen...