Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - MacDuff

Pages: [1] 2 3 ... 5
1
nach schneller durchsicht fiel mir das auf:
Code: [Select]
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

2
Danke --
das ging gut bis:
Code: [Select]
git reset --hard brickd-2.4.0worauf folgte:
Code: [Select]
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
Code: [Select]
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

3
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:
Code: [Select]
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

4
Danke -
es funktioniert nun mit:
Desktop Einvironment aktiviert +
Code: [Select]
app = QApplication()oder
Desktop deaktiviert +
Code: [Select]
app = QCoreApplicationQApplication 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

5
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

7
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
Code: [Select]
# (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

8
Projektvorstellungen und Projektideen / Re: openhab Integration
« on: April 05, 2017, 08:16:33 »
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:

Code: [Select]
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
   

9
Projektvorstellungen und Projektideen / Re: openhab Integration
« on: March 19, 2017, 09:10:42 »
hallo Theo et al,
mein openhab schreibt nicht aufs LCD20x4...
hier die getesteten befehlszeilen in .rules:

Code: [Select]
sendCommand(LCD, String::format("TFNUM<10>WZ-FENSTER AUF"))und so auch nicht:
Code: [Select]
sendCommand(LCD, "TFNUM<10>WZ-FENSTER AUF")
Hier die Fehlermeldung:

Code: [Select]
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?
Code: [Select]
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

10
Projektvorstellungen und Projektideen / Re: openhab Integration
« on: March 09, 2017, 16:07:36 »
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

11
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:

Code: [Select]
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

12
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

13
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

14
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:

Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
## 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

15
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
 

Pages: [1] 2 3 ... 5