ESP8266 mit OLED Display in Blinddeckel

Begonnen von tomster, 11 März 2016, 13:52:13

Vorheriges Thema - Nächstes Thema

bloodybeginner

ich werf mal folgendes mysensors Projekt in den thread:
https://www.openhardware.io/view/23/In-wall-LCD-SwitchScene-controller-for-MySensors

Da wäre auch ein Board beschreiben mit 220V Spannungsversorgung, Arduino Pro Mini und NRF24L01+ - eventuell lässt sich das Board als Vorlage für nen ESP nehmen

wingfighter

Hallo

Ich habe mir das Projekt aus Softwaresicht mal angeguckt. Die eine oder andere Idee kann man sicher noch adaptieren.
Bei den Displays ist aber die sehr unterschiedliche Programmierung die Herausforderung.
Ich habe mir das Datasheet in den letzten Tagen aber mal genauer angeguckt und auch die Register gefunden, über die die Helligkeit des Display gesteuert wird. Außerdem gibt es auch ein Bit um es ganz dunkel zu schalten.

Ich habe im Moment am A0 also ADC des ESP8266 einen Photowiderstand hängen und lasse so die Helligkeit regeln. Da muss man sicher eine individuelle Feinjustage für die Steilheit der Kurve vorsehen. Aber grundsätzlich funktioniert das Verfahren.

Ich hatte noch eine Idee, die aber zz an meinen fehlenden FHEM-Künsten scheitert.
Wie schon geschrieben, habe ich das MQTT-Protokoll implementiert. Die beiden Messwerte werden auch regelmäßig an FHEM übertragen.
Nun ist die Idee, dass man per publischSet_<Display_n> Messwerte (z.B. andere Raumtemperaturen oder die Außentemperatur etc.) an das Display übertragen kann.
Mann könnte z.B. 9 zusätzliche Displays im Sketch vorhalten und wenn sie per mqtt mit Zahlen gefüllt werden, rolliert die Anzeige über 2 + n Messwerte. Und wenn per mqtt eine "clear Display n" geschickt wird, wird der Inhalt gelöscht und  die Anzeige aus dem Rollieren raus genommen.
Dazu wäre es aber sinvoll, dass die anzuzeigenden Werte automatisch an den Sketch gesendet werden.

Hier mal ein Ausschnitt aus dem Post in dem das MQTT-Modul vorgestellt wurde:
define heizung_kinderzimmer MQTT_DEVICE
attr heizung_kinderzimmer publishSet_desired-temp fhem/kinderzimmer/temperatur


Man kann auf diese Weise interaktiv einen Wert per MQTT an das Device senden und dort weiter verarbeiten. Das funktioniert auch grundsätzlich.

Nun würde ich aber eine FHEM-Variable - also z.B. die Raumtemperatur des Bades - immer wenn sie sich ändert automatisch senden wollen. Sicher kann man so etwas in der 99_myUtils.pm einbauen. Aber ich frage mich, ob es dafür nicht eine Lösung auf attr-Ebene gibt.

Ich stelle mir das in etwa so vor:
define heizung_kinderzimmer MQTT_DEVICE
attr heizung_kinderzimmer publishSet_desired-temp ReadingsVal(<TempDevice>, "temerature", "") fhem/kinderzimmer/temperatur


Nur gelingt es mir auf diese Weise nicht. Im ESP-Sketch kommt dann das "ReadingsVal(<TempDevice>" an. ;-(

Hat jemand eine Lösung für mich?

Gruß
wingfighter

MadMax-FHEM

Hallo,

verfolge diesen Thread ja gespannt!

Parallel bin ich über das hier gestolpert:


https://forum.fhem.de/index.php/topic,51267.0/topicseen.html


Weiter so!

Jetzt muss ich nur noch einen Platz finden wo ich das Display haben will und auch Strom da ist... ;-)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

tiwo85

#33
Hallo,
Super Projekt, ich versuche selber Software aufzustellen, aber mit einem Mono-oled und bin noch ziemlich am Anfang.

Bezüglich deines MQTT/Readingsproblem, schau mal hier :
https://forum.fhem.de/index.php?topic=27532.0
Das Stichwort heißt MQTT_Bridge.

Habe es bei mir so in etwa am werkeln.

define mqtt_Temp_Aussen MQTT_BRIDGE Temp_Aussen
attr mqtt_Temp_Aussen IODev Mosquitto
attr mqtt_Temp_Aussen publishReading_humidity fhem/aussen/wetter/relFeuchte
attr mqtt_Temp_Aussen publishReading_temperature fhem/aussen/wetter/Temperatur

Temp_Aussen ist ein LaCrosse Sensor, welcher die Readings temperature und humidity hat.

Gesendet von meinem D5803 mit Tapatalk


wingfighter

Hallo Tiwo85

