FHT Schaltzeiten Endlosschleife

[habichthugo]

Folgendes Phänomen:

Code Auswählen Erweitern

2014-04-20_20:10:04 FHT_Wohnzimmer mon-from1 08:00 mon-to1 23:30 tue-from1 08:00 tue-to1 23:30 wed-from1 08:00 wed-to1 23:30 thu-from1 08:00 thu-to1 23:30
2014-04-20_20:10:04 FHT_Wohnzimmer fri-from1 08:00
2014-04-20_20:12:01 FHT_Wohnzimmer actuator: 28%
2014-04-20_20:12:02 FHT_Wohnzimmer mon-from1: 08:00
2014-04-20_20:12:02 FHT_Wohnzimmer mon-to1: 23:30
2014-04-20_20:12:02 FHT_Wohnzimmer tue-from1: 08:00
2014-04-20_20:12:02 FHT_Wohnzimmer tue-to1: 23:30
2014-04-20_20:12:03 FHT_Wohnzimmer wed-from1: 08:00
2014-04-20_20:15:57 FHT_Wohnzimmer actuator: 28%
2014-04-20_20:15:58 FHT_Wohnzimmer mon-from1: 08:00
2014-04-20_20:15:58 FHT_Wohnzimmer mon-to1: 23:30
2014-04-20_20:15:59 FHT_Wohnzimmer tue-from1: 08:00
2014-04-20_20:15:59 FHT_Wohnzimmer tue-to1: 23:30
2014-04-20_20:15:59 FHT_Wohnzimmer wed-from1: 08:00
2014-04-20_20:17:55 FHT_Wohnzimmer actuator: 28%
2014-04-20_20:17:56 FHT_Wohnzimmer mon-from1: 08:00
2014-04-20_20:17:56 FHT_Wohnzimmer mon-to1: 23:30
2014-04-20_20:17:56 FHT_Wohnzimmer tue-from1: 08:00
2014-04-20_20:17:56 FHT_Wohnzimmer tue-to1: 23:30
2014-04-20_20:17:57 FHT_Wohnzimmer wed-from1: 08:00
2014-04-20_20:18:00 FHT_Wohnzimmer report2 8
2014-04-20_20:19:53 FHT_Wohnzimmer actuator: 28%
2014-04-20_20:19:54 FHT_Wohnzimmer mon-from1: 08:00
2014-04-20_20:19:54 FHT_Wohnzimmer mon-to1: 23:30
2014-04-20_20:19:54 FHT_Wohnzimmer tue-from1: 08:00
2014-04-20_20:19:54 FHT_Wohnzimmer tue-to1: 23:30
2014-04-20_20:19:55 FHT_Wohnzimmer wed-from1: 08:00
...
2014-04-20_22:00:12 FHT_Wohnzimmer mon-from1: 08:00
2014-04-20_22:00:12 FHT_Wohnzimmer mon-to1: 23:30
2014-04-20_22:00:12 FHT_Wohnzimmer tue-from1: 08:00
2014-04-20_22:00:13 FHT_Wohnzimmer tue-to1: 23:30
...

Ich habe also probiert Schaltzeiten zu setzen, erst acht auf ein Mal (was ja zulässig ist) und dann noch einen Einzelbefehl hinterher. Bestätigt werden nun ständig die ersten fünf Zeiten. Auf der FHT selbst hat sich aber nichts geändert, d.h. da stehen immer noch die alten Zeiten, wenn ich sie mir an der FHT direkt ansehe. Und das Spiel endet offenbar nicht.
Das Gleiche an weiteren FHTs, z.B. (hier nur einmalig sechs Schaltzeiten):

Code Auswählen Erweitern

