Emulation für Growatt NOAH 2000

[Ren108]

Ich habe hier einen Growatt Noah2000 mit dem ich gerne eine Nulleinspeisung vornehmen würde. Also habe ich mir einen Tasmota Lesekopf besorgt, eingerichtet und bekomme meine Werte (siehe pullrequest für den Zähler) Mir war nicht bewusst dass es Diese Leseköpfe mit ESP32 und ESP8266 gibt. Daher bin ich jetzt bei einem ESP 8266 gelandet.

Verhalten mit ECO Tracker Emulation:

• ECO Tracker wird korrekt in der ShinePhone App erkannt
• Kopplung funktioniert
• Smart Mode kann aktiviert werden
• Regelung funktioniert sichtbar (Leistungsanpassung anhand Netzbezug)
• Nach ca. 1–2 Minuten verschwindet der ECO Tracker vollständig aus der App
• Gerät kann danach erneut hinzugefügt werden
• Verhalten ist reproduzierbar (immer gleicher Ablauf)
• Tasmota läuft dabei weiter, Zählerdaten kommen an und die Regel-Logik scheint weiterhin aktiv zu sein.

Verhalten mit Shelly-Emulation:

• Shelly-Emulationsscript auf Tasmota getestet
• Gerät wird in ShinePhone nicht erkannt
• Kein Hinzufügen möglich
• https://github.com/TheRealMoeder/Energy2Shelly_ESP diese Emulation wird allerdings erkannt.

[ottelo9]

Hi. Verhalten mit Shelly Emu ist bekannt. Möglicher Fix wäre evtl. Das hier:

#13

Aber das Shelly Script würde nicht mehr auf dein ESP8266 passen. Also bist du gezwungen EcoTracker zu nehmen. Aber wieso sich das bei dir so komisch verhält.. keine Ahnung. Gibt aber im pv Forum in meinem Thread paar Leute mit diesem Akku. Evtl da mal fragen?

https://www.photovoltaikforum.com/thread/250523-marstek-venus-jupiter-b2500-shelly-pro-3em-emulator-tasmota-lesekopf/?postID=4435927&highlight=Growatt%2BNoah#post4435927

Justin Hahn zb

[Ren108]

Anscheinend brauch der NOAH dauerhaft mDns zur Kommunikation bzw um die Verbindung zu halten. Wenn ichs richtig verstehe ist aktuell nur zum finden der Verbindung mDns aktiv. Ist das richtig?

[ottelo9]

Nein, eigentlich ist ein DNS immer aktiv....

Ich habe mal eben bei mir nachgeschaut. Irgendwann meldet sich der EcoTracker EMU via mDNS nicht mehr in meinem Netzwerk. Komisch...

Update:
Ich logge die serielle Ausgabe mit. Ab und zu macht er ein WiFi SSID rescan und einmal NTP sync. Die Kiste bzw. der Dienst _everhome._tcp.local. und auch _http._tcp.local. ist wie gesagt irgendwann nicht mehr via mdns-browser auffindbar.

Anpingen via ping ecotracker-34b7dad7d28c.local klappt dann nicht mehr. Normal anpingen via ping ecotracker-34b7dad7d28c klappt.

Update2:
Das Problem liegt wohl am Network rescan. Denn genau zu diesem Zeitpunkt war der ping mit .local nicht mehr möglich

13:39:23.947 WIF: Network (re)scan started...
13:39:27.902 WIF: Checking connection...
13:39:27.903 WIF: Network 0, AP1, SSId FRITZ!Box, Channel 1, BSSId xx, RSSI -46, Encryption 1
13:39:27.905 WIF: Network 1, AP-, SSId FRITZ!Box, Channel 1, BSSId xx, RSSI -47, Encryption 1
13:39:27.908 WIF: Network 2, AP-, SSId FRITZ!Box, Channel 1, BSSId xx, RSSI -67, Encryption 1
13:39:29.001 WIF: Connecting to AP1 FRITZ!Box Channel 1 BSSId xx in mode HT40 as tasmota-D7D28C-4748...
13:39:29.091 WIF: IPv4 192.168.178.132, mask 255.255.255.0, gateway 192.168.178.1
13:39:31.447 WIF: IPv6 Local xx
13:39:35.447 WIF: IPv6 Global xx