Die Richtung ESP8266->FHEM funktioniert auch sauber. Und auch das manuelle Senden von Werten von FHEM zum ESP8266 geht grundsätzlich.

Mir will es nur nicht gelingen, z.B. eine Außentemperatur, die von einem Sensor gemessen wird, der in FHEM eingebunden ist, automatisch per publishSet_<AußenTemperatur> an den ESP zu senden.

Gruß wingfighter


tiwo85

Ich verstehe glaube ich, was du meinst. Ich versuche es mal zu erklären.
Ich glaube das Problem liegt daran, daß du ein MQTT_DEVICE erstellt hast. Der Sensor ist ja als device in Fhem schon vorhanden also muss dazu eine Brücke / bridge zwischen fhem und mqtt geschaffen werden.
Define <BridgeName> MQTT_Bridge <SensorName>
Und da du ein einen gemessenen Wert, also ein reading publishen möchtest, musst du PublishReading_<Reading> <topic>
nehmen.

Gesendet von meinem D5803 mit Tapatalk


wingfighter

Danke für den Tipp.
Das war's.

Jetzt kann ich mich mal mit den n dynamischen Displays in der OLED-Anzeige widmen. ;-)

Hier https://forum.fhem.de/index.php/topic,50238.0.html ist übrigens noch ein guter Ansatz für eine Basis-Konfiguration, ohne bei jedem Modul eine individuell im Sketch "verdrahtete" Konfiguration zu implementieren.
Muss man auf jeden Fall weiter verfolgen.


wingfighter

#37
So, ich habe noch ein bisschen am Programm erweitert.
Die aktuelle Version liegt wieder unter https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/blob/master/NHD-1.69-160128UGC3_ESP8266_Temp_Hum.ino.

Ich habe jetzt 10 zusätzliche Displays eingefügt, auf die im aktuellen Stand Werte in der Form xx.x geschrieben werden können.
Die Werte können an das Display per MQTT gesendet werden.

Im Sktech wird in Zeile 103 der Subcribe_Topic vereinbart auf den das Display lauschen soll:
#define display_topic "fhem/Display"

Möchte man z.B. eine Temperatur an Display 1 senden, sieht das auf der Mosquitto-Console so aus:
mosquitto_pub -t 'fhem/Display/1' -m '20.0'

Nun soll das ja möglichst automatisch ablaufen. Und wie schon in der vorigen Anfrage beantwortet, möchte ich aus FHEM heraus beispielhaft diverse Temperaturen und/oder Luftfeuchtigkeiten etc. übertragen.
In FHEM sieht das bei mir dann so aus:

Hier zunächst die Definition für die Werte des Sensors, der am ESP8266 hängt und seine Werte per MQTT an FHEM sendet:

define SB.TempHum MQTT_DEVICE
attr SB.TempHum IODev mqtt
attr SB.TempHum stateFormat state
attr SB.TempHum subscribeReading_Luftfeuchte fhem/Sensor/DHT22/Luftfeuchte
attr SB.TempHum subscribeReading_Temperatur fhem/Sensor/DHT22/Temperatur


Und hier die Definition für die zu übertragenden Werte an das Display. In diesem Fall ist es ein kombinierter Außenfühler für Temperatur und Luftfeuchte, der auf der Terrasse angebracht ist. Daher das TR im Namen.

define TR.Temperatur.mqtt MQTT_BRIDGE TR.Temperatur.Luftfeuchte
attr TR.Temperatur.mqtt IODev mqtt
attr TR.Temperatur.mqtt publishReading_temperature fhem/Display/1
attr TR.Temperatur.mqtt publishReading_humidity fhem/Display/2


So wie die Attribute definiert sind, werden allerdings weder genaue Messwertbezeichnungen noch Einheiten übertragen. So dass auf dem OLED-Display in der obersten Zeile "Display n" angezeigt wird. Als Einheit steht momentan °C fest in der Anzeige.

Hier sind wieder die FHEM-Profis gefragt, die mir bestimmt einen Tipp geben können, wie man einen String in der Art '<Wert>,<Einheit>,<DisplayName>' per MQTT senden kann.

Es bleibt noch offen, dass im Moment nur die benötigten Zeichen in Arrays hinterlegt sind. Diese im internen Speicher abzulegen und dann auch für alle ASCII 0-127, ist noch ein ToDo.

Und dann hätte ich da noch die Idee mit der Eieruhr, die per Taste, oder MQTT vom Handy aus gestartet werden kann. ;-)

Gruß wingfighter


PS: Habe  mal die Verdrahtung des Testaufbaus angehängt.

wingfighter

Hallo

Ich habe den Font jetzt etwas verkleinert - Verdana Bolt 44pt.
Version V 0.11 im Anhang bzw. auf GitHub.

