Addictive displays

Nach meinen ersten Gehversuchen selbst mal an der Twizy Displayfront zu basteln ( Arduino Twizplay ) bin ich in den letzten Tagen mal mit meinem TTGO Display vom Ali 'ins Bett gestiegen'.

Mittlerweile habe ich einige Funktionen auf dem ESP32 in Betrieb genommen und möchte das hier gern vorstellen. Auf diesem Weg würde ich dann ebenfalls gern noch ein paar Anregungen einholen, was bei Euch überhaupt für Anwendungsfälle vorliegen, um dann etwas meine Stossrichtung zu definieren.
Wie beim Arduino Display möchte ich Alles veröffentlichen. Hardware gäbe es teilweise für wenige EUR im Internet oder man kann hier auch noch was entwickeln - als Forumsprojekt. Das ist dann eher für Diejenigen interessant, die sich zwar für ein Zusatzdisplay interessieren, aber beim Basteln, SW programmieren / flashen noch etwas unruhig werden.

Hier etwas Butter bei die Fische, so sieht es grad bei mir auf dem Schreibtisch aus (2.4Zoll Entwicklungsboard,, 240x320).
In dem Video resetiere ich das Display. Wenn man mal die Arduino Variante gesehen hat, erkennt man das hier alles flott über die Bühne geht (das war einer der Gründe warum ich Arduino nicht mehr weiterverfolgt habe). Es werden ein paar Beispielzahlen angezeigt, am Ende ein kleines Oszi Fenster . In so einem Fenster möchte ich während der Fahrt einige Messwerte anzeigen und verfolgen! Ich freu mich schon drauf! Das war für mich das Bonbon in dieser Lösung.




Die Displays inkl. uC (esp32) gibt es für um die 20EUR bei AliExpress. Mit Gehäuse sehen diese Entwicklungsboards so aus.
zB.


Man kann natürlich auch andere, grössere Displays anschliessen, der Aufwand im Aufbau steigt dadurch allerdings - oder es gibt in Zukunft auch weitere Entwicklungsboards mit grösseren Displays, die man hier verwenden kann.

Was habe ich mir bisher angesehen:
- arbeite mit der ESP32 Entwicklungsumgebung in Eclipse (nicht Arduino IDE)
- Wifi vom ESP32 als Station (Endpunkt) und Access Point (WLAN Knoten, bei dem sich sie Stationen anmelden)
- habe das CAN Interface am ESP32 in Betrieb genommen
- habe das Display in Betrieb genommen und ein paar Beispieldaten dargestellt (ESP32_TFT_Lib, Video)
- habe eine MQTT Broker+Client auf dem ESP32 getestet (Mongoose, habe damit zwischen Handy und Display Daten ausgetauscht (App MQTT_Dash))


TODO
Habe noch nicht die Einzelkomponenten vernetzt.
Inbetriebnahme der SD Karte (optional für das Laden von Bildern oder als Datenspeicher?)

Jetzt wieder zu Euch!
Wen interessiert sowas? Also gibt es aktuell Bedarf an einem anderen Display, der nicht von einem Twizplay oder OVMS abgedeckt wird?
Da sind 3 Knöpfe am Display, die kann man natürlich zum Sevcon Map umschalten verwenden (Thema SimpleConsole).
Wer hat noch andere Feature Wünsche?
Darf ich Euch zu einer Diskussion einladen?

Die Geschwindigkeitsanzeige mit rein, einen Aufsatzrahmen für den original Tacho 3D gedruckt und dann ein eigenes Betriebssystem
in den Twizy genagelt und es ist vorbei mit der closed Source Geschichte von Renault....

Ich habe keine Ahnung wie weit so etwas TÜV-Konform etc ist, aber es wäre die Befreiung von allen Renault-Zwängen und Restriktionen.

Quasi ein Open Source Betriebssystem für den Twizzel. Mit freier Batteriewahl, freier Leistungswahl etc etc.....


Ich glaub ich träum zu laut Ich hab halt leider von DER Geschichte viel zu wenig Ahnung. Und ob ich mir die in diesem Leben noch antun werde?

Jekyll schrieb: Jetzt wieder zu Euch!
Wen interessiert sowas? Also gibt es aktuell Bedarf an einem anderen Display, der nicht von einem Twizplay oder OVMS abgedeckt wird?
Da sind 3 Knöpfe am Display, die kann man natürlich zum Sevcon Map umschalten verwenden (Thema SimpleConsole).
Wer hat noch andere Feature Wünsche?
Darf ich Euch zu einer Diskussion einladen?

Eine OVMS not-so-simple-console, wie dexter sie bereits hier im letzten Absatz andiskutiert hat, wäre (m)ein Traum und der Platz den TC anregt wäre auch mein Favorit.
Der Tacho darf dahinter aber ruhig weiter funktionieren
Wenn ich das richtig sehe, wäre das mit deinem Ansatz möglich.

Bis auf die aktuell gefahrene Geschwindigkeit und die grobe Restreichweitenschätzung (egal ob in % in KM in Pfund oder sonstwie)
kann ich auf alles andere eigentlich zur Not verzichten.

Danke für Euer Feedback.
Ich nehme die Zielrichtung 'Displayalternative' mal mit auf. Vielleicht noch zu erwähnen sind die Lampen neben dem Display (GO,N...). Die sollte man wohl nicht verdecken?!
Was mir grad noch einfällt. Natürlich ist in Sachen Bedienung ein Touch Display nochmal was charmanter. Da schaue ich mal ob ich sowas hier auch mal teste. Touch-Prototyp geht eventuell mit Arduino-Stapel Ansatz, fertige Boards habe ich da bisher keine gesehen.

