TP Link Wlan Steckdosen einbinden?

[afuxi]

Go-e Charger lädt prima, Danke an Euch alle und vor allem an Andreas.

Als totaler Amateur eine Frage an Euch.
Da nun trotzdem noch reichlich PV - Strom übrig ist, würde ich gern auch noch diverse Verbraucher bei Überschuss dazuschalten. Toll wäre es, wenn ich meine TP Link WLan-Steckdosen schalten könnte. Damit bestünde die Möglichkeit Geräte/Verbraucher bis zu 16 A, wie Wärmepumpe, Heizstab im Pufferspeicher, Warmwasserbereiter, Waschmaschine, Klimaanlage etc. zu schalten.
Das würde den Nutzen von EVCC noch einmal gewaltig erhöhen.
Wenn mir dann noch Jemand erklärt, wie so ein Text so bleibt, wie man ihn geschrieben hat.....

[premultiply]

EVCC beschränkt sich ganz bewusst ausschließlich auf das Laden von Elektrofahrzeugen um einen beherrschbaren Funktionsumfang möglichst gut abzudecken. Das ist schon anspruchsvoll genug. Und ja, auch wenn andere das so machen, hier soll bewusst keine eierlegende Wollmilchsau geschaffen werden.
Die Gefahr dass das Projekt sonst wie andere Projekte ausufert und (noch) komplizierter zu konfigurieren oder zu bedienen ist ist sonst zu groß.

Die sonstigen Verbrauchen lassen sich bei einer SMA-Anlage z. B. mittels der Software Smart Appliance Enabler (SAE) in das integrierte Energiemanagment einbinden und dann damit auf die gewünschte Art und Weise steuern.
Für andere Fabrikate muss man ggf. eigene Lösungen mit Heimautomationslösungen o. ä. schaffen.
Die Möglichkeiten sind vielfältig.

[thierolm]

Welche TP-Link Steckdosen (Konkreter Typ) hast du denn im Einsatz? Evcc unterstützt aktuell zwei einfache "Pseudo" charger (FritzDect + Tasmota), welche allerdings mit Focus auf die Beladung von zusätzlichen EVs, wie Elektro Motorrädern und E-Scootern aufgesetzt wurden.

[andig]

@premultiply das schöne ist ja dass die Steckdosen perfekt und ohne Aufwand ins Konzept passen- ich hätte nix dagegen, weitere zu unterstützen.

[premultiply]

Mir ging es dabei nicht um die Steckdosen-Modelle als solche sondern die Verbraucher die dran hängen.
EVCC sollte sich funktionell klar auf das ordentliche Laden von E-Fahrzeugen beschränken und nicht auch noch den Anspruch haben plötzlich Warmwasser zu bereiten, zu waschen, kochen und spülen und die Anwesenheit und Gesundheitszustand der Hauskatze zu überwachen sowie bei der Gelegenheit an die nächste Sperrmüllabfuhr zu erinnern.

[Alestrix]

Mir ging es dabei nicht um die Steckdosen-Modelle als solche sondern die Verbraucher die dran hängen.
EVCC sollte sich funktionell klar auf das ordentliche Laden von E-Fahrzeugen beschränken

Mit der Steckdose soll natürlich das Ladegerät des E-Bikes geschaltet werden - damit passt es wieder komplett ins Konzept!

[afuxi]

Die TP-Link Steckdose, die jetzt übrig ist, hat im Winter über Awattar hourly in den kostengünstigen Zeiten das Auto geladen. Ist wegen des neuen Go-e jetzt aber frei, der das automatisch kann.

[afuxi]

Ich habe und nutze folgende TP Link Wlan Steckdosen, die da wären HS100, HS110, mit Messfunktion und KP105P2. Genutzt werden die Steckdosen per Alexa, Alexa App und der zugehörigen Kasa App. Man kann Verbraucher bis zu 16 A schalten. Siehe auch: https://www.amazon.de/dp/B06W586CDZ/ref=cm_sw_em_r_mt_dp_Y40NXQXSSS1BHY65RCVW

[thierolm]

