Bekomme FHT 80b nicht gepairt

[patlabor]

Hallo zusammen,

habe gestern mein FHEM mit CSM in Betrieb genommen. Die FS20 Elemente habe ich ohne Probleme mit Autocreate eingerichtet bekommen. Aber irgend wie hapert es mit den FHT teilen. Autocreate hat zwar fast unmittelbar 4 FHT devices angelernt aber ich kann nur Ventilstellung, Wunschtemperatur und Ist-temperatur auslesen. Schalten funktioniert nicht.

Wenn ich den Wiki Eintrag richtig verstehe, ist dies auch normal so, da die FHTs noch gepairt werden müssen. Und genau das funktioniert nicht.

Nachdem ich am FHT80b Cent auf nA stelle setzte ich einen Befehl, versuchsweise "set sz.heizung desired-temp 30", ab. Nach ein paar minuten steht Cent wieder auf "ON", jedoch nimmt der FHT noch immer keine Befehle an.

Leider verstehe ich auch das Namensschema bei FHT nicht wirklich. Autocreate hat die Devices mit FHT_xxxx angelegt. Diese Nummer finde ich leider nicht. Im FHT finde ich nur unter Code eine 5 stellige nummer die ich keinem der FHT Einträge zuordnen kann.

Ich habe die Devices über Ausschlußverfahren zugeordnet und umbenannt. "Wunschthemeratur im Schlafzimmer ist z.Zt. 20° und das Ventil steht auf 12% d.h. FHT_1205 muß das Schlafzimmer sein."

Gibt es hier eine Möglichkeit die Adressen zuverlässig und zweifelsfrei zuzuordnen?

[Ban]

Hallo Patlabor,

Bzgl. des nicht funktionierenden Pairen. Versuch mal die gleiche Prozedur mit Cent auf n/a stellen, aber vergebe vorher mal einen neuen FS20 Code.
Hatte das auch mal und das Ändern des Codes hat bei mir geholfen. Bei mir war es aber nur ein FHT von Mehreren. Ein Versuch ist es aber wert.

Grüsse,
Michael

[Zrrronggg!]

Autocreate hat zwar fast unmittelbar 4 FHT devices angelernt aber ich kann nur Ventilstellung, Wunschtemperatur und Ist-temperatur auslesen. Schalten funktioniert nicht.

Das ist normal. Ohne pairen sind das genau die Werte die man empfangen kann.

Wenn ich den Wiki Eintrag richtig verstehe, ist dies auch normal so, da die FHTs noch gepairt werden müssen.

Exact. Will man auch was an das FHT80b senden, muss man pairen. Wenn man mehrere Funkschnittstellen hat muss man ausserdem das IOdevice auf die Schnittstelle einstellen, mit der man gepairt hat.

Nachdem ich am FHT80b Cent auf nA stelle setzte ich einen Befehl, versuchsweise "set sz.heizung desired-temp 30", ab. Nach ein paar minuten steht Cent wieder auf "ON", jedoch nimmt der FHT noch immer keine Befehle an.

Das ist ungewöhnlich, aber nicht echt selten. Da kann es viele Gründe für geben. Mit denen befassen wir uns, wenn du sicher bist, die Butter und Brot-Sachen richtig gemacht zu haben. Als erstes sei der Hinweis erlaubt, das es durchaus eine Weile dauern kann, bis Befehle ankommen, idR. 2 Minuten. Wenn die Queue deiner Funkschnittstelle (speziell durch viel ausprobieren) schon voll ist, auch wesentlich länger. Wenn du z.B. in deiner Queue durch "ungeduldig rumspielen" schon 8 Befehle oder so hast, kann es sein, das zwar der erste in der Queue erfolgreich pairt aber deine von dir gewünschte Änderung erst 16 (!) Minuten später dran ist.

Leider verstehe ich auch das Namensschema bei FHT nicht wirklich. Autocreate hat die Devices mit FHT_xxxx angelegt. Diese Nummer finde ich leider nicht. Im FHT finde ich nur unter Code eine 5 stellige nummer die ich keinem der FHT Einträge zuordnen kann.

