Hi. SML\r ist der Name, den du in der Meter Description (>M Sektion) vergeben hast! Da hast du wohl ein \r drin.
Du hast auch einmal "Status 10" das andere mal "Status10" eingegeben. Das gibt unterschiedliche Ausgaben!
Hi. SML\r ist der Name, den du in der Meter Description (>M Sektion) vergeben hast! Da hast du wohl ein \r drin.
Du hast auch einmal "Status 10" das andere mal "Status10" eingegeben. Das gibt unterschiedliche Ausgaben!
Omega13 Ein Tippfehler
da es nur eine Debugausgabe für die Console ist, ist das egal ![]()
Danke für Infos. Das liegt tatsächlich an meinem Zähler und nicht an Tasmota.
Mal eine Frage in die Runde. In welchem Intervall sendet euer Zähler die Daten? Ich habe ein MT175 und laut Console (sensor53 d1) sendet meiner in keinem festen Intervall, sondern zwischen 1-4 Sekunden. Komischerweise sendet er in kürzeren Abständen bei höheren Leistungen (>1000W). Das ist sehr merkwürdig ...
Man kann das auch gut via MQTT sehen. Dafür muss man natürlich die Daten sofort senden lassen, das geht mit einer 16 (keine Dezimalstelle) oder 17 (eine Dezimalstelle) am Ende der SML Zeile z.B:
1,77070100100700ff@1,Leistung,W,Power_curr,16
Wäre eine gute Idee, dafür einen passenden Thread aufzumachen. Auch gerne im anderen Forum. Welcher SmartMeter unterstützt der Growatt (Noah)?
Kurzes Update bzgl. EcoTracker / Shelly Emulation mit Tasmota-Lesekopf (Hitchi / Bitshake /...) für Marstek und Hoymiles Akkus:
Ich habe die beiden Scripte 1_SML_EcoTrackerEmu_Simple.tas und 2_SML_Script_Chart_PV_EcoTrackerEmu.tas aktualisiert, nun findet auch der Hoymiles Akku (MS-A2) den Emulator via App / Nulleinspeisung läuft mit dem Emu.
Anleitung auf meinem Blog.
Zur Info:
>T
pcurr=0-SML#Power_curr
Funktioniert doch, wenn im SML Deskriptor der Name auch SML ist. Ich hatte bei mir einen anderen Namen und deshalb ging es nicht.
Mhh dann ging das wohl früher mal und wurde dann geändert auf sml[x]. Mit den neueren Images gehts jedenfalls nicht, naja ![]()
SML#Power_curr dürfte aber nicht funktionieren...
kannst du mal ein print in der >S Sektion setzen:
print %SML#Power_curr%
Bei mir funktioniert das nicht, auch nicht in der >T Sektion.
Ich habe mir mal dein Script angeschaut und mich über folgendes gewundert:
Da es in der Tasmota Script Wikiseite auch als Beispiel aufgeführt wurde habe ich es mal bei mir getestet. Das funktioniert nicht! Evtl. wurde da was mit rules verwechselt (ich habe direkt mal ein PR github erstellt) ... Wenn du auf Power_curr zugreifen willst, dann musst du das mit der Variable sml[x] machen !
Aus der Wiki:
To get the value of one of the descriptor lines, use sml[X]. X = Line number. Starts with 1. (compiling with USE_SML_SCRIPT_CMD required)
Außerdem braucht man eigentlich nie die >T Sektion. Du kannst pcurr=0-sml[3] auch in die >S setzen. Aber das Script hat sowieso noch mehr Fehler. pcurr2 wurde oben nie deklariert/initialisiert.
Und das # wird nur in der >M Sektion als letztes gesetzt:
Den Port im Script hast du auf 2200 geändert? res=udp(0 2220)
cpwr=0-sml[4]
Reicht auch ![]()
Update
ZitatIm Prinzip schon aber mit "cpwr=sml[1]-sml[4]" bekomme ich auch Verbrauchswerte. Also + und - Werte.
Ok, stimmt. Da hatte ich nicht ganz nachgedacht ![]()
Ich hab letztens in dem PV Forum ein Extra Thread für die Marstek Shelly Emulation erstellt:
Vielleicht sollte ich hier auch einen extra Thread erstellen oder soll es in dem anderen Forum weiter gehen?
Das Problem hatte ich auch bei mir. Folgendes muss im Script geändert werden, damit es klappt.
Wenn du mein Script verwendest:
Wenn du gemu2015 Script verwendest:
Mhhh ich hab mein Marstek noch nicht installiert. Hatte alles nur so trocken getestet und hatte die Meldung ebenfalls. Aber ich dachte mir das ist normal weil der ich einen Test Lesekopf mit fester Leistung verwendet hatte (SML Simulator Script).
Ich glaube der Akku versucht sich einzuregeln und schaut immer auf die Leistung vom Lesekopf. Der Emulator greift im Script auf die Variable power2 zurück, das ist die Leistung gefiltert. Versuche das mal auf power zu ändern, dann wird die ungefilterte Leistung verwendet. Gemu meinte aber dann könnte der Akku anfangen zu schwingen.
Hast du auf 1Phase in der App gestellt oder 3 Phasen?
Hier ist ein Beispiel mit globalen Variablen: https://tasmota.github.io/docs/Scripting…riables-example
Das Beispiel oben sendet ein ARRAY als globale Variable. Du benötigst ja nur ein Wert. Falls du mein Script verwendest musst du nur eine Variable im Script bei ändern:
Lesekopf:
oder wenn du die gefilterte Leistung global haben willst:
Im Script, das den Heizer steuern soll, muss du die Variable ebenfalls so deklarieren. Glaube ich jedenfalls. Habe mit globalen Variablen noch nicht gearbeitet.
Das wusste ich noch nicht! Danke für die Info.
Update:
Die Simulation klappt auch mit einem B2500 Akku. Der Port muss ggf. Nur im Script geändert werden, je nach Firmwarestand:
Shelly Pro 3EM
Danke für die Info bzgl. ESP8266! Ich habe ein angepasstes Image tasmota1m_shelly_ottelo erstellt und mit deinem Beispielscript getestet. Funktioniert einwandfrei! Natürlich passt mein großes Script mit den Diagrammen nicht mehr hinein.
Downloads via https://github.com/ottelo9/tasmota-sml-images
Ich habe alle anderen Features (Home Assistant API) drin lassen können. Es reichte wirklich nur den Scriptspeicher zu reduzieren #define EEP_SCRIPT_SIZE 4096. Siehe auch user_config_override.h.
Danke für den Hinweis Thomas, werde ich korrigieren. Nun zu deiner Frage: Ich konnte mit dem Image nichtmal Tasmota Scripting aktivieren (leeres Script, nur >D war drin), mein ESP hat sich sofort aufgehängt und nach ein paar Minuten war er wieder da, mit deaktiviertem Script. Ich werde mal alle unnötigen Features rausschmeissen und dann nochmal testen, aber dann fehlt halt z.B Home Assistant. Ich denk mal der kleine ESP hat einfach zu wenig RAM.
Mein Marstek Jupiter C Plus ist heute angekommen. Die App hat den virtuellen Shelly Pro 3EM sofort gefunden und bekommt die Daten :D. Bislang hängt da noch mein SML Simulator (IR-Lesekopf mit SML Simulator Script) dran, der zufällige Leistungswerte an den ESP32-C3 Lesekopf sendet.