>
> Leider geht es nicht, von (im Moment) vier FHT80b hat nur einer
> reagiert. Der Log zeigt keine Fehler.
> Kann es sein, dass die FHZ 1300 PC nicht so viele Befehle verschicken
> kann?
Der Befehlsspeicher vom FHZ1300PC ist eher klein, 40 Byte wenn ich
mich recht erinnere, das wären dann ca. 8 Befehle. Das kann also schon
sein, dass der Befehle verschluckt, scheint mir sogar wahrscheinlich.
Allerdings sollten dann EOB (End of Buffer) Meldungen im log
erscheinen.
(Oder kommt die nur bei CULs, weil die eigentlich von culfw erzeugt
wird? Ich weiss es nicht. Kann gut sein, das FHZ1300PC keinen LOVF und
EOB Meldungen abgibt, da bin ich aber unsicher, ich habe keine
FHZ1300)
Du könntest den Softbuffer einschalten, um das Problem zu lösen.
(siehe commandref)
Softbuffer schafft softwareseitig in FHEM einen zusätzlichen Buffer.
Nachteil ist, das die Abarbeitung des Inhaltes sehr lange dauern kann,
also kommandos erst ne stunde später oder so ausgeführt werden. Aber
einen versuch ists wert.
> define act_on_Sommer notify Sommer { if ("%" ne "off"){ fhem("set
> FHT_.* mode manual ;; set FHT_.* desired-temp 8.0 ;; define Sommer_off
> at +00:30:00 set Sommer off") } }
und
>
> define act_on_Winter notify Winter { if ("%" ne "off"){ fhem("set
> FHT_.* mode auto ;; set FHT_.* desired-temp 21.5 ;; define Winter_off
> at +00:30:00 set Winter off") } }
Das erzeugt in der Tat ordentlich Funklast. Sollte an sich gerade noch
gehen, aber wenn man gerade Sachen ausprobiert, wenn man etwas
einrichtet und also damit rumspielt, könntest du in DutyCycle Probleme
laufen, d.h. die maximale Sendedauer überschreiten. Ich würde aus dem
Bauch raus sagen, das wenn du jedes der Scripte 1x innherhalb einer
Stunde ausführen lässt, du bereits an der Grenze der 1% bist.
Siehe Wiki z.b.
http://fhemwiki.de/wiki/Maximal_nutzbare_Geräte
http://fhemwiki.de/wiki/1%25_Regel
Warte mal ne Stunde und versuche es dann noch mal.
> 2012.01.30 13:10:59 2: FS20 set Sommer on
> 2012.01.30 13:10:59 2: FHT set FHT_1526 mode manual
> 2012.01.30 13:10:59 2: FHT set FHT_253c mode manual
> 2012.01.30 13:10:59 2: FHT set FHT_2a2e mode manual
> 2012.01.30 13:10:59 2: FHT set FHT_4a46 mode manual
> 2012.01.30 13:10:59 2: FHT set FHT_5133 mode manual
> 2012.01.30 13:11:00 2: FHT set FHT_563c mode manual
> 2012.01.30 13:11:00 2: FHT set FHT_5b42 mode manual
> 2012.01.30 13:11:00 2: FHT set FHT_1526 desired-temp 8.0
> 2012.01.30 13:11:00 2: FHT set FHT_253c desired-temp 8.0
> 2012.01.30 13:11:00 2: FHT set FHT_2a2e desired-temp 8.0
> 2012.01.30 13:11:00 2: FHT set FHT_4a46 desired-temp 8.0
> 2012.01.30 13:11:00 2: FHT set FHT_5133 desired-temp 8.0
> 2012.01.30 13:11:00 2: FHT set FHT_563c desired-temp 8.0
> 2012.01.30 13:11:00 2: FHT set FHT_5b42 desired-temp 8.0
naja, das log sagt nur, was FHEM an die Zentrale übergeben hat.
Ob die das auch senden konnte sieht man nicht. Mit CUL und CUNO könnte
man
sehen, ob die Befehle auch tatsächlich gesendet wurden, indem man die
Dinger abfragt,
aber die FHZ1300PC kann das nicht, soweit ich weiss.
> Kann man die Befehle öfter verschicken lassen?
Kann man. Aber wenn die Sendelast dein Problem ist, würde das die
Situation nicht verbessern.
> Hab da etwas von einen attr retrycount gesehen, das steht auf 3
Soweit ich weiss hat recount nur dann eine Bedeutung, wenn der
softbuffer eingeschaltet ist.
Und wieso 4 FHTs? Ich sehe da acht Adressen. Kommunikationsversuche
mit FHTs die eingerichtet aber nicht vorhanden sind verbraten auch
Sendezeit!