FHT Unknown device - please define it

Begonnen von ChrisF, 16 Februar 2013, 12:00:25

Vorheriges Thema - Nächstes Thema

ChrisF

Hallo,

ich setze seit einigen Tage mein erstes FHT 8V-3 Thermostatventil ein und habe nun ein kleines Problem damit.

Zu meinem Setup:
Ich nutze FHEM in der neuesten Version (mache auch regelmäßig 'update') auf einer Fritz!Box 7390.
An zusätzlicher Hardware habe ich einen CUL V3 868MHz, einen CUNO 868MHz und ein HomeMatic LAN Interface im Einsatz.

Zur Steuerung des FHT 8V-3 benutze ich das PID Modul im Zusammenhang mit einem S300TH.
Das funktioniert alles soweit gut, das Stellventil erhält entsprechende Steuersignale und führt diese aus.

Hier mein Code:
-----
define CUL_0 CUL /dev/ttyACM0@9600 1234
define CUNO CUL 192.168.1.5:2323 6627
#########################################################################
## Definition Thermostat Wohnzimmer Südfenster
#########################################################################
define wz_ThermostatSueden FHT8V 6727 CUNO
attr wz_ThermostatSueden room Heizungen

#########################################################################
## Definition Heizung Wohnzimmer Südfenster
#########################################################################
define wz_HeizungSueden PID Temp_Wohnzimmer wz_ThermostatSueden
attr wz_HeizungSueden alias wz_HeizungSueden_pid
attr wz_HeizungSueden room Heizungen

#########################################################################
## Definition und Anzeige des Sollwertes für Heizung Wohnzimmer Süden
#########################################################################
define wz_HeizungSueden_desired_temp dummy
attr wz_HeizungSueden_desired_temp fp_Grundriss_EG 190,550,2,Wunschtemperatur
attr wz_HeizungSueden_desired_temp room Heizungen
attr wz_HeizungSueden_desired_temp setList state:19,20,21,22,23,23.5,24
attr wz_HeizungSueden_desired_temp webCmd state
### Der Notivy steuert das Zusammenspiel Änderung im Floorplan und Weitergabe an FHEM
define Change_wz_HeizungSueden notify wz_HeizungSueden_desired_temp  {\
    my $neuer_wert = ReadingsVal("wz_HeizungSueden_desired_temp","state","0") ;;\
    fhem("set wz_HeizungSueden desired $neuer_wert");;\
}
-----

Ich will das Thermostatventil primär über meinen CUNO steuern, da dieser sich in unmittelbarer Nähe befindet.

Nun mein Problem:
Ich erhalte in Abständen von einigen Minuten regelmäßig die Einträge:
-----
2013.02.16 11:53:22 3: FHT Unknown device 6727, please define it
2013.02.16 11:53:22 2: autocreate: define FHT_6727 FHT 6727
2013.02.16 11:53:22 1: FHT_6727: CODE collides with the FHTID of the corresponding CUL
-----

Sobald ich den CUL abziehe verschwinden die Fehlermeldungen.

Ich habe bereits einen reset des CUL mittels "set CUL_0 raw e" durchgeführt.

Außerdem nimmt der FHT 8V-3 bei eingestecktem CUL mit den produzierten Fehlermeldungen irgendwann keine Signale mehr an.

Kann eventuell jemand helfen?

Vielen Dank im voraus!

rudolfkoenig

Interessantes Problem, ich fuerchte das wurde bisher nicht beachtet.

- CUL1 (hier CUNO) sendet Befehl an das FHT8v
- CUL2 (hier CUL_0) empfaengt es, und will es als "FHT80b" in FHEM definieren. Hat dabei keine Ahnung, dass es kein "echter" 80b ist, sondern FHEM selbst.
- Beim Anlegen der neuen "FHT80b" wird CUL1 (das zuletzt definierte Geraet) per default als IODevice zugewiesen. Um Probleme im FHT8v Betrieb zu vermeiden, prueft FHEM die IDs, und verweigert das Anlegen.
- Beim der naechsten Meldung in 2 Minuten geht das Ganze von vorne los.

Hab gefixed und eingecheckt, fix ab morgen per update verfuegbar.

Workaround: CUNO vor dem CUL_0 definieren, und alle FHT8v's per IODev Attribut dem CUNO zuweisen.

ChrisF

Vielen Dank für die prompte Reaktion und Hilfe!
Ich habe den Workaround implementiert und erhalte nun keine Fehlermeldungen mehr.
FHEM hat per Autocreate einmal erfolgreich ein neues device "FHT_6727" erstellt.

Allerdings habe ich nach wie vor das Problem, dass das Thermostatventil FHT 8V-3 bei gestecktem CUL nur einige Male Stellbefehle durchführt und dann irgendwann damit aufhört (meistens so 2-5).
Wenn ich den CUL abziehe, dann läuft es durch. Zumindest läuft es jetzt schon wieder ohne CUL einige Stunden problemlos.

Gibt es hierzu eventuell noch Theorien? Kann vielleicht auch ein Defekt des FHT 8V-3 vorliegen?

Vielen Dank und Gruß!

ChrisF

Hallo nochmal,

muss mich korrigieren. Auch ohne gestecktem CUL hat das FHT V8-3 nun seinen Dienst eingestellt.

Gruß!

rudolfkoenig

Das klingt danach, dass das CUNO out-of-sync kommt, d.h. zu spaet seine Pakete sendet.

Von Hoerensagen: die IR Routinen im CUNO koennten dafuer veranwortlich sein, da sie mit einem hohen Frequenz am pollen sind. Ob OneWire auch sowas macht, weiss ich nicht.
Ich wuerde eine Version ohne IR und OW uebersetzen, und pruefen ob daran liegt. Oder mit dem CUL testen.

ChrisF

Hallo,

danke für den Hinweis!
Habe danach gezielt gesucht aber das übersteigt im Moment irgendwie meine Fähigkeit.
Also ich weiß nicht, wie ich die aktuelle Firmware 1.52 so verändern kann, dass IR abgeschaltet ist auf dem CUNO (das brauche ich nämlich defintiv nicht).
Wäre wirklich sehr dankbar über einen Hinweis, wie ich das bewerkstelligen kann oder wo ich da eventuell etwas zu nachlesen könnte...

Vielen Dank aber auf jeden Fall schon einmal für alle bisherigen Hinweise und für die neue FHEM Version!!

rudolfkoenig

In board.h muss wohl HAS_IRRX usw. auskommentiert werden.

http://culfw.de/commandref.html enthaelt Hinweise zum Uebersetzen, es kann aber die Moeglichekeiten eines Anfaengers uebersteigen.

Ich sehe gerade, dass ungefaehr ab culfw version 1.50 HAS_IRRX in CUNO2 nicht mehr aktiviert ist, d.h. in der aktuellen Version von culfw.de (1.52) sollte es auch deaktiviert sein.

ChrisF

Hallo,

also der Tipp mit der neuen CUNO Firmware war anscheinend Gold wert!
Ich habe den CUNO gestern auf 1.52 geflashed und seit dem wird der FHT 8V-3 fehlerfrei angesteuert!

Nochmals herzlichen Dank!