Tja. Das FHT80b selber kennt seine Adresse in 2 Dezimalzahlen, von 0-99. Fhem kenn die Adressen hexadezimal.
Du muss also irgendeinen dez<-> Hexumrechner  (gibts auch als Webseite) nehmen und die Adresse paarweise umrechnen. Beispiel weiter unten.

Gibt es hier eine Möglichkeit die Adressen zuverlässig und zweifelsfrei zuzuordnen?

Klar.

dein  FHT_1205 hat am FHT selber zum Beispiel
hex 12 = dez 18
hex 05 = dez 05

1805

eingestellt. ist zugegeben etwas iritiernd aber bei 4 Dingern hat man's schnell umgerechnet und die Teil richtig benannt.
Habe deine Nachfrage mal zum Anlass genommen den passenden Wikiartikel zu ergänzen:
http://www.fhemwiki.de/wiki/FHT80b#Hinweise_zum_Betrieb_mit_FHEM

Wenn du das gemacht hast, erstmal alle neu pairen (nur um sicher zu gehen), dann an die richtigen Dinger Befehle senden, paar Minuten warten... und dann sehen wir weiter.

Wenn's dann immer noch Probleme gibt, melde dich hier, dann brauche ich aber auch infos zu deiner Funkschnittstelle, also ob das ein CUL ist oder was auch immer. Und wie die FHTs in deiner fhem.cfg angelegt sind bitte dann auch hier posten.

Ansonsten immer mal gut zum Lesen:
http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT
http://www.fhemwiki.de/wiki/Was_ist_der_Hauscode%3F

http://www.fhemwiki.de/wiki/FHT_mit_RFR_CUL_pairen (auch wenn du keine RFR hast auch sinngemäss fürs "normale" Pairen paar Hinweise)

http://www.fhemwiki.de/wiki/FHT80b

Wenn du nicht alles verstehst, erstmal egal. Stell hier ruhig Fragen.


@Ban

Bzgl. des nicht funktionierenden Pairen. Versuch mal die gleiche Prozedur mit Cent auf n/a stellen, aber vergebe vorher mal einen neuen FS20 Code.

Was immer du mit "FS20 Code" meinst: FS20 hat mit FHT *nichts* zu tun.Das sind unterschiedliche Systeme, deren Adressschemata haben NICHTS gemein, nichts was du für FS20 einstellst hat irgendeine Wirkung auf FHT oder FHT80 pairing. Den beiden Protokollen ist NUR gemein, dass sie beide auf einer ähnlichen Funkcodierung beruhen und daher beide im SlowRF Mode von einem CUL/CUNO/FHZ1X00PC empfangen werden können.

Ich VERMUTE, dass du in vielleicht die FHT-ID meinst.
Ich empfehle hier nachzulesen:
http://www.fhemwiki.de/wiki/Was_ist_der_Hauscode%3F

Diese ggf. probeweise mal anders einzustellen kann u.U. tatsächlich nicht schaden, insbesondere weil dann garantiert alle FHTs sicher NICHT MEHR gepairt sind. Im Sinne von "mal sauber von vorne Anfangen" kann das nützlich sein, ja.

[Ban]

Hallo Zrrronggg!,

ja ich meinte die FHT Geräteadresse. Ich hatte im Kopf, dass bei FHT und bei FS20 die gleiche Adressierung bzgl. Haus und Geräte ID verwendet wird.
Hatte ich falsch im Kopf... Den Ausdruck Code habe ich der Einfachheit wegen aus dem FHT Menu übernommen, da dieser hier so benannt ist.

Grüße,
Michael

[Zrrronggg!]

FHT Menu

Was für ein FHT Menu meinst du?

[patlabor]

Hallo,

erstmal danke für die vielen Tipps und Hinweise, aber irgendwie komme ich nicht weiter.

Habe mittlererweile etwas "rumprobiert" aber leider ohne Erfolg.

