Das leidige Thema LOVF am CUNO

[Puschel74]

Hallo zusammen,

in letzter Zeit haben sich an einem meiner CUNOs wieder vermehrt LOVF-Meldungen breit gemacht.
Erst habe ich das ganze "ignoriert" da ich langfristig von FS20 auf HM migrieren möchte.
Ok - die CUNO bleiben da ich die FHT80b (noch) nicht ersetzen werde.
Also doch mal dran gesetzt und geschaut was da so los sein könnte.
Ein Abfrage mit

Code Auswählen Erweitern

get CUNO3 raw T02brachte mir eine ansehnliche Liste von Befehlen die in diesem CUNO auf die Abarbeitung warten.
Der CSM fast leer und CUNO1 und CUNO2 - moment, CUNO2 lieferte <no answer>.
Also mal die Version geprüft

Code Auswählen Erweitern

get CUNO2 versionlieferte ein <V 1.44 868 CUNO> zurück.
Also nochmal ein raw T02 und siehe da - auch dieser Buffer leer.

Ok. IODev geprüft und wirklich jedes Device (ich hoffe ich hab keines übersehen) einem CUNO bzw. dem CSM zugewiesen.
LOVF bleibt - klar CUNO3 ist noch immer voll.
Also mal die credit10ms abgefragt.
CSM, CUNO1 und CUNO2 immer über 600.
CUNO3 dümpelt bei unter 100 rum.
CUNO3 wird auch als letzter in die fhem.cfg eingebunden.
Also mal die Reihenfolge vertauscht und das CSM als letztes eingebunden.
Auch sendpool angepasst und alle 10 Minuten per at die credit10ms abgefragt.
siehe da - sporadisch disconnecten die Geräte und reappearen wieder.
Bei den CUNO könnte ich noch einen Fehler im Netzwerk vermuten - obwohl alle anderen Geräte im Netzwerk einwandfrei funktionieren.
Aber beim CSM kann ja wohl kein Netzwerkproblem vorliegen.

Frage: Kommen die disconnects weil ich per at alle 10 Minuten die credit10ms abfrage?
Wie kann ich so eine Abfrage besser machen - oder wie sollte ich diese Abfrage überhaupt machen oder spricht etwas dagegen zyklisch diesen Wert abzufragen?

Code Auswählen Erweitern

+*00:10:00 {
  my $credit_CSM = ReadingsVal("CSM","credit10ms",50);
  my $credit_CUNO1 = ReadingsVal("CUNO1","credit10ms",50);
  my $credit_CUNO2 = ReadingsVal("CUNO2","credit10ms",50);
  my $credit_CUNO3 = ReadingsVal("CUNO3","credit10ms",50);
  fhem("set CSMcr ".$credit_CSM);
  fhem("set Cuno1cr ".$credit_CUNO1);
  fhem("set Cuno2cr ".$credit_CUNO2);
  fhem("set Cuno3cr ".$credit_CUNO3);
  fhem("get CSM credit10ms");
  fhem("get CUNO1 credit10ms");
  fhem("get CUNO2 credit10ms");
  fhem("get CUNO3 credit10ms");
}
Ja ich weiß. Es geht sicher auch schöner aber um dieses "schöner" geht es mir hier nicht.
Den "Umweg" über die 4 dummy musste ich nehmen da ich die Werte der 4 Geräte nicht in der Datenbank gefunden habe.

Sreenshot zeigt den Verlauf der credit10ms über alle 4 Geräte. Dort wo der Plot auf Null geht hat das jeweilige Device ein <no answer> geliefert.
Die Konfig der Geräte hab ich auch mal angehängt.

Code Auswählen Erweitern

# Definition CUNO1 - Wohnzimmer
define CUNO1 CUL 192.168.2.23:2323 0101
attr CUNO1 room 80_Definition
attr CUNO1 sendpool CUNO1,CUNO2,CUNO3,CSM

# Definition CUNO2 - OG_Zimmer
define CUNO2 CUL 192.168.2.24:2323 0202
attr CUNO2 room 80_Definition
attr CUNO2 sendpool CUNO1,CUNO2,CUNO3,CSM

# Definition CUNO3 - DG_Dachboden
define CUNO3 CUL 192.168.2.25:2323 0303
attr CUNO3 room 80_Definition
attr CUNO3 sendpool CUNO1,CUNO2,CUNO3,CSM,

# Definition CSM - Keller
define CSM CUL /dev/ttyAMA0@38400 0404
attr CSM addvaltrigger 1
attr CSM model CUL
attr CSM rfmode SlowRF
attr CSM room 80_Definition
attr CSM sendpool CUNO1,CUNO2,CUNO3,CSM

