Hallo Zusammen,
ich habe in den letzten Wochen mal wieder zum Lötkolben gegriffen und eine Aufsteckplatine für den Raspery Pi entwickelt.
Dadurch sind leider auch ein paar Weiterentwickungen (Webviecontroll und HM485 Modul) etwas liegen geblieben.
Das ganze besteht aus einem kleinem Graphic-LCD 3 Tastern und 3 LED's (rot, gelb, grün).
Mit einem optionalem CSM-Modul von Busware kann direkt z.B. mit FS20/Homematic-RF komponenten kommuniziert werden.
Alternativ kann die Platine mit einem RS485 Tranceiver z.B. für die Kommunikation mit Homematic-Wired Komponenten bestückt werden.
Das Display kann 128x64 Pixel darstellen und kann für Statusinformationen oder z.B. zur Darstellung eines kleinen Menüs dienen. Das Display hat eine dimmbare weiße Hintergrundbeleuchtung.
Mit den 3 Tasten kann man das ganze Bedienen, und die 3 LED's können als Status-LEDs z.B. für eine Warn/Info Anzeige benutzt werden.
Softwareseitig gibt es dazu derzeit einen kleinen Daemon, der die Ansteuerung des LCD, der LED's und das Auslesen der Tasten übernimmt, und ein FHEM-Modul welches das LCD ansteuern kann. Tastenevents kommen dann auch über das Modul bei FHEM an. Das Modul übernimmt derzeit auch die Menü-Darstellung und die Tastenauswertung.
Das Ganze ist dann in einem Standardgehäuse untergebracht. Und damit das nicht zu sehr bearbeitet werden musste (außer ein paar Löchern) ist das ganze Transparent. Dann noch einen kleine Fuß und schon kann man sich das Ganze beinahe ins Wohnzimmer stellen :)
So sieht das dann aus:
(siehe Anhang / see attachement)
Auf den restlichen Bildern ist die platine ohne RasperyPi zu sehen und ein kleines Menü-Demo.
Falls jemand interesse hat das nach zu bauen kann ich hier gerne noch weitere Infos geben. Ein paar Platinen hätte ich auch noch übrig.
Gruß
Dirk
Hallo Dirk,
absolute Hochachtung, das Teil ist der Hammer. Das sieht so cool aus. Ich hätte da gerne eine Platine.
MfG
Achim
Hallo Dirk,
das ist fast genau das, was mir mittlerweile für den Keller vor schwebt (Anzeige Status bzw. Ölverbrauch, etc..) Hast Du einen Schaltplan? Wie hoch ist die Stromaufnahme? An einer Platine wäre ich auch interessiert, Rest per PM.
Danke und Gruß.
PeMue
Hi PeMue,
Den Schaltplan usw. werde ich mal in einer kleinen Dokumentation zusammenstellen.
Den Gesamtstromverbrauch müsste ich mal messen.
Ich schätze so ca. 10-30mA + max. 60mA Hintergrundbeleuchtung (je nach eingestellter Helligkeit) + Energieverbrauch vom RasperyPi.
Und du willst den armen Raspery nur als schnöde Statusanzeige missbrauchen? Da langweilt der sich doch :)
Gruß
Dirk
Hallo Dirk,
irgendwo muss er ja die Daten herhaben, siehe auch http://forum.fhem.de/index.php?t=msg&th=11874&goto=76701&rid=0#msg_76701 (http://forum.fhem.de/index.php?topic=11874.msg76701#msg76701). Dazu kommt noch die Solaranlage bzw. ggf. mit RS485 die Fotovoltaik ...
Ich gehe mal davon aus, dass der CSM auch den Pin für den Bootloader hat :-)
Da die serielle Schnittstelle durch den CSM belegt ist, wie liest Du dann den RS485 ein? Der RPI hat ja nur eine serielle Schnittstelle, oder?
Gruß PeMue
ZitatIch gehe mal davon aus, dass der CSM auch den Pin für den Bootloader hat :-)
Das ist korrekt.
Es gibt sogar ein kleinen Script zum flashen :)
Auch die ISP-Pins sind nach außen geführt.
ZitatDa die serielle Schnittstelle durch den CSM belegt ist, wie liest Du dann den RS485 ein? Der RPI hat ja nur eine serielle Schnittstelle, oder?
beide teilen sich derzeit den UART. Daher derzeit der Hinweis der alternativen Bestückung. Auf meiner Platine habe ich aber beide bestückt, da ich mal testen will ob man trotzdem beide parallel verwenden kann. Da bekommt halt der eine die Daten vom anderen mit. Und bei gleichzeitigem Senden/Empfangen gibt es Datensalat.
Eigentlich hätte ich noch eine 2. UART per SPI anbinden können. die Idee hatte ich aber erst als die Platinen schon in Produktion waren.
Dann vielleicht das nächste mal.
Gruß
Dirk
Hallo,
damit der Nachbau leichter fällt (Leerplatinen gibt es noch bei mir) ist hier jetzt eine Ausführlich Dokumentation.
Da es einige Anfragen gab: Ich habe alle Bauteile, auch die Displays nachbestellt. Somit könnte ich dann auch die Teile für einen kompletten Bausatz anbieten.
Und falls es Interessenten für eine teilbestückte oder komplett fertige Platine gibt, auch dass ist möglich.
Gruß
Dirk
Hallo,
erstmal *Respekt*.
Das sieht ja genial aus.
Aufgrund dieses Textes von dir
ZitatUnd falls es Interessenten für eine teilbestückte oder komplett fertige Platine gibt, auch dass ist möglich.
und meiner grobmotorischen Fähigkeiten wäre ich an einer fertigen Platine interessiert.
Grüße
ich würde auch eine fertige Platine haben wollen
Hallo zusammen,
ich habe mich gerade frisch registriert, weil ich meine FS20-Komponenten zukünftig mit FHEM steuern will. Jetzt war ich schon kurz davor bei Busware die COC-Erweiterung für meinen vorhandenen Raspi zu kaufen. Dieses Projekt scheint mir doch deutlich interessanter zu sein.
Dirk,
wenn ich das richtig verstanden habe kann Dein Projekt alles, was das COC mit Raspi kann (FHEM hosten und die Komponenten direkt per Funk ansteuern). Aber eben noch deutlich mehr ...
Ich hätte daher wenn möglich auch gerne einen kompletten Teilesatz (ohne Raspi aber alles andere). Bauen möchte ich selbst.
Viele Grüße aus Bayern
Thomas
Hallo Thomas,
Zitatwenn ich das richtig verstanden habe kann Dein Projekt alles, was das COC mit Raspi kann (FHEM hosten und die Komponenten direkt per Funk ansteuern). Aber eben noch deutlich mehr ...
Je nach dem Wie man das betrachtet
Das CSM ist im Prinzip ein CUL ohne USB-Schnittstelle und zumindest mit dem Funkmoduls des COC.
Das CSM, was ich bisher bestücke hat "nur" einen Atmega m324p an Bord. Das reicht für CULFW aber aus. Es gibt aber auch eines mit Atmega m1284p was ein paar Euro teurer ist.
Diese Platine hier hat halt "nur" das Funkmodul für FS20, Homematic usw. an Bord. Dafür kein OneWire und keine RTC und auch keine zusätzliche Spannungsversorgungsbuchse. Dafür aber das LCD mit 3 Tastern und 3 Status-LED's
Gruß
Dirk
Ja so dachte ich mir das schon. Aber das ist auch das, was ich möchte.
Es bleibt also dabei:Ich hätte gern einen kompletten Satz. Platine, CSM, Bauteile, Gehäuse, usw. Gibts auch eine Antenne?
Danke für die schnelle Antwort
Thomas
Die Antenne wie auf dem Bild abgebildet ist mit dabei.
Gruß
Dirk
Hallo Dirk,
zu
ZitatDas CSM, was ich bisher bestücke hat "nur" einen Atmega m324p an Bord. Das reicht für CULFW aber aus. Es gibt aber auch eines mit Atmega m1284p was ein paar Euro teurer ist.
Welches ist den der "grösste" Atmega den das Board noch verträgt?
Wäre es möglich meines mit dem m1284p zu bestücken (Preisdifferenz ist kein Problem)?
Ich vermute mal das flashen der Firmware geht ja gleich wie am "kleineren" m324p.
Ich hab gern noch etwas Luft nach oben für den Fall das mal eine neue grössere Firmware kommt.
Ich mach das bei meinen AVR-Net-IO auch immer.
Der kleine µC raus und ein 644p rein.
Grüße
ZitatWäre es möglich meines mit dem m1284p zu bestücken
Das Kann ich machen. Mal sehen ob ich die Bestellung bei Busware noch geändert bekomme.
Der m1284p hat 128kb Programspeicher, mehr EEPROM, RAM usw, der m324p "nur" 32kb Programspeicher
Allerdings hat der CUL auch nur den m324p verbaut. Daher hätten dann alle CUL-Besizter ein Problem wenn CULFW hier nicht mehr rein passt.
Weiter Unterschiede zwischen m1284p m324p kannst du hier nachlesen:
http://www.atmel.com/images/doc8059.pdf (//www.atmel.com/images/doc8059.pdf)
http://www.atmel.com/images/doc7674.pdf (//www.atmel.com/images/doc7674.pdf)
Hallo Dirk,
danke für die rasche Rückmeldung.
ZitatAllerdings hat der CUL auch nur den m324p verbaut.
Du brauchst die Bestellung nicht versuchen zu ändern - lass mal so weiter wie es ist.
ZitatDaher hätten dann alle CUL-Besizter ein Problem wenn CULFW hier nicht mehr rein passt.
Das hat mich überzeugt ;-)
Grüsse
Hallo Dirk,
ich habe mir gerade nochmal Deinen Schaltplan angeschaut. Dabei ist mir aufgefallen, dass Du die Pins für den I2C-1-Bus für die LED nimmst. Eigentlich wollte ich einen Bausatz bei Dir bestellen und noch einen BMP180-Luftdrucksensor "dazubasteln". Das geht dann wohl aber nicht. Schade. :-(
Ich verstehe aber Deine Äußerungen so, dass Du nochmal eine überarbeitete Platine planst? Könntest Du die Pins 3 und 5 für den I2C-Bus freihalten?
Oder ist im Gehäuse so viel Platz, dass ich auf der Rückseite des RasPi vom P5-Header den I2C-0 abgreifen und eine kleine Breakout-Platine mit dem BMP180 montieren kann?
Gruß
Helmut.
Hallo Helmut,
ZitatIch verstehe aber Deine Äußerungen so, dass Du nochmal eine überarbeitete Platine planst?
Das ist richtig. Das Layout ist schon fertig, aber noch nicht weggeschickt. Daher könnte ich noch ein paar Änderungen einfließen lassen.
Der BMP180 ist ja ganz nett. Könnte man evtl. direkt Pads auf der neuen Platine dafür vorsehen.
Weil so viel Platz ist oben nicht mehr. Nur das manuelle Löten macht bestimmt keinen Spaß.
Da es dem Luftdruck ja eigentlich egal ist wo man den misst, ist das hier in Kombination eigentlich eine schöne Idee.
Nur mit der Temperatur des Sensors wird man nicht viel anfangen können, da es im Gehäuse schon etwas wärmer ist als außen.
Dann könnte man als zusätzliche Option entweder 3 Status-LED's oder 2 Status-LED's + Luftdrucksensor machen. (ein GPIO-Pin ist noch frei)
Oder man bindet den an die I2C-Schnittstelle des CSM an. Dann müsste hier aber auch der Code dafür rein. Dafür währen dann die Pins für die LED's frei.
Gruß
Dirk
Hallo Helmut nochmal ,
ZitatOder ist im Gehäuse so viel Platz, dass ich auf der Rückseite des RasPi vom P5-Header den I2C-0 abgreifen und eine kleine Breakout-Platine mit dem BMP180 montieren kann?
Das kannst du natürlich auch machen.
Zwischen Unterseite der RPI-Platine bis zum Gehäuseboden sind noch etwa 5mm Platz.
LED1 und LED2 würden dann unbestückt bleiben, dann könntest du den Sensor mit Breakoutplatine direkt an den entsprechenden Pins des P5-Header vom RPI anlöten
Edit:
P5 am Raspberry Rev2 ist natürlich der kleine 8-Polige unbestückte Header. Daher stehen hier SDA0 und SCL0 frei zur Verfügung. Das hatte ich oben verwechselt. Daher können die LED's 1 und 2 natürlich weiter benutzt werden.
Gruß
Dirk
Hallo zusammen,
da in der mehrfachen Herstellung der Fuß aus Hobbycolor mir dann doch nicht genau genug geworden ist und in Erinnerung an diese Seite (//www.formulor.de/), habe ich die Teile dort mal Lasern lassen.
Für den ersten Test erstmal in Transparent, Transparent (einseitig matt) und in Weiß.
Und da das Ganze deutlich schneller als gedacht geliefert wurde ist hier schonmal das Ergebniss:
(siehe Anhang / see attachement)
Mein Favorit ist eindeutig Transparent (einseitig matt). Je nach dem wie man die Teile zusammenbaut hat man dann die matte Seite außen oder innen. Bitte gebt mir nochmal bescheid welchen Fuß ihr möchtet. Alternativ gäbe es unter oben genanntem Link auch noch andere Materialien / Farben.
Die Displays sollten übrigens in diesen Tagen kommen, so dass ich die Platinen hoffentlich spätestens nächste Woche versenden kann.
Update: Das Material hier ist übrigens Acrylglas. Also auch deutlich härter als das Hobbycolor.
Gruß
Dirk
Hallo Dirk,
mein Favorit wäre eindeutig der mittlere Fuß (transparent matt). Allerdings werde ich meinen Raspberry Pi in einem kleinen Schaltschränckchen im Keller (mit USB-Hub, AD-Wandler über I2C und D-Logg für die Solaranlage) "versenken" und das Display mit einem Displayglas per Flachbandkabel anbinden. Sobald das fertig ist, werde ich ein Bild posten. Blöd ist nur, dass ich gerade am Wochenende in Sachen Musik so viel unterwegs bin ...
Viele Grüße
PeMue
ZitatAllerdings werde ich meinen Raspberry Pi in einem kleinen Schaltschränckchen im Keller ... "versenken"
Das habe ich mittel bis langfristig auch vor. Daher werde ich mal sehen wir ich den Raspberry mit dem Display anständig in ein Hutschinengehäuse bekomme. Wenn es soweit ist stelle ich das hier bestimmt wieder vor.
ich habe übrigens noch einen kleinen Fehler im Schaltplan gefunden.
C12 hat nur einen Wert von 100nF.
Das ist der Abblockkondensator vom Display.
Das werde ich in den nächsten Tagen aber auch der Doku nochmal entsprechend korrigieren.
@Puschel74: bei Dir ist aber schon der richtige Wert bestückt.
Gruß
Dirk
Hallo,
Paket dankend erhalten.
Perfekt verpackt - ich mach mich gleich mal ans zusammen bauen.
Grüße
Ein kleines Update der Dokumentation:
- Korrektur der Maße für die Gehäusebohrung
- Korrektur einiger Bauteilwerte
Ahh super, ich hab das mal eben schnell überflogen. Mir ist nur aufgefallen, dass der Federring nicht zwischen Buchse und Gehäuse auf der Innenseite sondern immer zwischen Mutter und Gehäuse kommt, sonst hat der eigentlich wenig Sinn auch wenns "scheisse" aussieht.
Und dann:
ZitatDaher sollten für die LED's LED1 - LED3 superhelle LED's verwendet werden.
Meinst du das wirklich so oder meinst du LowCurrent LED's? Weil "superhelle" brauchen weit mehr als die normalen 20mA, da dürfte sich bei 5 mA rein garnichts tun.
Btw. mein Platinchen kommt heute an, dann kann ich ja schonmal den Bräter vorheizen ;-)
Gruß
Daniel
Zitatauch wenns "scheisse" aussieht
Ich glaube daher hab ich das auch so gemacht.
Die Spannung auf die Mutter sollte so trotzdem noch ausreichen. Du kannst das aber auch umdrehen.
ZitatMeinst du das wirklich so oder meinst du LowCurrent LED's?
Derzeit bekommen die LED's < 10 mA. Ich wollte die 3,3V vom PI nicht zu sehr belasten.
Und damit man dann noch was sieht, eben superhell. LowCurrent LED's sind bei gleicher Stromstärke dunkler (fand ich).
Wobei superhell relativ ist. Sagen wir die LED's sind heller als "normale" :)
Gruß
Dirk
Jubel ! Mein Bausatz ist da.
Großes Lob an Dirk. Schneller Versand und sehr ordentlich verpackt. Daran könnte sich der eine oder andere Elektronikversender ein Beispiel nehmen.
Grüße aus dem verregneten Bayern
Thomas
He he dem kann ich nur beipflichten, du hast wohl ein Logistikunternehmen am Start was ;-)
Alles schön in einzelnen Tüten, da brauch ich meine Lupe und mein Multimeter garnicht auspacken. Ein richtig schönes Westpaket, naja oder Ostpaket ;-)
Danke!
/Daniel
Moin,
habe eben nachm Frühstück mal die FPC aufgelötet, das geht aber eigentlich. Ich hab erst mit dem Mini-Fluxer nen bissel Flußmittel aufgetragenm dann die Buchse raufgelegt, die Kannten angelötet und dann noch einmal Fluxer rauf und mit einer größeren Lötspitze einmal langgezogen, das wars, ohne zuführen von Lötzinn, nur das was an der Spitze klebt, das reicht.
Also ist wirklich machbar, auch für die Leute mit wenig Löterfahrung geht das mit etwas Ruhe und Geschick. Die restlichen SMD Bauteile sind schwieriger, die passen nicht zwischen meine Wurstfinger ;-) Und ich hab kein Löthonig da zum ankleben.
/Daniel
ZitatDie restlichen SMD Bauteile sind schwieriger, die passen nicht zwischen meine Wurstfinger ;-) Und ich hab kein Löthonig da zum ankleben.
Ich mache das mittlerweile lieber als "Durchsteckbauteile" löten.
Ich mach das so: zuerst ein Pad verzinnen. Das Teil mit der Pinzette festhalten, Zinn am eben verzinnten Pad aufschmelzen und das Bauelement mit der Pinzette da drauf schieben. Dann ist es das Bauteil fixiert und es kann das/die anderen Pads verlötet werden.
Gruß
Dirk
Also ganz ehrlich: Vor der FPC-Buchse habe ich ein wenig Angst. Bisher habe ich nur "klassische" Löttechnik und nichts mit SMD gemacht.
Was ist denn ein Mini-Fluxer? Und überhaupt "Fluxer?
Ich dachte mir eigentlich, dass ich zunächst mal auf die Lötpunkte Lötfett ("Flussmittel" = FLUXER ??) mit einem Q-Tipp dünn auftrage. Dann, wie von Daniel angesprochen, Kanten mittels Löten fixieren und jetzt die filigranen Beinchen per langsamen entlangziehen mit etwas Lötzinn an ihren Lötpunkten anlöten. Überschüssiges hätte ich mit Entlötlitze entfernt.
Welche Temperatur nehmt Ihr eigentlich für SMD-Bauteile und speziell für die FPC-Buchse. Ich habe Sorge, dass mir die Bauteile oder die Platine verschmort.
Viele Grüße
Thomas
Ein Mini-fluxer: http://www.pkelektronik.com/stannol-flussmittelstift-x32-10i-no-clean-10ml.html (//www.pkelektronik.com/stannol-flussmittelstift-x32-10i-no-clean-10ml.html)
Bitte kein Lötfett verwenden. Lötfett ist in der Regel säurehaltig. Falls du kein Flussmittel zu Hand hast, einfach Kolophonium (gibts auch im Musikladen, wo es auch Geigen gibt) in Spiritus auflösen. Anstelle des Q-Tipp benutze ich einen dünnen Pinsel.
Hier ein Video wie man die Buchse löten kann:
https://www.youtube.com/watch?v=c3iPpsnHKds (//www.youtube.com/watch?v=c3iPpsnHKds)
Für die restlichen Bauteile kann man das so machen:
https://www.youtube.com/watch?v=8whMwCBf8wA (//www.youtube.com/watch?v=8whMwCBf8wA)
Das geht wirklich easy. Wenn man das einmal gemacht hat möchte man keine Durchsteckbauteile mehr löten :)
Temperatur nehme ich immer so um die 280-320 grad. Je nach Zinn. Verschmoren tut dabei noch nichts.
Lediglich beim Löten der LED's darauf achten, dass das nicht zu lange dauert.
Gruß
Dirk
Also ich habe mit 350 Grad gelötet.
Ich fluxe das ein (Flussmittel, in einem Stift von Stannol, in der Industrie gibts Maschinen die auch so benannt werden, also Fluxen ist quasi ein Fertigungsprozess), mach auf die Lötspitze ein WENIG! Lötzinn, lege das Bauteil auf, drücke es mit einer Pinzette fest und drücke einmal die Lötspitze gegen < 1 Sec (Daher auch eine Lötspitze nehmen die nicht zu klein ist, sonst kommt keine Wärme an den Pad) naja und die anderen Seite kann man dann normal verlöten, Spitze rann, Lot zuführen und gut ist. Aber immer mit ganz wenig Lot, sonst hat man sone fetten Beulen da ;-)
Aber die Diode hat mir den Nerv geraubt! Warum muss die auch rund sein ;-) Naja und der Stecker an dem Display für das Licht, den fand ich noch am schwierigsten, ich hab den aber verlötet und nicht nur zuammengepresst, das ist mir immer nichts. Dafür habe ich dann aber wirklich die Lötnadel genommen. Wenn da zu viel Lot drin klebt ist nichts mehr mit crimpem am Ende ...
Der Fluxer ist sehr dünnflüssig, da muss man etwas aufpassen, aber man spart sich das Putzen danach. Wattestäbchen würde ich nicht benutzten! Da lösen sich die kleinen Fusseln, das ist eventuell ein Problem.
Und mit Kolophonium immer etwas aufpassen, nicht einatmen etc. Ist nicht umsonst garnicht mehr zugelassen das Zeugs ;-) Ich glaube da wird heute anderes Material verwendet aber nicht das original Baumharz was es ja letztendlich ist.
So ich habe meine fertig, bis auf das Funkmodul. Mal schauen ob was geht ;-) Aber erstmal gibts Mittag ;-)
/Daniel
Soooo geht alles ;-) Bis auf die rote LED, die hat nen Schuss weg, aber egal, da sind genug LED's kann der Kiste, brauch ich eh nicht. Zur not habe ich noch ne blaue da, dann kommt die rein.
Aber wird gut heiß die Kiste in dem Gehäuse.
/Daniel
ZitatBis auf die rote LED, die hat nen Schuss weg
Zu lange im "Bräter" gehabt?
Dein Umschlag liegt ja noch hier. Soll ich dir noch ne rote LED da rein tun?
ZitatAber wird gut heiß die Kiste in dem Gehäuse.
Daher die Idee mit den Kühlkörpern.
Ich hatte da so ca. 5-10 Grad weniger mit den Teilen.
Derzeit habe ich im Gehäuse am SoC 47 Grad das geht eigentlich.
Gruß
Dirk
Hallo,
die beiden RasPi ohne LCD-Modul haben zwischen 45°C und 47°C und der mit LCD-Modul und Kühlkörper hat auch um die 46°C.
Bei allen ist das Gehäuse aber verschlossen - also kein Oberteil weg gelassen.
Grüße
@Dirk: naja kannste ja noch eine reinwerfen ja, aber nur wenn du den noch auf bekommst, also ansonsten wie gesagt, ich hab noch ne blaue, aber ist echt unwichtig. Das LCD geht und das ist schon genug ;-)
Aber das ich die rote zu lange gebraten habe kann gut sein, die wollte nämlich nicht, da hatte ich wirklich ein paar Probleme, da ist mein Bräter in Stanby gegangen und ich hab das nicht gemerkt und mich gewundert warum hier nichts passert ;-)
Ich werd jetzt mal das Gehäuse bohren. btw. ohne Gehäuse hat meiner 49.77 Grad, bei Zimmertemp von 28 Grad.
/Daniel
Zitataber nur wenn du den noch auf bekommst
Der war noch nicht zu geklebt :)
Zitatbei Zimmertemp von 28 Grad
Ihh. Wohnst du unterm Dach? Wir haben es heute "nur" 24 Grad. Dafür ist es draußen hier heute nur 21 Grad.
Gruß
Dirk
Japp unterm Dach :-(
Und Neubau, da speichern die Wände nur eins, Wärme ...
/Daniel
Hallo,
ich hab einen RasPi im Heizraum - dort meldet ein S300TH 23.1°C und der RasPi sagt 44.39°C,
Ein RasPi sitzt im OG schattenseitiges Zimmer - FHT80b sagt 23.9°C und der RasPi hat 48.15°C und der RasPi im Keller mit LCD sagt 50.31°C (hatte ich den grad in der Hand?????).
Temperaturen sind für mich soweit mehr als ok.
Den LCD-RasPi hatte ich grad vorhin auch etwas "gequält" mit apt-get update und apt-get upgrade - ob das was ausmacht, kA.
Der liegt aber auch vor dem Samsung-Monitor.
Gefräste Lüftungsschlitze im Gehäuse würden sich evtl. anbieten (Platz ist ja noch ;-) ).
Grüße
ZitatGefräste Lüftungsschlitze im Gehäuse würden sich evtl. anbieten (Platz ist ja noch ;-) ).
Da mir die Laser-Möglichkeiten bei Formulor ganz gut gefallen, hatte ich gedacht da Gehäusetechnisch vielleicht noch was zu machen.
Allerdings bin ich Designtechnisch im Moment eher "unkreativ". Vielleicht hat der eine oder andere hier ja eine Idee. Dann könnte man da sicher ein noch schöneres Gehäuse entwickeln.
Grüß
Dirk
Hallo,
ZitatAllerdings bin ich Designtechnisch im Moment eher "unkreativ".
Form follows function - ist hier der falsche Weg denke ich.
Löcher rein wo Platz ist - wenn das Gehäuse etwas grösser wäre dann noch einen Lüfter dazu ^^.
Vergiss den letzten Satz - Löcher würden reichen zum Wärme abführen, je nachdem wo der RasPi steht.
Grüße
ZitatForm follows function - ist hier der falsche Weg denke ich.
Die Idee mit dem neuem Gehäuse hatte ich schon vor ein paar Tagen. Völlig unabhängig von der Themperatur-Diskusion hier.
Ich hab grade mal meine Fritzbox unten befühlt. Die ist deutlich wärmer. Geschätzt 50 Grad außen am Gehäuse. Auf alle fälle unangenehm heiß. Also wird die CPU der Box deutlich darüber liegen.
Daher denke ich mit den 50 Grad am SoC vom Raspberry Pi ist da alles schön.
Gruß
Dirk
Hallo zusammen,
eigentlich dachte ich, dass ich löten könnte. Aber die Buchse für das Display hat mir mehr Schwierigkeiten gemacht, als gedacht.
So habe ich angefangen:
- Buchse draufgelegt und die beiden äußeren Pins mit feiner Spitze angelötet
- dann jeden Pin mit feiner Spitze versucht, anzulöten
-> dann hatte ich zwischen Pin 5 und 6 ruckzuck einen Kurzschluß.
Also das Ganze wieder runtergelötet, die Pins mit Heißluft abgeblasen und wieder von vorne.
Besser ist:
- Pads auf der Leiterplatte dünn mit Flussmittel einstreichen (oder mit dem erwähnten Fluxer)
- die beiden äußeren Pins anlöten (nicht die mechanischen Fixierungen)
- mit einer relativ großen Spitze (damit die Pins auch warm werden) ziemlich nahe am Kunststoff erhitzen und die Spitze der Pins verzinnen
- dann die mechanischen Fixierungen anlöten
Das ganze sieht dann unter dem Mikroskop so
(siehe Anhang / see attachement)
aus. Das sind immer noch keine perfekten Lötstellen, sollten aber für die Anwendung im Keller ausreichen.
Jetzt muss ich nur noch die Zeit finden, den Rest zu bestücken ...
Gruß PeMue
Hallo,
ich habe vergangenes Wochenende die Buchse auch aufgelötet. Bisschen Flussmittel, etwas Lötpaste, Entlötlitze fertig... Schön wärs gewesen. Erstmal zu viel Flussmittel (ich hoffe ich habe alles aus dem Stecker bekommen), dann zu viel Lötpaste die dann wieder mit Lögsauglitze weg musste. Nach der Anleitung vom YouTtube Video ging es trotz 20-jähriger "Lötabstinenz" auf Leiterplattenebenene doch recht gut. Das habe ich mir schwieriger vorgestellt, vor allem da ich "damals" noch keine SMD Bauteile verwendet habe.
Viel schwieriger war das Crimpen der Buchse. Was für ein Gefummel. Ich habe gar nicht gewusst, das meine Finger so dick sind und meine Hände zittern... Zum Glück habe ich ein paar Buchsen mehr bestellt. Ich hatte zwar eine Crimpzange für kleine Stecker, aber so klein... Gibt es dafür überhaupt eine Zange? Jetzt habe ich eine gemischte Lösung mit etwas zu großer Crimpzange und manuellen Nachquetschen mit einer Zange und ein klein wenig Lötzinn. Dabei habe ich festgestellt, das meine kleinste Pinzette viel zu groß für das Halten der kleinen Buchsen ist. Vielleicht hätte ich doch mit dem alternativen DS2423 Zähler mit konventionellen Bauteilen anfangen sollen.
Gestern sind die restlichen Bauteile gekommen. Mal sehen ob ich heute Abend den Rest bestücken kann und eine erste Funktionsprobe der Anzeige möglich ist.
MFG Achim
ZitatViel schwieriger war das Crimpen der Buchse. Was für ein Gefummel.
Falls man nicht vor hat das Display wieder abzunehmen währ auch noch ein direktes anlöten der Backlight-Kabel denkbar.
Damit erspart man sich dann das Gefummel :)
Gruß
Dirk
Hallo,
ich habe die Platine fertig. Und was passierte nach dem ersten Einschalten... nicht viel. Die LEDs liesen sich ansteueren, auch die Taster konnten gelesen werden, auch das Dimmen der Hintergrundbeleuchtung funktioniert. Nur leider blieb die Anzeige dunkel.
Ich will jetzt nicht ein Roman über die Fehlersuche schreiben, letztendlich war es eine kalte Lötstelle am Displaystecker. Es empfiehlt sich, die Verbindungen von den Kontaken oben (oder im Stecker) bis zu den Kondensatoren oder dem GPIO Stecker durchzumessen. Das Messen an den gelöteten Kontakten (oder knapp daneben) bringt keine Sicherheit, da man sehr schnell mit der Messspitze ein kalte Lötstelle überbrückt.
Und man muss darauf achten, dass das Flachbandkabel auch wirklich ganz in der Buchse drin steckt, geht etwas schwer da man das Kabel nicht richtig greifen kann.
MfG Achim
Hi,
die Buchse ist drin. Das war zwar ein ziemlicher Akt, aber ich glaube, dass es jetzt passt. Ich habe es mal durchgemessen und der Kontakt war da.
Jetzt bin ich gerade bei den LEDs. Dirk, kannst Du mir verraten, wie die Polung auf den Bauteilen erkennbar ist? Die Grüne hatte ein Dreieck auf der Rückseite. Schätzungsweise ist die Spitze die Kathode. Die rote hat so eine Art liegendes T auf der Rückseite. Die gelbe hat wieder ein Dreieck.
Für schnelle Hilfe wäre ich dankbar, damit ich weitermachen kann.
Allerseits einen schönen Sonntag.
Grüße
Thomas
Messe das mit ein Multimeter, das ist die einfachste Methode. Ansonsten zeigt die Pfeilspitze zur Kathode (Bei dem T Aufdruck dann die die Spitze des T, das kann man sich ja auch wie ein Pfeil vorstellen)
/Daniel
Hallo zusammen,
"inspiriert" durch die Beiträge habe ich mit dem Stecker für die Hintergrundbeleuchtung folgendes gemacht:
- Stecker locker auf eine Pinzette "gespießt", so dass die Crimkontakte frei sind und nach oben schauen
- Kabel mit wenig Lötzinn angelötet
- danach mit größerer Pinzette gecrimpt
Da mir saudummerweise zwei 180 Ohm Widerstände fehlen, kann ich nicht weitermachen. Aber was solls, dann gibt es heute abend halt mal wieder den Tatort ...
Gruß PeMue
Zitat von: sturmth schrieb am So, 30 Juni 2013 14:37Jetzt bin ich gerade bei den LEDs. Dirk, kannst Du mir verraten, wie die Polung auf den Bauteilen erkennbar ist?
Oh, ein Punkt der noch mit in die Dokumentation gehört. Das werde ich nachpflegen.
Ansonsten, der Tip von Daniel. Mit einem Multimeter im Diodentest ggf. durchmessen.
ZitatDa mir saudummerweise zwei 180 Ohm Widerstände fehlen ...
@PeMue: die 2 x 180 Ohm sind die in dem Fall "nur" Vorwiderstände der LED's. Durch die 180 Ohm kommen an den beiden LED's etwa 10 mA an. 150 - 220 sind auch ok. dann sind die LED's ggf etwas dunkler oder etwas heller.
Was auch gut geht, die SMD Widerstände lassen sich auch gut übereinander löten. Also quasi parallel.
2 x 360 Ohm übereinander gelötet, oder jede andere Kombination die parallel geschaltet 180 Ohm ergeben tuen es auch.
Gruß
Dirk
Hallo zusammen,
am offenen Raspberry Pi sieht die Temperatur nach der Montage der drei Kühlkörper um etwa 19:00 Uhr so
(siehe Anhang / see attachement)
aus. Alles in allem weiß meiner noch nicht so recht, was er tun soll und "blubbert" im Standby vor sich hin, aber mir fällt schon noch das ein oder andere ein ...
Gruß PeMue
Mhh meiner hat bei langer Weile um die 52 Grad im geschlossenem Gehäuse. Aber das Gehäuse ist so dicht, da bringen die Kühlkörper auch nichts weil da ehe keine Luft drann vorbei gleitet. Aber ich meine da muss er durch, dann lebt der eben 2 Jahre weniger, auch egal, bis das Teil stirbt gibts eh was neues und viel besseres auf dem Markt ;-)
/Daniel
Hallo,
einer meiner RasPi hängt im Heizraum um per I2C-Sensoren Vor- und Rücklauf an der Heizung und Warmwasseranlage zu messen.
Wie man schön sieht sehe ich damit genau wann meine Frau die Waschmaschine und den Trockner einschaltet ^^
Der Anstieg der Temperatur passt auch gut mit dem S300TH im Heizraum überein.
(siehe Anhang / see attachement)
Grüße
Edith: Offenes Gehäuse ohne Kühlkörper
Hallo,
der Aufbau hat soweit problemlos funktioniert. Es lief auch alles, - bis auf die beiden äußeren Leuchtdioden. Die waren über die FHEM-Oberfläche nicht zum leuchten zu bringen. Bei dem Versuch sie auszulöten, umzudrehen und wieder einzulöten ist leider eine völlig zerstört worden. Ob die andere jetzt funktioniert probiere ich gleich. Irgendwie ist das mit der Polung der LEDs nicht so ganz trivial bei SMDs.
Grüße aus Bayern
Thomas
Edit:
Ja ich lag richtig. Die grüne und die gelbe sind jetzt ok.
Noch was zur Antenne. Ich habe die Verschraubung am Gehäuse ohne größere Probleme durchgeführt. Vor dem Zusammenbau. Wenn man das Gehäuse schräg zusammenfügt und auf der Antennenseite anfängt, klappt das ganz easy.
ZitatIrgendwie ist das mit der Polung der LEDs nicht so ganz trivial bei SMDs.
Naja was heißt trivial, die Polung ist wichtig genauso wichig wie bei THTs, also von dem her kein Unterschied. Man erkennt es wie schon oben beschrieben an dem Aufdruck. Ich mess das immer fix nach mit einem Multimeter, Diodentest und dann immer gibt ihm, wennse leuchtet schauste wo das rote Kabel ist, und dort ist plus, die andere Seite dann folglich ground.
Und plus ist nicht immer die Seite wo der Widerstand ist, da muss man etwas aufpassen, was auch immer dem Entwickler dazu bewogen hat ;-)
Meine rote LED habe ich auch zerbraten beim ersten Mal, da habe ich zu lange drauf gehalten oder die war wirklich schon defekt. Ich finde die LEDs aber ehe überflüssig. Da sind so viele LEDs in dem Chassis da sieht man die oben eh kaum, aber gut wer eine sinnvolle Anwendung für hat, warum nicht.
/Daniel
Hallo,
ZitatIch finde die LEDs aber ehe überflüssig.
...
aber gut wer eine sinnvolle Anwendung für hat,
Ich hab meinem Schatz nie beibringen können wann sie lüften "darf".
Seit den 3 LED`s oben am RasPi sieht sie auf einen Blick wann sie die Fenster schliessen sollte ^^
Grün = draussen ist kühler als drinnen ergo sollte sie lüften
Gelb (oder Orange) = jetzt wird es Zeit die Fenster zu schliessen
Rot = jetzt aber flott und Fenster zu - oder gar nicht erst öffnen
Ich hab aber noch keine Abfrage drinnen ob Fenster offen sind sondern erstmal Innentemp. zu Aussentemp.
Der Rest wird am Wochenende "programmiert" - geschrieben.
Grüße
Ha ha ha geil, naja das ist natürlich ein Argument ja.
Hi,
busware hat einen draufgesetzt und bietet etwas ähnliches mit Touchscreen an:
http://www.busware.de/tiki-index.php?page=CCD (//www.busware.de/tiki-index.php?page=CCD)
Specs:
- CC1101 transceiver w/ co-processor m1284p with culfw/Contiki - optional ISP header
- ILI9341 based 2.8" TFT Display (240x320)
with touchscreen (ADS7846)
full Linux X11-support DS1338-RealTimeClock with SuperCAP energy storage UMFT200XD-like I2C breakout[/list]
Allerdings würde ich nicht Facebook oder die Tagesschau im Heizungskeller nutzen...
Ich frage mich sowieso, wie sich ein Touchscreen in einer rauen Hausautomationsumgebung auf Dauer verhält.
Cheers,
Helmut.
Auch sehr schön.
Das währ ein nächstes Projekt gewesen. Dann kann ich mir das ja jetzt sparen :)
Hallo,
tomster hat mich auf ein Problem der aktuellen CSM Firmware (1.55) und Homematic hingewiesen.
Ich habe die Version 1.55 und die Version aus dem Trunk noch einmal compilert. Jetzt laufen die auch mit Homematic.
Ich habe beide Versionen hier angehängt. Einmal für das "ältere" CSM mit dem Atmega324p und einmal für das aktuelle CSM mit dem Atmega1284p.
Für das Flashen des neuen CSM muss das Flash-Script angepasst werden:
ausavrdude -p atmega324p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:$1
muss hier avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:$1gemacht werden.
Vor dem Flashen nicht vergessen FHEM zu stoppen :)
Gruß
Dirk
Hallo Dirk,
betrifft der Bug auch die CUNO Firmware? Ich meine, ich habe sowieso keine Homematic und eine "uralte" Firmware, aber rein interessehalber ...
Gruß PeMue
Hi PeMue,
da ich keinen CUNO habe kann ich das leider gar nicht beantworten.
Gruß
Dirk
Hallo zusammen,
habe gerade das Display mit etwa 20 cm Flachbandkabel (RPi kommt in einen Schaltschrank) angeschlossen. Zwei LEDs am Display sind an, eine am CSM ist auch an bzw. die andere blinkt schön lustig vor sich hin, aber die activity LED für das Booten macht gar nichts. Habe schon verschiedene Netzteile probiert, aber bei keinem bootet die Kiste. Mein Einergiemessgerät meldet ca. 3,5 W, so dass eigentlich der Strom (bis 1 A) reichen sollten. Dummerweise steht der nächste Monitor (VGA) zwei Stockwerke höher ;-)
Meine nächsten Schritte wären
- Flachbandkabel durchmessen
- Lötstellen nochmal überprüfen
Hättet ihr sonst noch Ideen? Ich meine, das Flachbandkabel sollte eigentlich kein Thema sein, die Schaltfrequenz bei den GPIOs ist ja relativ niedrig ...
Danke + Gruß
PeMue
ZitatZwei LEDs am Display sind an
Die sind so lange an, bis der LCD-Daemon startet. Dann werden die GPIO's initialisiert.
Zitataber die activity LED für das Booten macht gar nichts
Das kling nach einem Problem der Speicherkarte.
Lade dir für den ersten Test am Besten mal das Image runter. Das sollte laufen.
Gruß
Dirk
Hallo Dirk,
ohne Display bootet die Kiste, aber ich schau mal, ob ich noch eine freie Speicherkarte habe und spiele das Image drauf und boote von da mit Display.
Gruß PeMue
Zitatohne Display bootet die Kiste,
Achso. Und direkt angesteckt, ohne Kabel, wie sieht es da aus?
ZitatAchso. Und direkt angesteckt, ohne Kabel, wie sieht es da aus?
Hmm, Flachbandkabel hat zwei Stecker in den Platinen, da brauch ich 'nen Adapter (2x Buchse aneinander und das möglichst kurz) ...
Hallo Dirk,
Habe den Raspberry mit Deiner Platine, dem LCD und dem CSM aufgebaut und es läuft alles prima. Danke nochmal.
Kurze Frage - die Hintergrundbeleuchtung kann man diese auch abschalten?
ZitatIch habe die Version 1.55 und die Version aus dem Trunk noch einmal compilert. Jetzt laufen die auch mit Homematic.
Ich habe beide Versionen hier angehängt. Einmal für das "ältere" CSM mit dem Atmega324p und einmal für das aktuelle CSM mit dem Atmega1284p.
Nach dem Flashen des CSM auf 1.55 bzw. 1.57 ist mir auf gefallen, dass der RFmode MAX nicht mehr verfügbar ist.
Gruß
Maxel
Hallo Maxel
ZitatKurze Frage - die Hintergrundbeleuchtung kann man diese auch abschalten?
Ja, aber derzeit leider nicht mit dem FHEM-Modul. Da hab ich die Mindesthelligkeit auf 1 beschränkt. Das werde ich wohl mal ändern.
Ansonsten mit dem Client:
/opt/rpiLcdDaemon/client <port> setBacklight,0Der Standartport ist 1234.
ZitatNach dem Flashen des CSM auf 1.55 bzw. 1.57 ist mir auf gefallen, dass der RFmode MAX nicht mehr verfügbar ist.
Wie sieht es bei V 1.52 aus? Leider hab ich keine MAX Komponenten zu testen.
Gruß
Dirk
Hallo Dirk,
auf dem eingepackten CSM-Modul war schon die 1.55 drauf. Dort war MAX einstellbar.
Die Version von culfw.de habe ich noch nicht wieder drauf gespielt.
Gruß Maxel
Leute,
ich bin zu doof, das Display in Betrieb zu nehmen. Meiner Meinung nach ist die Hardware ok, ich habe CSM ohne externe Bauelemente bzw. das Display bestückt.
- mit angeschlossenen 3,3 V und GND ist die Stromaufnahme ca. 15 mA
- die LEDs schalten sauber (+ ca. 6 mA je LED)
- mit 5 V zusätzlich funktioniert das LCD Backlight (bei 100 % Ansteuerung)
- die Taster schalten und haben weder Kurzschluss zu GND noch zu 3,3 bzw. 5 V
- alle anderen Verbindungen zum CSM bzw. zum Display habe ich durchgemessen und die sind ok (auch keine Kurzschlüsse zu GND oder Versorgung)
Wenn die Display Platine über ein kurzes Flachbandkabel (max. 2 cm) angeschlossen ist, "zuckt" die Aktivitäts LED des Raspberry Pi kurz und dann war's das. LED grün und rot sind an (liegt aber vermutlich an der fehlenden Initialisierung, die gelbe CSM LED brennt, das rote Blinken beim CSM ist nicht mehr da, war aber bei den ersten Versuchen vorhanden).
Ich habe den Verdacht, dass der Raspberry Pi über die serielle Schnittstelle etwas senden/empfangen möchte, nicht das bekommt, was er gerne hören möchte und dann stehen bleibt.
Ich habe TTYAMA0 schon auskommentiert bzw. gelöscht wie in busware.de (//busware.de/tiki-index.php?page=COC_Installation) beschrieben. Minicom habe ich auch irgendwann mal installiert, aber nie verwendet.
Wenn ich das Display abstecke, bootet die Kiste, als sei nichts gewesen.
Habt ihr noch Ideen? Ansonsten lade ich mal Dirk's Image runter und probiere ...
Danke + Gruß
PeMue
Edit:
Ohne Displayplatine geht in fhem
define CUL CUL /dev/ttyAMA0@9600 1234
ohne Fehlermeldung durch und das Gerät ist auch noch opened. Ich dachte immer, fhem schickt etwas und wenn es nicht die richtige Antwort bekommt, gibt es eine Fehlermeldung ...
PS: Warum ist die CSM Firmware auf einmal v1.57, wenn im SVN "nur" die v1.55 drinsteht? Oder ist die schon "hochgezählt" und kommt dann ins SVN. Ich frag mal, da ich immer noch hoffe, das Ding zum spielen zu bringen ...
ok, das mit dem Flachbandkabel bzw. oben und unten muss ich noch mal üben.
Fehler war folgender: Wenn Platine A mit Stecker oben (Raspberry Pi) durch ein Flachbandkabel auf Platine B mit Stecker unten (Display) verbunden wird, ist Pin 1 mit Pin 2 vertauscht. Oder das Flachbandkabel muss auf Platine B von oben eingesteckt werden, dann funktioniert es auch wieder ...
Display tut, CSM tut auch (bis auf die Manipulation der LED) und es ist nichts den 5 V Tod gestorben. Ich werde - wenn ich das Display im Deckel des Schaltschranks habe - die Lösung gesammelt posten.
@Dirk: Du bekommst von mir noch ein paar gesammelte Hinweise für die Dokumentation.
Danke nochmal an Dirk für Deine unermüdliche Arbeit.
Gruß PeMue
Gibt es eigentlich schon gute Anwendungen für das Display? Ich bin leider noch nicht wirklich zum Spielen gekommen und erfreue mich noch am dem FHEM Logo ;-)
Aber Füllstandsanzeige der Zisterne, grafisch, oder irgend sone Gags, gibts da schon was?
/Daniel
Hi Daniel,
Da ich alle Befehle für das Display über das Modul in FHEM zur Verfügung gestellt habe, sollte es recht einfach sein mit ein paar Notifys und ein paar Zeilen Perl code da was entsprechendes hinzuzaubern.
Allerdings gebe ich zu, dass das Modul im Moment eher noch ein Beispiel ist. Vor allem die Menüsteuerung, da die noch fest im Code verdrahtet ist.
Ideen nehme ich aber gerne auf :)
Gruß
Dirk
Hallo Daniel,
denkst Du an so etwas?
(siehe Anhang / see attachement)
oder
(siehe Anhang / see attachement)
Ich kämpfe momentan noch mit der 4-bit Farbtiefe, die das Display laut Dokumentation können soll ;-))
Vorstellbar wäre eine Füllstand in 25 oder sogar 10 % Schritten, wo dann zusätzlich entweder oben bzw. seitlich noch der exakte Füllstand als Text (in % oder Litern) angezeigt wird.
Irgendwie stellt mein Display nach einer Weile die ganze Sache invertiert dar und nach ein paar Stunden ist es ganz aus. Ein Neustart des dameons hilft ...
Gruß PeMue
ZitatIch kämpfe momentan noch mit der 4-bit Farbtiefe, die das Display laut Dokumentation können soll ;-))
Echt, hab ich das in geschrieben? Das Display zeigt natürlich nur SW an.
Aber gespeichert sind die Bilder als 16-Farben-Bitmap. Und das hab ich tatsächlich mit Windows-Paint gemacht.
ZitatIrgendwie stellt mein Display nach einer Weile die ganze Sache invertiert dar und nach ein paar Stunden ist es ganz aus. Ein Neustart des dameons hilft ...
Das Display wird per SPI nur geschrieben, nicht gelesen.
Daher ist im Daemon kein echtes spiWait implementiert sondern es wird eine fest eingestellte Zeit gewartet. Wenn die Wartezeit nun zu kurz ist, das Timing weicht von Display zu Display wohl etwas ab, kann es zu solchen Fehlern kommen.
Daher kann man die Wartezeit in
src/libs/rpiHardware.c in der Funktion
rpiHW_spiWait Vergrössern.
void rpiHW_spiWait(void) {
int i;
for(i = 0; i < 10; i++) {
asm("NOP;");
}
}Die 10 oben kann man vergrössern. Ggf. mal 20 Probieren.
Die Grafiken sind übrigens schick :)
Gruß
Dirk
Hallo zusammen,
im Anhang mal was zum Spielen, das Skript im Verzeichnis
script hilft beim Anschauen. Die Herstellerlogos habe ausgespart, weil ich nicht weiß, ob das lizenrechtlich problematisch sein könnte ...
Und hier noch die Hommage an Rudolf:
(siehe Anhang / see attachement)
Für Verbesserungsvorschläge bin ich offen.
Viel Spaß
Gruß PeMue
@Dirk:
Zitatvoid rpiHW_spiWait(void) {
int i;
for(i = 0; i < 10; i++) {
asm("NOP;");
}
}
Ich habe es mal mit 15 probiert und es scheint stabil zu laufen.
Hallo,
sieht ja genial aus.
Ich wollte jetzt endlich mal das LCD als Anzeige benutzen (und PeMues) Skript mal durchlaufen lassen aber ...
wie nicht anders zu erwarten scheitere ich schon an der Installation des rpiLcdDaemon lt. Anleitung.
Ein
sudo mkdir /opt/rpiLcdDaemonscheitert logischerweise mit der Fehlermeldung das das Verzeichnis bereits existiert.
Ein
sudo cp rpiLcdDaemon.tgzscheitert mit der Meldung
ZitatFehlender ZieldateiOperand hinter rpiLcdDaemon.tgz
Als nächster also ganz frech ein
sudo ./scripts/install_startscriptsausgeführt und dadurch die Meldung(en) erhalten
Zitatupdate-rc.d using dependency based boot sequencing
update-rc.d using dependency based boot sequencing
update-rc.d warning: default start runlevel arguments (2 3 4 5) do not match rpiLcdDaemon Default-Start values (S)
Daher bringt mir natürlich auch ein nachfolgendes
sudo /etc/init.d/rpiLcdDaemon startnur ein müdes
ZitatFAIL Starting RasperyPi LCD Daemon : rpiLcdDaemon failed!
So. Und nun bin ich wieder so schlau wie vorher (also garnicht schlau) und bin für jede Hilfe dankbar.
Grüße
Hallo Puschel,
ich dachte, Du hättest schon mal Dirks Image runtergeladen? Da sollte das Ganze doch einigermaßen automatisch laufen.
Ich bin Dirk's Tester und installiere manuell:
- die wiringPi Bibliotheken werden zwingend (also auch mit kompiliertem daemon) gebraucht, diese am besten in /usr/local installieren
- dann im Verzeichnis /opt/rpiLcdDaemon/src folgenes eingeben:
make daemon
make client
make clean
- die entstandenen rpiLcdDaemon bzw. client ein Verzeichnis weiter nach oben schieben
- dann noch einmal
install_startscripts
probieren.
Im Anhang noch ein Skript, dass meinen Bildschirm nach meinem Belieben konfiguriert ...
Viel Erfolg.
Gruß PeMue
Zitat von: PeMue schrieb am Mo, 05 August 2013 20:11im Anhang mal was zum Spielen, das Skript im Verzeichnis
Sehr cool PeMue. Soll ich die Bilder im Github mit einchecken?
Zitat@Dirk:
Zitatvoid rpiHW_spiWait(void) {
int i;
for(i = 0; i < 10; i++) {
asm("NOP;");
}
}
Ich habe es mal mit 15 probiert und es scheint stabil zu laufen.
Gut, dann checke ich das auch mit ein.
Zitat von: Puschel74 schrieb am Mo, 05 August 2013 21:05Ein
sudo mkdir /opt/rpiLcdDaemon
scheitert logischerweise mit der Fehlermeldung das das Verzeichnis bereits existiert.
Wieso existiert das bei dir schon?
sudo cp rpiLcdDaemon.tgzOk, das ist natürlich Quatsch. Da fehlt das Ziel. Das habe ich beim Korrekturlesen bisher immer übersehen.
So muss der Block in der Doku aussehen, bassierend vom aktuellem Verzeichniss in dem das rpiLcdDaemon.tgz sich aktuell befindet:
sudo mkdir /opt/rpiLcdDaemon
sudo cp rpiLcdDaemon.tgz /opt/rpiLcdDaemon
sudo tar -zxvf rpiLcdDaemon.tgz
cd /opt/rpiLcdDaemon
Zitatupdate-rc.d warning: default start runlevel arguments (2 3 4 5) do not match rpiLcdDaemon Default-Start values (S)
Das ist komisch. Auf was für einem Linux bassiert das System auf deinem Raspberry? Ich hatte auf Raspian aufgesetzt.
Gruß
Dirk
Hallo Dirk,
ZitatSoll ich die Bilder im Github mit einchecken?
Ich würde noch warten, bis sich das ganze etwas "stabilisiert" und wir wissen, was so gebraucht wird bzw. die Nomenklatur klar ist. Die Bilder sind alle mit 2 Bit (s/w) Farbtiefe, bei 4 Bit bekomme ich eine Fehlermeldung des
daemons.
Zitatsudo mkdir /opt/rpiLcdDaemon
sudo cp rpiLcdDaemon.tgz /opt/rpiLcdDaemon
Danach müsste noch ein
cd /opt/rpiLcdDaemonsonst kommt beim nächsten Befehl
Zitatsudo tar -zxvf rpiLcdDaemon.tgz
eine Fehlermeldung ;-)
Gruß PeMue
ZitatIch würde noch warten, bis sich das ganze etwas "stabilisiert" und wir wissen, was so gebraucht wird bzw.
Dann warte ich noch.
ZitatDie Bilder sind alle mit 2 Bit (s/w) Farbtiefe, bei 4 Bit bekomme ich eine Fehlermeldung des daemons.
Dann hat mich das Windows Paint bei der Auswahl des Dateiformates angelogen. 2 Bit währen aber auch logisch. Was hast du für ein Programm genommen?
Gruß
Dirk
ZitatWas hast du für ein Programm genommen?
Ich habe IrfanView 4.25 portable genommen.
Gruß PeMue
Moinsen,
ZitatWieso existiert das bei dir schon?
Keine Ahnung.
Ich hab das Image von dir auf meine SD-Karte gespielt und den RasPi gebootet und das Verzeichnis ist vorhanden.
Ich kann heute abend mal den inhalt des Verzeichnisses posten.
ZitatDas ist komisch. Auf was für einem Linux bassiert das System auf deinem Raspberry? Ich hatte auf Raspian aufgesetzt.
Auf welchem Kernel Wheezy beruht müsste ich jetzt googlen.
Grüße und danke schonmal ihr 2
ZitatIch hab das Image von dir auf meine SD-Karte gespielt und den RasPi gebootet und das Verzeichnis ist vorhanden.
Aha, na dann sollte das Verzeichnis auch drauf sein.
Somit musst du aber gar nix machen.
Display anstecken -> einschalten -> Läuft.
Wenn ich mich an die letzten Threads erinnere lief das bei dir doch bereits?
Gruß
Dirk
Hallo,
ZitatWenn ich mich an die letzten Threads erinnere lief das bei dir doch bereits?
Ja. Das lachende Haus schaut mich auch brav an.
Ich bin jetzt nur am schauen wie ich PeMues *.gifs zum durchlaufen bringe.
Daher dachte ich (war wohl doch nicht so das ich das mal wieder versucht habe ^^) ich muss den Daemon noch installieren.
Ich hab natürlich mit keinem Gedanken dran gedacht das der ja schon installiert sein muss und laufen muss um überhaupt die
Shutdown und Bootmeldung zu sehen.
Und die Fail-Meldung kommt vermutlich daher das der Daemon ja schon gestartet ist und nicht nochmal gestartet werden kann
(wozu auch).
Grüße
Hallo Puschel,
ZitatIch bin jetzt nur am schauen wie ich PeMues *.gifs zum durchlaufen bringe.
ich möchte bemerken, dass diese Bilder BMPs sind, mit anderen Formaten kommt der daemon vermutlich nicht klar.
Einfach das ZIP z.B. auf einem Windows Rechner auspacken, z.B. auf /tmp auf dem Raspberry Pi kopieren und in /tmp/scripts das Skript mit <Verzeichnis> als Parameter aufrufen. Dann sollte das Display die Bilder "durchscrollen". Bin gerade dabei, die Zisterne in 20 % Schritten zu erstellen. Da ist das Windows 7 Paint gar nicht so schlecht ...
Gruß PeMue
Hallo,
Zitatdass diese Bilder BMPs sind
Ja ok. Dann eben *.bmp`s ^^
Zitatauf dem Raspberry Pi kopieren und in /tmp/scripts das Skript mit <Verzeichnis> als Parameter aufrufen.
Danke für den Tipp - gleich mal ausprobieren.
Grüße
Zitatich möchte bemerken, dass diese Bilder BMPs sind, mit anderen Formaten kommt der daemon vermutlich nicht klar.
Im unkomprimierten BMP kann man die Pixeldaten halt ohne viel Aufwand auf das Display schieben. Daher wird hier ausschließlich BMP unterstützt.
Gruß
Dirk
Hallo,
naja, man lernt nie aus ;-)
Das Skript sollte natürlich erst mit
chmod a+rx show_images.sh
ausführbar gemacht werden ;-)
Aber schon ok. Nur so lernt man mitdenken.
Das verlange ich von meinen Lehrlingen ja auch immer ;-)
Und nun nochmal eine dumme Frage.
Das Datum und die Uhrzeit bekommt man mit einem einfachen cls im Skript anscheinend nicht weg.
Zumindest bleibt bei mir Datum und Uhrzeit stehen und die Grafiken von PeMue überlappen dadurch ab und zu mal.
So und nun kommts ^^
Wie bekomme ich
a) Datum und Uhrzeit am anfang eines Skripts weg und
b) am Ende eines Skripts wieder auf das LCD?
Danke für Eure Geduld mit mir.
Grüße
P.S.: @PeMue Dein Skript bzw. deine wunderbare Zusammenfassung habe ich leider erst jetzt gesehen da sich das mit unseren beiden Beiträgen überschnitten hat und die Forensoftware eine neue Seite mit meinem Beitrag erstellt hat.
Ich werd gleich mal wiringPi nachinstallieren (sicher ist sicher).
Hallo Puschel,
ich bin gerade nicht an meinem Privatrechner, aber in der Doku müsste etwas mit time (für Start der Uhrzeit/Datum) bzw. timestop (für das Ende) stehen. Einfach über den client schicken und freuen ...
Das mit dem ausführbar machen ist natürlich richtig, ich werde das mal mit reinschreiben ...
Gruß PeMue
PS: Wenn Du Dirk's image hast, sollte wiringPi schon installiert sein. Einfach mal auf Gordon's Seite gehen und die Befehle zum Initialisieren raussuchen und testen.
ZitatDas Datum und die Uhrzeit bekommt man mit einem einfachen cls im Skript anscheinend nicht weg.
Zumindest bleibt bei mir Datum und Uhrzeit stehen und die Grafiken von PeMue überlappen dadurch ab und zu mal.
So und nun kommts ^^
Wie bekomme ich
a) Datum und Uhrzeit am anfang eines Skripts weg und
b) am Ende eines Skripts wieder auf das LCD?
Datum und Uhrzeit werden vom Daemon, sofern aktiviert, selbstständig aktualisiert.
Siehe Befehlsübersicht.
/opt/rpiLcd/Daemon/client 1234 stopDate
/opt/rpiLcd/Daemon/client 1234 stopTimeStoppt die Aktualisierung und verhindert das Wiedererscheinen der Zeit nach einem cls.
/opt/rpiLcd/Daemon/client 1234 date,x,y,fontNum,centuryStartet z.B. das Datum wieder.
Gruß
Dirk
Hallo,
danke ihr 2 für den richtigen Schubs.
@PeMue
Ich werd mich mal schlau machen wg. wiringPi
Dank deiner Erklärung sollte das ja easy sein.
@Dirk (auch auch PeMue)
Ich werd mir die Doku mal ausdrucken und unters Kopfkissen legen (und verinnerlichen).
Dann erübrigen sich meine unnötigen Fragen zum Glück von selbst.
Danke nochmal ihr 2.
Grüße
Edith:
gpio -v
gpio readall
liefert brav Ausgaben.
Also sollte wirinPi installiert sein und funktionieren.
Hallo,
und hier sind die Bilder mit dem Tankinhalt (in 20 % Schritten).
(siehe Anhang / see attachement)
Einfach mal ausprobieren und Rückmeldung an mich ...
Gruß PeMue
Hallo,
ich mal wieder :-)
Auf der fhem-Kommandozeile funktioniert ein
set rpiLCD backlight 255bzw.
set rpiLCD backlight 1Bei ersterem wird die Hintergrundbeleuchtung erwartungsgemäss heller und bei zweiterem dunkler.
Ein
set rpiLCD backlight 0bringt mir ein
ZitatUnknown argument 0, choose one of 1:2:3:4
Und wie ich einen Text über fhem auf das Display bekomme habe ich immer noch nicht zusammen bekommen.
Ok. Letzteres liegt sicher an mir ^^
Aber egal was ich versuche erhalte ich im LogFile immer sowas:
Zitat2013.08.10 21:24:45 1: backlight
2013.08.10 21:24:45 1: cls
2013.08.10 21:24:45 1: led
2013.08.10 21:24:45 1: text
2013.08.10 21:24:59 1: backlight
2013.08.10 21:24:59 1: cls
2013.08.10 21:24:59 1: led
2013.08.10 21:24:59 1: text
2013.08.10 21:25:16 1: backlight
2013.08.10 21:25:16 1: cls
2013.08.10 21:25:16 1: led
2013.08.10 21:25:16 1: text
Für sachdienliche Hinweise bin ich mal wie immer dankbar.
Grüße
Hallo Puschel,
das mit dem Backlight 0 ist vermutlich ein Fehler im fhem Modul. Allerdings habe ich noch nicht herausbekommen, warum das so ist.
Auf der Konsole geht mit
/opt/rpiLcdDaemon/client 1234 setBacklight,0bei Dir das Licht ganz aus ...
Interessanterweise kann der daemon auch nur bis 254 hochzählen.
Gruß PeMue
Zitatdas mit dem Backlight 0 ist vermutlich ein Fehler im fhem Modul.
Ja, kann man vermutlich so sehen :)
Ich bin wohl nicht auf die Idee gekommen dass man die BG-Beleuchtung ausschalten möchte.
Der Daemon kann es. Ich fixe das noch.
Ich habe auch grade gesehen, dass es vom Modul aus ein "set ... text" gibt, aber dass dieses vom Modul gar nicht verarbeitet wird.
Also bekommt man mit reinen FHEM-Mitteln derzeit keinen text auf das Display. Dazu muss mann Shell-Befehle abschicken
Ich stelle die Tage noch ein Update zur Verfügung.
Noch irgendwelche Ideen die ich hier berücksichtigen soll?
Gruß
Dirk
[quote title=Dirk schrieb am So, 11 August 2013 08:43]
ZitatNoch irgendwelche Ideen die ich hier berücksichtigen soll?
Nicht das Du damit die Büchse der Pandorra öffnest :)
Also, ich hätte da mal ein Problemchen mit dem Daemon.
Folgender script wird minütlich über die crontab aufgerufen :
#!/bin/bash
mytemp="Temp:"$(perl -e 'printf (qx(cat /sys/class/thermal/thermal_zone0/temp) / 1000)')
myload=$(uptime | cut -d':' -f5|sed -e"s/,/./g")c
client 1234 text,35,30,$mytemp,0,1
client 1234 text,20,40,"$myload",0,1
das klappt aber immer nur ein paar stunden, danach aktualisert sich die anzeige nicht mehr.
auch ein manueller "client 1234 cls" bleibt einfach hängen. die uhrzeit läuft allerdings weiter.
auch wenn ich den mittleren button lange drücke, komme ich ins menu, und auch wieder zurück.
aber sämtliche versuche per shell den client zu benutzen, bleiben hängen, genauso wie jeglicher /etc/init.d/rpiLcdDaemon start|stop|restart.
ein netstat zeigt mir, das die verbindungen nicht sauber geschlossen werden:
root@raspberrypi:/var/log# netstat -an |grep :1234 |grep VERBUNDEN |wc -l
1112
weiter mit
root@raspberrypi:/var/log# killall -s9 -v client
root@raspberrypi:/var/log# netstat -an |grep :1234 |grep VERBUNDEN
tcp 0 0 127.0.0.1:45750 127.0.0.1:1234 VERBUNDEN
tcp 0 32 127.0.0.1:35382 127.0.0.1:1234 VERBUNDEN
tcp 0 26 127.0.0.1:35390 127.0.0.1:1234 VERBUNDEN
tcp 0 0 127.0.0.1:1234 127.0.0.1:45750 VERBUNDEN
root@raspberrypi:/var/log# client 1234 cls
^C
bleibt also auch wieder hängen, so hilft es nur den daemon mit -9 zu killen und neu zu starten.
was ich noch nit verstehe, ist das wenn ich den client manuell starte die sessions sauber verschwinden.
grüße
jupp
Zitatdas klappt aber immer nur ein paar stunden, danach aktualisert sich die anzeige nicht mehr.
Ui, das sieht mir aber verdammt nach einem Bug im Daemon aus.
Zitatauch wenn ich den mittleren button lange drücke, komme ich ins menu, und auch wieder zurück.
Die erste Verbindung im FHEM bleibt immer offen. Daher funktioniert das hier.
Deine Verbindungen werden geöffnet und anschliessend wieder geschlossen. Und das immer wieder.
Daher wird irgendwann keine Verbindung mehr zugelassen bzw. mit einer neuen nicht mehr korrekt gearbeitet.
aber sämtliche versuche per shell den client zu benutzen, bleiben hängen, genauso wie jeglicher /etc/init.d/rpiLcdDaemon start|stop|restart.Auch ein "/etc/init.d/rpiLcdDaemon start|stop|restart" verwendet die Clientverbindung zum Daemon. Daher könnte das meine o.g. Vermutung bestätigen.
Ich versuche das mal nachzustellen und zu fixen.
Gruß
Dirk
Hallo Dirk,
geschlossen werden die Verbindungen nicht :
root@raspberrypi:/run/shm/grabber# netstat -an |grep :1234 |wc -l
914
Die hängen alle für immer in CLOSE_WAIT.
root@raspberrypi:/run/shm/grabber# netstat -an |grep :1234
tcp 21 0 127.0.0.1:1234 127.0.0.1:56866 CLOSE_WAIT
Hiermit kannst du (kann ich?) den Fehler simulieren :
#!/bin/bash
x=1
while [ $x -le 1023 ]
do
x=$(( $x + 1 ))
echo "text,35,50,Test,0,1" |nc -q0 -w0 127.0.0.1 1234 &> /dev/null
echo $x
done
Grüße
jupp
Nun einer, den ich gar nicht verstehe :
Definert habe ich
fhem> list left_button_short
Internals:
CFGFN
DEF rpiLCD.BTN_LEFT:.Pressed {fhem("set rpiLCD_LED3 on")}
NAME left_button_short
NR 141
NTFY_ORDER 50-left_button_short
REGEXP rpiLCD.BTN_LEFT:.Pressed
STATE active
TYPE notify
Attributes:
fhem> list left_button_long
Internals:
CFGFN
DEF rpiLCD.BTN_LEFT:.Pressed_long {fhem("set rpiLCD_LED3 off")}
NAME left_button_long
NR 142
NTFY_ORDER 50-left_button_long
REGEXP rpiLCD.BTN_LEFT:.Pressed_long
STATE active
TYPE notify
Attributes:
fhem> list right_button_short
Internals:
CFGFN
DEF rpiLCD.BTN_RIGHT:.Pressed {fhem("set rpiLCD_LED1 on")}
NAME right_button_short
NR 143
NTFY_ORDER 50-right_button_short
REGEXP rpiLCD.BTN_RIGHT:.Pressed
STATE active
TYPE notify
Attributes:
fhem> list right_button_long
Internals:
CFGFN
DEF rpiLCD.BTN_RIGHT:.Pressed_long {fhem("set rpiLCD_LED1 off")}
NAME right_button_long
NR 144
NTFY_ORDER 50-right_button_long
REGEXP rpiLCD.BTN_RIGHT:.Pressed_long
STATE active
TYPE notify
Attributes:
fhem>
alles klappt wie es soll. (kurzer druck LED an, langer druck LED aus)
ändere ich aber jetzt nur einen notify zu
fhem> list right_button_short
Internals:
CFGFN
DEF rpiLCD.BTN_RIGHT:.Pressed {fhem("set rpiLCD_LED1 on") ;; system("connair privat an")}
NAME right_button_short
NR 143
NTFY_ORDER 50-right_button_short
REGEXP rpiLCD.BTN_RIGHT:.Pressed
STATE active
TYPE notify
Attributes:
fhem>
(ich möchte die led einschalten und den bash script namens "connair" mit den parametern "privat" und "an" aufrufen)
wird aus :fhem> 2013-08-11 21:01:33 dummy rpiLCD_LED1 on
2013-08-11 21:01:33 rpiLCD rpiLCD BTN_RIGHT: Pressed
2013-08-11 21:01:33 rpiLCD rpiLCD none
das hier (obwohl ich nur den rechten button drücke)
fhem> 2013-08-11 20:59:51 dummy rpiLCD_LED1 on
2013-08-11 20:59:52 rpiLCD rpiLCD BTN_RIGHT: Pressed
2013-08-11 20:59:52 dummy rpiLCD_LED3 on
2013-08-11 20:59:52 rpiLCD rpiLCD BTN_LEFT: Pressed
wo dreh ich mich denn da im kreis, das auf einmal angeblich auch LEFT gedrückt wird ?
danke
jupp
Hallo Fhem Kollegen
dieses Projekt finde ich hoch genial, herzliche gratulation.
Kann ich bitte eine fertig bestückte Platine erwerben und wenn ja, wo.
würde mich darüber sehr freuen.
gruss und danke
Remo
Hallo Remo,
ich hab dir eine PM geschickt.
@Jupp,
sorry für die späte Antwort. Die letzten tage waren hier etwas stressig.
Zitatgeschlossen werden die Verbindungen nicht :
Die Verbindungen wurden schon geschlossen.
Das Problem lag hier am vergessenen pthread_join. Dadurch wurde der Tread nicht wirklich beendet und nach etwa 374 neuen Verbindungen und damit auch neuen Treads konnte kein weiterer Tread mehr gestartet werden. Das hat dann wiederum dazu geführt, dass die folgenden Verbindungen nicht abgearbeitet und dann auch nicht geschlossen worden.
Ich habe das im Github gefixt. Kannst du das bitte einmal testen ob das bei dir soweit funktioniert.
Übrigens bei mehr als 10 Connections pro Sekunde kommt das Display nicht mehr mit der Aktualisierung nach.
Ich habe dein Testscript mal etwas angepasst:
#!/bin/bash
echo "cls" |nc -q0 -w0 127.0.0.1 1234 &> /dev/null
x=1
while [ $x -le 1023 ]
do
x=$(( $x + 1 ))
echo "text,35,50,Test: $x,0,1" |nc -q0 -w0 127.0.0.1 1234 &> /dev/null
echo $x
sleep 0.1
done
Gruß
Dirk
Moin Moin,
guck mal bitte, ob ich mich vertan habe. Das LCD wird initialisiert, über FHEM kann ich z.b. die Helligkeit steuern. "client" funktioniert nicht. weder cls noch setbacklight,auch /etc/init.d/rpiLcdDaemon stop bleibt hängen.
sudo -i
/etc/init.d/rpiLcdDaemon stop
cd /opt
mv rpiLcdDaemon rpiLcdDaemon.org
git clone https://github.com/kc-GitHub/rpiLcdDaemon.git
cd rpiLcdDaemon/src
make clean
make daemon
make client
cp rpiLcdDaemon ../
cp client ../
rm /etc/init.d/rpiLcdDaemon
ln -s /opt/rpiLcdDaemon/scripts/init.d/rpiLcdDaemon /etc/init.d/
update-rc.d rpiLcdDaemon remove
update-rc.d rpiLcdDaemon defaults
/etc/init.d/rpiLcdDaemon start
Danke !
Soweit sieht das gut aus.
Das init.d script musst du beim Neukompilieren aber nicht löschen und wiederanlegen.
So wie es aussieht hab ich hier aber noch einen Fehler eingebaut.
Beim zweiten Client bleibt die Verbindung hängen.
Ich guck da gleich mal.
Gruß
Dirk
So jupp,
du kannst nochmal testen. Jetzt sollte es funktionieren.
Man sollte im ersten C-Projekt halt nicht gleicht mit Treads starten.
Falls einer der hier anwesenden C-Profis mal über den Code schauen möchte, würde ich mich freuen.
Viele Grüße
Dirk
Moin Moin,
läuft seit cirka 12 Stunden ohne Problem, Du scheinst auf dem richtigen Weg zu sein.
Wenn ich das "sleep" entferne, kann ich den Daemon aber immer noch abschiessen, sodaß er keine neuen Verbindungen akzeptiert. Ich kenn mich aber mit C nicht aus, da kann ich nicht helfen.
Was mir noch aufgefallen ist, das die grüne LED bei Start des Daemons eingeschaltet wird. War das vorher auch schon so ?
Und wenn bitte jemand ein paar posts weiter vorne nochmal über die notifies gucken könnte, ich komm da nicht weiter.
danke
jupp
Zitat von: juppzupp schrieb am Mo, 19 August 2013 10:55... dass die grüne LED bei Start des Daemons eingeschaltet wird. War das vorher auch schon so?
Ja, der Daemon initialisiert die grüne LED auf "an".
Gruß PeMue
Hallo
Habe vor einiger Zeit den Pi mit Display bekommen und bin begeistert.
Da ich jetzt demnächst Max Komponenten bekomme wollte ich das CSM auf MAX umstellen. Hier bekomme ich aber Fehlermeldungen das dieses nicht unterstützt wird (bin gerade unterwegs. Genauen Fehler kann ich gerade nicht sagen).
Wie kann ich das CSM mit einer neuen Firmware bespielen?
Danke
Hallo stenny73,
in der Firmware mit der das CSM ausgeliefert wurde ist noch keine MAX-Unterstützung einkompiliert.
In der aktuellen Firmwar ist die Unterstützung mit drinn
ZitatWie kann ich das CSM mit einer neuen Firmware bespielen?
Schau mal in die Doku, Abschnitt "Wie kommt die Firmware in das CSM-Modul?"
Vermutlich musst du im Flash-Script "/opt/rpiLcdDaemon/scripts/CSM-Flash.sh" die richtige MCU noch einstellen. Ich glaube dein CSM hat einen Atmega m1284p an Bord.
Gruß
Dirk
Hallo
bin doch zu doof ;-)
Habe im Script auf "avrdude -p ATMEGA1284P -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:$1"
der SV4 ist gebrückt aber es kommt "Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding"
Bei culfw ist auch nur die 1.55er (die wohl drauf ist daher habe ich die 1.57 von "http://sourceforge.net/p/culfw/code/391/tree/trunk/culfw/Devices/CSM/CSM.hex (//sourceforge.net/p/culfw/code/391/tree/trunk/culfw/Devices/CSM/CSM.hex)" benutzt.
So nun hat es geklappt.... ABER
Auf culfw.de steht zwar 1.55 aber angezeigt bekomme ich die 1.49
Mit der Firmware aus dem SVN bekomme ich es gar nicht angezeigt - CSM blinkt auch nicht.
stenny73
Hallo stenny,
ich habe diese Firmware hier (//sourceforge.net/p/culfw/code/392/tree/trunk/culfw/Devices/CSM/CSM.hex) verwendet und die zeigt die richtige Version an und kann MAX.
Gruß PeMue
Hi
die läuft auch irgendwie nicht an.....
CMDS
"leer"
Clients
:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:
DEF
/dev/ttyAMA0@38400 1234
DeviceName
/dev/ttyAMA0@38400
FHTID
1234
NAME
CSM
NR
20
PARTIAL
STATE
opened
TYPE
CUL
initString
X21
Komisch.....
Hallo stenny,
gibt Dein CSM keine version (VERSION) zurück?
Für MAX muss man mit
attr <CSMname> rfmode MAX umschalten.
Was meinte denn AVRdude? Ist das Flashen sauber durchgelaufen?
Gruß PeMue
Im Log stand immer "CSM: Mode MAX not supported"
Aber jetzt geht es. Die Datei war aus irgendeinem Grund defekt.
Jetzt alles i.O. Hab jetzt aber die r392 genommen.
Nach dem sch... mache ich aber erst Morgen weiter.
Danke nochmal für die Hilfe - war wohl mein Fehler war.....
Hallo zusammen,
hier einmal die CSM-Firmware mit MAX-Unterstützung für den Atmega324p und den Atmega1284p
Gruß
Dirk
Hallo,
@Dirk
Hast du schon ein neues Image für den LCD-RasPi?
Oder ist der letzte Download immer noch aktuell?
Und was machen die Antennenkabel ;-)
Grüße
ZitatOder ist der letzte Download immer noch aktuell?
Ja, ist er. Ich habe das Image noch nicht wieder aktualisiert. Wenn die neue FHEM-Version draussen ist, dann werde ich das sicher aktualisieren.
ZitatUnd was machen die Antennenkabel ;-)
Antennenkabel sind inzwischen da. Neue Platinen sind aber noch in Arbeit.
Gruß
Dirk
Hallo zusammen,
ich habe nun auch erfolgreich das Board aufgebaut und in Betrieb genommen.
(Danke an Dirk für den vorbildlichen zusammengestellten Teilesatz)
Nachdem ich das CSM Modul auf die FW 1.57 geflash habe, klappt es auch mit der Kommunikation mit meinen HomeMatic Komponenten.
Die von Hause aus geflashte Vers. 1.55 wollte nicht .......
Nun brauche ich Hilfe beim Ausgeben von Text auf dem Display.
Über die Konsole ist es kein Problem, da klappt alles.
ZitatIch habe auch grade gesehen, dass es vom Modul aus ein "set ... text" gibt, aber dass dieses vom Modul gar nicht verarbeitet wird.
Also bekommt man mit reinen FHEM-Mitteln derzeit keinen text auf das Display. Dazu muss mann Shell-Befehle abschicken
Ich stelle die Tage noch ein Update zur Verfügung.
Noch irgendwelche Ideen die ich hier berücksichtigen soll?
Konkret möchte ich die Temperatur und Luftfeuchtigkeit von meinem HM-WDS40-TH-I auf dem Display ausgeben.
Da ich nicht der Programmier-Profi bin, helfen mir Beispiele weiter, die ich abändern kann.
Schon mal Danke für eure Hilfe.
Gruß
Klaus
Hallo Klaus,
ich patche nicht gerne in anderen Modulen, Dirk wird mit bestimmt verzeihen.
Als "quick workaround" anbei mein 00_RPI_LCD.pm.
Mit set <lcd_name> text <zeile [0:4]> <text_mit_underscores> müsste sich jetzt etwas auf den Bildschirm zaubern lassen.
Folgende Einschränkung:
- der Text hört ab dem ersten Leerzeichen auf, daher die underscores
Ich weiß leider nicht, wie man in Perl die Parameter übergibt, '' und "" gehen nicht.
Die Zeilen mit der Analoguhr kannst Du ja rauswerfen, war ein Versuch von mir ...
Gruß PeMue
Hallo Peter,
danke für die schnelle Antwort.
Sehe ich es richtg, das ich dein geändertes Modul 00_RPI_LCD.pm in das Verzeichnis:
/opt/fhem/FHEM kopieren muss ?
und das "alte" Modul 00_rpiLCD.pm kann / muss da bleiben ?
(eigendlich ist das bei mir nur ein symbolischer Link)
Gruß
Klaus
Hallo Klaus,
benenne Dein altes Modul um und speichere meines da ab, wo das alte war. Dann sollte auch der symbolische Link wieder funktionieren.
Gruß PeMue
Hallo Peter,
dein gepatchtes Modul habe ich zum laufen gebracht.
Ich mußte noch in der fhem.cfg die Definitionen anpassen.
Alt: rpiLCD
Neu: RPI_LCD
Danke, nun kann ich mich einer anderen Baustelle widmen.
Gruß
Klaus
Moin zusammen,
ich benötige noch mal einen Tipp, wie ich eine "Variable" als Text auf dem Display ausgeben kann.
mit:
set RPI_LCD text 0 Hallo_Klaus
bekomme ich ja nun wunderbar was auf das Display, möchte aber gerne Messwerte vom Temperatursensor letztendlich an dem Display anzeigen.
Schon mal Danke
Gruß
Klaus
Hallo Dirk,
hast du noch Platinen? Kann ich bei dir noch einen Komplettsatz erwerben?
Ich fange gerade erst mit fhem an und habe gerade meinen PI und
will jetzt erst mal zum testen das licht im Schalfzimmer mit FS20 komponenten
zu schalten. Wenn ich deinen Bausatz nehme brauche ich doch keinen CUL mehr oder?
Mfg
ed_2
Hallo Ed,
ZitatWenn ich deinen Bausatz nehme brauche ich doch keinen CUL mehr oder?
Wenn Du das CSM auf der Platine bestückst, dann brauchst Du keinen CUL mehr. Das Programmieren der Firmware geht auch sehr schön, RPi hängt im Keller und vom Büro aus kann ich flashen ...
Gruß PeMue
Hallo ed_2,
Zitathast du noch Platinen?
Im Moment sind Platinen bestellt, und sollten nun hoffentlich nächste Woche hier ankommen. Diejenigen die bisher warten mussten bitte noch etwas gedult.
ZitatKann ich bei dir noch einen Komplettsatz erwerben?
Ja, ich schicke dir zu den Details eine PM
ZitatWenn ich deinen Bausatz nehme brauche ich doch keinen CUL mehr oder?
Wenn du den mit CSM-Modul bestellst, so wie PeMue schon richtig sagte, ersetzt das CSM den CUL.
Gruß
Dirk
Hallo Klaus,
versuchs mal damit:
my $wert=22.34;
my $ausgabe="Hallo_Klaus_der_Wert_ist:_".$wert;
set RPI_LCD text 0 $ausgabe
Habe es noch nicht getestet und wahrscheinlich vermische ich Perl und fhem code, aber vielleicht funktioniert es ...
Gruß PeMue
Hallo Peter,
entschuldige das ich erst jetzt auf deinen Tipp reagiere.
Habe momentan etwas "Umzugsstress" (Schwiegereltern ziehen um ....), und da ist Hilfe angesagt.
Nun zu deinem Vorschlag:
klaptt nicht, leider ...
Der Perl-Code muß, soweit ich es verstanden habe, in {}-Klammern gesetzt werden.
Das Problem ist aber irgendwie die Übergabe von der Variablen an das Display.
Die folgende Zeile:
set RPI_LCD text 0 $ausgabe
läßt auf dem Display nur den Text: $ausgabe erscheinen.
Evt. hat der Dirk als "Entwickler" ja noch einen Lösungsvorschlag parat ?
Schöne Grüße
Klaus
Hi Klaus,
ZitatEvt. hat der Dirk als "Entwickler" ja noch einen Lösungsvorschlag parat ?
Bestimmt. Allerdings komme ich erst am Wochenende dazu. Kann sein das es hier auch noch was fehlt im Code.
Gruß
Dirk
Hallo Dirk,
ich habe die Textausgabe in Dein Modul implementiert (siehe ein paar Ecken weiter vorne). Mein Problem ist aber, wie bekomme ich Text mit Leerzeichen bzw. Text und Variablen ausgegeben. Wär's in C wärs kein Problem, aber mit Perl bin ich noch nicht so vertraut.
Gruß PeMue
Das hier:
sub
prg_LCD_Anzeige()
{
my $zeile_0 = sprintf("%.1f",ReadingsVal("Temp.AZ","temperature",0))." °C";
fhem ("set LCD line20.0 Temp: $zeile_0");
}
müsste in etwa (LCD Aufruf ändern) auch bei Dir funktionieren. Damit kann ich auf dem 1-Wire-Display z.B. die Temperatur eines DS1820 anzeigen. Per Notify wird dieses Unterprogramm aus der 99_myUtils aufgerufen.
Zitatich habe die Textausgabe in Dein Modul implementiert (siehe ein paar Ecken weiter vorne)
Ja, das habe ich gesehen. Das hatte ich hier auch schon liegen. Du warst aber schneller :)
Daher will ich das die nächsten tage auch mal wieder aktualisieren.
Gruß
Dirk
Hallo zusammen,
jetzt habe ich ein für mich ungelöstes Problem:
Ich schalte beim Raspberry Pi per crontab (als root) mit
/sbin/ifup wlan0 und
/sbin/ifdown wlan0 das WLAN zeitgesteuert ab. Funktioniert auch, ohne das der vcontrold (der auch auf 127.0.0.1 abfragen kann) stehen bleibt.
Jetzt wollte ich das LCD Display nutzen, um in einem Menüpunkt das WLAN bei Bedarf wieder einzuschalten.
#------------------------------------------------------------------------------
# RPI_LCD_menuWlanOn (PeMue)
# start with sudo ifup wlan0
# stop with sudo ifdown wlan0
# get status with ifconfig wlan0
#------------------------------------------------------------------------------
sub RPI_LCD_menuWlanOn($) {
my ($hash) = @_;
my ($hash, $buttonState) = @_;
my $cmdline;
my $state;
my $result;
RPI_LCD_contentClear($hash);
RPI_LCD_command($hash, 'setFont,0');
# $cmdline = 'ifconfig wlan0 2>&1 | grep UP';
$cmdline = "ip -o addr show | grep inet | grep wlan0";
$result = `$cmdline`;
Log (3, "vor Abfrage: $result");
if (length($result) == 0) # WLAN is off
{
$cmdline = "sudo /sbin/ifup wlan0 &";
# $cmdline = "sudo ifconfig wlan0 up";
Log (3, "Einschalten: $cmdline");
$state = qx($cmdline);
Log (3, "WLAN eingeschaltet: $state");
RPI_LCD_command($hash, 'text,0,13,WLAN:eingeschaltet,0,1');
}
else # WLAN is on
{
RPI_LCD_command($hash, 'text,0,13,WLAN:an,0,1');
}
}
Die Abfrage funktioniert, aber das WLAN schaltet sich ums Verr... nicht ein. Was mache ich falsch? Ich habe es schon mit ' und mit " bzw. auch mit qx() probiert, aber es klappt nicht. Ich weiß, dass das Einschalten lange dauert, daher das & am Ende.
Wäre klasse, wenn mir jemand einen Tipp hätte.
Danke + Gruß
PeMue
Zitat von: PeMue schrieb am Do, 26 September 2013 08:32Was mache ich falsch? Ich habe es schon mit ' und mit " bzw. auch mit qx() probiert
' und " wird nicht klappen, das entsprechende Zeichen für qx() ist der rückwärts-Accent `
Gib mal in Deiner $cmdline die kompletten Pfade (sowohl für sudo als auch für ifup) mit an. Das & am Ende kannst Du weglassen.
Hallo zusammen,
da es mit der Software nicht so ganz klappt, habe ich das Display über Flachbandkabel in den Schaltkasten eingebaut:
(siehe Anhang / see attachement)
Jetzt brauche ich nur noch einen Streifen schwarzes Tonpapier für den Rand. Cool finde ich die abgesägte LED für die beiden LEDs (Duo LED?) vom CSM. Doku folgt.
Gruß PeMue
Hallo zusammen,
ich habe von Dirk meine Platine bekommen und die auf meinen
Raspberry aufgesteckt. Jetzt leuchtet das LCD hell und beim starten wird
folgendes im LOG angezeigt.
2013.10.13 22:01:24 0: Server shutdown
2013.10.13 22:01:44 1: Including fhem.cfg
2013.10.13 22:01:46 3: telnetPort: port 7072 opened
2013.10.13 22:01:48 3: WEB: port 8083 opened
2013.10.13 22:01:48 3: WEBphone: port 8084 opened
2013.10.13 22:01:48 3: WEBtablet: port 8085 opened
2013.10.13 22:02:04 1: Including ./log/fhem.save
2013.10.13 22:02:04 1: statefile: Please define CUL_0 first
2013.10.13 22:02:04 1: usb create starting
2013.10.13 22:02:07 3: Opening CUL device /dev/ttyAMA0
2013.10.13 22:02:09 3: Setting CUL baudrate to 38400
2013.10.13 22:02:09 3: CUL device opened
2013.10.13 22:02:09 1: define CUL_0 CUL /dev/ttyAMA0@38400 1034
2013.10.13 22:02:10 3: Opening CUL_0 device /dev/ttyAMA0
2013.10.13 22:02:10 3: Setting CUL_0 baudrate to 38400
2013.10.13 22:02:10 3: CUL_0 device opened
2013.10.13 22:02:10 3: CUL_0: Possible commands: mBCFiAGMRTVWXefltx
2013.10.13 22:02:10 1: usb create end
2013.10.13 22:02:10 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2013.10.13 22:02:10 0: Server started with 27 defined entities (version $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $, os linux, user fhem, pid 1111)
Was muss ich jetzt weiter machen??
Ich habe von einm RPI_LCD Modul gelesen und in der PDF steht was von rpiLcdDaemon.tgz
wo kann ich das downladen? Was muss ich noch installieren?
@Dirk hast du das CUL/CNC schon geflasht??
Ich betreibe Rasbmc und darauf FHEM und will FS 20 komponenten schalten.
Wer kann mir weiter helfen??
Besten Dank
ed_2
Ich warte auf betateilchens Komentar. "Duck und weg"
Hallo ed_2
in dem Thread weiter vorne (http://forum.fhem.de/index.php/topic,12854.msg83311.html#msg83311 (http://forum.fhem.de/index.php/topic,12854.msg83311.html#msg83311)) hat Dirk eine Doku gepostet. Da ist die komplette Anleitung zur Softwareinstallation drin.
Die Software ist unter https://github.com/kc-GitHub/rpiLcdDaemon (https://github.com/kc-GitHub/rpiLcdDaemon) zu finden. Steht im anderen Thread http://forum.fhem.de/index.php/topic,13221.msg83321.html#msg83321 (http://forum.fhem.de/index.php/topic,13221.msg83321.html#msg83321)
MfG
Achim
Hi,
ja die Anleitung hatte ich auch gelesen und den GIT habe ich auch gefunden.
Nur wie lade ich da was runter wie komme ich an die tgz Datei?
Irgendwie bin ich zu blöd dazu.
Mfg
ed_2
Hallo ed_2
der Downloadbutton auf GITHUB ist bei mir immer rechts im unteren Drittel des Bildschirms. So als grobe Orientierung. ;) Dort bekommts du das gesamte Paket als ZIP. Dann eben nach Dirks Anleitung anstelle des TGZ Archives das ZIP verwenden und den entsprechenden unzip anstelle des tar verwenden. Oder auf einem Windows System entpacken und mit z.B: WINSCP auf den RPi kopieren.
Oder du holst dir das komplette Image von Dirk (http://forum.fhem.de/index.php/topic,13221.msg83321.html#msg83321 (http://forum.fhem.de/index.php/topic,13221.msg83321.html#msg83321)) und "baust" darauf deine FHEM Installation auf.
MfG
Achim
Hallo zusammen,
ihr könnt mich ja für blöd halten aber es funktioniert noch immer nicht.
Jetzt kommt folgende Meldung.
pi@raspbmc:/opt/rpiLcdDaemon$ sudo ./scripts/install_startscripts
update-rc.d: using dependency based boot sequencing
update-rc.d: using dependency based boot sequencing
update-rc.d: warning: default start runlevel arguments (2 3 4 5) do not match rpiLcdDaemon Default-Start values (S)
pi@raspbmc:/opt/rpiLcdDaemon$ sudo /etc/init.d/rpiLcdDaemon start
[ ok ] Starting RasperyPi LCD Daemon : rpiLcdDaemon.
pi@raspbmc:/opt/rpiLcdDaemon$ /opt/rpiLcdDaemon/client 1234 setBacklight,100
/opt/rpiLcdDaemon/client: error while loading shared libraries: libwiringPi.so.1: cannot open shared object file: No such file or directory
pi@raspbmc:/opt/rpiLcdDaemon$
Danach habe ich nach dieser Anleitung wiringpi installiert.
https://projects.drogon.net/raspberry-pi/wiringpi/
Dazu musste gcc und make noch installiert werden aber ich bekomme immer noch
diese Meldung und am Display ändert sich nichts es kommt keine Anzeige.
Was kann ich noch machen?
Mfg
ed_2
Hi ed_2,
also entweder ist WireingPi nicht richtig installiert. Oder aber in einem anderen Verzeichniss.
Starte doch mal das kompiliere den Deamon doch noch einmal neu.
Einfach in das src-Verzeichniss wechsel und make eingeben.
cd /opt/rpiLcdDaemon/src
make
cp rpiLcdDaemon ..
Wenn es keine Fehler gab, dann sollte es danach funktionieren.
Gruß
Dirk
Hallo Dirk,
jetzt hat es soweit funktioniert das jetzt die Anzeige auf den Display erscheint.
Wenn ich aber den Befehl zum dimmen des Displays gebe kommt immer noch der Fehler.
Anbei mal die Befehle die ich eingegeben habe und die Meldungen die dann kamen.
pi@raspbmc:/opt/rpiLcdDaemon/wiringPi$ cd /opt/rpiLcdDaemon/src
pi@raspbmc:/opt/rpiLcdDaemon/src$ make
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -c -o rpiLcdDaemon.o rpiLcdDaemon.c
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -c -o libs/lcd.o libs/lcd.c
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -c -o libs/utility.o libs/utility.c
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -c -o libs/server.o libs/server.c
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -c -o libs/command.o libs/command.c
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -c -o libs/timer.o libs/timer.c
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -c -o libs/rpiHardware.o libs/rpiHardware.c
gcc -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -O0 -Wall -g -D_REENTRANT -o rpiLcdDaemon rpiLcdDaemon.o libs/lcd.o libs/utility.o libs/server.o libs/command.o libs/timer.o libs/rpiHardware.o -lrt -I/usr/local/include -L/usr/local/lib -lwiringPi -lpthread
pi@raspbmc:/opt/rpiLcdDaemon/src$ cp rpiLcdDaemon ..
pi@raspbmc:/opt/rpiLcdDaemon/src$ cd ..
pi@raspbmc:/opt/rpiLcdDaemon$ ls -l
total 108
-rwxrwxrwx 1 root root 87 Aug 18 10:46 README.md
-rwxrwxrwx 1 root root 11423 Aug 18 10:46 client
drwxrwxrwx 2 root root 4096 Oct 14 13:35 images
-rwxrwxrwx 1 root root 75098 Oct 14 20:54 rpiLcdDaemon
drwxrwxrwx 3 root root 4096 Oct 14 13:35 scripts
drwxrwxrwx 6 root root 4096 Oct 14 20:53 src
drwxr-xr-x 8 root root 4096 Oct 14 18:26 wiringPi
pi@raspbmc:/opt/rpiLcdDaemon$ sudo /etc/init.d/rpiLcdDaemon start
[ ok ] Starting RasperyPi LCD Daemon : rpiLcdDaemon.
pi@raspbmc:/opt/rpiLcdDaemon$ cd /opt/rpiLcdDaemon
pi@raspbmc:/opt/rpiLcdDaemon$ sudo ./scripts/install_startscripts
update-rc.d: using dependency based boot sequencing
update-rc.d: using dependency based boot sequencing
update-rc.d: warning: default start runlevel arguments (2 3 4 5) do not match rpiLcdDaemon Default-Start values (S)
pi@raspbmc:/opt/rpiLcdDaemon$ /opt/rpiLcdDaemon/client 1234 setBacklight,100
/opt/rpiLcdDaemon/client: error while loading shared libraries: libwiringPi.so.1: cannot open shared object file: No such file or directory
pi@raspbmc:/opt/rpiLcdDaemon$ sudo /opt/rpiLcdDaemon/client 1234 setBacklight,100
/opt/rpiLcdDaemon/client: error while loading shared libraries: libwiringPi.so.1: cannot open shared object file: No such file or directory
pi@raspbmc:/opt/rpiLcdDaemon$
Was kann ich da noch machen? Oder ist das so OK?
Mfg
ed_2
Soweit sieht alles gut aus.
So wie es aussieht ist der der Client aber auch gegen die wiringPi libs gelinkt. was eigentlich nicht sein müsset.
Mach noch mal ein:
cd /opt/rpiLcdDaemon/src
make client
cp client ..
Aber, den Client brauchst du im Einsatz mit FHEM nicht. Wenn du also das Startbilld bereits siehst, sollte das auch jetzt schon funktionieren.
Gruß
Dirk
Hi,
habe ich auch gemacht und bekomme jetzt keine Fehlermeldung mehr
aber das Display wird auch nicht dunkler.
pi@raspbmc:/opt/rpiLcdDaemon$ /opt/rpiLcdDaemon/client 1234 setBacklight,100
RaspberryPi LCD deamon
Backlight 100 is set.
Mfg
ed_2
Frage zu backlight: Ich habe in der config am Ende de Sequenz des LCD Parts "set rpiLcd backlight 1" eingegeben. Das klappt und das Display wird dunkler. Wenn ich aber nach längerer Zeit wieder auf das Display schaue, hat es die urspüngliche Helligkeit wieder. Ein Aufruf von fhem und eine Eingabe von "set rpiLcd backlight 1" in die Befehlszeile bewirkt wieder ein abdunkeln des Displays. Warum schaltet es immer wieder hoch?
Zitat von: ed_2 am 14 Oktober 2013, 21:25:27
aber das Display wird auch nicht dunkler.
100 ist schon ziemlich hell.
Mit
/opt/rpiLcdDaemon/client 1234 setBacklight,1Sollte es deutlich dunkler werden.
Zitat von: stgeran am 15 Oktober 2013, 08:15:36
Frage zu backlight: Ich habe in der config am Ende de Sequenz des LCD Parts "set rpiLcd backlight 1" eingegeben. Das klappt und das Display wird dunkler. Wenn ich aber nach längerer Zeit wieder auf das Display schaue, hat es die urspüngliche Helligkeit wieder.
Ich habe in der Beispilekonfiguration eine einfache Automatische Helligkeitssteuerug nach Daylight eingebaut. Das überschreibt deine Manuelle Ändeurng. Das kannst du einfach ausschalten.
Gruß
Dirk
Nach welchem Sensor fragt Dein Daylight? Das heist, es regelt sich automatisch? Wäre ja cool :-)
Das Ganze funktioniert ohne Hardwaresensor mit dem Twilight-Modul. von FHEM.
http://fhem.de/commandref.html#Twilight
Abhängig vom errechneten Sonnenstand nach geographischen Standort, Jahreszeit und Uhrzeit.
Gruß
Dirk
Hallo Dirk,
ZitatDas kannst du einfach ausschalten.
Und wie schalte ich das ab? In
fhem oder im
daemon?
Danke + Gruß
PeMue
PS: Freut mich, mal wieder regelmäßiger von Dir zu hören. Ich habe noch eine Liste mit Optionen/Wünschen/Verbesserungen für das LCD und den daemon ;)
Hi PeMue,
ZitatUnd wie schalte ich das ab? In fhem oder im daemon?
Im FHEM.
"Einfach" das TWILIGHT löschen bzw. anpassen.
ZitatPS: Freut mich, mal wieder regelmäßiger von Dir zu hören. Ich habe noch eine Liste mit Optionen/Wünschen/Verbesserungen für das LCD und den daemon.
Ich fürchte das muss derzeit etwas warten.
Ich will vorher das HM-Wired Zeugs endlich mal in einen funktionerenden Stand bringen
Gruß
Dirk
Hallo Dirk,
dem was der PeMue geschrieben hatte.........
Zitat von: PeMue am 15 Oktober 2013, 22:46:08
PS: Freut mich, mal wieder regelmäßiger von Dir zu hören. Ich habe noch eine Liste mit Optionen/Wünschen/Verbesserungen für das LCD und den daemon ;)
.......schließe ich mich voll an.
Gruß Klaus
Moin zusammen,
ich habe noch ein Problem mit dem LCD Display. Hin und wieder steht der Inhalt auf dem "KOPF".
Es reagiert auf Befehle, aber nur ein komplettes Reboot vom Raspi bringt es wieder dazu "normal" zu sein.
Hat jemand eine Idee wo ich den Fehler suchen kann ?
Gruß
Klaus
Hallo Klaus,
Das Problem liegt hier am Timing der Display-Ansteuerung. Im Daemon muss dafür ein Wait etwas verlängert werden.
Benutzt du mein Image oder benutzt du den Deamon von Github. Hier sollte das Timing bereits entsprechend angepasst sein.
Gruß
Dirk
Hallo Dirk,
ich benutze das Image von dir.
Gruß
Klaus
Hi Klaus,
Dann lade dir mal bitte den letzte Master:
https://github.com/kc-GitHub/rpiLcdDaemon/archive/master.zip
In dem Zip (im Verzeichniss src) ist auch bereits eine kompilierte Version des Deamon.
Diesen bitte mit deinem austauschen. Dann sollte das nicht mehr auftreten.
Gruß
Dirk
Hallo Dirk,
habe ich gerade mal ausgeführt:
Zitat von: Dirk am 26 Oktober 2013, 12:51:46
Dann lade dir mal bitte den letzte Master:
https://github.com/kc-GitHub/rpiLcdDaemon/archive/master.zip
Ich werde mal beobachten ob das "Problem" nun weg ist.
Es trat ja nur sehr sporadisch auf ...
Danke für den Tipp.
Gruß Klaus
Hallo Dirk,
ich habe in rpihardware.c
Zitat/**
* wait some cpu cycles
*
* Parameter: void
* Return: void
* changed from 10 by PeMue
*/
void rpiHW_spiWait(void) {
int i;
for(i = 0; i < 25; i++) {
asm("NOP;");
}
}
schon von 10 auf 25 erhöht, allerdings steht das Display manchmal auch noch Kopf. In github ist noch 10 drin. Wo hast Du etwas geändert? Wenn es mit 700 MHz geht, müsste man nicht auch für Übertakten Reserve lassen?
Danke + Gruß
PeMue
Hi PeMue,
ich hätte schwören können, dass ich das schon gepushed hatte.
Ich habe es mal direkt im Github geändert.
Im Moment komme ich nicht an mein DEV-Rpi, weil der zu Hause liegt.
Kannst du einmal testen ob bei dir auch ein Wait von 50 funktioniert.
Gruß
Dirk
Hallo Dirk,
erst mal vielen Dank für dein Projekt und den reibungslosen Bestellablauf.
Leider bekomme ich mit der installierten Firmware (V 1.57 CSM868) MAX nicht zu laufen.
2013.11.10 10:30:29 3: Opening CSM device /dev/ttyAMA0
2013.11.10 10:30:29 3: Setting CSM baudrate to 38400
2013.11.10 10:30:29 3: CSM device opened
2013.11.10 10:30:29 3: CSM: Possible commands: mBCFiAGMRTVWXefltx
2013.11.10 10:30:29 2: CSM: Mode MAX not supported
2013.11.10 10:30:29 3: CSM: Mode MAX not supported
2013.11.10 10:30:30 3: No I/O device found for cm
2013.11.10 10:30:30 1: cm: did not find suitable IODev (CUL etc. in rfmode MAX)! You may want to execute 'attr cm IODev SomeCUL'
2013.11.10 10:30:30 3: Opening rpiLCD device localhost:1234
2013.11.10 10:30:30 3: rpiLCD device opened
2013.11.10 10:30:31 1: configfile: CSM: Mode MAX not supported
Im Thread steht ja schon eine Bemerkung von "PeMue" dazu, dass die FW mit r392 Abhilfe schaffen könnte.
Beim Flashen hab ich aber jetzt das Problem, dass er mir Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
meldet.
Ich vermute mal dass SV4 noch nicht gesetzt ist. Leider hab ich die Rev. 3 von dir, wo der ISP Connector anstelle des SV4 sitzt.
Hab aber im Thread nur die Beschreibung zur Rev. 2 gefunden. Oder ich bin einfach nur blind und hab sie nicht gesehen.
Mit der Suche danach bin ich auch nicht weitergekommen.
Kannst du sie ev. noch posten ?
cu
Hallo gelbwichtel,
ZitatLeider bekomme ich mit der installierten Firmware (V 1.57 CSM868) MAX nicht zu laufen.
Welche Firmware hattest du benutzt? Die FW aus dem SVN hat (hatte?) keine funktionierende Max-Unterstützung.
Schau mal hier: http://forum.fhem.de/index.php/topic,12854.msg92825.html#msg92825
Die sollte mit MAX funktionieren.
ZitatIch vermute mal dass SV4 noch nicht gesetzt ist.
SV4 war nur zum Flashen und ist auch in der Rev3 auch weggefallen. Daher geht das Flashen hier einfacher.
Ich war der Meinung dass ich die Doku zu Rev3 hier schon mal hochgeladen hatte. Aber ich finde sie auch nicht mehr.
Daher hab ich sie hier im Anhang nochmal reingestellt.
Die Platinenfotos sind hier aber noch aus Rev2. Das sollte aber nicht stören.
Gruß
Dirk
Update: DOC durch PDF ersetzt
Hi Dirk, danke für die Beschreibung.
Aber das Flashen klappt irgendwie nicht.
Zitat
Leider bekomme ich mit der installierten Firmware (V 1.57 CSM868) MAX nicht zu laufen.
Welche Firmware hattest du benutzt? Die FW aus dem SVN hat (hatte?) keine funktionierende Max-Unterstützung.
Schau mal hier: http://forum.fhem.de/index.php/topic,12854.msg92825.html#msg92825
Die sollte mit MAX funktionieren.
Da ich die beiden Platinen von dir fertig aufgebaut bekommen habe, weiß ich natürlich nicht, welche Version du drauf gemacht hast.
Aber spielt ja keine Rolle, ich will sie ja jetzt draufflashen.
Aber daran scheitert es ja. Da in der Rev. 3 SV4 nicht mehr da ist und ja zum Flashen benötigt wurde, die Frage, was ist analog zu setzen?
Auch wenn nichts zu jumpern wäre:
Ich bekomme halt die Fehlermeldung Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
Hab's im Skript sowohl mit dem 1284p als auch mit dem 324p versucht.
Oder muss ich wirklich über die ISP flashen ?
Danke vorab
ZitatDa ich die beiden Platinen von dir fertig aufgebaut bekommen habe, weiß ich natürlich nicht, welche Version du drauf gemacht hast.
Da hatte ich vermutlich die Version aus dem SVN, also ohne MAX-Unterstüzung genommen.
ZitatDa in der Rev. 3 SV4 nicht mehr da ist und ja zum Flashen benötigt wurde
SV4 wird bei Rev3 zum Flashen nicht mehr benötigt. Es muss hier für nix mehr gesetzt werden.
Nur FHEM muss vor dem Flashen beendet sein!
ZitatOder muss ich wirklich über die ISP flashen ?
Nein, das braucht es nicht.
Gruß
Dirk
Danke Dirk, funzt.
Hätte ich ja eigentlich selbst drauf kommen können, dass ein aktives FHEM beim Flashen hinderlich ist.
cu
Hallo zusammen,
könnte mir bitte jemand netterweise das Image für den RasPi mit LCD zur Verfügung stellen?
Danke.
Grüße
P.S.: Ich find meines nichtmehr 8)
Zitatkönnte mir bitte jemand netterweise das Image für den RasPi mit LCD zur Verfügung stellen?
Hi Puschel,
Hier ist der Beitrag mit dem Image:
http://forum.fhem.de/index.php/topic,13221.msg83321.html#msg83321
Gruß
Dirk
Moin,
vielen Dank Dirk!!!
Ich werd mir den Link gleich mal als Lesezeichen ablegen ;D
Schönen Tag noch an alle.
Grüße
Ich kann mit:" set RPI_LCD text 0 Hallo_Klaus " den Text auf das Display zaubern. Aber das Haus und der normale Text bleiben noch stehen. Wie kann ich das Display leeren und wie bekomme ich nach meinen "Textversuchen" das alte Bild wieder hin ohne shutdown restart?
Hallo stgeran,
das Modul kann im Moment leider noch nicht alles. Hier hänge ich etwas hinterher :(
Du kannst aber alles aus FHEM heraus mit Shell-Befehlen erreichen.
Als Beispiel kannst du in das Initscript vom Daemon reinschauen.
# screen löschen
/opt/rpiLcdDaemon/client 1234 cls
# Grafik anzeigen
/opt/rpiLcdDaemon/client 1234 bmp,0,0,/opt/rpiLcdDaemon/images/fhem.bmp
# Schriftart setzen
/opt/rpiLcdDaemon/client 1234 setFont,1
# Text ausgeben
/opt/rpiLcdDaemon/client 1234 text,50,34,Hallo,0,1
Die Vollständige Befehlsbeschreibung findest du in der Dokumentation zum Display
Viele grüße
Dirk
Danke für den Tip.
Sind noch Platinen zu haben? Ich würde gerne eine fertige Platine nehmen. Kann man mit der Platine auch 433mhz Sensoren ansteuern?
Hallo Spezialtrick,
Ich habe die Tage neue Platinen bekommen.
Das CSM gibt es aktuell nur als 866Mhz Version.
Wenn man mit eingeschränkter Reichweite leben kann, kann man damit auch 433Mhz Sensoren empfangen.
Gruß
Dirk
Super. :) Anfangs wollte ich mir ein einen Pi Crust von NinjaBlocks http://ninjablocks.com/pages/picrust (http://ninjablocks.com/pages/picrust) für meinem Raspberry kaufen. Daran störte mich jedoch, dass man an deren Cloud System gebunden ist und im Falle des Ablebens der Firma eine nutzlose Platine hat. Nach kurzer Zeit bin ich dann auf FHEM gestossen und dann habe deine Platine gesehen und wusste sofort dass es die perfekt All in One Lösung für mich ist. :)
Wie sehr wäre der Empfang eingeschränkt? Reicht es für eine 60qm Wohnung? Ich möchte für erste nur ein paar Lampen, Bewegungsmelder und Tür-/Fensterkontakte steuern.
Wie viel möchtest du für eine fertige Platine haben?
Zitat
Wie sehr wäre der Empfang eingeschränkt? Reicht es für eine 60qm Wohnung? Ich möchte für erste nur ein paar Lampen, Bewegungsmelder und Tür-/Fensterkontakte steuern.
Ohne wissen vom Umfeld ist das kaum zu beantworten.
Bei Funk spielen eben viele Faktoren mit rein. Umgebungsbedingunegn wie Wände, andere Funkquelle in der Umgebung, Störungen usw.
ZitatWie viel möchtest du für eine fertige Platine haben?
Hast ne PM
Gruß
Dirk
Hallo Dirk,
ich habe leider immer noch Probleme mit "Pixelsalat".
Die letzte rpiLcdDaemon-Version von github läuft nicht so stabil bei mir wie der Daemon, der bei dem von dir zusammenstellten Image dabei ist.
Könntest Du bitte da noch mal Hand anlegen ?
Und mit der Ausgabe von Temperaturdaten von meinem Temperatursensor (HM-WDS40-TH-I) bin ich auch irgendwie noch nicht so richtig weitergekommen. :(
Noch einen schönen 3.ten Advent.
Gruß Klaus
LAN -> WLAN aber wie ?
Hallo,
da ich mich nicht so gut mit Linux auskenne, bitte ich um Eure Unterstützung. Und sicherlich hat der Eine oder Andere die Prozedur schon durchgeführt.
Momentan hängt meine FHEM-Zentrale noch ganz normal am LAN. Ich würde aber gerne auf WLAN umsteigen. Ein entsprechender USB-Stick mit WLAN liegt hier schon. Wie kriege ich das denn am einfachsten hin?
Danke schonmal für Eure Hilfe.
@Dirk,
wie kann ich den Daemon vorübergehend deaktivieren ?
unter /etc/default finde ich leider keine Konfigdatei dafür !
klaus
Hallo Klaus,
das müsste mit
sudo /etc/init.d/rpiLcdDaemon stop gehen (ist aus dem Kopf, da WLAN in den Keller noch ausgeschaltet :-[ Oder einfach den Befehl eingeben ohne Parameter, dann sagt er, was er kann.
Gruß Peter
Hallo Peter,
das hält dann aber nur bis zum nächsten Reboot !
Ich würde es gern temp. daktivieren , ohne komplett zu deinstallieren.
Klaus
Hallo Klaus,
Das hier sollte funktionieren:
sudo update-rc.d rpiLcdDaemon remove
Zum Wiedereinsachalten:
sudo update-rc.d rpiLcdDaemon defaults
Gruß
Dirk
Hallo Dirk,
danke für den Tipp , funktiniert ;)
Klaus
Hi Klaus,
sorry, deinen Post habe ich irgendwie übersehen.
Zitat von: dampf123 am 15 Dezember 2013, 11:22:13
ich habe leider immer noch Probleme mit "Pixelsalat".
Kommt das nach einer bestimmten Zeit erst?
Nach einem Restart des Daemon ist alles wieder Ok?
Kannst du mal den loop in rpiHW_spiWait mal erhöhen?
z.B. auf 50
ZitatDie letzte rpiLcdDaemon-Version von github läuft nicht so stabil bei mir wie der Daemon, der bei dem von dir zusammenstellten Image dabei ist.
Die Änderungen sind hier eigentlich nicht so groß.
Wie äußert sich denn Instabilität?
Hier läuft der Damon auf 2 PIs ohne Probleme.
ZitatUnd mit der Ausgabe von Temperaturdaten von meinem Temperatursensor (HM-WDS40-TH-I) bin ich auch irgendwie noch nicht so richtig weitergekommen. :(
Was ist genau das Problem?
ZitatNoch einen schönen 3.ten Advent.
Und ich wünsche noch ein frohes neues :)
Gruß
Dirk
Hallo Dirk,
dann versuche ich mal meine "Probleme" zu schildern:
- dieser Pixelsalat, also das -auf-dem-Kopf-stehen- tritt unregelmäßig auf. Ich würde so sagen, im Abstand von 4-6 Tagen.
Ein -shutdown restart- reicht nicht aus, um das Display wieder richtigzustellen, nur ein kompletter Neustart vom Raspi hilft.
Den loop in rpiHW_spiWait ändern würde doch bedeuten, das ich den daemon selbst irgendwie neu kompilieren müsste, oder ?
wie geht das ?? (bin nicht so der große Programmierguru, leider )
<<<<Die letzte rpiLcdDaemon-Version von github läuft nicht so stabil bei mir wie der Daemon, der bei dem von dir zusammenstellten Image dabei ist. >>>>>> damit meine ich, das der Pixelsalat mindestens täglich auftaucht. Also deutlich gehäuft.
Und zu meinem Problem der Datenausgabe auf dem Display:
ich möchte halt die Temperatur bzw. Luftfeuchtigkeit ausgeben:
so in etwa: set RPI_LCD TEXT Parameter 1
Ich habe schon mit dem von PeMue gepatchten Modul 00_RPI_LCD.pm rumexperimentiert. Nur ist da noch nichts sinnvolles rausgekommen. :-\
Also die Möglichkeit irgendwelche variable Parameter auf dem Display ausgeben.
So, ich hoffe du kannst mit meinem geschreibsel was anfangen.
Gruß
Klaus
-auf-dem-Kopf-stehen-
Das hatte ich vorgestern auch wieder ;-) ist bei mir aber erst das zweite Mal aufgetreten seit dem das Teil läuft und ich die Platine bekommen habe.
Nur mal so als kurzer Einwurf, aber stört mich nicht da ich das Display ehrlich gesagt nicht nutze... Da ist immer nur das standard Bild drauf.
Gruß
Daniel
Zitatauf-dem-Kopf-stehen
Ist ziemlich Sicher ein Timingproblem.
Ich erhöhe das mal, und stelle das "Kompilat" zur Verfügung. Kann aber frühestens heute Abend testen.
Zitatich möchte halt die Temperatur bzw. Luftfeuchtigkeit ausgeben:
so in etwa: set RPI_LCD TEXT Parameter 1
Ich habe schon mit dem von PeMue gepatchten Modul 00_RPI_LCD.pm rumexperimentiert. Nur ist da noch nichts sinnvolles rausgekommen. :-\
Ich werde am Wochenende endlich mal die die Taxtausgabe in das Modul einbauen.
Dann sollte das genau so funktionieren.
Viele Grüße
Dirk
Hallo Dirk,
dann warte ich mal auf die Dinge die du da entwickelst. :)
Schon mal besten Dank für deine Mühe.
Gruß
Klaus
Ich habe das Repo im Github mal aktualsiert.
https://github.com/kc-GitHub/rpiLcdDaemon/tree/master/src
spiWait ist mit 50 jetzt doppelt so lang.
eine Kompilierte Version ist auch dabei.
@Klaus,
Teste das bitte noch einmal.
Gruß
Dirk
Moin Dirk,
ich habe soeben die Datei >>> rpiLcDaemon <<< gegen die geänderte mit spiWait 50 ausgetauscht.
Schauen wir mal, ob das LCD Verhalten sich bei mir ändert.
Eine Frage am Rande:
ich habe die Datei mir WinSCP auf meinen Raspi kopiert. Nur musste ich die Dateirechte anschließend noch manuell ändern, von 0655 auf 0755. Sonst lief der Daemon nicht.
Gibt es da eine Globale Einstellung bei WinSCP die ich da noch bei der Dateiübertragung beachten muß, oder ist die Datei von vornherein auf 0644 gesetzt ?
Noch einen schönen Tag und Danke
Gruß Klaus
Hallo Dirk,
kurzer Zwischenbericht:
UpTime Raspi 1 Tag 5 Stunden ohne Pixelsalat. :)
Gruß
Klaus
Hallo Dirk,
bis jetzt habe ich kein einziges mal "Pixelsalat" gehabt. :)
Somit scheint der Wert von spiWait mit 50 OK zu sein.
Das Problem ist für mich somit vom Tisch. Danke.
Vorsichtige Frage: wie weit bist du mit der Textausgabe gekommen ?
Gruß
Klaus
Hallo,
sag mal eine Frage, die Funktion, dass das Bild auf dem Kopf steht brauche ich jetzt ;-) Mein RPi liegt nämlich jetzt im Wohnzimmer weil ich kein anderen Platz an der Wand etc. gefunden habe, und da steht das Bild auf dem Kopf so wie er jetzt liegt. Kann man das irgendwo konfigurieren oder ist das hard coded? Könnte man da ein Parameter einführen womit man das einstellen kann?
Gruß
Daniel
@ Daniel: ... getreu dem Motto "it's not a bug, it's a feature" :)
Ich hatte mit einem Wert von 25 für spiWait ganz gute Ergebnisse, aber die Tage war dann das Display wieder komplett aus. Habe gerade auf 50 hochgestellt und werde berichten.
Frage an alle, die diese Probleme hatten:
Wie war bei Euch die Taktfrequenz eingestellt? Erlaubt ihr übertakten oder nur die Standardfrequenz 700 MHz? Ich denke, das wäre gut für Dirk, das zu wissen.
Gruß und schönen Sonntag.
PeMue
Zitat von: dampf123 am 18 Januar 2014, 19:28:50
bis jetzt habe ich kein einziges mal "Pixelsalat" gehabt. :)
Somit scheint der Wert von spiWait mit 50 OK zu sein.
Sehr schön. Dann lass ich das so.
Danke für das Feedback
Zitat von: ext23 am 19 Januar 2014, 12:17:16
sag mal eine Frage, die Funktion, dass das Bild auf dem Kopf steht brauche ich jetzt ;-) ...
Kann man das irgendwo konfigurieren oder ist das hard coded?
Könnte man da ein Parameter einführen womit man das einstellen kann?
Aktuell ist das hard coded. Bei der Initialisierung des Displays in lcd.c in LCD_Init.
ändern von
lcd_write_cmd(0xC8);nach
lcd_write_cmd(0xC0);Sollte das gewünschte Ergebniss bringen.
Ich kann da aber auch eine Option für einbauen.
Zitat von: PeMue am 19 Januar 2014, 13:31:58
Wie war bei Euch die Taktfrequenz eingestellt? Erlaubt ihr übertakten oder nur die Standardfrequenz 700 MHz? Ich denke, das wäre gut für Dirk, das zu
Da das rpiHW_spiWait hier durch eine simple Warteschleife realisiert wird, ist die Frequenz des RPI hier wichtig.
Wer seinen Raspi also mit einer Frequenz > 700Mhz betreibt muss die Anzahl der Loops wohl vergrößern.
Wenn ich dann aber schon bei weiteren Konfigurationsoptionen bin, dann werde ich für das Wait auch eine Option mit einbauen.
Dann kann man das optional anpassen.
Viele grüße
Dirk
Hallo Dirk,
eine Frage zum Stand deiner Softwareentwicklung zu dieser Erweiterungsplatine:
gibt es da schon etwas Neues ?
Gruß
Klaus (der leider kein Programmierer ist, und es toll findet, wenn jemand für so ein Projekt seine Freizeit opfert )
Hallo Klaus,
ich bin da schon drann.
Ich denke am Wochenende kann ich dir schon mal eine Version vom FHEM-Modul schicken die zumindest schon mal die Textausgabe selber beherrscht. Also ohne umwege über Shell-Befehle.
Gruß
Dirk
Hallo Dirk,
danke für die Info. :)
Gruß Klaus
Hallo Zusammen,
anbei das Modul mit etwas mehr Möglichkeiten.
Folgende Befehle gibt hier:
# Viereck zeichen
set <name> rect x1 y1 x2 y2 outline
# Linie zeichnen
set <name> line x1 y1 x2 y2
# Text schreiben (bei mehreren Wörtern muss string in Anführungszeichen geschrieben werden)
# Der komplette String kann auch in {} eingeschlossen werden, dann wird der string als Perl interpretiert.
# Somit kann man dann auch variablen ausgeben.
set <name> text x y string [invert] [clearBg]
# Beispiel um das Reading einens Sensors auszugeben
set rpiLCD text 30 30 {ReadingsVal('KS300','humidity','').'%'}
# bmp ausgeben (der Dateiname muss absolut angegeben werden)
set <name> bmp x y filename
# Font festlegen (0, 1, 2, 3
set <name> setFont fontNum
#Datum an Position ausgeben. Dieses Datum wird an dieser Position automatisch aktualisiert.
set <name> date x y fontNum
# Zeit ausgeben. Wenn showSeconds 1 ist, wird die Zeit mit laufenden Sekunden ausgegeben
set <name> time x y fontNum showSeconds
# Zeitaktualisierung stoppen
set <name> stopTime
# Datumsaktualisierung stoppen
set <name> stopDate
# Kreis zeichen
set <name> circle x y r
# Screen löschen (nur unterhalb der Datumszeile)
set <name> cls
# Kompletten Screen löschen
set <name> clearAll
# LED's schalten (ledNum = 1-3, state = 0 oder 1)
set <name> led ledNum state
# Hintergrundhelligkeit setzen (level = 0 - 255, 0 = aus)
set <name> backlight level
Wenn das so alles funktioniert bitte ein kleine Feedback.
Dann check ich das Modul auch ein.
Gruß
Dirk
Update Anhang gelöscht.
Hallo Dirk,
hast Du eine Nachtschicht eingelegt? Werde morgen mal testen und schauen, wie weit sich mein daemon von Deinem Modul "wegentwickelt" hat und berichten. Bin gerade dabei, für meine Photovoltaikanlage einen Konverter zu schreiben, daher liegt das Display etwas "auf Eis".
Gruß Peter
Zitathast Du eine Nachtschicht eingelegt
Ja. Ich wollte fertig werden. Sonst hätte das wieder ein paar Tage liegen geblieben :)
Gruß
Dirk
Hallo Dirk,
da warst du ja richtig fleißig, sogar eine Nachtschicht hast du eingelegt. :)
Das Modul habe ich auch schon bei mir mal auf den Raspi gezogen und getestet.
Leider kann ich noch keinen Erfolg vermelden. :(
Folgendes Problem:
set RPI_LCD text 30 30 {ReadingsVal('TH_1','humidity','').'%'}
erzeugt auf dem LCD-Display nur das %-Zeichen. Leider keinen Messwert.
Wenn ich in der Komandozeile
{ReadingsVal('TH_1','humidity','').'%'}
eingebe, wird mir brav 61% auf dem Monitor ausgegeben.
Das habe ich auch noch mal via PuTTY und Telnet Verbindung versucht, auch da wird mir der Meßwert zurückgegeben.
Die anderen Funktionen, so wie Rechteck zeichnen und Textausgabe klappt einwandfrei.
Ich hoffe du kannst mit meiner "Fehler"-Beschreibung etwas anfangen.
Gruß Klaus
Wenn das %-Zeichen angezeigt wird, scheint der Ausdruck aber interpretiert zu werden.
Was kommt denn bei:
set RPI_LCD text 30 30 {ReadingsVal('TH_1','humidity','99').'%'}
Hallo Dirk,
auf dem Display erscheint dann: 99%
Gruß Klaus
Ups,
ich glaube mit dem Befehl set led stimmt auch was nicht.
set led 1 1
führt zum Absturz. Kann das aber noch nicht verifizieren. Das muss ich noch mehr eingrenzen.
Später mehr ( habe gleich leider noch einen Termin ......, daher zu wenig Zeit)
Gruß
Klaus
Zitat von: dampf123 am 31 Januar 2014, 16:47:21
auf dem Display erscheint dann: 99%
Dann passt das aber.
99 ist der Default-Wert den die Funktion liefert wenn das Reading kein Ergebniss hat.
Tippfehler im Device-Name?
Zitatführt zum Absturz. Kann das aber noch nicht verifizieren. Das muss ich noch mehr eingrenzen.
Was stürztz ab? FHEM?
Gibt es Logeinträge?
Moin Dirk,
so ich habe mal etwas mit dem Raspi rumgespielt.
Ich habe mal das Device umbenannt, und zwar von RPI_LCD auf LCD1. Ergebnis ist aber das gleiche.
set LCD1 text 30 30 {ReadingsVal('TH_1','humidity','').'%'}
bringt ein %-Zeichen auf das LCD-Display.
In der Komandozeile
{ReadingsVal('TH_1','humidity','').'%'}
eingegeben bringt mir auf dem Monitor den aktuellen Wert zurück.
Da steht dann: 63%
Somit schließe ich Tippfehler aus, der Temperatursensor ist auch OK.
Dann zum Absturz bei der Eingabe von:
set LCD1 led 1 1
dabei stürzt das fhem ab.
Auf der Konsole vom raspi steht dann folgendes:
Undefined subroutine &main::rpiLCD_command called at ./FHEM/00_RPI_LCD.pm line 442
Hilft dir das weiter ?
Gruß Klaus
ZitatAuf der Konsole vom raspi steht dann folgendes:
Undefined subroutine &main::rpiLCD_command called at ./FHEM/00_RPI_LCD.pm line 442
Hilft dir das weiter ?
Definitiv.
Ich schaue mir das heute abend an.
Warum das Reading bei dir nicht ausgegeben wird ist mir ein Rätsel. Vor allem weil der Defaultwert ja angezeigt wird.
Vielleicht finde ich da noch was.
Gruß
Dirk
Ich habe das Modul heruntergeladen und in /opt/fhem/FHEM gespeichert. Ein" reload 00_RPI_LCD.pm" bringt folgenden Fehler:
Too many arguments for main::RPI_LCD_text at ./FHEM/00_RPI_LCD.pm line 376, near "$clearBg)"
BEGIN not safe after errors--compilation aborted at ./FHEM/00_RPI_LCD.pm line 552.
Was habe ich vergessen oder falsch gemacht?
Hi,
eine Frage ersetzt das neue Modul das alte "00_rpiLCD.pm"? Weil es hat ja ein anderen Namen gelle. Oder hab ich eine zu alte Version auf meinem RPi?
Gruß
Daniel
Zitat von: ext23 am 01 Februar 2014, 20:43:22
eine Frage ersetzt das neue Modul das alte "00_rpiLCD.pm"? Weil es hat ja ein anderen Namen gelle. Oder hab ich eine zu alte Version auf meinem RPi?
Du hast recht. Die neue Version liegt hier schon ein paar Wochen. Und diese Info habe ich tatsächlich unterschlagen.
Also "00_RPI_LCD.pm" ersetzt die alte Version "00_rpiLCD.pm".
Beim Define muss das nun auch heißen:
define <name> RPI_LCD localhost:1234Zitat von: stgeran am 01 Februar 2014, 17:45:17
Ich habe das Modul heruntergeladen und in /opt/fhem/FHEM gespeichert. Ein" reload 00_RPI_LCD.pm" bringt folgenden Fehler:
Too many arguments for main::RPI_LCD_text at ./FHEM/00_RPI_LCD.pm line 376, near "$clearBg)"
BEGIN not safe after errors--compilation aborted at ./FHEM/00_RPI_LCD.pm line 552.
Was habe ich vergessen oder falsch gemacht?
Vermutlich weil das alte Modul noch geladen war. Siehe oben.
@dampf123
Der Absturz beim Setzen der LED's ist nun gefixt.
set LCD1 text 30 30 {ReadingsVal('TH_1','humidity','').'%'}Sollte bei dir nun auch funktionieren. Es war der Unterstrich.
Gruß
Dirk
Update:
00_RPI_LCD.pm gelöscht. Diese Version befindet sich mit im Github-Repo
So,
ich darf mal anfangen ;-) LED habe ich versucht an zu schalten und dann kommt:
Das define dazu ist noch das original von dir (define rpiLCD_LED1_on notify rpiLCD_LED1.on set rpiLCD led 1 1)
Undefined subroutine &main::rpiLCD_command called at ./FHEM/00_RPI_LCD.pm line 442.
und FHEM schießt sich ab.
Achso und ich hab die letzte Version genommen wo es gefixed sein sollte. Hoffe ich zumindest oO
Arghh nee halt mein Fehler, scheisse wget hat die nicht überschrieben, verdammt, da hab ich gepennt.
Puh, ich dachte schon ich habe die falsche Datei rangehängt.
Wenn ihr keine Fehler mehr finden, dann pushe ich das dann Anfang der Woche ins Github.
Gruß
Dirk
Also noch sah alles gut aus was ich so durchprobiert habe. Die "Auf den Kopf stellen" Funktion fehlt mir noch ;-)
Gruß
Daniel
Hallo Dirk,
super ..... :)
Led's kann ich wieder schalten ohne Absturz.
In der Komandozeile eingegeben:
set LCD1 text 20 15 {ReadingsVal('TH_1','humidity','').'%'}
bringt auch den aktuellen Messwert auf das Display.
Dann habe ich diese Zeile in die fhem.cfg geschrieben. Da passiert aber nichts.
Hm, bin ich da auf nem Holzweg ? das müsste doch auch gehen oder ?
Gruß
Klaus
Edit: habe noch mal zwei screnshot's angehängt
Zitatbin ich da auf nem Holzweg
Etwas.
Wenn du das so in der fhem.cfg schreibst, dann kommt es auf die Reihenfolge an. Ggf. ist LCD1 oder TH_1 da noch nicht definiert.
Besser ist ein Notify
define TH_1_notify notify .*TH_1.* set LCD1 text 20 15 {ReadingsVal('TH_1','humidity','').'%%'}
Der aktualisiert die Daten auf dem Display wenn neue Daten empfangen wurden. Das %% muss übrigens so sein.
Dieser:
define initialized notify global:INITIALIZED trigger TH_1_notify TH_1Sorgt dafür, dass das obige Notify einmal getriggert wird, sobald FHEM initialisiert wurde.
Gruß
Dirk
Hi,
es klappt.
Auch wenn ich den Code noch nicht zu 100% begriffen habe. Aber daran arbeite ich noch.
Nur das ° Zeichen macht "Probleme", das sah auf den Display lustig aus. ::) Ist aber nicht so wichtig.
So, ich habe mir mal ein Bier aufgemacht, und schick dir ein "virtuelles" rüber. ;D
Besten Dank für deine Mühe.
Gruß
Klaus
ZitatAuch wenn ich den Code noch nicht zu 100% begriffen habe. Aber daran arbeite ich noch.
Die erste Zeile definiert einen Notify der bei Events mit TH_1 im Inhalt den aktuellen Wert auf das Display schreibt.
ZitatNur das ° Zeichen macht "Probleme"
Ja, stimmt. Die Zeichensätze im LCD-Daemon unterstützen derzeit nur den einfachen Ascii-Satz. (0 - 128)
ZitatSo, ich habe mir mal ein Bier aufgemacht, und schick dir ein "virtuelles" rüber.
Na dann Prost :)
Hallo Dirk,
auch bei mir funktioniert es. Vielen Dank!
Ich weiß nicht, ob man früh am morgen mit dem Bier trinken beginnen kann, aber ich schick dir auch eins rüber. :)
Gruß Maxel
Hallo Dirk,
ich habe noch eine Frage zu den Logeinträgen:
2014.02.02 20:15:36 2: CUL_HM set RT_1_Clima getConfig
2014.02.02 20:16:26 1: Rpi LCD command: text,88,15,64%,0,1
2014.02.02 20:16:26 1: Rpi LCD command: text,45,15,13.2,0,1
2014.02.02 20:16:26 1: Rpi LCD command: text,88,15,64%,0,1
2014.02.02 20:16:26 1: Rpi LCD command: text,45,15,13.2,0,1
2014.02.02 20:16:26 1: Rpi LCD command: text,88,15,64%,0,1
2014.02.02 20:16:26 1: Rpi LCD command: text,45,15,13.2,0,1
2014.02.02 20:18:08 2: CUL_HM set RT_1_ClimaTeam getConfig
Da sind immer einige doppelte Einträge, und ich kann mir das nicht erklären wieso die da sind.
hier noch ein Auszug aus meiner fhem.cfg :
#####################################################################
# Meßwertausgabe
# von TH_1
#
set LCD cls
set LCD text 0 15 Keller:
set LCD rect 72 15 73 16 1
set LCD text 75 15 C
define TH_1_notify notify TH_1 set LCD text 88 15 {ReadingsVal('TH_1','humidity','').'%%'};;set LCD text 45 15 {ReadingsVal('TH_1','temperature','').''}
define initialized notify global:INITIALIZED trigger TH_1_notify TH_1
damit habe ich mir eine Ausgabezeile gestrickt, die dann so aussieht:
Keller: 13.2 °C 64%
Die Funktion ist einwandfrei, nur halt die Mehrfach-Logeinträge. ::)
Gruß
Klaus
Zitat von: Maxel am 02 Februar 2014, 09:00:15
Ich weiß nicht, ob man früh am morgen mit dem Bier trinken beginnen kann, aber ich schick dir auch eins rüber. :)
Danke Mal sehen ob heute Abend noch was geht :)
Zitat von: dampf123 am 02 Februar 2014, 20:26:19
Da sind immer einige doppelte Einträge, und ich kann mir das nicht erklären wieso die da sind.
Ich vermute das dass Notify auf mehrere Events reagiert. Der Sensor schickt bestimmt Temperatur und Feuchtigkeit mit je einem Event.
Dann würde der dem Notify zugeordnete Befehl zwei mal ausgeführt
Gruß
Dirk
Hallo,
kann ich mit dem neuen Modul jetzt auch die Menüstruktur innerhalb FHEM aufbauen, oder muss das weiterhin extern passieren?
Vielleicht können wir hier ja Ideen von Inhalten und deren Umsetzung sammeln?
Gruß Daniel
Hallo Daniel,
Zitatkann ich mit dem neuen Modul jetzt auch die Menüstruktur innerhalb FHEM aufbauen, oder muss das weiterhin extern passieren?
Die Menüstruktur wurde bisher intern im FHEM-Modul aufgebaut. Das hat sich bisher auch nicht geändert.
Sofern musst du derzeit "nur" das FHEM-Modul ändern.
Ich würde das gerne aber auch irgenwie über die Config umsetzen. Allerdings hatte ich noch nicht die endgültige Idee.
Gruß
Dirk
Ich hätte da auch noch einen Wunsch. Wie schaut es denn mit FHEM2FHEM aus? ich hab den RPi nur über FHEM2FHEM angebunden, mein Hauptsystem läuft woanders. Das ist ja nicht möglich das LCD und die LED von woanders anzusprechen oder?
Gruß
FHEM2FHEM habe ich in noch gar nicht getestet.
Das kann ich mir aber gerne mal ansehen.
Hast du nähere Hinweise auf was ich hier achten muss?
Gruß
Dirk
Na so wie ich das verstanden habe ist es bei FHEM2FHEM immer so das man eine Trennung zwischen Gerät und logischen Gerät haben muss. Bei einem CUL also den CUL an sich und die FS20 Steckdose ist dann das logische Gerät. Das ist ja hier nicht der Fall, wir haben nur "RPI_LCD" worüber alles direkt bedient wird. Bei dem I2C_BMP180 ist es vermutlich ähnlich. Also zumindest wüsste ich jetzt so adhoc nicht wie man das konfiguriert mit FHEM2FHEM.
Gruß
Jetzt wo du es sagst erinnere ich mich dunkel.
Das würde wohl einen größeren Umbau bedeuten.
Zwischenzeitlich könnte ich den Deamon per Config ja dazu veranlassen auch Verbindungen von Remote Adressen anzunehmen.
Dann könnte man per Netzwerk Befehle an das Display schicken. Währ das was?
Also wenn ich da für mich sprechen darf, ich würde das begrüßen ja. Dann verhält es sich eben wie ein HMLAN oder Netzwerk CUL. Das wäre aus Sicht der FHEM Struktur ja auch eine saubere Lösung denke ich.
Achso und "Bild drehen" bitte noch auf die ToDo Liste nehmen ;-)
Gruß
Daniel
Ich habe im Github das Repo aktualisiert.
Der Daemon unterstützt optional nun die Verbindung von Clients über das Netz, also nicht nur von Localhost.
Ausserdem kann das Bild nun um 180 Grad gedreht angezeigt werden.
Für alle die die das Display und den Raspberry auf dem Kopf stellen wollen :)
Der Daemon hat dafür ein paar Parameter bekommen:
rpiLcdDaemon <portNum> [allowRemoteConnect] [lcdFlip] [DEBUG]
portNum: wie bisher der Port auf dem der Daemon lauschen soll
allowRemoteConnect: Damit nimmt der Daemon auch Verbindungen von "außen" an und nicht nur von Localhost
lcdFlip: Hiermit lässt sich der Displayinhalt um 180 grad drehen
DEBUG: Wie bisher die Debug-Ausgaben
Um die beiden oben genannten Funktionen zu nutzen muss das Startscript ggf etwas angepasst werden.
Die Zeile 33 kann dann wiefolgt geändert werden:
# Alt:
start-stop-daemon --start --quiet --background --exec $DAEMON -- $PORT $DEBUG
# Neu:
start-stop-daemon --start --quiet --background --exec $DAEMON -- $PORT [allowRemoteConnect] [lcdFlip] $DEBUG
Je nachdem welche Funktion man hier verwenden möchte kann man beide oder eben nur eine Option angeben.
Gruß
Dirk
Boa super, danke Dirk.
Dann werd ich das doch gleich mal ausprobieren.
Gruß
Daniel
Also prinzipiell funktioniert es, aber das 180 Grad drehen haut nicht so ganz hin, das ist jetzt alles Spiegelverkehrt.
Gruß
Daniel
Zitataber das 180 Grad drehen haut nicht so ganz hin, das ist jetzt alles Spiegelverkehrt.
Du musst natürlich noch ein Spiegel benutzen :)
War bei mir gestern "Abend" doch etwas spät.
Ich habe nur gesehen, steht auf dem Kopf, super, klappt. Das das spiegelverkehrt war habe ich gar nicht bemerkt.
Na gut. Habe das Ganze dann nochmal um die Hochachse gespiegelt. Jetzt passt es auch mit dem Drehen um 180 Grad.
Ist also gefixt und gepusht.
Gruß
Dirk
Du wirst lachen aber die Idee mit dem Spiegel kam mit auch, zumal mein RPi quasi liegt ;-)
Dann werd ich mal schauen ob es jetzt passt.
Gruß
Daniel
Hallo Dirk,
hast du evtl noch ein paar Teile von der FHEM Zentrale bei dir rumliegen ?
Gruß Stefan
Hallo Stefan,
ja, Die Teile sind noch da. Ist sogar noch eine komplett bestückte Platine da.
Schreib mir mal ne PM.
Gruß
Dirk
Zitat von: Dirk am 17 März 2014, 10:10:05
Hallo Stefan,
ja, Die Teile sind noch da. Ist sogar noch eine komplett bestückte Platine da.
Schreib mir mal ne PM.
Gruß
Dirk
Hallo Dirk,
ist vielleicht noch eine fertig bestückte Platine vorhanden.
Hätte daran Interesse.
Weitere Details gerne auch per PM.
Danke!
Hallo jostereo,
Zitatist vielleicht noch eine fertig bestückte Platine vorhanden.
Ja, schick mir eine PM.
Gruß
Dirk
Hey Dirk,
Am Samstag hat mit betateilchen überzeugt vom der FB wegzugehen.
Und auf den raspberry pi zu setzen. Ist auch schon bestellt.
Dein Display am raspberry pi hat mir sehr gut gefallen.
Wenn du noch eins bestückt bei dir liegt würde ich gerne von dir noch ein Display ordern.
Und evtl. gleich dann mal die Sensoren von dem Beitrag.
http://forum.fhem.de/index.php/topic,20620.0.html
Innen und Aussensensor (max Ausstattung )+ Programm Adapter (gelötet auf 3,3V) wenns mal fertig sind
Gruß Gerd
Hallo Gerd,
ich hab dir ne PM geschickt.
Gruß
Dirk
Danke Dir Dirk.
Habe meine Wunschliste geschickt :-)
Gruß Gerd
Gesendet von meinem iPad mit Tapatalk
Hallo Dirk,
ich bin auch interessiert an deinem Display. Hast du noch Teile?
Hi tiwo85,
Ja, es sind noch Teile da.
Schick mir mal eine PM mit deiner Wunschliste.
Gruß
Dirk
Hallo,
ich verwende ebenfalls die UART-Schnittstelle des Raspberry mit einem RS485-Transceiver. Allerdings habe ich noch Probleme mit dem Schalten des Tx-Enable-Pins. Laut Wiki-Eintrag (http://www.fhemwiki.de/wiki/Serial/Netzwerk-RS485-Adapter (http://www.fhemwiki.de/wiki/Serial/Netzwerk-RS485-Adapter)) soll es möglich sein, mit den Parametern HM485d_gpioTxenInit, HM485d_gpioTxenCmd0 und HM485d_gpioTxenCmd1 die Shell-Commands zum Initialisieren und Setzen des Sende-Pins zu übergeben.
Sobald ich jedoch irgendwas als Attribut angebe, startet das Modul HM485d nicht mehr.
2014.06.02 22:48:16 3: HM485_LAN: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --serialNumber SGW0123456 --device /dev/ttyAMA0 --gpioTxenInit "gpio mode 1 out" --gpioTxenCmd0 "gpio write 1 0" --gpioTxenCmd1 "gpio write 1 1" --verbose 5
2014.06.02 22:48:16 3: HM485_LAN: HM485d Could not start
Auch verschiedene Syntaxvarianten ("x", (x), 'x') haben nicht geholfen.
Vielleicht kann einfach mal jemand, der die RS485-Platine nutzt, seine Config posten.
Besten Dank & schöne Grüße
Markus
Hallo,
ich hatte so ein ähnliches Problem. Dirk sagte, dass es manchmal zu Problemen mit dem automatischen Starten und Erkennen mit FHEM kommt. Er empfahl mir den Prozess bis zum Fix separat zu starten.
Ich mache das z.B. so:
perl /opt/fhem/FHEM/lib/HM485/HM485d/HM485d.pl -device /dev/ttyAMA0 -gpioTxenInit "/usr/local/bin/gpio mode 0 out" -gpioTxenCmd0 "/usr/local/bin/gpio write 0 0" -gpioTxenCmd1 "/usr/local/bin/gpio write 0 1" -verbose 2&
Bei mir erfolgt die Ansteuerung des RS485 ICs über Pin11 des GPIO, so wie auf der Addon Platine.
Falls der Server dann startet kannst du mit gpio readall prüfen ob der GPIO17 sich im Mode OUT befindet (normalerweise ist der im Mode IN), dann funktioniert die Ansteuerung der GPIO.
+----------+-Rev2-+------+--------+------+-------+
| wiringPi | GPIO | Phys | Name | Mode | Value |
+----------+------+------+--------+------+-------+
| 0 | 17 | 11 | GPIO 0 | OUT | Low |
Der HM485d kennt noch ein paar zusätzliche Parameter die unter "HM485d.pl -help" beschrieben sind.
Wenn hmwId und serialNumber weggelassen werden, werden hier die Standardwerte benutzt.
in FHEM sieht das dann bei mir so aus:
define HM485_SER HM485_LAN localhost:2000
attr HM485_SER room HM485
Hallo Hoschiq,
erstmal sorry für die späte Antwort - ich war ein paar Tage im Urlaub (ohne Internet)!
Besten Dank für Deine Hilfe, mit der Angabe des kompletten Pfads scheint es tatsächlich zu funktionieren.
Also z.B. "usr/local/bin/gpio mode 0 out" anstelle von "gpio mode 0 out". Auf die Idee bin ich nicht gekommen!
Grüße
Markus
Hallo Dirk,
ein super Projekt!
Ich hätte gerne einen kompletten Satz.
Bisher habe ich noch nicht SMD's gelötet. Es wäre also schön, wenn ich eine bestückte Platine bekommen könnte.
Gruß
Gerd
Hallo,
so eben habe ich den Raspi mit LCD+CSM in die Wüste geschickt und nun muß ich die SD-Karte neu Aufsetzen.
Gibt es hierfür eine Installationsanleitung. Ja, ich weiß es gibt in diesem Trade ein Image, aber ich würde es gerne zu Fuß machen.
Vorgehensweise wie ich meinen Raspi in die Wüste schickte.
Gestern machte ich noch schnell vom Betriebssystem ein Update, überstand auch mehrere Reboots.
Heute wollte ich FHEM Update, nur den anschließenden Reboot überstand er nicht.
Nun haben CHANGED, conigDB.pm und fhem.pl ganze 0 Bytes Größe.
Thomas
hallo zusammen,
ich habe mich mal wieder mit dem LCD beschäftigt.
Hier ist nun meine Ausgabe auf dem Display
(https://www.dropbox.com/s/4gxvqklh8x106ao/IMG_9319.JPG?dl=0)
https://www.dropbox.com/s/4gxvqklh8x106ao/IMG_9319.JPG?dl=0 (https://www.dropbox.com/s/4gxvqklh8x106ao/IMG_9319.JPG?dl=0)
Mein cfg dazu
#####################################################################
# Meßwertausgabe
# FÜR DAS LCD DISPLAY
## Wetter
define KS300_notify notify KS300 set rpi_LCD text 88 15 {ReadingsVal('KS300','humidity','').'%%'};;set rpi_LCD text 45 15 {ReadingsVal('KS300','temperature','').''}
attr KS300_notify room LCD
define initialized notify global:INITIALIZED trigger KS300_notify KS300
attr initialized room LCD
## Tobias
define HZ_TO_NF notify global:INITIALIZED trigger HZ_TO_notify CUL_HM_HM_CC_RT_DN_22DB8A_Clima
attr HZ_TO_NF room KIZI-Tobias
define HZ_TO_notify notify CUL_HM_HM_CC_RT_DN_22DB8A_Clima set rpi_LCD text 88 25 {ReadingsVal('CUL_HM_HM_SEC_SC_2_247E5B','state','').' '};;set rpi_LCD text 45 25 {ReadingsVal('CUL_HM_HM_CC_RT_DN_22DB8A_Clima','measured-temp','').''}
attr HZ_TO_notify room KIZI-Tobias
## Karina
define HZ_KA_NF notify global:INITIALIZED trigger HZ_KA_notify CUL_HM_HM_CC_RT_DN_22DB2E_Clima
attr HZ_KA_NF room KIZI-Karina
define HZ_KA_notify notify CUL_HM_HM_CC_RT_DN_22DB2E_Clima set rpi_LCD text 88 35 {ReadingsVal('CUL_HM_HM_SEC_SC_2_247E68','state','').' '};;set rpi_LCD text 45 35 {ReadingsVal('CUL_HM_HM_CC_RT_DN_22DB2E_Clima','measured-temp','').''}
attr HZ_KA_notify room KIZI-Karina
## Wohnzimmer
define HZ_WZ_NF notify global:INITIALIZED trigger HZ_WZ_notify CUL_HM_HM_CC_RT_DN_22DBD9_Clima
attr HZ_WZ_NF room Wohnzimmer
define HZ_WZ_notify notify CUL_HM_HM_CC_RT_DN_22DBD9_Clima set rpi_LCD text 88 45 {ReadingsVal('CUL_HM_HM_SEC_SC_2_247FCA','state','').' '};;set rpi_LCD text 45 45 {ReadingsVal('CUL_HM_HM_CC_RT_DN_22DBD9_Clima','measured-temp','').''}
attr HZ_WZ_notify room Wohnzimmer
## Kueche
define HZ_KU_NF notify global:INITIALIZED trigger HZ_KU_notify CUL_HM_HM_CC_RT_DN_22DCDE_Clima
attr HZ_KU_NF room Küche
define HZ_KU_notify notify CUL_HM_HM_CC_RT_DN_22DCDE_Clima set rpi_LCD text 88 55 {ReadingsVal('CUL_HM_HM_SEC_SC_2_247804','state','').' '};;set rpi_LCD text 45 55 {ReadingsVal('CUL_HM_HM_CC_RT_DN_22DCDE_Clima','measured-temp','').''}
attr HZ_KU_notify room Küche
Und Was mich sehr gestört hat waren die ewig langen LOG einträge in der FHEM log.
Diese habe ich Modul 00:RPI_LCD.pm in der Funktion auskommentiert.
#------------------------------------------------------------------------------
# RPI_LCD_command
#------------------------------------------------------------------------------
sub RPI_LCD_command(@) {
my ($hash, $msg, $nonl) = @_;
return if(!$hash || AttrVal($hash->{NAME}, "dummy", undef));
my $name = $hash->{NAME};
my $ll5 = GetLogLevel($name,5);
## Log (1, 'Rpi LCD command: '.$msg);
$msg .= "\r\n";
# writes command to daemon
syswrite($hash->{TCPDev}, $msg) if($hash->{TCPDev});
}
Oder hat einer eine Tip wie ich die notify etwas besser machen könnte.
@ Dirk an dem Modul machst du ja nichts mehr oder ??
Gruß Gerd
Hallo Dirk,
Zur Zeit bekomme ich immer das Problem das das Display sich Spiegelt ??
https://www.dropbox.com/s/h0znsaxt0em2mpx/IMG_9373.JPG?dl=0 (https://www.dropbox.com/s/h0znsaxt0em2mpx/IMG_9373.JPG?dl=0)
HAst du da eine IDEE
Gruß Gerd
Das hatten wir doch schonmal. Das war irgend ein Timing Problem. Musste mal weiter oben in dem Thread lesen.
Gruß
Daniel
Hey ext23,
das war ja damals die neue Version von Dirk. Das war ja ein Bug.
Aber nun habe ich das manchmal das am früh morgens das Display alles Spiegelverkehrt und auf dem Kopf steht .
Na mal sehen ...
Du kannst aber versuchen das Timing hier noch weiter zu verlangsamen. Das sollte auf alle Fälle helfen.
Hallo,
funktioniert die Platine auch auf dem neuen RPi B+????
Hat das vielleicht schon jemand ausprobiert.
Gruß Daniel
Ich hab zwar kein B+ sondern nur ein BananaPi da, aber ich würde sagen wenn die Pins alle passen mechanisch sowie elektrisch sollte das keibn Problem sein oder?!?
Apropos Problem, ich hätte da auch eins. Wo bekomme ich nochmal die culfw 1.61 für das CSM mit dem 324P her? Ich hab das eben mit culflash versucht aber dann viel mir ja ein das es mit dem CSM was anderes ist. Schon seit gefühlten Jahren nicht mehr gemacht ;-)
Gruß
Daniel
Servus.
Also unter den Verzeichnis vom LCD-Dämon ist ein Script zum flashen.
Und das hex file bekommst du hier.
http://forum.fhem.de/index.php/topic,27812.msg208344.html#msg208344
Gruß Gerd
Ahh ok danke, hat geklappt. Allerdings nur ohne das Flash Script... Ich hab's direkt gemacht.
sudo avrdude -p atmega324p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:./CSM.hex
Gruß
Daniel
Hallo Daniel,
bei mir hat vor einem halben Jahr das Flash Skript funktioniert, allerdings musste ich zuerst den Port freimachen (sprich fhem oder den CSM stoppen), damit das Skript funktioniert.
Gruß PeMue
Hallo PeMue
Ja das Problem kenn ich. Das habe ich auch machen dürfen. FHEM stoppen.
Naja logisch ja, hatte ich auch gemacht aber ging nicht...
Aber gut das Pin getoggle aus dem Script muss man ja anscheinend nicht machen, in den Bootloader kommt avrdude auch alleine so wie es aussieht. Bzw. war das CSM noch in dem Mode und hat sich das gemerkt beim reboot, wird ja nicht Stromlos das Modul.
Übrigens das hex aus dem svn ist nicht für den 324p kompiliert...
Gruß
Daniel
Hallo,
hat jemand das CSM.hex für den 324p?
Gruß Daniel
Probiere mal das, ich glaube das war das richtige...
Version 1.61
Gruß
Daniel
Hi,
ja hat funktioniert:
VERSION V 1.61 CSM868
wird angezeigt.
Allerdings habe ich das Problem, dass ich bei
get myCUL version -> myCUL version => No answer
und bei dem Versuch die Temperatur meiner Max Thermostate zu ändern kommt die Meldung:
2014.11.06 22:36:03 1: Error in CUL_MAX_SendQueueHandler: CUL myCUL did not answer request for current credits. Waiting 5 seconds.
Kennt einer das Problem und vielleicht auch noch die Lösung???
Gruß Daniel
Mein Display blinkt ab und zu (Änderung der Hintergrundbeleuchtung)
Hat das schon mal jemand beobachtet?
Im log ist nichts zu sehen. Wenn ich jedoch die Beleuchtung über das webinterface ändern will sehe ich im log
2014.12.19 20:25:46 1: Rpi LCD command: setBacklight,1
2014.12.19 20:25:51 1: Rpi LCD command: setBacklight,10
2014.12.19 20:25:57 1: Rpi LCD command: setBacklight,100
2014.12.19 20:26:11 1: Rpi LCD command: setBacklight,1
Es ändert sich allerdings nichts an der Helligkeit. Ist die Beleuchtung etwa defekt?
Hallo ins Forum und gesundes neues Jahr.
Leider haben ich mir meine SD-Karte nach zwei Tagen Konfiguration und Anpassung abgeschossen.
Leider gibt es das Image nur in einer Wheezy vom 23.06.2013. Hatte da Probleme mit der Samba Installation und eine Sicherheitsgruppe GPIO gab es auch nicht. Das apt-get Update funktionierte nicht.
Alles lief. Nun habe ich den Raspi nicht mehr herunterfahren können und musste ihn ausschalten. Jetzt startet das Display nicht mehr. Keine Ahnung woran es liegt. Könnt Ihr helfen? Fhem zeigt "disconnected" an.
Um mir das erneute Aktualisieren des Images zu sparen meine Frage. Gibt es denn ein Image mit einer Aktuellen Weezy Version?
Grüße Frank
Hallo ins Forum.
Und erst mal noch Gratulation zu diesem tollen Projekt.
Das mit dem Image hat sich erledigt. Bin jetzt auf dem aktuellen Stand und habe mir ein Image gezogen.
Für alle Fälle. ;)
Leider komme ich mit der Ausgabe von Text nicht zurecht.
Bsp.:
fhem("set LCD text 0 25 'Aktuell:' 0 1");
Diese Zeile sollte doch "Aktuell" nicht invertiert schreiben und den Rest der Zeile löschen. Ausgegeben wird dagegen invertiert und die Zeile wird nicht gelöscht.
Im Log steht dann:
Rpi LCD command: text,0,25,Aktuell :,1,1
Alle Versuche
fhem Log
0 0 - > 1,1
0 1 -> 1,0
1 0 - > 1,0
1 1 - > 1,1
führen zu immer gleichen Ergebnis.
Habe ich da einen Denkfehler oder ist es ein Bug?
Grüße Frank
Hallo ins Forum.
Kann bitte mal jemand testen, ob Bspw. ein
set LCD text 70 25 0
funktioniert. Bei mir geht es nicht.
Fehlermeldung:
"Wrong syntax: Use "set LCD text x y string [invert] [clearBg]", x, y, invert, clearBg must be numbers"
Ein set LCD text 70 25 1 dagegen geht ohne Fehler.
Grüße Frank
@majorshark
Hi,
ich habe jetzt das gleiche Problem.
Ich muste meinen Raspi hart ausschalten und mein Image ist jetzt defekt.
Kannst du dein Image zur Verfügung stellen?
Mfg
ED_2
Hallo ED_2.
Das kann ich machen. Leider habe ich das Image vor dem Sichern auf 16 GB aufgeblasen. !?
Grüße Frank
Hi,
das währe gut wenn du das irgendwie zur verfügung stellen könntest.
Was hast du in das Image denn alles rein gepackt?
16GB ist schon heftig.
Ich habe nur eine 8GB Karte.
Das kann mann doch bestimmt verkleinern?
Mfg
ed_2
Na ja einfach die SD-Karte im Raspi expandiert. Verkleinern ist dann schwierig.
Grüße Frank
Zitat von: majorshark am 21 Januar 2015, 14:57:21
Hallo ED_2.
Das kann ich machen. Leider habe ich das Image vor dem Sichern auf 16 GB aufgeblasen. !?
Grüße Frank
Hatte das gleiche Problem und hab es hiermit gelöst:
http://www.forum-raspberrypi.de/Thread-tutorial-backup-des-laufenden-systems-anlegen (http://www.forum-raspberrypi.de/Thread-tutorial-backup-des-laufenden-systems-anlegen)
Gruß
Peter
Hallo,
hat schon mal jemand versucht diese Erweiterungsplatine mit der Kernel Version 3.18.x zu betreiben. Da ändert sich ja die komplette Deviceansteuerung bzw. Aufruf der Treibermodule?
Viele Grüße
Achim
Hallo,
hat jemand ein aktuelles Image für mich mit den entsprechenden Treibern für die FHEM-Zentrale?
Das würde mir den neuen Einstieg sehr erleichtern.
Mfg
ED_2
Moin,
ich habe jetzt den Kernel "Linux fhemrpi 4.9.19+ #983 Thu Mar 30 14:42:18 BST 2017 armv6l GNU/Linux" laufen aber so richtig viel geht da auch nicht mehr. Die LEDs lassen sich nicht schalten, nur das Backlight des LCDs geht aus.
Aber I2C spinnt bei mir auch, der findet den BMP180 nicht mehr. Ich hab jetzt alles abgeschaltet und nutze den Raspberry nur noch als Satellit für RFX433 und CUL. Der liegt eh nur aufm Schrank wo ihn keine sieht.
/Daniel