Wochenplan für FHT setzen

Dr. Boris Neubert · 12 Januar 2008, 01:43:35

Hallo @all,

erstmal vorweg ein grosses Lob an Rudolf für seine tolle Arbeit!

Schon lange habe ich mit diversen Funksystemen zum Schalten meiner
Verbraucher gewerkelt bis ich letztens auf das FS20 gestossen bin. Nun
habe ich begonnen mein Haus mit diversen Komponenten auszustatten:
Steckdosen, Dimmer und Heizungssteuerung. Das ganze habe ich seit zwei
Tagen dann auch mit einer FHZ1300 gekoppelt und pgm3 im Einsatz.
Soweit so gut.

Meine FHT80b ist mit 3 Stellventilen sowie zwei Fensterkontakten
gekoppelt. Im pgm3 kann ich dank gnuplot die Graphen gut zur
Information der gemessenen Werte nutzen.

Nun hatte ich den Wochenplan direkt im FHT eingestellt und möchte
diesen jetzt über fhem neu setzen. Hintergrund: meine Frau arbeit
halbtags wöchentlich im Wechsel vor- oder nachmittags. Je nach Woche
soll also unterschiedlich geheizt werden. Da ich diese Anpassungen
nicht händisch machen will, kam mir die Idee das einem cronjob zu
überlassen.

Also habe ich ein Script geschrieben, das ermittelt ob aktuell eine
gerade oder ungerade Woche ist und je nach Ergebnis einen neuen
Wochenplan setzen soll. Dieser job soll dann später wöchentlich
aufgerufen werden, wenn es denn klappen würde

Wenn ich das Script nun starte, werden die Werte scheinbar gesetzt und
auch gesendet (verbose 5). Im Logfile erscheinen auch die Einträge.
Allerdings werden die Werte (*-from1, *-from2, etc) nicht im FHT
gesetzt. Auch im STATEFILE stehen diese Werte nicht. Habe ich evtl.
etwas vergessen?

Auch hatte ich hier gelesen, das evtl. bei zu schneller Befehlfolge
etwas verschluckt wird. Dazu hatte ich das Script auch schon mal mit
"Sleep 1" nach jedem Befehl gebremst; leider ohne Erfolg.

Hier das Script:

#!/bin/bash

let WEEKNR="`date +%V`%2"

WORK="mon tue wed thu fri"
FREE="sat sun"

FHT1="wz_Heizung"

FHEM_BIN="/usr/local/bin/fhem.pl localhost:7072"
CMD="set"

if [ ${WEEKNR} -eq 0 ]; then
# even = Spätschicht
for DAY in ${WORK}; do
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from1 08:30"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to1 11:30"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from2 16:30"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to2 22:30"
done
for DAY in ${FREE}; do
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from1 08:30"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to1 23:50"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from2 24:00"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to2 24:00"
done
else
# odd = Frühschicht
for DAY in ${WORK}; do
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from1 12:00"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to1 22:30"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from2 24:00"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to2 24:00"
done
for DAY in ${FREE}; do
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from1 08:30"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to1 23:50"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-from2 24:00"
${FHEM_BIN} "${CMD} ${FHT1} ${DAY}-to2 24:00"
done
fi

exit 0

Guest · 12 Januar 2008, 14:07:32

Originally posted by: <email address deleted>

Hallo,

On Jan 12, 1:43 am, "M.Fischer" wrote:
> Auch hatte ich hier gelesen, das evtl. bei zu schneller Befehlfolge
> etwas verschluckt wird. Dazu hatte ich das Script auch schon mal mit
> "Sleep 1" nach jedem Befehl gebremst; leider ohne Erfolg.

Welche Version hast Du im Einsatz?
"Softwarebuffer for FHT devices" aktiv?
Was sagt "list FHZ" vor und nach dem Aufruf deines Skripts?

Gruß
Holger

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dr. Boris Neubert · 12 Januar 2008, 19:43:54

hallo holger,

On 12 Jan., 14:07, sweetie-pie wrote:
> Welche Version hast Du im Einsatz?

Server started (version 4.2 from 2007-12-02 ($Id: fhem.pl,v 1.31
2007/11/27 15:17:47 rudolfkoenig Exp $), pid 31413)

> "Softwarebuffer for FHT devices" aktiv?

nein, hatte ich bis eben noch nicht gesetzt... hab's mal enabled..

