Entschuldigung, aber das ist einfach falsch. Ob die WB "enabled" ist hat überhaupt nichts damit zu tun ob sie lädt.

Kein Problem, musst dich nicht entschuldigen!
Der Code stammt ja eh von Dir: #15466
Ich habe hier nur den Variablenbezug geändert.😇

PS: Eigentlich bräuchte man im Code nur noch Register 1000 zum Lesen/Schreiben der Leistung. Könnte man in 1 Variable zusammenführen (elwaRegGetSetPower oder nur elwaRegPower).

Ich habe hier nur den Variablenbezug geändert.

Genau. Geht halt nicht.

Das verstehe ich leider nicht warum der Bezug auf einen anderen (korrekteren) Variablennamen ein Problem sein soll?
Ursprünglich hat man über elwaRegSetPower (1000) geschrieben (...Set...) und über elwaRegPower (1074) die Leistung gelesen.
Das ist aber schon seit einiger Zeit geändert und die Leistung wird auch aus Register 1000 gelesen, daher hat elwaRegPower seitdem auch den Wert 1000.

An dieser Stelle im Code wird aber doch gar nicht geschrieben, sondern die Leistung gelesen, also wäre hier die Verwendung der Variable elwaRegPower korrekter. Auch wenn beide auf Register 1000 verweisen und es eigentlich keinen Unterschied macht.

Nochmal. Ob die Elwa lädt oder nicht (=Power) ist für die Frage ob sie laden darf (=Vorgabeleistung != 0) völlig irrelevant!

Das könnt nur ihr sagen ;). Solange das bei SetPower>0 auf 0-2 geht ja :)

Naja, bei SetPower>0 geht es z.B. nie auf 0, weil der Heizstab ja dadurch einen PV Überschuss mitgeteilt bekommt und in der Regel dann zu heizen beginnt.
Außer er erreicht "seine" Temperaturgrenze, dann geht er auf 3.
Aber er kann auch, bei Unterschreiten der Mindesttemperatur, von sich aus anfangen zu heizen, dann haben wir 2.

Ich habe das mal versucht mit switch-case umzusetzen, aber er heizt jetzt mit Mindestlleistung, auch wenn Mode=Off. Aber ich vermute, wenn er auf PV Überschuss wartet (Wert=0), darf ich nicht wb.enable=true machen, oder?

Die Anforderung ist klar. Wenns die erfüllt dann gehts ;)

Also dann diese Logik:

enabled : true = 1 / 2
enabled : false = 0 / 3 / 4

Erster Test war erfolgreich.
Wenn er jetzt aber selber anfängt zu heizen wegen Sicherstellung Warmwasser, dann wird evcc einen "charger logic error: disabled but charging" Fehler melden. Aber das ist ja vermutlich sogar korrekt und so gewollt.

Edit: Blödsinn von mir! Dann meldet er Status 2 und das ist dann auch enabled=true. Sollte also keinen Fehler melden.

...und bei enabled=off sollte er auch kein WW machen!

Riecht mir zu stark nach weiterhin falschen Verständnis von
a) Freigabe liegt vor - Energiebezug erlaubt,
b) Freigabe liegt nicht vor - eigenmächtiger Energiebezug unter allen Umständen untersagt.

Was sollen offensichtliche Fehlerzustände oder Thermostatabschaltungen damit zu tun haben?

Sorry, aber ich tu mir einfach schwer die Logik dahinter vollständig zu verstehen und auf einen Heizstab zu übertragen. 😟

Ich hatte das jetzt so verstanden, dass eine Freigabe ein von der Wallbox definierter Zustand ist und mit dem Zustand des LP in evcc synchron sein muss. Freigabe heißt, die Wallbox kann, wenn man ihr eine Leistungsvorgabe schickt, laden, weil ein Auto angesteckt ist, eine RFID Karte erkannt wurde usw.
So habe ich das jetzt auf die Heizstab Zustände angewendet und deshalb auch z.B. die 3 (Solltemperatur erreicht) in die Liste aufgenommen. In diesem Zustand kann der Heizstab keine Leistung annehmen (ins Register 1000 kann man schon schreiben, aber da wird nix passieren) und wird auch nicht anfangen zu heizen.

Oder ist das ein von evcc definierter Zustand, ob man einer Wallbox aktuell eine Leistungsvorgabe schicken kann, weil eine Freigabe vorliegt? Und evcc blockiert bzw. gibt die Wallbox entsprechend per Befehl frei.

Der Heizstab kann aber im Gegensatz zu einer Wallbox doch immer Energie beziehen. Ich KANN es ihm auch nicht per Befehl verbieten, soweit ich das weiß! Wenn der Anwender beim Heizstab die WW Sicherstellung aktiviert hat (und das macht Sinn ! Ich nutze das als "Sicherheitsnetz", falls die WP mal ausfällt und das WW zu kalt werden droht), dann wird er auch ohne evcc anfangen zu heizen, wenn die Mindesttemperatur unterschritten ist. Also auch wenn der LP auf Aus steht. Wenn wir durch LP = Aus auch die WW Sicherstellung deaktivieren, werden wir vermutlich einige verängerte Anwender haben, weil das überraschend kommt, dass evcc den Heizstab so tief beherrscht.

PS: Eventuell könnte man dieses Register zur kompletten Deaktivierung des Heizstabs nutzen:

1081 R/W Device state 0 / 1

Das lässt sich lesen, aber auch beschreiben! Laut Doku sollte man da aber nicht mehr als 1x pro Tag schreiben, weil sonst der interne Speicher stärker altert und früher defekt ist.

Und evcc blockiert bzw. gibt die Wallbox entsprechend per Befehl frei.

Richtig. Und nicht anders.

Keine Freigabe heisst keine Freigabe.
Und über Enabled muss evcc lesen können ob der via Enable vorgegebene Freigabezustand vom Gerät verstanden und eingehalten wird.

Neue Erkenntnisse:
Register 1081 kontrolliert den gesamten Heizstab und wäre prinzipiell das was für Enable/Disable gesucht wird! Auf 0 gesetzt ist der Heizstab komplett deaktiviert.

Großer Nachteil: Die vom Heizstab gebotenen Funktionen "WW Sicherstellung / Boost" und "Legionellenschutz" sind damit auch nicht mehr aktiv !!!
Das passt dann zwar zur evcc Vorgabe "keine Freigabe = absolut keine Leistungsaufnahme", aber damit unterbindet evcc eventuell kritische Dinge wie "alle 3 Tage um 12h auf 70°C heizen, um gefährliche Legionellenbildung zu vermeiden".
Diese Freiheit sollte der MyPV Heizstab haben, zeit- bzw. temperaturabhängig selbst anfangen zu heizen, auch wenn der LP in evcc gerade auf "Aus" steht oder anderweitig keine Freigabe hat.
Wenn wir das so strikt wie gefordert implementieren, werden wir Ärger mit Anwendern bekommen, weil evcc wichtige Funktionen deaktiviert hat. Das würde ich nicht vorschlagen, es so zu tun.

Bleiben wir also beim Status und so wie @premultiply vorgeschlagen hat, beachten wir nur die Werte 1/2 und 0, von denen wir sicher wissen, was sie für den Freigabezustand bedeuten. Beim Rest geben wir den gemerkten Zustand zurück.