Keine Temperaturdaten von FHT80b

[David Johnstone]

Tja, bin jetzt auf dem nächsten Problem gestossen,
meine Raumregler liefern keine Temperatur:-

server1:/data/download/fhem-4.1/webfrontend # fhem.pl 7072 "list lo"
Internals:
CODE 6623
DEF 6623
NAME lo
NR 4
STATE ???
TYPE FHT
IODev FHZ
Attributes:

server1:/data/download/fhem-4.1/webfrontend #

Woran könnte das liegen? Auf dem Display
zeigen die Temperatur, sie regeln auch richtig.
Es liegt auch nicht am Empfang, gleiches Ergebniss egal
ob die direkt neben dem FHZ1300 oder zwei Stockwerke
nach oben liegen.

Nochmals danke an den Experten!
David

[Gerhard Pfeffer]

Ich würde einmal den Versuch starten und mit dem Befehl

"set ${devicename} refreshvalues"

die Daten von den FHTs zurück zu bekommen. In den meisten Fällen führt das schon einmal zum Erfolg.

[David Johnstone]

Hi Gerhard,
danke für den Tipp, leider scheint es nicht geholfen
zu haben:-

server1:/data/download/fhem-4.1/webfrontend # fhem.pl 7072 "set lounge
refreshvalues"

server1:/data/download/fhem-4.1/webfrontend # fhem.pl 7072 "list

lounge"

Internals:
CODE 6623
DEF 6623

NAME lounge

NR 4
STATE ???
TYPE FHT
IODev FHZ
Attributes:

In dem logfile steht zu dem Vorgang:-

2007.11.25 16:17:37 4: Connection accepted from 127.0.0.1:34493
2007.11.25 16:17:37 5: Cmd: >set lounge refreshvalues<
2007.11.25 16:17:37 2: FHT set lounge refreshvalues
2007.11.25 16:17:37 5: Sending 810b04d8020183662365ff66ff
2007.11.25 16:17:38 5: Sending 8105044fc90185
2007.11.25 16:17:39 5: Triggering lounge
2007.11.25 16:17:39 5: lounge trigger: Checking FHZ for notify
2007.11.25 16:17:39 5: lounge trigger: Checking bath for notify
2007.11.25 16:17:39 5: lounge trigger: Checking bathlog for notify
2007.11.25 16:17:39 5: lounge trigger: Checking bedroom for notify
2007.11.25 16:17:39 5: lounge trigger: Checking bedroomlog for notify
2007.11.25 16:17:39 5: lounge trigger: Checking fhz_timer for notify
2007.11.25 16:17:39 5: lounge trigger: Checking global for notify
2007.11.25 16:17:39 5: lounge trigger: Checking lounge for notify
2007.11.25 16:17:39 5: lounge trigger: Checking loungelog for notify
2007.11.25 16:17:39 5: lounge trigger: Checking wz_refresh for notify
2007.11.25 16:17:39 5: Cmd: >quit<
2007.11.25 16:17:39 4: Connection closed for 127.0.0.1:34493
2007.11.25 16:17:39 5: FHZ/RAW: 8107c9b7010285012e (Unparsed: )
2007.11.25 16:17:39 4: FHZ FHZ fhtbuf: 2e)
2007.11.25 16:17:42 4: Connection accepted from 127.0.0.1:34494
2007.11.25 16:17:42 5: Cmd: >list lounge<
2007.11.25 16:17:42 5: Cmd: >quit<
2007.11.25 16:17:42 4: Connection closed for 127.0.0.1:34494

[Gerhard Pfeffer]

Sorry - hatte vergessen zu erwähnen, dass es bis zu 10 Minuten dauern kann, bis du Daten von den einzelnen Geräten zurück erhältst. Schau noch einmal im Logfile nach, ob nicht doch noch Daten zurück gekommen sind.

On Nov 25, 2007 4:21 PM, David Johnstone <davi...@mail.com> wrote:

Hi Gerhard,
danke für den Tipp, leider scheint es nicht geholfen
zu haben:-

server1:/data/download/fhem-4.1/webfrontend # fhem.pl 7072 "set lounge
refreshvalues"