Sinn würde nur die Dose mit mit Messfunktion haben, wäre das die HS150? Die habe ich auf Amazon nicht gefunden.
Die HS100 und KP105P2 können soweit ich das gesehen habe "nur" schalten.
Kannst du mir einen Link zur Dose mit Messfunktion schicken? Würde mir dann evtl. eine zur Entwicklung eines evcc "pseudo" Chargers anschaffen ...

[afuxi]

Sorry, HS110, hab ich später korrigiert.

[thierolm]

OK, dann bestell ich mir mal eine und schaue ob die Web API nutzbar ist.
Ich halte dich über den Fortschritt am laufen (mach das aber nicht Hauptberuflich ... just to manage expectations!)
Lass bitte die Diskussion solange offen.

Ich hoffe das @premultiply mit dem Focus auf EV charging auch damit OK ist.

Eine "eierlegende Homeautomation" Lösung soll und darf evcc definitiv nicht werden.

[thierolm]

Mein goe-Charger und meine Tasmota Sonoff POW R2 Steckdose vertragen sich prima via evcc in meiner Garage und laden ordentlich meinen Zoe und die Zero S :-)

[afuxi]

Das ist fein. Bin gespannt und sehr geduldig. Keine eiermilchlegende, aber eine Variante, um das Auto auch einfach mit einem Ziegel zu laden. Kann Dir auch meine HS110 schicken. Brauche ich eigentlich nicht mehr, weil evcc funzt.

[thierolm]

Das mit dem schicken wäre cool. Ich bin bei mir nämlich komplett auf FritzDECT was Steckdosen angeht ... Du müsstest sie halt nur auf den Werkszustand zurücksetzen.
Ich schicke sie dir dann einfach nach getaner Arbeit zurück. OK?

[afuxi]

Gern und wohin?

[thierolm]

...

[afuxi]

Ok, melde mich wenn sie unterwegs ist. Wird wahrscheinlich erst nächste Woche.

[thierolm]

Top, no prob! :-)

[afuxi]

HS110 wurde heute verschickt. Die wurde bisher wirklich ausschließlich zum Auto laden verwendet. Aber im Winter um über Awattar hourly nachts in der kostengünstigsten Zeit zu laden. Macht jetzt der Go-e prima.

[thierolm]

Alles klar, ich geb' bescheid, wenn sie da ist.

[Alestrix]

Ich habe auch so eine TP-Link Steckdose hier am Laufen und schalte/lese sie über das Skript von
https://github.com/ggeorgovassilis/linuxscripts/tree/master/tp-link-hs100-smartplug
Evtl. hilft das ja?

[thierolm]

Thx, ich lese mich langsam schon etwas warm ... :-) Die Dosen haben da ja einen wilden Crypting-Approach gewählt.
Funktioniert das Skript einfach, in dem du die IP-Adresse und den Port der Dose angibst?
Würde heissen, dass die kodierten "payloads" im Script für alle Dosen gelten?

[Alestrix]

Jep, funktionier bei mir out-of-the-box. Habe es auf meinem MIPS Router abgelegt (EdgeRouter-X), der läuft immer, somit kann ich die Steckdose von dort immer schalten und auslesen.

[thierolm]

Na dann sollte es mit der evcc Einbindung flott gehen. :-)

[thierolm]

@Alestrix hattest du das python Script von https://github.com/softScheck/tplink-smartplug mal probiert?

Die Infos auf https://www.softscheck.com/en/reverse-engineering-tp-link-hs110/ und die Command Summary auf https://github.com/softScheck/tplink-smartplug/blob/master/tplink-smarthome-commands.txt lesen sich auch super interresant ... :-)

Ich werde auf Basis der Infos mal die proprietären TP-Link crypt und decrypt Funktionen mit go bauen.

[Alestrix]

@thierolm Nope, ich hatte mich vor ein paar Jahren darüber gefreut, dass es klappt, und danach nicht weitergesucht.

Wollte es jetzt auch mal in EVCC einbauen mit

- name: tplinkmeter
  type: default
  power:
    type: script
    cmd: /bin/sh -c "/opt/scripts/tplink.sh 192.168.4.50 9999 emeter | /bin/sed -ne 's/^.*power.:\([0-9.]*\),.*$/\1/p'"

aber scheinbar gibt's im evcc Docker container kein sed (und auch kein jq) 😞 und auch jq: innerhalb eines type: script blocks wird von EVCC leider nicht verstanden...

