Wochenplan für FHT setzen

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

Vorheriges Thema - Nächstes Thema

Dirk

                                                   

Hi,

Matthias Urlichs

> 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.

Diese Information habe ich aus der Dokumentation der FHZ1000PC.dll
Schick ich dir als Mail.

Gruss
Dirk

--
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
-~----------~----~----~----~------~----~------~--~-

Guest

Originally posted by: <email address deleted>

> > 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%20P...
> 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.

Also ich habe mich bevor dieses tolle Projekt so weit war, mal selber
um die Programmierung/Entwicklung einer Zentrale gekümmert. Grob bin
ich zu folgenden Schluss gekommen:

Die Regler senden alle 116 - 121 Sek. den aktuellen Stellwert an die
Ventile. Dieser Wert variiert in den Granzen nach einem bestimmten
Muster, damit sich mehrere Regler nicht zufällig dauerhaft beim Senden
überbügeln. Stellglied und Regler sind synchronisiert, da das
Stellglied ein nur Empfangsfenster hat, wo der Empfänger ein ist. Das
schon die Batterie.
Ist der Regler an einer Zentrale angemeldet, schaltet er unmittelbar
nach dem Aussenden des Stellwerts seinen Empfänger ein, um evtl.
Befehle von der Zentrale zu empfangen. Daraus ergibt sich eine bei
leeren Buffer in der Zentrale min. eine Verzögerung von 1- ~120 Sek
bis ein per fhem abgesetzter Befehl am Regler ankommt. Die Zentrale
startet dabei die Kommunikation mit dem Regler, da Ihr Empfangsteil
auf Grund des Netzbetriebs dauerhaft eingeschaltet bleiben kann und
sie somit den Zeitpunkt durch das Stellwert-Telegramm erkennt.
Darüber hinaus geht i.d.R. 4x pro Stunde ein etwas umfangreicheres
Telegramm zwischen Regler und Zentrale hin und her. Die Zeitabstände
sind ein vielfaches der oben beschrieben Abstände....

Was mit allerdings auch aufgefallen ist, ist dass fhem tatsächlich
jeden Befehl einzeln zum Regler sendet. Mit der Orginalsoftware geht
das in einem Rutsch, was ich z.B. bei den Datentelegrammen mitgeloggt
habe. Außerdem ist es beim umgekehrten Weg Regler zu Zentrale auch so
(refresh values). Aber ganzehrlich: Mich hat das nie gestört.

@Martin:
Wieso willst Du die Regler denn Programmieren? Ist dein fhem nicht im
Dauerbertieb? Schalte doch zu den gegeben Zeiten direkt, entweder per
at-Job oder auch per Script wenn Du willst....
--~--~---------~--~----~------------~-------~--~----~
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

Am Dienstag, 15. Januar 2008 schrieb sweetie-pie:
> Was mit allerdings auch aufgefallen ist, ist dass fhem tatsächlich
> jeden Befehl einzeln zum Regler sendet. Mit der Orginalsoftware geht
> das in einem Rutsch, was ich z.B. bei den Datentelegrammen mitgeloggt
> habe. Außerdem ist es beim umgekehrten Weg Regler zu Zentrale auch so
> (refresh values). Aber ganzehrlich: Mich hat das nie gestört.

also ich empfinde das schon als störend. wenn ich mal mein wochenplan-script
als beispiel nehme, so werden dann für jeden tag 2x from und 2x to gesetzt.
und das für die ganze woche. d.h. fhem muss dann 28 befehle absetzen. dadurch
kommt natürlich aufgrund der von euch geschilderten funktionsweise ein recht
hoher delay zu stande. besonders, wenn es bei der übertragung hin und wieder
zu übertragungsproblemen kommt und ein telegramm nicht abgesetzt werden kann.
dann wird der delay noch grösser, je nach gesetztem retrycount. besser wäre
es, wenn nur ein telegramm erzeugt werden würde. zumal ich auch einen
zusammenhang mit dem empfang der messwerte sehe. wie ich geschrieben hatte
scheint in der zeit, wo der softbuffer abgearbeitet wird (und das hat ja bei
mir ewig gedauert) fhem keine telegramme von der fht entgegen zu nehmen. das
hat wiederum zur folge, das gnuplot dann ziemlich viele lücken aufweisst.

