Neues Modul - 70_KEBA.pm zur Steuerung Keba KeContect P20

Begonnen von marcus42, 29 November 2015, 12:38:12

Vorheriges Thema - Nächstes Thema

hasenhirn

Vielleicht kannst Du das als Inspiration oder so gebrauchen  ;)

defmod n_Ladeleistung notify Ladeleistung:LL:.* set KEBA current $EVTPART1;; get KEBA update
attr n_Ladeleistung userReadings Ladeleistung {ReadingsVal("Ladeleistung","LL", 0)}

setstate n_Ladeleistung 2020-04-29 11:14:43
setstate n_Ladeleistung 2020-04-25 06:25:53 Ladelei 7000
setstate n_Ladeleistung 2020-04-25 06:25:53 state active


defmod Ladeleistung dummy
attr Ladeleistung group KEBA
attr Ladeleistung room Wallbox
attr Ladeleistung setList state:6,7,8,9,10,11,12,13,14,15,16
attr Ladeleistung sortby 03
attr Ladeleistung stateFormat state A
attr Ladeleistung userReadings LL {ReadingsVal("Ladeleistung","state",0) *1000}
attr Ladeleistung webCmd state

setstate Ladeleistung 7 A
setstate Ladeleistung 2020-04-29 11:14:43 LL 7000
setstate Ladeleistung 2020-04-29 11:14:43 state 7


"plugged_on_wallbox_and_locked" habe ich im Modul angepasst da "plugged on wallbox and locked" durch die Leerzeichen Stress gemacht hat ( die anderen Meldungen natürlich ebenso ).
Ich habe jetzt aber gar nicht mehr überprüft ob es so auch geht  ???

defmod n_Verbindungsstatus notify KEBA:Enablesys:.*|KEBA:Plug:.* {if (ReadingsVal("KEBA","Plug","") eq "plugged_on_wallbox_and_locked") {fhem ("set Verbindungsstatus 0")} elsif (ReadingsVal("KEBA","Plug","") eq "plugged_on_wallbox_ev_and_locked" && ReadingsVal("KEBA","Enablesys","") eq "disabled" ) {fhem ("set Verbindungsstatus 1")} elsif (ReadingsVal("KEBA","Plug","") eq "plugged_on_wallbox_ev_and_locked" && ReadingsVal("KEBA","Enablesys","") eq "enabled" ) {fhem ("set Verbindungsstatus 2")}}

setstate n_Verbindungsstatus 2020-04-29 11:14:43
setstate n_Verbindungsstatus 2020-04-10 00:37:08 state active



defmod Verbindungsstatus dummy
attr Verbindungsstatus devStateIcon 0:Typ_2_Stecker@red 1:Typ_2_Stecker@blue 2:Typ_2_Stecker@green
attr Verbindungsstatus group KEBA
attr Verbindungsstatus room Wallbox
attr Verbindungsstatus sortby 01
attr Verbindungsstatus userReadings ReadingsVal("KEBA","state","")
attr Verbindungsstatus webCmd :

setstate Verbindungsstatus 0
setstate Verbindungsstatus 2020-04-29 11:14:43 state 0


Gruß

Thomas

glitschi

Hallo zusammen,

Zuerst einmal besten Dank für das Modul, genau das was ich gesucht habe  :)

Leider habe ich jedoch ein Problem wenn zwei Wallboxen definiert sind.

define Wallbox_Garage KEBA 172.16.9.21 7090 180
setuuid Wallbox_Garage 5eb54895-f33f-21ca-e4ea-xxxx
attr Wallbox_Garage DbLogExclude A.*,B.*,DIP.*,F.*,I.*,P,PF,Product,Serial,Sec,T.*,U.*
attr Wallbox_Garage event-on-change-reading .*
attr Wallbox_Garage room Wallbox