2014-04-20_20:10:03 FHT_Bad mon-from1 08:00 mon-to1 10:00 tue-to1 10:00 wed-to1 10:00 thu-to1 10:00 fri-to1 10:00
2014-04-20_20:11:17 FHT_Bad actuator: 0%
2014-04-20_20:11:18 FHT_Bad mon-from1: 08:00
2014-04-20_20:11:18 FHT_Bad mon-to1: 10:00
2014-04-20_20:11:18 FHT_Bad tue-to1: 10:00
2014-04-20_20:11:18 FHT_Bad wed-to1: 10:00
2014-04-20_20:11:19 FHT_Bad thu-to1: 10:00
2014-04-20_20:13:12 FHT_Bad actuator: 0%
2014-04-20_20:13:13 FHT_Bad mon-from1: 08:00
2014-04-20_20:13:13 FHT_Bad mon-to1: 10:00
2014-04-20_20:13:14 FHT_Bad tue-to1: 10:00
2014-04-20_20:13:14 FHT_Bad wed-to1: 10:00
2014-04-20_20:13:14 FHT_Bad thu-to1: 10:00
2014-04-20_20:15:00 FHT_Bad report2 8
2014-04-20_20:15:08 FHT_Bad actuator: 0%
2014-04-20_20:15:09 FHT_Bad mon-from1: 08:00
...
2014-04-20_22:08:43 FHT_Bad mon-from1: 08:00
2014-04-20_22:08:44 FHT_Bad mon-to1: 10:00
2014-04-20_22:08:44 FHT_Bad tue-to1: 10:00
2014-04-20_22:10:38 FHT_Bad actuator: 0%
2014-04-20_22:10:39 FHT_Bad mon-from1: 08:00
2014-04-20_22:10:39 FHT_Bad mon-to1: 10:00
2014-04-20_22:10:40 FHT_Bad tue-to1: 10:00
2014-04-20_22:12:33 FHT_Bad actuator: 0%

Das scheint also systematisch nicht zu funktionieren? Oder was ist da los?
RSSI ist bei 55..60, sollte also kein prinzipielles Sende/Empfangsproblem sein...

[Zrrronggg!]

Sieht für mich trotzdem wie gestörte und daher immer wieder wiederholte Kommunikation aus.

Was für eine Funkschnittstlele hast du? Wenn's ein CUL / CUNO o.ä. ist sieh dir doch mal die Kommunikation an insbesondere die FHT Befehlsbuffer.  (Siehe Wikiartikel)

[habichthugo]

Ich habe ein CUL v3 (siehe Sig.). Der ist auf dreimalige Wiederholung eingestellt, was er (laut Log) aber nicht getan hat. Die FHTs orgeln aber ständig die Bestätigungen weiter...
Etwa 10 Min. nach den Ursprungsbefehlen setzt

Code Auswählen Erweitern

2014.04.20 20:20:09 2: MyCUL: unknown message LOVF
2014.04.20 20:20:10 4: CUL_Parse: MyCUL LOVF

ein. Ich vermute also, der CUL schafft es nicht die Bestätigungen der FHTs zu quittieren. Und die haben kein Wiederhollimit und orgeln dann bis zum Sanktnimmerleinstag?
Ich habe nur fünf FHTs und sonst keine weiteren FS20&Co. Komponenten. Allerdings frage ich die je alle 15 Min. mit 'report2 8' ab (versetzt, also geht alle drei Min. so ein Befehl raus), um in den Logs bzw. Grafiken regelmäßig das 'desired-temp' zu haben. Ich stelle das mal testhalber ab...

[Zrrronggg!]

Seufz.

Hier mal paar Hinweise:

Der ist auf dreimalige Wiederholung eingestellt,

Das hat keine Wirkung. Dies gilt nur wenn man softbuffer eingestellt hat (der wiederum bei CUL keine Wirkung hat).
Steht in mehreren Wikiartikeln zum Thema FTH. Das attr kannst du komplett entfernen.

Etwa 10 Min. nach den Ursprungsbefehlen setzt
Code: [Auswählen]
2014.04.20 20:20:09 2: MyCUL: unknown message LOVF

Ja, das wundert nicht. Irgendwann ist speziell bei der "gesprächigen" Kommunikation mit den FHTs das Kontingent aufgebraucht.

Ich vermute also, der CUL schafft es nicht die Bestätigungen der FHTs zu quittieren.

IdR. sind eher die FHTs der Übeltäter, weil deren Sender / Empfänger schlechter ist als vom CUL. Aber woran es genau liegt kann man nur wissen, wenn man die Kommunikation mal genau verfolgt. Wie man das macht und wie die aussehen müsste steht im Wiki.

Und die haben kein Wiederhollimit und orgeln dann bis zum Sanktnimmerleinstag?

Doch, haben sie, mindestens deren Sendelimit nämlich. Ich gehe Stand jetzt auch davon aus, dass die ständige Wiederholung der Arie vom CUL/FHEM veranlasst wird. Genaueres weiss man aber erst, wenn... siehe oben.

