D0 Zähler SML auslesen mit Tasmota

Die Apps haben ja bei der Installation einen Such-Modus für den Ecotracker.
Wisst Ihr, wonach er da sucht? z.B. Growatt? Muss man diese Hürde auch nehmen, bevor man den Ecotracker "simuliert"?

hier die Version für scripter. Geht halt auch mit esp8266 Anbei scripter source code (Anhang)

und simples Beispielscript:

>D 40

>B
; set websserver on #1
won(1 "/v1/json")

>on1
print here comes the request
wcs so(4)
wcs HTTP/1.1 200 OK\r\n
wcs Content-type: application/json\r\n\r\n
wcs {"Einspeisung": %sml[1]%}
wcf


; OBIS Einspeisezähler (nur Einspeisung)
>M 1
+1,10,o,0,9600,OBIS

-1,1-0:2.8.1*255(@1,Einspeisung,KWh,Total_out,4
-1,=d 1 10 @1,Aktuelle Einspeisung,W,Power_curr,0
-1,1-0:0.0.0*255(@#),Zähler Nr,,Meter_number,0
-1,0.1.2*11(@1,test,T,zeit,0
#

Mega danke gemu2015 !!!

Das ist echt ne smarte Lösung mit wenig Scriptzeilen. Ich werde die scripter mit dem aktuellen Tasmota kompilieren und das Image dann zur Verfügung stellen. Ich sag Bescheid.

Update:

Hier der Link zu meinem Google Drive. Dort habe ich die angepasste Firmware für ESP32, ESP32-C3 und ESP8266 hochgeladen. Bislang noch ungetestet. Später werde ich alles auch hier hochladen inkl. Scriptbeispiel.

gab noch ein Problem beim Neustart, hier update

unterstützt jetzt bis zu 3 Handler

>D 40

>B
->sensor53 r

; add handler is only called on tasmota restart
; so when editing have to restart
; up to 3 handlers
>ah
; add handler #1
won(1 "/v1/json")
; add handler #2
won(2 "/v1/test")

>on1
print here comes the request 1
wcs so(4)
wcs HTTP/1.1 200 OK\r\n
wcs Content-type: application/json\r\n\r\n
wcs {"Einspeisung": %sml[1]%}
wcf

>on2
print here comes the request 2
wcs so(4)
wcs HTTP/1.1 200 OK\r\n
wcs Content-type: application/json\r\n\r\n
wcs {"test": %sml[1]%}
wcf


; OBIS Einspeisezähler (nur Einspeisung)
>M 1
+1,10,o,0,9600,OBIS
-1,1-0:2.8.1*255(@1,Einspeisung,KWh,Total_out,4
-1,=d 1 10 @1,Aktuelle Einspeisung,W,Power_curr,0
-1,1-0:0.0.0*255(@#),Zähler Nr,,Meter_number,0
#

Zitat von ottelo

Ich habe mir ein neues Tasmota32 (Generic ESP32) Image (Tasmota-15.0.1) erstellt, mit Berry, Script, GoogleChart, SML Support (Features siehe mein github). Das Image auf mein Test ESP32 geschoben und mein normales Script übertragen. Dann das Berry Script geladen. Scheint alles zu funzen.

Ich kann dir ein angepasstes Tasmota Image für dein ESPxx erstellen (mit allen Features). Welchen IR Lesekopf hast du denn bzw. welchen ESP? Es geht nur mit ESP32 (z.B. ESP32-C3).

Hallo ottelo, ich komme von deinem Blog (Kommentar) über meine dortige Anfrage hier her. Vielen vielen Dank für deine Mühe! Ich habe inzwischen einen Hichi IR V2 (ESP32) bestellt und werde dann in den Test gehen. Mein Venus E kommt hoffentlich noch diese Woche. Welcher ESP32 im Hichi IR verbaut ist, weiss ich leider noch nicht.

dig
Welcher ESP im Hichi V2 verbaut ist siehst du auch auf meinem Blog Kapitel 1 (ESP32-C3).

Ich habe gemu2015 Änderungen von eben neu übersetzt und die Images in meiner Googe CLoud aktualisiert.

Zitat von ottelo

Ich habe mir ein neues Tasmota32 (Generic ESP32) Image (Tasmota-15.0.1) erstellt, mit Berry, Script, GoogleChart, SML Support (Features siehe mein github). Das Image auf mein Test ESP32 geschoben und mein normales Script übertragen. Dann das Berry Script geladen. Scheint alles zu funzen.

ottelo: Ein riesengroßes Dankeschön an dich!

Eine super Lösung, um einen Tasmota Smartmeter Reader als Ecotracker-Datenquelle für einen Marstek Venus E zu benutzen.

Ich habe dein neues "tasmota32berry_ottelo" Image ohne Restore über die bereits laufende Tasmota Ottelo V14.6.0 (deine aktuelle Version mit SML aber ohne Berry Script) geflasht (ESP32 Cam 4MB FLASH/8MB PSRAM). Ich habe dann dein Berry Skript energy_api.be per Tasmota File Manager hochgeladen und mit load("energy_api") gestartet. Es hat sofort funktioniert (bis auf den bereits beschriebenen Fehler mit dem Print-Befehl. Es muss print(self.power) anstelle print(power) heissen).

Das Skript läuft als Tasmota-Driver jeweils mit dem Teleperiod-Zyklus, auch wenn keine Web-Requests erfolgen. Da mein Zyklus auf 1 Sekunde steht, habe ich nach einer anderen Möglichkeit gesucht. Gemini hat mir das Skript auf reine Web-Events umgeschrieben. Es läuft jetzt nur noch, wenn ein Web-Request auf <Tasmota-IP>/v1/json erfolgt. Im Skript ist dokumentiert, wo die eigenen SML-Namen eingetragen werden müssen.

Hinweis zu Berry: Ein laufendes Berry-Skript lässt sich nicht mit load("energy_api") ändern und neu laden. Es wird dann zusätzlich zu(m) laufenden alten Skript(s) quasi als weiterer Thread gestartet und die alten Skripts laufen im Hintergrund weiter. Man kann laufende Skripts leider nicht anzeigen oder stoppen. Laut Doku muss man die virtuelle Berry-Machine mit dem Befehl BrRestart von der Tasmota Console (nicht von der Berry Console*) neu starten. Danach lässt sich das Skript wieder in der Berry Console laden und starten (oder es wird einfach automatisch über ein vorhandenes "autoexec.be" nach BrRestart mitgestartet).

Mit Berry erschließen sich auf dem Tasmota ESP32 ganz neue Anwendungen, die vorher gar nicht möglich waren.
Ich fände es sehr interessant, wenn Du Berry auch in deine normalen ESP32-Firmwares einbauen könntest.

*In der Doku gibt es einen Hinweis, dass mit #define USE_BERRY_DEBUG ein Click in der Berry Console für einen Berry Restart reicht.

Ansich kann man ja mit Tasmota Script alles machen. Auch jetzt die Ecotracker-Datenquelle (siehe Beispiel von gemu2015 oben)! Also braucht man eigentlich kein Berry. Die ursprüngliche Idee war, das Image für den IR Lesekopf so schlank wie möglich zu halten, auch im Hinblick mit Abstürze/Reboots, das wir ja bereits mit Tasmota 14.x hatten. Von daher möchte ich Berry eigentlich ungern wieder mit rein nehmen. Die Frage ist auch ob die Masse das haben will oder nur vereinzelt ein paar. Das Image kann man sich ja auch schnell selbst bauen, dazu habe ich alles auf meienr github Seite beschrieben.

Zitat von Thomas

joela hast du die neue Tasmota schon mit Venus E am laufen? Wird dieser dann als Ecotracker gefunden?

Meine Lieferung des Venus E wird voraussichtlich Ende dieser Woche eintreffen, daher habe ich noch keine Erfahrungen damit.
Wenn Berry stabil läuft, wäre das ein echter Game-Changer. Bisher habe ich für komplexere ESP32 Anwendungen Micropython und für einfachere Projekte ESPEasy verwendet. Berry ähnelt Micropython stark und bietet eine moderne leistungsfähige Skript-Sprache auf dem ESP32. Von der Kombi Tasmota + Berry habe ich erst vor wenigen Tagen gehört.
Mit dieser Kombi könnte ich zukünftig alle ESP32 Projekte mit Tasmota-Berry machen. Sehr verlockend...
Es gibt eine große inoffizielle ESP32 (Classic Dual-Core) Tasmota Titanium Version, die SML, Skript und Berry beinhaltet (unter Tasmota-Specials https://github.com/Jason2866/Tasmota-specials). Das scheint die einzige andere fertige Firmware zu sein, die neben Berry auch SML mitbringt.
ottelo: Ich teste Berry erstmal mit deiner ESP32 Firmware weiter. Den Einstieg hast du mir damit schon mal sehr einfach gemacht und es hat mir viel Zeit gespart. Danke nochmal dafür.

Der Marstek Venus E 5,12 kWh (Firmware V152) Speicher ist gestern noch geliefert worden (der erste Eindruck ist sehr gut).
Hier sind meine Erkenntnisse bezüglich der CT-Emulation (Ecotracker und Shelly Pro 3EM):
Die emulierte Ecotracker-API auf dem Tasmota wird beim Suchen (Menüpunkt Ecotracker(Beta) im Bereich CT hinzufügen) in der Marstek App nicht gefunden. Die API antwortet korrekt, wenn ich sie testweise im Browser unter der URL <Tasmota-IP>/v1/json aufrufe.
Nur die automatische Suche direkt aus der App findet sie nicht. Es gibt leider auch keine manuelle Möglichkeit eine URL dafür in der App einzutragen.
interessanterweise zeigt die App beim Suchen nach dem Ecotracker ein animiertes Bluetooth Symbol. Das könnte daran liegen, dass das Mobilgerät "als Helfer" den Ecotracker im Netz sucht und die gefundene Info dann per Bluetooth an die Venus sendet (das ist nur eine Vermutung).
Auf dem App Screen steht außerdem, dass sich das Mobilgerät und der Ecotracker im gleichen (WLAN)-Netz befinden müssen. Wahrscheinlich wegen möglicher UDP-Pakete, die sonst nicht richtig geroutet werden. Da die Tasmota-Ecotracker Emulation keine UDP-Funktionalität hat, könnte auch das das Problem sein. Es könnte auch an einem fehlenden mDNS für den Ecotracker liegen, da dies beispielsweise beim Shelly Pro 3EM nötig ist, damit Venus den Shelly im Netz findet. Es gibt aber zu wenig Dokumentation und zu viel Spekulation zu dem Thema.
Ich lese auch von Schwierigkeiten, wenn der CT mit dem 2,4 GHz WLAN verbunden ist und das Mobilgerät mit 5 GHz, was eigentlich der Normalfall ist.
Ich habe danach die "uni-meter" (Docker) Emulation mit der Shelly Pro 3 EM ausprobiert. Sie unterstützt UDP und mDNS. Auch hier findet die Venus den emulierten Shelly Pro 3EM CT nicht, obwohl die Shelly App auf dem Mobilgerät den Emulator sofort per Auto-Discovery findet. Ich werde nochmal testweise einen älteren Accesspoint für die Venus einrichten. Mal sehen.
In den nächsten Tagen werde ich Modbus anschließen, da dies die umfangreichsten Steuer- und Monitoring Funktionen ermöglicht.
Ich habe im PV-Forum gelesen, dass bei Ausfall der Marstek-Cloud auch der lokale PV-Speicher (mit CT Eigenverbrauchssteuerung) abschaltet. Dies ist letzten Sonntag wohl passiert. Die Steuerung über Modbus war aber nicht betroffen.

Wenn ich die lokale Rest-API vom emulierten Ecotracker im Browser aufrufe, kommt wie erwartet: {"energyCounterIn":6472.05,"energyCounterOut":19747.9,"powerAvg":0,"energyCounterInT1":5004.77,"energyCounterInT2":1467.28,"power":-5467}
Power steht zwar hinten anstelle vorne, aber die Position der einzelnen Parameter darf bei JSON beliebig sein und kann sich auch im laufenden Betrieb mal ändern (man kann es hier auch nicht in eine bestimmte Reihenfolge bringen).
Das Problem scheint mir an der Discovery zu liegen. Ohne mDNS müsste die Venus App alle 256 IPs in der Range 192.168.1.0 bis 192.168.1.255 durchprobieren, ob die gewünschte Antwort kommt. Das könnte man vielleicht testweise im eigenen Netz so machen, aber wohl nicht als produktive Lösung anbieten. Schade ist, dass man die IP bei Marstek nicht manuell setzen kann.

Ich habe den Tasmota Hostname auf EC Tracker geändert. Wie du gesagt hast, wird der Hostname von Tasmota dann auf EC-Tracker geändert.
Das hat leider keine Veränderung gezeigt.
Direkt in der Fritzbox (7590) habe ich den Hostname dann auf EC Tracker und testweise auch auf ECTracker überschrieben.
Mit allen 3 Hostnamen führt es zu keiner Veränderung, d.h. die Marstek App läuft beim CT-Scan in den Timeout.
Im PV-Forum wird häufig über Probleme mit der Venus E und dem Mix aus 2,4 GHz und 5 GHz zwischen den Geräten berichtet.
Ich habe dazu einen 2,4 GHz AP direkt im Technikraum (wo Tasmota und Venus E stehen) aufgestellt und alle beteiligten Geräte (Tasmota, Venus E, Mobilgerät (Android und testweise IPad) auf diesen AP angemeldet. Die Marstek-App verbindet sich dabei in allen Szenarion zuverlässig mit der Venus E, im Nahbereich über Bluetooth und sonst über WLAN, aber der CT-Scan funktioniert nicht.
Auch mein parallel auf Docker laufendes uni-meter mit Shelly Pro 3EM Emulation (Docker mit LAN-Verbindung zur Frtzbox) wird nicht gefunden, egal mit welchem AP die Venus E verbunden ist.
Schade, es funktioniert so nicht.