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.

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

Mehr lesen

Translate »