Allerdings frage ich die je alle 15 Min. mit 'report2 8'

Das dürfte das Sendecontingent schon recht deutlich beanspruchen to say the least. Ich müsste das mal ausrechnen, aber ich habe so im Gefühl, dass diese Abfrage allein (plus die normalen Meldungen der FHTs) das Sendekontingent bereits so strapaziert, dass die Übertragung von weiteren 8 Befehlen für die Wochenprogramme scheitern *muss*. (auch hier: Sendekontigentverbrauch und wieviel man mit FHTs kommunizieren kann und so weiter... steht im Wiki). Grob überschlägig wird das auf jeden Fall sehr knapp!

Ich stelle das mal testhalber ab

Ja, das wäre auch mein erster Vorschlag.

Und ansonsten Kommunikation ansehen.
Zum Einstieg dies lesen:
http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT

[Puschel74]

Hallo,

hier hat es auch noch einen Beitrag zum Thema LOVF:

http://forum.fhem.de/index.php/topic,17285.msg113053.html#msg113053

welchen ich nicht so schnell vergessen werde da
a) ich selbst auch rein getappt bin aber
b) mir in diesem Beitrag genial geholfen wurde und ich
c) seitdem Ruhe habe.

Allerdings muss ich dazu sagen das ich wohl mit meinen 11 FHT etwas "Glück" habe das seltenst einer stumm wird.
Ich daher nicht ständig Daten abfragen muss um einen einigermassen sauberen Plot zu bekommen.

Grüße

[habichthugo]

Habe gestern noch alle reports abgestellt, CUL reset und ein Stunde gewartet. Dann

Code Auswählen Erweitern

set FHT_Wohnzimmer mon-from1 08:00 mon-to1 23:30 tue-from1 08:00 tue-to1 23:30 wed-from1 08:00 wed-to1 23:30 thu-from1 08:00 thu-to1 23:30
set FHT_Wohnzimmer fri-from1 08:00
set FHT_Kueche mon-from1 08:00 mon-to1 20:00 tue-to1 20:00 wed-to1 20:00 thu-to1 20:00 fri-to1 20:00
set FHT_Bad mon-from1 08:00 mon-to1 10:00 tue-to1 10:00 wed-to1 10:00 thu-to1 10:00 fri-to1 10:00
set FHT_xxx mon-from1 24:00 mon-to1 19:00 mon-to2 24:00

Nix ist über Nacht angekommen. Es LOVF nur so vor sich hin. Kann man doch echt haken, wenn man nicht mal einen Bruchteil der Register von fünf FHTs übertragen bekommt. Und vor allem fängt sich das offenbar nicht von alleine. Naja...

[Zrrronggg!]

Ja, bestimmte Situationen fangen sich nicht mehr von alleine. Insbesondere,  wenn die Abarbeitung des Buffers wegen kommunikationsproblemen so langsam ist, das die normale Kommunikation die alle 15 Minuten stattfindet (und die du nicht abstellen kannst) das Sendelimit stärker belastet, als abgearbeitet werden kann.

Das ist auch mit 5 FHTs möglich.

Das übertragen von umfangreichen Wochenscenarien ist grundsätzlich immer dazu angetan Probleme zu bereiten.
Alle 15 Minuten Daten per report anfragen ebenso.

Und du hattest beides gemacht.

Wenn du in LOVF Situationen irgendwas änderst ist es immer ne gute Idee, den CUL auch zu resetten oder den Buffer zu leeren. Die Probleme des Rückstaus im Buffer verdecken sonst Erfolg oder Misserfolg der Massnahmen.

Wie sind den die RSSIs zu den CULs? Alle 85 oder kleiner ?

Die vorgeschlagenen Artikel schon gelesen? Mal versucht die Kommunikation wie vorgeschlagen zu beobachten um zu sehen wo es hacken könnte?

attr lazy überall aktiviert, um den Verkehr zu reduzieren?

[habichthugo]

Sicher habe ich mir das alles angesehen. RSSI ist bei der schlechtesten FHT -74. Reports oder anderen Traffic habe ich nicht mehr. attr lazy dürfte also nichts bewirken.
CUL/FHT drehen sich im Kreis, sobald ich nur einen Befehl mit (angeblich zulässigen) acht Registern sende:

Code Auswählen Erweitern

fhem> get MyCUL raw T02
MyCUL raw => N/A
fhem> info timer
set MyCUL raw X61
fhem> 2014-04-21 20:22:19 CUL MyCUL raw X61
fhem> set FHT_Wohnzimmer mon-from1 08:00 mon-to1 23:30 tue-from1 08:00 tue-to1 23:30 wed-from1 08:00 wed-to1 23:30 thu-from1 08:00 thu-to1 23:30
fhem> 2014-04-21 20:24:19 FHT FHT_Wohnzimmer mon-from1 08:00 mon-to1 23:30 tue-from1 08:00 tue-to1 23:30 wed-from1 08:00 wed-to1 23:30 thu-from1 08:00 thu-to1 23:30
2014-04-21 20:24:23 FHT FHT_xx actuator: 0%
2014-04-21 20:24:44 FHT FHT_Bad actuator: 0%
2014-04-21 20:25:07 Global global UNDEFINED FHT_0b0b FHT 0b0b
2014-04-21 20:25:27 FHT FHT_Wohnzimmer actuator: 0%
2014-04-21 20:25:27 FHT FHT_Wohnzimmer FHZ:can-xmit: 90
2014-04-21 20:25:27 FHT FHT_Wohnzimmer can-rcv: 90
2014-04-21 20:25:27 FHT FHT_Wohnzimmer FHZ:start-xmit: 90
2014-04-21 20:25:27 FHT FHT_Wohnzimmer start-xmit: 90
2014-04-21 20:25:27 FHT FHT_Wohnzimmer FHZ:mon-from1: 08:00
2014-04-21 20:25:27 FHT FHT_Wohnzimmer mon-from1: 08:00
2014-04-21 20:25:28 FHT FHT_Wohnzimmer FHZ:mon-to1: 23:30
2014-04-21 20:25:28 FHT FHT_Wohnzimmer mon-to1: 23:30
2014-04-21 20:25:28 FHT FHT_Wohnzimmer FHZ:tue-from1: 08:00
2014-04-21 20:25:28 FHT FHT_Wohnzimmer tue-from1: 08:00
2014-04-21 20:25:28 FHT FHT_Wohnzimmer FHZ:tue-to1: 23:30
2014-04-21 20:25:28 FHT FHT_Wohnzimmer tue-to1: 23:30
2014-04-21 20:25:28 FHT FHT_Wohnzimmer FHZ:wed-from1: 08:00
2014-04-21 20:25:29 FHT FHT_Wohnzimmer wed-from1: 08:00
2014-04-21 20:25:29 FHT FHT_Wohnzimmer FHZ:wed-to1: 23:30
2014-04-21 20:25:29 FHT FHT_Wohnzimmer FHZ:wed-to1: 23:30
2014-04-21 20:25:45 IT SchalterB on
2014-04-21 20:25:52 FHT FHT_Kueche actuator: 0%
...
get MyCUL raw T02
MyCUL raw => 4D06:1430,158D,1830,198D,1C30,1D8D,2030,218D
fhem> 2014-04-21 20:29:23 FHT FHT_Wohnzimmer actuator: 0%
2014-04-21 20:29:23 FHT FHT_Wohnzimmer FHZ:can-xmit: 90
2014-04-21 20:29:23 FHT FHT_Wohnzimmer can-rcv: 90
2014-04-21 20:29:23 FHT FHT_Wohnzimmer FHZ:start-xmit: 90
2014-04-21 20:29:23 FHT FHT_Wohnzimmer start-xmit: 90
2014-04-21 20:29:23 FHT FHT_Wohnzimmer FHZ:mon-from1: 08:00
2014-04-21 20:29:24 FHT FHT_Wohnzimmer FHZ:mon-from1: 08:00
2014-04-21 20:29:24 FHT FHT_Wohnzimmer mon-from1: 08:00
2014-04-21 20:29:24 FHT FHT_Wohnzimmer FHZ:mon-to1: 23:30
2014-04-21 20:29:24 FHT FHT_Wohnzimmer mon-to1: 23:30
2014-04-21 20:29:24 FHT FHT_Wohnzimmer FHZ:tue-from1: 08:00
2014-04-21 20:29:25 FHT FHT_Wohnzimmer tue-from1: 08:00
2014-04-21 20:29:25 FHT FHT_Wohnzimmer FHZ:tue-to1: 23:30
2014-04-21 20:29:25 FHT FHT_Wohnzimmer tue-to1: 23:30
2014-04-21 20:29:25 FHT FHT_Wohnzimmer FHZ:wed-from1: 08:00
2014-04-21 20:29:25 FHT FHT_Wohnzimmer wed-from1: 08:00
2014-04-21 20:29:25 FHT FHT_Wohnzimmer FHZ:wed-to1: 23:30
2014-04-21 20:29:26 FHT FHT_Wohnzimmer FHZ:wed-to1: 23:30
2014-04-21 20:29:49 FHT FHT_xx actuator: 0%
2014-04-21 20:29:50 FHT FHT_Kueche actuator: 0%
get MyCUL raw T02
MyCUL raw => 4D06:1430,158D,1830,198D,1C30,1D8D,2030,218D

