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
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 09, 2019, 18:40:03 »
@ 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

2
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 08, 2019, 16:23:45 »
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:

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

3
Anfängerfragen und FAQ / Re: RED + Wifi + Touchscreen
« on: August 30, 2019, 17:43:27 »
ich hab das mal mit einem kleinen usb-hub realisiert...

4
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

5
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

6
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

7
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

8
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
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

11
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
   

12
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

13
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

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:

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

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

Pages: [1] 2 3 ... 5