da die Suche zum Eltako FTK nicht viel ausspuckt und der einzige Thread dazu auch geschlossen wurde, stelle ich halt die Anfrage in einem neuen Thread.
Welche ist die passende Instanz zum FTK? Ich habe in anderen Thread etwas vom STM250 gelesen, der aber nur eine Bool-Variable besitzt. Hier hat sicher schonmal jemand etwas programmiert, um die Daten vom FTK anschliessend zu verarbeiten? Könnte man das posten?
Da in dem anderen Thread noch fleissig über die ENO-Unterstützung in IPS diskutiert wurde, hier noch eine Anregung: es wäre schön, wenn es Instanzen für die verschiedenen EEPs hätte. Damit sollte sich das meiste schon erschlagen lassen. Diese sind herstellerunabhängig.
In den Fällen, in denen der Hersteller etwas am Paket herumbastelt (Eltako ist leider auch einer davon), sollte die Instanz entsprechend anders benannt sein. Aber das nur am Rande.
Ich bin nun selbst ein wenig am probieren, wie man die Daten in die Statusvariable lesen kann. Meine „Opfer“ sind der Hoppe-Fenstergriff und der STM250, denn diese scheinen die einzigen 1Byte-Instanzen für Eno zu sein.
Allerdings ist es mir irgendwie nicht möglich, an die 0x08 heranzukommen, die der Sensor völlig korrekt alle 15min in die Luft wirft…der Status vom Hoppe ist sogar -12.
Ich habe zwar keine Hoppe Fenstergriffe. Es gibt aber eine Instanz dazu. Kannst du diese nicht verwenden?
Für die Ftk reicht doch eine Boolean aus. Es gibt nur offen oder zu. Da passt der STM250 wunderbar.
Die Instanz vom Hoppe ignoriere ich jetzt mal, die passt wirklich nicht (es sind Eltako FTKs im Spiel).
Die Sensoren senden 1BS-Telegramme (ORG = 0x06), dann im DB3 (dem einzigen Byte) eine 0x08, wenn Fenster offen und eine 0x09, wenn Fenster zu. Kann man schön auf dem Gateway tracken, die Daten kommen korrekt.
Edit: da habe ich wohl das DB0 und DB3 verwechselt…siehe weiter unten.
Die STM250-Instanz aktualisiert jedoch nicht. Es steht immer „geöffnet“ da, obwohl der Variablenwert aktualisiert wurde (der Zeitstempel ändert sich brav). Ich vermute mal, dass die Instanz die Daten nicht so interpretiert, wie es vom EEP 06-00-01 gedacht ist, nach dem der FTK sendet.
(Schaut man sich den Original-STM250 an, sieht der optisch sehr ähnlich aus. Leider steht im Datenblatt nicht, welche Daten er genau sendet…)
Daher die Frage: gibts was anderes (ich fürchte nicht) oder was muss ich tun, um die Daten manuell zu modifizieren? Irgendjemand hier hatte scheinbar mal ne Lösung…
Aber nicht die neuen „breiten“ sondern die alten schmalen.
Ich habe eine STM250 Instanz. Dazu mir nur ein eigenes Profil angelegt und gut. Also bei mir kommt true und false da korrekt raus.
Ich habe so ein Problem bei meinen FTS12EM.
Da hilft keine STM250 Instanz, da diese nicht das Gerät findet, sondern nur eine Hoppe Instanz. Diese wertet aber das Protokoll anders aus und zeigt die Zustände in der Integer Variable als -12 und -7
Das Problem mit der Hoppe-Instanz habe ich auch erlebt, dort kam aber konsequenz -12 heraus.
Aber schonmal spannend, dass die STM250 bei dir klappt.
Wäre es möglich, dass du einmal die Daten von deinem Eno-Gateway kopierst und hier reinstellst, wenn einer der FTKs sendet?
Ich habe mir derzeit so beholfen, dass ich eine Dummy-Instanz um „Statusvariablen“ erweitert habe und mit einer Register Variable direkt die Daten vom Gateway lese, ausschneide und dann einfach die Dummyinstanz mit den Daten aktualisiere. Klappt, ist aber irgendwie ein Fusstritt für IPS (Das gleiche mache ich derzeit auch mit dem Helligkeitssensor, um den ganzen Tag an die Dämmerungsmessung ranzukommen.)
Das ist jetzt seeehr spannend, denn die Auswertung dieser Daten ist nicht sehr trivial.
Grundsätzlich gehe ich davon aus, dass IPS die Daten im seriellen Protokoll anzeigt und nicht die der Funkstrecke. Diese haben nämlich nur ein Datenbyte (EEP 2.0, 1BS communication, ORG = 0x06). Im Logauszug sind jedoch 4 Datenbyte dargestellt. Früher wurde das einzige Byte der Funkstrecke im DB3 übermittelt (das ist die 08 in deinem Log), die restlichen Bytes sind ungültig.
Bei uns sieht das anders aus: A5 5A 0B 06 00 00 00 09 00 85 8C 46 01 72. Gleiches EEP (0x06), aber die Daten stehen in DB0. Das erklärt auch, wieso die STM250-Instanz immer nur 0 sieht (und folglich nix damit anfangen kann).
Derzeit vollzieht sich der Wechsel auf die neuen EEP2.1, welche das Datenhandling ein wenig ändern. In Zukunft wird auf dem seriellen Protokoll auch nur noch das DB0 übermittelt. Aus Kompatibilitätsgründen werden die Daten aus den 1BS-Telegrammen ins DB0 geschrieben, auch wenn die anderen DBs noch vorhanden sind.
Ich habe noch keine Ahnung, an welcher Stelle das Problem hier genau entsteht. Die Kommunikation mit anderen 1Byte-Geräten funktioniert scheinbar (PTM200, aber das ist RPS). Als Quelle bleiben also das EnOcean-Ethernet-Gateway oder die Interpretation in IPS.
also erstmal ist dein Post ohne Einstieg in das Protokoll schwere Kost
Also mal eine Erklärung zu meiner Konfiguration:
BSC BOR für den Funk kram. Der Gateway Debugauszug war von einem FTK über das BSC BOR
RS485-USB Adapter direkt am Eltako RS485 Bus. Also eine weitere Serielle Instanz. Da gehen aber auch „nur“ die Protokolle rüber. Diese lese ich dann mittels Cutter usw.
Hier mal ein Auszug eines FTS12EM
08.10.2012 22:59:12.00 | RECEIVED | A5
08.10.2012 22:59:12.00 | RECEIVED | 5A
08.10.2012 22:59:12.00 | RECEIVED | 0B
08.10.2012 22:59:12.00 | RECEIVED | 05
08.10.2012 22:59:12.00 | RECEIVED | 50
08.10.2012 22:59:12.00 | RECEIVED | 00
08.10.2012 22:59:12.00 | RECEIVED | 00
08.10.2012 22:59:12.00 | RECEIVED | 00
08.10.2012 22:59:12.00 | RECEIVED | 00
08.10.2012 22:59:12.00 | RECEIVED | 00
08.10.2012 22:59:12.00 | RECEIVED | 00
08.10.2012 22:59:12.00 | RECEIVED | 0A
08.10.2012 22:59:12.00 | RECEIVED | 00
08.10.2012 22:59:12.00 | RECEIVED | 6A
08.10.2012 22:59:13.00 | RECEIVED | A5
08.10.2012 22:59:13.00 | RECEIVED | 5A
08.10.2012 22:59:13.00 | RECEIVED | 0B
08.10.2012 22:59:13.00 | RECEIVED | 05
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 0A
08.10.2012 22:59:13.00 | RECEIVED | 00
08.10.2012 22:59:13.00 | RECEIVED | 1A
Herstellerwoche muss ich mal schauen. Aber die Anlage rennt hier schon zwei Jahre, also würde ich mal Mitte 2010 sagen.
Ah, ich habe mich schon gewundert, wieso da jedes Byte in einer eigenen Zeile reintropft.
Die Fertigungswoche ist interessant, weil Eltako in seinem Datenblatt ab KW30/2011 erwähnt, dass die Rückmeldung verändert wurde.
Aber nun zu deinen Daten: ich fürchte, das, was Eltako dort implementiert, ist sehr proprietär und entspricht keinem EEP direkt. Also scheitern auch die IPS-Instanzen beim Lesen der Daten.
Ratespiel: du hast den Eingang +E6 angesteuert in deinem Logauszug? (Adresse 0A = 9 + 1, Daten 0x50).
Aber eben, da muss man von Hand ran. Ich gehe davon aus, dass du bereits eine Funktion hast, die die Daten korrekt auswertet?
Hmm. Wo seh ich das? Muss ich mal nen Aktor raus nehmen.
Welcher Eingang das war müsste ich erstmal schauen. Aber ja ich denke die haben für das Gerät das Protokoll verbogen. Daher hätte ich ja auch gerne direktere Elako Überstürzung oder eine Instanz bei der man das Protokoll von aussen konfigurieren kann.
Tja, ich mach das so:
Hoppe Fenstergriff Instanz (da dort eine Integer Variable drin steckt)
Anlernen über suchen: Taster drücken und schon wurde die Instanz gefunden. Daher denke ich ist die Adressierung nicht verbogen!
3.Wolf codiert Und Instanzen angelegt wie im Screenshot
Was passiert dann. Das Script ist so das ich für jeden Taster eine Hoppe Instanz benötige. Diese lege ich alle unter oberste Instanz.
In das Hoppe Modul Lege ich noch eine Dummy Instanz mit den Werten, welche dann für jeden Taster gesetzt werden (Über ein Script). Diese setzt dann den Status true/false für Taster gedrückt und nicht gedrückt.
In der Dauer messe ich die Zeit wie lange gedrückt wurde.
Über den Link lege ich die zu verknüpften Lampen rein. Auch hier musste ich mir den Wolf Code da die Eltako Stromstoss Autoren sich nicht so verhalten wie gewünscht.
Funktioniert alles soweit naja mit reduzierten WAF. Dachte erst ich könnte ohne Bidi. Heute würde ich das nicht nochmal so machen. Tausche aber mal nicht eben 3000 Euro Autoren aus.
Lange ist’s her, aber gestern bin ich auf die Lösung gestossen und die könnte für den ein oder anderen ENO-Benutzer noch interessant sein.
Das Problem betrifft theoretisch alle Sensoren, die 1BS-Telegramme senden, wie z.B. der Türkontakt. Das korrekte EEP dafür ist D5-00-01, welches IPS ja nun auch nativ unterstützt. Interessant ist, dass das Thermokon STC die Daten im DB0 an IPS übergibt, welches aber korrekterweise gemäss ENO-Spezifikation im DB3 stehen müsste. Wechselt man auf das IPS-868-Gateway, welches ESP3 unterstützt, kommen die Daten tatsächlich im DB3 an und die Instanz funktioniert wie gewünscht.
Frage nun an die Community: ist das einfach ein Fehler im STC-Gateway, dass die 1BS-Telegramme an der falschen Stelle übermittelt werden oder muss ich da noch etwas konfigurieren?
Hast es doch selber geschrieben. Du hast das Gateway auf ESP3 umgestellt. D5-00-01 gibt es erst ab ESP3 und ab EEP 2.x.
In den früheren Versionen wurde die Telegramme immer mit einer festen Länge übertragen (glaube 14 Bytes). Daher wurden solche 1BS Telegramme immer mit einer Data-Payload von 4Bytes übertragen.
Ja, das ist richtig, früher gingen immer alle 4 Datenbyte über die Luft. Schade halt, dass das Thermokon-Gw das eine Byte zwar von der Luftstrecke liest, aber dann im „falschen“ DB aufs Netzwerk legt. Damit sind diese sonst sehr guten Gateways irgendwie disqualifiziert.
Ich habe bei Thermokon mal angefragt wegen eines Updates, aber irgendwie waren sie der Meinung, dass das alles so seine Richtigkeit habe.
Und Instanzen angelegt wie im Screenshot