server1:/data/download/fhem- 4.1/webfrontend # fhem.pl 7072 "list

[David Johnstone]

> Sorry - hatte vergessen zu erwähnen, dass es bis zu 10 Minuten dauern kann,
> bis du Daten von den einzelnen Geräten zurück erhältst. Schau noch einmal im
> Logfile nach, ob nicht doch noch Daten zurück gekommen sind.

Danke, aber leider nein, ich beobachte seit vielen Stunden jetzt.
Ich habe auch mal den Server neu gestartet, und auch versucht
ein FHT80b neu zu synchronisieren (freigeben) mit dem FHZ1300
obwohl dies nicht nötig sein soll.
Aber alles nichts gebracht, immer noch nur "???" wo die Daten
stehen soll. Ein "set lounge desired-temp 19" z.B. funktioniert
auch nicht.
Welche weitere diagnose Möglichkeiten hätte ich?
Kann man irgendwie das USB Protokoll belauschen?

[Matthias Urlichs]

Hi,

David Johnstone:

> Kann man irgendwie das USB Protokoll belauschen?

Das USB-Protokoll ist FTDI (am anderen Ende ist eine simple serielle
Schnittstelle). Da siehst du nicht mehr und nicht weniger, als das FHEM
sowieso mitloggt.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: Das Zitat wurde zufällig ausgewählt. | http://smurf.noris.de
- -
Letzte Worte eines Sportschützen:
"Nur noch kurz den Lauf reinigen"

[Juergen L.]

Hi David,

einfach nochmal den FHZ1300 vom USB-Port für 15 Sekunden abklemmen
(Powercycle), dabei FHEM nicht stoppen. Die Resycronisation bekommt
FHEM meist alleine wieder hin. Danach nochmal nachn den FHTs gucken
(evtl. refreshvalues).

Grüße,
Jürgen

[Gerhard Pfeffer]

Was scheinbar zur Zeit Mode sein dürfte, dass die USB-Ports etwas zu wenig Strom liefern.
Hast du vielleicht die Möglichkeit einen aktiven USB-Hub zwischen die FHZ und den Computer zu hängen?
Bzw. wie weit ist denn die FHT von der FHZ entfernt?

Ich habe auch das Problem, dass mein FHZ immer wieder einmal den "Geist aufgibt". Bei mir genügt allerdings ein kurzes ab- und anstecken der FHZ.

[David Johnstone]

Danke, das habe ich probiert aber es hat leider nicht geholfen.
Ich habe es mit und ohne Neustart der Server probiert,
auch mit refreschvalues.
Ein logfile habe ich hier hingestellt, falls jemanden Lust
hat es anzuschauen (ich glaube aber irgendwie nicht, daß
die Antwort dort liegt):-
http://frankfurt1.ath.cx/fhem.log
@Gerhard: Danke, ja, evtl. ist USB Power ein Problem.
Ich hätte fast an einem hardware-Schaden glauben können,
das Teil funktioniert aber auf einem anderen Windows Rechner.
Ich habe leider kein aktiven Hub, das kann ich erst morgen
ausprobieren.


>
> Grüße,
> Jürgen

[David Johnstone]

> Was scheinbar zur Zeit Mode sein dürfte, dass die USB-Ports etwas zu wenig
> Strom liefern.
> Hast du vielleicht die Möglichkeit einen aktiven USB-Hub zwischen die FHZ
> und den Computer zu hängen?
> Bzw. wie weit ist denn die FHT von der FHZ entfernt?
>
> Ich habe auch das Problem, dass mein FHZ immer wieder einmal den "Geist
> aufgibt". Bei mir genügt allerdings ein kurzes ab- und anstecken der FHZ.

Ich habe leider im Moment kein aktiven Hub. Ich habe es aber gerade
ausprobiert auf einem zweiten Linux Desktop-Rechner mit etwas höher
dimensionierte Netzteil und normale Platine (der erste ist eine
Stromspar-
mini-itx System). Der durfte etwas mehr Strom liefern können, liefert
aber genau gleiches Ergebniss. Ich glaube also irgendwie nicht, daß
es ein Problem mit +5V ist, kann ich aber noch nicht 100 prozentig
ausschließen.
Zu der Entfernung: ich habe es auch ausprobiert mit einem FHT80b
direkt neben der FHZ1300 ohne Änderung, so daß ich das ausschliessen
kann als Problem.

