Aug 10

edl: release 1.1.21

Änderungen bei stark wechselhaftem Wetter.

Aug 09

edl: Version 1.1.20 mit KNXnet/IP Unterstützung

Die Version 1.1.20 ist online. Neben kleiner Bugfixes in der Steuerung der Wallbox, wird nun KNX voll unterstützt. Dazu ist es in der ini-Datei möglich, die IP des KNXnet/IP Gateways, den Port und die Zielgruppenadresse einzustellen. Nach dem Neustart des Dienstes wird zyklisch einmal pro Minute der „Aktuelle Wirkleistungswert L1,L2,L3“ ins KNX Netz gestreut.

Um dieses virtuelle Objekt in der ETS Software zu benutzen, ist es möglich, die ETS Datei des Hager TE360 zu nutzen. Dort Kommunikationsobjekt 3 auswählen. Es werden 4 byte gesendet. Negativwerte sind „Lieferungen ins Netz“, Positive sind „Bezugsleistungen“.

Hager TE360 Webseite

Wichtig! Gegenüber der Vorversion muss die [KNX] Sektion in der ini Datei angepasst werden. Hier gab es Veränderungen.

Die edl Software nutzt das Gateway nur für den Augenblick des Sendens der 4 Byte Nutzdaten. Es baut die Verbindung immer wieder ab und beim nächsten Mal eine Neue auf. Sollten andere Geräte den „Tunnel“ gerade belegen, so wird das Senden verworfen und beim nächsten Mal erneut versucht!

Aug 07

edl: KNXnet/IP cEMI Problem gelöst

Ich bin an dem Problem noch ein wenig verzweifelt, aber ich konnte es dennoch lösen. Ich habe auf mein TUNNELLING_REQUEST deshalb keine Antwort bekommen, weil das Gateway zwischen „Rahmen“-Anfragen und „Daten“-Anfragen unterscheidet. Die Rahmenanfragen muss man mit einem anderen lokalen Port versenden, als später die eigentliche Dataanfrage, hier das TUNNELLING_REQUEST.

Diese beiden unterschiedlichen, wenn auch beliebigen Ports, muss man schon in der ersten Anfrage (CONNECTION_REQUEST) korrekt mitteilen. Um Portüberschneidungen auf dem Client zu vermeiden, sollte man die lokalen Ports durch das Betriebssystem vergeben lassen.

So sieht nun eine saubere KNXnet/IP cEMI Anfrage (schreibend) aus. Hier ist es das Einschalten einer Lampe auf der Gruppenadresse 1/0/2

1st: sending CONNECT_REQUEST

06 10 02 05 00 1a 08 01 c0 a8 0a b3 d9 6d 08 01 c0 a8 0a b3 d8 36 04 04 02 00

2nd: receiving CONNECT_RESPONCE with no errors

06 10 02 06 00 14 49 00 08 01 c0 a8 0a 0e 0e 57 04 04 10 01

3rd: sending CONNECTIONSTATE_REQUEST

06 10 02 07 00 10 49 00 08 01 c0 a8 0a b3 d9 6d

4th: receiving CONNECTIONSTATE_RESPONCE with not errors

06 10 02 08 00 08 49 00

5th: sending TUNNELLING_REQUEST (Switch the lighbumb on, at 1/0/2)

06 10 04 20 00 15 04 49 00 00 11 00 bc e0 00 00 08 02 01 00 81

6th: receiving TUNNELLUNG_ACK with not errors

06 10 04 21 00 0a 04 49 00 00

7th: receiving TUNNELLING_REQUEST from gateway to proof our request (change bytes from 11 to 2e)

06 10 04 20 00 15 04 49 00 00 2e 00 bd e0 10 01 08 02 01 00 81

8th: sending TUNNELLING_ACK

06 10 04 21 00 0a 04 49 01 00

9th: sending DISCONNECT_REQUEST

06 10 02 09 00 10 49 00 08 01 c0 a8 0a b3 d9 6d

10th: receiving DISCONNECT_RESPONCE without errors

06 10 02 0a 00 08 49 00

Jetzt kann ich das Ganze modifizieren und die aktuellen Leistungsdaten ins KNX Netz senden.

So sieht das dann in Wireshark mit KNXnet/IP Plugin aus:

wireshark

Wer genau wissen will, was welches Byte bedeutet und wie man das selbst umsetzt, der guckt sich das am besten hier an.

Aug 04

edl: KNX Integration

Bisher konnte ich nur mit einer externen Software KNX Geräte im Haushalt mit der Information von überschüssigem Strom versorgen. Dies soll nun auch die edl Software übernehmen.

