nachdem mein erstes Modul im Einsatz ganz gut läuft habe ich noch auf die schnelle ein weiteres gemacht. Dazu habe ich das Repository aus dem FTS12 Post unbenannt, da ich nun ggf. weitere Unterstützungen nach Bedarf erstelle.
Eltako IPS Modul für FTS12 Aktor auf dem RS485 Bus über einen FGW14 eingebunden
Das Eltakto Tastermodul ist von IPS nicht unterstützt. Dieses Modul soll den Tasterstatus als Bool Statusvariablen ausgeben und eine festlegbare Unterscheidung zwischen einem kurzen und langem Tastendruck ermöglichen.
FSB14
Das Eltakto Beschattungsmodul ist von IPS nicht vollständig unterstützt. Dieses Modul soll den Rückkanal der Fahrzeit auswerten und damit die Position in Prozent wiedergeben. Durch das Standard Variablenprofil kann ein verlinker Enocean Aktor angesteuert werden.
Wird auch eine Unterstützung für die fts14em Module kommen?
Bin gerade am überlegen, ob ich meinen Neubau mit dem Eltako System ausstatten soll und dabei würde ich einige FTS14EM verwenden.
An diesem werden nicht nur Taster angeschlossen, sondern auch bewegungsmelder und Fensterkontakte die ich dann darüber in ips einbinden möchte.
Würde das damit dann gehen?
ich hab ein solches Modul nicht, aber das sollte dennoch gehen auch wenn man einfach ein neues Modul auf Basis des FTS12 macht.
Das Protokoll im Byte3 sieht etwas anders aus. Beim überfliegen ist das aber eigentlich nichts anderes als ein FTS12
Data_byte3 = Ansteuerung von +E1 -> 0x70 (Basis-ID +0)
Ansteuerung von +E2 -> 0x50 (Basis-ID +1)
Ansteuerung von +E3 -> 0x30 (Basis-ID +2)
Ansteuerung von +E4 -> 0x10 (Basis-ID +3)
Ansteuerung von +E5 -> 0x70 (Basis-ID +4)
Ansteuerung von +E6 -> 0x50 (Basis-ID +5)
Ansteuerung von +E7 -> 0x30 (Basis-ID +6)
Ansteuerung von +E8 -> 0x10 (Basis-ID +7)
Ansteuerung von +E9 -> 0x70 (Basis-ID +8)
Ansteuerung von +E10 -> 0x50 (Basis-ID +9)
Gerade geschaut das FTS12 geht nicht weil Datenbyte 0 genutzt wird und beim 14er das Byte3. Die Logik ist aber sehr ähnlich. So ins blaue gedacht braucht man nur in der Konfig zusätzlich eine Unterscheidung welches Byte ausgewertet werden soll.
Das Eltakto Beschattungsmodul ist von IPS nicht vollständig unterstützt. Dieses Modul soll den Rückkanal der Fahrzeit auswerten und damit die Position in Prozent wiedergeben.
Das Modul steuert einen verlinken Enocean Aktor.
Die FSB14 Aktoren senden in der Endlage (Ablauf der max. Zeit am Aktor eingestellt) ein extra Protokoll für die erreichte Endlage. Dieses wird ausgewertet und in diesem Fall die Fahrzeiten und Position gemäß der Fahrzeiteneinstellung korrigiert. Damit erreicht man in einer Endlage immer eine Neujustierung falls bei mehrfachen Fahrten ohne Endlage eine Verschiebung der Position aufgrund von Ungenauigkeiten eintritt. Hintegrund: Der Aktor meldet nur die Fahrzeit und keine echte Position.
Variablen
Fahrzeit - Ist die aggregierte Fahrzeit des Aktors als Integer in Sek*10 (Beispiel 5,5 Sek = 55). Die Fahrzeit wird bei beim hochfahren um einen Schleppfaktor korrigiert.
Position - Gibt die Position der Beschattung in Prozent wieder. 0=offen und 100=geschlossen
Konfiguration
Anlegen einer Instanz, sie ist unter Eltakto Geräten mit dem Namen FSB14 zu finden
Enocean Gateway auswählen
Muss auch ein Gateway sein auf den man die Antworten des FSB14 bekommt. Bei mir zB. ein FGW14
Parameter setzen
DeviceID (Hex) - Ist die Enocean Geräteadresse in Hexadecimal ohne führende Nullen
DeviceID Aktor - Als Link den zu steuernden Eltako Rolladen Aktor auswählen. Also die vermutlich schon vorhandene Shutter Instanz. Es wird aber der Name gezeigt, nicht die InstanzID oder eine DeviceID
50% - Bsp. 90. Die Fahrzeit in Sek*10 eintragen, wo die Beschattung zur Hälfte beschattet hat. (90= 9 Sek.)
75% - Bsp. 140
99% - Bsp. 200. Die Fahrzeit in Sek*10 eintragen, wo die Beschattung z.b. Rolläden nur noch die Schlitze offen sind.
geschlossen - Bsp. 273 - vollständog geschlossen
Fahrzeitkorrektur für Fahrten nach oben:
Schleppfaktor =1.0 für keine Korrektur. Oder Bsp. 0.835 für einen 2m Alu Rolladen. Hintergrund ist das aufgrund des Gewichtes die Laufzeit für die Fahrt nach unten und oben unterschiedlich ist. Um den Faktor zu ermitteln ist die Fahrzeit von offen->geschlossen und von geschlossen->offen zu messen. Beispiel runter=24,21 Sek. und hoch=28,81 Sek. Der Schleppfaktor ist dann Zeit runter geteilt durch Zeit hoch. Also 24.21 / 28.81 = 0.84
Bedienung und Anzeige:
Einfach die % auswählen der Variable Position. z.B. über Link im Webfront
Ok, ich hab vielleicht ne komische Kombination. Ich habe zwei Enocean Gateway. Das BSC Funk und FGW Seriell.
Der Rolladen Shutter läuft bei mir über Funk.
Das PHP Modul FSB14 über die FGW.
Um z.b. die Enocean Adresse zu bekommen habe ich einfach ein Hoppe Window Catch angelegt und habe suchen gedrückt. Wenn man dann den Rolladen fährt habe ich die Adresse in dem Fenster bekommen.
Bei der Device-ID musst du mir nochmal weiter helfen… egal was ich da eintrage kommt nichts an.
Kannst du nicht die ID nehmen, die auch als Rückmelde-ID bei der Instanz eingetragen ist?
Bei mir funktioniert das Modul einfach nicht, zum Testen hab ich mir jetzt einen Fork gezogen, aber irgendwo muss das Modul noch einen Grundsatz-Fehler haben, es kommen gar keine Daten vom Gateway an, auch wenn man den Filter auf das Modul raus nimmt.
Wer Lust hat mit nach dem Fehler zu suchen, ich habe ein minimal korrigierte Version unter: MoreEltako/FSB14 at master · Hagbard235/MoreEltako · GitHub
geforkt. Laufen tut sie aber noch nicht… wäre ja schon für Debug-Daten dankbar.
So, es gab einige Konflikte weil IPS noch das alte Modul irgendwie geladen hatte… nachdem ich ID und bezeichner etc. alles geändert hatte funktioniert es.
Den Fehler hab ich jetzt auch gefunden, wer mein Repo nutzt, der kann einfach die Rückmelde-Adresse des Aktors nehmen, den man dort eh eingetragen hat.
@mäc: Du könntest die Änderungen auch in dein Modul übernehmen, dann würde ich den Fork wieder löschen
Hi, ja, der Integer-Überlauf war das eine, den ConnectParent habe ich in die Create-Methode verschoben aber die Zeiten stimmen immer noch nicht. Das liegt wohl am FSB14, denn…
Wenn ich hoch fahre und Stopp mache bekomme ich erst einmal eine DB0 = 1 (hochfahren) und beim Stopp ein DB0=10 (Hex a), da funktioniert alles richtig.
ABER
wenn ich runter fahre bekomme ich erst ein DB0=2 (runterfahren) und schon bald, ohne dass das Ende erreicht ist ein db0=80 (Hex 70) , was eigentlich heisst dass das Rollo unten ist, ist es aber gar nicht. Ein Stopp kommt nicht mehr als Signal! damit machen alle runter-fahrten mit Stopp die Position ganz kaputt.
es liegt an der FSB14-Konfiguration… bei mir sind ALLE bis auf einen auf eine Einstellung wo es heisst
„kann NICHT durch Zentralenbefehl gestoppt werden“… was das heissen soll… keine Ahnung…
wenn man aber, wie bei dem einen, auf „kann durch Zentralenbefehl gestoppt werden“ stellt, dann geht es…
eine SEHR komische Verarbeitung bei Eltako… zum einen funktioniert es ja nicht wie dort beschrieben, zum anderen bei hoch anders als bei runter…
1. Int Überlauf
logo hab ich mir nicht mal nen Kopf gemacht aber muss geändert werden.
2. Verschieben des Connect in die Create
Das muss eigentlich nicht sein nach Doku:
Wird ausgeführt, wenn auf der Konfigurationsseite „Übernehmen“ gedrückt wird und nach dem unittelbaren Erstellen der Instanz.
Probierst bitte nochmal das ohne die Create Änderung? Punkt 1 übernehme ich. Logo
Connectparent bitte nur im Create. Sonst kann es sein, dass wenn der User absichtlich den Parent disconnected, er nach übernehmen der Konfig wieder verbunden wird.
Solle Eingriffe sollten vermieden werden (hoheit des User und so).
Doku sagt auch im Create ConnectParent IP-Symcon :: Automatisierungssoftware
Michael