> @Martin:
> Wieso willst Du die Regler denn Programmieren? Ist dein fhem nicht im
> Dauerbertieb? Schalte doch zu den gegeben Zeiten direkt, entweder per
> at-Job oder auch per Script wenn Du willst....

sicher wär das auch eine möglichkeit. der server läuft eh 24x7x365. doch
eigentich finde ich meine geplante variante etwas charmanter.

erstens ist dann der fht autark. also auch wenn ich mal meinen server ausser
betrieb nehme ist gewährleistet, das der wochenplan gesetzt ist.

und zweitens wäre dann ja noch die oben geschilderte problematik. aus dieser
sicht fände ich es schon sinnvoller, wenn nur einmal die woche ein telegramm
mit dem für diese woche geltenden zeiträumen gesendet wird.

zur zeit ist es z.b. so, das der fht wieder mal nichts meldet. gestern abend
schien es (wie meiner letzten mail zu entnehmen ist) endlich alles zu laufen
und nun ist schon wieder seit 23:53 oder so funkstille. ich habe aber
mittlerweile auch keine idee mehr, woran es liegen könnte.

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
-~----------~----~----~----~------~----~------~--~-
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Guest

Originally posted by: <email address deleted>

Hi,

Martin Fischer:
> also ich empfinde das schon als störend. wenn ich mal mein wochenplan-script
> als beispiel nehme, so werden dann für jeden tag 2x from und 2x to gesetzt.
> und das für die ganze woche. d.h. fhem muss dann 28 befehle absetzen. dadurch
> kommt natürlich aufgrund der von euch geschilderten funktionsweise ein recht
> hoher delay zu stande.

Tja, da hilft wohl nur selbermachen...

> zur zeit ist es z.b. so, das der fht wieder mal nichts meldet. gestern abend
> schien es (wie meiner letzten mail zu entnehmen ist) endlich alles zu laufen
> und nun ist schon wieder seit 23:53 oder so funkstille. ich habe aber
> mittlerweile auch keine idee mehr, woran es liegen könnte.

... und das Ding aktiv nach seinen Werten fragen, wenn er sie nicht
freiwillig sendet.

(Ich hab gut reden, mein Code kann das auch nicht. *NOCH* nicht. :P )

--
Matthias Urlichs  |  {M:U} IT Design @ m-u-it.de  |   smurf@smurf.noris.de
Disclaimer: Das Zitat wurde zufällig ausgewählt.  |   http://smurf.noris.de
 - -
Körperliche Abwesenheit ist besser als Geistesgegenwart.

--~--~---------~--~----~------------~-------~--~----~
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

                                                   

> > und das für die ganze woche. d.h. fhem muss dann 28 befehle absetzen. dadurch
> > kommt natürlich aufgrund der von euch geschilderten funktionsweise ein recht
> > hoher delay zu stande.
>
> Tja, da hilft wohl nur selbermachen...

Oder 11_FHT.pm erweitern: Angeblich kann man FHT Befehle auch
zusammenfassen (hintereinander "kleben"), und diese als einen Befehl
dem FHZ uebergeben. Mit dem softbuffer waere sowas auch einfacher zu
realisieren. Ob der FHZ dann diese einzeln oder im Paket dem FHT
weitergibt, dass weiss ich nicht. Freiwillige? Wer keine Lust zum Perl-
Programmieren verspuert kann immer noch helfen, und per "set FHZ raw /
get FHZ fhtbuf / FHT beobachten" rausfinden, ob meine Behauptungen
wahr sind, und das Programmieren ueberhaupt lohnt.