Wenn ihr noch Angaben benötigt dann nur los - welche und wie kann ich euch diese verschaffen.

Danke schonmal für das durchlesen.

Grüße

[rudolfkoenig]

brachte mir eine ansehnliche Liste von Befehlen die in diesem CUNO auf die Abarbeitung warten.

Das ist nie gut, und du solltest anhand der IDs pruefen, ob alle Requests dahingehoeren, bzw. wo hakt es bei der Uebertragung.

IODev geprüft und wirklich jedes Device (ich hoffe ich hab keines übersehen) einem CUNO bzw. dem CSM zugewiesen.

Man kriegt mit

Code Auswählen Erweitern

list TYPE=FHT IODev
eine relativ kryptische Liste, oder mit

Code Auswählen Erweitern

{ join(" ", map { $_.":".$defs{$_}{IODev}{NAME} } devspec2array("TYPE=FHT")) }
eine besser lesbare

Auch sendpool angepasst

Ist nur dafuer da, dass man Befehle nicht gleichzeitig aussendet. Sollte bei FHTs kaum Wirkung zeigen, ist eher gedacht fuer das Schalten von zig Leuchten mit unterschiedlichen CULs

und alle 10 Minuten per at die credit10ms abgefragt.

Die credit10ms Abfrage sollte nur ein Wert im Specher zureuckliefern, und ich wuerde nur bei einem RFR von der zyklischen Abfrage abraten.

Code Auswählen Erweitern

Kommen die disconnects weil ich per at alle 10 Minuten die credit10ms abfrage?
Vermutlich, da die Routine nur 3 Sekunden wartet, und dann die Verbindung schliesst, und erneut oeffnet mit der gezeigten Fehlermeldung. Mit

Code Auswählen Erweitern

{ $defs{CSM}{RA_Timeout} = 10; }
kann man diesen Wert temporaer erhoehen, allerdings haengt dann FHEM hier auch bis zu 10 Sekunden lang.

Weiterhin unklar:
- wieso verursacht ein credit10ms disconnects
- wieso sendet CUNO3 soviel.

[Puschel74]

Hallo,

und danke schonmal für deine Hilfe.

Ein

Code Auswählen Erweitern

{ join(" ", map { $_.":".$defs{$_}{IODev}{NAME} } devspec2array("TYPE=FHT")) }
(Danke für diese Langversion) liefert mir

DG_Bad_Heizung:CUNO3
DG_Lern_Heizung:CUNO3
DG_Schlaf_Heizung:CUNO3
EG_Eingang_Heizung:CSM
EG_Kueche_Heizung:CSM
EG_WC_Heizung:CSM
EG_Wohnzimmer_Heizung:CUNO1
Keller_Gaestezimmer_Heizung:CSM
OG_Badezimmer_Heizung:CUNO2
OG_Schlafzimmer_Heizung:CUNO2
OG_Zimmer_Heizung:CUNO2

So war die Aufteilung von mir auch mal angedacht.
Ich werde morgen erstmal hergehen und einen DG-FHT an den CUNO2 anlernen und einen OG an den CUNO1
Dann sollte der erste Teil schonmal entschärft sein - hoffe ich.

Ich habe mir auch die Beiträge im Wiki zur 1%-Regel und den maximal verwendbaren Geräten durchgelesen und komme langsam zu der Vermutung das CUNO3 durch FS20-Aktoren (Bewegungsmelder) so schwer an seine Grenze getrieben wird.
Daher habe ich den/das CSM in der Definition mal nach CUNO3 gestellt den ich meine gelesen zu haben das FHEM als Sendedevice für alles was nicht zugeordnet ist das letzte eingebundene verwendet.
Dies habe ich aber gestern abend schon gemacht und der credit10ms im CUNO3 erholt sich einfach nicht.

Hier mal der Auszug aus dem FHEM-LogFile nach dem Start von FHEM gestern abend:

2013.12.07 20:08:39 1: Including ./Konfig/Globale_Def.cfg
2013.12.07 20:08:39 3: Opening CUNO1 device 192.168.2.23:2323
2013.12.07 20:08:39 3: CUNO1 device opened
2013.12.07 20:08:39 3: CUNO1: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2013.12.07 20:08:39 3: Opening CUNO2 device 192.168.2.24:2323
2013.12.07 20:08:39 3: CUNO2 device opened
2013.12.07 20:08:39 3: CUNO2: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2013.12.07 20:08:40 3: Opening CUNO3 device 192.168.2.25:2323
2013.12.07 20:08:40 3: CUNO3 device opened
2013.12.07 20:08:40 3: CUNO3: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2013.12.07 20:08:40 3: Opening CSM device /dev/ttyAMA0
2013.12.07 20:08:40 3: Setting CSM baudrate to 38400
2013.12.07 20:08:40 3: CSM device opened
2013.12.07 20:08:40 3: CSM: Possible commands: mBCFiAGMRTVWXefltx

