Vehicle Homepage? Daimler, du kannst uns mal! EVIP kommt...

Ein erster Schritt müsste, meines Erachtens, sein, das man sich Hardwaremäßig zwischen Com-Modul und ED3 schaltet. Man kann doch dann bestimmt so irgendwie unterscheiden was vom COM-Modul kommt und mal abfangen das das mach wenn es zB die Vorklimatisierungszeit durchgibt.

Noch gibt es eine Hand voll ED3 mit funktionierender App. @Welker66's ED3 zum Beispiel.

Wie man die erwähnte Theorie in der Praxis umsetzt weis ich leider nicht. Ich kann sie aber auf Anweisung umsetzen und auch ein Wochenende damit verbringen Deutschland, Österreich oder die Schweiz zu durchqueren um bei einem ED3 mit funktionierendem COM-Modul eben genau das zu machen.

[MyLab-odyssey]

Ein erster Schritt müsste, meines Erachtens, sein, das man sich Hardwaremäßig zwischen Com-Modul und ED3 schaltet. Man kann doch dann bestimmt so irgendwie unterscheiden was vom COM-Modul kommt und mal abfangen das das mach wenn es zB die Vorklimatisierungszeit durchgibt.

Moritz, bitte keine Ab-/Eingriffe in den EV-CAN. Das ist überhaupt nicht trivial und es sollte auch anders gehen. Ich habe Erich explizit davor gewarnt und die Lösung über das OBD-Gateway ist auch praktikabel!
Die Lösung ist denkbar einfach: Man muß ja nur den BC programmieren Dazu habe ich mit freundlichen Usern (Rund um den Globus) mal etwas nachgehakt. Hier findet man in meinen Issue-Diskussion (#17) zu ED_BMSdiag die passenden Ansätze. Man muß nur auf die BC-ID 0x512 die Platzhalter (rezessiven Bytes) überschreiben. Also man setzt die Uhrzeit und ob A/C eingeschaltet werden soll und dann macht der Wagen das mit seiner eigenen RTC selbst. Will man direkt klimatisieren gibt man ihm einfach nur eine zu kleine Vorlaufzeit und er legt direkt los. Außerdem läßt sich mit der ID der Ladestrom regeln. Vielen Dank an die User dort (aospan, MBTP, nsb002, zkertesz et al.)!

Code: Alles auswählen

Mit
0x512 00 00 12 1E 00 00 00 00

setzt man z.B. die Uhrzeit auf 18:30. Maskiert man nun Byte 3 (0x12) mit 0x40 (und setzt so dort das zweite Bit auf High) wird die A/C Funktion mit aktiviert.

Den Ladestrom ändert man mit
0x512 00 00 1F FF 00 7C 00 00 auf 12A. 

8A = 0x74, 12A = 0x7C and 32A = 0xA4 (als max. bei 22kW). Also einen Offset berechnen 0xA4 = d164: z.B. 12A = 0xA4 - 0x7C = 0x28 = d40 -> vom Maximum (0xA4 = 32A) abziehen und dann durch zwei dividieren, um auf den Wert für 20A zu kommen (mit 0,5A Auflösung).

Aber in meinem Thread ist alles Dokumentiert, nur das Wecken vom Bus ist noch nicht vollständig untersucht aber auch da sind wir dran...

Also ges gibt viel zu tun - dranbleiben

Moritz, bitte keine Ab-/Eingriffe in den EV-CAN. Das ist überhaupt nicht trivial und es sollte auch anders gehen. Ich habe Erich explizit davor gewarnt und die Lösung über das OBD-Gateway ist auch praktikabel!

Alles klar. Dann lass ich die Finger da auch besser raus
Euer Lösungsweg erscheint mir auch der besser dankt weniger Risiko.

[martin]

Odyssey, du bist ja gut infomriert und daher wollte ich dich fragen, ob du schon probiert hast die Leute von OVMS dazu zu bewegen den Smart zu ingegrieren?
Du hast ja in der zwischenzeit die wichtigsten Can Nachrichten entschlüsselt und ich sehe es wie du, die Hardware in V3 ist wirklich top (auch mit LTE)
Oder gibt es andere Gründe warum der Smart noch nicht mit OVMS kann?

[Mad]

So wie ich das sehe gibt es keine "Leute von OVMS", das ganze ist jeweils auf die Initiative von Privatleuten zurückzuführen, die sich aufgerafft haben und für den entsprechenden Fahrzeugtyp das OVMS implementiert haben.

Also einfach selber einbringen

[erich]

Es sind nun mal 10 Platinen für meinen MQTT/SD Logger mit Touchscreen bestellt und auf dem Weg zu mir.
Die vier händisch verkabeltne Prototypen (1x Smart, 3x Zoe) laufen seit ein paar Monaten sauber und weitestgehend Bugfrei.
Für meinen Teil reicht mein eigener MQTT-Server vollkommen.

Da aber einige nach einer Lösung gefragt haben die keinen eigenen Server im Internet stehen haben, ich aber nichts für die habe oder programmieren will, hat das Seichobob angeboten.

Er ist Web-Programmierer und hat auch eine Zoe.
Er würde die Seite, die er für sich selbst Bauen will und die auf meiner Hardware aufsetzt Multiuser-Fähig machen, damit auch die, die keinen eigenen Server haben, wieder an die Daten ihres Smarts/Zoes kommen.

Er bekommt eine der ersten Platinen und kann dann selbst entscheiden was er damit macht und wie er es anderen zur Verfügung stellt.

Ob man in der Hardware dann meinen privaten MQTT-Server (der ist nur für mich) oder den von Seichobob (der ist dann für ihn und ggf für weitere) einträgt oder man einen eigenen Server hat und es darüber laufen lässt, oder ob man eine ganz andere Lösung will (ovms) oder was es sonst noch alles gibt. Das ist jedem selbst Überlassen und ich will auch keine Wertung abgeben was besser oder schlechter ist.

Ich weis nur, dass meine Lösung für mich passt und funktioniert.

Es mag sicher noch andere Ansätze geben die ggf. sogar einfacher, günstiger oder besser sind.
Aber da scheint noch nichts fertig zu sein. Somit bleibe ich erst mal bei meiner eigenen Lösung.

Der Code auf dem esp32 ist inzwischen 100% neu geschrieben. Vom BMS-Diag Code der auf dem Arduino damals lief existiert nichts mehr. Das einzige was in beiden Codes gleich ist sind die CAN-ID's. Aber schon bei der Berechnung einiger Werte sind wir uns teilweise nicht mehr einig.

Wenn, dann setzt unser beider Code auf Daimlers ID's auf. Aber meiner inzwischen nicht mehr auf dem von odyssey. Ja, odyssey war der erste der am Bus geschnüffelt hat und er hat auch das BMS mit Abfragen im Griff die ich mich nicht mal im Ansatz traue ab zu setzen, aber die Telemetrie von mir ist was 100% neues und eigenes. Andere Hardware, andere Software, andere Server, anderer Einsatzzweck, ...

Ich versuche es positiv und neutral zu sehen.

Jeder kann das nehmen was für seine Anforderungen das sinnvollste ist oder sich selbst etwas bauen.

Um die Batteriedaten aus zu lesen = BMS-Diag
Um Telemetrie zu machen = nehm ich meine Lösung

Ich will niemanden etwas aufschwatzen, zu etwas zwingen oder überreden.
Mein Display ist primär für mich. Wenn aber jemand meint, dass er auch so etwas möchte teile ich gerne mein Wissen.

Dies beschreibt genau die "Zusammenarbeit" von Seichobob und mir.
Es ist keine "Zusammenarbeit" im klassischen Sinn. Er möchte einfach das nachbauen was ich habe um selbst dann mit seinem Wissen darauf aufbauen um damit letzendlich eine eigene Lösung für sich zu realisieren. Nicht mehr und nicht weniger.

Es gibt auch noch Uli hier im Forum. (Er hat das Zoe Display geschrieben) Auch er möchte die Platine mit dem ESP32 und dem Display haben. Aber er will nur die Hardware und sich ggf. selbst die Software neu schreiben. Er ist Programmierer und will nur eine einfache, schöne in das Auto integrierte Hardware Plattform zu haben ohne sich mit Prototypen-Arduino-Shields und rumhängenden Kabeln rumärgern zu müssen.

Es laufen bisher mehr Zoes (3) als Smarts (1). Aber die Software kann beide Autos. Wir könnten auch noch weitere implementieren. Wie z.B. den Kona oder was weis ich noch. Einfach die CAN-ID's her und es gibt eine neue Version.

[SolElektrikFan]

Hallo Seichobob & Erich,

tut mir wirklich leid, dass Deine/Eure Projektidee hier so niedergemacht wurde. Hoffe, Du/Ihr bist jetzt nicht zu sehr gefrustet und beantwortest mir und vielleicht anderen, ob Deine Lösung mittlerweile funktioniert.

Fahre jetzt seit Ende Juli einen Smart Fortwo ED 451 und bin auch auf der Suche nach einer entsprechenden Lösung.
Ich war auch ziemlich enttäuscht über das Verhalten von Daimler nachdem Sie den Dienst eingestellt haben,
nicht mal eine Ersatz-Lösung für das Problem liefern zu können.

Meine Lösung
Habe mir einen ODB2-Wifi-Adapter besorgt. Für Android gibt es diverse Apps, z.B. EVNotify. Leider fehlt "unser" Auto noch in der Auflistung. Ich stehe aber mit dem Entwickler Giuseppe in Verbindung und hoffe auf baldige Umsetzung, kann Dir dann gerne Bescheid geben.

[erich]

Ach gefrustet bin ich nicht.

Meine Lösung funktioniert für mich tadellos.

Für viele von Euch könnte es aber ein Problem sein, denn nicht jeder von Euch hat einen eigenen MQTT-Server im Internet stehen der dann die Daten, schön aufbereitet, zum Handy schicken kann.
Das sind doch recht spezielle "Shellscripte auf Drogen" die ich mir damals für mich zusammengeklopft habe.
Die sind in keinster weise "multiuser" tauglich oder sonst wie sinnvoll skalierbar für viele.

Die Hardware und das senden zu einem MQTT ist kein Thema. Das haben wir im Griff.

Und für den "Empfangs und schön aufbereitungs-Part" kommt nun demnächst der eine oder andere Tester.

Hier der aktuelle Lösungsansatz für die die keinen eigenen Server im Netz stehen haben.

Zum Datensammeln (vom Auto)
Freie MQTT-Server gibt es...
https://www.cloudmqtt.com/plans.html (der kostenlose CuteCat sollte reichen)

Zum schönen aufbereiten und anzeigen der MQTT-Daten auf einem Handy oder auf dem Rechner...
http://www.thingstud.io/ (da bin ich noch am probieren wie das funktioniert)

Wenn sich jemand von Euch mit dem http://www.thingstud.io/ auskennt oder sich da etwas einarbeiten möchte, dann darf er/sie/es sich gerne bei mir melden.

Grüße...
...Erich

[asdfle]

Ich finde Euer Projekt auch spannend - und könnte beim Prototypenaufbau oder Testen mithelfen.