> Was sagt "list FHZ" vor und nach dem Aufruf deines Skripts?

abe:~ # fhem.pl localhost:7072 "list FHZ"
Internals:
DEF /dev/ttyUSB0
DeviceName /dev/ttyUSB0
FD 6
NAME FHZ
NR 1
PARTIAL
QUEUECNT 0
STATE raw 04 01010100010000
TYPE FHZ
Readings:
2008-01-12 12:00:53 fhtbuf 43
2008-01-12 12:51:39 init2 1f04a0071c3b40ff
2008-01-12 12:51:39 serial 136e63ff
Softbuffer:

abe:~ # /usr/local/src/heizungsplan
abe:~ # fhem.pl localhost:7072 "list FHZ"
Internals:
DEF /dev/ttyUSB0
DeviceName /dev/ttyUSB0
FD 6
NAME FHZ
NR 1
PARTIAL
QUEUECNT 0
STATE raw 04 01010100010000
TYPE FHZ
Readings:
2008-01-12 12:00:53 fhtbuf 43
2008-01-12 12:51:39 init2 1f04a0071c3b40ff
2008-01-12 12:51:39 serial 136e63ff
Softbuffer:

gruß martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

rudolfkoenig · 12 Januar 2008, 21:58:42

On 12 Jan., 19:43, "M.Fischer" wrote:
> > "Softwarebuffer for FHT devices" aktiv?
>
> nein, hatte ich bis eben noch nicht gesetzt... hab's mal enabled..
>

dabei bin ich dem beispiel aus der command reference gefolgt:

attr FHZ softbuffer 0 # disable the softbuffer for FHT devices
attr FHZ softrepeat 300 # resend failed commands to FHT devices after
300 seconds
attr FHZ softmaxretry 4 # stop resending failed commands to FHT
devices after 4 retries.

allerdings treten dann fehler auf:

2008.01.12 19:46:16 1: Unknown attribute softbuffer, use attr global
userattr (room comment do_not_notify:1,0 dummy
:1,0 filtertimeout repeater:1,0 showtime:1,0 model:fhz1000,fhz1300
loglevel:0,1,2,3,4,5,6 fhtsoftbuffer:1,0)
2008.01.12 19:46:16 1: Unknown attribute softrepeat, use attr global
userattr (room comment do_not_notify:1,0 dummy
:1,0 filtertimeout repeater:1,0 showtime:1,0 model:fhz1000,fhz1300
loglevel:0,1,2,3,4,5,6 fhtsoftbuffer:1,0)
2008.01.12 19:46:16 1: Unknown attribute softmaxretry, use attr global
userattr (room comment do_not_notify:1,0 dum
my:1,0 filtertimeout repeater:1,0 showtime:1,0 model:fhz1000,fhz1300
loglevel:0,1,2,3,4,5,6 fhtsoftbuffer:1,0)

gruß martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dr. Boris Neubert · 13 Januar 2008, 11:23:26

Hallo,

Am Samstag, 12. Januar 2008 schrieb M.Fischer:
> On 12 Jan., 19:43, "M.Fischer" wrote:
> > > "Softwarebuffer for FHT devices" aktiv?
> >
> > nein, hatte ich bis eben noch nicht gesetzt... hab's mal enabled..
>
> dabei bin ich dem beispiel aus der command reference gefolgt:
>
> attr FHZ softbuffer 0 # disable the softbuffer for FHT devices
> attr FHZ softrepeat 300 # resend failed commands to FHT devices after
> 300 seconds
> attr FHZ softmaxretry 4 # stop resending failed commands to FHT
> devices after 4 retries.

sieht aus, als ob die Doku hier nicht der Wirklichkeit entspricht.

fhtsoftbuffer ist das Attribut an der FHZ:

   attr myFHZ fhtsoftbuffer 1

retrycount ist das Attribut an der FHT

   attr myFHT retrycount 4

retryafter ist für die FHTs auf 240s hardkodiert.

Grüße,
Boris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Martin Fischer · 13 Januar 2008, 13:56:45

hallo boris,

Am Sonntag, 13. Januar 2008 schrieb Boris Neubert:
>
> sieht aus, als ob die Doku hier nicht der Wirklichkeit entspricht.
>
> fhtsoftbuffer ist das Attribut an der FHZ:
>
> attr myFHZ fhtsoftbuffer 1
>
> retrycount ist das Attribut an der FHT
>
> attr myFHT retrycount 4
>
> retryafter ist für die FHTs auf 240s hardkodiert.