Nach dem fünften Register (wed-from1) ist regelmässig fin und der ganze Befehl verbleibt im Puffer und verklemmt ihn.
Der CUL sendet die Register ja offenbar doch alle einzeln. Was macht da die Bündelung in einem Befehl überhaupt für einen Sinn? Ich dachte, dass spart Traffic?

p.s.: Vier an einem Stück gehen scheinbar problemlos:

Code Auswählen Erweitern

fhem> 2014-04-21 20:52:04 FHT FHT_Wohnzimmer mon-from1 08:00 mon-to1 23:30 tue-from1 08:00 tue-to1 23:30
2014-04-21 20:52:18 Global global UNDEFINED FHT_0b0b FHT 0b0b
get MyCUL raw T02
MyCUL raw => 4D06:1430,158D,1830,198D
fhem> 2014-04-21 20:52:59 FHT FHT_Wohnzimmer actuator: 7%
2014-04-21 20:53:00 FHT FHT_Wohnzimmer mon-from1: 08:00
2014-04-21 20:53:00 FHT FHT_Wohnzimmer mon-to1: 23:30
2014-04-21 20:53:00 FHT FHT_Wohnzimmer tue-from1: 08:00
2014-04-21 20:53:00 FHT FHT_Wohnzimmer tue-to1: 23:30
get MyCUL raw T02
MyCUL raw => N/A


[habichthugo]

Das vorläufige amtliche Endergebnis:
Meine Probleme lagen offenbar einzig und alleine daran, dass ich versucht habe, acht Kommandos in einem Befehl an die FHTs zu senden. Bis zu fünf Kommandos gehen, mehr nicht, dann klemmt sich die Kommunikation fest. Das ist bei allen meinen FHTs das gleiche.

Warum aber kann man dann acht Kommandos in einem Befehl absetzen, wenn das systematisch nicht funktioniert?

Meine 'report2 8' habe ich wieder an. Mit alle 30 min. pro FHT bzw. (zeitversetzt) in Summe alle 6 Min. fallen bei mir die Sendezeitslots (get CUL raw X) scheinbar nicht unter 800, also offenbar unkritisch.

Maximalwert scheint bei mir 900 zu sein!? Aber das wären ja 900*10ms=9s bzw. nur 1/4% einer Stunde (3600s)? Ich dachte das Limit wäre 1%???

[Zrrronggg!]

Auch wenn ich jetzt all der Vollhaarspalter rüberkomme, lass uns bitte erstmal eines klären:

"scheinbar" heisst: Sieht so aus - ich weiss aber ES IST  NICHT SO

Das meinst du aber nicht oder? Du meinst "anscheinend", richtig?
(Anscheinend = "Sieht so aus, ich weiss aber nicht genau ob es auch so ist")
Die Unterscheidung wäre hier schon wichtig denke ich.

Mal angenommen das ist so wie ich vermute, dann hier mal ein paar Antworten:
1.

RSSI ist bei der schlechtesten FHT -74. Reports oder anderen Traffic habe ich nicht mehr. attr lazy dürfte also nichts bewirken.

Ja, ich denke da hast du recht. Bei -74 gibts keine Probleme. Allerdings wirkt Lazy auch bei Kommandos wie set time oder set date, sogar bei einzelnen Aspekten davon (nur Stunde).
Ist aber sicher aktuell tatsächlich erstmal egal.
2.