Ja. Im Ergebnis denke ich an sowas nur in schön.

Einverstanden

Das Mäusekino wird niemand vermissen.
Wenn man sich dann sogar noch sein eigenes Thema schnitzen kann ...
KITT und LCARS würde der Renner

Was man mit der obigen Hardwareanstellen kann, weiß ich nicht.
Ich weiß aber, was ich mir wünschen würde.

Nämlich einen legitimen Nachfolger zum Twizplay.
Die Software von meinem datiert auf 2013, ein Update wäre also nicht wirklich übertrieben.
Wenn man dann noch ergänzend zur Twizplay-Funktionalität das OVMS damit bedienen könnte, dann wäre es perfekt.

Der Erfolg des OVMS beruht mMn zum großen Teil auch darauf, dass der Benutzer die Software relativ einfach selbst updaten kann.
Dies war beim Twizplay leider nicht möglich.
Wie sieht das denn bei dieser Hardware aus?
Muss man da studierter Informatiker bzw. Elektroingenieur sein um die Software auf dem aktuellen Stand zu halten?

Snorre schrieb: Was man mit der obigen Hardwareanstellen kann, weiß ich nicht.
Ich weiß aber, was ich mir wünschen würde.

Nämlich einen legitimen Nachfolger zum Twizplay.
Die Software von meinem datiert auf 2013, ein Update wäre also nicht wirklich übertrieben.
Wenn man dann noch ergänzend zur Twizplay-Funktionalität das OVMS damit bedienen könnte, dann wäre es perfekt.

Der Erfolg des OVMS beruht mMn zum großen Teil auch darauf, dass der Benutzer die Software relativ einfach selbst updaten kann.
Dies war beim Twizplay leider nicht möglich.
Wie sieht das denn bei dieser Hardware aus?
Muss man da studierter Informatiker bzw. Elektroingenieur sein um die Software auf dem aktuellen Stand zu halten?

unterschreib.

Danke Snorre~
Updatebarkeit ohne Kniebruch nehme ich mit auf. Muss mir mal ansehen wie das im Moment im OVMS V3 gemacht wird. Da gibt es sicher schon nette Loesungen.
Vom Twizplay nehme ich mal mit das man mehrere Seiten zum Umschalten hat.

Im ersten Anlauf wäre ich für einen CAN Bus Logger. Es gibt einige Leute die immer mal wieder Probleme haben. U.a. Chili.
Wenn dann genügend Erfahrungen vorliegen und du noch willst, wäre neben dem Twizplay auch ein Slave Ladegerät interessant. Der erste Lader wird missbraucht um mit einem Zweitlader die Ladeleistung zu erhöhen.

Jekyll schrieb: Updatebarkeit ohne Kniebruch nehme ich mit auf. Muss mir mal ansehen wie das im Moment im OVMS V3 gemacht wird. Da gibt es sicher schon nette Loesungen.

So komfortabel wie beim V3.0 muss es ja gar nicht sein.
Klasse wäre es natürlich schon.

Das Updateverfahren des V2.0 bzw V2.5 (freie Prgrammiersoftware für MS und Linux, günstiger Pickit-Programmieradapter) oder Ähnliches, wäre für mich immer noch akzeptabel.

Snorre schrieb: So komfortabel wie beim V3.0 muss es ja gar nicht sein.

Ist der selbe Microprocessor, selbe Plattform. Auch ohne es mir angesehen zu haben, steht die Hoffnung da ähnlich herangehen zu können.

In Sachen Datenaufzeichnung:
wer hat sich damit schon umgetan? Es gibt ja schon einen CAN Logger, Dexter hat das folgende Repo angelegt:
github.com/dexterbg/CanLogger (logging data on serial)

Ansonsten: Zu dem Punkt gehört ein Stück weit auch die Auswertung / Visualisierung der Daten. Vermutlich waren es bisher CSV Datenformate mit Excel etc. ausgewertet (wie bei Dexters Logger).
Als (bei mir bereits bekannte) Alternative: ich habe bei mir in der Hausautomatisierung einen RaspberryPi verwendet, um MQTT Daten in einer Datenbank zu speichern (die Daten kommen per WLAN vom Display oder OVMS v3). Das Praktische war, dass es einige freie (IoT) Tools gibt, die man zur Auswertung der Daten nutzen kann. Bei mir war das Grafana (Auswertung als Webseite) und InfluxDB als Datenbank. Das MQTT Protokoll wird vom OVMS v3 und vom Display unterstützt.
Ansonsten muss man mal nach weiteren Logger Implementierungen im Netz schauen ... um das Rad da nicht neu zu erfinden.

Der CAN Logger von Dexter ist gut für arbeiten am stehenden Fahrzeug und auch für eine kurze Fahrt. Ein PC muß angeschlossen sein und die Informationen müssen vom angeschlossenen Notebook in eine Textdatei geschrieben werden. Eine Fehlersuche, wenn der Fehler nur alle 20km auftritt, ist schwer.
Grafana würde mich auch interessieren.

klausz schrieb: Eine Fehlersuche, wenn der Fehler nur alle 20km auftritt [...]

Würde gern an dem genauen Einsatzfällen arbeiten. Um keine Blindlesitung für ungenutzte Feature zu haben. Ist bei Chili noch Bedarf? Was fährt er ausserdem im Auto (Ovms v3?)?
Ein Tema ist mir noch zum Loggen eingefallen: um die Daten auf der Speicher Karte nicht zu korrumpieren, muss man den Logger sauber ausschalten / runterfahren ( egal welche Plattform). Wenn man das händisch 3x macht geht das schneller. Wenn man aber das absolute Dauerloggen braucht, kann man den Aufwand spendieren das im System mit einzubauen...