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.
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 …
Nein Betriebsart 5 kann dieses auch nicht, hier kann man nur definieren für welche Aktoren die Zustandsänderung über Funk weitergeleitet wird…
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… :-/
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…
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
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 
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
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 | Parse Buffer | U<NUL><BEL><BEL><SOH>zöp<SOH>¥i‚0<SOH>ÿÿÿÿM<NUL>2
HEX: 29.10.2016 12:23:03.00 | Parse Buffer | 55 00 07 07 01 7A F6 70 01 A5 69 82 30 01 FF FF FF FF 4D 00 32
TXT: 29.10.2016 12:23:03.00 | Parse Data: 01 | öp<SOH>¥i‚0
HEX: 29.10.2016 12:23:03.00 | Parse Data: 01 | F6 70 01 A5 69 82 30
TXT: 29.10.2016 12:23:03.00 | Parse Data (Opt) | <SOH>ÿÿÿÿM<NUL>
HEX: 29.10.2016 12:23:03.00 | Parse Data (Opt) | 01 FF FF FF FF 4D 00
TXT: 29.10.2016 12:23:03.00 | TRANSMIT | U<NUL><SOH><NUL><ENQ>p<BS>8
HEX: 29.10.2016 12:23:03.00 | TRANSMIT | 55 00 01 00 05 70 08 38
TXT: 29.10.2016 12:23:03.00 | Parse Buffer | U<NUL><ENQ><SOH><STX>Û<NUL>ÿÔ”<NUL><LF>˜
HEX: 29.10.2016 12:23:03.00 | Parse Buffer | 55 00 05 01 02 DB 00 FF D4 94 00 0A 98
TXT: 29.10.2016 12:23:03.00 | Parse Data: 02 | <NUL>ÿÔ”<NUL>
HEX: 29.10.2016 12:23:03.00 | Parse Data: 02 | 00 FF D4 94 00
TXT: 29.10.2016 12:23:03.00 | Parse Data (Opt) | <LF>
HEX: 29.10.2016 12:23:03.00 | Parse Data (Opt) | 0A
TXT: 29.10.2016 12:23:03.00 | RESULT | <NUL>ÿÔ”<NUL>
HEX: 29.10.2016 12:23:03.00 | RESULT | 00 FF D4 94 00
TXT: 29.10.2016 12:23:06.00 | Parse Buffer | U<NUL><LF><BEL><SOH>ë¥<STX>U<NUL><HT><SOH>¥i‚<NUL><SOH>ÿÿÿÿO<NUL>–
HEX: 29.10.2016 12:23:06.00 | 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
TXT: 29.10.2016 12:23:06.00 | Parse Data: 01 | ¥<STX>U<NUL><HT><SOH>¥i‚<NUL>
HEX: 29.10.2016 12:23:06.00 | Parse Data: 01 | A5 02 55 00 09 01 A5 69 82 00
TXT: 29.10.2016 12:23:06.00 | Parse Data (Opt) | <SOH>ÿÿÿÿO<NUL>
HEX: 29.10.2016 12:23:06.00 | 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?
@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
Vielen Dank für die Antwort.
Ich dachte schon ich sei zu blöd
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.
Ich habe „leider“ ein USB Gateway mit ESP3
OK, dann anbei meine Version mit dem faulen raten der CRC8
Evtl. kannst Du ja was mit anfangen, es muss pro FUD61NPN ja nur einmalig zum Einlernen von IPS benutzt werden.
Dazu erstmal den FUD61NPN in den Einlernmodus PC/GVS bringen. Wenn es dann blinkt einfach dieses Script starten.
Dann sollte die LED aufhören zu blinken
<?
// Es muss nur der Bereich der BaseID und GeräteID im Stream geändert werden,
// sowie die InstanzID des i/o Gateways unten! Nicht den Splitter eintragen!
$Sendstream = "55000A0701EBA5E0400D80FFBEF2020003FFFFFFFFFF00";
// 55 = Sync Byte
// 000A = Header.Data Length = Dezimal 10
// 07 = Header.Optional Length = Dezimal 7
// 01 = Header.PaketType
// EB = CRC8 Wert für Header
// A5E0400D80FF = TeachIN Definition (Datenbytes 0 bis 6)
// BEF200 = BaseID -> Austausch durch Deine BASEID vom Enocean Gateway (Datenbytes 7 bis 9)
// 2 = GeräteID wird zur BaseID addiert!!!!!, Austausch durch Deine Geräte ID (In IPS eingestellt bei der FUD61NPN Instanz) (Datenbyte 9)
// 00 = Datenbyte 10
// 03FFFFFFFFFF00 = Optionale Daten (Opt. Datenbyte 1 bis 7)
// Es muss nur der Bereich der BaseID und GeräteID bei Dir geändert werden,
// sowie die InstanzID des i/o Gateways! Nicht den Splitter eintragen!
// CRC8 erraten, als quick and dirty Lösung nur zum Anlernen :-)
// For Schleife kann ggf. auch in Etappen ausgeführt werden 0 - 100, 100 bis 200, 200 - 255
for ($b=0;$b<=255;$b++){
if ($b < 16) {
$Send = $Sendstream . "0" . strtoupper(dechex($b));
} else {
$Send = $Sendstream . strtoupper(dechex($b));
}
echo "Sende Enocean Paket: ".$Send."<br />
";
CSCK_SendText(12345 /*[Enocean LAN Gate]*/,hextostr($Sendstream)); //Sendet den Text "Beliebiger Datensatz" auf dem Client Socket mit der ID 12345
IPS_Sleep(50); // Wartezeit zwischen den Paketen = Gesamt = ca. 13 Sekunden
}
function hextostr($x) {
$s='';
foreach(explode("
",trim(chunk_split($x,2))) as $h) $s.=chr(hexdec($h));
return($s);
}
?>
Top! Vielen Dank!
Werde ich heute abend direkt ausprobieren.
Hmm, leider klappt es mit dem Skript immer noch nicht 
Ich habe allerdings auch ein USB Gateway.
Daher habe ich den send Befehl angepasst. Er sendet auch korrekt aber der Dimmer reagiert nicht.
Gibt es sonst noch etwas zu beachten?
Ich gucks mir am WE noch mal an.
Scheinbar lässt eine Lösung seitens IPS ja noch auf sich warten.
Und gab es am Wochenende neue Erkenntnisse?
Hallo Luke 2205,
mit Kids geht nicht immer alles so schnell wie mann möchte .-)
Und mein Testaufbau ist nicht so Safe, das ich es mit den Kids machen kann :rolleyes:
Also es sollte funktionieren, aber Du kannst noch mal versuchen den Wert für IPS_Sleep(50) auf IPS_Sleep(300) oder so zu setzen. Evtl. ist dein Gateway damit überfordert. Falls die Zeit zu lang wird, muss Du die Schleife teilen.
Sonst schick mir per PN doch mal deine BaseID, und dein Script. Dann schaue ich mir das mal an, wenn es die Zeit erlaubt
Hallo,
ich muss hier an dieser Stelle mal eine Frage stelle.
Ich interessiere mich brennend für die Eltako 14 Serie. Nun habe ich einiges gelesen, wie sich das mit den einbinden in IPS verhält und bin leicht verwirrt. Ich beforzuge die Kabelgebundene Lösung mit dem FGW14.
Frage 1:
Ist es möglich Komponenten der Eltako 14 Serie relativ problemlos einzubinden ? (inkl. Rückmeldung)
Frage 2:
Ist es möglich über diesen Gatway auch abgesetzte Funkaktoren in Verbindung mit dem FAM14 zu bedienen ebenfalls inkl. Rückmeldung?
ich danke euch für ein paar Infos bevor ich loslege