Dazu braucht man eigentlich nur ein KNX IP Interface, der die Daten vom Ethernet auf das KNX TP Netzwerk weiterleitet. Ich habe mich für das Siemens 5WG1 148-1AB21 entschieden.

siemens_ip-schnittstelle

Dies ist kein Router (zum Verbinden von 2-KNX Linien über Ethernet), sondern nur ein IP Interface. Es kann eine Verbindung zu einer Gruppenadresse aufnehmen.

Die edl Software soll die vorliegenden Informationen über „zu viel freien Strom“ im KNX Netzwerk verbreiten. Die Kommunikation mit dem Interface funktioniert sehr gut, nur leider komme ich an einer Stelle nicht weiter. Weiss jemand einen Rat?

Ich sende wie folgt:

1.) sende CONNECT_REQUEST

06 10 02 05 00 1a 08 01 00 00 00 00 f4 57 08 01 c0 a8 0a 0e 0e 57 04 04 02 00

2.) empfange CONNECT_RESPONCE mit vergebender Channel ID (hier 0x53) für diese Verbindung

06 10 02 06 00 14 53 00 08 01 00 00 00 00 00 00 04 04 00 0e

3.) sende CONNECTIONSTATE_REQUEST

06 10 02 07 00 10 53 00 08 01 00 00 00 00 f4 57

4.) empfange CONNECTIONSTATE_RESPONCE mit Status normal (0x00)

06 10 02 08 00 08 53 00

5.) sende TUNNELING_REQUEST

06 10 04 20 00 15 04 53 00 00 11 00 bc e0 00 00 08 02 01 00 81

HIER KOMMT KEINE ANTWORT. WIESO? Was ist falsch?

nach dem Empfangstimeout beende ich die Verbindung:

6.) sende DISCONNECT_REQUEST

06 10 02 09 00 10 53 00 08 01 00 00 00 00 cd a9

7.): empfange DISCONNECT_RESPONCE ohne Fehler (0x00)

06 10 02 0a 00 08

Wer hat Erfahrung damit? Wer kann helfen?

Jul 28

edl Release 1.1.17

Kleinere Bugfixes…

Jul 27

Einmal vollladen bitte

Was macht man, wenn das Auto vollgeladen ist, die Waschmaschine und der Geschirrspühler gearbeitet haben? Bewässern? Dazu steht die Sonne leider noch zu hoch.

Genau. Sinnlose km zur Eisdiele fahren 🙂

samstag

Jul 21

edl Release 1.1.16 zum freien Download

Es ist soweit. Die erste öffentliche Version der Software ist verfügbar.

Einfach herunterladen und wie beschrieben installieren und starten.

Dann kommen dabei solche Kurvern heraus: (eigene Visualisierung der MySQL Daten vorausgesetzt!)

Bildschirmfoto-2013-07-21-um-19.00.20

Wie hier zu sehen ist, mag der Lear Lader sich nicht ganz der feinen Stromvorgabe fügen. Das ist ein bekannter Softwarebug im Lear Lader. Hoffentlich gibt es hier bald ein Softwareupdate von Daimler. Bis auf die kleine Stufe, hängt der Smart aber gut an der „Nadel der Sonne“ :).

Jul 15

Erweiterungen in edl 1.0.14

Ab der Version 1.0.14 kann man zwischen drei Lademodi wechseln.

1.) AUTO CHARGING – das Auto wird adaptiv zur Überschusseinspeisung einer PV Anlage oder eines BHKW geladen.
2.) QUICK CHARGING – die Wallbox läd das Auto mit dem größten gemeinsamen Nenner, ohne Rücksicht auf Überschussladung etc.
3.) MANUAL CHARGING – man kann der Wallbox einen Ladewert vorgeben und das Auto wird danach geladen.

Der „manuelle“ Modus wird notwendig, wenn z.B. nachts aus einem Stromspeicher geladen werden soll. Solch eine Ladung sollte natürlich in Abhängigkeit der Größe und Leistungsfähigkeit des Speichers geschehen. So kann z.B. mit 6A geladen werden. Während dieser Ladung gleicht der Speicher den „Verbrauch“ zu einer rechnerischen 0 am Zweirichtungszähler aus.

Ebenfalls habe ich die Minimalladung überarbeitet. Man kann je nach Auto die kleinste Stromstärke vorgeben. So z.B. für den Smart die 6A und für die ZOE 13A.

home6

Ein kleine Überarbeitung der Control-Seite wurde nach Einführung des 3. Lademodus und der Minimalladung nötig.

control7

Dadurch wurde auch die XML Webseite umfangreicher.