Was macht da die Bündelung in einem Befehl überhaupt für einen Sinn? Ich dachte, dass spart Traffic?

Laut Doku schon. Jede Kommunkation mit den FHTs braucht ja 5+n Kommandos (n=Anzahl der übermittelten Werteänderungen). Diese 5 fallen bei mehren Kommandos in einem "set" Befehl nur 1x an, das spart Sendeslots, nämlich bis zu 35, wenn ich das richtig sehe.

Es hat aber vermutlich auch einen Nachteil, den du gerade erlebt hast: Die Kommunikation wird immer länger und ALLES wird wiederholt wenn was schief geht. Die Chance dass es irgendeine Störung gibt steigt natürlich an, je länger die Kommunikation ist. Ich bin im übrigen auch nicht sicher, was "8 Kommandos" hier tatsächlich meint. Da lazymode z.B. verhindert, das "set time" die Stunde aktualisiert, wenn diese schon stimmt, sondern nur die Minuten sendet, ist z.b. denkbar, dass "set time" in Wirklichkeit 2 Kommandos sind.
Wenn das so wäre, wäre sicher auch "mon-from1 08:00" 2 Kommandos. Ist aber nur spekuliert.
Ich selber habe noch nie mehr als vielleicht 3 Kommandos zusammengefasst, daher kann ich aus eigener Anschauung hier nichts zu sagen.

3.

Warum aber kann man dann acht Kommandos in einem Befehl absetzen, wenn das systematisch nicht funktioniert?

3a. Fehler in der Doku
3b. from ... to... Befehle verhalten sich anders als die normalen "set xy-temp yz" Befehle
3c. Bei DIR geht es nicht, sonst schon. Wie dies?
Wenn du z.b. in deinem Haus irgendwas hast, was alle x ms den Kanal stört und die Übertragung von 8 Befehlen am Stück  x+1 ms dauert, dann bekommst du die 8 Befehle NIE durch. 5 aber öfters wohl.


4.

fallen bei mir die Sendezeitslots (get CUL raw X) anscheinend nicht unter 800, also offenbar unkritisch.

Solange die Empfangslage gut ist vielleicht ja. Dennoch erhöhst du das Verkehrsaufkommen im Normalbetrieb um etwa 50% (grob geschätzt), ausserdem steht der Kram ja im Buffer, sodass auch Temperaturänderungen bis zu 2 Minuten nach dem Absetzen um genau diese 2 Minuten versetzt werden, als ggf erst nach 4 Minuten ausgeführt werden. Und das auch nur wenn alles glatt läuft. Also MACHEN kann man das, ich will dir das nicht ausreden. Du musst eben nur auf dem Schirm haben, dass das ggf. auftretende Probleme zusätzlich belastet.

5.

Maximalwert scheint bei mir 900 zu sein!?

Hm. Bei mir sind's auch nie mehr als 900, ich muss zugeben, da habe ich noch nie drüber nachgedacht. Ich weiss aber auch nicht genau, wie Rudolf König das ganz genau implementiert hat.

[habichthugo]

Ja, ich meinte anscheinend.

Das mit den fünf und acht (Schaltzeiten-) Kommandos in einem Befehl habe ich je vier Mal pro FHT probiert und das Ergebnis ist immer das selbe (gleiche?). Das ist mir zu reproduzierbar um Zufall zu sein.

Was wirklich ganz doof ist, ist das die

Code Auswählen Erweitern

2014-04-20_20:10:04 FHT_Wohnzimmer mon-from1 08:00 mon-to1 23:30 tue-from1 08:00 tue-to1 23:30 wed-from1 08:00 wed-to1 23:30 thu-from1 08:00 thu-to1 23:30
...
>>> 2014-04-20_20:12:02 FHT_Wohnzimmer mon-from1: 08:00 <<<
genau so aussehen, wie eine Bestätigung von der FHT bzw. entsprechende Reaktion auf eine Report-Aufforderung, und auch so ausgewertet werden (steht dann im Reading als gegessen). Die FHT hat aber die Werte nicht übernommen. Damit bleibt für ein funkgesteuertes Update dann nur eine komplette Übertragung der Tabellen, nicht wie ich es ja offensichtlich vor hatte, nur der Differenzen.

