KNX: CommandLine Tool für Siriproxy

Um z.B. im Haus die Lampen im KNX Netz zu steuern, kann man eine teure Visualsierung nutzen, oder auch einfach das iPhone und Siri.

Dazu braucht man keinen Jailbreak und außer dem iPhone nur noch ein Rasperry-PI mit dem siriproxy und ein kleines Linux-CommandLine-Tool, der die Commandos in Richtung IP-KNX-Gateway abfeuert.

Hier findet man ein gutes Tutorial zur Installation des siriproxy auf einem Raspi.

SiriProxy auf Raspberry Pi

Ist das fertiggestellt, gibt es hier das passende CommandLineTool von mir zum Download.
Zusätzlich zur Raspi (ARM) Version habe ich noch Eins für x86 Linux kompiliert und mit in das ZIP gepackt.

Download knxcmd_1.0.1

Einfach eine der Dateien auf dem ZIP wählen, ins /bin Verzeichnis legen und ausführbar machen.

chmod +x knxcmd

Ruft man dann

> knxcmd -?

auf, erscheint
Usage: ./knxcmd [-d?] [-i ipaddress] [-p port] [-g groupaddress] [-c command]
-i 192.168.10.10 Interface IP address
-p 3671 Specified port
-g 1/1/90 Group address of receiver
-c 81 Command byte in hex
-d Shows debug infos
-? This help info

Hier ein Beispiel zum Einschalten einer Lampe auf Adresse 1/1/90

> knxcmd -d -i 192.168.10.14 -p 3671 -g 1/1/90 -c 81

und zum Ausschalten

> knxcmd -d -i 192.168.10.14 -p 3671 -g 1/1/90 -c 80

Viel Spaß beim Ausprobieren.

Für Vorschläge oder Erweiterungen bin ich dankbar.

edl: release 1.1.21

Änderungen bei stark wechselhaftem Wetter.

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!

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.

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?

edl Release 1.1.17

Kleinere Bugfixes…

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

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“ :).

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

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.

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

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

edl Datenausgabe

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

home3

und weitere Details in der XML Ausgabe sehen:

xml3

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

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.

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)

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

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.

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

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.

Load more

Translate »