Raspberry Pi Add-On Board (nicht mehr verfügbar / Fertigung eingestellt)

[RappaSan]

Ok, das ist schon mal wissenswert.
Nur die Sprünge von 0 nach 28-30.000 machen mich etwas nervös.
Auch läßt sich so der untere Teil der Messkurve quasi gar nicht darstellen.

Btw.: Am WLAN stick lag's nicht, gleiches Verhalten auch über Netzwerkkabel.

[Kuzl]

Mal was ganz anderes - ist das nur bei mir so, dass die CUL-LED sich wieder einschaltet, wenn man die Hintergrundbeleuchtung ausschaltet?

Gruß
Kuzl

EDIT:
Ok jetzt ist sie irgendwie wieder aus

EDIT2: okay es scheint so, als passt da irgendwas nicht. ich hab die LED jetzt schon 2x ausgeschaltet und sie schaltet sich immer wieder ein.

[locutus]

ist das nur bei mir so, dass die CUL-LED sich wieder einschaltet, wenn man die Hintergrundbeleuchtung ausschaltet?

Die LED visualisiert den Datentransfer auf der seriellen Schnittstelle. In welchen CUL Modi (SlowRF, HomeMatic, MAX) soll denn die LED nach dem Ausschalten der Hintergrundbeleuchtung wieder aufleuchten?
Eventuell mit

Code Auswählen Erweitern

set CUL_0 raw e
zurücksetzen und die LED mit

Code Auswählen Erweitern

set CUL_0 led 00
ausschalten.

Evtl. noch ein kleiner verbesserungsvorschlag für die Anleitung:
Für die Hintergrundbeleuchtung einen normalen Dummy verwenden, da sonst immer kommt, dass man kein IO-Device dafür hat, wenn man kein FS20 benützt.

Entweder ist kein CUL definiert, CUL hat den Status opened oder aber ttyAMA0 ist nicht freigegeben.
Einen normalen Dummy für die Hintergrundbeleuchtung? Wie soll bitte die Funktion dazu aussehen?

[Kuzl]

Hm okay also irgendetwas scheint nicht ganz zu passen.
Wenn ich die LED ausschalte, dann bleibt sie erstmal aus und wenn ich dann z.b. das Display ausschalte geht sie wieder an. Ebenso, wenn ich über Homematic etwas schalte.

CUL ist allerdings definiert und funktioniert reibungslos.

Einen normalen Dummy für die Hintergrundbeleuchtung? Wie soll bitte die Funktion dazu aussehen?

Bei mir so:

Code Auswählen Erweitern


define LCD_Backlight dummy
attr LCD_Backlight webCmd on:off

define LCD_Backlight_Switch notify LCD_Backlight { if ("%" ne "off") { system("/usr/local/bin/gpio write 4 1 &") } else { system("/usr/local/bin/gpio write 4 0 &") } }

[locutus]

Nur die Sprünge von 0 nach 28-30.000 machen mich etwas nervös.
Auch läßt sich so der untere Teil der Messkurve quasi gar nicht darstellen.

Vergiss bitte die 0815 Lösung mit dem Dummy. Nimm stattdessen das 51_I2C_TSL2561.pm Modul von kaihs.
http://forum.fhem.de/index.php/topic,20942.0.html

Code Auswählen Erweitern

define Luminosity I2C_TSL2561 /dev/i2c-1 0x39
attr Luminosity poll_interval 10

[kaihs]

Ich habe das Modul auch seit ein paar Tagen und bin ziemlich begeistert.

Abweichend von der Anleitung von locutus habe ich folgendes gemacht:

Ein-/Ausschalten der Hintergrundbeleuchtung über das RPI_GPIO Modul:

Code Auswählen Erweitern


define Backlight RPI_GPIO 23
attr Backlight devStateIcon .on:FS20.on .off:FS20.off
attr Backlight direction output
attr Backlight icon light_mirror
attr Backlight restoreOnStartup yes
attr Backlight room Status


Die Größe des RSS-Bildes habe ich an die Auflösung des Displays angepasst, das verhindert das Flackern beim L8aden eines neuen Bildes:

Code Auswählen Erweitern

attr FrameRSS size 128x160

Die layout.txt muss dann entsprechend angepasst werden

Code Auswählen Erweitern


### RSS Layout ###
font /usr/share/fonts/truetype/freefont/FreeMono.ttf # TrueType Schriftart
rgb "c0c0c0" # HTML Farbencode
pt 26 # Schriftgroesse
time 0.08 0.20 # Uhrzeit
pt 16
text 0.12 0.70 { ReadingsVal("BMP085","pressure-nn","?"). " hPa" } # BMP085 Luftdruck
text 0.04 0.85 { sprintf("%.1f", ReadingsVal("OWX_28_6398A4050000","temperature","0")) . "/" . ReadingsVal("Wetter","temperature","?"). " °C" } # Aussentemperatur
img 25 50 0.4 png file { "/opt/fhem/www/images/default/weather/" . ReadingsVal("Wetter","icon","") . ".png" } # Wetter Icon
pt 10
#text 0.04 0.95 "IP: 192.168.2.202" # IP Adresse
text 0.04 0.95 { "Helligk. " . ReadingsVal("Helligkeit","luminosity","0"). " lx" } # Helligkeit in Lux


