FHT80B "Sicherheitscode" auslesen?

[zauberfee]

Hallo,
auch auf die Gefahr hin mich als Esel zu outen-
seit einiger Zeit versuche ich erfolglos mit einem FHT80B und einem FHT8V zu kommunizieren.
Nachdem ich viele Anleitungen und Problemlösungen gelesen habe fange ich noch einmal ganz von vorne an.
Der FHT8V gehört zum FHT80B- sind beide separat gekauft worden- und meldet sich beim Einlegen der Batterien mit "18" und "52".
Nun würde ich gerne den Sicherheitscode des FHT80B auslesen. Beim ersten Start habe ich einst versäumt diesen aufzuschreiben.
Wie mache ich das?

Danke im Voraus,
Tim

[bergadler]

Hallo,

entweder die Batterien im Thermostat nochmal neu einlegen.
Nach Eingabe Datum/Uhrzeit kommt der "Sync" mit der Zentrale bzw. FHEM,
wobei dann links unten im Display der Code erscheint.

Oder (eigentlich braucht man ihn auch überhaupt nicht zu wissen) einen neuen "Sync"
des Ventilantrieb mit dem Themostaten anstoßen.
Dabei bekommt der Antrieb den Code vom Thermostaten zugeteilt.
(FHT80B Bedienungsanleitung Punkt 3.9.5 "An A")

Gruß

[zauberfee]

Hallo bergadler,

danke für deine Hilfe.
Ich habe mich vielleicht falsch ausgedrückt-
die Kommunikation zwischen FHT80B und FHT8V funktioniert.
Die Kommunikation mit FHEM auf der Fritzbox (mit CUL868) funktioniert überhaupt nicht.
Mittlerweile findet die FHEM den FHT80B nicht mehr automatisch. Der FHT8V wird gefunden, doch ist nicht ansprechbar.

Irgendwie ist da der Wurm drin. Werde um meine Probleme etwas exakten beschreiben zu können morgen (äh gleich...) den CUL-Stick  an meinen neuen Pi hängen und gucken was dort passiert.

[stromer-12]

Im FHT80b Kommunikation mit Zentrale auf "on" gesetzt und anschliessend einen Befehl an den FHT gesendet?

[zauberfee]

Die Kommunikation mit FHEM auf der Fritzbox (mit CUL868) funktioniert überhaupt nicht.
Mittlerweile findet die FHEM den FHT80B nicht mehr automatisch.

So, mittlerweile etwas weiter, aber nicht schlauer.
Umzug auf PI war problemlos. IT-Komponenten & FS20-Komponenten funktioniert, Milight devices funktionieren (halbwegs).

Culstick sieht anscheinend den FHT80B-

2015.02.03 15:10:21 3: FHT Unknown device 1234, please define it
2015.02.03 15:10:21 2: autocreate: define FHT_1234 FHT 1234
2015.02.03 15:10:21 1: FHT_1234: CODE collides with the FHTID of the corresponding CUL
2015.02.03 15:10:21 1: define FHT_1234 FHT_1234 FHT 1234: FHT_1234: CODE collides with the FHTID of the corresponding CUL
2015.02.03 15:10:21 1: ERROR: FHT_1234: CODE collides with the FHTID of the corresponding CUL

, hat aber ein Problem. Verstehe das nur nicht, denn der Culstick ist so definiert:

define CUL_0 CUL /dev/ttyACM0@9600 1034

Gruß,
Tim

[Zrrronggg!]

Ich muss zugeben, ich verstehe das Problem nicht und die Fehlermeldung auch nicht.

Bitte leg doch das FHT80 mal per Hand an.
Denke daran, das die Adresse in FHEM in HEX angegeben werden muss.
D.H du musst den Code den du nach dem einlegen der Batterien im FHT ablesen kann PAARWEISE in Hex umrechnen.
Das FHT zeige z.b. an

022
044


Dann ist die Adresse die man in FHEM anlegen muss
22 in HEX = 16
44 in HEX = 2c

Also

Code Auswählen Erweitern

define heizung1 FHT 162c

Details dazu hier
http://www.fhemwiki.de/wiki/FHT80b
ider auch hier
http://www.fhemwiki.de/wiki/FHT_mit_RFR_CUL_pairen
(Umrechnungstabellen oder automatische rRechner gibts zuhauf im Netz.)