Übrigens:
Wenn man in ein Display einen Wert schreibt, so wie oben erläutert,
mosquitto_pub -t 'fhem/Display/1' -m '20.0'

kann man den auch wieder löschen, d.h. das Display aus der Anzeige-Rotation entfernen:
mosquitto_pub -t 'fhem/Display/1' -m 'clear'

Gruß
wingfighter



tomster

So bin wieder da, wenn auch maximal gejetlaggt...

Primaarbeit wingfighter! Werd ich morgen gleich Mal flashen und testen.
Und Mal schauen, wie man den Photowiderstand so hinbekommt, dass man ihn in meinem Deckel nicht sieht. Vielleicht reicht es ja aus, den Widerstand von hinten auf die Blende zu kleben...

Wegen der Schriftart:
Wie detailtreu (=fein aufgelöst) wirkt denn die Verdana Font? Ich bin ja prinzipiell eher ein Freund von diesen Thin-Fonts wie z.B. Roboto, die auch bei der Google-Skin verwendet wird. Meinst Du das bekommt das Display hin, so dass es auch nach etwas aussieht?

wingfighter

#40
Das käme sicher auf einen Versuch an.
Aber bei solchen feinen Strukturen wie einem Thin-Font vermute ich, dass der Treppenstufen-Effekt sehr störend wirkt. Selbst bei dem Verdana Bolt sind Stufen zu erkennen.
Im Moment wird ja keine Kantenglättung der Schrift vorgenommen. Es wird nur das jeweilige Pixel in Vordergrund- bzw. Hintergrundfarbe gezeichnet.
Um eine Kantenglättung zu erreichen, musste man die Randpixel auf Pixelebene entweder dimmen können, oder -  was evtl. geht - die Farben abdunkeln. Aber das ist natürlich reichlich aufwändig. Da wird man dann wahrscheinlich mit JPG's oder PNG'S je Digit arbeiten müssen.

Die Sache mit dem Fotowiderstand gefällt mir auch noch nicht so richtig. Ich vermute, dass hinter dem Rahmen die Lichtverhältnisse nicht ausreichend sind, damit man einen Effekt sieht.
Eventuell kann man ja einen beliebigen anderen Helligkeit abhängigen Parameter aus FHEM nehmen und ihn per MQTT zum Display senden. Den kann man dann auch nachts und in sonstigen Sondersituationen "manuell" einstellen, egal, wie die Lichtverhältnisse gerade sind.

Naja, schau's Dir erst mal an. Da gibt's sicher noch Einiges zu optimieren.




Pf@nne

Ich weiß momentan zwar nicht was ich zuerst machen soll, aber die Displays machen sich im GIRA-Programm wirklich gut!
Habt ihr die TFTs auch schon mit Touchscreen gesehen?
Habt ihr noch weitere Links zu ggf. günstigeren Displays?

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

Rince

@Pf@nne
Günstiger sind Displays mit ST7735 Chip. Unter 5€ / Stück mit Versand.
Läuft mit ESP8266. (Verdrahtung und Bezugsquelle im Magische-Uhr Thread)
Hintergrundbeleuchtung ist als extra Eingang ausgeführt, der PWM fähig ist.

Wobei 1,8" grenzwertig groß ist.

Grafikausgabe habe ich noch nicht am laufen, nur Textausgabe.

Ich bin mir  aber sicher, dass die OLEDs um die es in diesem Thread geht ein schöneres Bild machen (vor allem blickwinkelstabiler)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

wingfighter

Auch ein sehr interessantes Display. Allerdings wird es nicht ganz in einen GIRA-Rahmen passen. ;-) Von daher "müssen" wir hier erst einmal bei dem NHD-1.69-160128 bleiben, wenn's Farbe und klein sein  soll.
Aber für 5€ wird es sicher das nächste Testobjekt.

@Pf@nne
Ich würde gern Teile Deiner Konfigurations-Library einbauen. Das ist ein sehr guter Ansatz, um nicht immer alle Parameter im Sketch vereinbaren zu müssen.
Allerdings müssen wir dann aufpassen, dass der Speicherplatz nicht ausgereizt wird. Dein Sketch hat 54.436 Bytes (66%). Meiner bis jetzt 36.184 Bytes (44%). Dass sind schon 110% ;-) Sicher sind eine Menge Komponenten doppelt. Aber da gäbe es sicher etwas zu optimieren.

Gruß
wingfighter


Pf@nne

Welchen ESP nutz du denn?
Bei meinem 12e (4M) sind es mal gerade 32% und davon sind 26% ESPCore....... ich glaube nicht, das wie das Ding so schnell vollbekommen.... :-)

Mit der Library (Template) tu dir keinen Zwang an, dafür ist es ja gedacht.
Ist aber noch alpha, von daher mit Vorsicht zu genießen.....

;D
FHEM auf: DS415+ (Master), Raspberry Pi 2