define Wallbox_Aussen KEBA 172.16.9.22 7090 200
setuuid Wallbox_Aussen 5ebd6b3f-f33f-21ca-fe96-xxxx
attr Wallbox_Aussen DbLogExclude A.*,B.*,DIP.*,F.*,I.*,P,PF,Product,Serial,Sec,T.*,U.*
attr Wallbox_Aussen event-on-change-reading .*
attr Wallbox_Aussen room Wallbox

Wenn beide definiert sind, auf einer ein update ausgeführt wird, beendet sich FHEM.
(FHEM beendet sich auch, nach dem Automatischen refresh Intervall)

Jede für sich ist kein Problem, funktioniert ohne Probleme, nur zusammen definiert geht nicht.

Letzer Eintrag im fhemlog
2020.05.14 18:18:37 3: Wallbox_Aussen Sending command: report 1
Can't use an undefined value as a symbol reference at ./FHEM/70_KEBA.pm line 194.

Hat jemand eine Idee was ich versuchen könnte?

Gruss Romano


heiko73

Hi!

Ich bin dabei, mir zwei KEBA P30 Wallboxen an die Wand zu schrauben und war begeistert, zu sehen dass es bereits eine FHEM Anbindung gibt. Leider ist das Thema hier seit ein paar Monaten inaktiv, könnte mir jemand ein Update geben, ob an dem Modul noch aktiv gearbeitet wird?

Danke und viele Grüße,
  Heiko

hasenhirn

Moin Heiko,

die letzte Änderung im Git Repo ist 9 Monate alt wenn ich es richtig gesehen habe.
Ich habe mir das Modul wie oben beschrieben etwas angepasst.
Im Moment bin ich auch am überlegen mir noch eine 2te Box zu zulegen.
Mit der Integration in FHEM bin ich eigentlich zufrieden und es läuft sehr stabil.

Gruß
Thomas

hasenhirn

@glitschi

Hallo Romano,

ich habe deinen Beitrag gerade erst gelesen ( die Benachrichtigung hatte ich wohl übersehen )
Bist du schon weiter gekommen? Ich bin am überlegen mir auch eine 2te Keba zu gönnen  :D

Gruß

Thomas

heiko73

 
Zitat von: hasenhirn am 24 November 2020, 05:48:19
Moin Heiko,

die letzte Änderung im Git Repo ist 9 Monate alt wenn ich es richtig gesehen habe.
Ich habe mir das Modul wie oben beschrieben etwas angepasst.
Im Moment bin ich auch am überlegen mir noch eine 2te Box zu zulegen.
Mit der Integration in FHEM bin ich eigentlich zufrieden und es läuft sehr stabil.

Gruß
Thomas

Super, werde dann berichten wenn ich die Boxen habe und erste Versuche starte, sie einzubinden!

Viele Grüße,
Heiko,

hasenhirn

Na da bin ich mal gespannt  :)
Sind die Boxen schon bestellt?
Ich bin auch gerade am über legen mir eine 2te zu kaufen da meine Frau im Februar ihren i3 bekommt und der X3 verkauft wird.
Auf der anderen Seite sollte eine Wallbox eigentlich reichen da das Model3 LR ja nicht so oft geladen werden muss  ::)
Bin mal gespannt wie es bei dir läuft. Ich habe ja noch etwas Zeit.

Gruß

Thomas

heiko73

Boxen sind (noch) nicht bestellt, habe gerade eben erst den Antrag auf Förderung bei der KfW gestellt und muss jetzt warten, bis ich die Förderzusage habe. Da die Jungs bei der KfW heute etwas überlastet sind (Förderung von Wallboxen für Privatpersonen ist heute gestartet worden), kann das sicher noch ein paar Tage dauern ;-) ..

Falls Du sowieso planst, eine zusätzliche WB zu installlieren, ist jetzt die Zeit! Es gibt ein paar Sachen zu beachten (nicht alle WB sind erlaubt, nur am Erstwohnsitz, nur für Privat, WB muss per Konfiguration auf 11kW gedrosselt sein falls sie mehr kann), aber dann sind 900 Euro / Ladepunkt ganz nett!