prima! das hat jetzt geklappt!

allerdings besteht das geschilderte problem mit dem anfangs erwähnten script
weiterhin. der fht übernimmt einfach nicht die einstellungen für *-from und
*-to.

gruß martin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Guest · 13 Januar 2008, 14:23:06

Originally posted by: <email address deleted>

On Jan 13, 1:56 pm, Martin Fischer wrote:
> allerdings besteht das geschilderte problem mit dem anfangs erwähnten script
> weiterhin. der fht übernimmt einfach nicht die einstellungen für *-from und

Hmm, irgendwie stimmen aber die Ausgaben über den Buffer nicht... ich
erwarte ertwas in der Art, wie es auch in der Anleitung steht...

FHZ> list fl

Internals:
CODE 5102
DEF 5102
NAME fl
NR 15
STATE measured-temp: 21.1 (Celsius)
TYPE FHT
IODev FHZ
Attributes:
room Heizung
Readings:
2006-11-02 09:45:56 actuator 19%
[....]
Send buffer:
2007-10-19 00:31:24 desired-temp 22.5
2007-10-19 00:33:20 mode auto

und list FHZ zeigt keine Veränderungen am Buffer... ich kann das bei
mir gerade auch nachvollzuiehen, das war aber defacto schon mal
anders... ich guck mir das nochmal an, aber heute wird das nichts
mehr... vielleicht kann ja jemand anders noch mal bei seiner
Installation prüfen...

Gruß
Holger
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

nobody0472 · 14 Januar 2008, 16:12:44

Am Sonntag, 13. Januar 2008 schrieb sweetie-pie:
> On Jan 13, 1:56 pm, Martin Fischer wrote:
> > allerdings besteht das geschilderte problem mit dem anfangs erwähnten
> > script weiterhin. der fht übernimmt einfach nicht die einstellungen für
> > *-from und

aaaalso:

nachdem ich nun wieder zu hause bin (hatte die ganze zeit aus 350 km
entfernung getestet) habe ich erstmal die fht80b neu bei der fhz angemeldet
(prog -> cent -> n.a.).. inzwischen hatte ich nämlich das problem das
überhaupt keine daten mehr von der fhz empfangen werden..

auch fhtsoftbuffer scheint jetzt zu klappen:
FHZ> list FHZ
Internals:
DEF /dev/ttyUSB0
DeviceName /dev/ttyUSB0
FD 6
NAME FHZ
NR 1
NR_CMD_LAST_H 37
PARTIAL
QUEUECNT 0
SOFTBUFFERTIMER 1
STATE time
TYPE FHZ
Readings:
2008-01-14 15:35:05 init2 1f04a0011c3b40ff
2008-01-14 15:35:06 serial 136e63ff
Softbuffer:
3:1200321307.23368:0:
ARG 0201830b2565ff66ff
CMD refreshvalues
HASH wz.Heizung
NSENT 2
SENDTIME 1200321585.04612
VAL
9:1200321322.72071:1:
ARG 0201830b251448
CMD mon-from1
HASH wz.Heizung
NSENT 2
SENDTIME 1200321585.04612
VAL 12:00
9:1200321385.95819:5:
ARG 0201830b251848
CMD tue-from1
HASH wz.Heizung
NSENT 2
SENDTIME 1200321658.66692
VAL 12:00
9:1200321424.66759:6:
ARG 0201830b251987
CMD tue-to1
HASH wz.Heizung
NSENT 1
SENDTIME 1200321424.66761
VAL 22:30

usw. usw.

das logfile sagt auch aus, das die daten gesendet werden:

2008.01.14 15:35:12 0: Server started (version =VERS= from =DATE= ($Id:
fhem.pl,v 1.36 2007/12/31 14:43:02 rudolfkoenig Exp $), pid 2702)
2008.01.14 15:35:22 2: FHT set wz.Heizung mon-from1 12:00
2008.01.14 15:36:04 2: FHT set wz.Heizung mon-from2 00:00
2008.01.14 15:36:04 2: FHT set wz.Heizung mon-to1 22:30
2008.01.14 15:37:04 2: FHT set wz.Heizung tue-from1 12:00
2008.01.14 15:37:04 2: FHT set wz.Heizung mon-to2 00:00
2008.01.14 15:37:04 2: FHT set wz.Heizung tue-to1 22:30
2008.01.14 15:37:04 2: FHT set wz.Heizung tue-from2 00:00
2008.01.14 15:37:46 2: FHT set wz.Heizung tue-to2 00:00
2008.01.14 15:37:46 2: FHT set wz.Heizung wed-from1 12:00