[thierolm]

Moin, die HS110 ist gestern bei mir angekommen. @afuxi Thx! :-)
Ich habe mir mal das tplink-smartplug git Projekt gecloned und die für evcc relevanten commands gegen die Steckdose verprobt, auch die Strommessung beim Laden meines Handys (siehe log unten). ==> Läuft! :-)
Werde mich als erstes an die Portierung der tplink-smartplug encrypt und decrypt Funktionen nach go machen, da ich die TP Link Commands im zukünftigen evcc Pseudo-Charger Modul im Klartext definieren will und nicht kryptisch ...
Ich halte euch über meine Fortschritte auf dem Laufenden.

xxx@xxx:~/evcc/git/tplink-smartplug$ ./tplink_smartplug.py -t 192.10.0.2 -c info
Sent:      {"system":{"get_sysinfo":{}}}
Received:  {"system":{"get_sysinfo":{"err_code":0,"sw_ver":"1.2.6 Build 200727 Rel.120821","hw_ver":"1.0","type":"IOT.SMARTPLUGSWITCH","model":"HS110(EU)","mac":"50:C7:BF:42:60:9B","deviceId":"80068B6B73AAD8C4A4D0F7B9AB5F8B1B1838EEAC","hwId":"45E29DA8382494D2E82688B52A0B2EB5","fwId":"00000000000000000000000000000000","oemId":"3D341ECE302C0642C99E31CE2430544B","alias":"evcc-charger","dev_name":"Wi-Fi Smart Plug With Energy Monitoring","icon_hash":"","relay_state":1,"on_time":1122,"active_mode":"schedule","feature":"TIM:ENE","updating":0,"rssi":-54,"led_off":0,"latitude":49.817090,"longitude":9.056194}}}
xxx@xxx:~/evcc/git/tplink-smartplug$ ./tplink_smartplug.py -t 192.10.0.2 -c on
Sent:      {"system":{"set_relay_state":{"state":1}}}
Received:  {"system":{"set_relay_state":{"err_code":0}}}
xxx@xxx:~/evcc/git/tplink-smartplug$ ./tplink_smartplug.py -t 192.10.0.2 -c off
Sent:      {"system":{"set_relay_state":{"state":0}}}
Received:  {"system":{"set_relay_state":{"err_code":0}}}
xxx@xxx:~/evcc/git/tplink-smartplug$ ./tplink_smartplug.py -t 192.10.0.2 -c energy
Sent:      {"emeter":{"get_realtime":{}}}
Received:  {"emeter":{"get_realtime":{"current":0.016382,"voltage":235.595586,"power":0,"total":0,"err_code":0}}}
xxx@xxx:~/evcc/git/tplink-smartplug$ ./tplink_smartplug.py -t 192.10.0.2 -c on
Sent:      {"system":{"set_relay_state":{"state":1}}}
Received:  {"system":{"set_relay_state":{"err_code":0}}}
xxx@xxx:~/evcc/git/tplink-smartplug$ ./tplink_smartplug.py -t 192.10.0.2 -c energy
Sent:      {"emeter":{"get_realtime":{}}}
Received:  {"emeter":{"get_realtime":{"current":0.078473,"voltage":236.848969,"power":8.845580,"total":0,"err_code":0}}}

[Alestrix]

Vielleicht kannst Du ja neben MQTT, Skript, http noch einen tp-link Protokollhandler bauen, dann könnten die Bastler unter uns direkt mit den JSON Strings arbeiten. 😄

[andig]

ihr könnt das ja einfach als shell plugin mit jq einbinden- da wär ja schon alles da ;)

[andig]

Siehe #883

[Alestrix]

aber natürlich müsste dafür python in den container, jq ist das kleinste problem

@thierolm wollte es meines Wissens in Go nachimplementieren, dann brauchen wir auch kein Python mehr.

[thierolm]

@thierolm wollte es meines Wissens in Go nachimplementieren, dann brauchen wir auch kein Python mehr.

So sieht es aus :-)
Kann in go schon encoden, decoden und testweise schalten. :-)