[David Johnstone]

Also jetzt habe ich der FHZ1300 auf einem externen USB Hub
mit eigenem Stromversorgung. Ich habe den FHEM Server neu gestartet
und auch ein refreshvalues gemacht, dann eine halbe Stunde gewartet,
usw. Ich habe sogar auch noch den Rechner neu gebootet, aber alles
ohne, daß sich irgend etwas ändert!

FHZ1300 und FHT80b liegen direkt nebeneinader gut entfernt von
Metal und Störquellen.

Jetzt bin ich komplett Ratlos. Ich will auf jeden Fall die FS20 Geräte
aus dem internet steuern können, will aber nicht mein Server von
Linux auf Windows umstellen!

Woran kann es noch liegen, daß es bei mir nicht geht und
bei euch alle?! Im Logfile stehen anscheinend nur sende-Befehle.
Kann ich irgendwie prufen ob:-

(1) Kommunikation mit dem FHZ1300 über /dev/ttyUSB0 richtig ist
und funktioniert? ("define FHZ FHZ /dev/ttyUSB0" im config-File)
(2) Das Senden erfolgreich abläuft? (set Befehle bewirken auch nichts)
(3) Irgendetwas von den Reglern FHT80b empfangen wird?

Bin sehr dankbar für alle weitere Ratschläge!
David

[Martin Haas]

Hallo David,

schonmal den Punkt 6 der FAQ probiert??
http://www.koeniglich.de/fhem/faq.html#faq6

Mach das erst, wenn die FHZ1300 einsatzbereit ist (wie du sagtest,
vermutest du einen "Nachbarn mit FHZ").

Grüße,
Martin

[David Johnstone]

> schonmal den Punkt 6 der FAQ probiert??http://www.koeniglich.de/fhem/faq.html#faq6

>
> Mach das erst, wenn die FHZ1300 einsatzbereit ist (wie du sagtest,
> vermutest du einen "Nachbarn mit FHZ").

Hi Martin,

ich hatte schon auf einem FHT80b die PROG, "Sond", "CEnt", "nA"
Einstellung probiert. Ich verstehe aber hier das Prinzip nicht so
ganz.
Wenn wir mal annehmen, es gibt in der Gegend mehrere FHZ1X00
Basisstaionen, wie kann ich dann durch eine erneute Freigabe
erreichen, daß mein FHT80b sich diesmal mit der "richtige"
synchronisiert? Irgendwie ,ußte ich beide Seiten auf der Paarung
vorbereiten, ähnlich wie bei den Stellenantrieb.

Ich habe auch ein KS300 Wetterstation die ich gerade in Betrieb
genommen habe (zumindest Batterien ein). Ich hatte gerade ein
tail -f auf dem Logfile von fhem, und es kamm sofort viele Zeilen
mit "KS300 detected" (siehe unten), also irgendwas kann das
Ding doch empfangen! Aber wie kriege ich die Code für die KS300
raus um in dem config-File einzutragen? Kann ich es irgendwie aus
diesem Log berechnen?