Gruss,
  Rudi
--~--~---------~--~----~------------~-------~--~----~
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

hallo matthias,

Am Dienstag, 15. Januar 2008 schrieb Matthias Urlichs:
> Martin Fischer:
> > also ich empfinde das schon als störend. wenn ich mal mein
> > wochenplan-script als beispiel nehme, so werden dann für jeden tag 2x
> > from und 2x to gesetzt. und das für die ganze woche. d.h. fhem muss dann
> > 28 befehle absetzen. dadurch kommt natürlich aufgrund der von euch
> > geschilderten funktionsweise ein recht hoher delay zu stande.
>
> Tja, da hilft wohl nur selbermachen...

ne schon klar :-) mal spaß beiseite: würde ja nicht ernsthaft sinn machen hier
einen fork aufzumachen. vielleicht wäre es aber möglich seitens der
entwickler diese thematik mal auszugreifen. besonders, weil ja erwähnt wurde,
dass das feature softbuffer noch recht neu ist. wenn es das protokoll
hergibt, das mehrere befehlsfolgen in einem telegramm gesendet werden können,
sollte das doch auch die performance von fhem steigern.

> > zur zeit ist es z.b. so, das der fht wieder mal nichts meldet. gestern
> > abend schien es (wie meiner letzten mail zu entnehmen ist) endlich alles
> > zu laufen und nun ist schon wieder seit 23:53 oder so funkstille. ich
> > habe aber mittlerweile auch keine idee mehr, woran es liegen könnte.
>
> ... und das Ding aktiv nach seinen Werten fragen, wenn er sie nicht
> freiwillig sendet.
>
> (Ich hab gut reden, mein Code kann das auch nicht. *NOCH* nicht. :P )

da würde nämlich auch gleich die frage folgen: wie mache ich das mit fhem? :-)
wie ich schon sagte: ein lob an alle beteiligten, die fhem zu dem gemacht
haben, was es ist. jetzt aber parallel dazu noch was eigenes zu coden, macht
in meinen augen jedoch kein sinn..

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
-~----------~----~----~----~------~----~------~--~-
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Guest

Originally posted by: <email address deleted>

Hi,

Martin Fischer:
> wie ich schon sagte: ein lob an alle beteiligten, die fhem zu dem gemacht
> haben, was es ist. jetzt aber parallel dazu noch was eigenes zu coden, macht
> in meinen augen jedoch kein sinn..
>
Ich habe meinen eigenen Code (in Python), weil ich ein komplett anderes
Konzept dahinterstehen habe, und das geht mit FHEM nicht unbedingt
einfach zu bewerkstelligen.

Dessenungeachtet kann mein Teil natürlich auch mit FHEM reden.

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

--~--~---------~--~----~------------~-------~--~----~
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

ok, dann fasse ich mal eben zusammen, was ich in diesem thread bisher gelernt
habe.

ausgangslage nochmal kurz: per script soll ermittelt werden ob es eine gerade
oder ungerade woche ist und je nach dem ein neuen wochenplan (insg. 28x
befehle (set *-from[1|2], set *-to[1|2])) setzen.

ich habe gelernt, das fhem jeden befehl einzeln absetzt.
weiterhin habe ich gelernt, das die regler alle 116-121 sec. den stellwert an
die ventile senden. wobei dieser wert nach einem bestimmten muster variiert
um nicht mit anderen reglern zu kollidieren.
weiterhin habe ich gelernt, das wenn der regler mit einer zentrale
synchronisiert ist, er unmittelbar nach dem aussenden der stellwerte an die
ventile, seinen empfänger einschaltet um befehle von der zentrale zu
empfangen. je nach status des buffers ergibt sich somit eine verzögerung von
1- ~120 sec. jedoch gibt es auch eine andere meinung, die sagt, das die
regler sich alle 150 sec. bei der zentrale melden.