Was noch "unelegant" ist, ist die "BigEndian Unsigned Integer" Packetierung des verschlüsselten Command JSON's.
@andig hast du eine Quelle/Idee für die Umsetzung in go.
In Phyton gibt es da die struct.pack Funktion. Für die TPLink Commands Message wird es wie folgt im tplink_smartplug.py Script definiert:
result = pack(">I", len(string)).
Dabei steht > für BigEndian und I für unsigned integer.

Ich habe dazu im Netz nichts brauchbares oder für mich verständliches für GO gefunden. :-(

Für meine erste charger Version, werde ich die 4 hex codes (siehe im log dump) manuell an den Anfang des encodeten Command []byte Arrays tackern ....

    /home/thierolm/evcc/git/evcc/internal/charger/tplink_test.go:22:
00 00 00 00 d0 f2 81 f8 8b ff 9a f7 d5 ef 94 b6 c5 a0 d4 8b f9 9c f0 91 e8 b7 c4 b0 d1 a5 c0 e2 d8 a3 81 f2 86 e7 93 f6 d4 ee de a3 de a3
    /home/thierolm/evcc/git/evcc/internal/charger/tplink_test.go:38: 
         00000000  00 00 00 2d d0 f2 81 f8  8b ff 9a f7 d5 ef 94 b6  |...-............|
        00000010  c5 a0 d4 8b f9 9c f0 91  e8 b7 c4 b0 d1 a5 c0 e2  |................|
        00000020  d8 a3 81 e4 96 e4 bb d8  b7 d3 b6 94 ae 9e e3 9e  |................|
        00000030  e3                                                |.|
    /home/thierolm/evcc/git/evcc/internal/charger/tplink_test.go:50: 
         00000000  7b 22 73 79 73 74 65 6d  22 3a 7b 22 73 65 74 5f  |{"system":{"set_|
        00000010  72 65 6c 61 79 5f 73 74  61 74 65 22 3a 7b 22 65  |relay_state":{"e|
        00000020  72 72 5f 63 6f 64 65 22  3a 30 7d 7d 7d           |rr_code":0}}}|

[Alestrix]

Siehe #883

Habe mich heute zum ersten Mal mit VSCode und mit Go beschäftigt, die Anpassung für den Script Provider ist trotzdem schon mal erledigt. Kämpfe aber noch damit, dass ich nicht weiß, wie ich in VSCode mit Git umgehen muss. Ist ein "Stash" sowas wie ein Commit?

[Alestrix]

#894
Ich verzweifle noch mit den Git Fähigkeiten von VSCode. Habe am Ende den Code aus VSCode in die Zwischenablage kopiert und in der GitHub Webseite eingefügt.

[andig]

Meinst Du https://golang.org/pkg/encoding/binary/ oder https://github.com/lunixbochs/struc?

[thierolm]

Ja, die hatte ich mir angeschaut, aber damit nicht den Hexheader erzeugen können wie in der Phyton Vorlage. :-(

Ich habe allerdings festgestellt, dass ein fixer header mit 4 null Bytes für alle von uns benötigten Commands ausreicht und damit das tplink.go Modul heute umgesetzt und erfolgreich getestet. :-)

Ich werde heute Abend/Nacht den entsprechenden PR vorbereiten, muss jetzt erst mal der Chefin und den Kids helfen, sonst wird es ungemütlich ;-)

xxx@xxx:~/evcc/git/evcc$ ./evcc -c evcc_tplink.yaml charger -l debug
[main  ] INFO 2021/04/18 14:16:33 evcc 0.52 (995a1bb)
[main  ] INFO 2021/04/18 14:16:33 using config file evcc_tplink.yaml
Power:         0W
Charge status: B
Enabled:       false
xxx@xxx:~/evcc/git/evcc$ ./evcc -c evcc_tplink.yaml charger -l debug
[main  ] INFO 2021/04/18 14:17:01 evcc 0.52 (995a1bb)
[main  ] INFO 2021/04/18 14:17:01 using config file evcc_tplink.yaml
Power:         0W
Charge status: B
Enabled:       true
xxx@xxx:~/evcc/git/evcc$ ./evcc -c evcc_tplink.yaml charger -l debug
[main  ] INFO 2021/04/18 14:17:25 evcc 0.52 (995a1bb)
[main  ] INFO 2021/04/18 14:17:25 using config file evcc_tplink.yaml
Power:         5W
Charge status: C
Enabled:       true
xxx@xxx:~/evcc/git/evcc$ ./evcc -c evcc_tplink.yaml charger -l debug
[main  ] INFO 2021/04/18 14:17:36 evcc 0.52 (995a1bb)
[main  ] INFO 2021/04/18 14:17:36 using config file evcc_tplink.yaml
Power:         0W
Charge status: B
Enabled:       true

[thierolm]

PR ist erstellt: #891

[afuxi]

@thierolm, Du kannst die Steckdose gern so lange behalten, wie Du sie noch brauchst.
Erstmal Glückwunsch, es funktioniert ja wohl. Ich habe mit Interesse Eure Dialoge gelesen und kein Wort verstanden...... Meine Studien im Fach „Rechentechnik“ und meine Programmierversuche in „Basic“ sind schon eine Weile her. :)
Nun habe ich eine Menge Amateurfragen, wie ich Deine Arbeit für mich nutzbar machen kann und ob Du mir vielleicht dabei hilfst. Ich glaube, das gehört nicht hier ins Forum; können wir dazu mal telefonieren?

[mark-sch]

Die von dir angeregte ChargedEnergy Funktion könnte doch dann immer den im E-Meter der Steckdose auflaufenden Tages-erngy-Wert des aktuellen Tages liefern ...

@andig Was hältst du von der Idee oben?

Mir ist aktuell nicht mehr so ganz klar, was die ChargedEnergy Funktion als float64 Ergebnis inhaltlich liefern soll:

1. Die seit dem letzten evcc Restart aufgelaufene geladene Energie
2. Die seit dem letzten Vehicle connect aufgelaufene geladene Energie
3. Die im Charger mitgeschriebene Energie des aktuellen/laufenden Tages (Daily Total)
4. Die im Charger mitgeschriebene Energie der aktuellen Woche .
5. Die im Charger mitgeschriebene Energie der aktuellen Monats.
6. Die im Charger mitgeschriebene Energieseit Anfang der Charge Zeit :-)