Der Link für mehr Infos: 8)
https://www.kfw.de/inlandsfoerderung/Privatpersonen/Bestehende-Immobilie/Zuschussportal/Online-Antrag-Ladestationen-f%C3%BCr-Elektroautos/

Viele Grüße,
    Heiko

heiko73

OK, nach langer Wartezeit sind die beiden Boxen jetzt am Start. Eine x-series als Master, eine c-series als Slave.

Leider habe ich das gleiche Problem wie glitschi, wenn ich die zweite Box definiere, dann beendet sich FHEM...

Wenn ich Perl könnte, würde ich mich darum kümmern ... Gibt es eigentlich irgendwo eine aktuellere Version? Bin gar nicht sicher, wo ich meine herhabe (wahrscheinlich von github), aber es hat ja anscheinend schon ein paar Fixes/Erweiterungen gegeben?

Viele Grüße,
  Heiko

heiko73

OK, habe mich doch mal ein wenig mit Perl auseinandergesetzt und gesehen, dass beim Define der 2. Wallbox ein "socket not created" kam. Sobald er dann das erste Mal mit der Wallbox kommunizieren wollte, steigt FHEM wegen dem oben genannten Fehler aus.

Ich habe dann gesehen, dass der Socket für jede Wallbox gleich aufgesetzt wird und dass als Port immer der Port verwendet wird, der im Define angegeben wurde (bei mir 7090). Allerdings wird beim Erstellen des Socket der Quellport angegeben, so dass hier versucht wurde, die Kommunikation der 2. Wallbox mit dem gleichen Quellport aufzusetzen wie bei der 1. Wallbox. Daher kann der UDP Socket nicht aufgesetzt werden.

Es gibt hier also mindestens zwei Probleme:
a) es wird versucht, den UDP Socket wird bei jeder Wallbox mit dem gleichen Quellport zu erzeugen. Da jeder Port nur einmal verwendet werden kann, schlägt das bei der 2. Wallbox fehl
b) es wird anscheinend nicht geprüft, ob eine Wallbox korrekt angelegt werden konnte und wenn dann versucht wird, über den nicht vorhandenen socket zu senden, crasht FHEM

Ich konnte a) immerhin dadurch beheben, dass ich in der Zeile 139 den Code von

my $socket = IO::Socket::INET->new(Proto => 'udp', Localport => $port);


auf


my $socket = IO::Socket::INET->new(Proto => 'udp', ReusePort = 1, Localport => $port);



geändert habe. Jetzt crasht FHEM nicht mehr beim Versuch, auf die 2. Wallbox zuzugreifen und ich bekomme auch Werte angezeigt.

Schonmal gut, aber b) ist noch nicht gelöst und ob mein "Fix" auch zuverlässig funktioniert, weiß ich nicht. Die Kommunikation ist asynchron und ich kann mit meinen bescheidenen Kenntnissen nicht sehen, was die Read Routine antriggert und wie sie z.B. erkennt, von welcher wallbox die Daten gerade sind.

Da muss noch einiges an Arbeit reingesteckt werden, damit das robust funktioniert.

rudolfkoenig

#70
Zitatob mein "Fix" auch zuverlässig funktioniert, weiß ich nicht.
Wenn ich als Aussenstehender, nach 15 Minuten .pm und .pdf studieren was nicht uebersehen habe, dann kann das nicht richtig funktionieren.

Das Modul wertet nicht den Sender aus, und wenn mehrere Instanzen den gleichen UDP-Port verwenden, dann ist es Zufall, bei welcher FHEM-Instanz die Daten landen. Oder kein Zufall, aber dann landen alle Daten beim Letzten, was nicht wesentlich besser ist.

Um das Porblem "richtig" (im Sinne einer FHEM-Architektur) zu loesen, muesste man das Modul in zwei aufspalten (IO-Modul und "logisches" Modul).

