#define MDNS_ENABLED true
Sollte mdns in Tasmota erlauben
#define MDNS_ENABLED false // [SetOption55] Use mDNS (false = Disable, true = Enable)
Nachdem was ich gelesen habe, kann man damit nur den Tasmota-Hostnamen per mDNS publishen.
Es lässt sich damit kein anderer Hostname wie "Shelly..." publishen.
Die Marstek App findet den emulierten Shelly Pro 3EM mit dem UDP-Skript und neuer UDP Tasmota-Firmware beim CT-Scan nicht.
Nach ca. 40 Sekunden Scan erfolgt nur ein Timeout. Die UDP Debug-Message payload ist in der Tasmota-Console nicht geloggt.
Ein Webbrowser-Aufruf der Rest-API unter <Tasmota-IP>/v1/json wird aber beantwortet mit {"Einspeisung": -1870.00} und findet sich im Log unter here comes the request 1.
Soweit ich gelesen habe, wird für die Discovery des Shellys mDNS verwendet. Danach wird ein Remote Procedure Call mit UDP auf die gefundene IP ausgeführt. Ich denke es scheitert hier an der Discovery des Shellys.
Ich habe auch bei Everhome angefragt, entgegen der Aussage von Marstek soll es nicht ohne Cloud funktionieren.
...everHome
Hallo, es ist aktuell nicht möglich den EcoTracker ohne everHome zu betreiben. Ein Zählerschrank schirmt weniger stark ab, als man zunächst annimmt. Wenn dein Smartphone im Zählerschrank WLAN-Empfang hat, hat der EcoTracker dies ebenfalls. Beste Grüße Daniel everHome
Die Antwort von Everhome scheint veraltet zu sein, da es eine lokale REST API im Ecotracker gibt, die zudem in der App auch für jeden sichtbar aktiviert werden kann (habe ich so gelesen). Es passt auch nicht zur Funktionsweise der Marstek App, die bei Auswahl vom "Ecotracker(Beta)" keine Cloud-Zugangsdaten erfragt. Das könnte so wie Everhome sagt gar nicht funktionieren.
Könntest du im Everhome-Chat noch mal auf diesen Widerspruch hinweisen?
Wenn der WLAN Name des Ecotrackers wirklich "EC Tracker" ist, kann man den mit Tasmota nicht vorgeben da das Leerzeichen immer durch "-" ersetzt wird. Habe auf die Schnelle nicht gefunden wo Tasmota das macht. Müsste man testhalber mal auskommentieren.
Erst dann hätte man eine Chance das es mit dem Ecotracker REST API funktioniert.
Wenn ich den WLAN Namen/Hostname des Tasmotas in der Fritzbox ändere, dann müsste das doch den Hostname des Tasmotas aus Sicht der Venus E und der anderen Geräte im Netz überschreiben, oder?
P.S. Die Modbus-Schnittstelle für die Venus E habe ich seit gestern mit Soll-Vorgabe der Lade- und Entladeleistung nach den Messwerten am Hausanschluss im Testbetrieb. Der erste Eindruck ist sehr gut. Ich bekomme die Bezugs/Einspeise-Messwerte im Augenblick im 4 Sekunden Takt aus einer API der PV-Anlage und sende die neuen Vorgabewerte direkt an die Venus E, die es direkt umsetzt. Das Modbus Ethernet Gateway (Elfin EE11) zeigt auch die Fehlerstatistik der RS485 Schnittstelle an. Bei 20 MB bis jetzt 0 Fehlerbytes. Bislang läuft alles fehlerfrei.
Ich habe den Hostnamen everhome-ecotracker in allen Kombinationen in Tasmota und Fitzbox eingetragen, in der Fritzbox testweise auch mal ohne den Bindestrich. Der Ecotracker wird aber nicht gefunden, unabhängig ob ich es mit der Android oder IPad App probiere. Alle Geräte waren im gleichen 2,4 GHz WLAN, welches ich nur zum Testen eingerichtet habe.
Das wäre gut, wenn du es bei dir testen kannst. Im PV-Forum haben die meisten augenscheinlich auch keine Probleme mit der uni-meter Emulation, die bei mir von der Venus E auch nicht gefunden wird. Ich habe übrigens die Venus E Firmware V152. Ein Update auf die V153 wird noch nicht angeboten. Ich würde die Ecotracker-Emulation gerne als Backup-Lösung einsetzen.
Hast du auch Mal Hostname Ecotracker oder eco-tracker probiert.
Ich hab es gerade mit beiden Hostnames probiert, aber der CT-Scan läuft auch hier in den gleichen Timeout.
Hast du auch Mal Hostname Ecotracker oder eco-tracker probiert.
Ich melde mich gleich nochmal.
Kurze Info: Wie gesagt wollte ich die Venus E über Modbus steuern. Ich habe jetzt das Modbus RTU (RS485) Interface von der Venus E mit einem Modbus Elfin EE11 (Modbus RTU nach Modbus TCP Ethernet), im lokalen IP-Netz verfügbar gemacht. Mit dem ioBroker Modbus Adapter und den passenden Venus E Holdingregistern (importiert aus Marstek_KJ.txt) aus dem PV-Forum Thread https://www.photovoltaikforum.com/thread/244060-…broker-steuern/ hat die Verbindung sofort funktioniert. Damit stehen sämtliche Akku-Parameter sekündlich zum Lesen und Schreiben bereit. Auch die Watt-genaue Steuerung von Laden und Entladen hat im Test sofort funktioniert 
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.
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.
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.
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.
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.