Was ich allerdings rausgefunden habe ist, das sich die FHTs überhautpt nicht pairen lassen. Z. Zt. laufen die FHTs bei  mir über ein FHT1000. Wenn ich jetzt an einem beliebigen FHT "cent" auf nA stelle, meldet sich scheinbar irgendwann die FHT1000 und pairt sich wieder. Trenne ich die Zentrale vom Netz und nehme die Batterien raus, kann ich danach anstellen was ich will, der FHT bleitbt auf "cent nA" stehen.

Mittlererweile habe ich nach dem Absetzen eines Befehles 2 komplette Nächte abgewartet, leider ohne Erfolg. Daran das ich den Buffer vollgeschrieben habe, kann es also eigentlich nicht helfen.

Als Funkschnittstelle habe ich wie bereits im Eröffnungspost geschrieben ein CSM im Einsatz. Dieses ist durch autocreate so definiert:

define CUL_0 CUL /dev/ttyAMA0@38400 1034

und die FHTs sind wie folgt definiert:

define sz.heizung FHT 1005
attr sz.heizung retrycount 3
attr sz.heizung room FHT
define FileLog_sz.heizung FileLog ./log/sz.heizung-%Y.log sz.heizung
attr FileLog_sz.heizung logtype fht:Temp/Act,text
attr FileLog_sz.heizung room FHT
define SVG_sz.heizung SVG FileLog_sz.heizung:fht:CURRENT
attr SVG_sz.heizung label "sz.heizung Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_sz.heizung room Plots

[Zrrronggg!]

Seufz.

Das du noch eine FHZ1000 am laufen hast ist ja nun eine WESENTLICHE Information, die du uns bisher vorenthalten hast.

Grundsätzlich: Der Betrieb von 2 Zentralen ist... wenig sinnvoll. Entweder FHZ1000 oder FHEM mit CUL.

Solange die FHZ läuft, ist die Chance, das die zuerst was zum FHT sendet mindestens 50:50, da wundert es natürlich NICHT, dass das Pairing mit dem CUL dann eher zufällig klappt.


Mittlererweile habe ich nach dem Absetzen eines Befehles 2 komplette Nächte abgewartet, leider ohne Erfolg. Daran das ich den Buffer vollgeschrieben habe, kann es also eigentlich nicht helfen.


Wenn Befehle im Buffer sind, die an FHTs gehen die mit einer anderen Zentrale gepairt sind, dann hilft es vor neuen Pairingversuchen meiner Erfahrung nach, erstmal das CUL zu resetten. ich habe eigentlich noch nie erlebt, das eine paitingverscuh geglückt ist, wenn VOR dem umstellen des FHT80 auf Cent n/a schon Befehle im Buffer des CUL waren.

Also:
1. FHZ1000 Auschalten
2. CUL Buffer leer machen (am einfachsten ienefach kurz CUL stromlos machen oder Resettbefehel absetzen)
3. FHT auf Cent n/a
4. zu dem FHT einen Befehel setzen, am besten irgendein set desired temp

Eine Sache habe ich allerdigns überlesen:

Funkschnittstelle habe ich wie bereits im Eröffnungspost geschrieben ein CSM im Einsatz.

Was ist ein CSM?

Noch ein paar Anmerkungen:

define sz.heizung FHT 1005

Punkte in Gerätenamen ist eine schlechte Idee, da Punkte in Perl eine Bedeutung haben.

attr sz.heizung retrycount 3

Diese Zeile hat in deinem Setup keine Wirkung, kannst du weglassen.

[patlabor]

Wie gesagt, das die FHZ1000 das Problem sein könnte, habe ich mir auch schon gedacht und sie daher ja auch vom Netz genommen. Hat allerdings wie geschrieben nichts gebracht.

Die Zentrale ist z.Zt komplett aus dem Spiel raus.

Aber irgendwie bleiben die Befehle im Buffer hängen. Habe mittlererweile die alten FHTs aus fhem gelöscht und über autocreate nochmal neu angelernt. Das FHT mit dem ich z. Zt experimentire heisst jetzt einfach FHT_1005 und steht auf cent nA.

