jansch

Ich möchte das Thema nochmal weiterführen. Ich tendiere nun eigentlich zu einem Elgris Smart Meter LAN 2.0. Dieser ist laut Geräteliste via SunSpec kompatibel. Jetzt habe ich bei Elgris zusätzlich den Smart Meter IOT entdeckt. Dieser ist laut Beschreibung ein abgespeckter LAN (ohne SMA Kompatiblität, einer Modubus Schnittstelle weniger etc.), aber mit SunSpec. Gehe ich recht in der Annahme, wenn da Modubus/TCP/SunSpec drauf steht, dass er wahrscheinlich auch Out of the Box kompatibel mit der WARP sein wird?

Moin, ich konnte es gestern noch erfolgreich testen. Mein Lesekopf am Zähler, der normalerweise seine Daten zu einem MQTT Broker schiebt, schreibt jetzt seine Daten ebenfalls in einen virtuellen API Zähler der WARP3. Falls jemand mal sowas mit esphome realisieren möchte, hier mein Beispielsketch: esphome: name: "esphome-lesekopf-zaehler" friendly_name: Stromzähler min_version: 2025.5.0 name_add_mac_suffix: false esp8266: board: esp01_1m # Enable logging logger: baud_rate: 0 #level: INFO # Enable Home Assistant API api: encryption: key: !secret api_enc_key # Publish to MQTT mqtt: broker: <brokerhost> username: <mqttuser> password: !secret mqttuser_password discovery: False # disable entity discovery discover_ip: True # enable device discovery topic_prefix: grid/meter time: - platform: homeassistant # enable http request http_request: esp8266_disable_ssl_support: true follow_redirects: false timeout: 0.5s # Allow Over-The-Air updates ota: - platform: esphome wifi: min_auth_mode: WPA2 networks: - ssid: !secret wifi_ssid_iot password: !secret wifi_password_iot # To have a "next url" for improv serial web_server: ota: False #log: False version: 1 button: - platform: restart name: restart internal: True uart: tx_pin: TX rx_pin: RX baud_rate: 9600 data_bits: 8 parity: NONE stop_bits: 1 # debug: sml: sensor: - platform: sml name: "Bezug Total" obis_code: "1-0:1.8.0" unit_of_measurement: kWh accuracy_decimals: 2 device_class: energy state_class: total_increasing filters: - multiply: 0.0001 - platform: sml name: "Lieferung Total" obis_code: "1-0:2.8.0" unit_of_measurement: kWh accuracy_decimals: 2 device_class: energy state_class: total_increasing filters: - multiply: 0.0001 - platform: sml name: "Leistung" obis_code: "1-0:16.7.0" unit_of_measurement: W accuracy_decimals: 0 device_class: power state_class: measurement on_value: then: - http_request.send: method: POST url: http://<warphost>/meters/1/update request_headers: Content-Type: application/json body: !lambda |- return "[" + to_string(x) + "]"; Relevant für den API Teil sind die Abschnitte # enable http request http_request: esp8266_disable_ssl_support: true follow_redirects: false timeout: 0.5sum http_request grundsätzlich erstmal zu aktivieren und globale Parameter zu setzen und - platform: sml name: "Leistung" obis_code: "1-0:16.7.0" unit_of_measurement: W accuracy_decimals: 0 device_class: power state_class: measurement on_value: then: - http_request.send: method: POST url: http://<warphost>/meters/1/update request_headers: Content-Type: application/json body: !lambda |- return "[" + to_string(x) + "]";und zwar insbesondere der Abschnitt ab "on_value". Dieser bewirkt in diesem Fall, dass - sobald dieser Sensor einen neuen Wert bekommt, der HTTP Request auf die API getriggert wird. Alternativ wäre auch denkbar dies statt an die Wertänderung einfach an einen Timer zu hängen (on_time, interval). Edit: Mein Stromzähler ist übrigens ein SGM-DD von EFR, welcher häufig bei uns von der Digimeto verbaut wird. Falls jemand eine exakt passende Basis für den üblichen Selbstbau-Lesekopf benötigt, wird er hier fündig: https://www.printables.com/model/1437844-lesekopf-stromzahler-sgm-dd

Ah sehr gut. Ich versuche das gleich heute Abend mal zu Hause sollte ja mit einem http_request aus dem ESPhome auch zu bewerkstelligen sein.

Danke für den zusätzlichen Vorschlag. Für den EM24 habe ich bisher aber eher Preise in der ~100 Euro Liga gefunden. Bin ich da irgendwo falsch abgebogen?