Nach der Einrichgtung cfg sichern und dann stellst du das FHT auf  "cent" n/a

(nicht wie oben gepostet auf ON)

und sendest einen Befehl. (irgendeinen)

Fertig. (Kontrolle: cent muss von selbst von n/a auf ON gesprungen sein, dann hat's geklappt)

[zauberfee]

Hallo Zrrronggg,
danke für deine Antwort.
ich habe nicht verstanden, warum es da eine Kollision der FHTIDs gab.

define FHT_1234 FHT 1234
attr FHT_1234 IODev CUL_0

erscheint mir insofern richtig, als dass der Sicherheitscode des FHT8V 18 und 52. Das wäre dann umgerechnet 1234. Das ist aber der Sicherheitscode des FHT8V. Der FHT80B sollte doch auch einen eigenen haben? Dieser stimmt (wahrscheinlich) nicht mit des FHT8V überein, denn beide Geräte sind NICHT in einem Set gewesen. Trotzdem funktioniert die Kommunikation zwischen beiden Geräten.

Ich habe den Culstick mal anders definiert.

define CUL_0 CUL /dev/ttyACM0@9600 0000

Nun gibt es nicht mehr die unten angegebene Kollision. Mir war nicht klar, ob ich die FHTID des Culstick einfach ändern darf. Zumindest funktionieren nun die ITs und FS20s und die milights immer noch.

Ich habe mal nen Screenshot des angelegten Heizungsdevice angehängt.
Das ist aber das einzige Heizungsdevice was automatisch angelegt wurde.
Bis jetzt habe ich gedacht es wäre der FHT80b. Ist das auf dem Screenshot erkennbar?
Sollten nicht beide Heizungsdevices automatisch erscheinen?


Nach der Einrichtung cfg sichern und dann stellst du das FHT auf  "cent" n/a

Habe ich schon ein Dutzend mal probiert. Hat leider nie funktioniert.
Irgendwie ist da etwas im Argen und ich komme nicht drauf.

Gruß,
Tim

[Zrrronggg!]

Ich benutze kein autocreate und weiss daher nicht genau was da passiert. Oder vielleicht doch.

Ferner scheinen mir hier auch Begrifflichkeiten durcheinanderzulaufen, sodass ich manchmal einfach nicht weiss was du meintest. Und mir ist eigentlich auch eben erst klar geworden was dein Problem und was die Ursache ist.

Ich versuche mal zuerläutern so gut ich kann:

ich habe nicht verstanden, warum es da eine Kollision der FHTIDs gab.

Ich weiss nicht ob es sowas überhaupt gibt, wenn man nur ein CUL hat. Die Fehlermeldung spricht auch nicht von Plural sondern von "with the FHTID" (singular)
Thema ist, dass die FHT-ID quasi der Sicherheitscode des CUL ist.

Zur Begrifflichkeit: Die FHT-ID ist die Adresse, die ein CUL/CUNO/FHZ bekommt.
Dies kann man in FHEM frei festlegen. Sie hat 2x2 Stellen. (2 Wertepaare von hex00-62, entsprechend dezimal 0-99). Eine Installation hat je Funkschnittstlle nur EINE FHT-ID.

Ein Collison der FHT-IDs (Plural) ist also nur möglich, wenn du ZWEI CULs oder sowas hast. Wenn es hier ein Collision gibt wird diese NICHT von FHEM als Fehler ausgegeben(!)

Wenn du nur ein CUL hast gibt es nur eine FHT-ID.

Wärend die FHT-ID die Adresse der FEHM Funkschnittstelle ist, ist die Adresse der FHT80b der "Sicherheitscode" oder auch nur "Code" oder "FHT80 -Adresse".

In den Internals eines FHT80b wird dies in "Code" und "def" ausgegeben. Warum doppelt ist mir eigentlich nicht klar, aber beide Einträge sind immer gleich und enthalten den Sicherheitscode des FHTs in hex.
Man den Sicherheitscode eine FHT80b übrigens FREI EINSTELLEN mit der Funktion "sond/code".

Dannach muss man aber sowohl in FHEM als auch in den Ventilantrieben den Code ebenfalls anpassen, jeweils durch neues pairen.


Der Knackpunkt ist aber, das FHT-ID auf der einen Seite und Sicherheitscode auf der anderen Seite beides nur Namen für Adressen im selben Adressschema des FHT Protokolls sind. Mehr dazu gleich.

define FHT_1234 FHT 1234
attr FHT_1234 IODev CUL_0

Wenn du nur ein CUL hast ist die Definition des IODev überflüssig übrigens.

erscheint mir insofern richtig, als dass der Sicherheitscode des FHT8V 18 und 52. Das wäre dann umgerechnet 1234.

Stimmt.

Das ist aber der Sicherheitscode des FHT8V.

Das wollen wir schwer hoffen!

Der FHT80B sollte doch auch einen eigenen haben? Dieser stimmt (wahrscheinlich) nicht mit des FHT8V überein, denn beide Geräte sind NICHT in einem Set gewesen. Trotzdem funktioniert die Kommunikation zwischen beiden Geräten.

Die FHT8v haben keinen fest eingestellten Code, sondern dieser wird meines Wissens im Moment des Anlernens des FHT8v vom FHT80b übertragen. Zwar sind alle FHT8v mit irgendeinem Code ab Werk versehen und - wenn sei als SET gekauft werden - ist der Code absgestimmt. D.H. er IST in einem SET gleich. Wenn man die Geräte aber getrennt kauft oder den Sciherheitscode des FHT nachträglich ändert, muss man expliziet den Code des FHT80b auf das FHT8v übertragen, sonst reagiert das nicht auf das FHT. Das Prozeder dazu ist in der Aleitung des FHT8v beschrieben (Stromlos machen und dann Taste in bestimmter Reihenfolge drücken und dann Befehl senden).

D.H. Doch, der Sicherheitscode eines FHT und aller an ihm angelernten Ventilantriebe ist immer gleich!

Ausserdem: Das FHT8v braucht keine ECHTE eigene Adresse, den kommuniziert nicht bidirectional. Es kann nur empfangen. Es muss daher eigentlich nur wissen, wie der Siciherheitscode des FHT80b ist auf dessen Befehle es reagieren soll. Daher wird der Code einfach übertragen.

define CUL_0 CUL /dev/ttyACM0@9600 0000

Du hast dem CUL nun die FHT-ID 0000 zugewiesen. Diese hat als einzige ein besondere Funktion, nämlich: "Nicht an der FHT-Kommuniaktion aktiv teilnehmen!"
D.H. dein CUL empfängt jetzt zwar noch FHT80b Signale, kann aber nichts mehr senden und man kann FHT8b auch nicht mehr mit dem CUL pairen. D.H. du kannst zwar z.B. sehen welche Temperatur am FHT80b eingestellt ist, aber diese nicht mehr ändern.

Nun gibt es nicht mehr die unten angegebene Kollision.

Ja klar, aber auch sonst dürfte nicht mehr viel gehen.

Mir war nicht klar, ob ich die FHTID des Culstick einfach ändern darf.

Doch, dass muss schon deswegen gehen, weil man ja  - falls man mehrere CULs hat - diesen jeweils andere FHT-IDs geben können muss.

Zumindest funktionieren nun die ITs und FS20s und die milights immer noch.

Die haben mit der FHT-ID *nichts* zu tun. Denen ist es schnurzegal ob und wenn ja welche FHT-ID du dem CUL gibst. Das sind andere Protokolle, die keine echtes pairing kennen und daher hat die Funkschnittstelle auch keine eigene Adresse (die FHT-ID ist wie gesagt im Grunde die Adresse des CUL in der Kommunikation mit den FHTs)

Ich habe mal nen Screenshot des angelegten Heizungsdevice angehängt.
Das ist aber das einzige Heizungsdevice was automatisch angelegt wurde.

Weiviel FHT80bs hast du denn? Soweit ich verstanden habe hast du doch nur eines.

Bis jetzt habe ich gedacht es wäre der FHT80b.

Ja, ist es doch auch.

Sollten nicht beide Heizungsdevices automatisch erscheinen?

Definiere mal "Heizungsdevice". Was meinst du damit?
Wenn du damit ausdrücken willst, das du das FHT80b und das FHT8v sehen müsstest: Nein.
Im Normalfall sieht man NUR das FHT80b, die daran gekoppelten Ventiltriebe sind nur in den actuator readings indirect erkennbar. FHEM kann das FHT8v auch nicht sehen, denn das FHT8v sendet nichts!

Nach der Einrichtung cfg sichern und dann stellst du das FHT auf  "cent" n/a
Habe ich schon ein Dutzend mal probiert. Hat leider nie funktioniert.

Was hat denn GENAU nicht funktioniert?

Also eigentlich ist soweit ich das sehe alles in Butter bei dir. Einzig iritiernd ist dieses:

CODE collides with the FHTID of the corresponding CUL

Diese Meldung habe ich noch nie gesehen, daher stand ich am Anfang auch auf dem Schlauch. Aber eigentlich ist das klar: Ich interpretiere die so, dass die FHT-ID des CUL tatsächlich nicht gleich eines der  FHT80b devices sein darf die in der selben Funkwolke sind. Da das Format der Adressen gleich ist, wäre das zu erwarten, ich habe nur nirgends je gelesen, dass das so ist und bisher angenommen, dass obwohl das Format gleich ist, die FHT-ID (also die Adresse des CUL) sich irgendwie noch Unterscheidet vom Sicherheitscode des FHT80b (also die Adresse des FHT80b).
Das wäre aber nur nötig um genau so Konflikte aufzulösen.

Die Chance, dass das zufällig gleich ist ist auch recht klein, etwa 1:10.000, da hat man sich vielleicht gedacht: Ach für die paar Fälle machen wir uns nicht die Mühe zwei Typen von Adressen zu definieren.

Die Lösung ist aber super einfach und du bist im Prinzip schon drauf gekommen: Entweder dem CUL eine andere FHT-ID geben (aber *nicht* 0000) oder dem FHT80b per sond/code eine andere FHT-ID geben.
Dannach neu anlernen (cent/n/a etc.etc)
Fertig.

Wenn du die FHT-ID des CUL änderst hast du weniger Arbeit, weil du dann nur das FHT80b neu pairen musst und den Ventiltrieb nicht.

Ich hoffe es wird jetzt klarer.

Meiner Aufassung nach hast du zusammenfassend 4 Problem gehabt:
1. Das Pech, das die von dir gewählte FHT-ID mit einer Chance von 1:10.000 leider genau der Sicherheitscode deines einzigen FHT80b war
2. Das mir und offenbar auch anderen Lesern deines Posts das noch nie untergekommen war und wir daher nicht direkt drauf gekommen sind
3. Du fälschlich angenommen hast , die FHT8v müssten eine eigene Adresse haben
4. Du fälschlich angenommen hast , die FHT8v würden als eigene Device in FHEM durch Autocreate angelegt.

[zauberfee]

So!
Es läuft!
Ein Riesen Dankeschön für deine ausführlichen Erläuterungen!
Das Ändern der FHTID des Culsticks war die Lösung.

Das Lesen deiner Antwort hat wohl länger gedauert als die bidirektionale Verbindung zum FHT80 herzustellen.

Wie du schon geschrieben hast sind da ein paar Probleme (und ein Anfänger) zusammengekommen.
Die ominöse Kollision der FHT-ID und dann mein Volltreffer bei der freien Wahl der FHT-ID des Culsticks. Als ich deine Erklärung dazu las fiel mir ein, dass ich beim Lesen von unzähligen Beiträgen diese Einschränkung schon gelesen (und leider wieder vergessen) hatte.
Ich hatte bei den ersten Versuchen (vor Monaten) nach der Installation der Heizungskomponenten zwei Geräte anngezeigt bekommen und war von da an davon ausgegangen, dass es FHT80B UND FHT8V gewesen wären.
Im Nachhinein wird mir klar, dass es der Vorgänger des FHT80B gewesen sein muss. Besagten FHT8R2 hatte ich vorher in Gebrauch und zwar schon abgebaut, aber evtl die Batterien nicht sofort raus genommen. Und den hat FHEM dann direkt mal angelegt...

ENDLICH gelöst!

VG,
Tim