Hallo zusammen,
irgendiwe bin ich auf dem Holzweg vermute ich.
Nachdem sich seit vorgestern mein Logfile mit
2013.01.07 16:21:55 2: CUL1: unknown message LOVF
2013.01.07 16:22:10 2: CUL1: unknown message LOVF
2013.01.07 16:22:10 2: CUL1: unknown message LOVF
2013.01.07 16:22:10 2: CUL1: unknown message LOVF
2013.01.07 16:22:10 2: CUL1: unknown message LOVF
2013.01.07 16:22:54 2: CUL1: unknown message LOVF
2013.01.09 07:27:49 2: CUL1: unknown message LOVF
2013.01.09 07:27:58 2: CUL1: unknown message LOVF
2013.01.09 07:29:46 2: CUL1: unknown message LOVF
2013.01.09 07:31:16 2: CUL1: unknown message F221C
2013.01.09 07:38:39 2: CUL1: unknown message LOVF
2013.01.09 07:39:21 2: CUL1: unknown message LOVF
füllt, und zwar beinahe im Sekundentakt, habe ich erstmal die meisten Geräte per IODEV vom CUL wieder "abgezogen" und auf
2 CUNO aufgeteilt.
Gestern abend habe ich einen dritten CUNO (CUNO3) installiert und in FHEM eingebunden (inkl. sendpool) in der hoffnungsvollen Annahme
das sich die Funklast dann "etwas" verteilen würde - pustekuchen.
Gestern hat sich dann auch noch CUNO1 mit dieser Meldung bemerkbar gemacht - aber nicht so häufig wie der CUL.
Am CUL habe ich jetzt nur noch einen! FHT aus der selben Etage als IODEV zugeordnet (das war auch bisher so).
Das einzige was ich "rumgeschoben" habe waren FS20-Komponeten (PIRI, PIRA, PIRU, ST, SU, DI) und diese habe ich dem CUNO3 zugeordnet.
Ob sinnvoll oder nicht einem PIRA ein IODEV zuzuordnen, ok.
Kurz und knapp:
Wie werde ich diese Nachrichten wieder los (weniger senden?) oder
wie verteile ich meine Geräte am besten per IODEV auf (1 X CUL + 3 X CUNO) wobei der CUL zur Not auch rausfliegen kann da ich in
der Schublade noch einen (Reserve-)Cuno liegen habe als Ersatz.
Für sachdienliche Hinweise bin ich dankbar.
Grüße
P.S.: Es geht gesamt um 11 FHT (diese sind Etagenweise auf die CUNO aufgeteilt) und vorerst ca. 10 FS20-Komponenten pro Etage.
Macht es überhaupt Sinn, ausser den FHT, einem Geräte ein IODEV zuzuweisen??
LOVF steht fuer Limit OVerFlow, damit ist die 1% Sendebeschraenkung gemeint, was culfw mit 9 Sekunden pro 15Minuten durchsetzt: Falls diese Grenze erreicht ist, und man was senden will, dann kommt diese Meldung. 11 FHT ist 'ne Menge, deswegen habe ich diese Dinger erst im Verdacht. Mit 11 FHTs ist ein CUL am Limit, und belegt ca 1% Sendezeitraum (siehe irgendwo Wikiartikel). Auch wenn das auf mehrere CULs verteilt ist, bleibt es 1% Funklast, und stoert damit alle FHTs in der Naehe.
Was ich machen wuerde:
- (wirklich!) laenger ueberlegen, welche FHT's von fhem aus unbedingt umprogrammiert werden muessen, und pruefen, ob die internen Mechanismen der FHT's nicht reichen.
- Umstellzeiten versuchen zeitlich zu entzerren (also nicht das Wochenprogramm aller FHTs taeglich um 12:00 umstellen)
- bei allen CULs/CUNs mit "get CUL raw T02" anschauen, was im FHT Buffer sich befindet. Das gibt ein Hinweis darauf, bei welchen FHT's es klemmt.
- alle CULs/CUNs mit "set CUL raw X61" zum mitteilen der FHT-Protokoll-Nachrichten ueberreden, und dann entweder "inform timer" oder "Event Monitor" auswaehlen. Damit sieht man, ob irgendwelcheFHTs Probleme mit dem Empfang haben. Zum Schluss mit "set CUL raw X21" zurueckstellen oder fhem neu starten.
- mit "list TYPE=FHT IODev" die Zuordnung pruefen. Die hash-Adresse muss man durch pruefen der einzelnen FHT's nach CUL-Name uebersetzen.
Hallo Rudi und danke schonmal für deine Antwort.
Das LOVF aussagt das das Sendelimit erreicht ist war mir schon klar ;-)
Nur woher?
Die 11 FHT laufen (bis auf einen) im Mode Manual und es werden KEINE Werte durch fhem verstellt.
Ich sende nichts aktiv an diese 10 FHT und der eine der noch übrig ist spult sein autoprogramm ab.
Auch dieser wird von mir nicht aktiv angesprochen.
Also ich stelle, wenn überhaupt, an einem einzigen FHT (Wohnzimmer) aktiv die desired-temp 1-mal am Tag, eher seltenr.
Ich werde deine Tipps mal durcharbeiten und notieren was dabei raus kommt.
Was mir gestern zumindest aufgefgallen ist, ist das der CUL1 mit den LOVF-Meldung ankam als ich mit dem Licht im Keller
gespielt habe (5-mal Licht an und auch aus und schon war LOVF im Log).
Ok. Also die ersten beiden Punkte fallen schonmal raus wobei ich auch den ersten Punkt nochmal überdenken werde.
Danke nochmal für die Tipps
Grüße
hiya puschel,
auch ich habe jahrelang 11 fht betrieben. alle mit fhem als zentrale gepaart. anfangs hatte ich auch die eine oder andere LOVF meldung aber meist nur dann, wenn ich was von den fhts übertragen lies. allerdings traten die LOVFs nicht in der häufigkeit auf, die du beschreibst.
um das ganze zu entzerren, habe ich seinerzeit eine alte FHZ1300 rausgekrammt und diese als IODev für mein obergeschoss nur für die fhts eingesetzt. die restlichen fhts laufen über einen cuno.
seit dem hatte ich keine LOVFs mehr.
sicherlich kann man meine umgebung nicht mit deiner vergleichen aber ich würde das an deiner stelle auch nochmal so oder so ähnlich aufbauen.
gruss martin
Hallo,
leider sagen mir diese Werte nichts:
CUL1 raw => 012A:00AA,00F3 51B6:DD01,1E 0C04:00B6,68E6 4AD5:6E01,0E 1E4E:6C82,E7 012A:00BA,00F3
2F39:600D,6101,6204,6302,6400 0C03:600D,6101,6204,6302,6400 2529:600D,6101,6204,6302,6400
2F39:600D,6101,6205,6302,6400 0C03:600D,6101,6205,6302,6400 2529:600D,6101,6205,6302,6400 2F39:411E
221C:00AA,0000,0000,0000,0000 2F39:600D,6101,6206,6302,6400 0C03:600D,6101,6206,6302,6400 2529:600D,6101,6206,6302,6400
CUL1 version => V 1.44 CUL868
CUNO1 raw => No answer
set CUNO1 raw X21 mit shutdown restart durchgeführt
CUNO1 raw => 3D09:600D,6101,6204,6302,6400 012A:600D,6101,6204,6302,6400 3D09:600D,6101,6205,6302,6400
012A:600D,6101,6205,6302,6400 3D09:600D,6101,6206,6302,6400 012A:600D,6101,6206,6302,6400 3D09:600D,6101,6207,6302,6400
012A:600D,6101,6207,6302,6400 3D09:600D,T4AD56E0217
CUNO1 version => V 1.44 CUNO868
CUNO2 raw => 36BD:413C 36BD:600D,6101,6202,6302,6400
CUNO2 version => V 1.44 CUNO868
CUNO3 raw => N/A
set CUNO3 raw X21 mit shutdown restart durchgeführt
CUNO3 raw => N/A
get CUNO3 version
CUNO3 version => V 1.44 CUNO868
Der CUNO3 wird als Initialized angezeigt aber auch ein
set CUNO3 raw X21 brachte nichts
Definiert ist er so:
define CUNO3 CUL 192.168.2.25:2323 0404
sendpool CUL1,CUNO1,CUNO2,CUNO3
Kann es sein das ich die FHT erst an diese "FHT-ID" gewöhnen/pairen muss?
@Martin
Danke für deinen Tipp aber da ich die CUNO pro Etage verteilt habe würde es mich wundern wenn eine FHZ Erleichterung bringen würde -
zumal ich auch nur eine FHZ1000 in der Grabbelkiste habe ;-)
Aber wie schon geschrieben verstelle ich, wenn überhaupt, an EINEM FHT (Wohnzimmer) EINMAL am Tag die desired-temp.
Sonst sind nur FS20-Komponenten im Einsatz (auch über das gesamte Haus verteilt).
Ich werde mir, wie von Rudi vorgeschlagen, mal Gedanken über eine Neu-Zuordnung der FHT´s machen.
Kann ich die FHT mit IODEV daran hindern an einem anderen CU(L/NO) für einen vollen Puffer zu sorgen?
Ich hätte zur Not noch einen CUNO in der Grabbelkiste - geflasht und bereit für den Einsatz.
Würde es Linderung bringen wenn ich den CUL gegen einen CUNO tausche?
Danke schonmal für Eure Bemühungen.
Grüße
hiya puschel,
das ausschlaggebenede war jetzt nicht der einsatz des FHZ1x00 sondern eher die dedizierte zuordnung an ein IODev. aber das hattest du meines wissens eh schon gemacht. wobei ich bei mir dann das sendpool rausgelassen hatte.
also auf deutsch:
die FHZ1300 macht bei mir _nur_ die 5 fhts des obergeschosses, sonst bedient diese keine weiteren devices. quasi eine fht dmz ;-)
vielleicht spielt aber dennoch die fhz dabei eine rolle. ich weiss es nicht. ich kann nur berichten, wie ich die LOVFs bei mir in den griff bekam.
vielleicht ist es aber auch so, das wenn du das gleiche setup mit zwei cul/cun nachstellst es wieder zu LOVFs kommt, weil sie von dem gleichen fhem-modul bedient werden und da die 1% regel (egal für welches IODev in summe gesehen wird). das könnte vielleicht erklären, warum die kombination cuno/fhz bei mir eben nicht zu den LOVFs führt aber die kombination cun/cun bei dir doch.
das kann rudi als modulautor ggf. ins rechte licht rücken ob ich damit falsch liege.
gruss
Hallo,
danke schonmal für deine Erklärungen Martin.
Und ich dachte die 1%-Regel wird in culfw und daher direkt im CU(L/NO) überwacht und nicht in fhem.
Da hätte ich mir die schönen CUNO wohl sparen können :-(
Grüße
> das kann rudi als modulautor ggf. ins rechte licht rücken ob ich damit falsch liege.
Stimmt, ist falsch :). Das 1% wird direkt im culfw ueberwacht, ist also pro Geraet aktiv.
Sonst: CUL1 und CUNO1 habe 'ne Menge mitzuteilen, das abzuarbeiten dauert unter idealen Bedingungen 1-2 Stunden, und die gesendeten Datum bzw. Zeit Werte (60..64) sind inzwischen auch noch falsch. Ich wuerde diese Puffer jeweils mit "set CUL raw T01<FHTID>" oder "set CUL raw B00" oder abstecken/anstecken loeschen.
Wichtig:
- alle CULs/CUNOs die mit einem FHT kommunizieren sollten, muessen unterschiedliche FHTIDs haben (insb. die ersten zwei Stellen)
- bei jedem FHT ist zu pruefen, ob IODev zum gewaehlten CUL/CUNO passt.
- alle FHTs muessen neu mit dem passenden CUL/CUNO angelernt werden (FHT -> Cent -> N/A, im fhem Befehl senden, ist in Wiki beschrieben).
> set CUNO1 raw X21 mit shutdown restart durchgeführt
das ist "doppelt gemoppelt" und sollte man erst machen, wenn man mit "set CUL raw X61" und der "inform timer/Event Monitor" Ueberwachung (am besten mind. 30 Minuten lang) durch ist. Ist aber vermutlich alles ueberfluessig, da ich vermute, dass die vorherigen Punkte nicht eingehalten wurden, und deswegen was schiefgelaufen ist.
ja, wird sie ja auch... aber vielleicht gibt es da auch noch irgendein zusammenspiel im fhem modul.. darauf wollte ich hinaus..
also nichts mit einsparung :-)
Hallo,
einzig diesen Punkt
Zitat von: rudolfkoenig schrieb am Mi, 09 Januar 2013 09:31- alle CULs/CUNs mit "set CUL raw X61" zum mitteilen der FHT-Protokoll-Nachrichten ueberreden, und dann entweder "inform timer" oder "Event Monitor" auswaehlen. Damit sieht man, ob irgendwelcheFHTs Probleme mit dem Empfang haben. Zum Schluss mit "set CUL raw X21" zurueckstellen oder fhem neu starten.
habe ich nicht eingehalten da CUNO1 und CUNO3 nach einem raw X21 N/A bzw no answer lieferten.
Daher habe ich einen, vllt. vorschnellen?, restart von fhem durchgeführt.
Die CU(L/NO) haben als ID 0101, 0202, 0303, 0404 <--- sollte hoffentlich? passen.
@Rudi
was meinst du mit
Zitat- bei jedem FHT ist zu pruefen, ob IODev zum gewaehlten CUL/CUNO passt.
Worauf muss ich da achten?
Ich dachte CUNO und FHT verstehen sich - wenn sie gepairt wurden.
Also den dritten Punkt
Zitat- alle FHTs muessen neu mit dem passenden CUL/CUNO angelernt werden (FHT -> Cent -> N/A, im fhem Befehl senden, ist in Wiki beschrieben).
habe ich schon fast vermutet - werde ich gleich nachholen aber erst CUL1 und CUNO1 rücksetzen und den Buffer leeren.
Danke schonmal Euch 2 für die Hilfe.
Frage am Schluss: Macht es Sinn FS20-Device mit IODEV zu versehen?
Grüße
> was meinst du mit
>> bei jedem FHT ist zu pruefen, ob IODev zum gewaehlten CUL/CUNO passt
> Worauf muss ich da achten?
beispiel:
fht1 = IODev1
fht2 = IODev1
[...]
fht10 = IODev2
fht11 = IODev2
wobei IODev1 und IODev2 den jeweiligen CUL/CUNOs entsprechen.
dann:
fht1 -> cent -> n/a
und in fhem:
set fht1 time
dann weiter:
fht2 -> cent -> n/a
und wieder in fhem:
set fht2 time
usw.
dann sollte definitiv alle fhts mit den richtigen IODevs gepaart sein. das ganze aber mit etwas geduld durchführen und aufs logfile achten. ich würde mir immer erst den nächsten vornehmen, wenn die kommunikation des aktuellen komplett abgeschlossen ist.
ja, ich weiss: das kostet etwas zeit.
> Macht es Sinn FS20-Device mit IODEV zu versehen?
warum sollte das keinen sinn machen? sie werden ja eh immer mit einem IODev versehen, nämlich dem letzten aus der config zuständigem. wenn du z.b. reichweitenprobleme hast, dann macht es durchaus sinn, auch ein fs20 device an ein näherliegendes IODev zu binden.
gruss
Hallo,
danke Martin.
Naja, das mit der Zuordnung habe ich mir schon fast gedacht ;-)
Das habe ich vor einem Jahr schon so gemacht und ich weiß ... es geht "etwas" Zeit drauf bis alle 11 FHT durch sind.
Allerdings werde ich mir nach dem Essen mal eine Liste machen und die IODEV auch passend auf die FS20-Geräte verteilen aber erst
sind die FHT dran.
Ich vermute mal der CUL hat weniger Buffer als ein CUNO?
Dann werde ich im Keller auch den CUL gegen einen CUNO tauschen und den CUNO3 vorher noch im Dachboden verbauen.
Und dann heisst es durch und FHT neu "anlernen"
Danke nochmal
Grüße
Hallo,
nun mal zum, hoffentlich, Abschluss.
So
DG_Bad_Heizung HASH(CUNO3)
DG_Lern_Heizung HASH(CUNO3)
DG_Schlaf_Heizung HASH(CUNO3)
EG_Eingang_Heizung HASH(CUL1)
EG_Kueche_Heizung HASH(CUNO2)
EG_WC_Heizung HASH(CUL1)
EG_Wohnzimmer_Heizung HASH(CUNO2)
Keller_Gaestezimmer_Heizung HASH(CUNO1)
OG_Badezimmer_Heizung HASH(CUNO2)
OG_Schlafzimmer_Heizung HASH(CUNO3)
OG_Zimmer_Heizung HASH(CUNO2)
sind sie jetzt verteilt. (ich hab heut noch schnell im Speicher ne Steckdose installiert ;-) ).
Ich denke mal die Zurodnung trifft FHEM über das IODEV?
Ich hab aber an jedem die Zentrale neu anlernen lassen - einfach CENT auf NA und mit set desired-temp die Temperatur stellen lassen.
Nach erfolgter Übernahme der Temperatur, ja - ich bin schauen gegangen ob alle die neue Temp übernommen haben, und Kontrolle
ob CENT wieder von N/A auf ON lass ich mich mal überraschen ob ich jetzt Ruhe hab.
Danke schonmal an allen für die Hilfe.
Grüße
Nur am Rande: Pairing und IOdev müssen unbedingt übereinstimmten, sonst hast du Ruck Zuck trauer.
Hallo und Guten morgen,
Pairing und IODEV?
Stellt sich das nicht selbst ein?
Ich habe in Fhem meine FHT`s auf die CUNO`s verteilt (s. o. Liste) und danach JEDEN FHT neu mit FHEM gepairt.
Also an JEDEM FHT (auch die wo sich IODEV nicht geändert hat) neu auf Cent N/A und in FHEM einen Befehl an genau diesen FHT
gesendet.
Nachdem sich am Display die desired-temp auf den gesendeten Wert gestellt hat habe ich den Eintrag für Cent im FHT kontrolliert
( Cent on) und dann bin ich weiter zum nächsten FHT.
Nun sollte ja Pairing und IODEV stimmen oder überseh ich da was?
Grüße
P.S.: Zumindest habe ich bisher keine LOVF mehr im Log und die FHT reagieren brav auf alle Eisntellungen
> Nun sollte ja Pairing und IODEV stimmen...
Korrekt. Es sei denn, bei mehreren CUL/CUNOs sind die ersten zwei Stellen der FHT-ID identisch.
ZitatPairing und IODEV?
Stellt sich das nicht selbst ein?
Je nachdem was du damit meinst: Nein.
Aber wenn du zuerst die IOdevs geändert und dann CENT neu gemacht hast ist alles okay.
Das Blöde ist eben nur: Wenn man IOdev hinterher ändert merkt man das u.U ne Weile nicht, weil die Tempdaten und so ja weiter rein kommen, gleichzeitig aber der Buffer zuläuft.
Dieses Problem hatten wir schon hier und in der alten Group öfters, ich bin da auch schonmal drauf reingefallen.
in diesem Zusammenhang:
ZitatEs sei denn, bei mehreren CUL/CUNOs sind die ersten zwei Stellen der FHT-ID identisch.
das wollte ich neulich versehentlich machen, aber FHEM hat mich ja freundlicherweise gewarnt, dass ich das mal lieber nicht machen soll. Ich konnte also (in meinem Fall) 2 CULs gar nicht mit FHT-IDs versehen, die in den ersten beiden Stellen gleich waren.
Ich "wusste" dass man das nicht machen kann/soll, hatte es aber natürlich prompt vergessen.