xml6

Jul 09

Erster Test im Automatic Modus

Ein erster Test am Sonntag bei strahlendem Sonnenschein ergab, die Ladung läuft schon sehr gut. Die grüne Kurve zeigt die Überschusseinspeisung, die Rote den Bezug und die Blaue, was ins Auto fließt.

ersterTest

Dennoch kann man noch sehr viel an der Regelung schrauben. Ist die PV Anlage hinreichend groß, verlieren sich Verbraucher wie Kaffeemaschine oder Wasserkocher. Meine Anlage hat nur 4,36kWp und so ist eine genaue Regelung um so wichtiger.

Neben dem Automatic-Modus kann man auch Quick-Laden. Beispiel: kommt man nach Hause und will schnell wieder los und das Auto ist fast leer, drückt man entweder den „Quick-Charge“ Button an der Wallbox oder via Smartphone/Computer den Softbutton. Die Regelung läd dann das Auto mit maximaler Leistung auf. (hier 22kW)

Aus den abgeleiteten Erfahrungen von Sonntag habe ich die Software noch einmal stark angepasst. Mittlerweile sind es 6688 Zeilen Code.

Jul 06

edl Version 1.0.10 & alle Duty Cycles

Ab sofort unterstützt die KEBA Wallbox alle duty cycle, also von 6000mA bis 63000mA in Schritten von 60mA. Das macht eine sanfte Anpassung der Ladekurve an die Überschusseinspeisung möglich. Klasse und mein Dank geht an die Entwickler bei KEBA!!!

home_10

Jun 30

edl Version 1.0.9

Um noch sauberer zu unterscheiden, ob ein Ladeabel gesteckt ist und/oder eine Verbindung zum EV hergestellt ist, gibt die Wallbox nun „plug“ und „state“ aus. So kann man noch besser steuern.

home4

Dazu habe ich in der XML Ausgabe, zum Klartext mancher Stati, noch Attribute als integer hinzugefügt. Dies macht ein maschinelles Einlesen externer Applikationen noch einfacher.

xml4

Jun 25

edl Datenausgabe

Die Daten der Wallbox kann man in einer kleinen Übersicht im Homescreen:

home3

und weitere Details in der XML Ausgabe sehen:

xml3

Jun 17

edl: kleine Erweiterungen

In der Version 1.0.6 habe ich den Homescreen etwas ansgepasst. Dort findet man nun auch die Sektion Car und die letzte Regelzeit.

home2

Im Controlpanel kann man nun die maximalen möglichen Ladephasen des Autos einstellen.

Beispiele:
– Autos, die nur auf L1 laden (Smart ed ohne Schnelllader)
– Autos, die auf L1 und L2 laden (Mercedes Benz B Klasse ed)
– Autos, die auf L1, L2 und L3 laden (Smart ed mit 22kW Lader, Renault Zoe etc.)

control2

Auch die XML Ausgabe wurde erweitert.

xml2

Mai 31

edl: aktive Steuerung

Für den aktiven Eingriff in die sonst automatische Steuerung, gibt es nun die Control-Page.

