SoC: OVMS

[rleidner]

Hier wird bei Fragen und Problemen zum SoC-Modul OVMS geholfen.

Aktueller Stand:
2.x: PR: https://github.com/openWB/core/pull/1743 (in 2.1.6 master gemerged)
1.9: PR: https://github.com/snaptec/openWB/pull/2847 (in 1.9.304.0 Nightly gemerged)

Das OVMS-Modul im Fahrzeug sendet je nach Ausführung die Daten über Mobilnetz und/oder WLAN an den OVMS-Server (z.B. ovms.dexters-web.de).
Die OVMS Smartphone-Apps (Android/ios) verbinden sich mit dem gewählten OVMS-Server.
Das SoC-Modul holt die Daten auch vom selben OVMS Server.

Folgende Daten werden bei der Konfiguration benötigt:
- Server URL
- User Id des Accounts im OVMS-Server
- Passwort des Accounts
- VehicleId des Fahrzeuges (wird bei der Einrichtung des OVMS-Moduls vergeben)
- Abfrage-Intervall wenn nicht geladen wird
- Abfrage-Intervall wenn geladen wird.

[Stevie_AN]

Hallo,

also eigentlich sendet das OVMS den SoC über MQTT ja bereits raus. Man müsste somit nur irgendwie der OpenWB klar machen, dass der ankommende Topic "ovms//*vehicleid*/metric/v/b/soc" als "openWB/set/lp/1/%Soc" verstanden werden soll.

ICH kann das leider nicht. Darum hab ich das über NodeRed lösen müssen.

WENN wir der OpenWB also beibringen wollen, dass sie den SoC vom OVMS richtig interpretieren soll, dann würde ich das nicht über Dexter's Server machen, sondern direkt im lokalen Netz regeln.

Und da bietet sich für mich halt MQTT an.

[rleidner]

Hallo,

also eigentlich sendet das OVMS den SoC über MQTT ja bereits raus. Man müsste somit nur irgendwie der OpenWB klar machen, dass der ankommende Topic "ovms//*vehicleid*/metric/v/b/soc" als "openWB/set/lp/1/%Soc" verstanden werden soll.

ICH kann das leider nicht. Darum hab ich das über NodeRed lösen müssen.

WENN wir der OpenWB also beibringen wollen, dass sie den SoC vom OVMS richtig interpretieren soll, dann würde ich das nicht über Dexter's Server machen, sondern direkt im lokalen Netz regeln.

Und da bietet sich für mich halt MQTT an.

Danke für den Hinweis - ich bin normalerweise auch für MQTT.
Mein OVMS-Modul published über MQTT auf einen lokalen Broker (nicht der in der openWB).
Von dort mache ich einiges in Node-Red wie logging diverser Daten in InfluxDB oder Starten der Klimatisierung im smart wenn die 12V-Batterie-Spannung zu niedrig wird.
SoC/Range an die openWB weiterzureichen ist dann kein grosser Aufwand mehr.

Warum ich es dann doch über OVMS-Server gelöst habe:
Ich wollte die Daten aus dem OVMS auch, wenn das Fahrzeug unterwegs ist - deshalb über den OVMS-Server.
Ich habe das Modul hauptsächlich implementiert, weil zum Jahresende die smartEQ Cloud abgeschaltet wird und ich wollte einen gleichwertigen Ersatz.

BTW, falls Du es nicht gesehen hast:
Ohne spezielles SoC-Modul und Node-Red ginge es wohl lokal auch: https://forum.openwb.de/viewtopic.php?p=7186#p7186

[Stevie_AN]

BTW, falls Du es nicht gesehen hast:
Ohne spezielles SoC-Modul und Node-Red ginge es wohl lokal auch: https://forum.openwb.de/viewtopic.php?p=7186#p7186

Ja, diese Lösung über den HTTP-Soc hatte ich am Anfang auch genau so eingerichtet. Es wäre natürlich interessant, ob man das OVMS-Script

Code: Alles auswählen

/**
/**
 * Module plugin: openWB soc
 *  Version 1.0
 * 
 * Dependencies:
 *  - OVMS firmware >= 3.2.008-266
 * 
 * Installation:
 *  - Save as /store/scripts/lib/openwbsoc.js
 *  - Add to /store/scripts/ovmsmain.js: openwbsoc = require("lib/openwbsoc");
 *  - Issue "script reload"
 * 
 */


// Get state of charge:
function getSoc() {
  var soc = OvmsMetrics.Value(["v.b.soc"]);
  
  if ( soc )
    print(Math.floor(soc));
  else print(0);
}

// API exports:
exports.get = getSoc;

...so abändern kann, dass es auf dem V3-Server den SoC auf den Broker der OpenWB mit dem passenden Topic schickt?

[rleidner]

...so abändern kann, dass es auf dem V3-Server den SoC auf den Broker der OpenWB mit dem passenden Topic schickt?

Da sehe ich keine einfache Lösung; ich denke dazu müsste man die OVMS Firmware um eine generische mqtt-publish Funktion erweitern.