Für die Definition Nr 3. könnten wir dann die das {"emeter":{"get_daystat":{"day":22,"month":4,"year":2021}}} Command nutzen.

Nr. 1 + 2 oben macht doch evcc doch per default, ohne das im Charger Modul eine ChargedEnergy Funktion definiert sein muss.

Die Berechnung von 2) ist chick, nur in meinen Augen ohne StatusA nicht realisierbar. Man könnte mit Chargepower > 0 und == 0 eine Logik bauen, nur ist leider während eines Ladevorgangs auch mehrfach eine Ladeunterbrechung möglich.

[thierolm]

Mein Vorschlag wäre für den TP-Link charger einfach den von der Steckdose über get_daystat gelieferten aktuellen Tages-energy Wert zu liefern.
Da in der aktuellen charger Version das "Anstecken" über den Status Wechsel A=>B nicht erkannt werden kann, bekämen wir dann zumindest immer den originären von der Dose mitgeschnittenen Tages-Wert.
Das entspräche dann der Definition 3 oben.

Finde ich besser im Vergleich zu aufsummiertem Power oder Total Delta , wie es der ChargeRater liefert.

Regel:
Original Meter Statistikwerte der Steckdose vor abgeleiteten/berechneten Werten des ChargeRaters.

Eigentlich müsste das Ergebnis ja immer das Gleiche sein. :-)

Was meint ihr?

[Alestrix]

Was ist am Delta denn so schlecht? Beim daystat wird's schwierig, wenn man mal über Nacht was laden möchte.

[thierolm]

wenn man mal über Nacht was laden möchte.

Mein Ubuntu Server startet alle System Services einmal morgens um 3h durch ... Dann "vergisst" evcc den Total Wert vor dem Restart ...

[andig]

Ich fände die Idee gar nicht schlecht, einer eingeschalteten Steckdose eine Leistung zuzuordnen falls diese nicht selbst messen kann. Ein Case wären z.B. Heizstäbe deren Leistung sehr gut bekannt ist. Könnte ich mir daher als (optionale) Konfigurationseinstellung gut vorstellen. Ich komme langsam ins Nachdenken, ob/wie das in der internen Struktur noch klarer abbildbar wäre.

