Eltako FAM14 in IP Symcon einbinden

dth387 · 20. August 2016 um 15:22

Hallo zusammen,

ich beschäftige mich seit einigen Tagen im Rahmen der Planung eines Neubaus auch mit dem Thema IPS. Präferiere aktuell die Eltako 14er Serie und habe mir dort ein kleines Pilot-Brett mit Dimmer, Schaltaktoren aufgebaut.

Zentrale ist (wie empfohlen) das FAM14 , an welchem ein FTS14EM (Taster) mit dem FUD14 (Dimmer) und FSR14-4x (Schaltaktor) hängt. Das FAM14 habe ich via USB mit meinem Rechner verbunden, die Konfiguration via PCT14 (PC) von Eltako funktioniert soweit auch.

Nun versuche ich die Aktoren an IPS anzulernen, dazu erstelle ich ein Enocean Gateway (ESP3 Dolphin) und nutze als Schnittstelle einen Seriellen Port, mit dem ich mich auch verbinden kann. Bei Einrichten der Aktoren bekomme ich einen Fehler dass erst die BaseID des Enocean Gateways empfangen werden muss, geschieht jedoch nicht…

Ist die Einbindung via FAM14 überhaupt möglich oder benötige ich dafür ein weiteres Gerät ? Es würde mich wundern, wenn es nicht geht, da die Konfiguration via PCT14 ja reibungslos funktioniert…

Besten Dank!

VG Dirk

bertel2013 · 21. August 2016 um 19:15

Hallo Dirk,

Du benötigst für die Kommunikation zwischen IPS und Enocean noch ein Enocean-Gateway. Da wäre z. B. der Eltako FAM-USB (den verwende ich), Enocean USB300 (wegen fehlender Antenne nicht empfehlenswert) oder das Symcon EnOcean LAN Gateway (siehe Shop). Eine weitere Möglichkeit wäre auch ein Eltako FGW14-USB, damit hättest Du eine verkabelte Verbidung zum Bus (habe ich aber bisher noch nie getestet),
Der USB Anschluss am FAM14 dient lediglich zur Konfiguration des FAM14 mittels PCT14-Tool.

Gruß
Roberto

dth387 · 21. August 2016 um 20:15

Vielen Dank für den Hinweis !! Dann kann ich mir ja lange einen zurecht konfigurieren…

Ich bestelle mir mal den FAM USB und das FGW-14-USB und werde das ganze testen. Wobei mir natürlich eine kabelgebundene Lösung lieber wäre, da der HomeServer auf dem IPS läuft direkt neben dem Schaltschrank stehen wird.

Wo liegt der Vorteil / Mehrwert des Enocean LAN Gateways gegenüber der USB Lösung ?

bertel2013 · 22. August 2016 um 08:36

Hallo Dirk,

bzgl. dem FGW14-USB habe ich nochmal Kontakt mit Eltako aufgenommen, leider können von diesem keine Telegramme an dezentrale Aktoren (z. B. FSR61) gesendet werden.
Der Vorteil von einem LAN-Gateway ist, dass Du unabhängig von einem USB-Port bist (die ganzen USB-Devices können mit der Zeit ganz schön nerven) und man z. B. das Gateway von mehreren IPS Instanzen (z. B. produktiv und testing) ansprechen kann (was bei USB natürlich nicht geht).
Mein Tipp wäre also Eltako FAM-USB (ca. 65€) oder direkt das LAN-Gateway (ca. 150€).

Gruß
Roberto

kt1 · 22. August 2016 um 10:36

Hallo zusammen,

an dem Thema bin ich seit ein paar Tagen auch dran.
Bei einem Garagen-Anbau könnte ich eigentlich auf Funk verzichten, möchte das Zeug aber an IP-Symcon anbinden, und das scheint mit Funk offenbar einfacher zu gehen als mit RS485-Bus.

Aus meiner Sicht spricht alles für das LAN-Gateway, denn USB ist von Treibern abhängig, auf Dauer sind es viele USB-Geräte, LAN lässt sich an verschiedene - räumlich auch getrennte - IPS-Instanzen anbinden. Und nicht zuletzt: ich habe IPS virtualisiert auf einem ESXi-Server, da ist LAN viel einfacher zu handeln als einen USB-Port in die Virtuelle Maschine durchzuschleifen.