Wenn man diese Arbeit sparen will (d.h. Pfusch ist auch ok), dann muss man beim Empfang der Daten anhand der Sender-IP erst die richtige FHEM-Instanz finden (z.Bsp. ueber eine Schleife aller FHEM-Geraete), und dann die readings*Update Funktionen mit dessen $hash aufrufen.

Wenn man fuer nachfolgende Programmierer Kopfschmerzen ersparen will, dann oeffnet nur der erste "define" ein Port, alle Nachfolgenden verwenden diese Instanz zum Schreiben. Dieser Schritt ist, wie erwaehnt, optional :)

heiko73

Hi Rudolf und danke fürs Reinschauen!

Ja, habe ich auch so festgestellt. Habe etwas Debug eingebaut und tatsächlich wird immer der Hash einer der beiden Wallboxen übergeben, egal von welcher IP die Antwort per UDP ankommt. Leider sind die Wallboxen auch nicht so schlau, bei einem eingehenden Request die Antwort an den Source Port des Requests zurück zu schicken, sondern sie nehmen immer den Port 7090. Ich habe bisher auch noch keine Möglichkeit gefunden, diesen Port auf den Wallboxen umzustellen, damit sie jeweils andere Ports verwenden - dann würde es wieder klappen. Allerdings ist dann trotzdem nicht der Fall abgedeckt, dass jemand zwei oder mehr Wallboxen mit gleichem Port verwendet.

Wenn das tatsächlich nicht geht (ich werde auf jeden Fall trotzdem beim Hersteller anfragen), dann bleibt nur die von Dir vorgeschlagene Vorgehensweise, d.h. die Read Funktion bekommt zwar einen Hash übergeben, den muss sie aber ignorieren und selbst ermitteln, für welches der definierten Wallbox Objekte die Antwort ist, eben über die IP Adresse des Absenders der Antwort.

Ich habe mal versucht, in anderen Modulen zu spicken, finde aber keins bei dem ich durchsteige, wie das gehen soll.

Gibt es eine "foreach" Schleife mit der ich durch alle Hashes gehen kann, die zu diesem Modul gehören? Oder muss ich durch *alle* Hashes aller Module gehen (wow, das wären bei mir ein paar)?

Nur einen Socket aufzumachen wäre sicher machbar, aber mit dem Reuse Port und individuellen Sockets ist das Senden meiner Meinung nach einfacher und vor allem wird damit der Fall abgedeckt, dass es tatsächlich mal unterschiedliche Ports geben kann. Dann braucht man nicht bei jedem Define checken, ob es für den angegebenen Port bereits einen Empfangs-Socket gibt oder nicht.

Eine Trennung in Kommunikation und Logik hört sich gut an, allerdings übersteigt das bei weitem meine Fähigkeiten und ich halte es für wahrscheinlicher, dass ich das mit dem "Auswerten der Antwort und herausfinden, zu welchem Objekt es gehört" hinbekomme.

Nochmals Danke!

Viele Grüße,
  Heiko



heiko73

OK, ich glaube ich habs erstmal so hinbekommen.

Gehe doch durch alle Objekte/Hashes, machen die meisten anderen Module auch so, und checke dann als erstes auf den TYPE.

Jetzt werden die responses meiner beiden Wallboxen anscheinend korrekt zugeordnet.

Code:

  $socket->recv($response,512);
  my $peeraddress = $socket->peerhost();
  my $foundhash = 0;

  Log 3, "Message received from $peeraddress";
  Log 3, "Data: $response";

  my $ch = $hash;
foreach my $d(keys %defs) {
        $ch = $defs{$d};
        next if (!exists($ch->{TYPE}));
        next if ($ch->{TYPE} ne 'KEBA');
        Log 3,"  checking $ch->{Host} $ch->{NAME} ";
        $foundhash = 1;
        $hash = $ch;
        last if ($ch->{Host} eq $peeraddress);
        $foundhash = 0;
  }


  if ($foundhash eq '1') {
       Log 3," OK, message received from $hash->{Host} ";
  } else {
       Log 3," Unknown sender/could not find a matching object";
       return;
  }