2007.11.26 20:06:49 5: FHZ/RAW: 810d040e4027a0017105 (Unparsed: )
2007.11.26 20:06:49 5: FHZ/RAW: 155000200b (Unparsed:
810d040e4027a0017105)
2007.11.26 20:06:49 4: KS300 detected: 810d040e4027a0017105155000200b
2007.11.26 20:06:52 5: FHZ/RAW: 810d (Unparsed: )
2007.11.26 20:06:52 5: FHZ/RAW: 041f4027a0017115155000200c (Unparsed:
810d)
2007.11.26 20:06:52 4: KS300 detected: 810d041f4027a0017115155000200c
2007.11.26 20:06:55 5: FHZ/RAW: 810d041f4027a00171 (Unparsed: )
2007.11.26 20:06:55 5: FHZ/RAW: 15155000200c (Unparsed:
810d041f4027a00171)
2007.11.26 20:06:55 4: KS300 detected: 810d041f4027a0017115155000200c
2007.11.26 20:06:58 5: FHZ/RAW: 81 (Unparsed: )
2007.11.26 20:06:58 5: FHZ/RAW: 0d041f4027a0017115155000200c
(Unparsed: 81)
2007.11.26 20:06:58 4: KS300 detected: 810d041f4027a0017115155000200c
2007.11.26 20:07:01 5: FHZ/RAW: 810d041f4027a001 (Unparsed: )
2007.11.26 20:07:01 5: FHZ/RAW: 7115155000200c (Unparsed:
810d041f4027a001)
2007.11.26 20:07:01 4: KS300 detected: 810d041f4027a0017115155000200c
2007.11.26 20:07:04 5: FHZ/RAW: 810d041f4027a0017115155000200c
(Unparsed: )
2007.11.26 20:07:04 4: KS300 detected: 810d041f4027a0017115155000200c
2007.11.26 20:07:07 5: FHZ/RAW: 810d041f4027 (Unparsed: )
2007.11.26 20:07:07 5: FHZ/RAW: a0017115155000200c (Unparsed:
810d041f4027)
2007.11.26 20:07:07 4: KS300 detected: 810d041f4027a0017115155000200c

[David Johnstone]

Also der KS300 geht :-))
Jetzt weiß ich zumindest, daß die serielle comms geht usw.,
und daß der FHZ1300 in der Lage ist zu empfangen.
Ist nur die Frage was das Problem mit den FHT80b
Reglern sein kann.


server1:/usr/local/lib/FHEM/examples # fhem.pl 7072 "list ks1"
Internals:
CODE 0781
DEF 0781 250
NAME ks1
NR 4
RAINUNIT 250
STATE T: 18.1 H: 46 W: 0.0 R: 0.5 IR: no
TYPE KS300
WINDUNIT 1
Attributes:
Readings:
2007-11-26 20:42:28 avg_day T: 18.1 H: 46 W: 0.0 R: 0.5
2007-11-26 20:42:28 cum_day 2007-11-26 20:42:28 T: 0 H: 0
W: 0 R: 0.5
2007-11-26 20:42:28 humidity 46 (%)
2007-11-26 20:42:28 israining no (yes/no)
2007-11-26 20:42:28 rain 0.5 (l/m2)
2007-11-26 20:42:28 rain_raw 2 (counter)
2007-11-26 20:42:28 temperature 18.1 (Celsius)
2007-11-26 20:42:28 unknown1 f
2007-11-26 20:42:28 unknown2 7
2007-11-26 20:42:28 unknown3 1
2007-11-26 20:42:28 wind 0.0 (km/h)

server1:/usr/local/lib/FHEM/examples #

[Rudolf Koenig]

> ich hatte schon auf einem FHT80b die PROG, "Sond", "CEnt", "nA"
> Einstellung probiert. Ich verstehe aber hier das Prinzip nicht so
> ganz.

Bis Du Dir sicher, dass es sich um ein FHT80b handelt, und nicht um
die FHT8? Die sehen (angeblich) genauso aus, koennen aber nicht mit
dem FHZ1000(PC) reden. Hast Du noch weitere FHT's die funktionieren?
Funktioniert es unter Windows?

> Wenn wir mal annehmen, es gibt in der Gegend mehrere FHZ1X00
> Basisstaionen, wie kann ich dann durch eine erneute Freigabe
> erreichen, daß mein FHT80b sich diesmal mit der "richtige"
> synchronisiert? Irgendwie ,ußte ich beide Seiten auf der Paarung
> vorbereiten, ähnlich wie bei den Stellenantrieb.

Ich vermute, der erste gewinnt. Wenn ich das Prinzip richtig
verstanden habe: Die FHT's schlafen ca 2 Minuten. Dann senden die dem
Stellantrieben die Werte. Das kriegt der FHZ mit, und sendet
anschliessend die Daten aus dem Queue dem FHT. Dieser ist noch wach,
und kann darauf reagieren. Wenn der FHZ des Nachbarns besser zuhoert
oder lauter ist....