Was mich ein wenig stört, ist die Redundanz: ich brauche einen Funkaktor, damit ich den Schaltstatus mit IPS visualisieren und auch steuern kann, aber wenn ich einem Taster mehrere Dinge zuordnen und daher einen Tastendruck über IPS verarbeiten möchte, brauche ich auch dafür nochmal einen Funksender. Und das, obwohl Taster und Aktor im gleichen Schaltschrank verbaut sein werden …

Viel Grüße
Karsten

dth387 · 23. August 2016 um 12:34

Vielen Dank für die Unterstützung. Ich habe mir vorerst das FAM USB besorgt und das funktioniert einwandfrei.

Ggf. steige ich dann später noch auf das LAN Gateway um, falls ich mit Ports bzw. Treibern Probleme bekomme. Aktuell läuft IPS auf einem kleinen HomeServer neben dem Schaltschrank, von daher gibts bislang keine Probleme.

dth387 · 11. September 2016 um 21:58

Ich habe in der Konstellation feststellen müssen, dass ich in IPS immer nur die beiden Bestätigungstelegramme, nachdem der Aktor eine Aktion ausführt bzw. ausgeführt hat, empfange. Was fehlt sind die regelmäßigen Statustelegramme, die das FAM14 laut Beschreibung in Betriebsmodus 2 doch regelmäßig in den Gebäudefunk senden soll… Wenn ich die serielle Schnittstelle in IPS überwache passiert hier gar nichts. 1 mal in der Minute kommt ein Signal an (vermutlich die Base-ID) aber keine regelmäßigen Status Informationen der Aktoren…

Ist das bei Euch auch so bzw. mache ich hier etwas falsch ?

Besten DAnk !

MisterX · 12. September 2016 um 07:15

Regelmäßig heißt bei Betriebsart 2 nicht ein zyklisches Abfragen der Aktoren. Es bedeutet nur, dass alle Veränderungen/Schaltungen der BR14 Aktoren über Funk weitergeleitet werden. Dieses ist beispielsweise in Betriebsart 5 nicht so, dort werden nur Aktoren-Telegramme über Funk weitergeleitet die auch in PCT14 definiert worden sind.

dth387 · 12. September 2016 um 09:30

Vielen Dank für die Antwort - wird es denn in betriebsart 5 regelmäßig/zyklisch übertragen oder ist dies gar nicht möglich ? Dies wäre ja mE ein großer Nachteil , da sobald die IPS mal ein paar Sekunden weg ist die Status der Aktoren nicht mehr stimmen …

MisterX · 12. September 2016 um 13:23

Nein Betriebsart 5 kann dieses auch nicht, hier kann man nur definieren für welche Aktoren die Zustandsänderung über Funk weitergeleitet wird…

dth387 · 12. September 2016 um 19:58

Hm, das habe ich befürchtet. Wenn ich es richtig sehe, würde ich dann den Betriebsmodus 4 benötigen oder? Dort wird ja explizit vom zyklischen Abfragen in der Anleitung gesprochen, dann jedoch nicht mehr über Funk, sondern über den Bus. d.h. ich müsste das FGW14 nutzen, um damit in IPS zu kommen… im FHEM Forum habe ich einige Einträge drüber gelesen, funktioniert dies in IPS ebenfalls ?

Wie löst der Rest der Nutzer dieses „Problem“ eines falschen Status bzw. das IPS den Status nicht mitbekommt ?
Bei Licht wäre es mir gar nicht so schlimm, Bedenken habe ich bei meiner Rolladen/Beschattungssteuerung, hier möchte ich schon sichergehen dass die Rolladen auch in der gewünschten Beschattung sind und nicht zufällig kein Signal verschluckt haben bzw. umgekehrt bereits manuell in eine Position gebracht wurden, von der IPS nichts mitbekommen hat… :-/

dth387 · 14. September 2016 um 21:54

Also ich habe mir inzwischen ein FGW14 besorgt und dies via RS232 an IPS angebunden. Wird soweit erkannt und ich kann Problemlos über IPS und das FGW14 meine Aktoren schalten. Leider bekomme ich in IPS keine Rückmeldung… bzw. das stimmt nicht so ganz, ich bekomme über den seriellen Port schon eine Rückmeldung (in Modus 4 sogar sekündlich ) , allerdings verarbeitet die IPS nicht (Schaltzustand wird nicht geändert…)