Danke Matze! @wuesten_fuchs So würde ich das, wäre es meine eigene Anlage, tatsächlich auch in Erwägung ziehen bzw. lese ich meinen Zähler bereits mit einem IR Lesekopf mit esphome aus - allerdings nicht zum Überschussladen sondern um den Akku des Balkonkraftwerks zu steuern. Ist bei meiner mäßigen PV Fläche aber eher Hobby als alles andere und von Überschussladen brauche ich nicht träumen. Bei der Anlage, um die es hier geht, handelt es sich aber um die eines Familienmitglieds, welche ich mehr oder weniger remote IT technisch betreuen muss/will. Da möchte ich solche, mir grundsätzlich durchaus sympathischen, Bastel-Lösungen nicht unbedingt haben. Wenn dann mal der Zähler getauscht wird, muss man den neuen wieder freischalten, eventuell neues Gehäuse für den Lesekopf drucken etc. und dann steht das Tage bis Wochen bis der Pin da ist, weil die sich da erfahrungsgemäß auch kein Bein ausreißen. Und wenn mal jemand gegen den Lesekopf stößt ist auch gleich aus... Eine feste Installation mit dem EM24, an die man dann nicht mehr ran muss, die mir ausgiebig erprobt und stabil erscheint und wo auch normalerweise kein Dritter dran geht, ist mir da lieber. Die Installation macht eh der Elektriker - da halte ich mich, zumindest im Bereich Hausanschluss, raus. Aber um jetzt endlich auch Mal zum Punkt zu kommen. Interessant ist das ja trotzdem. Könnte der Bitshake direkt mit der Warp reden und beispielsweise einen virtuellen Zähler über die API füttern, oder braucht es da noch einen Mittler (home assistant oder was auch immer)?

Moin, ich stehe vor folgendem Thema: Eine alte PV Anlage soll für PV Überschussladen mit der Warp4 genutzt werden. Hierfür soll ein zusätzlicher Zähler am Hausanschluss installiert werden, welchen die Wallbox über Ethernet abfragen kann. Nach Lesen der Kompatiblitätsliste schwanke ich derzeit zwischen diesen beiden Modellen: Shelly Pro 3EM Carlo Gavazzi / Victron EM24 Welcher dieser beiden Zähler ist die bessere Option, falls man das so sagen kann? Gibt es eine Empfehlung oder eventuell ein ganz anderes Modell, welches ich noch nicht auf dem Schirm habe? Zweck des Zählers wird derzeit und auch in absehbarer Zukunft nur PV Überschussladen. Keine ESS Steuerung etc. Er soll also möglichst Preiswert (nicht billig!) sein, Ethernet und natürlich Warp kompatibel zwecks PV Laden. Danke für eure Gedanken! MfG Jan

Das sind ja gute Nachrichten. Danke für die schnellen Antworten!

Das klingt hervorragend. Ist dafür schon ein Release-Zeitraum angepeilt?

Hallo Gemeinschaft, dies ist mein erster Beitrag hier. Seid bitte gnädig, falls ich etwas übersehen habe, was die Etikette angeht. Ich selbst lade seit etwas mehr als einem Jahr glücklich mit einer warp 3. Nun konnte ich meinen Bruder, für seine Neuinstallation, zu 95% davon überzeugen, eine warp 4 pro zu bestellen. Hierzu habe ich noch eine oder zwei Fragen. Keine harte Anforderung, aber ein Thema, welches sehr praktisch wäre und mich auch in meinem, eh schon ausgeprägten, Bedürfnis zum warp4 Upgrade bestärken würde. Ist geplant, einen Lademodus zu implementieren, der es ermöglicht, z.B. in der Ladeplanung einen Ziel Ladestand, statt einer Ladedauer anzugeben? Über ISO15118 und die Schätzung des Ladestand während des Ladens (so habe ich es zumindest aus den Fahrzeugprofilen in der Doku herausgelesen), sollten die Voraussetzungen ja vorhanden sein. Meine Wunschvorstellung wäre, dass man in Normalfall das Auto bei Ankunft einfach ansteckt, es über Autocharge erkannt wird und im PV+Eco Mode zur Standard Abfahrtzeit auf eingestellten Zielwert geladen wird. Wäre es auch denkbar, dass man global, oder je Fahrzeug, die Ladung generell auf einen bestimmten Zielwert (z.B. ~80%) zu beschränken (was man ggf. auch durch irgendeine Aktion übersteuern könnte)? Mache Fahrzeuge bieten ja leider nicht die Möglichkeit die Ladung zu beschränken. Danke und Grüße Jan