und der fht übernimmt sie wohl auch:

FHZ> list wz.Heizung
Internals:
CODE 0b25
DEF 0b25
IODev FHZ
NAME wz.Heizung
NR 9
STATE code_7e0067: 72
TYPE FHT
Readings:
2008-01-13 21:53:40 actuator 00%
2008-01-14 15:41:13 code_4b0067 0
2008-01-14 15:58:02 code_7e0067 72
2008-01-14 15:41:09 day-temp 21.5 (Celsius)
2008-01-14 15:41:11 desired-temp 23.5 (Celsius)
2008-01-14 15:41:04 fri-from1 12:00
2008-01-14 07:53:02 fri-from2 16:30
2008-01-14 15:41:04 fri-to1 11:30
2008-01-14 15:41:05 fri-to2 22:30
2008-01-14 15:33:09 init 255
2008-01-14 07:53:08 lowtemp-offset 4.0 (Celsius)
2008-01-14 15:41:12 measured-high 0
2008-01-14 15:41:11 measured-low 217
2008-01-14 15:41:12 measured-temp 21.7 (Celsius)
2008-01-14 15:41:12 mode auto
2008-01-14 07:52:56 mon-from1 12:00
2008-01-14 15:42:56 mon-from2 00:00
2008-01-14 15:46:17 mon-to1 22:30
2008-01-14 15:48:15 mon-to2 00:00
2008-01-14 15:41:09 night-temp 16.0 (Celsius)
2008-01-14 15:41:06 sat-from1 08:30
2008-01-13 17:52:57 sat-from2 09:00
2008-01-14 15:41:06 sat-to1 23:50
2008-01-13 15:47:41 sat-to2 23:50
2008-01-14 15:41:07 sun-from1 08:30
2008-01-13 15:47:42 sun-from2 09:00
2008-01-14 14:32:26 sun-to1 23:50
2008-01-13 17:52:58 sun-to2 23:00
2008-01-14 15:58:02 thu-from1 12:00
2008-01-14 15:41:03 thu-from2 16:30
2008-01-14 15:41:03 thu-to1 11:30
2008-01-14 15:41:03 thu-to2 22:30
2008-01-14 07:56:52 tue-from1 12:00
2008-01-14 15:50:12 tue-from2 00:00
2008-01-14 09:32:49 tue-to1 22:30
2008-01-14 07:52:58 tue-to2 22:30
2008-01-14 15:41:13 warnings none
2008-01-14 15:41:01 wed-from1 12:00
2008-01-14 15:54:07 wed-from2 00:00
2008-01-14 15:52:10 wed-to1 22:30
2008-01-14 15:56:05 wed-to2 00:00
2008-01-14 15:41:10 windowopen-temp 10.0 (Celsius)

was ich nun festgestellt habe ist, das es sehr lange dauert, bis die neuen
settings übertragen werden. der softbuffer hat 'ne menge einträge und im
logfile sieht man das die befehle tröpfchenweise gesetzt werden. gestartet
hatte ich um ca. 15:35 und aktuell um 16:00 ist er immer noch am senden.

gerade eben kommt noch ein:

2008.01.14 15:58:20 2: FHT set wz.Heizung fri-to2 00:00
2008.01.14 16:00:20 2: FHT set wz.Heizung fri-from2 00:00
2008.01.14 16:02:21 2: wz.Heizung set fri-to2 00:00: no confirmation after 5
tries, giving up
2008.01.14 16:02:21 2: FHT set wz.Heizung sun-to1 23:50

dazwischen.. da das alles noch ziemliches neuland für mich ist frage ich mich
ob dieses verhalten so richtig ist.

ist es so, das wenn ein befehl übertragen wurde, dieser dann nicht mehr im
softbuffer bei einem list FHZ auftaucht? heisst das im umkehrschluss, das
alle sonstigen noch nicht gesendet wurden?