Zu meiner beispielhaften Config:

FAM14 - FTS14EM - FSR-4x - FGW14 , im Beispiel möchte ich das FSR-4x schalten.

Der FSR-4x hat im Eltako Bus die Kanäle 11-14 , ich möchte im Folgenden Kanal 11 schalten. Das FGW14 läuft auf Kanal 1.

In IPS lege ich ein Enocean Gateway ESP2 (TCM 120) an und der serielle Port wird mit 57600 Baud Rate betrieben (FGW dazu auf der passenden Pos. 6). In IPS habe ich nun einen Eltako Switch angelegt, gebe diesem einfach mal als ID die 11. Das Schaltsignal kann ich am FSR problemlos anlernen, dort wird es unter HEX ID 00 00 01 0B erkannt. Die 0B repräsentieren ja die 11, woher das 01 davor kommt, weiß ich nicht, allerdings funktioniert es.

Wenn ich nun den FSR das Relais 1 über IPS schalte (ein), bekomme ich im seriellen Port folgende Rückmeldung

A5 5A 8B 05 70 00 00 00 00 00 00 0B 30 3B

Das ganze sieht ja soweit ganz gut aus, die 70 repräsentiert laut Eltako ja den eingeschalteten Zustand., die 00 00 00 0B würde auch zum Kanal 11 des FSR passen, alles gut soweit. Demnach habe ich in IPS als Rückmelde ID auch die 00 00 00 0B eingetragen, allerdings übernimmt er die Rückmeldung bzw. den neuen Status nicht. Auch über das Suchen finde ich beim 5-maligen Schalten keine Rückmelde ID…

Hat jemand eine Idee woran das liegen könnte? Vom Prinzip her kommt ja alles an was ich brauche (die Status in FAM Modus 4 sogar sekündlich), d.h. die Lösung wäre optimal und deutlich besser als jegliche Funk-gebundene Lösung zwischen IPS und Eltako Bus… Ich frage mich nur, warum IPS den rückgemeldeten Zustand nicht übernimmt…

In FHEM scheint es ja zu funktionieren, ich würde ungern deswegen von IPS auf FHEM wechseln. Alternativ könnte ich natürlich noch überlegen die serielle Schnittstelle zu „überwachen“ und händisch die Status zu setzen, aber das kann ja auch nicht des Rätsels Lösung sein…

Silberstreifen · 26. September 2016 um 08:45

Das gleiche Problem hatte ich auch. Ich habe den Rückkanal dann tatsächlich über Cutter-Registervariable-Script gesetzt. Das funktioniert wunderbar. Aber ich gebe Dir Recht, die direkte Einbindung wäre deutlich toller, zumal die Scriptlösung bei sekündlicher Rückmeldung an ihre Leistungsgrenzen kommt.
Wenn ich die Systematik richtig verstanden habe, dann ist das „8B“ im Telegramm das Problem. In den Funktelegrammen steht „0B“ an gleicher Stelle.

@Paresy: lässt sich das nicht mal umsetzen? Das würde die Integration der Eltakos deutlich verbessern.

Viele Grüße
Jürgen

dth387 · 26. September 2016 um 09:12

Ja diesen Ansatz bin ich zunächst auch gegangen und habe wie du gemerkt, dass ich eine sehr starke CPU Auslastung bekomme, vermutlich weil sowohl das Enocean Gateway als auch die Register-Variable bzw. Skripts bei eingehenden Telegrammen arbeiten müssen.

Bin nun darauf gewechselt, komplett mit einer Register-Variable, Dummy-Instanzen und den passenden Aktions-Variablen zu arbeiten, die dann jeweils ein Aktionsskript ausführen und dort die Enocean Telegramme berechnen und direkt auf die Serielle Schnittstelle schicken. Auf der Registervariable liegt dann ein anderes Script was alles eingehende verarbeitet. Meine Konfiguration der Aktoren (Eltako IDs, Sende/Receive IDs, Variablen-IDs etc) habe ich in einer großen Config-PHP in einem Array gespeichert. Hier habe ich auch keine Probleme mit der CPU Last.