XML Ansicht zur Verarbeitung: (http://IP-ADRESSE:18001/control)

control

Im Normalfall läd das eAuto entlang der Überschusseinspeisung im Automatik-Modus und erhöht so den Eigenverbrauch. Diese Regelung arbeitet autark, kann aber übersteuert werden.

Aktiviert man die „Schnellladung“, so läd das Auto mit der maximalen Leitung, egal ob die Überschusseinspeisung einer PV Anlage oder eines BHKW dazu ausreicht.

Des Weiteren kann man die Grenze bestimmen, ab wann eine Zuschaltung/Abschaltung der Automatikladung erfolgen soll. Die „800“ bedeuten hier, dass ab 800W Überschusseinspeisung eine Ladung beginnt, auch wenn die kleinste Ladeleistung 1380W (6A) ist. Diesen Wert kann man beliebig zwischen 0 und 99999 W einstellen.

Mai 30

edl: interne Webseite

Der „EDL“ Linux-Dienst nimmt immer mehr Formen an. Damit man die gerade verarbeiteten Daten auch ansehen oder für eine Live-Visualisierung weiterverarbeiten kann, habe ich ihm einen internen Webserver auf Port 18001 (einstellbar) spendiert. Bis jetzt besteht er nur aus zwei Seiten. Zum einen die Homepage mit der Anzeige der aktuellen Variablen und einer XML Seite für externe Programme.

Homepage: (http://IP-ADRESSE:18001/)

home

XML Ansicht zur Verarbeitung: (http://IP-ADRESSE:18001/xml)

xml

Features des EDL Dienstes:

– echter Linux-Daemon, multithreaded
– unterstützt alle Linuxsysteme mit unterschiedlichen CPUs, z.B. x86, ARM
– einstellbare Parameter in einer Configdatei
– Unterstützung des Zähler-TCP-Gateway von http://shop.co-met.info/ (Mode C oder SML)
– Unterstützung der direkten Betriebes auf dem Raspberry Pi mit
IR Lesekopf an der serieller Schnittstelle
– Zweirichtungszähler AS1440 von Elster (Mode C) und MT175 von ISKRA (SML Protokoll)
– Extraktion der 4 wichtigsten Werte: Gesamtbezug, Gesamtlieferung, Lieferleistung, Bezugsleistung
– optional: Speicherung der 4 Werte in einer MySQL zur Auswertungszwecken
(automatische Erstellung einer Datenstruktur auf einer leeren MySQL Datenbank)

ToDo:

– Fertigstellung der KNX Daten-Übergabe
– Steuerung der KEBA Wallbox zum adaptiven Laden eines Autos (in Arbeit)
– Steuerung eines DIY ESS (LiFePo4 Stromspeicher)

Apr 01

Wallbox: Integration ins Smarthome

Die KeContact P20 bietet auf Port 80 eine kleine Homepage mit zwei Unterseiten an. Auf der Ersten wird der aktuelle Status angezeigt und die Zweite zeigt ein Log.
Da aber das kleine Log nur Daten in Sekunden seit dem Start der Box ausgiebt, habe ich die Rohdaten konsolidiert.

So sehen die Rohdaten aus:

0002bfe30300010002bfd f0200200002782a010000 000261cd0300010001c4260…….

Hierbei ins ganz einfach zu verstehen, dass sich die Zeichenkette in je 14 Zeichen teilt. Diese wiederum gliedern sich in 8 + 2 + 4 Bytes.

Hier das Beispiel an den ersten 14 Byte:

0002bfe3030001

0002bfe3 => hexadizimale Sekunden seit dem Start der Box

03 => Status, wobei 0=started, 1=unplugged, 2=plugged, 3=loading und 4=error

0001 => ein Untercode für den Status, hier schätze ich, dass 0020 (hex) bei z.B. dem Status „plugged“ einem entdeckten 32A Kabel entspricht

So sieht das Ganze als Unterseite auf meiner Haus-Homepage aus. Ich gebe die Logdaten nur bis zum letzten Neustart aus.

smarthome

Mrz 26

Wallbox: An der Wand…

anderwand

Viel sieht man noch nicht und verkabelt muss auch noch alles werden, aber das Ladekabel hat schon seinen Platz gefunden.

Mrz 18

KEBA KeContact P20 Connected Wallbox

Gestern habe ich sie bestellt, die Wallbox von KEBA, bezogen über SPX. Sie sieht sie aus:

Wallbox

Zum elektrischen Anschluss der Wallbox wird ein allstromseitiger FI und bei 32A ein LS der Charakteristik C verlangt. Der FI ist vorhanden, der Hager MCN332 ist bestellt. Öffnet man die Wallbox, kommt folgendes Terminal zum Vorschein:

anschluesse

Mrz 17

Softwareupdate des COM Moduls

….ja, es gibt eins es ist für alle Fahrzeuge bis zum Produktionstag 28.02.2013 sinnvoll.
Meine Werkstatt versucht sich gerade daran. Morgen soll ich meinen ed wieder abholen können. Dazu soll es noch ein Update der Navi-Firmware geben, da das Navi bei schlechtem GPS Empfang gern mal abstürzt.

Mrz 17

Seit fast 100 Tagen…

…fahre ich nun meinen Smart ed der 3. Generation und ich bin nach wie vor begreistert. Am 10.12.2012 übernahm ich ihn. Hier die Ausstattung:

– smart fortwo electric drive coupé
– electric drive design package
– Ledersitze in Schwarz mit Sitzheizung
– Panoramadach
– Einstiegsleisten
– Handschuhfach mit Klemmleiste
– Instrumententafel in Lederoptik
– Audio system navigation/multimedia RDS Radio mit 16,5 cm (6,5″) Touchscreen-Display
– Soundsystem
– 3-Speichen-Ledersportlenkrad mit Wippen für manuelle Bedienung der Rekuperation
– Lederschaltknauf
– Außenspiegel elektrisch einstell- und beheizbar
– LED-Tagfahrlicht
– Tempomat

Was fehlt? Die Wallbox.

Die KEBA Wallbox ist bestellt…

Load more

Translate »