Daran ist auch die Anzeige der Helligkeit in der letzten Zeile und eines per 1-Wire angeschlossenen Temperatursensors enthalten, ggf. nach Geschmack abzuändern .

Insgesamt ist diese Art der Displayansteuerung natürlich immer noch ziemlich suboptimal, besser wäre ja ein direktes 'malen' im Framebuffer.
Mal sehen, ob ich da was basteln kann.

[locutus]

Ein direktes "malen" im Framebuffer wäre genial. Allerdings ist notros fbtft sehr umfangreich geworden. Es werden immer mehr Displays unterstütz und das Ganze beschränkt sich nicht mehr auf den RPi. Eine Adaption für BeagleBone Black wurde bereits entwickelt.

Das RPI_GPIO Modul hatte ich auch schon im Visier.

128x160 ist das tatsächliche Pixelverhältnis für dieses Display. Ich habe in der Anleitung 300x400 vorgeschlagen, damit man ggf. mehr Inhalt im Bild unterbringen kann.

[Spezialtrick]

Ist das Display eigentlich dimmbar? 

[kaihs]

Ein direktes "malen" im Framebuffer wäre genial. Allerdings ist notros fbtft sehr umfangreich geworden. Es werden immer mehr Displays unterstütz und das Ganze beschränkt sich nicht mehr auf den RPi. Eine Adaption für BeagleBone Black wurde bereits entwickelt.

Ich denke man könnte das unabhängig vom eingesetzten Framebuffer Treiber gestalten und 'einfach' /dev/fb1 ansprechen. Es gibt schon ein Framebuffer Modul für perl (https://metacpan.org/pod/Graphics::Framebuffer, dass müsste man mit dem Layout Mechanismus des RSS Modul verheiraten.

128x160 ist das tatsächliche Pixelverhältnis für dieses Display. Ich habe in der Anleitung 300x400 vorgeschlagen, damit man ggf. mehr Inhalt im Bild unterbringen kann.

Dann muss aber fbi das Bild runterskalieren, das braucht Rechenzeit und führt wahrscheinlich zu dem Flackern.

[Mitch]

Die zusätzliche Raumtemperaturmessung war mit 'nem DS1820 schnell nachgerüstet. Inzwischen find ich's eher einen Benefit, die Gehäuseinnentemperatur zu sehen. Außerdem würde die Temperaturkompensation die verschiedene Abwärme bei Prozessorlaständerung u.ä. nicht berücksichtigen. 1wire ist da schon die bessere Lösung.

Gruß StefanP

Hi Stefan,

kannst Du mir sagen, wie und was du genau gemacht hast?
Danke.

In der Anleitung steht ja:

Wichtiger Hinweis:
Diese Betriebsart ist nicht mit der vorinstallierten culfw möglich. Das 1-Wire bridge device (DS2482-100) wird durch das Umsetzen der Lötbrücken direkt an den I2C-Bus des Raspberry Pi angeschlossen.

Das verunsichert mich ein wenig.

Würde mir gerne eine DS kaufen, weil ich die Temp im Zimmer messen möchte.
Habe einen SHT21 im Moment, der geht aber dann nicht mehr, weil die Ports belegt sind. Ausserdem bekomme ich ihn nicht richtig in FHEM eingebunden.

[StefanP]

Hallo Mitch,
im Auslieferungszustand sind die Lötbrücken so gesetzt, dass du einen 1Wire-Port direkt an einer Schraubleiste auf dem Modul nutzen kannst. Einfach nur einen Thermofühler anklemmen... läuft. Der Port ist bei mir mit

Code Auswählen Erweitern

define OWio OWX CUL_0 in der fhem.cfg konfiguriert.


Gruss Stefan

[Mitch]

Danke Stefan.

Würde denn der DHT11 oder DHT22 auch gehen?
Hätte den Vorteil der Luftfeuchte.
Habe nur keine Ahnung, wie ich den in FHEM einbinden kann.

[StefanP]

Hallo Mitch,
da bin ich leider überfragt. Such mal im Forum ob jemand DHT11/22 mit CUL zusammen verwendet. Ich kann dir nur die Funktion von DS18B20 bestätigen.

Gruß StefanP

[corny456]

Würde denn der DHT11 oder DHT22 auch gehen?

Jain. Die beiden sind keine 1-Wire Sensoren und können somit nicht direkt an einem 1-Wire bus betrieben werden sondern nur über einen Microkontroleroder am raspi...

Gruß
Marius

Sent from my iPad using Tapatalk HD

[locutus]

Tobias baut und verkauft 1-Wire Temperatur und Luftfeuchtesensoren
http://forum.fhem.de/index.php/topic,20905.0.html