Was sich aber schon mal festhalten lässt, ist dass die Kabelgebundene Variante über das FGW14 deutlich sauberer funktioniert als die Funk Lösung, es kommen alle Telegramme an und es wird nichts „verhackstückelt“ (sieht man sehr schön im Debug-Modus auf dem Seriellen Port. Sehr schön ist acuh dass man sich frei im Adressraum bewegen kann (demnach also auch vorhandene über FTS14-EM angebundene Taster emulieren) und weiterhin das FTS14-FA Funkausgabemodul überflüssig wird, welches man bei Funk-Anbindung ja benötigt, um über FTS14-EM angebundene konventionelle Taster in IPS integrieren zu können.

Aktuell arbeite ich noch daran, die in den Eltakos vorhandenen Szenen über IPS anzutriggern, so dass ich z.B. die Rolladen-Beschattung nicht über Laufzeiten in IPS berechnen und über Up > Down > Stop ansteuern muss, sondern einfach die passende FSB14-Szene aktiviere.

Schade ist natürlich dass ich nun die komplette bereits vorhandene Enocean Logik in IPS umgangen und vermutlich nachgebaut habe, eine Anpassung der vorhandenen Module wäre natürlich ein Traum

Silberstreifen · 26. September 2016 um 16:13

Ja genau wie Du arbeite ich auch mit nur einer Registervariable. Für den Raspi ist das dennoch eine riesige Belastung. Mit Deiner config hast Du mich aber auf eine Idee gebracht, die zwar die Auslastung nicht verringert aber die Handhabung deutlich vereinfacht.
Ich lege unterhalb der RegVar eine EnoSwitch-Instanz an, lösche die Stausvariable (weil schreibgeschützt) und lege eine neue an. Diese wird dann mit einem enoswitch-script verbunden, so dass man über das Webfront schalten kann.
Der EnoSwitch-Instanz habe ich dann einen Ident verpasst, damit das RegVar-Script die richtige Instanz findet und dann bei Rückmeldung die richtige Variable aktualisiert.

Hört sich komplizierter an als es ist und funktioniert wunderbar.

Würde mich dennoch freuen, wenn paresy eine originäre Lösung anbieten könnte.

Mit Szenensteuerung habe ich leider überhaupt keine Erfahrungen.
Viele Grüße
Jürgen

Luke2205 · 29. Oktober 2016 um 12:26

Hallo,

meine Frage bezieht sich zwar nicht auf das FAM14 aber ich hoffe mir kann trotzdem jemand helfen.
Ich habe mir einen Eltako FAM-USB besorgt.

Als einzigen Aktor habe ich einen FUD61NPN dieser lässt sich über zwei fest verdrahtete Taster auch einwandfrei achalten und dimmen.

Der FAM-USB wird unter Windows als COM-Gerät erkannt. Eingestellt habe ich ihn dann auf 57600 bit/s (8bit) eingestellt.
In IPS habe ich das Gateway über Splitter->Enocean Gateway eingebunden. Es wird auch erkannt und wenn ich die Lampen über die verdrahteten Taster schalte wird die Aktion im Gateway angezeigt:

TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:03.00 | HEX: 29.10.2016 12:23:03.00 | TXT: 29.10.2016 12:23:06.00 | HEX: 29.10.2016 12:23:06.00 | TXT: 29.10.2016 12:23:06.00 | HEX: 29.10.2016 12:23:06.00 | TXT: 29.10.2016 12:23:06.00 | HEX: 29.10.2016 12:23:06.00 | Parse Buffer | U<NUL><BEL><BEL><SOH>zöp<SOH>¥i‚0<SOH>ÿÿÿÿM<NUL>2
Parse Buffer | 55 00 07 07 01 7A F6 70 01 A5 69 82 30 01 FF FF FF FF 4D 00 32
Parse Data: 01 | öp<SOH>¥i‚0
Parse Data: 01 | F6 70 01 A5 69 82 30
Parse Data (Opt) | <SOH>ÿÿÿÿM<NUL>
Parse Data (Opt) | 01 FF FF FF FF 4D 00
TRANSMIT | U<NUL><SOH><NUL><ENQ>p<BS>8
TRANSMIT | 55 00 01 00 05 70 08 38
Parse Buffer | U<NUL><ENQ><SOH><STX>Û<NUL>ÿÔ”<NUL><LF>˜
Parse Buffer | 55 00 05 01 02 DB 00 FF D4 94 00 0A 98
Parse Data: 02 | <NUL>ÿÔ”<NUL>
Parse Data: 02 | 00 FF D4 94 00
Parse Data (Opt) | <LF>
Parse Data (Opt) | 0A
RESULT | <NUL>ÿÔ”<NUL>
RESULT | 00 FF D4 94 00
Parse Buffer | U<NUL><LF><BEL><SOH>ë¥<STX>U<NUL><HT><SOH>¥i‚<NUL><SOH>ÿÿÿÿO<NUL>–
Parse Buffer | 55 00 0A 07 01 EB A5 02 55 00 09 01 A5 69 82 00 01 FF FF FF FF 4F 00 96
Parse Data: 01 | ¥<STX>U<NUL><HT><SOH>¥i‚<NUL>
Parse Data: 01 | A5 02 55 00 09 01 A5 69 82 00
Parse Data (Opt) | <SOH>ÿÿÿÿO<NUL>
Parse Data (Opt) | 01 FF FF FF FF 4F 00

Leider bekomme ich den Aktor aber nicht eingelernt.
Ich habe dazu am Aktor den oberen Drehschalter auf Learn und den unteren auf Auto gestellt und im entsprechenden IPS Modul auf einlernen geklickt. Es tut sich dann aber nichts, weder am Aktor noch in IPS.

Hat jemand eine Idee was ich falsch mache?

Jambo · 6. November 2016 um 22:23

@Luke2205
Du machst gar nix falsch! Eltako hat das TechIn Paket beim FUD61NPN geändert. Alle neuen Geräte die in 2016 gefertigt wurden haben dieses Problem. Ich habe das dieses Wochenende analysiert. Die Lösung findest Du hier https://www.symcon.de/forum/threads/32926-Einlernprobleme-mit-FUD61NPN-und-LAN-Gateway
Ich hoffe es ist verständlich

Wir müssen also darauf warten bis die IP Symcon Entwickler die neue TeachIn Prozedur in IPS einbauen.
Oder so wie ich, selbst ein handgemachtes TeachIn Paket über das Gateway schicken. Allerdings ist die CRC8 Berechung für die beiden Checksummen ein wenig aufwendig. Falls IPS das nicht zeitnah einbaut ekläre ich es gern an dieser Stelle demnächst.Hängt sicher auch noch davon ab ob es ein Gateway ist welches ESP2 spricht oder ESP3.

Vielleicht antwortet mal einer der Entwickler auf das Thema in der nächsten Arbeitswoche

Luke2205 · 7. November 2016 um 16:18

Vielen Dank für die Antwort.
Ich dachte schon ich sei zu blöd

Jambo · 7. November 2016 um 23:39

Falls du ein Gateway auf ESP2 Basis hast, kannst Du die Cheksum ganz einfach selber berechnen.
Wie das genau geht steht hier: https://www.enocean.com/fileadmin/redaktion/support/dolphin-api/esp2_page.html
Also bis auf die beiden ersten Sync Bytes einfach alle anderen Bytes auf Hexbasis addieren und fertig
Dann schickst Du das Paket einfach über ein PHP Script an die IO Instanz.

<?
$Sendstream =  "Hier muss das hex Techinpaket als String stehen"; //(BSP:  "FFAB33..."
CSCK_SendText(12345 /*[Enocean LAN Gate]*/,hextostr($Sendstream)); //Sendet den Text "Beliebiger Datensatz" auf dem Client Socket mit der ID 12345

function hextostr($x) {
  $s='';
  foreach(explode("
",trim(chunk_split($x,2))) as $h) $s.=chr(hexdec($h));
  return($s);
}

Bei einem Gateway auf ESP3 Basis TCM310 / LAN Gateway ist das nicht ganz so einfach, da hier eine CRC8 Berechung stattfindet.

Luke2205 · 8. November 2016 um 06:55

Ich habe „leider“ ein USB Gateway mit ESP3