wenn dem so ist, frage ich mich dann allerdings, warum einige tage übertragen
werden und andere wiederum nicht? wo kann ich / sollte ich hier ansetzen?

auch ist mir noch nicht klar welchen wert ich bei einem *-from/*-to setzen
muss um diesen timer zu löschen? gelesen habe ich 24:00, doch dann steht bei
einem list immer noch der alte wert drin. jetzt habe ich mal mit 00:00
probiert, der dann auch auftaucht.

aktuell ist es zudem auch noch so, das zwar die gemessene temperatur
übertragen wird, doch nicht mehr der stellwert der actuatoren?

also fragen über fragen zum thema heizungssteuerung..

nochmal zum hintergrund:
ich möchte mittels eines scriptes feststellen, ob eine ungerade oder eine
gerade woche ist. abhängig von dem ergebnis soll dann der wochenplan neu
gesetzt werden. das inzwischen überarbeitet script sieht aktuell so aus:

#!/bin/bash

let WEEK="`date +%V`%2"

WEEKFILE="/var/fhem/week"
FHEM_BIN="/usr/local/bin/fhem.pl localhost:7072"

WORK="mon tue wed thu fri"
FREE="sat sun"

FHT_SET="wz.Heizung"
CMD="set"

[[ -f ${WEEKFILE} ]] && {
. ${WEEKFILE}
[[ ${WEEK} = ${LAST} ]] && echo "$0: nothing to do..." && exit 0
}

echo "LAST=${WEEK}" > ${WEEKFILE}

for FHT in ${FHT_SET}; do
if [ ${WEEK} -eq 0 ]; then
# even = Spätschicht
for DAY in ${WORK}; do
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from1 08:30"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to1 11:30"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from2 16:30"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to2 22:30"
done
for DAY in ${FREE}; do
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from1 08:30"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to1 23:50"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from2 00:00"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to2 00:00"
done
else
# odd = Frühschicht
for DAY in ${WORK}; do
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from1 12:00"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to1 22:30"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from2 00:00"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to2 00:00"
done
for DAY in ${FREE}; do
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from1 08:30"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to1 23:50"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-from2 00:00"
${FHEM_BIN} "${CMD} ${FHT} ${DAY}-to2 00:00"
done
fi
done

exit 0

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dirk · 14 Januar 2008, 17:03:57

Hallo Martin,

> was ich nun festgestellt habe ist, das es sehr lange dauert, bis die neuen

> settings übertragen werden. der softbuffer hat 'ne menge einträge und im
> logfile sieht man das die befehle tröpfchenweise gesetzt werden. gestartet

> hatte ich um ca. 15:35 und aktuell um 16:00 ist er immer noch am senden.

das ist Systembedingt. Die FHT's holen sich ca. alle 150 sec. Jeweils EINEN
"neuen Befehl" aus der FHZ ab. Daher kann es bei sehr vielen Befehlen recht
lange dauern (auch schon mal eine Stunde) bis die alle Befehle beim
jeweiligen FHT angekommen sind.

Der Softbuffer soll nur sicherstellen, dass kein Befehl verloren geht, oder
vom recht kleinen Hardwarebuffer der FHZ "vergessen" wird.

Gruß
Dirk

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dr. Boris Neubert · 14 Januar 2008, 17:51:48

hallo dirk,

Am Montag, 14. Januar 2008 schrieb Dirk Hoffmann:
> das ist Systembedingt. Die FHT's holen sich ca. alle 150 sec. Jeweils EINEN
> "neuen Befehl" aus der FHZ ab. Daher kann es bei sehr vielen Befehlen recht
> lange dauern (auch schon mal eine Stunde) bis die alle Befehle beim
> jeweiligen FHT angekommen sind.
>
> Der Softbuffer soll nur sicherstellen, dass kein Befehl verloren geht, oder
> vom recht kleinen Hardwarebuffer der FHZ "vergessen" wird.

ok.. dann ist das verständlich. wenn jedoch die meldung

2008.01.14 16:19:51 2: wz.Heizung set sun-to1 23:50: no confirmation after 5
tries, giving up

ausgegeben wird, ist dann die übertragung für diesen befehl definitiv
gescheitert? da das so ein- bis zweimal vorkommt, bedeutet dieses dann
folglich, das mein neuer wochenplan nicht komplett gesetzt wurde

wie kann ich das sicherstellen?

was mir auch noch aufgefallen ist: wenn ich den wochenplan setze, sendet die
fht ab diesem zeitpunkt nicht mehr die gemessenen werte. ich habe auch noch
nicht den zusammenhang raus, auch weiss ich noch nicht, ab wann dann die
daten wieder übertragen werden.

aktuell hatte ich wie in vorheriger mail geschrieben um 15:35 uhr mein script
gestartet. jetzt haben wir 17:50 uhr und mehrere refreshvalues sind
rausgegangen, aber der letzte eintrag von der gemessenen temperatur ist von
15:41 uhr. kann es sein, das so lange immer noch der wochenplan gesendet
wird, keine daten von der fht empfangen werden? oder das die fht solange
geblockt ist?

irgendwie ist hier der wurm drin.

gruss martin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dr. Boris Neubert · 14 Januar 2008, 18:06:05

Originally posted by: <email address deleted>

Hi,

Dirk Hoffmann:
> das ist Systembedingt. Die FHT's holen sich ca. alle 150 sec. Jeweils
> EINEN "neuen Befehl" aus der FHZ ab.

Hmm. Mein Verständnis ist:

Die FHTs senden zwar alle 116 sec eine neue Thermostatstellung. Jedoch
ist der Dialog mit der FHZ davon relativ unabhängig. Meine fragte
zuletzt zu folgenden Zeiten die FHT ab:

15:44:29
16:00:29
16:13:18
16:28:46
16:44:29
17:00:29
17:13:14
17:28:42
17:44:29

Eine besondere Systematik kann ich daran nicht unbedingt erkennen :-/
außer dass sich das Spiel stündlich wiederholt. (FHT #2 steht zwar nur
10m weit von meinem Empfänger weg, aber der ist zu ungünstig platziert,
so dass ich vom Dialog damit nicht viel mitkriege.)

Ich werde demnächst versuchen, mit meinem Code die FHT direkt zu
befragen -- befürchte jedoch, dass dazu die interne Verzögerung zu
hoch ist, zumal das Ganze noch durch zwei Rechner wandert.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Some husbands are living proof that a woman can take a joke.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dirk · 14 Januar 2008, 18:20:14

> 2008.01.14 16:19:51 2: wz.Heizung set sun-to1 23:50: no confirmation after
> 5 tries, giving up

Du könntest versuchen retrycount noch höher zu stellen. Da es keine
bidirektionale Übertragung ist, kann es vorkommen, dass Funkbefehle verloren
gehen.
Ansonsten versuch einmal das Setzen des Wochenplans von mehreren fht's
weiter auseinander zu legen. Vor allem bei mehreren FHT's kann es recht
schnell zu Funk-Kollisionen kommen.

> da das so ein- bis zweimal vorkommt, bedeutet dieses dann
> folglich, das mein neuer wochenplan nicht komplett gesetzt wurde

> wie kann ich das sicherstellen?

Ansonsten könnte man per Script auswerten, ob es Fehler bei der Übertragung
gab, und bei Bedarf nach einer Pause die betreffenden Befehle erneut senden.

Da der Softbuffer recht neu ist, ist es auch nicht ausgeschlossen, dass da
noch der ein oder andere Bug drin ist. Daher währ interessant ob und wie das
ganze bei den anderen funktioniert.

> was mir auch noch aufgefallen ist: wenn ich den wochenplan setze, sendet <
> die fht ab diesem zeitpunkt nicht mehr die gemessenen werte. ich habe auch
> noch nicht den zusammenhang raus, auch weiss ich noch nicht, ab wann dann
> die daten wieder übertragen werden.

Was hast du für eine FHZ? Ich hatte eine FHZ1000, bei der gab es ähnliche
Probleme wenn ich die Zeit eines FHZ's gesetzt habe. Dann hatte er aufgehört
seine Stellwert-Daten zu senden. Ich hatte gelesen, dass das wohl ein Bug in
der FHZ1000 ist. Seit dem ich eine FHZ1300 habe, gibt es hier kein Problem
mehr.

> jetzt haben wir 17:50 uhr und mehrere refreshvalues sind
> rausgegangen, aber der letzte eintrag von der gemessenen temperatur ist
> von 15:41 uhr. kann es sein, das so lange immer noch der wochenplan
> gesendet wird, keine daten von der fht empfangen werden? oder das die fht
> solange geblockt ist?

Sind noch Einträge von ungesendeten Befehlen im Softbuffer? Dann kann das
schon sein.

Gruss Dirk

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dirk · 14 Januar 2008, 18:34:29

> Hmm. Mein Verständnis ist:

> Die FHTs senden zwar alle 116 sec eine neue Thermostatstellung. Jedoch
> ist der Dialog mit der FHZ davon relativ unabhängig. Meine fragte
> zuletzt zu folgenden Zeiten die FHT ab:

> 15:44:29
> 16:00:29

Die FHT's senden Ihre Werte normalerweise nur wenn diese sich geändert
haben. So war es mal irgendwo dokumentiert. Wobei das teilweise auch öfters
passiert. Hab da auch keine Ahnung was da noch alles mit rein spielt.

Die Kommunikation zwischen Stellantrieb und dem FHT finden alle ca. 120 sec.
Statt. Das regelt der FHT auch vollkommen alleine ohne Einflussmöglichkeit
durch die Zentrale. Daher kann man die Stellantriebe auch nicht direkt
ansteuern

Die Kommunikation von FHZ zu FHT findet auch nur auf "Anfrage" statt, da die
FHT's nicht ständig auf Empfang sind. Wenn man ein Befehl an einen FHT
absetzt, dann wird dieser zunächst im Puffer der FHZ zwischengespeichert.
Alle ca. 150 sec. Meldet sich der FHT bei der Zentrale und "fragt ob es neue
Befehle gibt". Dabei wird ein zuvor empfangener Befehl dann auch bestätigt.
Der FHT geht dann kurz "auf Empfang" und die FHZ sendet in diesem
Zeitfenster den Befehl an den FHT.

Gruss
Dirk

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Martin Fischer · 14 Januar 2008, 18:52:14

Am Montag, 14. Januar 2008 schrieb Dirk Hoffmann:
> > 2008.01.14 16:19:51 2: wz.Heizung set sun-to1 23:50: no confirmation
> > after 5 tries, giving up
>
> Du könntest versuchen retrycount noch höher zu stellen. Da es keine
> bidirektionale Übertragung ist, kann es vorkommen, dass Funkbefehle
> verloren gehen.

dann werde ich das wohl mal machen...

> Ansonsten versuch einmal das Setzen des Wochenplans von mehreren fht's
> weiter auseinander zu legen. Vor allem bei mehreren FHT's kann es recht
> schnell zu Funk-Kollisionen kommen.

bisher habe ich nur eine im einsatz. ich plane jedoch noch 2-3 hinzu zu
nehmen. ist natürlich interessant das schon mal im hinterkopf zu behalten.

> > da das so ein- bis zweimal vorkommt, bedeutet dieses dann
> > folglich, das mein neuer wochenplan nicht komplett gesetzt wurde

> >
> > wie kann ich das sicherstellen?
>
> Ansonsten könnte man per Script auswerten, ob es Fehler bei der Übertragung
> gab, und bei Bedarf nach einer Pause die betreffenden Befehle erneut
> senden.

ich werde das mal im auge behalten. sollten die meldungen auch nach hochsetzen
des retrycounts bestehen, werde ich mir da mal einen kopf drüber machen. ich
meine auch schon so ein perl-script irgendwo gesehen zu haben.

> Da der Softbuffer recht neu ist, ist es auch nicht ausgeschlossen, dass da
> noch der ein oder andere Bug drin ist. Daher währ interessant ob und wie
> das ganze bei den anderen funktioniert.

das würde mich auch mal interessieren..

> > was mir auch noch aufgefallen ist: wenn ich den wochenplan setze, sendet
> > < die fht ab diesem zeitpunkt nicht mehr die gemessenen werte. ich habe
> > auch noch nicht den zusammenhang raus, auch weiss ich noch nicht, ab wann
> > dann die daten wieder übertragen werden.
>
> Was hast du für eine FHZ? Ich hatte eine FHZ1000, bei der gab es ähnliche
> Probleme wenn ich die Zeit eines FHZ's gesetzt habe. Dann hatte er
> aufgehört seine Stellwert-Daten zu senden. Ich hatte gelesen, dass das wohl
> ein Bug in der FHZ1000 ist. Seit dem ich eine FHZ1300 habe, gibt es hier
> kein Problem mehr.

also ich habe hier eine FHZ1300. aber ich habe bemerkt, das es mit dem
nächsten absatz zu tun hat.

> > jetzt haben wir 17:50 uhr und mehrere refreshvalues sind
> > rausgegangen, aber der letzte eintrag von der gemessenen temperatur ist
> > von 15:41 uhr. kann es sein, das so lange immer noch der wochenplan
> > gesendet wird, keine daten von der fht empfangen werden? oder das die fht
> > solange geblockt ist?
>
> Sind noch Einträge von ungesendeten Befehlen im Softbuffer? Dann kann das
> schon sein.

und genau so war es... kaum war der buffer leer fängt die fht das sprechen
wieder an:
hier noch die letzten gesendeten daten:
2008-01-14_15:41:10 wz.Heizung windowopen-temp: 10.0 (Celsius)
2008-01-14_15:41:11 wz.Heizung desired-temp: 23.5 (Celsius)
2008-01-14_15:41:12 wz.Heizung measured-temp: 21.7 (Celsius)

ab hier dann schluss.. erst jetzt geht es weiter:

2008-01-14_18:19:01 wz.Heizung actuator: 38%
2008-01-14_18:19:12 wz.Heizung day-temp: 21.5 (Celsius)
2008-01-14_18:19:12 wz.Heizung night-temp: 16.0 (Celsius)
2008-01-14_18:19:13 wz.Heizung windowopen-temp: 10.0 (Celsius)
2008-01-14_18:19:13 wz.Heizung lowtemp-offset: 4.0 (Celsius)
2008-01-14_18:19:14 wz.Heizung desired-temp: 25.0 (Celsius)
2008-01-14_18:19:15 wz.Heizung measured-temp: 22.9 (Celsius)
2008-01-14_18:20:58 wz.Heizung actuator: 38%
2008-01-14_18:22:56 wz.Heizung actuator: 38%
2008-01-14_18:22:57 wz.Heizung measured-temp: 22.9 (Celsius)

im fhem.log sieht man, das er wohl noch befehle aus dem buffer abgearbeitet
hatte:
2008.01.14 17:51:37 2: FHT set wz.Heizung tue-to1 22:30
2008.01.14 17:53:39 2: FHT set wz.Heizung refreshvalues
2008.01.14 17:57:39 2: wz.Heizung set refreshvalues : no confirmation after 5
tries, giving up
2008.01.14 18:35:12 2: FHT set wz.Heizung refreshvalues

demnach erkenne ich also einen zusammenhang. die frage ist nur: wer blockt den
verkehr? fhem.pl wegen dem softbuffer oder die fht, weil sie noch beschäftigt
ist? letzteres kann ich mir eigentlich nicht vorstellen.

in der zeit wo keine daten der fht gesendet wurden stand der STATE auf
code_7e0067: 135. aber auch mal eine 50. was sagt der code aus?

gruss martin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Dr. Boris Neubert · 14 Januar 2008, 19:57:36

Originally posted by: <email address deleted>

Hi,

Dirk Hoffmann:
> Alle ca. 150 sec. Meldet sich der FHT bei der Zentrale und "fragt ob es neue
> Befehle gibt". Dabei wird ein zuvor empfangener Befehl dann auch bestätigt.

Wie soll diese Frage aussehen? Ich sehe davon nichts in meinem Empfänger,
und der spuckt mir alles aus, was einigermaßen nach FS20 aussieht.

http://fhz4linux.info/tiki-index.php?page=FHZ%20%2F%20FHT%20 Radio%20Protocol
sagt, dass die Kommunikation (zumindest, wenn man aktiv mit der FHT
kommunizieren will -- wenn die FHT von sich aus was sendet, tut sie das
offenbar ca. einmal pro Viertelstunde dann, wenn sei dazu Lust hat)
direkt nach einem Ventilsteuerkommando zu geschehen hat, und die sind
hier alle 116 sec zu sehen.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I have not yet begun to byte!

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHZ1000 users on Linux" group.
To post to this group, send email to FHZ1000-users-on-unix@googlegroups.com
To unsubscribe from this group, send email to FHZ1000-users-on-unix-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/FHZ1000-users-on-unix?hl=en
-~----------~----~----~----~------~----~------~--~-

Wochenplan für FHT setzen

Guest

Guest