Mir ist leider noch keine vernüftige Lösung zur Fersteuerung eingefallen, die weiterhin ein lokales Übersteuern (Partyfunktion) erlaubt. Das Übertragen der (neuen) Tabellen ist nichts regelmässiges, sonder wird die Ausnahme (wie jetzt z.B. zur Osterferien-Zeit) bleiben. Das darf auch ein, zwei Stündchen dauern (sollet aber zu einem definierten Ergebnis führen).

Btw.: Wie kann ich den Traffik denn nun mal vernünftig berechnen? Wenn ich jetzt solche Vierer-Pakete versende, wie viel Sendezeit kostet das tatsächlich (ideal)? Und wie viele solche Pakete passen in den Sendepuffer?

[habichthugo]

Scheint ein Problem spezieller FHT zu sein?
https://groups.google.com/d/msg/fhem-users/9iVPkxPv6fg/ROyHXEkNP68J (2011!):
"Mit 5 set-Befehlen scheint es auch noch zu funktionieren, das scheint auch das Maximum zu sein, was er noch komplett abholt. Sobald ich einen 6. set einbaue, wieder das:" ff.

[Zrrronggg!]

Der Thread aus 2011 legt eigentlich eher nahe, dass es sich um Funkproblem handelt. Wie man diversen Wikiartikeln entnehmen kann, streuen die FHTs doch recht deutlich. Spielen mit Bandbreite könnte was bringen, wenn das auch bei dir die Ursache ist. Ich halte es für unwahrscheinlich, dass es tatsächlich FHTs gibt, die nur 5 Kommandos können. Ich glaube eher an Funkstörungen oder so.

Das mit den fünf und acht (Schaltzeiten-) Kommandos in einem Befehl habe ich je vier Mal pro FHT probiert und das Ergebnis ist immer das selbe (gleiche?). Das ist mir zu reproduzierbar um Zufall zu sein.

Selbe / gleiche... weiss ich hier auch nicht LOL, nein da glaube ich auch nicht an einen Zufall.
Wiederkehrende Funkstörungen in bestimmten Intervallen wären aber nicht ausgeschlossen. Das KÖNNTEST du prüfen, man kann das CUL so einstellen, das es alle aufgefangenen Flanken protokolliert. Ist aber Arbeit. Vielleicht ist es einfacher dann doch eben nur 5 zu grupperen und damit zu leben.

Was wirklich ganz doof ist, ist das die
Code: [Auswählen]
2014-04-20_20:10:04 FHT_Wohnzimmer mon-from1 08:00 mon-to1 23:30 tue-from1 08:00 tue-to1 23:30 wed-from1 08:00 wed-to1 23:30 thu-from1 08:00 thu-to1 23:30
...
>>> 2014-04-20_20:12:02 FHT_Wohnzimmer mon-from1: 08:00 <<<
genau so aussehen, wie eine Bestätigung von der FHT bzw.

im CUL mode X21 siehst du gar keine Bestätigung vom FHT. D.H. allles was du hier siehst ist wenn das Kommando von Fhem in den Buffer geschrieben wird und später, wenn er dann an das FHT gesendet wird. Ob das Erfolg hatte, siehst du mit X21 gar nicht.

Im FHEM-Log ist es noch schlimmer, da siehst du nur ob's in den Buffer geschrieben wurde.

Es mag doof sein, dass gesendete und empfange Sachen ähnlich aussehen, muss man eben wissen was was bedeutet leider.

Damit bleibt für ein funkgesteuertes Update dann nur eine komplette Übertragung der Tabellen, nicht wie ich es ja offensichtlich vor hatte, nur der Differenzen

.

Nicht unbedingt. 1. Weisst du ja, dass das gruppiert in 5 Befehlen gut durchgeht. 2. könntest du den Status den das FHT hat auslesen (mit readings Val) und vergleichen. Dann weist du was geklappt hat. Das ist allerdings Aufwand (und ich kann dir auch nicht echt helfen dabei, zu wenig Ahnung)

Mir ist leider noch keine vernüftige Lösung zur Fersteuerung eingefallen, die weiterhin ein lokales Übersteuern (Partyfunktion) erlaubt.

Ich weiss nicht genau, was du damit meinst, bzw welches Scenario du abdecken willst. Ich steuere die Temperatur komplett per FHEM. Das hindert mich aber nicht am FHT selbst auch andere Temperaturen einzustellen. Die werden von Fhem eben nur später wieder geändert. Für Abwesenheiten und ähnliche Sonderanforderungen habe ich in FHEM definierte Schalter, die das beeinflussen, was FHEM an die FHTs sendet.