> Ich habe auch ein KS300 Wetterstation die ich gerade in Betrieb
> genommen habe (zumindest Batterien ein). Ich hatte gerade ein
> tail -f auf dem Logfile von fhem, und es kamm sofort viele Zeilen
> mit "KS300 detected" (siehe unten), also irgendwas kann das
> Ding doch empfangen! Aber wie kriege ich die Code für die KS300
> raus um in dem config-File einzutragen? Kann ich es irgendwie aus
> diesem Log berechnen?

Musst Du nicht. Wie im commandref.html, Abschnitt #define, Typ KS300
zu lesen ist, man muss irgendeins definieren, es wird aber ignoriert.
Der KS300 hat kein Hausecode, das haben wir aber erst spaeter
rausgefunden.

[David Johnstone]

> Bis Du Dir sicher, dass es sich um ein FHT80b handelt, und nicht um
> die FHT8? Die sehen (angeblich) genauso aus, koennen aber nicht mit
> dem FHZ1000(PC) reden. Hast Du noch weitere FHT's die funktionieren?
> Funktioniert es unter Windows?

Ja, doch, es sind die Bidirektionalen, und die Windows-Software
zeigt auch die gesendeten Temperatur Werte an. Ich kann auch
die soll-Temperatur über Windows einstellen, und es wird richtig
angezeigt auf dem Display des FHT80b.

> > Wenn wir mal annehmen, es gibt in der Gegend mehrere FHZ1X00
> > Basisstaionen, wie kann ich dann durch eine erneute Freigabe
> > erreichen, daß mein FHT80b sich diesmal mit der "richtige"
> > synchronisiert? Irgendwie ,ußte ich beide Seiten auf der Paarung
> > vorbereiten, ähnlich wie bei den Stellenantrieb.
>
> Ich vermute, der erste gewinnt. Wenn ich das Prinzip richtig
> verstanden habe: Die FHT's schlafen ca 2 Minuten. Dann senden die dem
> Stellantrieben die Werte. Das kriegt der FHZ mit, und sendet
> anschliessend die Daten aus dem Queue dem FHT. Dieser ist noch wach,
> und kann darauf reagieren. Wenn der FHZ des Nachbarns besser zuhoert
> oder lauter ist....

Verstehe ich dich dann so, daß ich die FHT80b erneut mit den
Stellenantrieben paaren soll um Kommunikation mit dem FHZ1300
herzustellen?

> Musst Du nicht. Wie im commandref.html, Abschnitt #define, Typ KS300
> zu lesen ist, man muss irgendeins definieren, es wird aber ignoriert.
> Der KS300 hat kein Hausecode, das haben wir aber erst spaeter
> rausgefunden.

Ah, sorry, die Seite habe ich übersehen.
Danke für die Hilfe, auch für die Software!
Die Strukturierung, also Client/Server aufteilung, passt gut zu der
Anwendung!

[David Johnstone]

Eine andere Frage:
Es steht auf commandref.html, daß der

"define <name> FHT <housecode>
<housecode> is a four digit hex number"

ist hier wirklich hex gemeint und nicht BCD?
Letzteres sieht man in den Logfiles. Ich habe jetzt meine
3 Regler sequential eingestellt, also Housecodes in dezimal
6623, 6624, 6625. Ich sehe jetzt manchmal in den Logfiles
Unknown device 4217 (oder 4218, 4219). Dadurch ist mir
erst eingefallen, das sind meine Geräte!
Im config File soll dann aber stehen:-
19DF, 19E0, 19E1 - richtig?

[Rudolf Koenig]

> <housecode> is a four digit hex number"
>
> ist hier wirklich hex gemeint und nicht BCD?

Ja. BCD finde ich sehr aufwaendig zum eingeben, und beim parsen steht
es auch nur im Weg. Du meinst bestimmt was anderes :-)