Es gibt dann solche Log Einträge:


2021.02.16 13:24:34 3: wallbox1 Sending command: report 3
2021.02.16 13:24:34 3: wallbox1 Command was sent
2021.02.16 13:24:34 3: Message received from 192.168.0.111
2021.02.16 13:24:34 3: Data: {
"ID": "3",
"U1": 0,
"U2": 0,
"U3": 0,
"I1": 0,
"I2": 0,
"I3": 0,
"P": 0,
"PF": 0,
"E pres": 103263,
"E total": 1408408,
"Serial": "21328205",
"Sec": 936592
}

2021.02.16 13:24:34 3:   checking 192.168.0.111 wallbox1
2021.02.16 13:24:34 3:  OK, message received from 192.168.0.111
...
2021.02.16 13:24:53 3: wallbox2 Sending command: report 3
2021.02.16 13:24:53 3: wallbox2 Command was sent
2021.02.16 13:24:53 3: Message received from 192.168.0.112
2021.02.16 13:24:53 3: Data: {
"ID": "3",
"U1": 0,
"U2": 0,
"U3": 0,
"I1": 0,
"I2": 0,
"I3": 0,
"P": 0,
"PF": 0,
"E pres": 0,
"E total": 10804,
"Serial": "yyyyyyyy",
"Sec": 363890
}

2021.02.16 13:24:53 3:   checking 192.168.0.112 wallbox2
2021.02.16 13:24:53 3:  OK, message received from 192.168.0.112


Lasse das mal ne Weile laufen und hoffe, dass es hält.

Viele Grüße,
  Heiko

rudolfkoenig

ZitatLeider sind die Wallboxen auch nicht so schlau, bei einem eingehenden Request die Antwort an den Source Port des Requests zurück zu schicken, sondern sie nehmen immer den Port 7090.
Das ist noch nicht sicher: Du setzt ja den Source Port (aka Localport) immer auf 7090, selbst dein Betriebsystem hielt diese Idee vor ReusePort=>1 fuer nicht so toll (Port already in use).
Laut KEBA-Doku gibt es Broadcasts, die an 7090 gehen, ich weiss nicht, ob diese in deinem Fall relevant sind. Wenn ja, dann ist 7090 Pflicht. Muss aber nicht mehr als einmal geoffnet werden.

ZitatLasse das mal ne Weile laufen und hoffe, dass es hält.
Deine Loesung sollte funktionieren.

Fuer den Fall, dass viele Nachrichten kommen und dein Rechner zu schwach fuer die staendigen Schleifen ist, kann man die IP->$hash Zuordnung in einem Modul-Eigenen hash merken. Erst wenn die IP nicht in diesem Hash ist, muss man die Schleife durchfuehren (und die IP merken).


heiko73

Hi,

danke für die Hinweise, die Idee mit dem moduleigenen Hash hört sich gut an. Auf meinem FHEM Server ist das zwar kein Problem (Xeon CPU), aber für die Raspi-Fraktion etc. eventuell dann doch.

Ich schaue mal, ob ich einen einzigen "Sende-Socket" anlegen kann, der dann einen x-beliebigen (freien) UDP Port als Sourceport nutzt. Beim Empfangen kann ich nicht nur eine Socket nehmen, wenn man die Ports entweder auf den Wallboxen umkonfigurieren kann oder in Zukunft mal andere Modelle mit anderen Ports auf den Markt kommen (die aber ansonsten die gleiche Kommunikation per JSON ermöglichen).

Ich versuche mal, einen Socket pro vom Benutzer für die Wallboxen definierten Port aufzumachen.

Viele Grüße,
   Heiko