Update3:
Ich habe schonmal herausgefunden, dass Tasmota im Hintergrund alle 44min einen WiFi Rescan macht. Wenn ein besserer Hotspot in der Nähe ist, dann verbindet er sich dahin. Der mDNS Dienst ist dann nicht mehr erreichbar, d.h. man könnte den Emu nicht mehr finden. Das ist Abschaltbar via SetOption57.

[Ren108]

Ich habe jetzt als Zwischenlösung Energy2Shelly mit dem Noah Fix auf einem separaten ESP32 laufen. Das funktioniert jetzt soweit erstmal. Wäre aber natürlich schon cooler und auch praktikabler für andere wenn die Emulation direkt auf dem Tasmota laufen würde. Ob jetzt Shelly oder Ecotracker :)

[ottelo9]

Welcher Noah Fix ist das ?

[ottelo9]

@Ren108
Ich habe eine neues Tasmota 15.2.0 Testimage für ESP32-C3 gebaut für alle die Probleme mit dem EcoTracker Emulator haben. Via mDNS sollte nun wohl der korrekte Service und Parameter bereit gestellt werden. Zusammen mit meinem EcoTracker Script (via DropDown wählbar) könnte es vielleicht nun funktionieren (hoffen wir es). Gerne mal ausprobieren ob es damit funktioniert.

tasmota32c3_ottelo.zip

[Ren108]

TheRealMoeder/Energy2Shelly_ESP#80

Das meinte ich.

Werde die neue FW heute oder morgen testen.

[ottelo9]

@Ren108 Ah ok, es geht um die Shelly Emulation. Mein Image ist für die EcoTracker Emulation. Habe aber nur ein ESP32-C3 Image, du brauchst ESP8266?

Deren Bugfix ist der gleiche wie hier im PR vorgeschlagen für meine Scripte. Dann werde ich das wohl auch mal versuchen in die Shelly Scripte einzubauen, so klein wie möglich.

[Ren108]

Ich würd ja auch gern den Ecotracker direkt auf meinem ESP8266 verwenden. Also ja ich brauche ein ESP8266 Image.

[ottelo9]

@Ren108
Ich habe in der Tasmota Firma (im Scripter) den mDNS Server für Shelly optimiert und für EcoTracker korrigiert. Die geänderte xdrv_10_scripter.ino‎ habe ich gemu2015 geschickt, er hat sie gestern in seinem Repository eingepflegt.

Testimages:
tasmota1m_shelly_ottelo.bin.zip
tasmota32c3_ottelo.zip

Testscripte:
Ich habe insgesamt 4 Testscripte erstellt, in denen ich den neuen Shelly Endpunkt hinzugefügt habe "Shelly.GetStatus". 2x auf Basis des älteren ESP8266 Scriptes und 2x auf Basis des neuen für ESP32 (mit DropDown Menüs).

1_SML_ShellyEmu_Simple TEST.zip

Basiert auf 1_SML_ShellyEmu_Simple.tas (ESP8266)
1_SML_ShellyEmu_Simple ESP8266 TEST1.tas
1_SML_ShellyEmu_Simple ESP8266 TEST2.tas EM.GetStatus Endpunkt extrem abgespeckt

Basiert auf 1_SML_ShellyEmu_Simple.tas (ESP32)
1_SML_ShellyEmu_Simple ESP32 TEST1.tas
1_SML_ShellyEmu_Simple ESP32 TEST2.tas EM.GetStatus Endpunkt extrem abgespeckt

Wer Lust hat, gerne testen am NOAH 2000, Hoymiles usw. Ich habe das TEST2 Script an meinem Marstek Jupiter C Plus erfolgreich getestet. D.h. der Jupiter braucht nicht ALLE Informationen aus der offiziellen API (siehe JSON UDP Antwort unten).
Achtung. Der Test via Webbrowser IP\rpc\Shelly.GetStatus geht nicht, da ich das nicht eingebaut habe. Das wird meines Erachtens nicht benötigt! Wurde auch erst ab Gen2 eingeführt.

JSON Antwort via UDP Anfrage (Port 1010). UDP Abfragen getestet mit Hercules SETUP utility
Shelly.GetStatus