Das Übertragen der (neuen) Tabellen ist nichts regelmässiges, sonder wird die Ausnahme (wie jetzt z.B. zur Osterferien-Zeit) bleiben. Das darf auch ein, zwei Stündchen dauern (sollet aber zu einem definierten Ergebnis führen).

Ich bin ein erklärter Gegner davon, die FHTs so zu steuern, die Funklast ist einfach zu hoch. Aber mal ab und an die Programme ändern geht natürlich und speziell wenn man weiss, dass da auch dauert, kann man das auch machen. Bei RSSI -75 sollte das auch letztlich problemlos gehen. Als zusätzliche Sicherheit kann man wie gesagt auslesen, ob der gewünschte Zustand angekommen ist. Ein Beispiel wie man das für Temperaturen macht steht glaube ich im Wiki. Da wird mit FHT Dummies gearbeitet. Ich denke aber der Aufwand ist nicht nötig.

Btw.: Wie kann ich den Traffik denn nun mal vernünftig berechnen? Wenn ich jetzt solche Vierer-Pakete versende, wie viel Sendezeit kostet das tatsächlich (ideal)? Und wie viele solche Pakete passen in den Sendepuffer?

Man kann, das müsste ich mir aber jetzt wieder zusammenlesen und ausrechnen. Da ... äh... habe ich aber jetzt keine Lust zu. Sorry. Bestimmend ist, das jede Aussendung zu einem einzelnen FHT nur alle (ca.) 2 Minuten erfolgen kann. Wenn du also 5 x 5 Paket an ein FHT senden willst, wird das schon im Idealfall über 10 Minuten dauern. Das ist auch ein weiterer Grund warum man Befehle groupieren will: Die Sendeslots werden besser genutzt.

Die 5x5 Pakete einzeln gesendet verbraucht nicht nur  24x5 = 120 Sendeeinheiten mehr (da jede Kommunikation 5 Sendeeinheiten Handshakeoverhead hat) sondern dauert wegen der FHT Sendeslots nur alle 2 Minuten auch über 48 Minuten, wenn ich das richtig sehe. Das ist also eigentlich der wesentliche Grund, warum man zusammenfassen will. In den CULV3 Buffer passen soweit ich weiss 30 Befehle.
Kriegst du aber einfach raus: Warten bis die Kommunikation zu einem FHT gerade abgeschlossen wurde, schnell (innerhalb 2 Minuten) FHTs Kommandos an das FHT absetze bis EOB Fehlermeldung kommt, Zählen wieviel durchgingen, fertig. Oder Buffer vollmachen und dann Befehle mit

Code Auswählen Erweitern

get CUL raw T02  auslesen und nachzählen.

[habichthugo]

2. könntest du den Status den das FHT hat auslesen (mit readings Val) und vergleichen. Dann weist du was geklappt hat.

Ne, eben das geht nicht. In den Readings (Val) steht ggf. der vom CUL gesendete und vom FHT nicht bestätigte Wert.

Ich weiss nicht genau, was du damit meinst, bzw welches Scenario du abdecken willst.

Nun, ich möchte trotz des eingestellten (oder wie auch immer realisierten) Tagesprogramms die Möglichkeit haben, durch lokale Bedienung an einer FHT nicht nur die Solltemperatur (bis zum nächsten Schaltpunkt), sondern auch den Zeitraum zu verändern (Urlaubs- und/oder Partyfunktion). Ich wüsste nicht, wie ich das ohne den nativen Automatikmodus hin bekommen sollte. Also der 'mode holiday' soll lokal noch funktionieren.

[Zrrronggg!]

Ne, eben das geht nicht. In den Readings (Val) steht ggf. der vom CUL gesendete und vom FHT nicht bestätigte Wert.

Hm. Ist das so? Ich dachte bisher bei FHTs wäre das der vom FHT zurückgemeldete Wert. Immer hin kannst du ja mit Report1=255 alle Wochenprogramme melden lassen und auch erst dann zeigt bei mit FHEM die bei abfrage des FHTs auch an.

Aber das ist echt nicht mein Spezialgebiete, muss ich zugeben.