EnOcean EUL

[makki]

Ich hatte und habe keine Zeit für aber das würde nach der Vorlage FS20 funktionieren, ist banales Ascii..

Makki

[perf]

ctr,

Gibt es etwas neues zu erwähnen? Ich wollte gerade einen TCM310 kaufen.

/Per

[makki]

So wie ich bei FHEM abschaue, darf es gerne bei mir abschauen, die EIB/KNX-Nummer hab ich im wiregated.pl glaube ich im Griff

Makki

[ctr]

bin da aber inzwischen auch an Grenzen gestossen:
- Abfrage von Werten (zB Statusabfrage)
- Senden von Werten
FHEM spricht inzwischen auch nativ mit dem eibd, evtl. lässt sich darüber lösen

[makki]

Wiegesagt, es spricht nichts gegen FHEM und a bisserl Bash, ausser das ich das keinem erklärt bekomme
Mach ich mit meinen X10-FFB seit Jahren nicht anders..

Makki

[ctr]

Ich belasse es erstmal bei FHEM weil ich das für erstens für unkomplizierter halte was die Kommunikation mit der HW angeht (Stichwort Socket) und ich andererseits mit den EnOcean Events andere Plugins triggern will was u.U. Abhängigkeiten in den WG-Plugins erzeugen könnte.

Beispiel in der fhem.conf für einen Funkstuhl Sitzmöbelschalter (den ich derzeit als simplen "mobilen" Schalter in der Küche mißbrauche):

define EnO_switch_00xxxxxx EnOcean 00xxxxxx
attr EnO_switch_00xxxxxx room EnOcean
attr EnO_switch_00xxxxxx subType switch

define NotifyKeyPress_Kueche notify EnO_switch_00xxxxxx "/usr/local/bin/eno_kueche.sh "%""

Und dann das entsprechende Bash Script:

#!/bin/bash

INPUT=$1

if [ "$INPUT" = "pressed" ]; then
   /usr/bin/groupswrite local:/tmp/eib 0/0/1 1
fi

Neben den Funkstuhl Möbelschaltern habe ich auch erfolgreich den EnO-Fensterbeschlag von Hoppe austesten können.

[makki]

Nun, alles Geschmackssache, bei den anderen erschien es mir einfacher das wesentliche von FHEM zu kopieren (was auch im Source steht!) als den Rest davon zu verstehen (zu wollen)
Vorteil: ist beides Perl..

Makki

PS: udev-rule ist übernommen fürs nächste PL..

[ctr]

So, habe mal trotz schönem Wetter mal angefangen.

Das TCM310 wird einwandfrei erkannt und ein /dev/ttyACMx Interface angelegt. Angehängte udev Regel erstellt auch einen Alias (analog zu CULxxx).

Firmware habe ich nach busware.de Anleitung geflashed:
busware.de : EUL
Wichtig zu erwähnen:
- der Port muß mit 57600 bit/s angesprochen werden
- es handelt sich um ESP3 Pakete (nicht etwa die einfacheren/kürzeren ESP2)

An EnOcean Geräten habe ich bis jetzt nur die "Drucksensoren für Sitzmöbel" aus dem Funkstuhl-Sammelbestellungs-Thread.
Ein (in meinem Fall 21 byte) Telegramm sieht dann wie folgt aus:

00000000  [COLOR=Red]55[/COLOR] [COLOR=Magenta]00 07 07 01[/COLOR] [COLOR=Cyan]7a[/COLOR] f6 10  00 24 99 09 20 [COLOR=Orange]01 ff ff [/COLOR]
00000010  [COLOR=Orange]ff ff 5b 00 [COLOR=Black]c3[/COLOR][/COLOR]

Legende:
Init/Sync byte (immer 0x55)
Header (Data Length (hier 7 bytes f6 bis 20), Optional Length (fix) , Packet Type (fix))
CRC (zuerst Header, später Data)
Data/Payload
optional Data (SubTelNum, Destination ID - hier broadcast ff ff ff ff, dBm, Security Level)

Gucken wir uns Data/Payload genauer an:
f6 10 00 24 99 09 20

f6 = Packet type (Manufacturer specific command or message)
10 = In meinem Fall die eigentliche Nachricht (10 gedrückt, 00 losgelassen)
24 99 09 20 = ??? irgendwo steckt da die seriennummer drin, ich vermute die ersten 3 bytes und die 20 ist nochmal was anderes


Nun wäre wirklich die Frage ob man das alles selber parsed (inkl Init-Erkennung und CRC Berechnung) oder sich das von irgendwo (zB FHEM) einbindet...

[makki]

Wie wärs damit, FHEM die KNX-DPTs beizubringen (hey, es nicht "aus Versehen" OSS - lässt sich 1:1 übernehmen - und sorry die DPT's im wiregated - stimmen wenigstens )

FHEM war damals schon in der engeren Wahl - ist keineswegs schlecht aber war mir zu OO/perlisch - ich mag halt Dinge die "Otto Normal" versteht..
Das soll aber keinen daran hindern, ist ebenso erlaubt wie linknx..

Makki

[mumpf]

Hi,

eine andere (verfügbare) Alternative ist, einfach FHEM auf dem WireGate zu installieren (es gibt ein funktionierendes .deb package), dort den EUL einzubinden und über fhem notify die entsprechenden EnOcean devices auf den KNX zu bringen. Zumindest für Schaltzustände geht alles. Wenn es um andere DPT als DPT1.xxx geht, hat fhem noch einige Probleme...

Ich nutze das hier für einige Geräte, die von FHEM unterstützt werden (allerdings nicht für EnOcean) als Kombi mit linknx und bin zufriedener als meine ersten Versuche mit dem CUL-Plugin auf dem WG.

Nachteil: Man muss auch noch FHEM lernen...

Gruß, Waldemar

[ctr]

Ich hab alles nötige hier liegen an Hardware aber bisher 0 Zeit mir das mal anzugucken...

[StefanW]

Hallo Mirko,

nein, da gibt es nichts neues und auch mangels Nachfrage wenig Intentionen von unserer Seite. Mag in einem halben Jahr anders aussehen, zuvor haben wir andere Entwicklungsaufgaben mit höherer Priorität (nein, es gibt keine Liste oder Roadmap).

glg

Stefan

[JuMi2006]

Ich hab weder Druck noch Absichten in naher Zukunft, aber aus reinem Interesse: Gibts da schon was neues?

Gruß Mirko

[makki]

Das TCM310 ist ja etwas das einem die blutigen Details abnimmt, der AVR darauf macht nicht viel mehr als Seriell<->USB..

Wie schon beim CU* wird man sich bei FHEM anlehnen können, dort ist das wies scheint eingebaut.

Makki

[StefanW]

Ich freue mich dass sich CTR der Sache annimmt und zumindest den Versuch startet

Bedenkenträger dürfen sich von mir aus auch gerne zurückhalten, weil das ist durchaus demotivierend wenn ein Lösungsversuch gleich von vornherein zerredet wird. Auch Diskussionen zu möglichen Leistungsumfängen und was geht / was nicht sollten wir auch hinten anstellen bis CTR die Ergebnisse seines Projektes vorlegt.

Nur so aus meinem Erfahrungsschatz mit "Ankündigungen" heraus...

Stefan