über den buffer habe ich gelernt, das es nicht wie in der doku
beschrieben "attr FHZ softbuffer 1", sondern "attr FHZ fhtsoftbuffer 1"
heissen muss. ebenso muss es "attr FHZ retrycount " anstatt "attr
softmaxretry " heissen. auch habe ich gelernt, das der "retryafter"
hardcodet auf 240sec gesetzt ist.

für diese gesammten informationen bedanke ich mich erstmal. das hat schonmal
etwas licht ins dunkel gebracht (jetzt mal nicht per funk, sondern
analog :-) ).

diese informationen erklärt meine frage, warum das senden des wochenplans so
lange zeit in anspruch nimmt (fhem sendet jeden befehl einzeln, plus
zeitlichen versatz, plus ggf. retry's). hier kann ich also erstmal nichts
dran ändern, es sei denn fhem bekommt die möglichkeit "befehlsketten" als ein
telegramm zu senden.

bleiben jetzt noch die anderen fragen offen, die bisher noch nicht beantwortet
wurden:

welchen wert muss ich bei *-from/*-to setzen um diesen timer zu löschen? ist
es 24:00 oder 00:00?

was bedeutet STATE: code_7e0067: 135 bzw. 50? ich habe beobachtet, das immer
wenn STATE auf code_7e0067 steht, der fht keine daten (actuator|temp) mehr
sendet.

werden viele befehle gesendet und in den softbuffer verschoben, habe ich die
vermutung das der empfang seitens fhem solange geblockt ist, bis der
softbuffer abgearbeitet wurde. ist dem so? dazu kommt, das mir dabei
aufgefallen ist, das im anschluss der state der fht auf obigen code steht und
lange keine daten mehr an die fhz übertragen werden (gestern von 23:53 bis
heute 15:00 uhr). wer blockt also nun? fhem den empfang oder fht weil er zu
viele datentelegramme empfangen hat und deswegen "dicht" macht?

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
-~----------~----~----~----~------~----~------~--~-
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Martin Fischer

halle matthias,

Am Dienstag, 15. Januar 2008 schrieb Matthias Urlichs:
> Martin Fischer:
> > wie ich schon sagte: ein lob an alle beteiligten, die fhem zu dem gemacht
> > haben, was es ist. jetzt aber parallel dazu noch was eigenes zu coden,
> > macht in meinen augen jedoch kein sinn..
>
> Ich habe meinen eigenen Code (in Python), weil ich ein komplett anderes
> Konzept dahinterstehen habe, und das geht mit FHEM nicht unbedingt
> einfach zu bewerkstelligen.
>
> Dessenungeachtet kann mein Teil natürlich auch mit FHEM reden.

was hast du denn für ein anderes konzept entwickelt?

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
-~----------~----~----~----~------~----~------~--~-
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Guest

Originally posted by: <email address deleted>

Hi,

Martin Fischer:
> > Ich habe meinen eigenen Code (in Python), weil ich ein komplett anderes
> > Konzept dahinterstehen habe, und das geht mit FHEM nicht unbedingt
> > einfach zu bewerkstelligen.
>
> was hast du denn für ein anderes konzept entwickelt?

Also ...

- alles komplett asynchron programmiert
  das ist mit dem Deferred-Konzept von Python/Twisted sowas von einfach
- Vernetzung zwischen mehreren Instanzen auf verschiedenen Rechnern
  dito asynchron
- Login / Abfrage mittels SSH-Zugang
  in Twisted out-of-the-box dabei, Interpreter dran und fertig
- ereignisgesteuert
  und zwar mit einer Syntax, bei deren Anblick man nicht kirre wird :-P
- Integration von mehr als "nur" FS20-Geräten
  zB 1wire, lirc, ... (1wire kann ich schon, LIRC ist in Arbeit)
- das Web-Frontend kann im selben Prozess mitlaufen,
  oder remote auf die Daten zugreifen (und zwar gezielt, nicht XML-Dump)

--
Matthias Urlichs  |  {M:U} IT Design @ m-u-it.de  |   smurf@smurf.noris.de
Disclaimer: Das Zitat wurde zufällig ausgewählt.  |   http://smurf.noris.de
 - -
Der Glaube ist nicht der Anfang, sondern das Ende allen Wissens.
      -- Goethe

--~--~---------~--~----~------------~-------~--~----~
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

hallo rudi,

Am Dienstag, 15. Januar 2008 schrieb Rudolf Koenig:
> > > und das für die ganze woche. d.h. fhem muss dann 28 befehle absetzen.
> > > dadurch kommt natürlich aufgrund der von euch geschilderten
> > > funktionsweise ein recht hoher delay zu stande.
> >
> > Tja, da hilft wohl nur selbermachen...
>
> Oder 11_FHT.pm erweitern: Angeblich kann man FHT Befehle auch
> zusammenfassen (hintereinander "kleben"), und diese als einen Befehl
> dem FHZ uebergeben. Mit dem softbuffer waere sowas auch einfacher zu
> realisieren. Ob der FHZ dann diese einzeln oder im Paket dem FHT
> weitergibt, dass weiss ich nicht. Freiwillige? Wer keine Lust zum Perl-
> Programmieren verspuert kann immer noch helfen, und per "set FHZ raw /
> get FHZ fhtbuf / FHT beobachten" rausfinden, ob meine Behauptungen
> wahr sind, und das Programmieren ueberhaupt lohnt.

vielen dank für die info!

zwar bin ich auch der "perl-sprache" mächtig, doch liegt meine aktive zeit
schon etwas zurück.. ich bräuchte dann wohl doch etwas länger um mich wieder
reinzufuchsen.

ABER: als freiwilliger würde ich mich gerne zur verfügung stellen. wenn du mir
nochmal genau schildern könntest, was genau und vorallem wie ich was genau
beobachten soll, würde ich da gerne zu beitragen. da ich mich erst seit gut
2-3 wochen mit dem fs20 beschäftige ist mein background noch nicht so
gefestigt.

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
-~----------~----~----~----~------~----~------~--~-
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Dr. Boris Neubert

Am Dienstag, 15. Januar 2008 schrieb Matthias Urlichs:
> > was hast du denn für ein anderes konzept entwickelt?
>
> Also ...
>
> - alles komplett asynchron programmiert
>   das ist mit dem Deferred-Konzept von Python/Twisted sowas von einfach
> - Vernetzung zwischen mehreren Instanzen auf verschiedenen Rechnern
>   dito asynchron
> - Login / Abfrage mittels SSH-Zugang
>   in Twisted out-of-the-box dabei, Interpreter dran und fertig
> - ereignisgesteuert
>   und zwar mit einer Syntax, bei deren Anblick man nicht kirre wird :-P
> - Integration von mehr als "nur" FS20-Geräten
>   zB 1wire, lirc, ... (1wire kann ich schon, LIRC ist in Arbeit)
> - das Web-Frontend kann im selben Prozess mitlaufen,
>   oder remote auf die Daten zugreifen (und zwar gezielt, nicht XML-Dump)

auch interessant.. fhem scheint mir derzeit für meine zwecke geeignet.. da ich
von deinem projekt bisher aber auch noch nichts gehört habe, kann ich mir
darüber auch so kein bild machen. zwar hast du ja ein bisserl darüber auf
deiner homepage geschrieben, dennoch kann man dadurch noch kein vergleich
aufstellen. vielleicht finde ich am wochenende mal zeit mir dein konzept
anzuschauen, sofern ich es zum laufen bekomme :-)

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
-~----------~----~----~----~------~----~------~--~-
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

Am Dienstag, 15. Januar 2008 schrieb Martin Fischer:
> werden viele befehle gesendet und in den softbuffer verschoben, habe ich
> die vermutung das der empfang seitens fhem solange geblockt ist, bis der
> softbuffer abgearbeitet wurde. ist dem so? dazu kommt, das mir dabei
> aufgefallen ist, das im anschluss der state der fht auf obigen code steht
> und lange keine daten mehr an die fhz übertragen werden (gestern von 23:53
> bis heute 15:00 uhr). wer blockt also nun? fhem den empfang oder fht weil
> er zu viele datentelegramme empfangen hat und deswegen "dicht" macht?

na dann antworte ich mir mal eben selber ;-)

heute habe ich meine steuerung um einen weiteren fht erweitert und zu dem
thema nun folgende feststellung gemacht:

daten der beiden fht's werden gesendet:
2008-01-16_21:40:37 wz.Heizung actuator: 00%
2008-01-16_21:42:05 sc.Heizung actuator: 00%
2008-01-16_21:42:33 wz.Heizung actuator: 00%
2008-01-16_21:44:01 sc.Heizung actuator: 00%
2008-01-16_21:44:28 wz.Heizung actuator: 00%
2008-01-16_21:45:56 sc.Heizung actuator: 00%

um ~ 21:46 uhr habe ich auf einem fht den wochenplan mit dem script gesetzt.
das logfile zeigt dieses auch:
2008.01.16 21:46:14 2: FHT set wz.Heizung mon-from1 12:00
2008.01.16 21:46:24 2: FHT set wz.Heizung mon-to1 22:30
2008.01.16 21:46:45 2: FHT set wz.Heizung mon-from2 24:00
2008.01.16 21:47:48 2: FHT set wz.Heizung tue-from1 12:00
2008.01.16 21:47:48 2: FHT set wz.Heizung tue-to1 22:30
2008.01.16 21:47:48 2: FHT set wz.Heizung mon-to2 24:00
2008.01.16 21:47:52 2: FHT set wz.Heizung tue-from2 24:00
2008.01.16 21:48:20 2: FHT set wz.Heizung wed-from1 12:00
2008.01.16 21:48:20 2: FHT set wz.Heizung tue-to2 24:00
2008.01.16 21:48:21 2: FHT set wz.Heizung wed-to1 22:30
2008.01.16 21:49:03 2: FHT set wz.Heizung wed-to2 24:00
2008.01.16 21:49:03 2: FHT set wz.Heizung wed-from2 24:00
2008.01.16 21:49:47 2: FHT set wz.Heizung thu-to1 22:30
2008.01.16 21:49:47 2: FHT set wz.Heizung thu-from1 12:00
2008.01.16 21:49:47 2: FHT set wz.Heizung thu-from2 24:00
2008.01.16 21:50:02 2: FHT set wz.Heizung thu-to2 24:00
2008.01.16 21:50:02 2: FHT set wz.Heizung fri-from1 12:00
2008.01.16 21:50:03 2: FHT set wz.Heizung fri-to1 22:30
2008.01.16 21:50:03 2: FHT set wz.Heizung fri-from2 24:00
2008.01.16 21:50:03 2: FHT set wz.Heizung fri-to2 24:00
2008.01.16 21:50:03 2: FHT set wz.Heizung sat-from1 08:30
2008.01.16 21:50:16 2: FHT set wz.Heizung sat-to1 23:50
2008.01.16 21:50:16 2: FHT set wz.Heizung mon-from1 12:00
2008.01.16 21:50:37 2: FHT set wz.Heizung mon-to1 22:30
2008.01.16 21:50:37 2: FHT set wz.Heizung sat-to2 24:00
2008.01.16 21:50:37 2: FHT set wz.Heizung sat-from2 24:00
2008.01.16 21:51:19 2: FHT set wz.Heizung sun-to1 23:50
2008.01.16 21:51:19 2: FHT set wz.Heizung mon-from2 24:00
2008.01.16 21:51:19 2: FHT set wz.Heizung sun-from1 08:30
2008.01.16 21:51:43 2: FHT set wz.Heizung sun-to2 24:00
2008.01.16 21:51:43 2: FHT set wz.Heizung sun-from2 24:00
2008.01.16 21:52:40 2: FHT set wz.Heizung mon-to2 24:00
2008.01.16 21:52:40 2: FHT set wz.Heizung wed-from1 12:00
2008.01.16 21:52:40 2: FHT set wz.Heizung tue-from1 12:00
2008.01.16 21:52:40 2: FHT set wz.Heizung tue-to1 22:30
2008.01.16 21:52:40 2: FHT set wz.Heizung wed-to1 22:30
2008.01.16 21:52:40 2: FHT set wz.Heizung tue-from2 24:00
2008.01.16 21:52:40 2: FHT set wz.Heizung tue-to2 24:00
2008.01.16 21:53:10 2: FHT set wz.Heizung wed-to2 24:00
2008.01.16 21:53:10 2: FHT set wz.Heizung wed-from2 24:00
2008.01.16 21:54:10 2: FHT set wz.Heizung fri-from2 24:00
2008.01.16 21:54:10 2: FHT set wz.Heizung sat-from1 08:30
2008.01.16 21:54:10 2: FHT set wz.Heizung thu-to2 24:00
2008.01.16 21:54:10 2: FHT set wz.Heizung thu-to1 22:30
2008.01.16 21:54:10 2: FHT set wz.Heizung fri-to1 22:30
2008.01.16 21:54:10 2: FHT set wz.Heizung sat-to1 23:50
2008.01.16 21:54:10 2: FHT set wz.Heizung thu-from1 12:00
2008.01.16 21:54:10 2: FHT set wz.Heizung fri-to2 24:00
2008.01.16 21:54:10 2: FHT set wz.Heizung fri-from1 12:00
2008.01.16 21:54:10 2: FHT set wz.Heizung thu-from2 24:00
2008.01.16 21:54:40 2: FHT set wz.Heizung mon-from1 12:00
2008.01.16 21:54:40 2: FHT set wz.Heizung mon-to1 22:30
2008.01.16 21:54:40 2: FHT set wz.Heizung sat-to2 24:00

in dieser zeit kam kein datentelegramm der fht's durch, welches wiederum an
diesen einträfen zu sehen ist:
2008-01-16_21:54:06 wz.Heizung actuator: 00%
2008-01-16_21:55:34 sc.Heizung actuator: 00%
2008-01-16_21:57:29 sc.Heizung actuator: 00%
2008-01-16_21:59:25 sc.Heizung actuator: 00%

die werte von sc.Heizung werden jetzt wieder empfangen, aber nur einmal
wz.Heizung. im softbuffer hängen nach 15 minuten immer noch 27 einträge. hier
nur ein auszug:
abe:~ # echo "list FHZ" | netcat -w1 localhost 7072
Internals:
   DEF        /dev/ttyUSB0
   DeviceName /dev/ttyUSB0
   FD         6
   NAME       FHZ
   NR         1
   NR_CMD_LAST_H 57
   PARTIAL
   QUEUECNT   0
   SOFTBUFFERTIMER 1
   STATE      time
   TYPE       FHZ
   Readings:
     2008-01-16 21:36:41   init2           1f04a0071c3b40ff
     2008-01-16 21:36:42   serial          136e63ff
   Softbuffer:
     9:1200516374.79618:2:
       ARG        0201830b011448
       CMD        mon-from1
       HASH       wz.Heizung
       NSENT      3
       SENDTIME   1200516880.88932
       VAL        12:00
     9:1200516374.86784:3:
       ARG        0201830b011587
       CMD        mon-to1
       HASH       wz.Heizung
       NSENT      3
       SENDTIME   1200516880.88932
       VAL        22:30
     9:1200516384.07336:4:
       ARG        0201830b011690
       CMD        mon-from2
       HASH       wz.Heizung
       NSENT      2
       SENDTIME   1200516679.77732
       VAL        24:00
     9:1200516405.1635:5:
       ARG        0201830b011790
       CMD        mon-to2
       HASH       wz.Heizung
       NSENT      3
       SENDTIME   1200517211.18069
       VAL        24:00

und so wie ich es bereits geschrieben hatte, vermute ich jetzt, das fhem
solange keine daten von wz.Heizung annehmen wird, bis alle befehle abgesetzt
worden.

@rudi:
es gab ja die diskussion, das mehrere befehle als ein datentelegramm gesendet
werden könnten. ich verstehe da absolut deine haltung, das du nur auf
verdacht nicht den aufwand betreiben willst. ich hatte dir da ja meine
unterstützung hierzu angeboten.

wäre es aber möglich, das du dich der sache mit dem softbuffer annimmst? also
wenn softbuffer abgearbeitet wird, das dennoch telegramme entgegen genommen
werden?

ich glaub, das man dann mit der konstellation leben könnte: befehle werden
zwar weiterhin einzeln abgearbeitet, aber zumindest würden dann die messdaten
auch angenommen, so dass es keinen abriss in z.b. gnuplot bei der auswertung
gibt. dann muss man halt die lange übertragung in seinem job berücksichtigen.

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
-~----------~----~----~----~------~----~------~--~-
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

                                                   

> wäre es aber möglich, das du dich der sache mit dem softbuffer annimmst?
> also wenn softbuffer abgearbeitet wird, das dennoch telegramme entgegen
> genommen werden?

fhem ist nicht richtig synchron (auch wenn Matthias es zu suggerieren
versucht :-), und wenn der FHZ was zu sagen hat, nimmt fhem die Daten
sofort entgegen.
So kriegt er auch mit, dass ein Befehl erfolgreich gesendet wurde: der
FHT meldet dem FHZ (und damit fhem), dass Befehl X angekommen ist.
Dann wird es aus dem Softbuffer gestrichen.
Ich vermute eher dass der FHT solange nichts sagt, bis vom FHZ noch
Befehle kommen -> Ich fuerchte hier kann ich nichts verbessern.


> werden könnten. ich verstehe da absolut deine haltung, das du nur auf
> verdacht nicht den aufwand betreiben willst. ich hatte dir da ja meine
> unterstützung hierzu angeboten.

Sorry, ich bin in meinem "Second-Life" (wo ich das Geld verdiene :)
z.Zt ausgelastet, deswegen kann ich nicht immer sofort antworten:

Hier die Anleitung zum testen:

Die Befehle per set FHZ raw 04 senden, wobei folgenden
Aufbau hat: 020183...

ist der Code der FHT in Hex
ist ein Befehl, z.Bsp
- 4100692c heisst desired-temp 22.0 (2*22 in hex ist 2c)
- 3e006901 heisst mode manual (00 is auto, 01 ist manual)

Also bei einem Hauscode von Hex 1234 sollte
set FHZ raw 04 02018312344100692c3e006901
auf einmal die temp auf 22.0 und mode auf manual setzen.

Weiter Codes siehe FHEM/11_FHT.pm.

Gruss,
  Rudi
--~--~---------~--~----~------------~-------~--~----~
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

Originally posted by: <email address deleted>

Hi,

Rudolf Koenig:
> fhem ist nicht richtig synchron (auch wenn Matthias es zu suggerieren
> versucht :-), und wenn der FHZ was zu sagen hat, nimmt fhem die Daten
> sofort entgegen.

Schon gut :-P

> Ich vermute eher dass der FHT solange nichts sagt, bis vom FHZ noch
> Befehle kommen -> Ich fuerchte hier kann ich nichts verbessern.
>
Abhilfe: als jeden dritten Befehl eine Temperaturabfrage hinschicken?

--
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
 - -
The weather for catching fish is that weather, and no other, in which fish
are caught.
               -- W. H. Blake

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~-