Das ist nie gut, und du solltest anhand der IDs pruefen, ob alle Requests dahingehoeren, bzw. wo hakt es bei der Uebertragung

Werde ich prüfen (sofern ich das schaffe).
Bei der Übertragung dürfte es eigentlich nicht hacken.
CUNO3 ist im Dachboden montiert, Luftlinie zu den 3 zugewiesenen FHT ca. 5m durch eine Holzdecke und eine Gipskartonwand durch.

Weiterhin unklar:
- wieso verursacht ein credit10ms disconnects
- wieso sendet CUNO3 soviel.

Wenn du mir sagst was ich tun kann um dir Informationen zu liefern mache ich das natürlich.

Grüße

Edith: Mal eben ein raw T02 am CUNO3 abgefragt.
Erst bekam ich nur ein <no answer> aber nachdem er die Version gemeldet hat ging auch die raw-Abfrage.

CUNO3 raw => 2F39:4118 0C03:4118 2529:4118 2F39:4118 0C03:4118 2529:4118 0002:4118 2F39:4118 0C03:4118 2529:4118 0002:4118 2F39:4118 0C03:4118 2529:4118 0002:4118 2F39:3E01 0C03:3E01 2529:3E01 0002:3E01 0002:412A 0002:412A 0002:65FF 2529:3E00 2529:3E00 2529:3E00 tA02C511514DE

Es stehen 4 Geräte im Buffer (wenn ich das richtig sehe): 2F39, 0C03, 2529 und 0002.
Die letzte versteh ich nicht ganz tA02C511514DE und was er den 4 Geräten mitteilen will - nun gut.

[rudolfkoenig]

Erst bekam ich nur ein <no answer> aber nachdem er die Version gemeldet hat ging auch die raw-Abfrage.

Das ist komisch, d.h. mit dem Netzwerk (oder CUNO?) ist etwas nicht in Ordnung.

Entschluesselung der T02: 4x desired-temp(41) an vier(!) Geraete: 2F39,0C03,2529 und 0002, manchmal auch  Mode:Manual/Auto an den gleichen, ein report1 mit Flag ff an einem einzelnen. Das t Befehl ist reingerutscht und ist strenggenommen ein Bug, den ich aber nicht fixen werde.

Vermutlich wuerde ein Reset der CUNO3 guttun, und ein lazy Attribut den betroffenen FHTs. Eigentlich muesste man die Kommunikation der CUNO3 mit den FHTs fixen, aber das ist ein Projekt mit ungewissen Ausgang. Zum debuggen gibt es die Anleitung in der Wiki (insb X61), leider kann ich nicht versprechen, dass ich alles erklaeren kann, teilweise habe ich auch bei mir nicht erklaerbare Aussetzer mancher FHTs.

[Puschel74]

Hallo,

danke für den Link.
Ich hab CUNO3 erstmal mit raw T010303 den Buffer gelöscht.

4xdesired-temp? Eigenartig.
Die 3 FHT im Dachgeschoss fahren eigentlich manuell auf 17°C da dieser Bereich zur Zeit unbewohnt ist.
Notifys habe ich für diesen Bereich auch keine angelegt also sollte auch aus FHEM heraus keine Änderungen der Temperatur kommen.

Vermutlich wuerde ein Reset der CUNO3 guttun, und ein lazy Attribut den betroffenen FHTs.

Danke. Werde den FHTs mal das attribut zuweisen und weiter beobachten.

Macht es Sinn credit10ms weiter per at abzufragen?
Wohl eher nicht da sie sich ja sporadisch disconnecten.

Grüße

Edith: Ich hab die credit10ms-Abfrage mal zeitlich aufgeteilt und frage die Geräte im Abstand von 2 Minuten ab.
Jetzt habe ich mal ein bischen beobachtet und mit get CUNOx raw T02 mal geschaut an welche FHT die CUNO (und das CSM) so senden.
Obwohl für den FHT im Keller eigentlich der CSM als IODev eingetragen ist meint auch CUNO1 das er an den FHT was senden muss:

CUNO1 raw => 0002:600D,610A,620A,6302,6400 0002:65FF 2529:4125

0002 = FHT im Keller
2529 = FHT Gäste-WC - diesen wollte ich eingentlich an CUNO1 als IODev anlernen um den CSM zu "entlasten"

Edith2: Ich weiß ja nicht wielange diese Befehle im Buffer des CUNO bleiben aber ich hab jetzt mal an jedem den Buffer geleert und allen FHT das lazy-Attribut gesetzt.