{
	"id": 0,
	"src": "shellypro3em-34B7DAD7D28C",
	"result": {
		"em:0": {
			"id": 0,
			"a_act_power": -35.0,
			"b_act_power": 0.0,
			"c_act_power": 0.0,
			"total_act_power": -35.0
		},
		"emdata:0": {
			"id": 0,
			"a_total_act_energy": 0,
			"a_total_act_ret_energy": 0,
			"b_total_act_energy": 0,
			"b_total_act_ret_energy": 0,
			"c_total_act_energy": 0,
			"c_total_act_ret_energy": 0,
			"total_act": 0,
			"total_act_ret": 0
		}
	}
}

EM.GetStatus abgespeckte Version TEST2 Script

{
	"id": 0,
	"src": "shellypro3em-34B7DAD7D28C",
	"result": {
		"id": 0,
		"a_act_power": -35.0,
		"b_act_power": 0.0,
		"c_act_power": 0.0,
		"total_act_power": -35.0
	}
}

[ottelo9]

Hier ein weiteres Testscript was auf dem PR #13 basiert. Es ist sehr groß und läuft nicht auf dem kleinen ESP8266 1M, also nur auf dem ESP8266 4M oder ESP32.

7_SML_ShellyEmu_Simple.txt

rpc/Shelly.GetStatus

{
  "id": 0,
  "src": "shellypro3em-34B7DAD7D28C",
  "result": {
    "wifi_sta": {
      "connected": true,
      "ssid": "kabellos",
      "ip": "192.168.178.132",
      "rssi": -40
    },
    "cloud": {
      "enabled": false,
      "connected": false
    },
    "mqtt": {
      "connected": false
    },
    "mac": "34B7DAD7D28C",
    "has_update": false,
    "unixtime": 1772962272,
    "time": "10:31",
    "ram_total": 50648,
    "ram_free": 38376,
    "ram_lwm": 32968,
    "fs_size": 233681,
    "fs_free": 174194,
    "temperature": 28.08,
    "overtemperature": false,
    "tmp": {
      "tC": 28.08,
      "tF": 82.54,
      "is_valid": true
    },
    "fs_mounted": true,
    "total_power": 658.12,
    "em:0": {
      "id": 0,
      "a_current": -117,
      "a_voltage": -117,
      "a_act_power": 658.12,
      "a_aprt_power": 658.12,
      "a_pf": 1,
      "a_freq": -117,
      "b_current": 0,
      "b_voltage": -117,
      "b_act_power": 0,
      "b_aprt_power": 0,
      "b_pf": 1,
      "b_freq": 0,
      "c_current": 0,
      "c_voltage": -117,
      "c_act_power": 0,
      "c_aprt_power": 0,
      "c_pf": 1,
      "c_freq": 0,
      "total_current": -117,
      "total_act_power": 658.12,
      "total_aprt_power": 658.12
    },
    "emdata:0": {
      "id": 0,
      "a_total_act_energy": -117,
      "a_total_act_ret_energy": 26713.01,
      "b_total_act_energy": 0,
      "b_total_act_ret_energy": 0,
      "c_total_act_energy": 0,
      "c_total_act_ret_energy": 0,
      "total_act": -117,
      "total_act_ret": 26713.01
    },
    "modbus": {
      "enabled": false
    },
    "serial": 1,
    "uptime": 6900
  }
}

[Ren108]

ich habe die neue Firmware geflasht und beide Scripte für E8266 nacheinander eingebaut. Leider findet mein NOAH2000 die Shelly EMU immernoch nicht. Muss ich das Script nochmal neu initialisieren? Habe nach dem speichern vom Script neu gestartet.

[ottelo9]

Schade! Nein das Script brauchst du nicht neu initialisieren, neustart reicht. Ein ESP32 zum Testen des 7_SML_ShellyEmu_Simple.txt Scriptes hast du nicht, nehme ich an?

[Ren108]

Ich könnte experimentell einen ESP32 statt den 8266 mit dem Lesekopf verbinden. Im moment fehlt mir aber etwas die Zeit.

Vllt braucht der Noah aber auch

IP\rpc\Shelly.GetStatus?

Der Emulator Energy2Shelly liefert das glaube ich.