Hallo HomeMaticer,
ich stehe vor einem riesen Problem. Ich habe mir einen HM-TC-IT-WM-W-EU und einen HM-CC-VD zugelegt. Beide Komponenten habe ich mit FHEM gepairt. Beim Versuch diese zu peeren (Anleitung unter http://www.fhemwiki.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP) hat mir FHEM eine Fehlermeldung ausgegeben (irgend etwas ziemlich langes) und zwei Drittel meiner fhem.cfg vollständig gelöscht (reproduzierbar).
Hier meine Einträge zum peeren:
set HM-TC-IT-WM-W-EU_Weather peerChan 0 HM-CC-VD single set
set HM-TC-IT-WM-W-EU_Climate peerChan 0 HM-CC-VD single set
Mit peerChan 1 und 2 meine ich es mal kurz am Laufen gehabt zu haben. Trau mich aber grad nicht mehr es zu testen, da die Reparatur meiner fhem.cfg sehr mühsam ist.
Ein seltsamer Effekt, der mir in diesem Zug aufgefallen ist, auf meiner 32GB-Karte sagt mir mein Raspberry es seien 5,?GB belegt und daher kein Platz mehr auf der Karte frei (wollte meine fhem.cfg Sicherung drauf kopieren).
Ich hab echt keine Ahnung was da los ist. Ich hatte gerde alles so schön am Laufen...
hi dan1180
Zitathat mir FHEM eine Fehlermeldung ausgegeben (irgend etwas ziemlich langes)
aha - ... - da ist mir gleich man nichts klar. soll ich einmal alle ziemlich langen Meldungen suchen?
Zitatzwei Drittel meiner fhem.cfg vollständig gelöscht (reproduzierbar).
welcher Teil? Evtl wäre die obige Fehlermeldung hilfreich.
Wo hast du eine Anleitung gefunden, einen VD mit einem TC-IT zu peeren? Das geht eh nicht.
ZitatEin seltsamer Effekt, der mir in diesem Zug aufgefallen ist, auf meiner 32GB-Karte sagt mir mein Raspberry es seien 5,?GB belegt und daher kein Platz mehr auf der Karte frei (wollte meine fhem.cfg Sicherung drauf kopieren).
was sind 5,?GB?
wenn die Karte voll ist, kann ein fhem.cfg nicht gesichert werden. Evtl solltest du hier erst einmal aufräumen. Das ist aber kein FHEM, schon garkein HM Problem
ZitatMit peerChan 1 und 2 meine ich es mal kurz am Laufen gehabt zu haben.
was ist peerChan 1 und 2?
was ist "meine ich"?
was war am Laufen?
Zitatda die Reparatur meiner fhem.cfg sehr mühsam ist.
warum? Kopieren einfach das File und spiele es ggf wieder ein - so einfach ist das.
Ein TC-IT kann keinen VD steuern - jedenfalls nicht direkt
Gruss Martin
Zitatset HM-TC-IT-WM-W-EU_Weather peerChan 0 HM-CC-VD single set
Cool... ich wusste gar nicht, dass ein VD einen Weather Channel hat :P
Hallo Martin,
erst einmal sorry für meine seltsamen Angaben. Es war heute Nacht ziemlich spät und ich ziemlich gefrustet...
Hier nochmal (hoffentlich) im Klartext:
1.) Die Fehlermeldung habe ich beim Versuch sie über copy&paste für das Forum zu speichern irgendwie veloren. Darin stand irgendwas von einem Komma und einer Aufzählung. Mehr weiß ich leider nicht. Ich dachte wenn der Fehler bekannt ist kennt jemand diese Fehlermeldung. Ich weiß, dass diese Aussage für sich nicht viel hilft.
2.) Zwei Drittel heißt, dass meine fhem.cfg mitten in den attribs für den HM-CC-VD "abgeschnitten" wurde und danach alles gelöscht war (bei einem späteren Versuch wurde die fhem.cfg komplett gelöscht, weshalb ich im Moment meinen RasPi komplett rücksichere). Darin enthalten alle 1wire Sensoren, Plots, Schaltaktoren...
3.) 5,?GB bedeuter, dass es 5.irgendwas (z.B. 5,4 oder 5,7) angezeigt hat. Aufräumen kann hier nicht das Problem sein, da meine SD Karte 32GB Speicherplatz hat. Die sind nur irgendwie verschütt gegangen?
4.) peerChan 1 bzw. 2 habe ich (als Versuch) aus http://www.fhemwiki.de/wiki/HM-CC-TC_Funk-Wandthermostat#Auszug_aus_der_fhem.cfg entnommen, da es mit 0 nicht funktioniert hatte. Eine Anleitung einen HM-TC-IT-WM-W-EU mit einem HM-CC-VD zu peeren habe ich von http://www.fhemwiki.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP
ZitatIm Gegensatz zum HM-CC-TC kann der HM-TC-IT-WM-W-EU auch andere HomeMatic-Schaltaktoren (z.B. HM-LC-SW1-FM) über den Channel 07 SwitchTr direkt anlernen, womit z.B. die Steuerung elektrischer Heizungen möglich wird. Der HM-CC-TC konnte direkt nur die HM-CC-VD steuern.
5.) Mühsam ist die Reparatur deshalb (gewesen) weil mir mein Raspi immer wieder angezeigt hat, dass ich keinen Speicherplatz mehr frei habe und ich immer wieder über den Remote Desktop neue Daten löschen musste um die fhem.cfg wieder kopieren zu können. Da dann ein "sudo reboot" nicht funktioniert hat musste ich in den Keller, ausstecken, einstecken, HM-Komponenten neu anlernen (welche im OG installiert sind)...
@betateilchen
Das mit dem _Weather ist wohl ein missverständmiss meinerseits aus der Anleitung (s.o.). Wie muss ich die Komponenten dann peeren?
Ich hoffe meine Erklärungen sind jetzt deutlicher. Vielen Dank für die Hinweise.
Bezüglich Speicherplatz: Es kann tatsächlich sein, dass du nur 5.X GB Speicherplatz im Dateisystem hast. Hast du das auf die vollen 32 GB erweitert? Anleitungen dazu gibt es im Internet.
Mach mal auf der Konsole ein:
df -h
Tatsächlich...Größe rootfs 5,8GB. Dann such ich mal nach der Anleitung. Kann das der Auslöser für all meine Probleme sein? Konnte fhem die .cfg nicht mehr richtig speichern weil der Platz aus war?
Vielen Dank!
Überprüfe mal die SD-Karte, kann sein, dass die hin ist.
Die Erweiterung geht doch über "Expand Filesystem" in der Raspi-Config? Da sagt mir mein System aber
ZitatYour partition layout is not currently supported by this tool. You are probably using NOOBS, in which case your root filesystem is already expanded anyway.
Ich habe aber trotzdem nur 5,8GB auf meiner 32GB Karte und, @Joachim, die ist nagelneu und wurde heute ausgetauscht, weil ich den selben Verdacht hatte. :'(
Neben den Problemen mit Speicher und setup:
einen TC-IT kann man nicht mit einem VD betreiben. Dieser TC sendet keine Ventileinstellungen! Ein CC-TC schon.
Du könntest einen Virtuellen TC bauen. Dann die Wetterdaten des TC-IT umrechnen in gewünschte Ventileinstellungen, und dann diese über den virtuellen TC an den VD schicken lassen. Mehr geht mit dieser HW nicht
Ok, dann hab ich ein (kleines) Problem. Auf dieser Annahme basiert meine gesamte Heizungs-Steuerungs-Planung. Ich habe in jedem Raum Fußbodenheizung und (meißt) auch einen Heizkörper. Die FBH wollte ich über Schaltaktoren, die Heizkörper mit Stellmotoren, ein- und ausschalten. Die Temperaturen und Regelungen sollten alle von einem TC-IT je Raum ausgehen. Natürlich alles über FHEM.
Ist es denn nicht möglich dem CC-VD zu sagen "Ventil auf" so lange Solltemp>Isttemp und "Ventil zu" wenn Solltemp=Isttemp? Ventil auf kann dann auch (je nach Bedarf) "Ventil 60% auf" sein.
Ich könnte mir folgendes vorstellen:
Wenn Soll - Ist >10 dann 100%
Wenn Soll - Ist >5 dann 70%
Wenn Soll - Ist > 2°C dann 50%
Wenn Soll - Ist = 0°C dann 20%
Wenn Soll - Ist < 2° dann 0%
Also nachdem ich mich nun eingehend mit verschiedensten Schriftstücken beschäftigt habe, bleibt bei mir immernoch große Frage offen:
Welchen Sinn hat der Stellmotor HM-CC-VD? Wo kann ich den einsetzen? Scheinbar kann ich den mit keinem Homematik-Thermostat pairen und ein peer über FHEM funktioniert auch nicht?! :-\
Hab ich da irgendwas grundsätzlich nicht verstanden?
a) VD von FHEM steuern
das ist möglich. Du musst einen virtuellen Aktor erstellen und den VD damit peeren. Der virtuellen Aktor aggiert dann als CC-TC (nicht TC-IT !) und sendet alle ~2,5 min (präzise Berechnung macht FHEM) an dem VD. Du musst die Ventilposition mit valvePos am virtuellen Aktor eingeben.
b) die ValvePos ermitteln
aus den Meldungen des TC-IT kannst du ermitteln, welche Position du einstellen willst. Möglichkeiten hast du viele: den SwitchTr des TC nutzen oder aus der Regeldifferenz berechnen
c) "Ventil auf"/"Ventil zu"
wenn dir das genügt ist es einfach. Aber zwischen 0 und 100% zu schwanken ist fraglich.
d) Regelung
das solltest du machen, denke ich. du nimmst (soll-temp - ist-temp)*10. Werte kleiner 0 setzt du '0'. Den wert schreibst du in das Ventil. Aus dauer ist dies aber nicht hinreichend - suche dir einen PI regel-algorythmus, der das besser macht
e) Beachte, dass HMLAN durch das viele senden belastet wird - beobachte die Auslastung.
Gruss Martin
p.s.: Der VD ist zusammen mit den CC-TC gedacht! Da funktioniert er problemlos
Hallo Martin,
ehrlich gesagt versteh ich noch nicht so ganz,wie ich das Ding zum Laufen bekomme. Liegt aber absolut an mir und meinen bisherigen Kenntnissen.
Du schreibst, der CC-VD ist zur Verwendung mit CC-TC gedacht. Der TC-IT ist aber laut FHEM-WIKI der Nachfolger des CC_TC...und der kann das nicht?
Vielen Dank so weit.
zu CC-TC und TC-IT lese einmal genau nach, wie das geht, wer mit wem. HM beschreibt das.
CC-VD + CC-TC
CC-RT allein
CC-RT - TC-IT
= > tauschen deine HW entsprechend. oder Bastle in FHEM:
Um deinen VD zu steuern mache erst einmal
Zitatdefine myTC CUL_HM 112233
set myTC virtual 1
rename myTC_Btn1 TC1
set TC1 peerChan 0 <vd> single
==> VD anlernen drücken
set TC1 valvePos 20
der vd sollte auf 20% schalten.
Die Regelung über notify bauen.
Gemacht wie befohlen ;D
Leider bewegt sich mein CC-VD nicht. Das Listing sieht folgendermaßen aus:
Internals:
DEF 1F914E
IODev HMLAN1
NAME CUL_HM_HM_CC_VD_1F914E
NR 196
STATE set_20 %
TYPE CUL_HM
protCmdPend 1 CMDs_pending
protState CMDs_pending
Readings:
2014-04-07 15:32:20 Activity alive
2014-04-07 15:17:16 CommandAccepted yes
2014-04-07 15:17:15 D-firmware 2.0
2014-04-07 15:17:15 D-serialNr KEQ0360571
2014-04-07 15:17:16 PairedTo 0xDD0111
2014-04-07 15:17:16 R-pairCentral 0xDD0111
2014-04-07 15:17:17 R-valveErrorPos 15 %
2014-04-07 15:17:17 R-valveOffset 0 %
2014-04-07 15:17:16 RegL_00: 02:01 0A:DD 0B:01 0C:11 00:00
2014-04-07 15:17:17 RegL_05: 09:00 0A:0F 00:00
2014-04-07 15:39:13 ValveDesired 20 %
2014-04-07 15:39:13 state set_20 %
cmdStack:
++A001DD01111F914E01011000010101
Helper:
mId 003A
oldDes 0
rxType 12
Io:
newChn +1F914E,00,01,1E
Prt:
bErr 0
sProc 2
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev HMLAN1
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 2.0
model HM-CC-VD
peerIDs 00000000,
room CUL_HM
serialNr KEQ0360571
subType thermostat
webCmd getConfig:clear msgEvents
Da scheint das Peeren nicht geklappt zu haben oder? Wobei das von TC1 den CC_VD unter peerIDs anzeigt:
Internals:
CFGFN
DEF 10000101
NAME TC1
NR 209
STATE ValveAdjust:20.0 %
TYPE CUL_HM
chanNo 01
device VIR_TC
peerList CUL_HM_HM_CC_VD_1F914E,
Readings:
2014-04-07 15:58:06 state ValveAdjust:20.0 %
2014-04-07 16:00:05 valveCtrl lost
2014-04-07 15:58:06 valvePosTC 20.0 %
Helper:
count 2
fkt vdCtrl
virtTC 00
Role:
chn 1
vrt 1
Vd:
ackT
cmd A2581000011F914E
id 1F914E
idh 0
idl 256
miss 9
msgCnt 9
msgRed 0
msgSent 0
next 1396879328.2587
nextM 1396879329.79267
typ 1
val 33
vin 20.0
Attributes:
model virtual_1
peerIDs 1F914E01,
webCmd press short:press long
peeren ist separat auf jeder seite. dass der TC1 dies anzeigt ist also ok, hat nichts mit der Sicht den VD zu tun.
im VD hängt noch eine message. da er nicht gepeert ist musst du config drücken, damit er diese Verarbeitet.
Config drücken? Meinst du die Anlerntaste? Wenn ja, leider keine Reaktion. Inzwischen habe ich auch ein "MISSING ACK in meinem Virtuellen Schalter. Hier das Listing:
Internals:
CFGFN
DEF 100001
IODev HMLAN1
NAME VIR_TC1
NR 324
STATE MISSING ACK
TYPE CUL_HM
channel_01 TC1_1
protCmdDel 7
protResndFail 7 last_at:2014-04-08 08:40:40
protSnd 7 last_at:2014-04-08 08:40:30
protState CMDs_done_Errors:1
Readings:
2014-04-08 08:40:40 state MISSING ACK
Helper:
rxType 1
Io:
newChn +100001,00,01,1E
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Attributes:
autoReadReg 4_reqStatus
expert 2_full
model virtual_1
msgRepeat 0
peerIDs
subType virtual
Der Stellmotor beharrt unverbesserlich auf seinen 15%...
ZitatConfig drücken? Meinst du die Anlerntaste?
ja.
ZitatInzwischen habe ich auch ein "MISSING ACK in meinem Virtuellen Schalter.
wenn dein vd immer noch nicht gepeert ist, muss das auch so sein. ;)
also vd mit vtc peeren.
set CUL_HM_HM_CC_VD_1F914E clear msgEvents
set TC1 peerChan 0 CUL_HM_HM_CC_VD_1F914E single set actor
anlerntaste vd 3 sec drücken
set CUL_HM_HM_CC_VD_1F914E getConfig
anlerntaste vd 3 sec drücken
erst wenn der peer im attribut peerIds eingetragen ist bist du fertig. dann sollte es funktionieren. anschliessend alles sichern mit save config.
gruss frank
Hallo Frank,
das peeren scheint funktioniert zu haben. Dake. Lag der Fehler daran, dass vorher kein "...set actor" beim peer-Befehl gesetzt wurde?
Ein paar kleine Fragen hätte ich da aber noch...
1.
Warum brauch ich den virtuellen Aktor? Warum kann ich das Ventil nicht direkt am gepairten VD steuern und dort mittels Programmierung für verschiedene Vorgaben gewisse Ventilstellungen vorgeben
(z.B. Solltemperatur TC-IT < Isttemperatur TC-IT -> Ventilstellung 50%)?
2.
Kann mir jemand sagen, in welchen Intervallen der VD "aufwacht" und sich sein todo anschaut? Holt er sich aktiv die anstehenden CMDs ab oder muss FHEM diese zufällig auch zu der Zeit senden?
3.
Ich möchte ja echt nicht nerven und ich habe es auch akzeptiert. Warum kann der TC-IT nciht mit dem CC-VD gepeert werden? Er hat doch auch einen _Climate Kanal, wie der CC-TC? Ich möchte es nur verstehen.
Vielen Lieben Dank an euch alle!
ZitatLag der Fehler daran, dass vorher kein "...set actor" beim peer-Befehl gesetzt wurde?
siehe einsteiger.doc! "...single set" oder "...single set both" setzt die peers im actor
und im remote. da der peer im remote bereits eingetragen war, musste nur noch im actor gesetzt werden.
ZitatWarum brauch ich den virtuellen Aktor? Warum kann ich das Ventil nicht direkt am gepairten VD steuern und dort mittels Programmierung für verschiedene Vorgaben gewisse Ventilstellungen vorgeben
(z.B. Solltemperatur TC-IT < Isttemperatur TC-IT -> Ventilstellung 50%)?
du brauchst keinen virtuellen actor, sondern ein virtuellen remote. der actor ist dein vd. warum ein vd nur von einem hm-cc-tc gesteuert werden kann, kann dir nur eq3 erklären.
ZitatKann mir jemand sagen, in welchen Intervallen der VD "aufwacht" und sich sein todo anschaut? Holt er sich aktiv die anstehenden CMDs ab oder muss FHEM diese zufällig auch zu der Zeit senden?
120 - 180 sekunden. der rythmus ist nicht konstant. siehe thread tc-emulieren. der vd wacht in diesen abständen für 250ms auf und erwartet dann seine befehle. wenn das 6 mal hintereinander nicht klappt schäft der vd ganz ein. nach ca 60 min kann er reannimiert werden.
ZitatIch möchte ja echt nicht nerven und ich habe es auch akzeptiert.
das ist gut. :)
ZitatWarum kann der TC-IT nciht mit dem CC-VD gepeert werden?
siehe 1. peeren könnte durchaus klappen. ;) der it wird wahrscheinlich nicht in dem augenblick, wenn der vd kurz aufwacht, den richtigen befehl senden. probieren geht über studieren.
ich nutze meine vd auch in kombination mit vtc. zusätzlich verwende ich noch das modul pid20 als regler. funktioniert bestens. sei froh, dass fhem seit kurzem überhaupt in der lage ist, den vd zu steuern!
gruss frank
Hallo Frank,
nochmal vielen Dank für die ausführlichen Antworten. Das heißt also theoretisch könnte der TC-IT mit dem CC-VD funktionieren. Es muss nur dann der Befehl gesendet werden, wenn der VD zuhört (sendet der CC-TC in kürzeren Abständen?).
Da ich jedoch meine Befehle alle über FHEM sende (pair und peer) und die FHEM-Befehle ja (über den VTC) "rechtzeitig" ankommen, könnte das doch eigentlich klappen?!? Das werd ich gleich mal probieren...
Der VTC funktioniert jetzt bestens. Nur springt mein VD nach einer gewissen Zeit (wahrscheinlich 6x erfolgloses hinhören) auf 15% zurück. Wie kann ich das noch vermeiden?
ZitatDas heißt also theoretisch könnte der TC-IT mit dem CC-VD funktionieren.
das war ironie! ;)
du kannst sie bestimmt peeren, doch wird der it den vd nicht steuern können. dazu müsste der it ventilpositionen senden. soweit ich das verfolgt habe, kann der aber nur temperaturen senden. er hat aber keinen regler der aus soll und ist eine ventilposition berechnet.
gruss frank
Und dafür brauch ich dann spätestens einen VTC? Oder kann ich die Regelung direkt im VD programmieren?
Was mach ich nun mit meinem VD wenn er sich nach einer Zeit x wieder schlafen legt?
...und Ironie ist bei einem Anfänger wie mir immer gefährlich ;)
ZitatDer VTC funktioniert jetzt bestens. Nur springt mein VD nach einer gewissen Zeit (wahrscheinlich 6x erfolgloses hinhören) auf 15% zurück. Wie kann ich das noch vermeiden?
da müsstest du mal rohmessages aus fhem.log posten.
attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs VIR_TC1,CUL_HM_HM_CC_VD_1F914E
attr TC1 verbose 5ZitatUnd dafür brauch ich dann mindestens einen VTC? Oder kann ich die Regelung direkt im VD programmieren?
der virtuelle tc ist dafür gedacht den realen vd mit entsprechenden befehlen zu passenden momenten zu steuern. du übergibst dem vtc eine ventilstellung und dieser kann sie dann dem vd mitteilen.
der vd hat keine regelung. das ist nur ein stellglied. er bekommt eine sollposition und stellt diese dann ein.
eine regelung berechnet aus einer ist- und solltemperatur eine ventilposition. das kannst du mit einem fhem-modul machen. da gibt es zum beispiel das modul pid20. suche mal nach pid20 im forum. dem regelmodul gibst du soll und ist temperatur. dieses berechnet dann eine ventilposition, die dem vtc übergeben wird.
gruss frank
ich hätte da noch einen tipp.
ich spekuliere mal, dass du den thread http://forum.fhem.de/index.php/topic,18193.msg120864.html#msg120864 (http://forum.fhem.de/index.php/topic,18193.msg120864.html#msg120864) noch nicht vollständig durchgearbeitet hast. ;)
daher denke ich das einschlafen deines vd ist entweder nach fhem reboot oder ähnlichem geschehen. damit fhem mit dem vd fehlerfrei kommunizieren kann, wird der lezte erfolgreiche kommunikationszeitpunkt zur berechnung des neuen zeitpunktes benötigt. dieser wird normalerweise nur in fhem in einem normalerweise unsichtbaren reading (.next) zwischengepeichert. um nach reboot immer einen aktuellen wert zu haben, muss diese variable ständig gespeichert werden.
ich mache dies durch einfügen des folgenden codes in fhem.cfg
define AutoSave at +*00:15:00 {\
{BlockingCall("WriteStatefile", "","", 30,"", "")}\
}
attr AutoSave room 99_System
dann kann der vd sogar 5min stromausfall meines servers überleben.
gruss frank
Die Rohmessages? Hab ich noch nie gebraucht ???
ISt das der Teil des fhem.log, der nach dem verbose 1 geschreiben wird? Der sieht so aus:
2014.04.08 18:25:32 4: HTTP FHEMWEB:192.168.2.103:51931 GET /fhem&cmd=attr+global+verbose+1
2014.04.08 18:25:32 5: Cmd: >attr global verbose 1<
2014.04.08 18:25:58.533 1: 192.168.2.151:1000 reappeared (HMLAN1)
2014.04.08 18:25:58.547 1: HMLAN_Parse: HMLAN1 new condition init
2014.04.08 18:25:58.693 1: HMLAN_Parse: HMLAN1 new condition ok
2014.04.08 18:26:22.092 5: CUL_HM TC1_1 m:177 ->178 t:1396974379.70243->1396974511.95243 M:1396974382.09205 :132.25
2014.04.08 18:26:22.100 0: HMLAN_Send: HMLAN1 S:S42296D58 stat: 00 t:00000000 d:01 r:42296D58 m:B2 A258 100001 1F914E 0080
2014.04.08 18:26:34.267 0: HMLAN_Parse: HMLAN1 R:R42296D58 stat:0008 t:00000000 d:FF r:7FFF m:B2 A258 100001 1F914E 0080
2014.04.08 18:26:34.271 0: HMLAN_Parse: HMLAN1 no ACK from 1F914E
2014.04.08 18:26:41.512 5: CUL_HM TC1_1 virtualTC use fail-timer
Ansonsten bitte kurze Erläuterung.
Zu deinem Tipp...nein, den Beitrag kannte ich noch gar nicht. Mein Problem mit Beiträgen dieser Art ist, glaube ich, dass ich nicht nach Worten wie "emulieren" suche :-\
Werd ihn mir auf jeden Fall mal ansehen, Danke.
Was ich aber gleich sagen kann ist, dass das Einschlafen nicht nach einen Neustart passiert ist.
Peeren -> Ventilpos. auf 50% -> warten -> Einschlafen...
ZitatDie Rohmessages?
http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen
Zitat
Peeren -> Ventilpos. auf 50% -> warten -> Einschlafen...
der VD hält einige Zeit tapfer durch bis er aufgibt. Also in den Rohmessages suhen (in den Readings stehen auch hinweisen)
Hallo Martin,
die Anleitung aus dem Wikli hatte mir Frank schon gepostet, danke. Dort steht aber leider auch nicht wirklich welches der relevante Teil ist, den ich aus meinem Log dann kopieren soll.
Seltsamerweise ist mein VD mittlerweile wieder wach ??? Nachdem ich ihn vor gut 3 Stunden schlafend auf 15% verlassen hatte steht er mittlerweile wieder auf den zuletzt eingestellten 50%...und ich hab nix gemacht...wirklich!
Hab ihm jetzt befohlen auf 20% zu gehen und will sehen, was er bis morgen macht. Mittlerweile werde ich wohl noch dem ein oder anderen Hinweis von euch nachgehen und kräftig Beiträge lesen. Ich will dieses Ding in den Griff bekommen!
Wäre nett wenn du mir noch 1-2 Zeilen zur Rohmessage schicken könntest. Oder einen link zu ner Erklärung. Vielen Dnak dafür!
Beachte das Verfahen:
der VD wacht leicht unregelmäßig auf - FHEM berechnet dies und sendet die Einstellungen. Wenn die beiden ausser tritt geraten dauert es etwas - irgendwann beginnt der VD quasi zu suchen.
=> normal kommen sie nicht ausser tritt
=> reboots können so etwas hervorrufen
=> nach einiger zeit (etliche Minuten) sollten sie sich wieder fangen
Du solltest valveCtrl beobachten - da steht drin, ob du noch Synchron bist
Hallo Martin,
in einem Punkt kann ich dir Recht geben...der VD fängt sich immer wieder. Dummerweise fällt er auch ständig wieder in den Error-Moder (ValvePos 15%). Eine Möglichkeit, dass er wieder zu sich kommt ist das (kurze) Drücken der Anlerntaste. Was ja irgendwie logisch ist wenn er manuell geweckt wird.
valveCtrl hat mir in der Fehlersituation auch immer einen Fehler angezeigt. Seit gut einer halben Stunde hab ich jetzt gar kein Reading namens valveCtrl mehr...aber im Moment (nach Drücken der Anlerntaste) tut auch alles.
Würde euch gerne mal noch über die Rohmessage schauen lassen, wenn mir jemand erklären kann wie ich die genau hier posten kann...
Danke.
wenn du die messages aufgezeichnet hast einfach mit "erweiterte optionen" die Datei anhängen
So, da bin ich wieder. Musste beruflich ein paar Tage weg...
Wie man eine Datei anhängt ist mir klar...ich weiß nur nicht welche?!? :-\
Wo wird die Rohmessage gespeichert. Hab da leider nichts zu gefunden.
wenn du sie eingeschaltet hast werden sie im globalen Log abgelegt
Hallo zusammen,
ich hab jetzt mal die log-Datei der letzten 24h angehängt. Ich hoffe, ich hab das mit den Rohmessages richtig eingeschaltet. Wie schalte ich das wieder aus? Oder hat das keinen Einfluss auf die Größe der log-Dateien?
Es ist noch immer so, dass der VD immer wieder die Verbindung verliert und auf 15% geht, dann nach einer Weile wieder Verbindung aufnimmt und die eingestellten 0% anfährt.
Bin wirklich jedem von euch für die Hilfe dankbar!
das Timing deines Systems ist unzuverlässig.
Beispiel
20:42:09.642 TC1_1 :150.25 => next trigger in 42:09.642 + 150.25sec = 44:39.89
20:42:09.850 Parse: m:58 8202 1F914E 100001 0101000044
20:44:39.898 TC1_1 :135.75 => trigger perfekt, next um 46:55.65
20:44:40.119 Parse: m:59 8202 1F914E 100001 0101000044
20:46:55.651 TC1_1 :121.5 => trigger perfekt, next um 48:57.15
20:46:55.905 Parse: m:5A 8202 1F914E 100001 0101000044
20:49:01.872 TC1_1 :171 => UPPS!!! 4 sec zu spät. next um 48:57.15 + 171 = 51:48.15
20:49:11.878 TC1_1 virtualTC use fail-timer
20:51:48.159 TC1_1 :156.5 => trigger perfekt, next um 53:24.66
20:51:48.474 Parse: m:5C 8202 1F914E 100001 0101000044
20:54:24.664 TC1_1 :142.25 => trigger perfekt, next um....
20:54:25.150 Parse: m:5D 8202 1F914E 100001 0101000044
Dein system muss sehr präzise antworten, damit nichts schief geht. Das macht es nicht immer. Du musst also suchen, welche Prozesse hie und da einen Delay einbauen.
Du könntest mit apptime einmal nach langläufern suchen - oder probieren, welche Processe hier zu bummeln.
Die Verzögerung war hier immerhin 4 sec - für echtzeit ein Unding.
Kann das an meinen 1Wire Sensoren liegen? Ich habe bei manchen event-on-change-reading aktiviert. Ich könnte mir vorstellen, dass ein Reading aufgrund eines Canges dazwischenfunkt wenn die HM Komponenten ihre Signale austauschen. Kann das sein? Ich werde das Attribut mal bei allen deaktivieren.
möglich... ist vieles.
4 Sec ist eine lange Zeit... - um es zum kippen zu gringen bracht es erheblich weniger.
starte einmal apptime und werte die Zeiten aus. Das wäre m.E. der 1. Schritt.
Hier das Resultat von apptime:
name function max count total average maxDly
tmr-OWTHERM_GetValues HASH(0x27ae330) 7416 2 14284 7142.00 11988 HASH(0x27ae330)
tmr-OWTHERM_GetValues HASH(0x27ae7b0) 6957 2 13814 6907.00 11742 HASH(0x27ae7b0)
tmr-OWTHERM_GetValues HASH(0x27aec30) 6890 2 13747 6873.50 11963 HASH(0x27aec30)
tmr-OWTHERM_GetValues HASH(0x2779498) 6888 2 13748 6874.00 12174 HASH(0x2779498)
tmr-OWTHERM_GetValues HASH(0x27936a8) 6885 2 13732 6866.00 12055 HASH(0x27936a8)
tmr-OWTHERM_GetValues HASH(0x27ac9c0) 6881 2 13732 6866.00 12033 HASH(0x27ac9c0)
tmr-OWTHERM_GetValues HASH(0x2793b28) 6880 2 13748 6874.00 12033 HASH(0x2793b28)
tmr-OWTHERM_GetValues HASH(0x27ace40) 6880 2 13729 6864.50 11990 HASH(0x27ace40)
tmr-OWTHERM_GetValues HASH(0x2792488) 6874 2 13732 6866.00 12277 HASH(0x2792488)
tmr-OWTHERM_GetValues HASH(0x2792908) 6873 2 13736 6868.00 12322 HASH(0x2792908)
tmr-OWTHERM_GetValues HASH(0x2792da8) 6870 2 13726 6863.00 12244 HASH(0x2792da8)
tmr-OWTHERM_GetValues HASH(0x2735de0) 6869 2 13724 6862.00 12013 HASH(0x2735de0)
tmr-OWTHERM_GetValues HASH(0x2792008) 6868 2 13725 6862.50 12285 HASH(0x2792008)
tmr-OWTHERM_GetValues HASH(0x27af0d0) 6868 2 13734 6867.00 11968 HASH(0x27af0d0)
tmr-OWTHERM_GetValues HASH(0x27af550) 6867 2 13726 6863.00 12093 HASH(0x27af550)
tmr-OWTHERM_GetValues HASH(0x2778b98) 6866 2 13720 6860.00 12101 HASH(0x2778b98)
tmr-OWTHERM_GetValues HASH(0x2779918) 6866 2 13714 6857.00 12146 HASH(0x2779918)
tmr-OWTHERM_GetValues HASH(0x2779018) 6864 2 13727 6863.50 12081 HASH(0x2779018)
tmr-OWTHERM_GetValues HASH(0x2793228) 6863 2 13702 6851.00 12345 HASH(0x2793228)
HMLAN1 HMLAN_Read 142 11 663 60.27 0 HASH(0x2219840)
FHEMWEB:192.168.2.103:51120 FW_Read 120 6 153 25.50 0 HASH(0x2ad4e98)
Was kann man da jetzt sehen?
max: Zeit in ms. Du hast jede Menge Jons, die ~7sec dauern. Die wurden im Beobachtungszeitraum 2-mal aufgerufen.
Das sind wohl one-wire timern (tmr sind Timer).
Diese Prozedur "OWTHERM_GetValues" ist schlicht nicht echtzeitfähig - die blockiert dein FHEM KOMLETT für 7 sec - immer wieder.
Du solltest mit dem Entwickler reden - ich sehe das als ernstes Problem.
Eine Prozedur kann schon einmal länger dauern... aber regelmäßig geht das nicht.
Der Entwickler muss dies in einen separaten Threat auslagern - oder sonst wie gerhacken. Offensichtlich wird hier aktiv gewartet.
Das kann u.a. dazu führen, dass deine Schaltkommandos um 7 sec verzögert werden - allein das ist schon nervig...
Ich habe jetzt mal alle OWTHERM, sowie meinen OWX, deaktiviert. Nun sieht das Ergebnis von "apptime" so aus:
name function max count total average maxDly
tmr-CUL_HM_updateConfig updateConfig 496 1 496 496.00 4 updateConfig
HMLAN1 HMLAN_Read 80 16 164 10.25 0 HASH(0x2b913c0)
eventTypes eventTypes_Define 59 1 59 59.00 0 HASH(0x2b8a310); eventTypes eventTypes ./log/eventTypes.txt
tmr-CUL_HM_procQs CUL_HM_procQs 44 4 116 29.00 150 CUL_HM_procQs
tmr-CUL_HM_respPendTout respPend:254C27 44 8 107 13.38 196 respPend:254C27
HMLAN1 HMLAN_Define 34 1 34 34.00 0 HASH(0x2b913c0); HMLAN1 HMLAN 192.168.2.151:1000
tmr-CUL_HM_respPendTout respPend:254AEA 29 5 53 10.60 2171 respPend:254AEA
GlobalAttr 19 13 20 1.54 0 set; global; modpath; .
tmr-CUL_HM_valvePosUpdt valvePos:10000101 11 1 11 11.00 3856922 valvePos:10000101
HKS_BD CUL_HM_Set 9 2 18 9.00 0 HASH(0x1eb0058); HKS_BD; ?
HKT_BU_Clima CUL_HM_Set 9 2 17 8.50 0 HASH(0x2b07ee8); HKT_BU_Clima; ?
TC1B1 CUL_HM_Set 9 2 17 8.50 0 HASH(0x28a4340); TC1B1; ?
VIR_SA1 CUL_HM_Define 9 1 9 9.00 0 HASH(0x2a99eb0); VIR_SA1 CUL_HM 100002
WTS_BD CUL_HM_Attr 9 14 10 0.71 0 set; WTS_BD; model; HM-TC-IT-WM-W-EU
HMSA4.1 CUL_HM_Define 8 1 8 8.00 0 HASH(0x2219510); HMSA4.1 CUL_HM 254C27
HMSA4.2_3 CUL_HM_Set 8 2 11 5.50 0 HASH(0x27359d0); HMSA4.2_3; ?
VIR_TC1 CUL_HM_Define 8 1 8 8.00 0 HASH(0x2a9b520); VIR_TC1 CUL_HM 100001
WTS_BD_Climate CUL_HM_Set 8 2 16 8.00 0 HASH(0x1daaa08); WTS_BD_Climate; ?
HKS_BD CUL_HM_Define 7 1 7 7.00 0 HASH(0x1eb0058); HKS_BD CUL_HM 1F914E
HKT_BU CUL_HM_Attr 7 13 8 0.62 0 set; HKT_BU; model; HM-CC-RT-DN
HKT_BU CUL_HM_Define 7 1 7 7.00 0 HASH(0x2b12e20); HKT_BU CUL_HM 248BD9
Besser oder? Ich denke, dass es eine gute Idee ist an anderer Stelle dieses Problem zur Diskussion zu stellen. Wo finde ich heraus wer der Entwickler dieses Moduls ist? Darf ich dem deine Bemerkung, was er machen sollte, schicken?
Werde jetzt mal meinen VD beobachten...aber ich habe da eine Vermutung wie oft er sich jetzt aufhängt... ;)
Soweit mal vielen Dank!
im file MAINTAINER.txt sind die Namen aufgeführt. In diesem Fall "pahenning".
Du kannst es einfach im 1-wire bereich posten - da sollte er als maintainer sowieso aktiv sein.
Klar kannst du meinen Kommentar posten.
Vielleicht hat er eh schon eine Lösung für das Problem....
Also ich hab das mal im "1wire" Forum gepostet und die sind der Meinung, dass mein Selbstgebauter DS9097 daran schuld ist. Also nicht weil ich den falsch gebaut habe sondern weil:
ZitatDie Verzögerungen kommen daher, dass OWTHERM beim normalen OWX bei jeder Themperaturmessung den DS18B20 erst triggern und nach Abschluss der Messung (ca. 1 Sekunde Verzögerung) auslesen kann. Die Sekunde Verzögerung erfolgt mit OWX immer synchron (d.h. einfach durch Anhalten des Prozesses). 19 Sensoren machen damit 19 Sekunden Wartezeit, verteilt auf das Wiederholinterval.
Seit ich meinen OWX und die Sensoren deaktiviert habe rennt mir FHEM beinahe davon ;D ...und ich finde in den letzten 24h keinen Aussetzer mehr im log meines VD 8)
Ich denke als Fazit kann ich zusammenfassen, dass mein langsamer OWX schuld an der ganzen Misere ist. Warum es mir meine fhem.cfg zerschossen hat weiß ich zwar noch nicht aber das kann auch ein individueller Fehler gewesen sein. Auf jeden Fall war an der fehlerhaften Kommunikation ein (unregelmäßiges) Blockieren der durch die OWTHERM-Sensorabfrage schuld. Gefunden wurde dieser Fehler durch den Befehl "apptime". Hier wurde deutlich, dass FHEM von OWTHERM 7-11 Sekunden beschäftigt wurde...eindeutig zu lane.
Vielen Dank an alle, die mich bei der Fehlersuche unterstützt und mir mit ihren Tipps geholfen haben. Ich hoffe irgendwann mal einem neuen, nervigen newbe mit meinem (dann angeeigneten) Wissen um FHEM helfen zu können ;D
Werd diesen Beitrag Ende der Woche schließen, falls jemand noch etwas anmerken oder nachfragen möchte.
Zitat...und ich finde in den letzten 24h keinen Aussetzer mehr im log meines VD
so kenne ich das auch. na dann viel spass.
gruss frank
@ dan1180,
Einfach mal als Tipp, dass 1-Wire FHEM verzögert, ist bekannt, und ein Designfehler beider! 1-Wire-Varianten für FHEM.
Wenn man 1-Wire Sensoren auf eine eigene FHEM-Instanz auslagert, und dann mit FHEM2FHEM und cloneDummy abfragt, dann läuft es hervorragend.
Anders ausgedrückt, 1-Wire mag nichts anderes neben sich.
Gruß Joachim
Die alternative wäre, 1-wire mit blocking zu implementieren. Da ich mir aber 1-wire nicht angesehen habe, könnte dies durchaus schwierig werden.
Im Prinzip ist daher Joachims Vorschlag wohl der pragmatische.
Ist der Betrieb mit einem aktiven BUS eine Alternative um FHEM zu "entlasten"? Das wurde mir nämlich im 1wire Forum vorgeschlagen. Kommt das einem 2. FHEM gleich?
Jain,
wie im letzten Beitrag von mir schon geschrieben, gibt es einen grundsätzlichen Designfehler in den 1-Wire-Modulen, der FHEM auf jeden Fall ca.1200 msec blockiert. Damit muss man z.Z. bei 1-Wire leben, auch wenn hier Abhilfe in Arbeit ist.
http://forum.fhem.de/index.php/topic,13580.0.html
Das ist aber z.Z. noch experimentell, und kostet Hardwareperformance.
Diese Verzögerung kann man auch mit einem aktiven Busmaster nicht beseitigen, deshalb mein Vorschlag mit seperater FHEM Instanz, FHEM2FHEM und cloneDummy. Dafür habe ich den cloneDummy gebaut.
Das andere Problem ist wahrscheinlich Dein passiver Eigenbau Busmaster. Bei dem wird die "low level" Kommunikation durch FHEM/OWX resourssenverbrauchend auf Deiner Hardware gemacht, dabei muß Durch die Hardware die Kommunikation ("High und Low") auf dem Bus peinlich genau eingehalten werden. Wenn hier die Zeitschlitze nicht stimmen, funktioniert die Kommunikation mit den Sensoren nicht, es kommt zu Lesefehlern und die Zeit, in der FHEM blockiert wird verlängert sich. hier kann ein aktiver Busmaster helfen, da sich dieser dann selbst um die Kommunikation auf dem Bus kümmert, und die Hardware auf der FHEM läuft raus ist. Zusätzlich gibt es bei einigen aktiven Busmasten aktive pull up widerstände, die für eine bessere Flankensteilheit zwischen High und Low sorgen, und damit die Stabilität auf dem Bus erhöhen.
Gruß Joachim
Und die 1200msec sind für meine HM Kommunikation schon zu viel? Einen zweiten RasPi mit FHEM aufzusetzen würde ich gerne vermeiden, wenn, wie du schreibst, eine Lösung für FHEM unterwegs ist. Weiter wird im 1Wire Forum von einem Asynchron Befehl gesprochen, der dann die 1Wire Abfrage im Hintergrund macht. Den hab ich mir aber noch nicht anschauen können.
Macht es einen signifikanten Unterschied ob ich 1 oder 19 Sensoren abfrage? Ich stelle mir übergangsweise vor nur auf Befehl einzelne Sensoren abzufragen. Das würde es mir mal für die erste Zeit tun. Zumindest bis es eine Lösung gibt oder ich die Zeit habe mich mit einem zweiten FHEM zu beschäftigen.
Ihr solltet die Diskussion in 1-wire forum fortsetzen - dort wird ggf. nach Lösungen gesucht, die ow erzeugt
Nochmal danke an alle!