> Letzteres sieht man in den Logfiles. Ich habe jetzt meine
> 3 Regler sequential eingestellt, also Housecodes in dezimal
> 6623, 6624, 6625. Ich sehe jetzt manchmal in den Logfiles
> Unknown device 4217 (oder 4218, 4219). Dadurch ist mir
> erst eingefallen, das sind meine Geräte!
> Im config File soll dann aber stehen:-
> 19DF, 19E0, 19E1 - richtig?

Also wenn im logfile 4217 steht, dann bitte genau das eingeben, nix
umrechnen oder so...

[Matthias Urlichs]

Hi,

> > Letzteres sieht man in den Logfiles. Ich habe jetzt meine
> > 3 Regler sequential eingestellt, also Housecodes in dezimal
> > 6623, 6624, 6625. Ich sehe jetzt manchmal in den Logfiles
> > Unknown device 4217 (oder 4218, 4219). Dadurch ist mir
> > erst eingefallen, das sind meine Geräte!

Überraschung. (Ist aber dokumentiert...)

Die Regler haben einen 2-Byte-Housecode; jedes Byte kann einen Wert
zwischen 0 und 99 haben; diese 4stellige "Zahl" wird im Regler eingestellt.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: Das Zitat wurde zufällig ausgewählt. | http://smurf.noris.de
- -
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: Das Zitat wurde zufällig ausgewählt. | http://smurf.noris.de
- -

"Frag mal, auf was für uptimes man kommt, wenn man Software-Entwicklung
unter NT macht..."
"Das können bis zu dreißig Minuten werden - in der Mittagspause."
-- Andreas Bogk, Kai Fett, de.alt.sysadmin.recovery

[David Johnstone]

Also, wie so oft hat das Problem anscheinend mehrere Ursachen
gehabt. Wenn man mehrere unbekannten Parametern hat und alle
ändert, dann wird manchmal jeder einzelne Permutation nicht lang
genug ausprobiert um zuverläßig sagen zu können, ob es die richtige
ist oder nicht.

Der Tipp mit der Code war wichtig, danke.

Mit den richtigen Codes geht es, aber nicht ohne einige
Merkwurdigkeiten. So muß ich wenn ich neue FHT80b Geräte einbaue,
oder (anscheinend nur bei den vom FHZ1300 weiter entfernten FHT80b's)
PROG, "Sond", "CEnt", "nA" setzen UND dann die Geräte erstmal
ganz in der Nähe der FHZ1300 liegen. Danach, also einige Stunden
später, kann ich die dann entfernen, in ihren richtigen Zimmern
stellen, und der Empfang klappt perfekt, auch Wochen lang.
Außerst merkwurdig, es ist fast so als wäre eine trainings-Phase,
daß die Geräte sich auf einander einstellen oder irgendwas
aushandeln. Wenn ich das nicht mache oder die Geräte zu früh
entferne, so werden oft die soll-Temperatur und Actuator-Stand
richtig übertragen, nicht aber die ist-Temperatur. Es reicht meist
nicht, daß die Parametern alle einmal richtig übertragen worden
sind.

Ich wurde zu gerne wissen, woran das liegt!

Vielleicht ist man desewgen bei den teuerer HomeMatic
zu einem protocol mit Rückmeldung/Empfangsbestätigung
rübergegangen.

Ganz in der Nähe vom FHZ1300 habe ich leider einige möglichen
Störquellen (DECT, WLAN), was ich leider nicht so einfach ändern kann.

Wenn es einmal richtig läuft dann scheint es einigermaßen stabil
zu sein, solange man nichts rünterfährt jedenfalls!

Ich habe zwischendurch ein Repeater probiert, der hat aber keine
spurbare Unterschied im Verhalten gebracht. Die Reichweite
scheint mehr als ausreichend zu sein, unter obigen Voraussetzungen.

[Rudolf Koenig]

> Ich habe zwischendurch ein Repeater probiert, der hat aber keine
> spurbare Unterschied im Verhalten gebracht. Die Reichweite
> scheint mehr als ausreichend zu sein, unter obigen Voraussetzungen.

Meines Wissens nach ist der Repeater nur fuer FS20 zu gebrauchen, FHT,
HMS oder KS300 profitieren nicht davon