Ben77

Hallo Eweri, habe unter iobroker einen mqtt-Server aufgesetzt mit dem der WiCan Dongle und evcc kommunizieren. Mqtt-Server kann natürlich auch auf HA laufen, oder mosquitto auf einem Raspberry z.b. In der evcc.yaml dann "vehicles" wie folgt angepasst: vehicles: - type: custom name: my_hyundai title: Ioniq icon: car phases: 1 capacity: 38.6 soc: source: mqtt topic: wican/dc0675xxxxxxx/can/soc Dann "loadpoints" noch angepasst: loadpoints: - title: Garage charger: my_charger vehicle: my_hyundai mode: pv phases: 1 priority: 10 mincurrent: 6 maxcurrent: 20 soc: poll: mode: charging interval: 1m estimate: false VG Ben

Habe seit 2 Monaten einen WiCan Dongle den ich an unserem Ioniq nutze. In Verbindung mit evcc klappt das super. Sobald ich den Ioniq mit der WARP3 verbinde, wacht der OBD Port auf und der WiCan überträgt per MQTT den SOC an evcc. So bin ich endlich die teils häufigen Bluelink Probleme los und habe eine unabhängige Standalone Lösung. Das es da z.b. mit dem ID4 Probleme mit der Alarmanlage gibt, ist natürlich schade :( Die Idee, das Wifi Modul der WARP mit dem ETH zu bridgen ist klasse, so hätte man gleich den Wifi-AP für den WiCan. Vorausgesetzt die WARP ist per LAN angebunden. Um den SOC direkt von WiCan auf die WARP zu bekommen, wäre auf der WARP ermutlich ein MQTT Server erforderlich. Ob der ESP der WARP dazu noch Kapazitäten frei hat ? Wäre natülich der Hammer wenn man auf der WARP3 noch einen MQTT Server unterbringen könnte. So könnten WARP und evcc direkt ohne Umwege über einen externen MQTT Server miteinander sprechen.

Ich würde mir diese Arbeit beim Kunden gerne einsparen und könnte mir zudem vorstellen, dass es für den Hersteller oder dessen Zulieferer kein nennenswerter Mehraufwand wäre, das entsprechede Loch gleich vorzusehen und eine Kabelverschraubung mehr mit einzupacken. Maschinell ist das Loch zudem präziser als mit Stufenbohrer. Von anderen WB`s kenne ich das nur so, dass für alle möglichen Zuleitungen eine entsprechende Kabeleinführung vorgesehen ist.

Hallo, habe bei uns das CAT7 Kabel ab der Kabel Einführung entmantelt und Schrumpfschlauch drüber gezogen bis zum Stecker. Dann ein 2adriges Steuerkabel entspreched auch entmantelt und die 2 Adren mit durchgesteckt. So passt es nun, aber ganz optimal finde ich die Lösung nicht. Eine 2. Kabeldurchführung (die ggfs. ab Werk mit einem Blindstopfen versehen ist) würde ich mir auch wünschen.

Wäre es nicht besser dies über "1040 / Battery max. discharge power limit, absolute Erlaubte entladeleistung" zu regeln anstatt über den MinSOC ? Habe mal irgendwo gelesen das der Wert alle xx Sekunden neu gesendet werden muss. Infos z.b. im iobroker Forum findet man zu dem Thema einiges. Neuste Firmware auf dem Plenticore ist auch ratsam. Bei Sungrow z.b. kann der MinSOC nur im Bereich 5-49 genutzt werden und verfälscht dann den angezeigten Ladestand. Ich selbst nutze bei Sungrow daher auch Max Discharge Power um die Batterieentladung zu verhindern.

Besten Dank @borg

Würde ich auch sehr begrüßen wenn es Alternativen gibt die App auch ohne Google auf das Smartphone zu bekommen ;) Denke auch die Community der dies wichtig ist, wächst stätig.

Für IOBroker gibt es einen fertigen Adapter, das wäre der einfachste Weg. Oder evcc installieren und die fertige implementierung für HA nutzen. Natürlich gehts auch via API ;)

Die EVU`s möchten ja am liebsten eine komplett verdrahtete Ansteuerung, per LAN sollte aber möglich sein. Der Shelly müsste also auch per LAN angebunden sein, und nicht per Wlan. Weiss gar nicht ob es aktuell Shellys mit LAN gibt, die auswertbare Eingänge haben. Ich suche mal nach geeigneter Hardware.

Habe eine Fritzbox, ISP ist Sewikom. Hinter der Fritzbox habe ich eine pfsense Firewall hinter der dann die verschiedenen Subnets/VLANs sind. In der pfsense habe ich ausgehend Port 51820 UDP für die IP der WARP3 freigegeben. Ohne diese Freigabe war die Verbindung zu my.warp-charger.com nicht möglich.

Wird dieses zusätzliche Gerät eine Hardware aus Eurem Hause ? Gibt es da schon nähere Infos ? Wir planen gerade mehrere Projekte mit der WARP3 bei denen §14a umgesetzt werden muss.

Wenn es bei den Automatisierungen nun noch eine 2. Bedingung gäbe, wäre die WARP fast perfekt. Wenn der Front­taster gedrückt wird UND der Lademodus "AUS" ist, wechsle Lademodus auf PV. Wenn der Front­taster gedrückt wird UND der Lademodus "PV" ist, wechsle Lademodus auf Min + PV. Usw. Dann könnte man wenigstens alle Lade-Modis über den Taster steuern, was ich von einer Wallbox mit Taster eigentlich erwarte. Das wäre für mich als Kunde, der nicht den ganzen Tag das Smartphone in der Hand hat, die wichtigste Funktion für den Taster. Dazu noch die passende LED Farbe (z.b. PV=Grün / Min+PV= Grün-Gelb / Schnell=Blau) und die Sache wäre rund ;)

Du hast Recht, ist natürlich UDP. War ein Tippfehler. Bisher hat 51820 UDP als Freigabe ausgereicht. 51821-51825 habe ich bisher nicht öffnen müssen (habe aber auch nur einen Benutzer).

Du hast unter Eco-Modus die Ladeplanung aktiviert. Da diese den Modus Min + PV wesentlich beeinflusst, wird dies auf der Statusseite vermutlich deshalb in ECO + PV geändert. Sobald Du die Ladeplanung deaktivierst, hast Du den Min + PV Modi wieder zurück ;)

Danke für diese hilfreichen Infos @ffreddow

Für Firewall Nutzer noch der Hinweis, dass die Wallbox IP ausgehend für Port 51820 TCP freigegeben werden muss. Seit ich diese Freigabe eben hinzugefügt habe, kann ich den Fernzugriff nutzen. @ffreddow Kann es sein, das die Freigabe nur einmalig bei dem ersten Login des jeweiligen Endgeräts nötig ist ?