versuche ich dann den FHT per "set FHT_1005 desired-temp 22" zu pairen passiert leider nichts.

mittlererweile habe ich rausgefunden, das ich mir mit get CUL raw T02 den Bufferinhalt anzeigen lassen kann, dort steht jetzt schon seit 20 min
CUL raw => 1005:412C

Was das CSM ist ist eigentlich im wiki ganz gut erklärt: http://www.fhemwiki.de/wiki/Raspberry_Pi:_CSM

[Zrrronggg!]

Aber irgendwie bleiben die Befehle im Buffer hängen.

Klar, im Befehlsbuffer des CUL bzw CSM (das läuft unter culfw. Ich kannte da bisher nur das COC, ist offenbar ähnlich. Für unsere belange so gut wie ein CUL, ausser dass man es nicht so leicht stromlos machen kann.)
Den Befehlsbuffer musst du löschen.
Da du das CSM nicht stromlos machen kannst, musst du den passenden Befehl absetzen.

Guckst du hier:

http://www.fhemwiki.de/wiki/CUL


findest du:

Inhalt des FHT Buffers
get myCUL raw T02 (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer

Wenn der nicht n/a ist, wirds nicht gehen.

Zum Restten findest du:

Reboot / Reset des CUL:
set myCUL raw B00

Ausserdem ginge noch
set CUL raw T01 <FHT-ID>
Dadurch wird NUR der FHT Buffer gelöscht.

Habe mittlererweile die alten FHTs aus fhem gelöscht und über autocreate nochmal neu angelernt.

Das war eher nicht nötig.

Das FHT mit dem ich z. Zt experimentire heisst jetzt einfach FHT_1005 und steht auf cent nA.

Okay. Meine Anleitung aus dem letzten Post befolgt?

1. FHZ1000 Auschalten
2. CUL Buffer leer machen (am einfachsten ienefach kurz CUL stromlos machen oder Resettbefehel absetzen)
3. FHT auf Cent n/a
4. zu dem FHT einen Befehel setzen, am besten irgendein set desired temp

1. Check
2. ??
3. Check
4. ??

2. und 4 bitte auch machen, dabei Reihenfolge bachten, und dann hier berichten, okay?

[patlabor]

Hallo nochmal,

irgendwie scheinen wir aneinander vorbei zu schreiben.

Hier noch einmal genau jeden schritt den ich mache.

1. FHZ1000 stromlos machen
2. Batterien aus FHT raus und 10min warten (vermutlich unnötig aber zur Sicherheit trotzdem)
3. überprüfen ob der CUL Buffer lehr ist: get CUL raw T02 wenn n/A alles ok. ansonsten mache ich momentan einfach einen reboot am raspberry ist wohl overkill aber ich will wirklich auf Nummer sicher gehen. danach  nochmal testen ob der buffer auch wirklich leer ist.
4. Batterien wieder in den FHT, warten bis der count down abgelaufen ist (der wird übrigens auch in fhem angezeigt, also scheint die Funkverbindung ja zu stehen.
5. Prog Taste halten im Menue cent auf n/A stellen und nochmal mit Prog bestätigen.
6. mit fhem den befehl "set FHT_1005 desired-temp 22" absetzen.
7. nochmal in den buffer schauen ob auch wirklich was drinsteht. im meinem fall dann CUL raw => 1005:412C
8. fünf minuten warten
9. an der FHT schauen ob sich was getan hat, steht dann immer noch auf cent nA
10. in den buffer schauen: immer noch CUL raw => 1005:412C
11. nochmal fünf minuten warten.
12. zurück zu 9.

das ist ungefähr das was ich jetzt seit 2 tagen ausprobiere, aber leider ohne erfolg.

[rudolfkoenig]

Vermutlich wird dann Zeit debugging auf culfw Ebene mit "set CUL raw X61" einzuschalten, und die Uebertragung per "inform timer" oder "Event log" zu verfolgen, siehe auch http://www.fhemwiki.de/wiki/FHT80b

[Zrrronggg!]

Okay, du hast alles richtig gemacht. 

Als nächstes: Rudis Vorschlag.  Nachsehen ob überhaupt Kommunkaton stattfindet bzw versucht wird.

Wenn's dazu Fragen gibt immer her damit.

[patlabor]

Habe jetzt mal versucht eueren Tip nachzuvollziehen. Um die Ausgabe etwas zu begrenzen habe ich zusätzlich zur FHZ alle FHT ausser einem Stromlos gemacht.
Über Telnet ist die Ausgabe nicht wirklich zu gebrauchen, der Text ist irgendwie "versetzt", unübersichtlicht und nur schwer zu lesen. Über den Eventlog geht es aber einwandfrei.

Hier ist das Ergebnis:

2014-01-14 10:28:22 FHT FHT_1005 actuator: 6%
2014-01-14 10:28:22 FHT FHT_1005 start-xmit: 100
2014-01-14 10:28:22 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:28:23 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:28:23 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:28:23 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:28:34 FHT FHT_1005 desired-temp 22
2014-01-14 10:28:36 PRESENCE HTPC absent
2014-01-14 10:28:44 PRESENCE darkness absent
2014-01-14 10:28:59 PRESENCE HTPC absent
2014-01-14 10:29:20 PRESENCE darkness absent
2014-01-14 10:29:23 PRESENCE HTPC absent
2014-01-14 10:29:46 PRESENCE HTPC absent
2014-01-14 10:29:57 PRESENCE darkness absent
2014-01-14 10:30:09 PRESENCE HTPC absent
2014-01-14 10:30:19 FHT FHT_1005 actuator: 6%
2014-01-14 10:30:20 FHT FHT_1005 start-xmit: 100
2014-01-14 10:30:20 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:30:20 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:30:20 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:30:21 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:30:32 PRESENCE HTPC absent
2014-01-14 10:30:33 PRESENCE darkness absent
2014-01-14 10:30:55 PRESENCE HTPC absent
2014-01-14 10:31:09 PRESENCE darkness absent
2014-01-14 10:31:18 PRESENCE HTPC absent

hier habe ich gemerkt, das der Buffer leer ist, das FHT allerdings immer noch nicht reagiert, habe dann einfach nochmal den Befehl abgesetzt:

2014-01-14 10:31:33 FHT FHT_1005 desired-temp 22
2014-01-14 10:31:41 PRESENCE HTPC absent
2014-01-14 10:31:45 PRESENCE darkness absent
2014-01-14 10:32:04 PRESENCE HTPC absent
2014-01-14 10:32:17 FHT FHT_1005 actuator: 6%
2014-01-14 10:32:17 FHT FHT_1005 start-xmit: 100
2014-01-14 10:32:17 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:32:18 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:32:18 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:32:18 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:32:21 PRESENCE darkness absent
2014-01-14 10:32:28 PRESENCE HTPC absent
2014-01-14 10:32:51 PRESENCE HTPC absent
2014-01-14 10:32:57 PRESENCE darkness absent


der Buffer bleibt jetzt leer, ohne das ich etwas verändert hätte (habe lediglich ein mal set CUL raw T01 1005 den Buffer geleert), der FHT reagiert jedoch immer noch nicht und zeigt immer noch "cent nA" an

[rudolfkoenig]

2014-01-14 10:30:20 FHT FHT_1005 start-xmit: 100

100 bedeutet, dass das FHT auf n/A steht.

2014-01-14 10:30:20 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:30:20 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:30:20 FHT FHT_1005 FHZ:start-xmit: 100
2014-01-14 10:30:21 FHT FHT_1005 FHZ:start-xmit: 100

Sehr komisch: ein FHZ/culfw sollte nie mit 100 antworten.
Wie ist das FHT-Code bzw. wie ist das CUL definiert?

[patlabor]

FHT-Code ist 1034 und der CUL ist so definiert: define CUL CUL /dev/ttyAMA0@38400 1034