[Alestrix]

Ich denke auch, der Ladeziegel an der schaltbaren Steckdose dürfte keine Seltenheit sein. Zwischen 20 und 80 Prozent sollte der Ladestrom ja in etwa das sein, was am Ziegel eingestellt ist.

[thierolm]

Ohne Power-Meter und fest konfiguriertem Ladestrom, ist dann auch die Status Vergabe fix:

Steckdose an - enabled: Status C
Steckdose aus - !enabled: Status B

[Alestrix]

Eigentlich müsste es ja jetzt schon mit Bordmitteln umsetzbar sein.
Mal frei Schnauze ohne Test:

    meters:
    - name: brickmeter
      type: default
        power:
          type: js
          script: |
            2300;
    chargers:
    - name: tasmota_nometer
      type: default
        enabled:
          type: http
          url: http://ip/cm?cmnd=status
          jq: .Status.Power
        enable:
          type: http
          url: http://ip/cm?cmnd=power%20${enable:%b}
        maxcurrent:
          type: js
          script: console.log(maxcurrent);
        status:
          type: combined
          plugged:
            type: js
            script: |
              1;
          charging:
            type: http
            url: http://ip/cm?cmnd=status
            jq: .Status.Power

Und dann beides in einem loadpoint vereinen.

[Alestrix]

Bin gespannt - mein EV wird wohl noch vor der Wallbox hier sein, daher werde ich erst mal mit schaltbarer Steckdose und Ladeziegel probieren.

[thierolm]

Cool ich wollte dann auch noch beim Tasmota charger die ChargedEnergy Funktion aus dem mitgeschnittenen Tages-Ernergie Verbrauch (Today) einbauen. Dann würden TP-Link und Tasmota charger Feature mäßig gleich laufen.

{"StatusSNS":{"Time":"2021-04-27T08:18:08","ENERGY":{"TotalStartTime":"2021-03-30T16:22:05","Total":7.312,"Yesterday":0.425,"Today":0.000,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}}

[mark-sch]

Die get_daystat Funktion der HS110 ist prima, somit überlebt der aktuelle Tagesverbrauch auch einen evcc restart:

Sent: {"emeter":{"get_daystat":{"day":23,"month":4,"year":2021}}}
Received: {"emeter":{"get_daystat":{"day_list":[{"year":2021,"month":4,"day":18,"energy_wh":3},{"year":2021,"month":4,"day":19,"energy_wh":0},{"year":2021,"month":4,"day":20,"energy_wh":2029},{"year":2021,"month":4,"day":21,"energy_wh":1201},{"year":2021,"month":4,"day":22,"energy_wh":0},{"year":2021,"month":4,"day":23,"energy_wh":0}],"err_code":0}}}

[thierolm]

@mark-sch Du wieder mit deiner aktuelleren SW Version: enregy _wh :-)

[andig]

Tip: welche Version es ist über pointer in der Struct erkennen. Oder einfach den Wert nehmen der nicht dem Zero Value entspricht (also in dem Fall != 0 ist).

[thierolm]

Guter Tip, werde auch die power Logik auf einen pointer in der struct umstellen.

Würde das zusammen mit der Einführung der ChargedEnergy function machen, wenn wir uns hier auf einen Ansatz geeinigt haben.

[thierolm]

@mark-sch Kannst du bitte bei Gelegenheit PR #932 testen?

[afuxi]

@thierolm hallo Markus, lt. Andreas hast Du es geschafft, die Steckdosen einzubinden. Ich würde gern meine Steckdose nutzen, um einen Heizstab (10 oder 16A) in meinem 600l Pufferspeicher bei PV Überschuss zu schalten. Allerdings mit geringer Priorität, also immer erst, wenn 1. das Auto und 2. der Hausspeicher voll sind.
Geht das? Und wenn ja, könntest Du mir das bitte auf meinem Raspi mit SSH Zugang installieren? Andreas hat mir gerade das aktuelle evcc aufgespielt.
Du erreichst mich auch unter XXX.

[andig]

Allerdings mit geringer Priorität, also immer erst, wenn 1. das Auto und 2. der Hausspeicher voll sind.

Prioritätssteuerung fehlt uns leider noch- daran kann Markus erstmal nichts machen :(