Wird das neue HomeMatic Funk-Heizkörperthermostat (HM-CC-RT-DN) bereits von FHEM unterstützt?!
Du bist nicht der erste, der das hier im Forum fragt. Hast Du Dir die bisherigen Antworten schon durchgelesen?
es gibt einen Anfang. in HMInfo "set hm models" kannst du es doch schon sehen.
Da bisher noch keiner eines hat ist es natürlich komplett ungetestet.
Achso ich dachte die wären schon längst erschienen.
Hatte das eine Zeit lang nicht verfolgt und nur gesehen, dass die Lieferzeit eine Woche beträgt ...
gestern/vorgestern wurden die ersten Regler ausgeliefert.
Die aktuelle Entwicklung in fhem kannst Du ab hier verfolgen: Link (http://forum.fhem.de/index.php?topic=12081.msg94917#msg94917)
hi,
habe gerade einen update eingestellt (version 3932)
Die Channel-default-namen habe ich geaendert (immer wenn mir die bedeutung klar wird ;-))
Channel5 ist 'ClimaTeam' da hier die RTs gepairt werden, die 'in einem zimmer' liegen. Also wenn man einen soll-wert aendert werden alle in einem Team auch geaendert.
Man kann die "auto-tabelle" auslesen (getConfig) und in chn 4 besichtigen.
das aendern ist programmiert, hat aber noch ein problem. Die msg werden akzeptiert,werte dennoch ignoriert.... Evtl liegt es daran, dass meine gerade in einem Team sind.... noch ungeklärt.
viel Spass beim testen. Da noch viele Punkte offen sind, bitte kommentare klar ausarbeiten.
Falls jemand anforderungen bezüglich Heizungssteerung formulieren kann, super
Gruss Martin
so mit 3933 kann man jetzt auch die "wochentemp" programmieren. Leider geht autoReadReg nicht, da das Device nach den Schreiben erst eine pause braucht
Hi,
mich würde interessieren ob der neue Regler auch über externe Fensterkontakte und Temperatursensoren (1Wire) gefüttert werden kann (wenngleich derzeit wohl zuwenig Praxis Erfahrungen mit dem gerade erst in der Auslieferung befindlichen Regler existieren), etwas ähnliches scheint ja mit dem Max Regler bereits zu funktionieren.
Greetz
Eldrik
steht so in der Anleitung, kannst du einmal lesen
- externe Fensterkontakte
- externer Temp fühler
- fernbedienung
-internes erkennen "offenes Fenster" wenn kein externer Fensterkontakt
- team building mit anderen RTs im gleichen Raum
getestet habe ich noch nicht, bin dabei
Hi,
Ja das hatte ich auch gelesen, aber doch bestimmt nur mit homematic Geräten oder?
Über die Testerfahrungen und mögliche Codeschnippsel würd ich mich in dem Zusammenhang freuen.
Greetz
Eldrik
nun, es wird sich wohl alles simulieren lassen.... mit virtuellen aktoren
Version 3935 kann sogar schon temperaturen einstellen....
p.s. meine RT arbeiten gut im burst mode. Falls jemand probleme hat mit der übertragung, bitte melden. Ist so nicht dokumentiert und könnte mit dem Eintragen vom peers zusammenhängen.
Zitat von: martinp876 schrieb am Sa, 21 September 2013 14:56Version 3935 kann sogar schon temperaturen einstellen....
In welchem Channel? Muss ich dazu den RT neu pairen?
channel 4. da spielt aktuell die musik.
peered funktioniert auch. Team(channer 5) koppelt die Thermostate. remote habe ich auch schon getested.
Fenster noch nicht
Zitat von: martinp876 schrieb am Sa, 21 September 2013 14:55nachkommastelle kommt.
danke :)
Zitat von: martinp876 schrieb am Sa, 21 September 2013 14:55auf .*battery.* zu parsen ist nicht empfehlenswert
ich parse auf
.*:[Bb]attery:.* das scheint erstmal wieder korrekt zu funktionieren.
Ich hab übrigens schon eine neue Baustelle: HM-LC-Sw4-Ba-PCB - aber das wird ein anderes Thema.
Hallo,
ich bekomme keine Temp übermittelt, habe immer Missing ACK
Setze 10_CUL_HM.pm 3936 ein und auf channel 4 (Heiz_AZ_ClimRT_tr) habe ich das aus dem log
2013.09.22 12:43:49 5: Triggering Heiz_AZ_ClimRT_tr (1 changes)
2013.09.22 12:43:49 5: Notify loop for Heiz_AZ_ClimRT_tr set_desired-temp 25.0
2013.09.22 12:43:49 2: CUL_HM set Heiz_AZ_ClimRT_tr desired-temp 25.0
2013.09.22 12:43:49 5: HMLAN_Send: HMLAN1 I:+228636,00,00,
2013.09.22 12:43:49 5: HMLAN_Send: HMLAN1 S:S4544AB89 stat: 00 t:00000000 d:01 r:4544AB89 m:01 B011 A1B23C 228636 860432
2013.09.22 12:43:51 5: HMLAN_Parse: HMLAN1 R:R4544AB89 stat:0008 t:00000000 d:FF r:7FFF m:01 B011 A1B23C 228636 860432
2013.09.22 12:43:51 2: HMLAN_Parse: HMLAN1 new condition ok
2013.09.22 12:43:51 5: Triggering HMLAN1 (3 changes)
2013.09.22 12:43:51 5: Notify loop for HMLAN1 cond: ok
2013.09.22 12:43:51 5: HMLAN_Parse: HMLAN1 no ACK from 228636
2013.09.22 12:43:52 5: HMLAN_Send: HMLAN1 S:S4544B514 stat: 00 t:00000000 d:01 r:4544B514 m:01 B011 A1B23C 228636 860432
2013.09.22 12:43:52 4: CUL_HM_Resend: Heiz_AZ nr 2
2013.09.22 12:43:54 5: HMLAN_Parse: HMLAN1 R:R4544B514 stat:0008 t:00000000 d:FF r:7FFF m:01 B011 A1B23C 228636 860432
2013.09.22 12:43:54 5: HMLAN_Parse: HMLAN1 no ACK from 228636
2013.09.22 12:43:56 5: HMLAN_Send: HMLAN1 S:S4544C419 stat: 00 t:00000000 d:01 r:4544C419 m:01 B011 A1B23C 228636 860432
2013.09.22 12:43:56 4: CUL_HM_Resend: Heiz_AZ nr 3
2013.09.22 12:43:58 5: HMLAN_Parse: HMLAN1 R:R4544C419 stat:0008 t:00000000 d:FF r:7FFF m:01 B011 A1B23C 228636 860432
2013.09.22 12:43:58 5: HMLAN_Parse: HMLAN1 no ACK from 228636
2013.09.22 12:43:58 5: HMLAN_Send: HMLAN1 S:S4544CB5A stat: 00 t:00000000 d:01 r:4544CB5A m:01 B011 A1B23C 228636 860432
2013.09.22 12:43:58 4: CUL_HM_Resend: Heiz_AZ nr 4
2013.09.22 12:44:00 5: HMLAN_Parse: HMLAN1 R:R4544CB5A stat:0008 t:00000000 d:FF r:7FFF m:01 B011 A1B23C 228636 860432
2013.09.22 12:44:00 5: HMLAN_Parse: HMLAN1 no ACK from 228636
2013.09.22 12:44:01 5: Triggering Heiz_AZ (1 changes)
2013.09.22 12:44:01 5: Notify loop for Heiz_AZ MISSING ACK
2013.09.22 12:44:05 5: HMLAN_Send: HMLAN1 I:K
2013.09.22 12:44:05 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0185774 d:1ACB23 O:A1B23C t:001736E6 IDcnt:0001
2013.09.22 12:44:16 5: HMLAN_Parse: HMLAN1 R:E228636 stat:0000 t:00176360 d:FF r:FFD4 m:53 8610 228636 000000 0AB0F2110510
2013.09.22 12:44:16 5: HMLAN1 dispatch A0F5386102286360000000AB0F2110510::-44:HMLAN1
2013.09.22 12:44:16 5: Triggering Heiz_AZ_ClimRT_tr (6 changes)
2013.09.22 12:44:16 5: Notify loop for Heiz_AZ_ClimRT_tr motorErr: ok
2013.09.22 12:44:16 5: Triggering Heiz_AZ (2 changes)
2013.09.22 12:44:16 5: Notify loop for Heiz_AZ battery: ok
Mache ich einen Fehler?
Gruß Otto
hallo Otto,
kann sein, dass es ein Protokoll-problem ist. Evtl funktioniert der burst mode bei dir (noch) nicht.
burst versus wakeup
bei wakeup muss man warten, bis der rt aufwacht, dann muss man sich sputen und senden.
burst: der rt ist im "semi-schlummer-mode"und kann jederzeit geweckt und befragt werden.
burst verbraucht mehr batterie(keine Ahnung wie viel)
erst einmal ist nur wakeup zugesichert. Wenn devices gepeert sind, die trigger an den rt senden dürfen mussder rt auch burst können, schaltet also auch burst ein.
ich hatte den rt gepeert (team-peer) und dann den peer wieder gelöscht. Dennoch kann ich ohne Probleme burst nutzen. daher habe ich auch burst zugelassen(und nach eueren erfahrungen gefragt..)
in der Datei im Anhang ist burst wieder off. der rt empfängt also nur wenn er aufwacht oder du anlernen drückst.
Probiere es einmal und berichte.
Ich werde an einem Verfahren arbeiten, dass flexibel arbeitet. mal sehen.
Gruss Martin
Hallo,
ich mache gerade auch erste Versuche mit einem HM_HM_CC_RT_DN und habe mit der aktuellen
Version: 10_CUL_HM.pm 3936 und dem HMConfig von heute morgen auch das Problem, dass ich
nur dann Daten an das Device schicken kann, wenn ich vorher die Anlerntaste drücke.
Nur dann kann ich z.B. beim ClimRT_tr die desired_temp oder die temp_list verändern (so dass
es auch am Device ankommt). Ansonsten führt jedes Kommande zum einem protResndFail.
Ich nutze einen HMLAN zur Kommunikation - fhem ansonsten auch komplett vorher upgedated.
Gruß Ralph
Hi,
ja, es geht beim Anlernen und wohl auch beim Aufwachen
2013-09-22_17:00:34 Heiz_AZ_ClimRT_tr T:24.7 desired:25 valve:68 %
2013-09-22_17:00:36 Heiz_AZ_ClimRT_tr set_desired-temp 19.0
2013-09-22_17:02:19 Heiz_AZ_ClimRT_tr set_desired-temp 18.0
2013-09-22_17:02:42 Heiz_AZ_ClimRT_tr motorErr: ok
2013-09-22_17:02:42 Heiz_AZ_ClimRT_tr measured-temp: 24.8
2013-09-22_17:02:42 Heiz_AZ_ClimRT_tr desired-temp: 25
2013-09-22_17:02:42 Heiz_AZ_ClimRT_tr ValvePosition: 68 %
2013-09-22_17:02:42 Heiz_AZ_ClimRT_tr mode: auto
2013-09-22_17:02:42 Heiz_AZ_ClimRT_tr T:24.8 desired:25 valve:68 %
2013-09-22_17:02:43 Heiz_AZ_ClimRT_tr set_desired-temp 20.0
18 Grad wurde um 17:02:42 übernommen, die 20 Grad hat er dann beim Anlernen übernommen.
Gruß Otto
Ich denke übrigens nicht, dass der aktivierte burst Modus an einem Homematic-Empfänger einen wirklich relevanten Einfluß auf die Batterielebensdauer hat. Es gibt ja inzwischen schon einige Komponenten, die im burst arbeiten und trotzdem sehr lange Batterielebenszeiten haben (sollen)
hi,
zur klärung:
- der burst mode wird NICHT von mir eingeschaltet, das macht der RT (und nicht nur der) intern
- der burst mode soll, wenn er ein ist, von fhem auch genutzt werden.
- aktuell nimmt fhem an, dass der RT burst kann. meiner hat es ( nach einer vorgeschichte). Auch wenn alle peers gelöscht sind
- das einschalten des burst hängt mit sicherheit mit dem peeren zusammen
die nächste version wird erst einmal von no-burst ausgehen. Ihr könnt das hmconfig, version weiter oben in diesem Thread, einbauen und alles sollte klappen!!
das Automatische "erkennen und nutzen" des burst-on kommt später
Gruss Martin
Hi,
Zitat von: martinp876 schrieb am So, 22 September 2013 18:25- das einschalten des burst hängt mit sicherheit mit dem peeren zusammen
Ja, sehe ich auch so. Es geht aber auch manuell. Habe gerade mal das Register burstRx auf on gestellt, danach hat Burst funktioniert :-)
Gruß
Michael
hi Michael,
gut, danke. hatte ich nicht gesehen :-(
ich werde am automatischen Erkennen arbeiten.
Gruss Martin
p.s. version 3944 ist ers einmal zurüch auf "wakeup only" für rt
Hallo,
ich habe versucht die desired-temp mit der letzten Version zu setzen, aber es hat weder mit noch ohne Anlernen funktioniert. Hat es jemand schon mal geschafft, wenn ja was genau hat er gemacht. Die Thermostate sind gepairt und zeigen es auch richtig an.
Gruß
BuRi
ich kann es setzen - kein Problem.
das mit den modi hast du verstanden?
ab Morgen geht erst einmal nur noch wakeup und config.
"conditional"-burst ist verschoben
Hallo,
du bist ja auch noch spät unterwegs.
Daß es drei modi gibt weiß ich, aber muß ich den wakeup modus setzen?
Gruß BuRi
hi buri,
modi musst du keine setzen,kannst du garnicht.
beim rt hatte ich mich verkalkuliert und fälschlich burst zugelassen. das funktioniert nur manchmal.
aktuell (Version heute) ist burst=off. Demnach funktioniert wakeup.
Es ist eben so, dass wenn burst angenommen wird alles sofort gesendet wird. wakeup ist somit irrelevant.
mein ziel ist, devices mit "conditional burst" entsprechend zu unterstützen. u.a der rt kann burst einschalten. ich muss also feststellen, ob es eingeschaltet ist oder nicht.
heute (nach update) kann der rt wakeup und config
Gruss Martin
Super
es hat funktioniert! Aber kann es sein, dass man die Temperatur immer mit Komma eingeben muss?
set desired-temp 12 hat nicht funktioniert, set desired-temp 12,0 geht!
Vielen Dank
BuRi
das mit dem Komma wäre aber extrem schräg, das kann ich mir als Ursache eigentlich kaum vorstellen.
Hallo zusammen,
das mit dem Komma glaube ich auch nicht. Ich habe aber ähnliche Probleme, auch mit der neusten Version ohne Burst: die Kommunikation funktioniert nur unzuverlässig. Manchmal geht's, manchmal nicht. Einigermaßen sicher ist die Kommunikation nur, wenn ich die Anlerntaste
drücke.
Ich hatte noch keine Zeit die Logs genau zu analysieren, oder Ursachenforschung zu betreiben...
Gruß Ralph
Zitat von: rabe schrieb am Mo, 23 September 2013 11:22die Kommunikation funktioniert nur unzuverlässig. Manchmal geht's, manchmal nicht. Einigermaßen sicher ist die Kommunikation nur, wenn ich die Anlerntaste drücke.
Hast Du denn auch lange genug gewartet? Die Änderung nach einem set desired-temp wird ja ohne burst eben nicht sofort übertragen. Das kann schonmal ein paar Minuten dauern und solange bleibt der Befehl als CMD_pending. Mit dem Drücken der Anlerntaste unterbrichst Du quasi nur die Wartezeit bis zum nächsten Datenaustausch zwischen fhem und dem device.
Hallo,
woran es liegt weiß ich nicht, aber jetzt habe ich ein neues Problem, das auch reproduzierbar ist. Ich habe im WZ zwei solcher Thermostate, die nur über fhem gepairt sind. Nun habe ich mir eine Funktion geschrieben die die Temperaturen für die verschiedenen Wochentage setzt. Beim ersten Aufruf wurden in jedem Thermostat nur die ersten 5 Tage (Montag bis Freitag) gesetzt. Beim zweiten Thermostat konnte ich die beiden fehlenden Tage problemlos manuell setzen.
Beim ersten Thermostat gibt es allerdings das folgende Problem: Setze ich Samstag, so wird Sontag auf die Default-Einstellung gesetzt. Setze ich Sonntag wird Samstag auf Default-Einstellung gesetzt. Alle Bemühungen halfen bisher nicht. Außerdem wurde die desired-Temperatur mal zwischendrin auf 12 Grad gesetzt. Irgendetwas funzt da nicht richtig. Hat einer eine Idee?
Gruß
BuRi
Ist denn die tempList softwareseitig in den RT überhaupt schon implementiert?
@martin: Könntest Du mal kurz einen aktuellen Status geben, was bisher schon funktionieren sollte? Sich das hier aus den verschiedenen Threads zusammenzuklauben ist sehr mühsam.
Hallo,
wie geschrieben, es funktioniert bei einem Device und bei dem anderen gibt es diese Merkwürdigkeiten.
Scheinbar ist es also implementiert. Man kann ja im Kanal 4 unter set nachschauen,
was alles geht. Es gibt ja nun auch desired-temp.
Gruß
BuRi
so einmal zusammenfassen
Version 3948 gerade abgegeben. Bitte file 10_CUL_HM UND HMConfig holen. ggf auch 98_HMinfo
- das setzen der Register sollte funktionieren (auch templist)
- das setzen desired-temp funktioniert auch mit 12 (ohne komma). hat schon immer. komma zahlen haben eh einen '.', kein ','
- conditional-burst funktioniert. man kann also das Register burstRX setzen, ab dann reagiert das Device "sofort". Natürlich wird das regSet burstRx noch im alten mode ausgeführt. bis es dann soweit ist kann es die üblichen 3 min dauern
- bei devices die conditional burst unterstützen wird der "burstability-state" in protCondBurst dargestellt
- conditional-burst wirs automatisch erkannt
- supported wird es von rt, tc und verschiedenen wds devices
Die testphase ist noch nicht lang gewesen - ganz zufrieden bin ich selbst noch nicht.
Fragen:
- nutzt einer heating-control? geht dies?
Gruss Martin
Hallo,
vielen Dank, Martin für die neue Version 3948 !
Ich habe diese gerade mal getestet. Die Kommunikation im noBurst mode und im Burst Mode sind viel
stabiler geworden. Im Burst Mode habe ich keine Fehlkommunikationen mehr.
Jedoch ist mir eine Sache aufgefallen:
Ich habe vom Burstmode mit XX regSet burstRx off wieder zurückgeschaltet (was auch wie erwartet
funktioniert hat), jedoch war ich dann nicht mehr in der Lage mit XX regSet burstRx on den Burst
Modus wieder einzuschalten. Ich bekomme dann reproduzierbare Übertragungsfehler und das Attribut wird nicht auf on gesetzt. Habe das mehrfach versucht. Dann habe ich fhem neu gestartet und XX regSet burstRx on hat auf Anhieb funktioniert.
Gruß Ralph
Hallo,
mal ne ganz dumme Frage, wo bekomme ich denn die neuste Version her?
Ich mach Updates normalerweise direkt in Fhem, aber dort liegt die neuste Version noch nicht vor.
Danke schon mal für die Info.
Burchard
Hallo,
die aktuellen Versionen sind auf SourceForge. Siehe
http://sourceforge.net/p/fhem/code/HEAD/tree/ (//sourceforge.net/p/fhem/code/HEAD/tree/)
Im trunk findest Du Martins aktuelle Versionen.
Gruß Ralph
Hallo Ralph,
der Parameter protCondBurst hat einen Fehler. Das Register setzen hat bei mir funktioniert.
protCondBurst ist ein 'empirisch' ermittelter Wert. wird immer beim Senden ermittelt und ist zur Info.
R_burstRx ist der Wert aus dem Device gelesen.
FHEM verknüpft die werte nicht.
Frage: hat das aendern von burstRx versagt oder war protCondBurst falsch?
Gruss Martin
Hallo Martin,
dass protCondBurst zwischen on und off hin und her springt habe ich auch bemerkt.
Irritiert hat mich, dass es auch nach dem Sendestart auf on steht, obwohl der Burstmode (also ich meine
den Wert von burstRx) auf off steht.
Zu Deiner Frage: was ich meine ist dass das Ändern von burstRx versagt hat. Ich habe mehrfach versucht das
Attribut zu setzen, das hat aber nicht geklappt (auch nach erneuten auslesen mit getconfig blieb es off).
Von den 3 cmds die beim Setzen dieses Attributes ausgelöst wurden, ist eines immer fehlgeschlagen.
Ich kann nicht sagen welches, da ich mich noch nicht systematisch durch die Logs gewühlt habe.
Gruß Ralph
Hi noch eine Frage,
gibt es schon eine Chance über den Browser (FhemWeb) die Änderung der desired-temp über das Pull-down Menü vorzunehmen, so wie das
bei HM-CC-TC auch funktioniert. Oder ist das noch Future Work?
Ich habe das mit "attr XX webCmd desired-temp" probiert, aber das Menü zur Temperatureinstellung wird nicht angezeigt.
Gruß Ralph
hallo konnte mir jemand sagen wie ich die Datei installiere bin noch relativ neu in der Sache.
MFG
RedOne
hallo Ralph,
es gibt V 3950.
da sollte protoCondBurst korrekt stehen.
ausserdem hat jedes kommando mit einem Parameter ein pull-down menue (falls es kein frei wählbarer Wert ist)
falls du vom Problem einfach die rohmessages schicken kannst...
ich habe am tc probiert, konnte hin und her schalten. rt muss ich noch...
Gruss Martin
R-decalcTime 660.660660660661 min
sieht lustig aus :)
Vorhin hab ich schonmal die ganzen Register im Device gesehen, auch R-burstRx. Aber ändern konnte ich das mit regSet nicht.
Jetzt sehe ich nichtmal mehr die Register. Irgendwie verweigert der RT grade die Kommunikation - obwohl gepairt und kein Missing Ack.
Hallo zusammen
hier auch noch eine kurze frage von mir
was bedeutet das genau und was kann (muss) ich dagegen tun.
Im ersten Moment schaut es so aus als würde alles funktionieren.
configCheck done:
incomplete register set
CUL_HM_HM_CC_RT_DN_21B9FE_ClimRT_tr:.RegL_07:
CUL_HM_HM_CC_RT_DN_235EA6_ClimRT_tr:.RegL_01:
CUL_HM_HM_CC_RT_DN_235EA6_ClimaTeam:.RegL_01:
CUL_HM_HM_CC_RT_DN_235EA6_Climate:.RegL_01:
CUL_HM_HM_CC_RT_DN_235EA6_Weather:.RegL_01:
CUL_HM_HM_CC_RT_DN_235EA6_remote:.RegL_01:
empty list
empty: CUL_HM_HM_CC_RT_DN_21B9FE_ClimRT_tr
empty: CUL_HM_HM_CC_RT_DN_235EA6_ClimRT_tr
empty: CUL_HM_HM_CC_RT_DN_235EA6_ClimaTeam
empty: CUL_HM_HM_CC_RT_DN_235EA6_Climate
empty: CUL_HM_HM_CC_RT_DN_235EA6_Weather
empty: CUL_HM_HM_CC_RT_DN_235EA6_WindowRec
empty: CUL_HM_HM_CC_RT_DN_235EA6_remote
lg
Stefan
manchmal funktioniert sogar schon das Setzen der desired-temp. Aber nur manchmal.
Schluß für heute - genug geärgert. Gute Nacht.
hi stefan,
hminfo prüft, ob die register i.O. erscheinen. Es werden ein paar generelle Dinge geprüft.
zum einen hast du durch alte Versionen noch register-fragmente die müll sind - und zum anderen ist nich eine unstimmigkeit drin die ich beheben muss. hängt mit "expert" zusammen.
bei solchen Fehlern sollte man
a) das device clearen : clear readings
b) neu lesen: getConfig
Ein Fehler wird wohl (vorläufig) bleiben
@Udo - das ist eben genauigkeit ;-)
Zitat von: martinp876 schrieb am Mo, 23 September 2013 22:33@Udo - das ist eben genauigkeit ;-)
wahrscheinlich bin ich zu müde, um das zu verstehen...
Zitatwahrscheinlich bin ich zu müde, um das zu verstehen...
deine bemerkung
R-decalcTime 660.660660660661 min
achso... N8
final update today:
V 3952
register setzen korriert (hoffentlich funktionieren jetzt alle)
leere register-reading-bug behoben
Gruss Martin
Hallo Martin,
vielen Dank für Deinen Einsatz bis spät in die Nacht. Ein kleines Problem habe ich noch gefunden,
man kann die desired-temp Temperatur nicht aus dem drop-down Menü auswählen, die box ist scheinbar zu klein.
Ungelöschte Register könnten Schuld sein an meinen komischen Effekten mit der tempList sein..
Habe die Zeiten und Temperaturen nun am Thermostat gesetzt. und damit erstmal einen work-arround gefunden. Nun geht es an die Steuerung.
Gruß
Burchard
hi burchard,
das drop-down geht bei mir. könnte auch am browser liegen. Die fensterbretie lege ich nicht fest... lass hören wenn es nach neustarts nicht besser wird.
das setzen der register und auch der temp-listen funktioniert mit dem letzten update - zumindest bei mir.
Probleme macht das senden von mehreren kommandos en-block. das muss ich noch reparieren.
nachdem wir jetzt 2 modi haben ist immer wichtig zu erwähnen, ob man burst oder wakeup fährt.
Gruss Martin
Hallo Martin,
bei mir geht es immer noch nicht. Angehängt habe ich einen Screenshot. Ich benutze den neusten IE.
Im Hinblick auf die Einbindung eines Innentemperatursensors und eines Türkontaktes hätte ich noch die Frage, wie ich die beiden Thermostate und die oben erwähnten Sender verknüpfe? Mach ich dass über fhem oder werden die Devices an einem Thermostat angelernt?
Gruß
Burchard
Hast Du mal den Browser-Cache komplett gelöscht?
Das Dropdown geht bei mir auch (immerhin mal etwas, das wirklich funktioniert *g*...)
...
Hallo Martin,
geht immer noch nicht.
Burchard
Nachtrag:
habe es auch mit dem Firefox probiert, geht auch nicht.
Burchard
hm .. hast du einmal einen update force probiert?
sieht aus wie ein slider
Stelle sicher, dass HMConfig auf dem letzten Stand ist
p.s. probiere einmal
set <rt_clima> ?
da sollte eine liste kommen wie:
Unknown argument r, choose one of clear:readings,msgEvents desired-temp:on,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,1
8.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 getConfig getRegRaw mode peerBulk regBulk regSet sign:on,off tempListFri tem
pListMon tempListSat tempListSun tempListThu tempListTue tempListWed
Super,
jetzt geht es, lag wahrscheinlich an der nicht aktuellen HMInfo.
Danke
Burchard
klar.
ich habe das Verfahren "automatisiert" (im code...). die drop-down info wird direkt aus der Komandobeschreibug generiert. und die ist in HMConfig - da werden die Kommandos definiert.
habe gerade einen update eingestellt (CUL-HM und HMConfig). ggf auch HMInfo mitnehmen ;-)
clear hat jetzt [readings|register|rssi|msgEvents]
also selektiver.
ausserdem sollte das setzen von Registern besser gehen - besonders wenn man mehrere kommandos ansetzen will.
Der RT zickt noch etwas, da er offensichtlich beim schreiben etwas langsam ist. danach geht ein kommando schief. Ich denke das gibt Probleme im wakeup mode. Im burst mode wird es einfach wiederholt.
Mal sehen, ob ich es noch hin bekomme. Einfach warten ist - besonders für wakeup - keine Option. Ausgemessen habe ich es auch noch nicht. Zu befürchten ist eh, das die auszeit schwankt - das ist üblich bei flashes/eproms - und wenn es HMrichtig gemacht hat...
Verständnissprobleme habe ich bei den peerings.
- RT nach RT: manchmal werden die werde kopiert, manchmal nicht
- fenster Auto open: funktioniert, aber eine message habe ich nicht erkannt.
- fenster - peer-open: untested
- peeren mit externem Temp-sensor - habe keinen, untestet.
Version 3953 steht bereit
Noch einmal ein Aufruf: nutzt jemand heating_control? Gibt es probleme? Wünsche?
Gruss Martin
Zitat von: martinp876 schrieb am Di, 24 September 2013 11:14- peeren mit externem Temp-sensor - habe keinen, untestet.
Vielleicht mal mit dem Weather-Channel vom TC probieren?
Mein Homematic-Tempsensor läuft inzwischen in Serbien, das ist etwas weit weg *g*
---
könnt ihr mir sagen wie ich die 3 Dateien updaten kann bei mir kommt immer
Wenn ich
Update thirdparty http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm (//sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm)
Eingebe
(Remote) is corrupt
Vielen dank Gruß
Redone
sieht aus wie ein Problem bei SVN.
Soll ich es nochmal löschen und neu installieren ?
nein, ein Problem IN SVN.
geht jetzt wieder
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw (//sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw)
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/98_HMinfo.pm?format=raw (//sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/98_HMinfo.pm?format=raw)
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/HMConfig.pm?format=raw (//sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/HMConfig.pm?format=raw)
Geht bei mir immer noch nicht.
Kann ich die Dateien auch manuell reinladen.
Wenn ich sie downloade und reinkopiere
Und dann ein shutdown restart mache
Oder würde das nicht funktionieren
Gruß RedOne
klar, so ist es gedacht. Was hattest du vor?
Ich dachte mit dem update thirdparty passiert das automatisch.
Dann habe ich das wohl nicht richtig verstanden
SVN Updates macht man nicht aus FHEM heraus, sondern auf der Systemkonsole des Rechners, auf dem fhem und der svn-Client läuft.
Hallo Zusammen,
ich habe seit heute zwei HM-CC-RT-DN. Die heizen den gleichen Raum. Daher würde ich sie gerne koppeln (peeren). Jetzt mal die blöde Frage wie geht das? Dazu kann ich irgendwie nix finden.
Muss ich zuerst den einen HM-CC-RT-DN an fhem pairen und dann den zweiten (wie in der Beschreibung steht) an diesen HM-CC-RT-DN peeren. Ist der zweite im Anschluss dann noch an Fhem zu pairen?
Danke und Grüße
Christoph
hi Christoph,
das sollte so schon mal nicht funktionieren.
wenn sich ein device der Kontrolle einer Zentrale unterwirft kann es nicht mehr selbst peeren. Ab dann macht es die Zentrale.
Und wenn es noch nicht gepairt ist darf die Zentrale nicht peeren
Also entweder erst peeren und dann beide pairen
oder:
- jedes device mit fhem pairen
- devices über fhem peeren
wichtig ist, den richtigen channel zu nehmen. das legt die funktion fest
-- rt nach rt: climaTeam channel
set <rt1-ClimaTeam> peerChan 0 <rt2-ClimaTeam> single
-- rt nach Fernbedienung: remote channel
set <button> peerChan 0 <rt-remote> single
-- rt nach fensterkontakt: WindowRec channel
set <fenster-sensor> peerChan 0 <rt-WindowRec > single
-- rt nach wettersensor: noch nicht getestet channel
set <thermoSensor> peerChan 0 <rt-????> single
das übertragen der steuerinfo funktioniert bei mir noch nicht komplett - bin am forschen. Das peeren sollet i.o. sein
Gruß Martin
Hallo Martin,
vielen Dank für die Hilfe!
Ich habe es mit
set xxxx_ClimaTeam peerChan 0 yyyy_ClimaTeam single
probiert. Allerdings erkenne ich keinen Effekt. Fehlermeldungen erhalte ich auch keine; der Befehl geht durch.
Viele Grüße
Christoph
Hallo Christoph,
also nach einem getConfig kannst du die Peers im cilmaTeam sehen. Es sollte der gegen-RT channel Clima sein - ist also nicht symetrisch.
Aber Probleme habe ich auch noch damit. es funktioniert bei mit nur teilweise - meist nur in eine Richtung.
Wenn es funktioniert dann kann man z.B. den mode umschalten und der 'partner' schaltet quasi sofort mit.
Burst hast du sicher eingeschaltet?
mehr habe ich im Moment noch nicht.
Funktionieren sollte die stand-alone variante.
erst ein unpair bei beiden RTs, dann bei beiden anlernen, sie peeren sich und letztlich beide wieder pairen mit FHEM.
Gruss Martin
Okay, das Peeren hat wohl geklappt. Die Devices erscheinen wechselseitig.
Burst habe ich nicht eingeschaltet. Wie führe ich das denn durch? Sorry, bin bei dieser Geräteklasse noch Newbie ;-)
1000 Dank schon mal !!!
ich bin jetzt im ordner opt/fhem/FHEM
der befehl zum kopieren
wget http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw (//sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw)
muss ich mit dem ?format=raw oder ohne den Befehl ausführen
und die bisherige 10_CUL_HM.pm
dann via rm löschen oder beiberhalten?
Gruß RedOne
Der Befehl funktioniert so überhaupt nicht. Du musst das hier machen:
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw -O 10_CUL_HM.pm
Und löschen brauchst Du gar nix, weil wget die vorhandene Datei überschreibt.
Hey - Du solltest Dir dringend ein paar lebenswichtige Linuxgrundlagen aneignen!
@betateilchen
da muss ich dir recht geben
jetzt habe ich aber 2 Dateien
10_CUL_HM.pm
und
10_CUL_HM.pm.1
ist also nicht schlimm
doch.
Beide löschen und nochmal machen.
alles klar Dankeschön vielmals das hat gepasst
jetzt des einzige und letzte
meine devices sind jetzt nicht mehr erkannt wenn ich jetzt wieder die anlern taste drücke
und den HMLAN auf 60 sekunden stelle findet er nix
muss man jetzt noch was zusätzlich machen ?
Hallo!
Bin seit heute auch im Besitz von HM-CC-RT-DN, habe ihn angelernt und habe bis jetzt keine Sorgen.
Desired-Temp wird angenommen, Temp und andere Werte werden an Fhem übergeben.
Eine frage hätte ich aber noch, denn würde gerne wissen ob die Ist-Temp auch direkt am HM-CC-RT-DN angezeigt werden kann? Habe irgendwie noch nichts dazu gefunden.
Danke für die tolle Arbeit damit das hier möglich wurde...
Mfg Steffen
2013.09.24 21:32:13 1: reload: Error:Modul 10_CUL_HM deactivated:
Glob not terminated at FHEM/HMConfig.pm line 20.
Compilation failed in require at ./FHEM/10_CUL_HM.pm line 12.
BEGIN failed--compilation aborted at ./FHEM/10_CUL_HM.pm line 12.
2013.09.24 21:32:13 0: Glob not terminated at FHEM/HMConfig.pm line 20.
Compilation failed in require at ./FHEM/10_CUL_HM.pm line 12.
BEGIN failed--compilation aborted at ./FHEM/10_CUL_HM.pm line 12.
2013.09.24 21:32:13 0: ERROR: Cannot autoload CUL_HM
2013.09.24 21:32:13 3: HMLAN1: Unknown code A0F8F86102286870000000AA8E6900025::-64:HMLAN1, help me!
das steht im logfile ich glaube ich warte aufs offizielle update
Anzeige der ist-temp am device hätte mich auch interessiert, habe aber noch nichts gefunden.
Sieht nicht so aus...
so... alles nochmal neu eingerichtet, scheint soweit zu funktionieren, nur die tempList streikt noch etwas.
Wird es ein set <> systime geben?
Hallo Martin,
ich habe gerade nochmal die neue Version aus dem SVN eingespielt - nun funktioniert auch bei
mir das Pulldown Menü bei desired-temp. Wunderbar - Danke!
In 10_CUL_HM.pm ist noch ein Typo:
Misplaced _ in number at ./FHEM/10_CUL_HM.pm line 2988
Gruß Ralph
Und ich habe gerade den zweiten RT in Betrieb genommen, diesmal im Arbeitszimmer, wo es zwei Fenster mit entsprechenden Fenstermeldern gibt (einmal den SC und einmal den RHS) und das Peeren beider Sensoren mit dem WindowRec hat prima funktioniert.
Tolle Arbeit!
Das wollte ich auch nochmal loswerden: Danke für die Mühe !
Funktioniert bei mir auch alles bestens!
Ich habe auch 2 dieser Regler.
Nur bekomme ich bei keinem der Geräte eine Temperatur übermittelt.
Was muss da gemacht werden, damit diese angezeigt werden bzw übermittelt werden
Danke für die
Info
Auch von mir ein herzliches Danke für die tolle und schnelle Arbeit !!
Die Probleme die ich jetzt noch habe, liegen wohl an meiner eigenen Schlusselligkeit: kein Burst-Modus und Peering klappt noch nicht; was sich wohl gegenseitig bedingt.
Der Regler muss fhem bekannt sein. Im Normalfall reicht also das pairen von Regler mit fhem. Die Werteübertragung erfolgt völlig autark vom Regler aus, dazu ist keine weitere Einstellung notwendig.
Das finde ich äusserst komisch.
Regler ist gepaired aber nichts da.
Was kann ich versuchen?
fg
betateilchen hat recht, wenn der Regler gepairt ist sollten die Werte automatich alle ~2-3min die werte übertragen. Kann man danngarnicht verhindern.
bist du sicher, das gepairt ist? Funktioniert getConfig?
hi,
ich habe Probleme mit dem "teaming", also die heizkörper gleichschalten. Es funktioniert nur in eine Richtung. Empfangen können beide. Aber die Aenderung sendet immer nur einer. Am peering sollte es nicht liegen, ich habe auch das HM-autonome peering probiert.
Hat jemand Erfahrungen? klappt es bei jemandem?
hat jemand schon einen Wetter-sensor gepeert? einen temp-sensor muss man mit Channel01 peeren. Hat jemand rohmessage eines temp-sensors? bitte posten.
Gruss Martin
Hallo Martin,
Du hattest nach Ideen und Wünschen gefragt...
Könnte man dem ClimaRT_tr Channel ein Attribut mit einem Korrekturfaktor verpassen? Bei mir wird die gemessene Temperatur durch die Nähe zum Heizkörper um ca. 2° zu hoch ausgegeben. Also der Regler meldet 21°, in Wirklichkeit sind im Raum aber nur 19,2° (also in dem Bereich, in dem man sitzt und sich wohlfühlen möchte)
Viele Grüße
Udo
edit: das mit dem Temperatursensor kann ich vielleicht noch im Laufe dieser Woche testen. Einen Raum mit zwei Heizkörpern hab ich leider nicht :)
Was mir beim WDS10THO aufgefallen war: der gepairte Sensor sendet seine Wettermeldungen immer an broadcast.
hi Udo,
einen temperaturOffset hat der RT doch eingebaut.
Zum ersten halte ich es für seltsam, wenn am RT display etwas anderes steht als in FHEM...
aber (nicht getestet!) hat der Clima-channel ein "R-tempOffset". hier lässt sich doch genau so etwas einstellen - steht auch in der Anleitung.
Ist es das was du brauchst?
was mir aufgefallen ist, dass das Ventil geöffnet wurde weit bevor die istTemp unter die Solltemp gefallen ist. Aber das muss ich noch beobachten. Beim RT kann man ja auch noch die Regelung beeinflussen...
das mit dem wds10tho waere interessant. Es ist ein aussensensor? waere wohl egal.
Interessant ist dann natürlich dessen config (pairing/peering).
man sollte ihn mit dem Channel1 des RT peeren können. Danach wäre interessant, was der RT an messages liefert. Evtl sieht man garnichts...
Gruss Martin
Zitat von: martinp876 schrieb am Mi, 25 September 2013 10:50einen temperaturOffset hat der RT doch eingebaut.
...
aber (nicht getestet!) hat der Clima-channel ein "R-tempOffset". hier lässt sich doch genau so etwas einstellen - steht auch in der Anleitung.
dann muss ich mir das nochmal anschauen.
Zitat von: martinp876 schrieb am Mi, 25 September 2013 10:50das mit dem wds10tho waere interessant. Es ist ein aussensensor?
Ja, Aussensensor, aber ich denke auch dass das egal ist.
Hallo Martin
einer meiner beiden Regler bringt nun Missing Ack aber es werden Werte an FHEM Übertragen aber zum Regler nicht. Kann ich da was von der Ferne machen ohne an den Regler zu gehen ?
lg
Stefan
Ich habe den RT über temperaturOffset am Gerät zu einer in der Raummitte gemessenen Temperatur "geeicht". Das funktioniert so einigermaßen. Wenn der Heizkörper bei großer Ventilstellung stark aufheizt ist die Abweichung allerdings relativ groß.
Dass der RT über die eingestellte Soll-Temperatur regelt kann ich auch beobachten (siehe Screenshot). Da ich die Geräte erst seit gestern im Gebrauch habe, muss ich das aber noch etwas beobachten und mit den Parametern rumspielen.
(siehe Anhang / see attachement)
Ich könnte mir theoretisch schon vorstellen, dass der RT eine gewisse "Lernphase" braucht, um das Aufheizverhalten des Raumes, in dem er sich befindet, zu verinnerlichen.
@Stefan,
wenn nur ein Regler nicht antwortet liegt der Verdacht nahe, dass er nicht gepairt ist, warum auch immer.Das ginge dann nur vor Ort, neu Anlernen.
man kann einigen an der Regelung spielen
regAdaptive :on
reguExtI :15
reguExtP :30
reguExtPstart :30
reguIntI :15
reguIntP :30
reguIntPstart :30
leider nicht genauer beschrieben, sit wohl ein PI oder PID regler. Adaptiv bedeuted wohl, dass es eine Lernphase gibt. ..
Das würde ja voraussetzen, dass der RT eine gewisse "künstliche Intelligenz" eingebaut hat. Das würde ich allerdings stark bezweifeln. Vom Hersteller gibt es dazu auch keine Hinweise. So etwas würde doch sicherlich offensiv beworben.
Oder hat hier jemand weitere Informationen?
Zitat von: CQuadrat schrieb am Mi, 25 September 2013 11:48Das würde ja voraussetzen, dass der RT eine gewisse "künstliche Intelligenz" eingebaut hat
Nein, das muss man nicht extra bewerben. Eigentlich erwartet man sowas von einer sinnvoll umgesetzen Heizungsregelung.
Und eine gewisse Lernphase gab es auch schon beim alten Wandregler.
Schau Dir doch die Sinuswelle bei der Temperatur an, das ist für mich eine ziemlich eindeutige PID-Lernkurve.
Hallo Martin
reicht es wenn ich nochmal drüber paire oder soll ich lieber alle Einträge des Reglers aus der Konfiguration werfen.
lg
Stefan
'drüber-pairen' sollte reichen. Pairen zerstört nicht die vorhandenen Inhalte.
das mit dem drüber-pairen funktioniert manchmal nur bedingt - das ist jedenfalls meine Erfahrung der letzten Tage. Ich habe mir angewöhnt, den Regler im Problemfall komplett zu löschen und neu zu pairen. Kann aber auch mit dem häufigen Versionswechsel der Moduldateien in den letzten Tagen zusammenhängen.
Hallo Martin und andere
ich bekomme das MISSING ACK des einen Reglers einfach nicht weg.
Er scheint zwar ein wenig zu kommunizieren aber nicht richtig.
Hat jemand noch einen Tipp für mich.
Gepeart habe ich glaube ich jetzt schon 10 mal.
ich habe ihn auch mit der Windowssoftware aus dem HomeLankanfigurator geworfen.
lg
Stefan
CUL_HM_HM_CC_RT_DN_235EA6
Internals
CFGFN
DEF
235EA6
EVENTS
3
HML_MSGCNT
57
HML_RAWMSG
E235EA6,0000,009E4BC3,FF,FFBB,438610235EA60000000AA0C6101718
HML_RSSI
-69
HML_TIME
2013-09-25 21:24:59
IODev
HML
LASTInputDev
HML
MSGCNT
57
NAME
CUL_HM_HM_CC_RT_DN_235EA6
NR
584
STATE
MISSING ACK
TYPE
CUL_HM
channel_01
CUL_HM_HM_CC_RT_DN_235EA6_Weather
channel_02
CUL_HM_HM_CC_RT_DN_235EA6_Climate
channel_03
CUL_HM_HM_CC_RT_DN_235EA6_WindowRec
channel_04
CUL_HM_HM_CC_RT_DN_235EA6_ClimRT_tr
channel_05
CUL_HM_HM_CC_RT_DN_235EA6_ClimaTeam
channel_06
CUL_HM_HM_CC_RT_DN_235EA6_remote
lastMsg
No:43 - t:10 s:235EA6 d:000000 0AA0C6101718
protCmdDel
0
protLastRcv
2013-09-25 21:24:59
protResnd
3 last_at:2013-09-25 18:59:59
protResndFail
1 last_at:2013-09-25 19:00:02
protSnd
3 last_at:2013-09-25 18:59:48
protState
CMDs_done_events:4
rssi_at_HML
avg:-64.75 min:-78 max:-62 lst:-69 cnt:57
Readings
Activity
alive
2013-09-25 18:59:58
CommandAccepted
yes
2013-09-25 18:59:48
R-intKeyVisib
set_invisib
2013-09-25 18:59:47
R-pairCentral
set_0x1EA224
2013-09-25 18:59:47
battery
ok
2013-09-25 21:24:59
batteryLevel
3.1 V
2013-09-25 21:24:59
state
MISSING ACK
2013-09-25 19:00:02
actCycle
000:10
actStatus
alive
expert
2_full
firmware
1.0
group
Heizung
model
HM-CC-RT-DN
peerIDs
room
Haus
serialNr
KEQ0576658
subType
thermostat
CUL_HM_HM_CC_RT_DN_235EA6_ClimRT_tr
Readings
R-boostAftWinOpen
off
2013-09-25 21:33:58
R-boostPeriod
5
2013-09-25 21:33:58
R-boostPos
80 %
2013-09-25 21:33:58
R-btnNoBckLight
off
2013-09-25 21:33:58
R-daylightSaveTime
on
2013-09-25 21:33:58
R-decalcTime
660.660660660661 min
2013-09-25 21:33:58
R-decalcWeekday
Sat
2013-09-25 21:33:58
R-modePrioManu
all
2013-09-25 21:33:58
R-modePrioParty
all
2013-09-25 21:33:58
R-noMinMax4Manu
off
2013-09-25 2133:58
R-regAdaptive
on
2013-09-25 21:33:58
R-reguExtI
15
2013-09-25 21:33:58
R-reguExtP
30
2013-09-25 21:33:58
R-reguExtPstart
30
2013-09-25 21:33:58
R-reguIntI
15
2013-09-25 21:33:58
R-reguIntP
30
2013-09-25 21:33:58
R-reguIntPstart
30
2013-09-25 21:33:58
R-showInfo
time
2013-09-25 21:33:58
R-showWeekday
off
2013-09-25 21:33:58
R-tempComfort
21
2013-09-25 21:33:58
R-tempFallWinOpen
12
2013-09-25 21:33:58
R-tempFallWinPerio
15 min
2013-09-25 21:33:58
R-tempLowering
17
2013-09-25 21:33:58
R-tempMax
30.5
2013-09-25 21:33:58
R-tempMin
4.5
2013-09-25 21:33:58
R-tempOffset
0.0K
2013-09-25 21:33:58
R-valveErrPos
15 %
2013-09-25 21:33:58
R-valveMaxPos
100 %
2013-09-25 21:33:58
R-valveOffset
0 %
2013-09-25 21:33:58
RegL_07:
01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
2013-09-25 21:33:58
ValvePosition
23 %
2013-09-25 21:34:52
desired-temp
20.5
2013-09-25 21:34:52
measured-temp
19.8
2013-09-25 21:34:52
mode
auto
2013-09-25 21:34:52
motorErr
ok
2013-09-25 21:34:52
state
set_desired-temp 20.5
2013-09-25 21:33:34
tempListFri
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-09-25 21:33:58
tempListMon
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-09-25 21:33:58
tempListSat
06:00 17.0 22:00 21.0 24:00 17.0
2013-09-25 21:33:58
tempListSun
06:00 17.0 22:00 21.0 24:00 17.0
2013-09-25 21:33:58
tempListThu
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-09-25 21:33:58
tempListTue
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-09-25 21:33:58
tempListWed
06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-09-25 21:33:58
tempList_State
verified
2013-09-25 21:33:58
kannst du einmal einenmitschnitt der Messages schicken?
das pairen hat funktioniert?
immerhin wurden die Register des channel 04 korrekt gelesen, also geht etwas, eben nur nicht alles. Aber was...
die rohmessages bitte
Hallo Martin
Welche Aktionen soll ich aufzeichnen ?
Noch ne doofe Frage, wie werden die Rohmessages aufgezeichnet hab ich noch nicht gemacht ?
lg
Stefan
Hallo Stefan,
probiere erst einmal version 3960.
ich habe ein Problem bemerkt bei mehreren "conditional-burst devices" (also 2 mal rt...) wenn man nacheinander abfragt. Dann antwortet immer der erste weiter dinge, die an den 2. addressiert sind. im detail ist das Problem beim hochfahren aufgetreten, wenn autoregread aktiv war. Einzelnes Lesen hat funktioniert.
Da die beim booten liste deterministisch ist hat es quasi immer den gleichen getroffen.
falls es das nicht war bitte
attr global verbose 1
attr global mseclog 1
attr hmlan loglevel 1
und dann eine Aktion mit fehlern
Gruss Martin
Hallo Martin
hat leider nichts geändert.
anbei ein Logauszug von pairen und einigen Kommandos.
Reicht das oder brauchst Du mehr.
lg
Stefan
Hallo Martin
konntest Du schon was finden ?
Ich bekomme diese Woche noch drei neu HM Regler und 3 HM Fenstersensoren, da werde ich es mit einem neuen Regler nochmal Versuchen.
LG
Stefan
Hallo Stefan,
dein device ist gepairt.
dennoch sehe ich, dass du anlernen (config) drückst und FHEM zu pairen versucht.
das geht schief.
das lesen danach ist fehlerfrei.
welches Kommando setzt du ab?
hast du einmal andere Register geschrieben oder geht das Schreiben nie?
Funktioniert Burst nicht? Ist beim Lesen eingeschaltet... warum nicht beim ersten Kommando?
Gruss Martin
Hallo Martin
ich habe einige male darüber gepairt, desired-temp habe ich geschickt und das wird auch ausgeführt aber der Status MISSING ACK kommt.
Ich hatte Probleme beim setzen des burstRx on, irgendwann war er dann aber on.
Wie kann man den Burst prüfen ?
LG
Stefan
Hi Stefan,
FHEM probiert, ob burst an ist. Auf das Lesen der Register verlasse ich mich nicht - zu komplex.
der Wert "protCondBurst" zeigt an, wie das Device auf den letzten Sendeversuch reagiert hat.
da es zum protokol zählt beginnt der Name mit prot.
Diesen Wert gibt es nur bei devices, die es auch unterstützen.
wieder einmal ein hinweis auf die Tabellenauswertung von HMInfo:
set hm param -d protCondBurst R-burstRx
gibt eine schnelle Übersicht
Gruss Martin
Hallo Martin
set hm param -d protCondBurst R-burstRx
zeigt folgendes :
param done:
param list
entity : protCondBurst |R-burstRx |
CUL_HM_HM_CC_RT_DN_21B9FE : on |on
CUL_HM_HM_CC_RT_DN_235EA6 : on |on
lg
Stefan
Hi Stefan,
du hast also 2 RTs, beide haben das Register gesetzt und bei beiden wurde die letzte Übertragung im burst-mode durchgeführt.
aller prima so weit.
Gruss Martin
Hallo Martin
und bei einem kommt
CUL_HM_HM_CC_RT_DN_235EA6
MISSING ACK
Hast Du noch eine Idee was ich tun kann außer auf die neuen zu warten.
lg
Stefan
Hallo Martin
kann es sein das es ein Grundsätzliches Problem mit dem State Parameter gibt.
Bei dem funktionierenden Regler habe ich schon länger keinen neuen Status bekommen.
state
CMDs_done_events:5
2013-09-25 06:40:46
Beim anderen
state
MISSING ACK
2013-09-25 23:40:40
lg
Stefan
hi Stefan,
der protState (in 'reinen Devices ist es auch der 'state') wird immer geaendert wenn FHEM etwas sendet. Also aktiv von FHEM getrieben. hier auch wieder ein Hinweis auf die zugehörigen anderen prot parameter.
probiere einmal HMInfo (mein überblicks-instrument)
set hm protoEvents
ist ein auszug der wichtigsten protocol-parameter aller devices.
du kannst diese auch rücksetzen - wenn du 'neu' anfangen willst:
set hm clear Protocol
jetzt aber zum Missing-Ack: das Beispiel,das du gesendet hast hatte etwas mit Anlernen drücken zu tun.
a) welches Kommando hast du gesendet?
b) warum anlernen drücken?
c) kannst du einmal ein getConfig aufnehmen?
d) kannst du einmal ein set <dev> regSet burstRx on aufnehmen (als beispiel)
also evtl
set hm clear Protocol
set <dev> getConfig
set <dev> regSet burstRx on
set hm protoEvents # wiederholen bis commands "done" sind.
set hm rssi
Ergebnisse schicken
Gruss Martin
Hallo Martin
a) weis ich nicht mehr genau
b) um ein definiertes Event zu haben.
c) mach ich gleich
d) mach ich auch gleich
Ich hab jetzt einen dritten Regler dran und der bringt auch MISSING ACK und lässt den burstRx nicht auf on setzen
Infos kommen in den nächsten zwei Stunden.
lg
Stefan
Hallo Martin
hier sind die Logs des getConfig der drei Regler
bei zwei steht nun RESPONSE TIMEOUT:PeerList
bei dem neuen MISSING ACK
Den Rest mache ich später
protoEvents done:
name :protState |protCmdPend |protSnd |protLastRcv |protResnd |protResndFail |protNack |protIOerr
CUL_HM_HM_CC_RT_DN_21B9FE: CMDs_done_events:16 |- |64:09-26 18:45:46 |09-26 18:45:45|14:09-26 18:45:54 |2:09-26 18:45:58 |- |-
CUL_HM_HM_CC_RT_DN_21CEA2: CMDs_done_events:2 |- |118:09-26 18:46:04|09-26 18:47:35|2:09-26 18:37:40 |- |- |-
CUL_HM_HM_CC_RT_DN_235EA6: CMDs_done_events:8 |- |16:09-26 18:34:29 |09-26 18:46:18|7:09-26 18:34:29 |1:09-26 18:34:33 |- |-
CUL_HM_HM_LC_SW4_WM_20F44F: Info_Cleared |- |- |- |- |- |- |-
CUL_HM_HM_SEC_RHS_1F194F: Info_Cleared |- |- |09-26 18:01:44|- |- |- |-
CUL_HM_HM_SEC_SC_21968B: CMDs_done |- |1:09-26 18:42:53 |09-26 18:42:53|- |- |- |-
CUL_HM_HM_SEC_SC_219EE8: Info_Cleared |- |- |09-26 17:26:57|- |- |- |-
CUL_HM_HM_SEC_SC_219F72: Info_Cleared |- |- |09-26 17:33:10|- |- |- |-
CUL_HM_HM_SEC_WDS_1E4D95: Info_Cleared |- |- |09-26 16:56:58|- |- |- |-
CUL_HM_HM_Sen_Wa_Od_1F06B1: CMDs_done |- |1:09-26 18:38:44 |09-26 18:39:00|- |- |- |-
CUL_HM queue:0
status request pending:
IODevs:HML:opened pending=0
lg
Stefan
Hallo Martin
in diesem Logfile sind die
set <dev> regSet burstRx on
für alle drei Regler drin
lg
Stefan
Hallo Stefan,
alle 3 deiner devices haben burst angeschaltet.
die meiste Kommunikation klappt auch.
Ein Problem (hatte es befürchtet) muss ich noch in angrif nehmen: wenn es ein Problem gibt und man wiederholen muss, muss man das Device wieder aufwecken.
Wenn du erst einmal ein device nach dem anderen Anfragst sollte es relativ stabil laufen.
alle 3 devices antworten und schienen zu funktionieren, soweit die gute nachricht.
wenn du (vorläufig) eins nach dem anderen machst sollte es klappen, immer warten bis "fertig". Am verbesserten re-transmitt muss ich arbeiten, sind ein paar detail zu bedenken.
Gruss Martin
Hallo Martin
kann man eigentlich einzelne Pendings löschen ?
CUL_HM_HM_SEC_SC_21968B: pending |3 pending |- |- |- |- |- |-
CUL_HM_HM_SEC_SC_219EE8: pending |3 pending |- |- |- |- |- |-
CUL_HM_HM_SEC_SC_219F72: pending |3 pending |- |- |- |- |- |-
CUL_HM_HM_SEC_WDS_1E4D95: pending |3 pending |- |- |- |-
Das pending steht nun schon einige Stunden bei diesen drei Geräten an
Hängt das mit dem re-transmit zusammen ?
Wie ist eigentlich der Zusammenhang zwischen State und protState, sollten die nicht gleich sein ?
STATE
MISSING ACK
protLastRcv
2013-09-27 12:51:16
protResnd
6 last_at:2013-09-27 11:33:14
protResndFail
1 last_at:2013-09-27 11:33:16
protSnd
9 last_at:2013-09-27 11:33:09
protState
CMDs_done_events:7
LG
Stefan
Zitat von: Stefan M. schrieb am Fr, 27 September 2013 12:56Das pending steht nun schon einige Stunden bei diesen drei Geräten an
Das pending wird so lange dort stehen bleiben, bis Du an den Geräten die Konfigurationstaste kurz betätigst, damit die anstehenden (pending) Daten endlich übertragen werden können.
Hallo!
Mir ist aufgefallen, das von den zwei HM-CC-RT-Dn die ich habe beide nicht in HCS erkannt werden?!
Meine HM-CC-TC schon, kann man das ändern?
Mfg Steffen
man kann das Protokoll aufräumen - mit
set <dev> clear msgEvents
wird auch der kommand-stack gelöscht. Quasi die ganze Kommunikation für dieses Device geht auf start.
Der SC meldet sich, glaube ich einmal am Tag (also wacht einmal am Tag auf). Zu diesen Zeitpunkt sollten dann die messages übertragen werden.
Evtl. muss man erst cyclic-info-message einschalten. Schaue einmal, ob du ein register findet. Ansonsten bleibt es braf stehen, bis Anlernen kommt.
HCS habe ich mir noch nicht angesehen. Aber ziel muss natürlich sein, sich hier anzubinden.
Ich habe noch nicht damit angefangen. Könnte sein, dass sich dann noch einige Parameter aendern müssen...
Gruss Martin
Guten Morgen!
Mir ist noch was aufgefallen was ich aber nicht so positiv finde,
denn bei einer disired-temp von 21 und einer temp 23.3 ist valve immer noch bei 31% was sollte daran intelligent sein;-).
Könnte man das noch ändern??
Mfg Steffen
Hallo Steffen,
FHEM wird daran nichts aendern. das ist Sache der Regelung. Ist mir aber auch schon aufgefallen - und ich habe keine Ahnung, warum dies so ist. Spekulieren kann man, dass HM die temperatur am heizkörper 2Grad höher einschätzt.
Was du machen kannst, über die Register ist
- einen temperatur-offset einstellen, d.h. den punkt um 2 Grad verschieben
- die Regelparameter anpassen (p und i wert des PID reglers)
ersteres ist einfach.
zweiteres ist interessant. hier kann man das Thermostat an seinen Raum anpassen. für einen Offset ist wohl eher der p-wert zu aendern.
An erfahrungen bin ich interessiert. Wie hier der "dynamische mode" reinspielt -keien Ahnung.
Gruss Martin
Hallo Martin,
danke für die Umsetzung :-)
Zitat von: martinp876 schrieb am Di, 24 September 2013 11:14Noch einmal ein Aufruf: nutzt jemand heating_control? Gibt es probleme? Wünsche?
Heating-Control funktioniert bei mir problemlos.
Achja, kann man irgendwie einen Temperatursensor simulieren?
Ich habs mit einem virtuellen Aktor probiert, den ich mit dem Weather-Channel gepeered habe, aber mir war dann nicht so ganz klar, welche Werte ich mit postEvent setzen kann (Temperatur in hex * 10?).
Gruß
Michael
Wenn DHL heute mal noch in die Puschen kommt und mir mein Paket zustellt, kann ich zumindest den Fall mit einem echten Temperatursensor heute noch testen.
Hallo,
bei mir funktionieren die ersten Thermostate soweit ganz gut, danke für die Implementierung!
Ist es eigentlich möglich, das hinterlegte Wochenprogramm in fhem zu definieren? Falls nicht, könnte man das theoretisch überhaupt implementieren?
schöne Grüße
Jo
Zitat von: Jojo11 schrieb am Sa, 28 September 2013 14:54das hinterlegte Wochenprogramm in fhem zu definieren?
klar, nennt sich tempList :)
Hallo!
Danke für den Tip, habe jetzt die temp-offset auf 2.0K gestellt.
Mal sehen was passiert?!?
Wollte nochmal fragen wegen der Einbindung zum HCS-Modul, da ich damit meine Therme steuer und das klappt ja gerade jetzt nicht so richtig?!
Hoffe da gibt es eine Lösung in Zukunft!
Mfg Steffen
HCS modul habe ich geaendert.Sollte jetzt gehen. habe im device noch etwas nachgebessert...
Nabend,
so meiner kam heute auch an ;-) gleich mal installiert im Badezimmer, da war vorher so ECO Comfort 200 Krücke dran. Ich hoffe die neuen HM Dinger sind genauso "Wasserdicht" wie die VD's. Mir sind nämlich schon einige abgesoffen beim Duschen... da fand ich die alten echt besser, da waren keine Knöpfe dran.
Bis jetzt geht alles, auch wenn hier irgendwie unter dem Thermostat nen Missing_ACK zu sehen ist. Aber egal soll mich erstmal nicht stören, bedienen kann ich es.
Eine Frage, ich wollte jetzt mein HM Fensterkontakt direkt mit dem Ding koppeln aber unter dem WindowRec gibts kein peerChan, kommt das noch oder wie muss ich das machen? Dachte jetzt an sowas wie "set bz_Heizung_WindowRec peerChan 0 bz_Fenster single"
Gruß
Daniel
Zitat von: ext23 schrieb am Sa, 28 September 2013 17:53"set bz_Heizung_WindowRec peerChan 0 bz_Fenster single"
spnontan würde ich sagen, das ist falschrum.
Und das mit dem MissingAck solltest Du nicht ignorieren.
Zitat von: betateilchen schrieb am Sa, 28 September 2013 15:46Zitat von: Jojo11 schrieb am Sa, 28 September 2013 14:54das hinterlegte Wochenprogramm in fhem zu definieren?
klar, nennt sich tempList :)
Super, danke! Habe ich leider nicht selber gefunden :\
schöne Grüße
Jo
Mhh stimm, macht Sinn, der Sensor sendet ja und nicht das Thermostat... ich probiere es mal.
Und das mit den Missing acks mhh vielleicht war meine Temp liste zu viel auf einmal und der ist noch am ackern um das zu übertragen, ich werds mal beobachten.
/Daniel
Zitat von: betateilchen schrieb am Sa, 28 September 2013 18:17Zitat von: ext23 schrieb am Sa, 28 September 2013 17:53"set bz_Heizung_WindowRec peerChan 0 bz_Fenster single"
spnontan würde ich sagen, das ist falschrum.
Und das mit dem MissingAck solltest Du nicht ignorieren.
OK das mit dem Fensterkontakt hat er gemacht, auch wenn ich das nicht so richtig am Gerät sehe, der zeigt nichts an. Aber gut das muss ich noch erforschen. Aber was nicht geht sind die Temp Listen für Samstag und Sonntag, ich möchte "09:00 17.0 10:00 21.0 19:00 17.0 23:00 19.0 24:00 17.0" haben aber der schreibt das nicht rein, die anderen Tage gehen, nur das WE nicht. Im Log kommen da auch immer "no ack"...
Wie schaut es bei euch aus, geht das?
Nach einem get conf bekomme ich immer:
tempListFri 05:30 17.0 06:30 23.0 19:00 17.0 23:00 19.0 24:00 17.0
tempListMon 05:30 17.0 06:30 23.0 19:00 17.0 23:00 19.0 24:00 17.0
tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
tempListThu 05:30 17.0 06:30 23.0 19:00 17.0 23:00 19.0 24:00 17.0
tempListTue 05:30 17.0 06:30 23.0 19:00 17.0 23:00 19.0 24:00 17.0
tempListWed 05:30 17.0 06:30 23.0 19:00 17.0 23:00 19.0 24:00 17.0
/Daniel
Zitat von: martinp876 schrieb am Sa, 28 September 2013 10:06FHEM wird daran nichts aendern. das ist Sache der Regelung. Ist mir aber auch schon aufgefallen - und ich habe keine Ahnung, warum dies so ist. Spekulieren kann man, dass HM die temperatur am heizkörper 2Grad höher einschätzt.
Ich habe jetzt einige Tests gemacht. Diese Differenz scheint systemisch zu sein. Sie tritt sowohl bei regAdaptive on als auch bei regAdaptive off auf.
(siehe Anhang / see attachement)
Nach einer Änderung des adaptive-Registers werden einige andere Werte auch noch zurückgesetzt (z.B. wird die desired-temp auf den aktuell "gültigen" Wert aus der tempList zurückgesetzt)
Zitat von: ext23 schrieb am Sa, 28 September 2013 19:00OK das mit dem Fensterkontakt hat er gemacht, auch wenn ich das nicht so richtig am Gerät sehe, der zeigt nichts an.
Wenn Du das Fenster aufmachst, erscheint im Display das Fenster-Auf-Symbol und die Temperatur geht auf die Window-Open-Temperatur.
Falls das nicht passiert, stimmt mit dem Peering noch etwas nicht.
Zitat von: ext23 schrieb am Sa, 28 September 2013 19:00was nicht geht sind die Temp Listen für Samstag und Sonntag
...
Wie schaut es bei euch aus, geht das?
Funktioniert problemlos.
(siehe Anhang / see attachement)
wieso taucht eigentlich der state auch in T auf?
(siehe Anhang / see attachement)
Ich möchte mich auch bedanken für die Hilfe,die geduld und die Arbeit,
Bei mir hat es jetzt auch endlich geklappt.
Kann mir jetzt vll. Noch jemand erklären wie das mit der Fenster auf Funktion, funktioniert wo das Gerät on board hat.
Grusse RedOne
Mhh also ich bekomme es nicht hin die Zeiten am Samstag und Sonntag zu setzten, ich hab keine Ahnung warum. Ist der Speicher voll oder was?!?
2013.09.29 00:09:56 2: CUL_HM set bz_Heizung_ClimRT_tr tempListSat 09:00 17.0 10:00 21.0 19:00 17.0 23:00 19.0 24:00 17.0
2013.09.29 00:09:56 1: HMLAN_Send: HMLAN1 S:S669EFBF1 stat: 00 t:00000000 d:01 r:669EFBF1 m:62 B112 23FF23 21CE0D
2013.09.29 00:09:57 1: HMLAN_Parse: HMLAN1 R:R669EFBF1 stat:0001 t:D312F4E9 d:FF r:FFC1 m:62 8002 21CE0D 23FF23 00
2013.09.29 00:09:57 1: HMLAN_Send: HMLAN1 S:+21CE0D,00,01,
2013.09.29 00:09:57 1: HMLAN_Send: HMLAN1 S:S669EFDF2 stat: 00 t:00000000 d:01 r:669EFDF2 m:63 A001 23FF23 21CE0D 00050000000007
2013.09.29 00:09:57 1: HMLAN_Parse: HMLAN1 R:E1D2544 stat:0000 t:D312F56C d:FF r:FFBF m:23 A258 1D2544 1A2BCA 0000
2013.09.29 00:09:58 1: HMLAN_Parse: HMLAN1 R:R669EFDF2 stat:0001 t:D312F740 d:FF r:FFC2 m:63 8002 21CE0D 23FF23 00
2013.09.29 00:09:58 1: HMLAN_Send: HMLAN1 S:S669F0048 stat: 00 t:00000000 d:01 r:669F0048 m:64 A001 23FF23 21CE0D 00081444156C16541778184419E41A4D
2013.09.29 00:09:59 1: HMLAN_Parse: HMLAN1 R:R669F0048 stat:0001 t:D312F8CF d:FF r:FFBF m:64 8002 21CE0D 23FF23 00
2013.09.29 00:09:59 1: HMLAN_Send: HMLAN1 S:S669F049D stat: 00 t:00000000 d:01 r:669F049D m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:09:59 1: HMLAN_Parse: HMLAN1 R:R669F049D stat:0008 t:00000000 d:FF r:7FFF m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:09:59 1: HMLAN_Parse: HMLAN1 no ACK from 21CE0D
2013.09.29 00:10:00 1: HMLAN_Send: HMLAN1 S:S669F08A6 stat: 00 t:00000000 d:01 r:669F08A6 m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:10:00 1: HMLAN_Parse: HMLAN1 R:R669F08A6 stat:0008 t:00000000 d:FF r:7FFF m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:10:00 1: HMLAN_Parse: HMLAN1 no ACK from 21CE0D
2013.09.29 00:10:01 1: HMLAN_Send: HMLAN1 S:S669F0D64 stat: 00 t:00000000 d:01 r:669F0D64 m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:10:01 1: HMLAN_Send: HMLAN1 I:K
2013.09.29 00:10:01 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:D313047D IDcnt:0007
2013.09.29 00:10:01 1: HMLAN_Parse: HMLAN1 R:R669F0D64 stat:0008 t:00000000 d:FF r:7FFF m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:10:01 1: HMLAN_Parse: HMLAN1 no ACK from 21CE0D
2013.09.29 00:10:02 1: HMLAN_Send: HMLAN1 S:S669F13AE stat: 00 t:00000000 d:01 r:669F13AE m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:10:03 1: HMLAN_Parse: HMLAN1 R:R669F13AE stat:0008 t:00000000 d:FF r:7FFF m:65 A001 23FF23 21CE0D 00081B141C451D20
2013.09.29 00:10:03 1: HMLAN_Parse: HMLAN1 no ACK from 21CE0D
@Daniel,
das Abschicken der Kompletten templist en-block macht Probleme, da der RT etwas lange zum schreiben braucht. Ich arbeite noch daran.
wenn man die Kommandos eins nach dem anderen sendet ist es ok.
@Udo,
bei mir steht kein "T" in den readings.
@RedOne
der "eingebaute Fenster-open-detector" reagiert auf "plötzlichen temperatursturz". Wenn der auftritt geht es für eine definierte Zeit(auch in den Registern) nach Fenster-offen-temp
@Daniel,
kann ich nicht sehen,warum das temp-setzen abrebrochen wird. könnte an einem delay liegen, dass wir zu langsam sind oder der empfangspegel ist zu schlecht. das wiederholen im condBurst mode muss überarbeitet werden. bin ich dran.
Zitat von: martinp876 schrieb am So, 29 September 2013 08:15@Udo,
bei mir steht kein "T" in den readings.
och, bei mir gibt es auch noch ein "H" und ein "unknown0" - lauter lustige Sachen :)
Ich werde mal die Readings alle löschen und schauen, ob die nochmal auftauchen.
Zitat von: betateilchen schrieb am Sa, 28 September 2013 21:28Zitat von: martinp876 schrieb am Sa, 28 September 2013 10:06FHEM wird daran nichts aendern. das ist Sache der Regelung. Ist mir aber auch schon aufgefallen - und ich habe keine Ahnung, warum dies so ist. Spekulieren kann man, dass HM die temperatur am heizkörper 2Grad höher einschätzt.
Ich habe jetzt einige Tests gemacht. Diese Differenz scheint systemisch zu sein. Sie tritt sowohl bei regAdaptive on als auch bei regAdaptive off auf.
(siehe Anhang / see attachement)
Nach einer Änderung des adaptive-Registers werden einige andere Werte auch noch zurückgesetzt (z.B. wird die desired-temp auf den aktuell "gültigen" Wert aus der tempList zurückgesetzt)
Guten Morgen!
Habe gestern den Wert auf "2.0K" verändert, doch heute bei einer Einstellung von desired-temp:21 und T:23.5 ist der Regler immer noch auf Valve:7%!
Muss ich sehr sagen, finde ich sehr enttäuschend:-(.
Könnte man nicht den Regler(Valve) irgendwie zum off-set steuern??
Dann nochmal zum HCS, mit dem update von heute werden zwar die Regler erkannt aber nicht die die ich definiert hatte:
Readings
CUL_HM_HM_CC_RT_DN_21CEAE
idle
2013-09-29 10:08:23
CUL_HM_HM_CC_RT_DN_228AA2
idle
2013-09-29 10:08:23
Heiz_Bad_Ankleide
idle
2013-09-29 10:08:23
KinderZimmer
idle
2013-09-29 10:08:23
Wz_Heizung1
idle
2013-09-29 10:08:23
device
Therme
2013-09-29 10:03:23
devicestate
off
2013-09-29 10:02:31
eco
off
2013-09-29 10:08:23
locked
00:00:00
2013-09-29 10:08:23
overdrive
off
2013-09-29 10:08:23
state
idle
2013-09-29 10:08:23thermostat
icoregler ArbeitszimmerKeller
23.1
desired-temp
CUL_HM_HM_CC_RT_DN_21CEAE
MISSING ACK
CUL_HM_HM_CC_RT_DN_228AA2
RESPONSE TIMEOUT:RegisterRead
icoregler Heiz_Bad_Ankleide
22.2
desired-temp
icoregler KinderZimmer
22.0
desired-temp
icoregler WaschKeller
23.5
desired-temp
icoregler Wz_Heizung1
21.3
desired-temp ist das so gewollt???
Mfg Steffen
Ahh nach dem heutigen Update gehen die Temp Listen am WE bei mir auch! Jetzt frisst er die.
btw. das unknown0 37 habe ich auch ;-)
Gruß
Daniel
weiß jemand ob diese Fenster-Offen-Temp nur für eine bestimmte Zeit bleibt und dann wieder auf normal geht? Wenn man das so im GästeWC hat wo dann das Fenster unter Umständen vergessen wird, dann würde das Ding ja iwann wieder los legen. Das Detektieren, dass das Fenster wieder zu ist, ist vll schwieriger, doch ich dachte es wäre schon möglich, immerhin wird auch ohne aktivierte Heizung die Temperatur dann leicht ansteigen. Dauert halt ne Weile dass man das automatisch merken kann...
Andere Frage: Ist es "richtig", dass die Synchronisation von Datum/Uhrzeit nach dem Einlegen der Batterien noch nicht funktioniert?
Es freut mich, dass schon so viele Sachen gehen!
Hallo zusammen
gibt es schon eine Möglichkeit die Templiste aller Tage alle auf einmal mit den gleichen Werten zu setzen (tempListAllDays) ?
lg
Stefan
Die Fenster-Offen-Temp bleibt bei mir so lange, wie das Fenster offen ist. Laut den zur Verfügung stehenden Registern sollte das aber auch anders einstellbar sein - aber ich hab das noch nicht gebraucht.
Das Setzen von Datum und Uhrzeit vermisse ich auch noch. Nicht nur beim Batterienwechsel sondern einfach auch als "set <device> systime"
Zitat von: Stefan M. schrieb am So, 29 September 2013 10:56gibt es schon eine Möglichkeit die Templiste aller Tage alle auf einmal mit den gleichen Werten zu setzen
Mach Dir eine Funktion in der 99_myUtils, das ist die einfachste und flexibelste Lösung.
Guten Tag,
nun ist ja aus HCS der Fehler "isn't numeric" weg. Eine kleine Ungenauigkeit bleibt aber noch: Ist ein Regler auf "off" kommt HCS beim Initialisieren mit zwei Fehlermeldungen (exakt je eine für jedes "off" gestellte Device):
Argument "off" isn't numeric in subtraction (-) at ./FHEM/59_HCS.pm line 639.
Argument "off" isn't numeric in subtraction (-) at ./FHEM/59_HCS.pm line 639.
Vielen Dank für ein wirklich geniales Modul!
Christian
Das Missing Ack bekomme ich nicht weg irgendwie, hat da noch einer einen Tip für mich?!?
(siehe Anhang / see attachement)
mach mal ein komplettes list <device>, ich denke, da hat das Pairing einfach nicht funktioniert.
Naja aber ich kann alles bedienen und das Teil auch konfigurieren. Also zumindest die einzelenen Kanäle.
Internals:
DEF 21CE0D
EVENTS 82
HMLAN1_MSGCNT 151
HMLAN1_RAWMSG E21CE0D,0000,D5D4BC5F,FF,FFBF,EF861021CE0D0000000A88D5110025
HMLAN1_RSSI -65
HMLAN1_TIME 2013-09-29 13:00:44
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 151
NAME bz_Heizung
NR 1085
STATE MISSING ACK
TYPE CUL_HM
channel_01 bz_Heizung_Weather
channel_02 bz_Heizung_Climate
channel_03 bz_Heizung_WindowRec
channel_04 bz_Heizung_ClimRT_tr
channel_05 bz_Heizung_ClimaTeam
channel_06 bz_Heizung_remote
lastMsg No:EF - t:10 s:21CE0D d:000000 0A88D5110025
protCondBurst on
protLastRcv 2013-09-29 13:00:44
protSnd 77 last_at:2013-09-29 10:56:55
protState CMDs_done
rssi_at_HMLAN1 avg:-65.25 min:-81 max:-62 lst:-65 cnt:151
Readings:
2013-09-29 10:56:55 Activity alive
2013-09-29 12:36:30 CommandAccepted yes
2013-09-29 10:14:48 PairedTo 0x23FF23
2013-09-28 18:56:14 R-backOnTime 10 s
2013-09-29 10:14:48 R-btnLock unlock
2013-09-29 10:14:48 R-burstRx on
2013-09-29 10:14:48 R-cyclicInfoMsg on
2013-09-29 10:14:48 R-cyclicInfoMsgDis 0
2013-09-29 10:14:48 R-globalBtnLock off
2013-09-29 10:14:48 R-intKeyVisib invisib
2013-09-29 10:14:48 R-localResDis off
2013-09-28 18:56:14 R-lowBatLimitRT 2.1 V
2013-09-29 10:14:48 R-modusBtnLock off
2013-09-29 10:14:48 R-pairCentral 0x23FF23
2013-09-29 10:14:48 RegL_00: 01:01 02:01 09:01 0A:23 0B:FF 0C:23 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2013-09-29 13:00:44 actuator 0 %
2013-09-29 13:00:44 battery ok
2013-09-29 13:00:44 batteryLevel 3.2 V
2013-09-29 13:00:44 desired-temp 17
2013-09-29 13:00:44 measured-temp 21.3
2013-09-28 18:41:10 noReceiver src:21CE0D A010 0500000000000700
2013-09-29 00:10:04 state MISSING ACK
2013-09-28 16:25:22 time-request -
Helper:
mId 0095
rxType 140
Prt:
awake 0
sProc 0
Rspwait:
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -65.2516556291391
cnt 151
lst -65
max -62
min -81
Shadowreg:
RegL_00: 01:01 02:01 09:01 0A:23 0B:FF 0C:23 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
Attributes:
actCycle 000:10
actStatus alive
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room Bad
serialNr KEQ0580420
subType thermostat
Irgendwie habe ich hier auch noch ein paar Schwierigkeiten. Nachdem ich die templist gesetzt habe (über 99_myUtils), wurde sie scheinbar übernommen, aber trotzdem nicht angewandt. Zumindest bleibt desired temp immer noch auf dem alten Wert. Und MISSING ACK habe ich jetzt auch, obwohl ich erneut gepairt und sonst nichts verändert habe. Die Temperaturen werden weiterhin alle paar Minuten übertragen. Was muss ich denn machen, damit das Wochenprogramm umgesetzt wird?
schöne Grüße
Jo
Zitat von: Jojo11 schrieb am So, 29 September 2013 17:12Was muss ich denn machen, damit das Wochenprogramm umgesetzt wird?
Warten. Wirksam wird erst der nächste Schaltzeitpunkt. Der Thermostat muss auf Auto stehen.
Hast Du "verified" bei den Readings der tempList stehen?
Das Missing Ack könnte von "zuviel" Funkverkehr kommen, warte mal ein ein paar Minuten und beobachte, ob das wieder verschwindet.
Gibts eigentlich schon unterschiedliche FW Versionen ? Ich habe 1.0 aber im Wiki steht was von 2.0.
/Daniel
Zitat von: betateilchen schrieb am So, 29 September 2013 17:23Warten. Wirksam wird erst der nächste Schaltzeitpunkt. Der Thermostat muss auf Auto stehen.
Hast Du "verified" bei den Readings der tempList stehen?
Das Missing Ack könnte von "zuviel" Funkverkehr kommen, warte mal ein ein paar Minuten und beobachte, ob das wieder verschwindet.
Ein "verified" kann ich hier nicht finden, aber die Liste scheint angekommen zu sein:
ValvePosition 0 % 2013-09-29 17:50:48
desired-temp 21 2013-09-29 17:50:48
measured-temp 23.6 2013-09-29 17:50:48
mode auto 2013-09-29 17:50:48
motorErr ok 2013-09-29 17:50:48
state T: 23.6 desired: 21 valve: 0 % 2013-09-29 17:50:48
tempListFri
05:30 17.0 08:30 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2013-09-29 16:41:29
tempListMon
05:30 17.0 08:30 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2013-09-29 16:41:29
tempListSat
06:30 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2013-09-29 16:41:29
tempListSun
06:30 17.0 09:00 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2013-09-29 16:41:29
tempListThu
05:30 17.0 08:30 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2013-09-29 16:41:29
tempListTue
05:30 17.0 08:30 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2013-09-29 16:41:29
tempListWed
05:30 17.0 08:30 21.0 21:00 17.0 23:00 21.0 24:00 17.0
2013-09-29 16:41:29
unknown0 33 2013-09-29 17:50:48Die MISSING ACKs bleiben auch hartnäckig bei beiden Thermostaten.
schöne Grüße
Jo
Zitat von: ext23 schrieb am So, 29 September 2013 17:45Gibts eigentlich schon unterschiedliche FW Versionen ? Ich habe 1.0 aber im Wiki steht was von 2.0.
/Daniel
Hallo,
das ist mir auch aufgefallen. Ich habe bei beiden Geräten V1.0 und denke mal, dass das im Wiki ein copy&paste Fehler vom alten Gerät ist. Ansonsten würde mich natürlich auch interessieren, wie man updaten kann (einschicken?).
schöne Grüße
Jo
Zitat von: betateilchen schrieb am So, 29 September 2013 10:06Zitat von: martinp876 schrieb am So, 29 September 2013 08:15@Udo,
bei mir steht kein "T" in den readings.
och, bei mir gibt es auch noch ein "H" und ein "unknown0" - lauter lustige Sachen :)
Ich werde mal die Readings alle löschen und schauen, ob die nochmal auftauchen.
Die Phantomreadings tauchen nach dem Löschen bei mir immer wieder auf.
Hallo!
Wollte nur kurz mitteilen das das "Missing Ack" auch schon ein paar Tage bei mir anzeigt wird,
aber trotzdem der Regler alle Befehle übernehmen tut.
Mfg Steffen
Hallo zusammen
bei mir ist ja auch der gleiche Effekt mit "Missing Ack" bei den Reglern vorhanden. Bin froh dass es nicht nur bei mir ist.
lg
Stefan
Guten Morgen!
Also ich bin jetzt langsam sowas von enttäuscht,
denn eingestellt ist desired auf 21 aber es sind jetzt schon 23.7 und Regler ist immer noch auf 33%.
Habe schon auf 2.0k geändert aber es scheint nicht der Richtige Weg zu sein.
Vielleicht hat ja jemand hier noch eine andere Lösung, ansonsten werde ich es wohl wieder abbauen müssen?!?
Mfg Steffen
Moin,
mhh so schlimm ist mir das noch garnicht aufgefallen. Schau mal so sieht es bei mir aus:
(siehe Anhang / see attachement)
Ich kann da jetzt erstmal nichts feststellen das hier was nicht passt. Sicher die Temp ist etwas stark angestiegen aber er hat ja zu gemacht. Und dazu kommt das gerade jemand geduscht hat, dann steigt die Temp eh nochmal an. Aber gut ich find die Dinger ehe absolute Grütze, das ist sowas von dumm an der Heizung zu messen, da verstehe ich HM echt nicht wieso die von den anderem System weg sind. Zumal ich es hasse wenn der Ventilregler Tasten und LCD hat, blödsinn sowas... Aber was will man machen, die bauen auch nur das wose mehr Kohle mit umsetzen können und nicht was dem Kunden gefällt...
Gruß
Daniel
UPDATE:
Dazu mal noch die Temperator von einem anderen Sensor im Bad:
(siehe Anhang / see attachement)
Meine Erfahrungen mit dem alten System:
- es hat ca. 2 Wochen gedauert, bis dass das System eingeschwungen war
- Das Verhalten der Ventile hatte ich dort auch. Erst nachdem ich
- die Ventile mit einem Hammer gängig gemacht habe
- den Stößel leicht eingefettet habe
- das Startprogramm vom Ventil 2x laufen lassen habe (das sucht nach Start- und End-Position vom Stößel und passt die Parameter entsprechend an)
hab ich die 0 als Basiswert der Ventile gehabt.
Zitat von: ext23 schrieb am Mo, 30 September 2013 07:04Zumal ich es hasse wenn der Ventilregler Tasten und LCD hat,
Das Display finde ich schon ok, und die Tasten (und vermutlich auch das Drehrad) kann man ja problemlos sperren.
Zitat von: DC schrieb am Mo, 30 September 2013 07:37Meine Erfahrungen mit dem alten System:
- es hat ca. 2 Wochen gedauert, bis dass das System eingeschwungen war
Das kann ich bestätigen. Da bei mir aber alle Ventile immer schon (von den alten Reglern) einmal pro Woche auf- und wieder zugedreht wurden, kann ich mir die Sache mit dem Hammer jetzt bei der Umrüstigung sparen.
Ich lass die neuen Regler einfach mal eine Zeitlang laufen, ich bin da sehr zuversichtlich, dass auch die automatisch lernen, die Ventile korrekt zu steuern.
Naja das Display mhhh das macht alles nur klobig. Und überall kreich der Dereck rein, von Wasser ganz zu schweigen wenn das Fenster bei Regen oder Schnee mal offen bleibt ...
Aber die Probleme mit dem Stift hatte ich hier bei mir nicht, die waren alle sehr leichtgängig. Aber mit dem Hammer würde ich vorsichtig sein ;-) Meistens reicht das ja mit dem Daumen zwei, drei mal den Stift rein zu drücken.
/Daniel
Wenn ein Ventil mehrere Jahre nicht betätigt wurde (wie ich beim Einzug in die jetzige Wohnung feststellen musste) bewegst Du da mit einem Fingerdruck gar nix mehr. Dann hilft wirklich nur noch Hammer (leichte Schläge) oder Ventil austauschen.
Hi,
unknown0 habe ich mir erlaubt einzubauen. Es zeigt den Unbekannten teil des Control-bytes. der verändert sich aber ich habe noch keine Beschreibung oder systematik erkannt. Falls es jemand entschlüsseln kann, super. Ansonsten werde ich es ggf wieder entfernen.
@unimatrix:
R-tempFallWinPerio 15 min
sollte m.E. nur relevant sein, wenn kein SC gepeert ist. Kann man sendern. Diese Zeit wird eingehalten, egal wie der Fensterzustand letztendlich ist!
das synchen der Uhrzeit sollte funktionieren. Ich habe nie eine eingestellt, stimmt aber.
Die Sommerzeit Abschaltung steht kurz bevor! Man kann auch
R-daylightSaveTime on
setzen. Auswirkungen untested ;-)
@Stefan
tempListAllDays ist nicht geplant
@Udo
der RT fragt die Uhrzeit jeden tag 2mal kurz hintereinander ab, wie auch ein TC. FHEM beantwortet dies schon seit einiger Zeit.
sysTime geht auch schon - muss man am device machen, nicht am channel.
Phantom Register: Unkonwn ist klar. das T und H nicht. In welchen Kanal tauchen die auf? was hast du alles gepeert?
@Christian,
das ist ein HCS problem - eigentlich nicht meine Baustelle. Das sollte beim TC auch so gewesen sein. ein Delta sollte weder bei "on" noch bei "off" errechnet werden (auch wenn beide eigentlich einen Wert hinterlegt haben).
@ext23
missingAck bei welchen Befehl? An weiteren Verbesserungen arbeite ich. Ist leider kompliziert... dauert noch etwas mit den tests
@jo
beim setzen von mehreren tempList kommt missing-ack weil der RT zu langsam ist. Wird aber doch (gerade noch) bearbeitet.
Die templist wird einwandfrei genutzt (bei mir). Der Wert wird erst beimnächsten "Zeitsprung" aktiv. Oder du schaltest noch einmal auf "auto". Nur durchsetzen der Liste wird die temp nicht geaendert!
@Daniel,
dein Test ist nicht relevant. du musst einmal den sollwert auf ist-wert -1 einstellen. die Heizung sollte m.E aus bleiben. In deinem Fall wird der sollwert nochgedreht, ist aber nie 2k unter dem ist-wert. Steffen hat schon recht.
Gruss Martin
Zitat von: martinp876 schrieb am Mo, 30 September 2013 10:27Phantom Register: Unkonwn ist klar. das T und H nicht. In welchen Kanal tauchen die auf? was hast du alles gepeert?
ClimRT_tr, gepeert sind zwei Fensterkontakte, ein SC und ein RHS.
Zitat von: martinp876 schrieb am Mo, 30 September 2013 10:27Die templist wird einwandfrei genutzt (bei mir).
Bei mir stehen alle temLists auf "24:00 16" da ich die gesamte Zeitsteuerung per Google Kalender mache und es ansonsten zu einer Vermischung aus den Sollwerten der tempList und den Sollwerten, die fhem schickt kam. Irgendwie fehlt den neuen Reglern die Betriebsart "central"...
hm - nicht einfach zu finden.
was sagt der Zeitstempel? kommt der zeitgleich mit einem anderen trigger? einem der peers?
Gruss Martin
Hallo,
hast du irgendwo deine Zeitsteuerung per Google Kalender dokumentiert? Ich wäre längst auf Zentralensteuerung umgestiegen, aber dachte bisher immer (ggf. fälschlicherweise) dass das setzen der desired-temp über die Zentrale nicht verlässlich ist und ich mir einfach dachte, je mehr ohne Funk geht, desto besser und stabiler. Aber vll hat sich die Zuverlässigkeit inzwischen verbessert?
Insgesamt hab ich jetzt 10 Ventile/Thermostate (alte und neue gemischt) und da wird schon viel hin und her gefunkt hab ich das Gefühl...
VG
Zitat von: unimatrix schrieb am Mo, 30 September 2013 11:08hast du irgendwo deine Zeitsteuerung per Google Kalender dokumentiert?
da gibt es doch nicht viel zu dokumentieren? Ich nutze das Kalendermodul von fhem und habe einen Kalender namens "Kalender_Heizung" definiert.
Ein Eintrag im Google-Kalender hat im Titel einfach den Reglername und die Solltemperatur für Beginn und Ende stehen, also z.B. "wz_Thermostat 22 16"
Im Beispiel wird die Temperatur zuerst auf 22 Grad eingestellt und am Ende des Zeitraums auf 16 Grad zurückgeregelt.
Dazu gibt es zwei notify, die entsprechend getriggert werden und die sich nur im split unterscheiden:
Kalender_Heizung:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,$dtemp,undef)= split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }
Kalender_Heizung:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,undef,$dtemp) = split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }
Zitat von: martinp876 schrieb am Mi, 25 September 2013 09:34hat jemand schon einen Wetter-sensor gepeert?
jepp...
Weather Channel vom RT:
Internals:
DEF 2286BC01
NAME az_FHT_Weather
NR 320
STATE ???
TYPE CUL_HM
chanNo 01
device az_FHT
peerList testSensor,
Readings:
2013-09-30 11:54:34 R-sign off
2013-09-30 11:54:34 peerList testSensor,
Helper:
peerIDsRaw ,20DACD01,00000000
Role:
chn 1
Shadowreg:
Attributes:
expert 1
group Heizung
model HM-CC-RT-DN
peerIDs 00000000,20DACD01,
room 12_Arbeitszimmer
Sensor:
Internals:
CFGFN
DEF 20DACD
EVENTS 15
HMUSB_MSGCNT 22
HMUSB_RAWMSG E20DACD,0000,0D1FAEB8,FF,FFC2,0B867020DACD00000000E039
HMUSB_RSSI -62
HMUSB_TIME 2013-09-30 12:13:35
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 22
NAME testSensor
NR 436
STATE T: 22.4 H: 57 D: 13.5
TYPE CUL_HM
lastMsg No:0B - t:70 s:20DACD d:000000 00E039
peerList az_FHT_Weather,
protCondBurst on
protLastRcv 2013-09-30 12:13:35
protResnd 2 last_at:2013-09-30 12:10:30
protSnd 8 last_at:2013-09-30 12:10:31
protState CMDs_done_events:2
rssi_at_HMUSB avg:-45.86 min:-62 max:-40 lst:-62 cnt:22
Readings:
2013-09-30 12:10:28 Activity alive
2013-09-30 12:10:30 CommandAccepted yes
2013-09-30 12:10:31 PairedTo 0x127000
2013-09-30 12:10:31 R-burstRx off
2013-09-30 12:10:31 R-intKeyVisib invisib
2013-09-30 12:10:31 R-pairCentral 0x127000
2013-09-30 12:10:31 RegL_00: 01:00 02:01 05:00 0A:12 0B:70 0C:00 0F:00 00:00
2013-09-30 12:13:35 dewpoint 13.5
2013-09-30 12:13:35 humidity 57
2013-09-30 12:10:31 peerList az_FHT_Weather,
2013-09-30 12:13:35 state T: 22.4 H: 57
2013-09-30 12:13:35 temperature 22.4
Helper:
burstEvtCnt 2
mId 003D
peerIDsRaw ,2286BC01,00000000
rxType 140
Prt:
awake 0
sProc 0
Rspwait:
Role:
chn 1
dev 1
Rssi:
At_hmusb:
avg -45.8636363636364
cnt 22
lst -62
max -40
min -62
Shadowreg:
Attributes:
actCycle 000:10
actStatus alive
expert 2_full
firmware 1.3
model HM-WDS10-TH-O
peerIDs 00000000,2286BC01,
serialNr KEQ0174839
subType THSensor
gepeert sind die problemlos, aber der RT kann scheinbar nix damit anfangen.
Um die Rohmessage werde ich mich noch kümmern.
ok danke mir war nicht klar, wie gut das Kalendermodul schon mit Google zusammen funktioniert! :)
Also ich habe jetzt 5 von den Dingern dran. Ich habe alle in den Modus manuell (am Taster) eingestellt und auf Off runtergedreht.
Bei meinen versuchen, die desired-temp per FHEM zu setzen komme ich auf eine Erfolgsquote von gefühlten 20%. Allerdings scheint auch mein hmlan oft im Overflow zu sein. Ich nehme an da wird das irgendwann verworfen? GGf. reichen die Standardeinstellung für HMLAN mit 10 Temp-Sensoren/Ventilen niht mehr aus? Missing-ACKs sehe ich zumindest keine.
Zitat von: unimatrix schrieb am Mo, 30 September 2013 12:24GGf. reichen die Standardeinstellung für HMLAN mit 10 Temp-Sensoren/Ventilen niht mehr aus?
Ich denke, über 10 Regler kann der HMLAN nur müde lächeln... Ob das Setzen von Temperaturen im manuellen Mode Sinn macht, erschließt sich mir nicht.
Zitat von: betateilchen schrieb am Mo, 30 September 2013 12:17Um die Rohmessage werde ich mich noch kümmern.
15867020DACD00000000D131Der Sensor ist mit fhem gepairt und mit dem Weather-Channel des RT gepeert.
Die Wettermeldung geht offenbar (wie weiter oben schon geschrieben) immer an broadcast.
sorry wenn ich mit Fragen nerve....aber woran sieht man denn dass Fenster-Auf detektiert wurde? Nur am Ventil oder auch irgendwo an einem Reading?
Bei mir war es draußen gestern 15 Grad - vll nicht kalt genug für eine Detektierung? Außerdem kam das Problem dazu, dass offenbar direkt am Ventil (wo ja gemessen wird) die Temperatur nicht so stark abfällt - weil das sitzt ja nunmal auf der relativ warmen Heizung.
Unterstützt das neue Ding einen direkt gepaarten Fenstersensor?
Zitat von: betateilchen schrieb am Mo, 30 September 2013 12:34... Ob das Setzen von Temperaturen im manuellen Mode Sinn macht, erschließt sich mir nicht.
Einen CENT-Mode gibts ja nicht oder? Der Auto-Mode macht ja noch weniger Sinn, dann greift ja womöglich kurz nach dem Setzen das Automatikprogramm des Ventils.
Zitat von: unimatrix schrieb am Mo, 30 September 2013 12:56Unterstützt das neue Ding einen direkt gepaarten Fenstersensor?
ja. Sogar mehrere.
Erkennen kannst Du es in fhem z.B. daran, dass die desired-temp auf den Wert aus dem Register R-tempFallWinOpen geändert wurde.
EIgentlich ist dafür der Channel WindowRec zuständig, aber so richtig funktioniert hat der (zumindest anzeigetechnisch sinnvoll) noch nie wirklich.
Zitat von: unimatrix schrieb am Mo, 30 September 2013 12:57Der Auto-Mode macht ja noch weniger Sinn, dann greift ja womöglich kurz nach dem Setzen das Automatikprogramm des Ventils.
Automatikprogramm abschalten...
Zitat von: betateilchen schrieb am Mo, 30 September 2013 10:39Zitat von: martinp876 schrieb am Mo, 30 September 2013 10:27Phantom Register: Unkonwn ist klar. das T und H nicht. In welchen Kanal tauchen die auf? was hast du alles gepeert?
ClimRT_tr, gepeert sind zwei Fensterkontakte, ein SC und ein RHS.
Inzwischen bin ich fast sicher, dass die Phantomreadings aus dem Modul dewpoint kommen.
Das parst den state und erwartet nach "T:" als nächsten Eintrag ein "H:" und nicht "desired" und "valve"
Zitat von: betateilchen schrieb am Mo, 30 September 2013 12:40Zitat von: betateilchen schrieb am Mo, 30 September 2013 12:17Um die Rohmessage werde ich mich noch kümmern.
15867020DACD00000000D131
Der Sensor ist mit fhem gepairt und mit dem Weather-Channel des RT gepeert.
Die Wettermeldung geht offenbar (wie weiter oben schon geschrieben) immer an broadcast.
Die Sache mit dem externen Sensor funktioniert. Wenn ein Sensor mit dem Channel1 des RT gepeert ist, loggt und verarbeitet der RT ab sofort die Messwerte vom externen Sensor.
Erkennen tut man das aber im RT nirgends.
Ich hab mich nur gewundert, warum im Arbeitszimmer seit etwa zwei Stunden immer die Temperatur vom Balkon geloggt wird (dort ist der neue HM-Sensor für die Aussentemperatur montiert)
Das MISSING ACK im Device hatte ich heute auch.
Und zwar von ca. 12 Uhr bis eben vor fünf Minuten. Der Beginn des "Problems" fällt mit dem Zeitpunkt zusammen, an dem ich den externen Temperatursensor mit dem RT erfolgreich gepeert habe, und das Problem verschwand, nachdem ich das Peering wieder gelöscht habe.
----------------
EDIT
Der RT macht komische Sachen.
(siehe Anhang / see attachement)
Der Temperatursprung ist für mich nicht nachvollziehbar. Aber seit diesem Zeitpunkt sendet der RT immer die gleiche Temperaturinformation von 24.0° oder 24.1° - das kann eigentlich aber nicht stimmen.
Jetzt habe ich das MISSING ACK wieder, genau am gleichen Regler wie heute Nachmittag. Und ich kriege das nicht mehr weg. Es ist übrigens der einizige RT mit diesem Verhalten, die beiden anderen laufen völlig unauffällig.
Ich habe jetzt den Regler schon komplett zurückgesetze und neu gepairt - keine Änderung.
Es scheint auch so zu sein, dass der Regler vom Device eine Nachricht an Broadcast schickt, obwohl er korrekt mit fhem gepairt ist.
ich bin mal wieder etwas ratlos (und frustriert)
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
...@betateilchen (...@betateilchen)
ist bei mir aber nun schon seit Tagen so:
(siehe Anhang / see attachement)
obwohl ich aber noch keine nachteile daran erkannt habe.
Denn befehle nimmt er ja an.
Vielleicht liegen aber die Probleme tiefgründiger damit?!?
Mfg Steffen
Ich habe die Probleme, seit ich heute mit dem Weather-Channel getestet habe.
Das habe ich nur mit diesem einen Regler bisher gemacht.
Inzwischen habe ich den Regler komplett zurückgesetzt, das Gerät komplett aus fhem entfernt und alles neu gestartet.
Dann eine vollständige Neukonfiguration und trotzdem kam die Meldung nach ein paar Minuten wieder.
Was mich wundert, ist das hier:
(siehe Anhang / see attachement)
Wieso taucht da das R-burstRx mit einem set_ state auf?
Und wieso taucht das nach einem kompletten Reset auf?
Und was ist das hier?
noReceiver src:2286BC 8010 0100000000 2013-09-30 20:27:10
---
burstRX im channel 01 ist ein überbleibsel. Wahrscheinlich hast du ein ser burstrx im weather-channel gemacht (ist noch zugelassen - wird aber nie korrigiert)
ich werde die zugriffsrechte der Register noch nach Channels beschränken.
das missing_ack ist meist temporär und kann kommen, wenn eine message wiederholt wird.
ich bin hier am überarbeiten des Konzeptes um das wiederholen von messages auch bei conditional-burst zu realisieren. Das kostet einiges an test-arbeit - dauert also noch ein bisschen.
das betrifft dann das gesamte protokoll, muss also einiges getested werden....
Gruss Martin
Ehrlich gesagt, denke ich nicht, dass das MISSING ACK in diesem Fall wirklich vom wiederholen kommt. Eine eigene andere Idee habe ich aber auch nicht.
Seit ich den HMUSB am Beaglebone habe, sind die Probleme beim Übertragungsprotokoll hier eigentlich komplett verschwunden. Nur dieser eine RT macht im Moment den Kummer, und das auch exakt erst seit den Tests mit dem Weather-Channel und dem externen Sensor.
Und das burst habe ich definitiv nicht im Weather gesetzt.
Hallo,
ich habe da noch ne frage
was bedeutet
unknow0 33
das steht bei mir?
Missing Ack habe ich auch aber bisher funtioniert alles bei mir
ohne probleme.
Gruß RedOne
Also ich habe das Missing Ack nur beim, ja wie sagt man, "Hauptdevice". Dafür dauerhaft, aber dennoch funktioniert alles. Was mich nur wundert ist, dass die Antenne bei dem Regler dauerhaft blinkt, ich dachte die leuchtet immer. Also einige Sachen sind echt komisch, aber zumindest funktioniert bei mir alles, also ich kann nicht klagen. Aber ich nutze auch nicht viel, schon garnicht ändere ich da irgend welche Register. Ich hab lediglich 1 Fensterkontakt an dem Regler.
Gruß
Daniel
Zitat von: ext23 schrieb am Mo, 30 September 2013 21:20Also ich habe das Missing Ack nur beim, ja wie sagt man, "Hauptdevice".
wo denn auch sonst?
Zitat von: ext23 schrieb am Mo, 30 September 2013 21:20Was mich nur wundert ist, dass die Antenne bei dem Regler dauerhaft blinkt
Dann ist er nicht korrekt gepairt.
Zitatwas bedeutet unknow0 33
wenn man das wüßte, hätte das bestimmt einen anderen Namen als unknown ...
Bei mir steht da übrigens bei den drei Reglern: 24 oder 38 oder 24
Übrigens:
Der Regler mit dem MISSING ACK ist der mit der 38, die beiden anderen, korrekt arbeitenden RTs haben die 24.
---
Na da gibts doch noch die anderen Geräte da, die einzelnen Unterkanäle da, das ist ja immer etwas kryptisch alles.
Gepaired sein sollte es wohl, ich kann ja alles bedienen oder nimmt das Ding auch Befehle an wenn es nicht gepaired ist, ich dachte nicht... Das blinken der Antenne ist auch erst seit gestern.
Ich biete übrigens: unknown0: 37
Gruß
Daniel
Zitat von: ext23 schrieb am Mo, 30 September 2013 21:53Na da gibts doch noch die anderen Geräte da, die einzelnen Unterkanäle da, das ist ja immer etwas kryptisch alles.
Aber die Kommunikation läuft immer über das Device.
Aha ok, naja wie gesagt solange das alles scheinbar nur Anzeigefehler sind stört mich das ehe nicht, ich denke mal die Dinger werden noch genug Macken haben, wurde ja nun erst auf den Markt geworfen und großartig testen tun die bei dem Hersteller bekannterweise ja nichts.
Viele Grüße
Daniel
hi,
ich habe eine neue Version eingestellt. Da sind erhebliche Umstellungen im "wiederholmechanismuss" eingebaut. Vorteil in erster Linie sollte sein, dass die conditional-burst devices auch messages wiederholen koennen.
Da hier hierzu einigs aufräumen musste ist gründliches Testen angesagt.
Bei mir hat es soweit funktioniert (sonst wäre es nicht hochgeladen worden).
das "missing-ack" sollte aus dem device verschwinden. anstatt dessen kommt wie bei allen (ausser TC - historisch) der status des Protokoll - also hoffentlich CMDs_done ohne Zusatz.
Gruss Martin
Danke Martin,
und testen tun wir doch alle gerne ;-) Ich werde gleich mal ein Update anstoßen.
Viele Grüße
Daniel
Hallo!
Möchte den Ersten erfolgreichen Test berichten,
"keine Missing Ack" mehr und alle befehle werden sofort und bis jetzt zu 100% bei mir umgesetzt.
Danke für die tolle Arbeit und deine Geduld...
Hätte da noch eine frage am Rande:
Wenn kann ich das Richtig einstellen im SVG das wenn ich mit event-on-change-reading arbeite,
das er die Daten ordentlich darstellt, wenn es überhaupt geht?
(siehe Anhang / see attachement)
Mfg Steffen
mit steps statt lines
Hallo zusammen
bei mir ging gerade gar nichts mehr mit den Reglern trotz aktuellem Softwarestand.
Overload am HMLan, Missing Ack für die Regler.
Es wurde kein Fensterstatus mehr zu den Reglern übertragen. (virtuelle Buttons und notify kein direktes peer)
Habe alles neu gestartet mal sehen wie es jetzt läuft.
lg
Stefan
Welche datei wird den geupdatet die HMLan.pm
Oder welche ?
00_HMLAN.pm
10_CUL_HM.pm
98_HMinfo.pm
Hallo zusammen,
es funktioniert nicht wirklich, die Regler reagieren nicht auf den Fensterstatus, das HMLan geht auf Overload.
Ich werde heute Abend und morgen eine komplett neue Umgebung auf einem RaspberryPi installieren und nur das HMLAn, einen Regler und einen Fenstersensor konfigurieren und dann mal beobachten.
lg
Stefan
Bei mir funktioniert im Moment scheinbar mal ALLES... vermutlich ein Zufall, der maximal bis zum nächsten Update anhält...
Wobei: Von der Traumvorstellung "Homematic auf RaspberryPi" bin ich inzwischen komplett abgekommen. Der Wechsel auf das Beaglebone Black hatte bereits > 90% aller HM-Probleme beseitigt. Alles was zeitkritisch ist (und das Homematic-Protokoll IST zeitkritisch) gehört nach meinen bisherigen Erfahrungen nicht auf den Raspberry. Dabei ist es auch unerheblich, ob man HMLAN oder HMUSB nutzt - ich habe beides probiert und hatte mit beidem auf dem Raspi massive Probleme.
Hallo
bei mir funktioniert der Türkontakt einwandfrei. Ich habe meine zwei RTs und den Türkontakt nicht in fhem, sondern direkt gepeert. Allerdings gibt es weiterhin eine merkwürdige Erscheinung:
Wenn ich die Templiste für einen Tag, z.B. Montag setze geht das (allerdings muss ich das getrennt für jeden RT machen).
Wenn ich nun die Templiste für Dienstag setze, wird in den Readings die Liste aktualisiert und die Liste vom Montag auf die Ursprungswerte gesetzt. Der Thermostat behält aber die vorher vorgegebene Temperatur bei. Kann also auch nur ein Darstellungsproblem von fhem sein. Ob es ev. daran liegt dass ich zwei RTs habe weiß ich nicht. Bekomme am Freitag ein weiteres Thermostat und werde es dann noch mal testen.
Also irgendetwas stimmt noch nicht so ganz, aber es wird täglich besser. Ich habe mitunter den Eindruck, dass fhem und HM auch an anderen Stellen noch nicht 100% harmonieren.
Aber trotzdem bisher tolle Arbeit und es macht viel Spaß damit zu experimentieren.
Gruß
Burchard
Hallo zusammen,
sollte ich dann lieber mit dem HMLan wieder auf die Fritzbox umziehen da läuft auch noch ein aktuelles FHEM drauf?
lg
Stefan
Hi,
bei mir läuft es jetzt ohne Probleme und ohne Overload.
Habe HMLan + RaspberryPi im Einsatz
Gruß Otto
Zitat von: BuRi schrieb am Mi, 02 Oktober 2013 09:43Wenn ich nun die Templiste für Dienstag setze, wird in den Readings die Liste aktualisiert und die Liste vom Montag auf die Ursprungswerte gesetzt.
Lass Dich davon nicht irritieren. Der RT braucht eine Zeitlang, um das zu verarbeiten und zu antworten. Die Readings heißen ja Readings, weil sie vom Gerät gelesen werden und das ist direkt nach dem Set-Befehl noch nicht möglich. Irgendwann steht unter den tempList-Readings aber ein Reading mit dem Wert "verified" - dann sollten alle Readings die von Dir eingegebenen Werte haben.
Im Zweifelsfall hilft auch immer mal ein getConfig, um die Werte neu zu lesen.
Zitat von: Stefan M. schrieb am Mi, 02 Oktober 2013 10:08sollte ich dann lieber mit dem HMLan wieder auf die Fritzbox umziehen da läuft auch noch ein aktuelles FHEM drauf?
Den Teufel mit dem Beelzebub austreiben?
Auf welche Hardware dann ?
Ich habe jetzt mal einen BeagleBone Black bestellt.
lg
Stefan
Hallo,
jetzt mal ein neues Problem. Nach dem Setzen der TempList habe ich folgende Fehlermeldung im logfile gefunden:
2013.10.02 09:18:45 2: CUL_HM set EG.WZ.HeizungsT.02_ClimRT_tr tempListWed 06:30 17.0 08:00 20.0 17:00 18.5 22:30 20.0 24:00 17.0
Use of uninitialized value in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 1612.
2013.10.02 09:24:36 2: CUL_HM set EG.WZ.HeizungsT.01_ClimRT_tr tempListThu 06:30 17.0 08:00 20.0 17:00 18.5 22:30 20.0 24:00 17.0
Use of uninitialized value in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 1612.
Was hat es denn damit auf sich?
Gruß
Burchard
Das ist keine wirkliche Fehlermeldung, sondern ein Hinweis auf "optisch unschöne" Programmierung. Da wird einfach irgendwo der Fall nicht abgefangen, dass eine Variable keinen Inhalt haben kann.
@Burchard
peeren des fensterkontakts sollte kein Problem machen. kann man auch simulieren, also an einen virtuellen Button anschliessen. Natürlich muss man an einen WindowRec peeren - klar hoffe ich.
die templist ist natürlich je RT zu setzen - sollte dies anders sein?
hast du
attr autoReadReg 4_reqStatus
im device gesetzt? das stellt sicher, dass die Anzeuge immer abgeglichen wird. Nach änderungen werden die Register automatisch gelesen.
Ansonsten kannst du manuell den Wert für Montag setzen, ein getConfig machen den wert für dienstag setzen, ein getConfig machen.
Wenn du so vorgehst - stimmen dann die Werte?
Hintergrund: ich werde noch einmal prüfen, ob ich auch bei "templist" die daten aus dem shadow berücksichtige. generell empfehle ich IMMER autoReadReg.Ich werden den default einmal auf "an" setzen..
und dann noch: das Register NUR im device setzen. Am besten in allen Devices ausser Config-only, also remote. Die antworten eh nicht.
@Stefan
mein HMLAN läuft auf der FB 7390 - keine (kaum?) Probleme. Das Timing stimmt jedenfalls
Super!!
Danke mit "attr autoReadReg 4_reqStatus" geht es. Bin immer wieder erstaunt was es alles in fhem gibt.
Gruß
Burchard
ich habe 2 Register vergessen einzubauen. Hier also der Nachtrag und eine Änderung der Namen
tempFallWinOpen -> winOpnTemp
tempFallWinPerio -> winOpnPeriod
boostAftWinOpen -> winOpnBoost
und neu sind:
winOpnDetFall
winOpnMode
damit sind die register, die zur window-open-detection gehören hintereinander sortiert.
winOpnTemp sowie winOpnBoost sind immer aktiv, egal ob winopen intern oder extern genutzt wird.
die anderen 3 beziehen sich wohl auf den internen window open-detector.
Mir ist nicht klar, ob der interne win-open automatisch "aus" ist wenn man einen externen gepeert hat ist mir nicht klar. Besser man schaltet ihn dann ab.
Der interne Decetor funktioniert. Aber auf einen meiner Sensoren scheint die Sonne (nicht perfekt...) aber wenn der Schatten kommt wird immer Fenster-offen erkannt. Also besser aus, wenn man einen externen Sensor nutzt, die könnten "ge-odert" sein.
V3990 fehler: nehmt V3991 - sorry
man sollte ein
set <RT-DNdevice> clear register
set <RT-DNdevice> getConfig
machen. Dann sind die alten register geschichte
Gruss Martin
Zitat von: martinp876 schrieb am Mi, 02 Oktober 2013 12:09generell empfehle ich IMMER autoReadReg.Ich werden den default einmal auf "an" setzen..
Bitte nicht.
ok - aber warum?
den meisten sollte es helfen - und das ist Sinn der Sache. Gerade Anfänger werden immer wieder in die Falle tappen, dass alte Werte herumstehen oder ein set_ nicht verschwindet. Default sollte max sicherheit und komfort bieten.
wenn ich es setze ist es nur ein default. falls du ein 0_off reinschreibst wird dies nie von einem default überschrieben. der Erfahrene kann es immer ausschalten und sich manuell kümmern.
hast du angst vor der last? schlechte Erfahrungen? wäre ein default ein echtes Problem mit diesem Hintergrund?
wenn Du den Anfängern wirklich mit solchen Mitteln alle "Fallen" abnimmst, wird das dazu führen, dass sich niemand mehr die Mühe machen muss, das Konzept von fhem und Homematic im speziellen überhaupt verstehen zu wollen. Ich finde, solche "Fallen", die keine wirklich Fallen sind, sondern sich begründen lassen, sind unbedingt notwendig um das MItdenken beim Tun zu fördern.
Aus eigener Erfahrung (gerade bei Homematic) kann ich sagen, dass ich das meiste, das ich in den letzten Monaten zu dem Thema gelernt und verstanden (!) habe, gerade aus solchen "Fallen" resultiert. Diese Erfahrung möchte ich nicht missen.
Da ich inzwischen verstanden habe, was sich hinter vielen Fehlermeldungen verbirgt, kann ich solche Attribute inzwischen auch aktiv mit gutem Gewissen tun, weil ich genau weiss, was ich damit bewirke. Wenn solch ein Attribut aber default gesetzt ist, kann es auch die Frage auf "was tut das?" aufwerfen und zum "Spielen" animieren.
Aber mach, wie Du denkst.
---
wie wäre es ein globales oder ein HMLAN Attribut einzubauen, dass den Default wert setzt? Wenn der 1 ist, dann wird bei Autocreate jeweils auch dieses autoreadreg als attr zu den neu angelegten Devices hinzugefügt?
PS: CCU ist unterwegs, sorry dass es so lange gedauert hat
Hallo zusammen,
ich hab jetzt mal einen bzw. zwei Regler in der Fritzbox und einem RaspberryPi konfiguriert.
Die Regler selbst scheinen zu funktionieren sowohl die Temperatur ist über FHEM zu ändern als auch die geänderte Temperatur wird an FHEM übertragen.
Für die Fenstersteuerung habe ich erst mal zwei virtuelle Button mit dem Windowrec gepeert. Im Logfile von Windorec sehe ich die Button Aktionen auch aber am Regler tut sich nichts.
Hat jemand eine Idee ?
lg
Stefan
peerXref done:
x-ref list
Button_AZ_Btn =>CUL_HM_HM_CC_RT_DN_235EA6_WindowRec
Button_Bad_Btn =>CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec
CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec =>Button_Bad_Btn
CUL_HM_HM_CC_RT_DN_235EA6_WindowRec =>Button_AZ_Btn
2013-10-03_12:38:23 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trigLast: Button_Bad_Btn:200
2013-10-03_12:39:12 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trig_Button_Bad_Btn: 0
2013-10-03_12:39:12 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trigLast: Button_Bad_Btn:0
2013-10-03_12:39:25 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trig_Button_Bad_Btn: 200
2013-10-03_12:39:25 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trigLast: Button_Bad_Btn:200
2013-10-03_12:55:07 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trig_Button_Bad_Btn: 0
2013-10-03_12:55:07 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trigLast: Button_Bad_Btn:0
2013-10-03_12:55:50 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trig_Button_Bad_Btn: 200
2013-10-03_12:55:50 CUL_HM_HM_CC_RT_DN_21CEA2_WindowRec trigLast: Button_Bad_Btn:200
2013.10.03 12:53:55.525 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D2AE2A IDcnt:0004
2013.10.03 12:54:20.526 1: HMLAN_Send: HML I:K
2013.10.03 12:54:20.535 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D30FDE IDcnt:0004
2013.10.03 12:54:23.333 1: HMLAN_Parse: HML R:E235EA6 stat:0000 t:02D31AC6 d:FF r:FFAF m:CA 8610 235EA6 000000 0A8CBC0F0018
2013.10.03 12:54:23.340 1: RCV L:0F N:CA F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_235EA6 DST:broadcast 0A8CBC0F0018 (,WAKEMEUP,CFG,RPTEN)
2013.10.03 12:54:45.536 1: HMLAN_Send: HML I:K
2013.10.03 12:54:45.544 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D37193 IDcnt:0004
2013.10.03 12:54:49.929 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:02D382B1 d:FF r:FFB0 m:D6 8610 21CEA2 000000 0A8CD1100018
2013.10.03 12:54:49.937 1: RCV L:0F N:D6 F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:broadcast 0A8CD1100018 (,WAKEMEUP,CFG,RPTEN)
2013.10.03 12:55:06.626 1: HMLAN_Send: HML S:S7DF4F2C2 stat: 00 t:00000000 d:01 r:7DF4F2C2 m:45 B112 100005 235EA6
2013.10.03 12:55:06.633 1: SND L:09 N:45 F:B1 CMD:12 SRC:Button_AZ DST:CUL_HM_HM_CC_RT_DN_235EA6 (HAVE_DATA) (,WAKEUP,BURST,BIDI,RPTEN)
2013.10.03 12:55:06.635 1: HMLAN_Delay: HML 235EA6
2013.10.03 12:55:06.641 1: SND L:0C N:46 F:A4 CMD:41 SRC:Button_AZ DST:CUL_HM_HM_CC_RT_DN_235EA6 010200 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x02 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.03 12:55:06.889 2: CUL_HM set Button_AZ_Btn postEvent 0
2013.10.03 12:55:07.405 1: HMLAN_Parse: HML R:E21CEB3 stat:0000 t:02D3C5B4 d:FF r:FFBB m:D3 8610 21CEB3 000000 0A88D4100018
2013.10.03 12:55:07.425 1: HMLAN_Send: HML S:S7DF4F5E1 stat: 00 t:00000000 d:01 r:7DF4F5E1 m:47 B112 100030 21CEA2
2013.10.03 12:55:07.432 1: SND L:09 N:47 F:B1 CMD:12 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 (HAVE_DATA) (,WAKEUP,BURST,BIDI,RPTEN)
2013.10.03 12:55:07.435 1: HMLAN_Delay: HML 21CEA2
2013.10.03 12:55:07.440 1: SND L:0C N:48 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 010400 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x04 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.03 12:55:07.686 2: CUL_HM set Button_Bad_Btn postEvent 0
2013.10.03 12:55:10.726 1: HMLAN_Send: HML I:K
2013.10.03 12:55:11.310 1: HMLAN_Parse: HML R:R7DF4F2C2 stat:0008 t:00000000 d:FF r:7FFF m:45 B112 100005 235EA6
2013.10.03 12:55:11.311 1: HMLAN_Parse: HML no ACK from 235EA6
2013.10.03 12:55:11.313 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:02D3CCA7 d:FF r:FFAF m:47 8002 21CEA2 100030 00
2013.10.03 12:55:11.319 1: RCV L:0A N:47 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.03 12:55:11.326 1: HMLAN_Parse: HML R:R7DF4F5E1 stat:0008 t:00000000 d:FF r:7FFF m:47 B112 100030 21CEA2
2013.10.03 12:55:11.327 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.03 12:55:11.329 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:02D3CEA3 d:FF r:FFAF m:47 8002 21CEA2 100030 00
2013.10.03 12:55:12.326 1: HMLAN_Send: HML I:K
2013.10.03 12:55:12.343 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D3D3FC IDcnt:0004
2013.10.03 12:55:12.345 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D3DA3D IDcnt:0004
2013.10.03 12:55:38.616 1: HMLAN_Send: HML I:K
2013.10.03 12:55:38.624 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D440F3 IDcnt:0004
2013.10.03 12:55:39.746 1: HMLAN_Parse: HML R:E21B9FE stat:0000 t:02D4454E d:FF r:FFC8 m:E7 8610 21B9FE 000000 0A88C70F0018
2013.10.03 12:55:49.826 1: HMLAN_Send: HML S:S7DF59B82 stat: 00 t:00000000 d:01 r:7DF59B82 m:49 B112 100005 235EA6
2013.10.03 12:55:49.833 1: SND L:09 N:49 F:B1 CMD:12 SRC:Button_AZ DST:CUL_HM_HM_CC_RT_DN_235EA6 (HAVE_DATA) (,WAKEUP,BURST,BIDI,RPTEN)
2013.10.03 12:55:49.836 1: HMLAN_Delay: HML 235EA6
2013.10.03 12:55:49.841 1: SND L:0C N:4A F:A4 CMD:41 SRC:Button_AZ DST:CUL_HM_HM_CC_RT_DN_235EA6 0103C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x03 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.03 12:55:50.113 2: CUL_HM set Button_AZ_Btn postEvent 200
2013.10.03 12:55:50.130 1: HMLAN_Send: HML S:S7DF59CB2 stat: 00 t:00000000 d:01 r:7DF59CB2 m:4B B112 100030 21CEA2
2013.10.03 12:55:50.138 1: SND L:09 N:4B F:B1 CMD:12 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 (HAVE_DATA) (,WAKEUP,BURST,BIDI,RPTEN)
2013.10.03 12:55:50.140 1: HMLAN_Delay: HML 21CEA2
2013.10.03 12:55:50.148 1: SND L:0C N:4C F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 0105C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x05 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.03 12:55:50.417 2: CUL_HM set Button_Bad_Btn postEvent 200
2013.10.03 12:55:53.516 1: HMLAN_Parse: HML R:R7DF59B82 stat:0008 t:00000000 d:FF r:7FFF m:49 B112 100005 235EA6
2013.10.03 12:55:53.517 1: HMLAN_Parse: HML no ACK from 235EA6
2013.10.03 12:55:53.525 1: HMLAN_Parse: HML R:R7DF59CB2 stat:0008 t:00000000 d:FF r:7FFF m:4B B112 100030 21CEA2
2013.10.03 12:55:53.527 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.03 12:55:53.528 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:02D47602 d:FF r:FFB1 m:4B 8002 21CEA2 100030 00
2013.10.03 12:55:53.534 1: RCV L:0A N:4B F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.03 12:56:03.625 1: HMLAN_Send: HML I:K
2013.10.03 12:56:03.633 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D4A2A7 IDcnt:0004
2013.10.03 12:56:30.234 1: HMLAN_Send: HML I:K
2013.10.03 12:56:30.241 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D50A9B IDcnt:0004
2013.10.03 12:56:45.832 1: HMLAN_Parse: HML R:E235EA6 stat:0000 t:02D54780 d:FF r:FFB0 m:CB 8610 235EA6 000000 0A8CBB0F0018
2013.10.03 12:56:45.840 1: RCV L:0F N:CB F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_235EA6 DST:broadcast 0A8CBB0F0018 (,WAKEMEUP,CFG,RPTEN)
2013.10.03 12:56:49.918 1: HMLAN_Parse: HML R:E21CEC3 stat:0000 t:02D55774 d:FF r:FFBC m:D4 8610 21CEC3 000000 0A88BF100018
2013.10.03 12:56:55.241 1: HMLAN_Send: HML I:K
2013.10.03 12:56:55.250 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D56C4F IDcnt:0004
2013.10.03 12:56:56.931 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:02D572DB d:FF r:FFAF m:D7 8610 21CEA2 000000 0A8CD1100018
2013.10.03 12:56:56.939 1: RCV L:0F N:D7 F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:broadcast 0A8CD1100018 (,WAKEMEUP,CFG,RPTEN)
2013.10.03 12:57:20.252 1: HMLAN_Send: HML I:K
2013.10.03 12:57:20.260 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:02D5CE04 IDcnt:0004
Habe jetzt mal alle 7 tempLists in ein Thermostat auf 24:00 6.0 gesetzt...das hat 3 Versuche gedauert bis es überlal drin war.
Ich habe jeweils im Abstand von 2 Minuten gesetzt (mit at-defines) und dann die Readings gelöscht und die Register mit getConfig (auf das Device) ausgelesen.
Beim 1. mal waren 2 templists noch alt (state verified) und beim 2. mal fehlte dann noch eine, die hat er beim 3. versuch geschluckt.
Auch das setzen von anderen REgistern funktioniert MANCHMAL nicht. MISSING-ACKS habe ich dabei nicht gehabt.
Bin ich der einzige? Ich glaube ich mache mal ein kleines Script für einen Langzeittest über nacht. Immer abwechselnd was setzen und auslesen und später logs analysieren oder so...
Probleme beim HM-CC-RT-DN Reglern
Anfänger braucht Hilfe beim Einrichten ( pairing ), mir gelingt es nicht den Regler zu bedienen oder auszulesen.
Ich habe den Regler wie alle Homematic- Geräte über die Anlerntaste im Fhem angelernt und
über set CUL_HM_HM_CC_RT_DN_21CF1B pair gepairt.
Wo ist das Problem? kann mir jemand bitte einmal erklären wie das richtig mache.
Internals:
CFGFN
DEF 21CF1B
EVENTS 1
IODev HMLAN1
NAME CUL_HM_HM_CC_RT_DN_21CF1B
NR 81
STATE CMDs_pending
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_RT_DN_21CF1B_Weather
channel_02 CUL_HM_HM_CC_RT_DN_21CF1B_Climate
channel_03 CUL_HM_HM_CC_RT_DN_21CF1B_WindowRec
channel_04 CUL_HM_HM_CC_RT_DN_21CF1B_ClimRT_tr
channel_05 CUL_HM_HM_CC_RT_DN_21CF1B_ClimaTeam
channel_06 CUL_HM_HM_CC_RT_DN_21CF1B_remote
hmPairSerial KEQ0580041
lastMsg No:01 - t:00 s:21CF1B d:000000 1000954B4551303538303034315900FFFF
protCmdPend 4 CMDs_pending
protCondBurst off
protLastRcv 2013-10-03 14:54:52
protSnd 1 last_at:2013-10-03 14:55:32
protState CMDs_pending
Readings:
2013-10-03 15:05:03 Activity dead
2013-10-03 14:55:34 state CMDs_pending
cmdStack:
++A4011EA25F000000010A4B455130353830303431
++A0111EA25F21CF1B860426
++A0011EA25F21CF1B04040000000001
++A0011EA25F21CF1B04040000000007
Helper:
mId 0095
rxType 140
Prt:
awake 0
sProc 1
Role:
dev 1
Attributes:
actCycle 000:10
actStatus dead
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room CUL_HM
serialNr KEQ0580041
subType thermostat
Internals:
CFGFN
DEF 21CF1B04
NAME CUL_HM_HM_CC_RT_DN_21CF1B_ClimRT_tr
NR 89
STATE set_desired-temp 19.0
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_CC_RT_DN_21CF1B
Readings:
Helper:
Role:
chn 1
Attributes:
expert
model HM-CC-RT-DN
peerIDs
room CUL_HM
@Energy,
die kommandos sind nicht abgeabeitet (einige zumindest).
Anlernen geht über "pairForSec", dann anlerntaste.
"nur" anlerntaste legt das Device an, aber pairt es nicht
"pair" wird evtl nicht akzeptiert, da das Device noch keine Zentrale kennt.
@unimatrix
in welchem mode laufen deine RTs? ist burst an?
@Stefan
ist burst eingeschaltet?
Hallo Martin
sollte so sein.
get reg all
CUL_HM_HM_CC_RT_DN_235EA6 type:thermostat -
list:peer register :value
0: backOnTime :10 s
0: btnLock :unlock
0: burstRx :on
0: cyclicInfoMsg :on
0: cyclicInfoMsgDis :0
0: globalBtnLock :off
0: intKeyVisib :invisib
0: localResDis :off
0: lowBatLimitRT :2.1 V
0: modusBtnLock :off
0: pairCentral :0x1EA224
CUL_HM_HM_CC_RT_DN_21CEA2 type:thermostat -
list:peer register :value
0: backOnTime :10 s
0: btnLock :unlock
0: burstRx :on
0: cyclicInfoMsg :on
0: cyclicInfoMsgDis :0
0: globalBtnLock :off
0: intKeyVisib :invisib
0: localResDis :off
0: lowBatLimitRT :2.1 V
0: modusBtnLock :off
0: pairCentral :0x1EA224
lg
Stefan
nein burst ist nicht eingeschaltet. Kann man das Register eigentlich auch manuell beschreiben (geht offenbar nicht?) oder muss man mit einem FensterKontakt peeren?
Also natürlich kann ich noch nix über Langzeittests sagen aber mit Burst scheint es sauber durchzuflutschen...auch egal hab ich eben alles im Burst :) geht eh schneller dann...
Danke!
Gibt es eigentlich schon die Möglichkeit aus Fhem heraus die Urlaubs-/Partyfunktion einzuschalten?
In den Registern kann ich da nichts Entsprechendes finden.
burstRx kann man auch ohne fensterkontakt setzen. Beim peeren eines fenster-kontakts wird es wohl automatisch gesetzt, kann dann aber auch wieder gelöscht werden.
Achtung: wann ein device (auch TC) register aendert(z.B. beim peeren...) habe ich nie getestet. nach meinen Erfahrungen kann man es aber im nachhinein immer aendern.
uh - habe ich den rt im command-ref vergessen....
siehe/probiere mode
mode auto
mode boost
mode comfort
mode lower
mode manu <temp>
mode party <temp> <from-time> <from-date> <to-time> <to-date>
Beispiel:
set <dev_Clima> party 10 03.8.13 11:30 5.8.13 12:00
Gruss Martin
ps: sollte ich die Kommandos aendern um die FHEM pull downs zu nutzen?
mode [auto|boost|comfort|lower] (pull-down)
modeManu <temp> (slider)
modeParty <temp> <from-time> <from-date> <to-time> <to-date> (manuelle eingabe)
gefällt mir eigentlich bessen - einfacher zu "klicken"
Gruss martin
noch was anderes...ist das richtig so? beim setzen kommt zunächst mal (inform on) eine falsche templist...weiter unten dann aber offenbar doch richtig. vll nur ein Anzeigefehler?
fhem> set temp_merle_Climate tempListFri 12:00 6.0 19:00 21.0 24:00 6.0
CUL_HM temp_merle_Climate tempList_State: set
CUL_HM temp_merle_Climate tempListSat: 07:00 6.0 18:00 20.0 19:00 6.0 20:00 6.0 24:00 6.0
CUL_HM temp_merle_Climate tempListSun: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListMon: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListTue: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListWed: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListThu: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListFri: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle displayMode: temp-hum
CUL_HM temp_merle displayTemp: actual
CUL_HM temp_merle controlMode: auto
CUL_HM temp_merle decalcDay: Sat
CUL_HM temp_merle displayTempUnit: celsius
CUL_HM temp_merle day-temp: 20 C
CUL_HM temp_merle night-temp: 6 C
CUL_HM temp_merle party-temp: 20 C
[...]
CUL_HM temp_merle_Climate tempList_State: verified
CUL_HM temp_merle_Climate tempListSat: 07:00 6.0 18:00 20.0 19:00 6.0 20:00 6.0 24:00 6.0
CUL_HM temp_merle_Climate tempListSun: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListMon: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListTue: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListWed: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListThu: 06:00 17.0 12:00 21.0 23:00 21.0 24:00 17.0
CUL_HM temp_merle_Climate tempListFri: 12:00 6.0 19:00 21.0 24:00 6.0
das ist ok so. Solange der Status noch auf "set" steht, ist die Liste noch nicht komplett verarbeitet. Das ist erst beim Status "verified" der Fall. Dann sollte die Liste den eingegeben Werten entsprechen.
so folgende updates (4003):
templist hat nun auch ein "set_" in jeder Zeile, wenn es nicht verified ist
das Kommando "mode" ist aufgespaltet in
"mode [auto|boost|comfort|lower]"
"mode_party temp start_date start_time endDate endTime"
"mode_manu temp"
das Reading modeSet wird nicht mehr genutzt/upgedated. Löschen muss man selbst
autoReadReg wird per default auf 4 gesetzt (device only)
minor changes in registern
*grmpf*
???
Hallo Martin
hast Du noch irgendwelche Ideen für mein Problem ?
lg
Stefan
Hallo Stefan,
habe es gerade noch einmal getested - und siehe da, es funktionierte nicht :-(
in deinem Fall ist zwar ein seltsames Problem mit der aufwachen gewesen - das sollte mit burstRx zu tun haben.
aber evtl probierst du Version 4005 - da wird der RT "schöner" aufgeweckt. jetzt funktioniert es bei mir.
Gruss Martin
ps. hatte ausversehen alle List0 register nicht mehr angezeigt (auch burstRx). ist in 4007 wieder sichtbar
Hallo Martin,
BTW: kannst Du diese Änderungen auch für den TC implementieren?
Das "mode [auto|boost|comfort|lower]" ist ja entsprechend für den TC drin, die anderen beiden Kommandos kann ich nicht finden.
Danke Uwe.
insgesamt gibts jetzt offenbar Unterschiede zwischen TC und dem DN. also beim TC heisst das Register z.b. day-temp und beim ON tempComfort.
Natürlich nicht so schlimm aber wenn man es geräteunabhängig machen will, vll eine Schönheitsreperatur.
Guten Morgen,
vielen Dank an Martin und an alle die die Sache vorantreiben für die tolle Arbeit. Bei mir funktioniert momentan alles zufriedenstellend.
Ich habe zum remote-channel noch zwei Fragen:
1. Welche Funktionen können mit einer Fernbedienung ausgelöst werden?
2. Wie programmiert man die Funktionen?
Das große Problem bei dem RT ist, dass man das Display je nach Einbausituation nicht sehen kann. Insofern wäre eine "Fernsteuerung" sehr vorteilhaft.
Gruß
Burchard
Hi,
jetzt ist es höchste Zeit die schönheitsreparaturen und alignments zu machen, habt ihr vollkommen recht. Mal sehen was ich vom TC her kenne
ok sind
desired-temp
unterschiede:
day-temp :regSet tempComfort
night-temp :regSet tempLowering
party-temp :mode-party
partyMode :mode-party, andere Parameter
controlMode [manual|auto|central|party] :mode [auto|boost|comfort|lower]
:mode-manu mode-party
decalcDay :regSet decalcWeekday, regSet decalcTime
Was kann man machen:
1)+++ TC day-temp,night-temp,party-temp
- kommandos sollten gelöscht werden. Es sind eigentlich register und werden durch regSet bereits abgedeckt.
2)+++ RT tempComfort, tempLowering
- register kann man nach day-temp und night-temp umbenennen.
3)+++ RT mode
a)- kann man nach controlMode unbenennen
b)- comfort|lower sollte man nach day und night unbenennen, um die relation zu den Registern zu wahren (siehe 2)
4)+++ TC decalcDay
- sollte gelöscht werden. Ist ein Register und so schon vorhanden
nicht wirklich alignen kann ich
party und manu: die Parameter sind unterschiedlich.
Meinungen?
@Burchard
mache ein
get <rt_remote> regList. da sind die optionen zu sehen. Ich haben den Text noch etwas geaendert:
no,tempOnly,auto,autoAndTemp,manuAndTemp,boost,toggle
long und short sind getrennt.
Es ist immer etwas "gefährlich" Optionen die es schon lange gibt zu entfernen, womöglich liegen die in irgendwelchen Scripten von Usern die hier nicht aktiv mitlesen und die an ihrem System auch nicht weiter basteln. Nach einem Update funktionieren sie dann nicht mehr. Ggf. macht es Sinn, etwas aus Kompatibilitätsgründen zusätzlich drinzulassen. Ich hatte erst kürzlich Spaß mit meinem Tastern (also die reinen Sender)...die hatte ich noch als einziges Device drin, was dann Events für Btn1 und Btn2 on und off kreiert hat, und irgendwie hab ich sie jetzt als Device mit 4 Channels drin, die aber alle etwas anders heissen (1-4). Das neue ist bestimmt besser, aber meine alten Sachen haben halt erstmal nicht funktioniert.
Was anderes ist mir gerade noch "passiert". Ich wollte einen Fensterkontakt bei einem DN als Peer eintragen (und umgekehrt) was auch geklappt hat, allerdings habe ich jetzt im DN zusätzlich dazu einen ganz anderen Fensterkontakt eingetragen, den ich mit Sicherheit nirgends eingegeben habe.
ansonsten muss ich auch sagen, das ist schon ein tolles Ergebnis. Überhaupt insgesamt, was man mit CULHM inzwischen alles herausholenkann - das ist jedenfalls mehr als auf normalem Weg mit CCU + Co ginge. Ich war ja damals selbst dabei als man versucht hat mal ansatzweise das Protokoll zu verstehen, als FHEM eigentlich eine FS20-Software war...und nun ...also das ist eine ganz tolle Sache!
(sogar mein heute selbstgebauter MP3-Gong läuft..wenn auch leise. Aber dafür kann ja die Implementierung hier nix :) )
klar ist es gefährlich, vorhandene kommandos zu aendern/löschen. Wenn man aufräumen will muss man sich aber vonetwas trennen können
Die vorgeschlagenen sind eher wenig "operationell" und daher eher nicht in scripten drin. Ich halte es für weniger-kritisch und daher machar. Aber wenn es dringent gewünscht wird, kann man es lassen.
die Bedienung der remotes ohne channel also nur mit buttons sollte noch funktionieren, auch wenn ich es nicht mehr teste. Es gibt keine Meldungen, dass hier einer Probleme hat(te). Die Channels werden angelegt, sobald du anlernen drückst. Aber nutzen musst du sie nicht (wie gesagt, nicht getestet!)
Noch einmal der Aufruf zur Durchsicht: wenn wir jetzt "alignen" was konkret haltet ihr für notwendig, was kann weg, was muss geaendert werden - auch im Bezug auf heating-control-systems jeder art u.ä.
Ich würde es gerne abschließen.
das mit den 2 fensterkontakten verstehe ich nicht. kann ich nicht nachvollziehen. Ich hatte einen eingetragen - war auch einer drin. hast du daten dazu,die man auswerten kann? wiesieht die HMID aus? könnte es ein "verrutschender Daten sein?
Gruss Martin
Hallo Martin
danke für die Mühe jetzt schaut es wieder besser aus mit den Fensterkontakten.
Das einzige was mir noch aufgefallen ist. Im WindowRec wird kein Status angezeigt da steht immer die ??? drin.
LG
Stefan
das mit dem Fensterkontakt konnte ich bisher nicht reproduzieren. Sollte es nochmal auftreten sammle ich entsprechende Daten. Durch ein simples unset konnte man es ja wieder entfernen.
Mich stört es auch eh nicht, ich weise ja nicht ständig sowas zu, aber es ist mir eben aufgefallen.
Auch das mit den remotes - kein Problem für mich. Habs alles auf channel umgestellt, ist viel sauberer. Ich glaube das tauchte bei einem Baterriewechsel auf dass die dann automatisch angelegt wurden, ggf. bin ich auch auf den Anlernknopf dabei gekommen.
VG!
Hallo,
nachdem meine beiden Geräte jetzt eigentlich gut funktioniert haben, habe ich gestern entdeckt, dass die templisten sich verändert haben. Kann das durch ein update geschehen sein? Selber habe ich daran zumindest bewusst nichts geändert.
Edit: Die zweite Frage hat sich erledigt.
schöne Grüße
Jo
Hallo, ich bin für die "Schönheitreparaturen" und die Vereinheitlichung der Bedienung der HM-Geräte - soweit möglich und sinnvoll.
Die Änderungen werden ja in der Updateliste genannt (wenn Martin dies hinterlegt - aber das macht er ja). Wenn man diese liest und nicht nur "blind" update anklickt, dann fallen diese auch auf und man kann entsprechend reagieren.
Gleiche Funktionen sollten auch gleich bedienbar sein - so ist ein Umstieg von einem System auf das andere oder ein Mischbetrieb ohne (große) Änderungen im eigenen Code möglich.
Danke und schönes WE,
Uwe
Gibt es eigentlich einen Grund dafür, dass ich den Partymode nur zu halben und ganzen Stunden schalten kann?
Hilfe, Hilfe,
ich habe heuet das neuste update eingespielt und bekomme immer Probleme mit dem HMLAN. in der Logdatei steht:
2013.10.05 13:02:17 2: CUL_HM set 1S.BZ.HeizungsT.00 getSerial
2013.10.05 13:02:17 2: CUL_HM set 1S.BZ.HeizungsT.00 getConfig
2013.10.05 13:02:29 2: CUL_HM set 1S.SZL.HeizungsT.00 getSerial
2013.10.05 13:02:29 2: CUL_HM set 1S.SZL.HeizungsT.00 getConfig
2013.10.05 13:02:41 2: CUL_HM set 1S.SZZ.HeizungsT.00 getSerial
2013.10.05 13:02:41 2: CUL_HM set 1S.SZZ.HeizungsT.00 getConfig
2013.10.05 13:02:53 2: CUL_HM set 1S.SZZ.Temperatur.00 getSerial
2013.10.05 13:02:53 2: CUL_HM set 1S.SZZ.Temperatur.00 getConfig
2013.10.05 13:02:53 2: CUL_HM set 1S.SZZ.Temperatur.00 statusRequest
2013.10.05 13:03:04 2: CUL_HM set TH.Licht.00 on-for-timer 180
2013.10.05 13:03:04 2: CUL_HM set TH.Licht.00 on-for-timer 180
2013.10.05 13:03:04 2: CUL_HM set TH.Licht.00 on-for-timer 180
2013.10.05 13:03:05 2: CUL_HM set 1S.TH.Bewegungsmelder.00 getSerial
2013.10.05 13:03:05 2: CUL_HM set 1S.TH.Bewegungsmelder.00 getConfig
2013.10.05 13:03:05 2: CUL_HM set 1S.TH.Bewegungsmelder.00 statusRequest
2013.10.05 13:03:14 3: Device 1S.BZ.HeizungsT.00 added to ActionDetector with 000:10 time
2013.10.05 13:03:17 2: CUL_HM set 1S.TH.HeizungsT.00 getSerial
2013.10.05 13:03:17 2: CUL_HM set 1S.TH.HeizungsT.00 getConfig
2013.10.05 13:03:29 2: CUL_HM set AU.Bewegungsmelder.01 getSerial
2013.10.05 13:03:29 2: CUL_HM set AU.Bewegungsmelder.01 getConfig
2013.10.05 13:03:29 2: CUL_HM set AU.Bewegungsmelder.01 statusRequest
2013.10.05 13:03:41 2: CUL_HM set AU.Bewegungsmelder.02 getSerial
2013.10.05 13:03:41 2: CUL_HM set AU.Bewegungsmelder.02 getConfig
2013.10.05 13:03:41 2: CUL_HM set AU.Bewegungsmelder.02 statusRequest
2013.10.05 13:03:53 2: CUL_HM set AU.Licht.01 getSerial
2013.10.05 13:03:53 2: CUL_HM set AU.Licht.01 getConfig
2013.10.05 13:03:53 2: CUL_HM set AU.Licht.01 statusRequest
2013.10.05 13:04:06 2: CUL_HM set AU.Temperatur.00 getSerial
2013.10.05 13:04:06 2: CUL_HM set AU.Temperatur.00 getConfig
2013.10.05 13:04:06 2: CUL_HM set AU.Temperatur.00 statusRequest
...
und endet dann mit
2013.10.05 13:06:18 2: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2013.10.05 13:06:29 2: CUL_HM set EcoOnOff getSerial
2013.10.05 13:06:29 2: CUL_HM set EcoOnOff getConfig
2013.10.05 13:06:41 2: CUL_HM set Fenster1 getSerial
...
2013.10.05 13:07:18 2: CUL_HM set Statusanzeige getConfig
2013.10.05 13:07:18 2: CUL_HM set Statusanzeige statusRequest
2013.10.05 13:07:23 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
Was läuft hier schief. Fhem versucht scheinbar von allen Devices die Konfiguration und Status zu erfragen.
Wer kann mir helfen?
Danke
Burchard
Hallo,
ich habe noch mal meine cfg-Datei durchgeschaut und festgestellt, dass für jedes!! Device folgender Eintrag vorhanden ist.
attr AU.Licht.01 autoReadReg 4_reqStatus
Diesen Eintrag habe ich nur für die Thermostaten eingetragen. Wie kann es passieren, dass plötzlich Einträge für ALLE Devices vorhanden sind?
Gruß
Burchard
@Stefan
der RT meldet, wie der TC, NICHT, wenn das Fenser offen erkannt wird. Schade eigentlich. Wenn du einen externen sender nutzt sollte "trigger" gesetzt werden. ich werde - wie beim TC - einbauen, dass
attr <> stateFormat last:trigLast
gesetzt wird.
@unimatrix
schon ok. ich will ja feedback - muss aber eine sinnvolle und akzeptable Entscheidung treffen. Daher die Anregung zur Diskussion.
@jo
die templist sollte sich nicht aendern. es könnte einen reset gegeben haben (warum auch immer). dann sollte die liste auf default stehen. Alles andere kann ich mir nicht erklären.
Bemerkung meinerseits:
ich habe mein "team" aufgelöst, da es nicht ordentlich funktioniert
- kommunikation funktionierte nur "einseitig", ein RT sendet einfach keine daten
- beim "internen FensterOffenDetekt" sendet der betroffene die falsche temperatur - absolut unbrauchbar
mit der Folge, dass der, welcher sendete erkannt hat, dass sein "peer" nicht mehr reagiert. daher wurde ein communikationsproblem gemeldet. macht auch keinen sinn, da der peer ja schon gelöscht war. ist der 2. definitive Bug in der FW. rücksetzen konnte ich es nur durch batterie-entfernen.
(trotz der beiden Bugs bin ich zufrieden mit den Teilen)
Hallo,
mein Team funktioniert einwandfrei. Ich habe zwei RTs einen Temperatursensor und zwei Fensterkontakte. Es funktioniert alles wunderbar, Manchmal gibt es allerdings Übertragungschwierigkeiten mit der TempLisr.
Ich habe aber momentan das etwas weiter oben beschriebene Problem. !!!
Wie kommt es, dass fhem für jedes HMDevice ein getConfig, getSerial und statusRequest sendet. habe ich das irgendwo global eingeschaltet ohne es zu wissen???? Hängt das mit dem Update zusammen oder war es Zufall?
Gruß
Burchard
Zitat von: martinp876 schrieb am Sa, 05 Oktober 2013 13:30@jo
die templist sollte sich nicht aendern. es könnte einen reset gegeben haben (warum auch immer). dann sollte die liste auf default stehen. Alles andere kann ich mir nicht erklären.
Ok, das könnte passen. Irgendwie will die Liste bei mir aber immer noch nicht so richtig. Wenn ich alles auf einmal übertrage, bekomme ich irgendwann ein "verified" bei tempList_State, aber die Werte für Freitag, Samstag und Sonntag sind trotzdem falsch. Jetzt versuche ich gerade mal wieder, die Tage einzeln zu schicken. Müsste dann der tempList_State nicht unmittelbar auf "set" wechseln (habe auch ein "set xxx getConfig" geschickt)? Oder gibt es einen Trick, die Werte ans Gerät zu schicken (manuell oder automatisch), so dass sie auch alle ankommen?
schöne Grüße
Jo
@Buri
gut, dass es klappt. sicher müsste ich nur mehrfach das peeren probieren.
bei sauber gepeerten fensterkontakten (mit jeden RT) sollte es auch keine Probleme geben - ich denke, da wird die desired-temp auch nicht ausgetauscht. das passiert wohl nur bei internen aenderngen.
=> wird die temp auch übertragen, wenn du nur einen vn der Zentrale aus aenderst?
da getConfig liegt am attribut
autoReadReg
kannst du, wenn nicht gewünscht, auf 0 setzen. ansonsten wird der default (=4) gesetzt. Das attribut wird nur im Device gesetzt.
@jo,
zum einen: kannst du einmal rohmessages aufzeichnen? dann kann ich noch einmal durchsehen.
2) verified setze ich, wenn die Werte,die in den Readings angezeigt werden auch "frisch" aus den registern gelesen wurden. "set" kommt wenn nach dem letzten lesen eine Änderung vorgenommen wurde.
nach den setzen sollte der zustand sofort auf set gehen. Verified kommt, sobald die register eingelesen und abgeglichen sind
Achtung: es findet kein vergleich statt. es werden IMMER die werte ausgegeben, die im Register stehen.
Ob die Übertragung funktioniert hat steht in den "Proto" variablen.
Hallo,,
Noch ein kurzer Erfahrungsbericht zum peeren. Es kommt auf die richtige reihenfolge beim anlernen an!
Erst wenn nan den Sensor zuerst anlernt ist es ok. ansonsten taucht er zwar in der peer liste auf funzt aber nicht!
Gruß
Burchard
Zitat von: martinp876 schrieb am Sa, 05 Oktober 2013 14:49@jo,
zum einen: kannst du einmal rohmessages aufzeichnen? dann kann ich noch einmal durchsehen.
2) verified setze ich, wenn die Werte,die in den Readings angezeigt werden auch "frisch" aus den registern gelesen wurden. "set" kommt wenn nach dem letzten lesen eine Änderung vorgenommen wurde.
nach den setzen sollte der zustand sofort auf set gehen. Verified kommt, sobald die register eingelesen und abgeglichen sind
Achtung: es findet kein vergleich statt. es werden IMMER die werte ausgegeben, die im Register stehen.
Ob die Übertragung funktioniert hat steht in den "Proto" variablen.
Danke erstmal. Es ist wie verhext. Kaum setze ich
attr global verbose 1
attr mseclog 1
attr HMLAN1 loglevel 1scheint es zu funktionieren. Zumindest scheinen die Werte jetzt in der Warteschleife zu sein.
Der Auszug sieht so aus:
2013.10.05 17:57:08.289 1: HMLAN_Send: HMLAN1 I:K
2013.10.05 17:57:08.307 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:4346E8CC IDcnt:0014
2013.10.05 17:57:33.303 1: HMLAN_Send: HMLAN1 I:K
2013.10.05 17:57:33.310 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43474A86 IDcnt:0014
Use of uninitialized value in hash element at ./FHEM/01_FHEMWEB.pm line 1088.
Use of uninitialized value in split at ./FHEM/01_FHEMWEB.pm line 1093.
2013.10.05 17:57:58.711 1: HMLAN_Send: HMLAN1 I:K
2013.10.05 17:57:58.722 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:4347ADC9 IDcnt:0014
2013.10.05 17:58:13.432 1: HMLAN_Parse: HMLAN1 R:E21CFF2 stat:0000 t:4347E741 d:FF r:FFBA m:6D 8610 21CFF2 000000 0A88DE100019
2013.10.05 17:58:13.534 1: HMLAN_Send: HMLAN1 S:S89572D08 stat: 00 t:00000000 d:01 r:89572D08 m:7E A112 123ABC 21CFF2
2013.10.05 17:58:13.727 1: HMLAN_Parse: HMLAN1 R:R89572D08 stat:0001 t:4347E84B d:FF r:FFB9 m:7E 8002 21CFF2 123ABC 00
2013.10.05 17:58:13.737 1: HMLAN_Send: HMLAN1 S:S89572E2A stat: 00 t:00000000 d:01 r:89572E2A m:7F A001 123ABC 21CFF2 00050000000007
2013.10.05 17:58:14.095 1: HMLAN_Parse: HMLAN1 R:R89572E2A stat:0001 t:4347E9DE d:FF r:FFBA m:7F 8002 21CFF2 123ABC 00
2013.10.05 17:58:14.108 1: HMLAN_Send: HMLAN1 S:S89572F9C stat: 00 t:00000000 d:01 r:89572F9C m:80 A001 123ABC 21CFF2 00081444154E1654176C184419FC1A55
2013.10.05 17:58:14.498 1: HMLAN_Parse: HMLAN1 R:R89572F9C stat:0001 t:4347EB71 d:FF r:FFBA m:80 8002 21CFF2 123ABC 00
2013.10.05 17:58:14.509 1: HMLAN_Send: HMLAN1 S:S8957312D stat: 00 t:00000000 d:01 r:8957312D m:81 A001 123ABC 21CFF2 00081B141C451D20
2013.10.05 17:58:14.901 1: HMLAN_Parse: HMLAN1 R:R8957312D stat:0001 t:4347ED04 d:FF r:FFBA m:81 8002 21CFF2 123ABC 00
2013.10.05 17:58:14.922 1: HMLAN_Send: HMLAN1 S:S895732CB stat: 00 t:00000000 d:01 r:895732CB m:82 A001 123ABC 21CFF2 0006
2013.10.05 17:58:15.304 1: HMLAN_Parse: HMLAN1 R:R895732CB stat:0001 t:4347EE97 d:FF r:FFBA m:82 8002 21CFF2 123ABC 00
2013.10.05 17:58:15.325 1: HMLAN_Send: HMLAN1 S:+21CFF2,00,01,
2013.10.05 17:58:15.326 1: HMLAN_Send: HMLAN1 S:S8957345E stat: 00 t:00000000 d:01 r:8957345E m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:16.154 1: HMLAN_Parse: HMLAN1 R:R8957345E stat:0008 t:00000000 d:FF r:7FFF m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:16.155 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
2013.10.05 17:58:19.704 1: HMLAN_Send: HMLAN1 S:S89574578 stat: 00 t:00000000 d:01 r:89574578 m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:20.310 1: HMLAN_Parse: HMLAN1 R:R89574578 stat:0008 t:00000000 d:FF r:7FFF m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:20.311 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
2013.10.05 17:58:23.724 1: HMLAN_Send: HMLAN1 I:K
2013.10.05 17:58:23.741 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43480F8B IDcnt:0014
2013.10.05 17:58:25.669 1: HMLAN_Send: HMLAN1 S:S89575CC5 stat: 00 t:00000000 d:01 r:89575CC5 m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:26.275 1: HMLAN_Parse: HMLAN1 R:R89575CC5 stat:0008 t:00000000 d:FF r:7FFF m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:26.276 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
2013.10.05 17:58:35.997 1: HMLAN_Send: HMLAN1 S:S8957851E stat: 00 t:00000000 d:01 r:8957851E m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:40.228 1: HMLAN_Parse: HMLAN1 R:R8957851E stat:0008 t:00000000 d:FF r:7FFF m:83 A001 123ABC 21CFF2 04040000000001
2013.10.05 17:58:40.229 1: HMLAN_Parse: HMLAN1 no ACK from 21CFF2
Use of uninitialized value in hash element at ./FHEM/01_FHEMWEB.pm line 1088.
Use of uninitialized value in split at ./FHEM/01_FHEMWEB.pm line 1093.
2013.10.05 17:58:50.777 1: HMLAN_Send: HMLAN1 I:K
2013.10.05 17:58:50.784 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43487932 IDcnt:0014
2013.10.05 17:59:10.356 1: HMLAN_Parse: HMLAN1 R:E21CFB0 stat:0000 t:4348C5A3 d:FF r:FFCD m:4E 8610 21CFB0 000000 0A88D5100021
2013.10.05 17:59:15.791 1: HMLAN_Send: HMLAN1 I:K
2013.10.05 17:59:15.799 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:4348DAEC IDcnt:0014
2013.10.05 17:59:35.851 1: HMLAN_Send: HMLAN1 S:S89586EEB stat: 00 t:00000000 d:01 r:89586EEB m:84 B112 123ABC 21CFB0
2013.10.05 17:59:40.712 1: HMLAN_Parse: HMLAN1 R:R89586EEB stat:0008 t:00000000 d:FF r:7FFF m:84 B112 123ABC 21CFB0
2013.10.05 17:59:40.713 1: HMLAN_Parse: HMLAN1 no ACK from 21CFB0
2013.10.05 17:59:40.801 1: HMLAN_Send: HMLAN1 I:K
2013.10.05 17:59:40.808 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314688 d:1C69A4 O:123ABC t:43493CA1 IDcnt:0014
Use of uninitialized value in hash element at ./FHEM/01_FHEMWEB.pm line 1088.
Use of uninitialized value in split at ./FHEM/01_FHEMWEB.pm line 1093.
schöne Grüße
Jo
Hi,
ok - ich denke es ist klar. Problem ist, dass der RT nach dem Schreiben ein päuschen braucht. da sind wir (normales senden) zu schnell. Das Bringt mich in ein (kleines) Dilemma.
ich kann warten. wenn du burst nutzt (bei dir nicht) dann werden die Kommandos noch abgearbeitet. wenn du wakeup nutzt (dein mode) wird der RT wahrscheinlich einschlafen - und man muss zum nächsten Aufwachen Warten. bei 7 Tagen sind dies 7*3min = 21 min dauer (wenn alles gut läuft).
ich habe noch einige Ideen im Kopf, wie man es machen könnte... aber das wird alles recht kompliziert und der User wird am Ende keinen Überblick mehr haben, das Verständnis verlieren. Mal sehen, was mir einfällt. In HM habe ich eine Variante mit templates...
mal nachdenken.
das ist jedenfalls der Grund - RT blocktiert nach dem (beim) Schreiben und FHEM timed aus.
p.s. noch einmal nachgetestet. Wenn man den RT in den burst mode versetzt funktioniert es ohne Probleme - jedenfalls bei mir.
Gruss Martin
Hallo liebe Fachleute,
ich habe seit heute Mittag weiterhin massive Probleme. Entweder liegt es an den neuen Dateien, die ich heute Mittag installiert habe, oder an den RTs oder beides im Zusammenspiel.
Nachdem die RTs im Wohnzimmer einwandfrei funktionierten, habe ich alle RTs im Haus mit fhem gepairt. Seit dem Update hängt sich mein HMLAN regelmäßig auf und es geht dann nichts mehr.
Ich habe für alle Devices
attr Device autoReadReg 0_reqStatus gesetzt und nur bei dem RT, dessen tempList ich ändern will
attr Device autoReadReg 4_reqStatus
Trotzdem treten nach dem Senden eines set Templist weiterhin Fehler auf.
u.a steht folgende Fehlermeldung im logfile:
2013.10.05 21:13:51 1: 192.168.178.48:1000 disconnected, waiting to reappear
2013.10.05 21:13:51 1: 192.168.178.48:1000 reappeared (HMLAN1)
2013.10.05 21:13:51 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.05 21:13:51 2: HMLAN_Parse: HMLAN1 new condition ok
oder es tritt ein Overload auf.
Hat jemand eine Idee oder ähnliche Probleme. Ich werde langsam etwas frustiert.
Im derzeitigen Stand kann man keine Templisten an die RT senden?!
Allen vielen Dank für die Unterstützung
Burchard
also seit dem autoreadreg 4 überall habe ich auch beim Neustarten von FHEM eine ganze Zeit ständig Overloads bis es sich dann beruhigt.
Habe hmLanQlen = 3_min und wdTimer=25. K.a. ob das noch tunebar ist. Habe ungefähr 30 Devices, dessen Config auslesbar ist.
ich finde das Feature mit dem autoreadreg prinzipiell gut. Man hat immer alle aktuellen Werte zur Hand und muss manuell nix machen.
GGf. wäre aber ein Tuning beim Timing möglich. Z.B. gerade wenn ich an meinen Scripten bastle, muss ich ständig FHEM neu starten (um die neuen Utils-Dateien zu laden) und dann kutz testen und dann wieder neu starten. Vll. sollte man nach dem Start das Auslesen der COnfigs nochmal verzögern? Außerdem vll den Abstand zwischen dem Auslesen aller Devices. Also k.a. nur ein device pro Minute. Dauert dann bis alles durch ist - aber das sollte normalerweise ja nicht stören...
Aber vll liegts bei mir auch an anderen Gründen, k.a. Wenn ich dasautoreadreg aber überall abschalte, dann habe ich keine Overloads mehr.
HI,
der abstand zwischen devices beim lesen ist aktuell 15 sec. eine kurze einschaltverzögeung gibt es auch.
beim testen von scripts kannst du auch ein ein reload deines geaenderten moduls ins auge fassen. geht deutlich schneller und die register werden nicht neu geladen.
reload myutil.pm
@Burchard,
ich kann schon templisten senden - ohne Probleme.
Ein Problem stellt tatsächlich ein wenn man mehrere templisten an ein device senden will UND burstRx=off ist. da der RT nach schreiben immer eine EEPROM-gedenk-minute einlegt timed der "wakeup" aus und das schreiben der 2. Liste wird nicht funktionieren. da muss ich mir noch etwas einfallen lassen. Sonstige Probleme habe ich nicht - bitte logs schicken, wenn du welche hast.
Ich schiebe gerade noch eine kleien änderung nach, damit comfort und lower jetzt day und night heisen (passend zum TC und den Symbolen am LCD display
Gruss Martin
Hallo,
allen leidenden am temp-list setzen - es gibt jetzt einen "compress mode" => V 4013.
man kann die Daten vorbereiten mit prep
mit exec werden dann alle Daten geschrieben. man hat also nur noch eine atomare msg-sequenz
set <devClima> tempListSav prep 07:00 14.0 09:00 16.0 17:00 18.0 22:00 19.0 24:00 14.0
set <devClima> tempListTue prep 07:00 14.0 09:00 16.0 17:00 18.0 22:00 19.0 24:00 14.0
set <devClima> tempListWed exec 07:00 14.0 09:00 16.0 17:00 18.0 22:00 19.5 24:00 14.0
- ohne parameter werden nur die gelieferten daten im kommando geshrieben
- nach lesen des registers (getConfig) sind alle "wartenden" Daten wieder verloren.
Mit dieser Methode sollten auch die "wakeup" freunde erfolge erzielen können.
Achtung: nach dem schreiben macht der RT immer noch ein schläfchen - folgenden kommandos können also ggf abgebrochen/nicht beantwortet werden
Gruss Martin
Und wieder eine Anfängerfrage ich möchte einen Fensterkontakt mit den HM-CC-RT-DN über Fhem peeren dazu habe ich set WZ_Fenster_links peerChan 0 WZ__WindowRec single
Eingetragen, das scheint grundsätzlich auch funktioniert zu haben im _WindowRec kann man den Fensterkontakt auch sehen.
Nur ob nun das Fenster offen oder zu ist macht das am Regler keinen Unterschied, was habe ich vergessen? was muss ich noch konfigurieren?
Internals:
DEF 21CF1B03
NAME WZ__WindowRec
NR 80
STATE last:trigLast
TYPE CUL_HM
chanNo 03
device WZ_Thermostat
peerList WZ_Fenster_links,
Readings:
2013-10-06 16:53:48 R-sign off
2013-10-06 17:01:41 peerList WZ_Fenster_links,
Helper:
peerIDsRaw ,219C7001,00000000
Prt:
awake 1
Role:
chn 1
Shadowreg:
Attributes:
expert 1
model HM-CC-RT-DN
peerIDs 00000000,219C7001,
room CUL_HM
Gruß
energy
Zitat von: betateilchen schrieb am Mo, 30 September 2013 13:58Zitat von: unimatrix schrieb am Mo, 30 September 2013 12:57Der Auto-Mode macht ja noch weniger Sinn, dann greift ja womöglich kurz nach dem Setzen das Automatikprogramm des Ventils.
Automatikprogramm abschalten...
Hallo Leutz :)
nachdem ich mir nun auch so ein Teil zugelegt habe und es auch eingerichtet bekommen habe, ergeben sich natürlich für einen blutigen Neuling auf diesem Gebiet ein Haufen Fragen...
Die Templisten sind programmiert und auch verified. Mein Problem ist, dass am Thermostat nichts geändert wird, d.h. weder im Manu noch im Auto-Modus. Ich liege doch richtig, wenn ich annehme, dass der HMLAN nur regeln kann, wenn der Thermostat in Auto steht? Und jetzt zu dem Zitat oben...wie schalte ich denn die interne Programmierung aus, damit die Steuerung durch FHEM erfolgen kann? Wahrscheinlich ne sehr dumme Frage ;) aber ich find nirgends eine Einstellung dazu und bitte mal um Schützenhilfe...
Die zweite Frage ist, wie ich im WEBGUI mobile ein Kontrollfeld bekomme, damit ich über FHEMMobile auch steuern kann?
Großes Danke schon mal vorweg, vor allem an all die Leute hier, die sich ständig die zeit um die Ohren hauen, damit der ganze Krams auch funktioniert :)
Gruß Dusti
Hallo energy,
du hast das Kommando auch für den SC abgesetzt - aber der SZ schläft gerne und viel. du musst noch anlernen drücken, damit er aufwacht und wir senden können.
nächster Schritt ist, dass der RT auch im bust mode ist. Schaue einmal nach, dass burstRx=on gesetzt ist.
und 3. Schritt sind, dass im SC peerneedsburst gesetzt ist. dass sollte eigentlich automatisch passieren, kannst du aber prüfen.
Gruss Martin
Hallo Martin
ich hatte heute sehr viel Overload mit reconnects auf dem HMLan. Kann man da was dagegen tun außer zu warten. Was ist eigentlich die Ursache, liegt die im HMLan oder im FHEM? Kannst Du da noch einen Schutz einbauen ?
Version : 4010, 4005, HM aktuell auf der Fritzbox
lg
Stefan
hm - scheint vermehrt aufzutreten.
ein autoReadReg konnte etwas dazu beitragen - aber nach dem booten spätestens sollte es geklärt sein. Und ständig aenderungen machst du ja nicht - oder?
Evtl doch einmal einen längernlog schicken
Gruss Martin
Hallo Martin,
<du hast das Kommando auch für den SC abgesetzt - aber der SZ schläft gerne und viel. du musst noch anlernen drücken, damit er aufwacht und wir senden können.
was ist ein SZ ?
<nächster Schritt ist, dass der RT auch im bust mode ist. Schaue einmal nach, dass burstRx=on gesetzt ist.
ist angeschaltet !
<und 3. Schritt sind, dass im SC peerneedsburst gesetzt ist. dass sollte eigentlich automatisch passieren, kannst du aber prüfen.
ist auch an !
ich habe jetzt immer bei den Fensterkontakt ein MISSING ACK bei fenster offen nach den peeren ?
Gruß
energy
Zitat von: martinp876 schrieb am So, 06 Oktober 2013 18:58hm - scheint vermehrt aufzutreten.
ein autoReadReg konnte etwas dazu beitragen - aber nach dem booten spätestens sollte es geklärt sein. Und ständig aenderungen machst du ja nicht - oder?
Jedes Gerät macht
CUL_HM set Steckdose1 getSerial
CUL_HM set Steckdose1 getConfig
CUL_HM set Steckdose1 statusRequestund ich mach öfter rereadcfg
Liegt es dadran?
@energy,
klingt seltsam. kannst du die Sequenz aufzeichnen wenn der fensterkontakt bewegt wird und es zum missing-ack kommt?
@Otto
nach einem rereadcfg werden alle Device gelöscht und neu installiert. wenn autoReadReg gesetzt ist wird es nach so einem restart die register neu lesen wollen - das ist die definition. Das ganze wird gestaffelt gemacht, alle 15sec ein device incl all seiner channels.
bei wakeup-devices wird es verzögert, bis sie aufwachen.
das ganze sorgt für message-aufkommen nach neustart, klar.
Mein Gedanke ist, dass nach einem neustart FHEM den Zustand aller Komponenten lesen muss da unklar ist, was wir alles verpasst haben (status). das gleiche gilt für register.
wenn du es nicht haben willst kannst du das attribut auf 0 setzen, dann ist ruhe. Steht immer nur in devices.
Das ganze habe ich getestet so weit, dass es eigentlich felermeldungen durchläuft. wenn du in kurzer Zeit mehrfach neu startest wird evtl der HMLAN eine überlast erkennen...
Gruss Marin
Hi martin,
das mit dem reload war mal ein guter Tipp für Doofe wie mich! ;) danke!
VG
Hallo,
und für mich Doofer:
wenn ich eine cfg Datei ändere kann ich doch nur über rereadcfg gehen.
Oder gibt es noch einen anderen Weg?
Gruß Otto
Hallo Martin,
habe den burstRx bei allen RTs eingeschaltet und es geht jetzt besser. Allerdings bekomme ich wie gesagt seit dem letzten Update regelmäßig die folgende Meldung vom HMLAN:
2013.10.06 20:35:50 1: 192.168.178.48:1000 disconnected, waiting to reappear
2013.10.06 20:35:50 2: HMLAN_Parse: HMLAN1 new condition disconnected
2013.10.06 20:36:54 1: 192.168.178.48:1000 reappeared (HMLAN1)
2013.10.06 20:36:54 2: HMLAN_Parse: HMLAN1 new condition init
Diese Meldung taucht dokumentiert erst seit dem Update auf. Die ganze Steuerung ist jetzt sehr ungenau. Der HMLAN signalisiert eine Meldung (rote LED) aber die Reaktion ist teilweise mehrere Sekunden später. Besonders beim Treppenhauslicht ist das kritisch.
Hast Du eine Idee was das bewirkt. Was hast Du denn in 00_HMLAN und anderen relevanten Modulen verändert?
LG
Burchard
ich kann keinen tempOffset setzen und burst funktioniert auch nicht mehr, obwohl an allen Reglern eingeschaltet - und auch als "on" angezeigt wird.
cannot calculate value. Please issue set az_FHT_ClimRT_tr getConfig first
Natürlich ändert ein ausgeführtes getConfig nix an der Fehlermeldung.
Hey - ich war schonmal ein paar Schritte weiter als jetzt wieder...
2013.10.06 23:30:19 2: CUL_HM set out_Regen getSerial
2013.10.06 23:30:19 2: CUL_HM set out_Regen getConfig
2013.10.06 23:30:31 2: CUL_HM set sz_FHT getSerial
2013.10.06 23:30:32 2: CUL_HM set sz_FHT getConfig
2013.10.06 23:30:56 2: CUL_HM set wz_FHT getSerial
2013.10.06 23:30:56 2: CUL_HM set wz_FHT getConfig
2013.10.06 23:30:56 2: CUL_HM set wz_FHT statusRequest
2013.10.06 23:31:08 2: CUL_HM set wz_FHT_Ventil getSerial
2013.10.06 23:31:08 2: CUL_HM set wz_FHT_Ventil getConfig
2013.10.06 23:31:08 2: CUL_HM set wz_FHT_Ventil statusRequest
2013.10.06 23:31:20 2: CUL_HM set wz_Ventilator getSerial
2013.10.06 23:31:20 2: CUL_HM set wz_Ventilator getConfig
2013.10.06 23:31:20 2: CUL_HM set wz_Ventilator statusRequest
Zum Kotzen...
Hey Energy,
das gleiche Probleme hatte ich auch. Hatte dann alles zurückgesetzt und erst die Fensterkontakte und Thermostate gepeert und dann alles mit der Basis gepairt.
Was fehlte war der Register im Thermostat...
RegL_01: 08:00 00:00
RegL_03:DG_Wohnzimmerfenster_chn 04:32 00:00
RegL_03:DG_Wohnzimmerfenster_chn:01
das ganze ging bei mir nachträglich so:
set DG_Wohnzimmerventil_WindowRec regBulk RegL_03:202DB101 04:32 00:00
set DG_Wohnzimmerventil_WindowRec regBulk RegL_01: 08:00 00:00
DG_Wohnzimmerventil_WindowRec mit deinem tauschen und 202DB101 mit der ID vom Fensterkontakt und dem Zusatz 01 für den ersten Channel.
Das setzt glaube ich die Handlungsanweisung für das Thermostat, falls es "mitbekommt" dass das Fenster nun offen ist.
Ich hoffe ich hatte nicht nochmehr Befehle abgesetzt.... ;) Ansonsten mach's wie ich und setze die Komponenten kurz zurück.
@dusti
"Mein Problem ist, dass am Thermostat nichts geändert wird, d.h. weder im Manu noch im Auto-Modus. Ich liege doch richtig, wenn ich annehme, dass der HMLAN nur regeln kann, wenn der Thermostat in Auto steht?"
--> Nein, geht im Auto modus und im Manu :-)
einmal mit "set XXXXX mode manu 16" <-- 16 heißt hier der manuelle Modus mit 16°C
oder aber mit "set XXXXX mode auto" und "set XXXXXX desired-temp 16" <---- auch hier wieder 16 Grad.
Der ganze Unterschied ist, dass wenn er im Auto-Modus ist, er zu deinen eingestellten Zeiten wieder zurück ins Programm springt.
Ich nutze das ganze so, dass meine Thermostate generell im "Auto"-Modus laufen. Zeitintervall 3 Stunden, alle Temps auf 16 Grad. Wenn jetzt meine Freundin am Thermostat dreht ist die Heizung "im schlimmsten Fall" für 3 Stunden auf der gewählten Temperatur und stellt sich dann "auto" zurück auf 16.
Per FHEM habe ich eine komplexe Steuerung erstellt die die Heizung in den Manu-Modus mit der gewünschten Temp bringt. Direkt darauf folgt meist ein "set XXXXX mode boost" um direkt mal aufzuheizen. Nach einem Timer setze ich die Heizung wieder in Auto ---> Dada, der Raum (z.B. Badezimmer wird 30 Min vor dem Wecker hochgefahren) ist nun warm und wird in 1:30h automatisch langsam auf 16 runtergeregelt.
Das heißt:
"Und jetzt zu dem Zitat oben...wie schalte ich denn die interne Programmierung aus, damit die Steuerung durch FHEM erfolgen kann? Wahrscheinlich ne sehr dumme Frage ;) aber ich find nirgends eine Einstellung dazu und bitte mal um Schützenhilfe..."
--> Brauchst du nicht. Du kannst immer alles steuern und der Automatikmodus heißt halt nur, dass er zu den angegeben Zeiten die programmierte Temperatur einstellt. Was du 5 Sekunden danach machst ist ihm reichlich egal.
"Dumme Frage?" - Ich habe die letzten 2 Wochen am Rechner verbracht und mich durch alles durchgekämpft. Dabei war ich froh um jede Frage die etwas mehr Licht ins dunkel gebracht hat ;-)
Gruß
Julian
Für den Scheiß mit dem autoReadReg 4 sollte man jemanden teeren und federn und dann mit Schimpf und Schande aus der Stadt jagen.
Ich hasse eine solche Bevormundung als Anwender - woher nimmt irgendjemand sich das Recht, funktionierende Installationen durch so einen Mist völlig lahmzulegen, indem Gerätedefinitionen plötzlich um irgendwelche Attribute erweitert werden, die solche fatalen Auswirkungen haben???
Wenn jemand dieses Attribut unbedingt verwenden möchte, soll er sich das eigenverantwortlich selbst setzen (wenn er denn weiß, was er dabei tut) - aber ich habe keine Lust, mich irgendwann nochmal hinsetzen zu müssen, um meine fhem-Installation wieder gradezubiegen, damit hier überhaupt wieder irgendwas so funktioniert wie es soll!
Gute Nacht.
EDIT:
Ich werde wahnsinnig - hier sind schon wieder alle Lampen auf rot, weil diese dämlichen Attribute plötzlich WIEDER bei allen Homematic Devices vorhanden sind und damit mein komplettes fhem lahmgelegt ist.
WO kann ich diesen Wahnsinn abschalten?
Vielen Dank
@JayBee :)
über die Befehle krieg ich ihn auch angesprochen, er ändert brav den Modus und die Solltemp., nur die templist greifen nicht. Ich hab gedacht, Thermostat in Auto-Modus, templist vorgeben und alles gut :O aber wohl falsch gedacht. Hier stand geschrieben, dass die Listen erst nach dem nächsten Schaltbefehl greifen, den hab ich auch abgewartet und...nix :( wie krieg ich ihn denn überredet, dass er auf die vorgegebenen Listen reagiert?
Betateilchen hat geschrieben "Automatik abschalten" aber leider nicht wie...
Fragen über Fragen *gg*
Gruß Dusti
Zitat von: dusti64 schrieb am Mo, 07 Oktober 2013 08:20Betateilchen hat geschrieben "Automatik abschalten" aber leider nicht wie
Doch das hatte ich hier im Forum auch schon geschrieben: Bei mir stehen alle sieben tempLists auf "24:00 16"
Hallo
bei mir geht das Setzen der Templist, wenn ich vorher für das Device autoReadReg auf 4_reqStatus setze. Meine RTs stehen dabei im Modus Auto. Allerdings sollte man autReadReg 0 4_reqStatus nur für das Device setzen, das man ändern will, ansonsten geht der HMLAN in overload, wenn man viele HM-Devices hat. Anschließend habe ich (muss man, glaube ich, oder??) fhem neu gestartet, damit das Attribut wirksam wird. Setzt man dann die TempListen, so erhält man kurze Zeit später den Status verfied.
Gruß
Burchard
Bei mir hat das Setzen der tempList auch ohne irgendwelche Klimmzüge problemlos ohne autoReadReg funktioniert. Man musste nur etwas Geduld haben, aber das war ja auch beim "alten" Thermostaten schon so.
Werde ich mal testen, vielleicht bin ich zu ungeduldig!!??
@Otto
Unimatrix läd nur ein modul. wenn du die Konfig aenderst muss FHEM komplett neu durchstarten, das ist in diesem Fall der Sinn. da wird , wenn eingestellt, auchimmer die komplette Config aus den Devices neu gelesen.
Warum du es so oft lesen musst, weiss ich nicht. Du kannst die Parameter auch in FHEM aendern.
Wenn du einen Überblick über parameter bekommen willst könnte ich dir nur HMInfo empfehlen. mit
set hm param [filter] <param1> <param2> <param3>...
kannst du tabellen erzeugen und prüfen. So mache ich es jedenfalls um eine Übersicht zu erhalten.
@Burchard
was ich veraendert habe? Seit wann? schon eine ganze Menge.
ich sehe 2 Probleme bei dir
a) HMLAN disconnected
das ist nicht das Problem anderer, die ein Overload haben. Es könnte auch ein ausbleibendes keep-alive oder das Aufhängen des HMLAN selbst zurückzuführen sein. In der Vergangenheit waren "schlafzeiten" anderer Module schuld an diesem Problem - mal sehen.
=> hier brauche ich Logs (roh) über einen relevanten Zeitraum
b) lange reaktionszeiten
könnte in die gleiche Richtung deuten. Auch hier brauche ich logs
Generall vermeide ich wartezeiten jeder Art, blockierende sowiese. Die Logs sollten hoffentlich helfen, den täter zu finden. Hast du nochandere Module laufen? Evtl zeitraubende web-abfragen?
autoReadReg sollte man anlassen können. Es erzeugt nach dem booten keine Last. Nur wenn register geaendert werden wird ein getConfig automatisch ausgeführt. Eine erhöhte Load kommt nach dem booten, da hier alles gelesen werden muss.
bei Overload nutzt ein geboot von FHEM nichts, da es im HMLAN vorliegt.Das Problem sollte sich nach 6 min beheben. Alternativ den HMLAN booten (strom ziehen)
@betateilchen
set tempOffset funktioniert.
wenn du ein getConfig ausführst - klappt dies? oder ist ein getConfig dein Problem?
kannst du, wenn du expert=2 setzt auch ein "RegL_07" sehen? das ist Pflicht, sonst kann ich nichts errechnen
autoReadReg - da verstehe ich dich nicht.
zum einen halte ich es für sinnvoll und besonders für anfänger
zum 2. verstehe ich dich nicht. du hast sicher das commadnref nachgeschlagen - und meinen Kommentar vorher gelesen? setze autoReadReg auf "0_off" und fertig. Ich setze nur defaults, du kannst alles überschreiben - das hatte ich DIR schon beschrieben.
So ein Kommentar von dir enttäuscht mich, inhaltlich, technisch und auch dein Verhalten - schade.
@dusti
bei tempList für RT imburst-mode sollte es keine Probleme geben. Man kann aber die neuen option "prep" und "exec" nutzen, also alle templisten mit prep setzen und bei der letzten ein "exec" schicken. Erst nach dem exec werden die Daten "geschrieben".Das ist komplizierter, sollte aber das lange warten des RT abfangen.
Gruss Martin
Zitat von: martinp876 schrieb am Mo, 07 Oktober 2013 10:55@betateilchen
set tempOffset funktioniert.
wenn du ein getConfig ausführst - klappt dies? oder ist ein getConfig dein Problem?
Ich hatte doch klipp und klar geschrieben, dass ein getConfig keine Besserung bringt.
Zitat von: martinp876 schrieb am Mo, 07 Oktober 2013 10:55zum einen halte ich es für sinnvoll
Schön, das
Du es für sinnvoll hältst, aber denkst Du auch an die Leute, die sich mit
Deinen Mutmaßungen hinterher rumschlagen müssen?
Zitat von: martinp876 schrieb am Mo, 07 Oktober 2013 10:55und besonders für anfänger
Nutzer von Homematic in fhem sind aber nicht nur Anfänger (die vielleicht grade ihr erstes und einziges Gerät in Betrieb nehmen), sondern auch Leute, die schon sehr viel Zeit in Installtation und Konfiguration investiert haben - und Du machst das alles mit einem Rundumschlag zunichte.
Du solltest nicht immer von Deinem Experimentierfeld mit vielleicht drei oder vier oder fünf Homematic Geräten ausgehen, sondern solltest Dir irgendwann auch vor Augen führen, dass es auch Leute mit 40 und mehr (echten!) Geräten geben kann. Und vielleicht auch darüber nachdenken, dass nicht jeder jeden Tag an seiner Installation rumkonfigurieren, sondern sie vielleicht einfach "nur benutzen" will. Das hatte ich Dir vor einiger Zeit schonmal versucht zu erklären.
Zitat von: martinp876 schrieb am Mo, 07 Oktober 2013 10:55setze autoReadReg auf "0_off" und fertig.
Ja klar... bei 43 Geräten. Bisher hatte ich das autoReadReg nur bei einem einzigen Gerät im Einsatz. Und jetzt soll ich mich hinsetzen und bei 42 anderen einen Eintrag setzen bzw. ändern, den ich bisher nie gebraucht habe, nur weil
Du da einen völlig sinnfreien Eintrag hinzugefügt hast, der hier das totale Chaos verursacht.
Zitat von: martinp876 schrieb am Mo, 07 Oktober 2013 10:55Ich setze nur defaults, du kannst alles überschreiben
Ja, aber die von Dir aufgezwungenen defaults sind einfach unbrauchbar! Und sag nicht, ich hätte Dir nicht von Deinem völlig vorsätzlichen Sabotageakt im Vorfeld abgeraten!
Zitat von: martinp876 schrieb am Mo, 07 Oktober 2013 10:55So ein Kommentar von dir enttäuscht mich, inhaltlich, technisch und auch dein Verhalten - schade.
So ein Verhalten, wie Du es hier mit der wahllosen Indoktrination eines in diesem Umfang völlig sinnlosen Attributes gezeigt hast, enttäuscht
mich menschlich, technisch und als Entwickler.
So etwas tut man nicht!---
Als bisher stiller Mitleser möchte ich mich jetzt doch auch einmischen:
1) wer seine Installation einfach nur "benutzt" wird auch keine Updates machen und deswegen auch keine neuen Defaults bekommen
2) Dinge wie "Für den Scheiß mit dem autoReadReg 4 sollte man jemanden teeren und federn und dann mit Schimpf und Schande aus der Stadt jagen." sind meiner Meinung nach im Ton einfach daneben, egal wie sehr die Meinung auseinander geht
3) Martin hat sich bisher reingehängt um die Thermostate zum funktionieren zu bringen und hat Fragen (auch Deine, betateilchen) in kürzester Zeit beantwortet, dafür verdient er (zumindest meine) Wertschätzung, danke Martin
4) es gilt das alte Open Source-Argument, niemand wird gezwungen das so zu benutzen wie es ist, Code ist veränderbar
Und um noch was zur Problemlösung beizutragen:
Mittels geeigneter "devspec" dürfte es auch bei 43 Devices nicht so wahnsinnig viel Aufwand sein, bei allen Devices das passende Attribut zu setzen.
Gruß Wolfgang
Hallo zusammen
danke Wolfgang, ich stimme Dir in den 4 Punkten zu, wollte aber nicht der erste sein der einen Kommentar abgibt.
lg
Stefan
Das stimmt schon was er schreibt. Es hätte gereicht zu verkünden das einem diese Änderung nicht passt. Melden sich zu dem Thema noch 10 andere würde Martin sicher nochmal drüber nachdenken die defaults anders zu setzen.
Ich denke mal das was von "betateilchen" auch nicht so gemeint, aber wenn etwas nicht funktioniert ist man eben erst mal "angepisst", ich kenne das, und ihr sicher auch ;-)
Aber nun lasst uns hier weiter technisch bleiben. So was gehört hier nicht her und jeder sollte es lernen solche emotionalen Sachen auch mal aus zu blenden.
Btw. eine kurze technische Frage, damit dieser Beitrag auch ein Mehrwert hat:
Ich habe festgestellt, dass ich am Wochenende doch zu stark unterschiedlichen Zeiten ins Bad gehe, nun wollte ich anstelle der TimeTables lieber manuell aus der "ferne" (FB am Bett) über FHEM den Boost Modus starten, geht das?
Gruß
Daniel
@ betateilchen
>>>Ich hatte doch klipp und klar geschrieben, dass ein getConfig keine Besserung bringt.
sorry, undich will KILPP UND KLAR wissen, obes ausgeführ wurde. Bitte auch du alles lesen und beantworten!!!!!
>>>Schön, das Du es für sinnvoll hältst, aber denkst Du auch an die Leute, die sich mit Deinen Mutmaßungen hinterher rumschlagen müssen?
ich denke schon - das musst du ja auch mit allen andere features, die ich DIR einbau.
du kannst es bequen abschalten - und konntest es schon lange, wenn du auch einmal zuhörst!!
>>>Nutzer von Homematic in fhem sind aber nicht nur Anfänger
und von Fortgeschrittenen erdarte ich nicht nur dampfgeplaudere sondern dass sie die ihnen angebotenen einstellungennutzen können. Scheint aber manchen zuviel zu sein.
>>>ja klar... bei 43 Geräten.
nicht so schlimm. ein einfaches replace in Editor von fhem.cfg, fertig.
das hätte ich von dir schon erwartet :-(
@Wolfgang - so kompliziert muss man es garnicht machen
>>>So etwas tut man nicht!
nun - vielleicht sollte ich weitere updates einstellen. dann muss ichm ich nicht mit dieser Tonart rumschlagen.
gehe besser auf version 1600 zurück, da sind alle meine ungewünschten updates entfernt.
@Daniel
set <rt_Clima> controlMode boost
Gruss Martin
Ah ok danke, da hatte ich was gelesen von den neuen Modes, aber ich war mir nicht sicher ob der danach wieder in den Auto Modus springt. OK I'll try it ;-)
/Daniel
Hi Martin,
nicht einschüchtern lassen. Ich finde sowohl deine updates gut und außerdem gibt es eine vollkommen transparente Kommunikation über die Änderungen.
Ist aber wohl normal bei so einem Projekt dass ab einer bestimmten Größe auch solche Arten von Feedbacks in Foren kommen. Muss man ignorieren, denke ich. Ich glaube, die Masse aller User ist hier gar nicht aktiv und hat einfach nur das System laufen und ist damit zufrieden. Und ein "updatefhem" ist ja immer noch eine bewusste Entscheidung, die man tun kann oder auch nicht...
Hi Daniel,
sorry, noch ein (neuer) bug bei controlMode - fix kommt in in paar minuten, werde noch durchtesten.
Gruss Martin
Ja keine Panik, hat alles Zeit bei mir, der Winter ist lang ;-)
/Daniel
V4016
habe boost noch einmal getestet - boost ist immer temporär und dauert so lange wie programmiert...
Gruss Martin
Zitat von: wmr72 schrieb am Mo, 07 Oktober 2013 11:491) wer seine Installation einfach nur "benutzt" wird auch keine Updates machen und deswegen auch keine neuen Defaults bekommen
Wir reden hier von der Nutzung EINES neuen Gerätes, das noch nicht so funktioniert, wie es vorgesehen ist. Da kommt man auch als Nutzer um Updates nicht rum. Aber wegen EINEM Gerät die Konfiguration ALLER anderen, bisher funktionierenden (!) Geräte
zwangsweise zu verändern, ist für mich absolut kontraproduktiv.
Zitat von: wmr72 schrieb am Mo, 07 Oktober 2013 11:493) Martin hat sich bisher reingehängt um die Thermostate zum funktionieren zu bringen und hat Fragen (auch Deine, betateilchen)
Das ist unbestritten.
Zitat von: wmr72 schrieb am Mo, 07 Oktober 2013 11:49dafür verdient er (zumindest meine) Wertschätzung,
Diese Wertschätzung hat er auch von mir, so gut sollte er mich eigentlich inzwischen kennen.
martinp876
nun - vielleicht sollte ich weitere updates einstellen
bitte nicht :)
der Parameter autoReadReg ist ja schon uralt, ich hatte den schon überwiegend gesetzt.
@betateilchen
na ja , war es mal wieder soweit,
Wertschätzung sieht anders aus,.
Erst mal vielen Dank für das Feedback :) schön zu wissen, dass es hier keine dummen Fragen gibt ;) Ich hoffe, dass es so bleibt!
Vorweg mal meine Meinung zu diesen Updategeschichten...ja, auch wenn es erst mein drittes Posting ist. Nur weil man NOCH keine Ahnung hat von FHEM, heißt das ja nicht, dass man blöde ist und manch einer, der vor langer Zeit seine ersten Schritte gemacht, wäre vielleicht damals dankbar gewesen für ein paar Defaults, die ihm das Leben leichter gemacht hätten. An dem Punkt bin ich nämlich gerade ;) Im Übrigen bin ich den lieben langen Tag von SPSen und Leitsystemen umgeben, nur sind die leider nicht in Perl programmiert und heißen nicht FHEM ;) Auch habe ich ein gewisses Verständnis für Steuerungsebenen wie Automatik/PLS/VOSS usw. und so. Aber ich mache kein Geheimnis draus, dass ich meine ersten Schritte mache, was HM und FHEM betrifft...
Wenn man drin steckt, ist es wohl recht einfach, diese Voreinstellungen zu ändern, wie viele Vorredner bestätigen. Das man gleich die Contenance verliert, ist nicht die feine Hausfrauenart :-D zumal ich bisher den Eindruck hatte, dass hier Profis am Werk sind :O
Wie schon erwähnt, verneige ich mich vor den Leuten, die soviel Zeit ans Bein binden, damit der Kram rund läuft! Und das bei einem Update mal was in die Hose geht, ist ja wohl nicht unbekannt, Stichwort Microsoft...
@Martin
Also bitte weiter so!!!
@Betateilchen
Sorry das ich noch nicht das ganze Forum durchgelesen habe ;) und sicher verstehe ich deinen Unmut, doch für dich dürfte es doch ein Klacks sein, diese Einstellungen zu ändern!?
So und jetzt wieder zu meinem eigentlichen Problem zurück. Wie gestern schon geschrieben, habe ich kein Problem, die templist zu setzen, ich hab weder einen Overload noch ein MissAck oder so was. Auch ist der Burst-Mode aktiviert und die Listen sind verfiziert. Nur umgeschaltet gemäß diesen Listen wird am Gerät nicht.
Wenn ich mir die Antworten so durchlese, stellt sich mir eher die Frage, ob wir manchmal über verschiedene templist reden. Ich rede über die Listen im Channel 4 (ClimRT_tr) Dort kann ich Zeiten und Temperaturen für jeden Wochentag vorgeben. Wenn ich den Antworten hier zufolge diese Listen auf 24:00 16 setze, um die interne Automatik abzuschalten, wo gebe ich dann die Regelzeiten und Temperaturen für den Thermostaten ein?
Wahrscheinlich bin ich voll auf dem falschen Dampfer...
Gruß Dusti
Zitat von: dusti64 schrieb am Mo, 07 Oktober 2013 20:25sicher verstehe ich deinen Unmut, doch für dich dürfte es doch ein Klacks sein, diese Einstellungen zu ändern!?
Es geht nicht darum, ob es ein Klacks ist oder nicht. Es kann einfach nicht sein, dass ich aufgrund einer völlig unnötigerweise systemweiten Änderung als Anwender dazu gezwungen werden, aktiv zu werden, um eine Funktionalität NICHT MEHR zu haben, die ich auch bisher nicht hatte, nicht gebraucht habe und auch jetzt nicht brauche. Im Gegenteil: Eine Funktion zu deaktivieren, die meine gesamte Installation sabotiert, ohne dass es dafür einen Grund gibt, nur damit mein Anwendungsszenario wieder so funktioniert wie bisher.
Wenn ein Attribut wie autoReadReg plötzlich (aus mir nach wie vor unerfindlichen Gründen) bei JEDEM Homematic-Gerät
vorhanden sein MUSS, dann ist es kein Attribut mehr, sondern gehört in das Define. Und wenn es im Define nicht angegeben wird, dann hat das gefälligst abgeschaltet zu bleiben. Das nennt sich Abwärtskompatibilität.
Zitat von: dusti64 schrieb am Mo, 07 Oktober 2013 20:25Wenn ich den Antworten hier zufolge diese Listen auf 24:00 16 setze, um die interne Automatik abzuschalten, wo gebe ich dann die Regelzeiten und Temperaturen für den Thermostaten ein?
Wo immer Du das willst. Du kannst in fhem heating_control verwenden, oder Du kannst mit vielen at-Definitionen einen Wochenplan erstellen, oder Du definierst die Heizzeiten in einem Google-Kalender, mittels dessen Hilfe fhem die gewünschten Temperaturen regelt. Ich habe mich für die Kalender-Variante entschieden und das funktioniert hervorragend. Ausserdem hat das den Vorteil, dass ich die Heizzeiten spontan von unterwegs ändern kann, wenn ich z.B. erst einen Tag später nach Hause komme oder sonst irgendwelche Änderungen im geplanten Ablauf vornehmen muss.
@Betateilchen...wie gesagt, ich versteh dich, halt mich aber mal raus, weil mir das Hintergrundwissen fehlt. Meine Antwort war allg. geschrieben zu dem Updateproblem und das sehe ich nun mal so...
Also der richtige Riecher und voll der falsche Dampfer mit den templist :-D passiert *gg*
Ich werd mir mal das heating_control reinziehen, würde es auch mit dem Kalender der iCloud gehen? Mit Google hab ich es nicht so :(
Und Danke (y)
Zitat von: dusti64 schrieb am Mo, 07 Oktober 2013 21:12würde es auch mit dem Kalender der iCloud gehen?
Nein. Aber das Kalenderprogramm vom MacOS kann auch mit Google umgehen :)
@Dusti,
die templisten stellen die regelzeiten ein. Eingegeben wird immer die end-zeit und die Temperatur. gestartet wird um 00:00 (startzeiten werden nicht angegeben).
die Letzte Zeit muss 24:00 sein, um den Tag zu beenden.
die templisten sind nur im Automode aktiv.
Gruss Martin
Ich glaube, beim Mode ControlParty hat sich ein Bug eingeschlichen: ich kann diesen Mode nicht mehr setzen.
habe ich heute gesehen - sorry - und behoben. wenn du die neuste Version aus SVN holst- oder morgen nach einem Update noch einmal probierst...
wenn es immer noch ein Problem gibt, bitte melden
Gruss Martin
1000 Dank schon mal !!
Ich hole mir dann morgen das Backup.
@ Betateilchen
unnötigerweise systemweiten Änderung
auch wenn du dich noch mehrmals wiederholst, es wird nicht besser.
ich habe den Anspruch, bei Homematic, nach Restart, Start, Stromausfall auf dem aktuellen Stand der Devices zu sein!
und nicht auf die Fhem.save, die irgendwann erstellt wurde, wo die ganzen Readings drinstehen. von wann auch immer.
zumal wenn wir gerade beim Heizungsthema sind, der TC um umzuschalten von auto auf manuel z.B, dies anders funktioniert wie bei Desiredtemp,
Da muß man ein Byte berechnen, das aus mehreren Readings besteht, und da mochte ich keinen alten Schrott drin haben.
Und wenn ich dran denke, wie du dich negativ über den actiondetector geäusert hast , weil du ihn nicht brauchst, oder beim TC, über den Centmodus ein Fass aufgemacht hast
naja, ....
zu deinen anderen komischen Äusserungen in Bezug auf Frizbox, Rpi; Hmlan; usw halt ich mich zurück.
Beaglebone ist gerade dein Favorit... ;)
Irgenwie hab ich ein Deschawü, wer länger dabei ist weiß wen ich mein :)
@ Martin876
wollt nicht auch noch nochmal rumspammen :)
*gähn*
Zitat von: fhem-hm-knecht schrieb am Di, 08 Oktober 2013 00:37Beaglebone ist gerade dein Favorit
Das ist das Einzige in Deinem Geschreibsel, das ich irgendwie nachvollziehen kann. Immerhin etwas.
@ Martin
Na das war doch mal ne Ansage, alles wird gut. Jetzt ist mir auch klar, wo es geklemmt hat. Ist zwar ungewöhnlich, mit einer Endzeit zu beginnen, aber wenn die erste Startzeit automatisch gesetzt wird, schließt sich der Kreis.
Und nun verstehe ich auch die 24:00 16, mir wollte sich bis dato der Sinn dieser templist nicht erschließen :O Danke!
Und hört bitte auf, euch hier zu fetzen, trinkt lieber mal ein Bier zusammen und freut euch des Lebens :-D
@dustie,
ja, ist gewöhnungsbedürftig - aber macht HM so, auch beim TC.
Hallo erstmal und vielen Dank für eure Bemühungen.
Als bisher stiller Mitleser muss ich mich jetzt doch mal zu Wort melden:
1: @Martin: Danke!
2: Das mit dem templisten habe ich noch nicht verstanden. Ich habe folgendes vor:
05:00 - 08:00 Uhr: 21°
08:00 - 17:00 Uhr: 16°
17:00 - 22:00 Uhr: 21°
22:00 - 05:00 Uhr: 16°
Ich würde das ganze gerne über Templisten machen, da ich einmal pro Tag abhängig von anderen Sensoren unterschiedliche Tagespläne setzen möchte.
Das die Zeiten in den Listen jeweils Ende-Zeiten sind habe ich auch verstanden, allerdings stehe ich irgendwie auf dem Schlauch was den Tagesanfang angeht. Ist die letzte Temperatur vom Vortag dann die erste des Folgetages?
Hallo,
für diesen Fall sieht deine tempList (für einen Tag) so aus:
set <chan> tempList<day> 5:00 16.0 08:00 21.0 17:00 16.0 22:00 21.0 24:00 16.0
Wie du siehst ist es "Pflicht" einen Schaltzeitpunkt um 24 Uhr zu haben.
VG
Das ging schnell, danke!
Wenn ich dann jede Stunde den Wert neu "einstellen" lassen möchte (falls mal jemand von Hand gedreht hat) müsste die Liste also so aussehen:
05:00 16.0 06:00 16.0 07:00 21.0 08:00 21.0 09:00 16.0 10:00 16.0 11:00 16.0 12:00 16.0 13:00 16.0 14:00 16.0 15:00 16.0 16:00 16.0 17:00 16.0 18:00 21.0 19:00 21.0 20:00 21.0 21:00 21.0 22:00 21.0 23:00 16.0 24:00 16.0
Wenn meine Auflistung so passt, habe ich zumindest das System verstanden!?
Dann komme ich natürlich an die Grenzen des Reglers, dieser kann ja nur 13 Schaltzeiten pro Tag. Wie würdet Ihr denn die Soll-Temperaturen setzen, wenn diese stündlich neu "gestellt" werden sollen um "Benutzer-Eingriffe" zu kompensieren?
Hallo,
setze doch die Bediensperre / Kindersicherung am Regler!
Gruß Otto
prinzipiell richtig, aber morgens hast du jetzt nur noch 2 Stunden lang 21 Grad.
Bediensperre ist keine Lösung - wenn ich dich richtig verstehe, sollen ja manuelle Eingriffe möglich sein, aber du willst dann z.B. nicht stundenlang bei der manuell geänderten Temeratur bleibe und daher öfters Schaltzeitpunkte haben. Insofern sicher eine Möglichkeit das zu lösen.
Bei einer Steuerung über FHEM und nicht über Templisten sind auch manuelle Eingriffe möglich. Mit einer geschickten Programmierung kann FHEM ja feststellen dass jemand manuell gedreht hat und kann z.B. für 2 Stunden die Automatik unterdrücken.
bedenke dass der RT am tag 13 schaltpunkte kann, nicht mehr.
Genau, manuelle Eingriffe sollen ja möglich sein.
Dann werde ich wohl doch etwas tiefer "perlen" müssen und die entsprechenden Werte über fhem setzen.
Danke für eure schnelle Hilfe!
Vielleicht sollte man nicht jede Stunde eine neue Solltemp. an den Regler schicken - zwischen 23 und 6 Uhr erschließt sich mir der Sinn nicht (außer Nachteulen "drehen am Rad"). Schon hast Du ein paar Schaltpunkte weniger :-)
Uwe
Theoretisch sende ich dann zwar jede Stunde eine neue Solltemp aber faktisch muss der Regler ja nichst tun, da in der Regel die Temperatur ja richtig eingestellt sein wird. Nur wenn jemand die Temperatur von Hand verstellt hat, muss der Regler "nachdrehen". Oder was sind deine Bedenken?
Ob der Regler etwas ändern muss oder nicht spielt keine Rolle. Er wird intern nur eine bestimmte Anzahl von Speicherplätzen für die Solltemp. haben (7 x 12 vermute ich mal).
Uwe
Hallo, ich habe jetzt meine ersten Schritte mit FHEM bewältigt und habe direkt ein paar Fragen
ich hab mich für Homematic entschieden, erstmal nur ein HMLAN-Konfigurator und ein HM-CC-RT-DN.
1) Verständnisfrage: beim pairen wird ja das Device und diverse Kanäle angelegt, interessant ist ja nur der Kanal 4, kann ich die anderen einfach ignorieren oder verpasse ich was wichtiges? zB. so:
attr wohnung hiddenroom DN_HIDDEN
define DN CUL_HM abcdef
attr room DN_HIDDEN
define DN_Weather CUL_HM abcdef001
attr room DN_HIDDEN
...
define bz_thermostat CUL_HM abcdef004
attr room Badezimmer
...
(ich hab da einen eigenen Hiddenroom angelegt damit man den einfach und nur den falls benoetigt einblenden kann)
2) Problem: ich habe versucht die tempListFri etc. zu setzen, hat auch wunderbar mit prep und exec funktioniert, aber viele Listen stehen jetzt noch mit set_ drin, das HMLAN ist nicht im Overload und missingAck hab ich auch nicht. Was kann ich tun?
3) Idee: ich würde gern 1 oder 2 externe Temperatursensoren verwenden und diese an den Thermostat senden. Geht das?
Im Optimalfall stelle ich mir das so vor: Temperatursensor1 im Raum: 20, Temperatursensor2 im Raum: 19.5, measured-temp vom Thermostat: 22, da ich den anderen sensoren mehr traue wuerde ich sie mehr gewichten
(2*(t1 + t2) + mt) / 5 => (2*(20 + 19.5) + 22) / 5 = 20.2
und jetzt sehe ich zwei Moeglichkeiten:
a) ich sende dem Thermostat diese IST-Temperatur und stelle über desired-temp meine Wunschtemperatur
b) ich steuere die Ventilöffnung vom Thermostat direkt
Was haltet ihr davon? Ist sowas möglich oder gibt es da schon eine Lösung in der Art?
Hi Absurd-Mind,
Channel 4 ist der "operationelle". Die anderen haben auch eine Bedeutung - zum einenzum Configurieren und - deutlich weniger - zum überwachen.
ch1 - hier kann man ein Thermostat peeren und die ist-temp "einspeisen"
ch2 - keine Ahnung, ob er noch eine bedeutung hat
ch3 ist der window receiver. hier kannst du fensterkontakte peeren und bekommst einen trigger wenn er ebeneinen sendet
ch5 wird zum peeren von RTs genutzt, also wenn2 rts in einem raum sind und sich synchronisieren sollen
ch6 kann mit einer remote-controll gekopplet werden. Das muss hier eingestellt werden und hier werden auch trigger vermerkt, so den welchen kommen
2) du musst die werte zur bestätigung aus dem RT rücklesen. das geht mit einem getConfig -oder dem Attribut autoReadReg=4 automatisch.
3) geht prinzipiell, aber der virtuelle Temp ist (noch) nicht implementiert. Die Berechnung ist diene Sache. Die werte müssten dann regelmässig gesendet werden - an den channel 01
a) wird möglich sein
b) ist nicht möglich. macht auch keinen sinn - der RT hat mit grösser sicherheit einen besseren regelalg als du. aber das Ventil kannst du eh nicht manuell stellen
Gruss Martin
Hallo Martin,
ich habe mir heute morgen ein Update gezogen. Seit dem ist mein Außentemperatursensor (HM-WDS10-TH-O) "dead".
Kann dies am Update liegen?
Danke und Gruß
Christoph
Hallo Christoph,
nicht, das ich es erklären könnte.
der status des ActionDetector wird aus der "letzten-empfangsnachricht" generiert. wenn die länger zurück liegt als die erwartet Zeit wird das Device als "dead" marktiert.
Es könnte sein, dass
a) attr actCycle einen zu kleinen Wert hat
b)protLastRcv ein altes Datum hat
c) der TH-O keine regelmässigen Daten mehr sendet
wie stehen die Werte? Wenn es etwas andere ist musst du die Werte schicken und ein paar logs
Gruss Martin
Hallo Martin,
a) actCycle steht auf 000:10, daran liegt es bestimmt nicht, der TH-O ist seit einem Monat im Einsatz, bisher ohne Probleme
b) protLastRcv wird gar nicht angezeigt, was mich wundert. Ich bin mir eigentlich ziemlich sicher, dass hier immer etwas stand
c) der TH-0 ist max ein Monat im Einsatz, die Batterien sollten daher noch voll sein.
Was mich wundert, dass im Log aufeinmal "R-intLKeyVisib: insvisib" steht. Was hat das zu bedeuten? Der burst-Mode war beim TH-0 ausgeschaltet.
Viele Grüße
Christoph
Hallo Christoph,
wenn in protRcv nichts steht wird auch nichts empfangen. Das kannst du sicher an den readings auch nach vollziehen.
das mit internal-key kann ich nicht deuten. Könnte sein, dass er es garnicht unterstützt und somit der wert im schlimmsten Fall zufällig ist.
Du kannst einmal anlerenn drücken und sehen, ob diese message ankommt.
wenn der TH-O gar nichts mehr sendet kann er auch kaputt sein. Selbstverständlich vorher die Batterien kontrollieren - schadet nie
Gruss Martin
Hallo Martin,
ich hab hier noch was festgestellt, was sagst du dazu:
Ich habe über FHEM das R-tempOffset auf 1.0K gesetzt, wurde übernommen, getconf zeigt es auch an. Dann habe ich direkt am Regler geschaut, dort steht aber 1.5 Grad, dann habe ich das auf 1,0 gesetzt, ein getconf mit FHEM gemacht und nun finde ich folgende Ausgabe: "R-tempOffset undef lit"
Update habe ich gestern um 9 Uhr das letzte gemacht.
Gruß
Daniel
Hallo Daniel,
mein Fehler, verzählt :-(
Wert 1.0k fehlt,alle positiven sind um eins verschoben.
beim nächsten Update nicht mehr
Danke Martin
Hallo Zusammen,
hat sich bezüglich der Meldung von BuRi (So, 06 Oktober 2013 20:58) etwas ergeben?
Ich habe seit ein paar Tagen auch diese Meldungen in meinen Logs. Auch wirkt das System in letzter Zeit etwas "dräge".
Viele Grüße
Christoph
konkretes ist mir nicht bekannt.
kannst du einmal loggen (roh-messages von HMLAN) was da passiert?
So alle paar Stunden erscheint "disconnected" und "reappeared" im Log:
2013.10.09 10:10:25 1: 192.168.4.200:1000 disconnected, waiting to reappear
2013.10.09 10:10:25 1: 192.168.4.200:1000 reappeared (HMLAN1)
2013.10.09 10:10:25 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.09 10:10:27 2: HMLAN_Parse: HMLAN1 new condition ok
2013.10.09 13:50:01 1: 192.168.4.200:1000 disconnected, waiting to reappear
2013.10.09 13:50:01 1: 192.168.4.200:1000 reappeared (HMLAN1)
2013.10.09 13:50:01 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.09 15:01:14 2: HMLAN_Parse: HMLAN1 new condition ok
2013.10.09 16:04:04 1: 192.168.4.200:1000 disconnected, waiting to reappear
2013.10.09 16:04:04 1: 192.168.4.200:1000 reappeared (HMLAN1)
2013.10.09 16:04:04 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.09 16:33:42 2: HMLAN_Parse: HMLAN1 new condition ok
2013.10.09 16:48:15 1: 192.168.4.200:1000 disconnected, waiting to reappear
2013.10.09 16:48:15 1: 192.168.4.200:1000 reappeared (HMLAN1)
2013.10.09 16:48:15 2: HMLAN_Parse: HMLAN1 new condition init
2013.10.09 18:25:56 2: HMLAN_Parse: HMLAN1 new condition ok
hm - kannst du logs ziehen von den roh-messages die zum HMLAN gehen?
Gruss Martin
Kann ich machen. Nur was muss ich dazu einstellen?
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1
Ergebnisse im generellen Logfile
Ich habe heute den Thermostaten bekommen und bisher habe ich eine Paarung zum FHEM (über HMLAN) hinbekommen.
Auch der Befehl "set Thermostat_WZ mode manu 20" (Info: Thermostat_WZ habe ich den Regler genannt) funktioniert einwandfrei, wenn auch mit einer Verzögerung von ca. einer Minute.
Aber was ich bisher nicht gefunden habe:
Wie kann ich im FHEM die aktuell eingestellte Temperatur abfragen/angezeigt bekommen. Geht das überhaupt?
Was bedeuten die folgenden Abkürzungen und warum stehen da überall ??? im FHEM dahinter?
Thermostat_WZ_Climate
Thermostat_WZ_ClimRT_r
Thermostat_WZ_ClimRT_tr
Thermostat_WZ_rCtrl
Thermostat_WZ_Weather
Thermostat_WZ_WindowRec
Weis das jemand?
Ciao, BK
ReadingsVal('Thermostat_WZ_ClimRT_tr','desired-temp','')
@stpkl
lese erst mal in Ruhe von ganz vorn in diesem treat, viele Probleme und Fragen klären sich dann selbst...
Zitatwenn auch mit einer Verzögerung von ca. einer Minute.
Ist wohl normal, geht schneller, wenn der burst Modus eingeschaltet ist
ZitatWie kann ich im FHEM die aktuell eingestellte Temperatur abfragen/angezeigt bekommen. Geht das überhaupt?
Du hast ein Device (der Thermostat selbst) und 6 Kanäle dazu, schau mal hier in diesem treat, steht alles drin, wofür sie sind und welche Rolle sie wann spielen, der entsch. ist der Kanal (channel) 4
Klick mal einfach auf "Thermostat_WZ" (ganz unten in deinem JPG), dann solltest du unter readings die Soll- und IST-Werte sehen.
ZitatWas bedeuten die folgenden Abkürzungen und warum stehen da überall ??? im FHEM dahinter?
Thermostat_WZ_Climate
Thermostat_WZ_ClimRT_r
Thermostat_WZ_ClimRT_tr
Thermostat_WZ_rCtrl
Thermostat_WZ_Weather
Thermostat_WZ_WindowRec
ZitatZitat Martin:
"Channel 4 ist der "operationelle". Die anderen haben auch eine Bedeutung - zum einen zum Konfigurieren und - deutlich weniger - zum überwachen.
ch1 - hier kann man ein Thermostat peeren und die ist-temp "einspeisen"
ch2 - keine Ahnung, ob er noch eine bedeutung hat
ch3 ist der window receiver. hier kannst du fensterkontakte peeren und bekommst einen trigger wenn er ebeneinen sendet
ch5 wird zum peeren von RTs genutzt, also wenn2 rts in einem raum sind und sich synchronisieren sollen
ch6 kann mit einer remote-controll gekopplet werden. Das muss hier eingestellt werden und hier werden auch trigger vermerkt, so den welchen kommen"
Die Fragezeichen in ch4 deuten auf einen unbekannten Status (state) hin, eventuell doch nicht richtig gepairt :O
Da es bei mir zum Anfang auch so ähnlich aussah, geh ich davon aus, dass das Gerät noch nicht richtig gepairt ist, zumal CMDs_pending da steht... ich hab es komplett gelöscht und neu eingerichtet, vorher den Thermostaten auf Werkseinstellungen resetet, wichtig vorher AES ausschalten, jedenfalls wurde es so beschrieben...Im Display des Devices sollte bei richtigen Pairing das Antennensymbol dauerhaft leuchten...
Good Luck (y)
P.S. lass mich gern berichtigen ;)
@Lucky
nur eine kleine Anmerkung: wenn burstRx "ein" ist sollte es schnell gehen. Wenn burstRx 'off' ist muss man auf das Erwachen (wakeup) warten - 0-3min
Zitat von: martinp876 schrieb am Mi, 09 Oktober 2013 19:24hm - kannst du logs ziehen von den roh-messages die zum HMLAN gehen?
Gruss Martin
hier ein etwas längerer Log-Auszug:
2013.10.09 23:29:31.374 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:29:31.835 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0706431 d:1EA2C9 O:CC0007 t:00447A84 IDcnt:0004
2013.10.09 23:30:44.482 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:30:44.580 1: HMLAN_Parse: HMLAN1 R:E21CF29 stat:0000 t:0044A2A4 d:FF r:FFB6 m:6C 8610 21CF29 000000 0A88E6100080
2013.10.09 23:30:44.696 1: HMLAN_Parse: HMLAN1 R:E206A48 stat:0000 t:0044EFB5 d:FF r:FFB0 m:1D 8670 206A48 000000 009A4E
2013.10.09 23:30:44.741 1: HMLAN_Parse: HMLAN1 R:E236C2B stat:0000 t:00450290 d:FF r:FFA2 m:B9 8610 236C2B 000000 0A88E8100080
2013.10.09 23:30:44.845 1: 192.168.4.200:1000 disconnected, waiting to reappear
2013.10.09 23:30:44.923 1: 192.168.4.200:1000 reappeared (HMLAN1)
2013.10.09 23:30:44.925 1: HMLAN_Send: HMLAN1 I:ACC0007
2013.10.09 23:30:44.927 1: HMLAN_Send: HMLAN1 I:C
2013.10.09 23:30:44.928 1: HMLAN_Send: HMLAN1 I:Y01,00,
2013.10.09 23:30:44.930 1: HMLAN_Send: HMLAN1 I:Y02,00,
2013.10.09 23:30:44.931 1: HMLAN_Send: HMLAN1 I:Y03,00,
2013.10.09 23:30:44.933 1: HMLAN_Send: HMLAN1 I:T19E88784,04,00,00000000
2013.10.09 23:30:44.935 1: HMLAN_Parse: HMLAN1 new condition init
2013.10.09 23:30:45.008 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0706431 d:1EA2C9 O:CC0007 t:004599DB IDcnt:0004
2013.10.09 23:31:01.381 1: HMLAN_Parse: HMLAN1 R:E21CFF0 stat:0000 t:0045DA03 d:FF r:FFB5 m:07 8610 21CFF0 000000 0A88E10F0080
2013.10.09 23:31:09.976 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:31:09.982 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0706431 d:1EA2C9 O:CC0007 t:0045FBBC IDcnt:0000
2013.10.09 23:31:34.984 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:31:34.991 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0706431 d:1EA2C9 O:CC0007 t:00465D70 IDcnt:0000
2013.10.09 23:31:59.993 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:32:00.000 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0706431 d:1EA2C9 O:CC0007 t:0046BF24 IDcnt:0000
2013.10.09 23:32:04.412 1: HMLAN_Parse: HMLAN1 R:E21CF29 stat:0000 t:0046D05A d:FF r:FFB6 m:6D 8610 21CF29 000000 0A88E6100080
2013.10.09 23:32:25.002 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:32:25.009 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0706431 d:1EA2C9 O:CC0007 t:004720D9 IDcnt:0000
2013.10.09 23:32:35.963 1: HMLAN_Parse: HMLAN1 R:E236C2B stat:0000 t:00474B9D d:FF r:FFA2 m:BA 8610 236C2B 000000 0A88E8100080
2013.10.09 23:32:43.140 1: HMLAN_Parse: HMLAN1 R:E206A48 stat:0000 t:004767A9 d:FF r:FFAF m:1E 8670 206A48 000000 00984F
2013.10.09 23:32:50.012 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:32:50.019 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0706431 d:1EA2C9 O:CC0007 t:0047828F IDcnt:0000
2013.10.09 23:34:17.359 1: HMLAN_Parse: HMLAN1 R:E21CFF0 stat:0000 t:0047C358 d:FF r:FFB5 m:08 8610 21CFF0 000000 0A88E00F0080
2013.10.09 23:34:17.463 1: HMLAN_Send: HMLAN1 I:K
2013.10.09 23:34:17.578 1: 192.168.4.200:1000 disconnected, waiting to reappear
2013.10.09 23:34:17.679 1: 192.168.4.200:1000 reappeared (HMLAN1)
2013.10.09 23:34:17.681 1: HMLAN_Send: HMLAN1 I:ACC0007
2013.10.09 23:34:17.683 1: HMLAN_Send: HMLAN1 I:C
Wie schaltet man burstRx = on ? Davon habe ich keine Ahnung :-(
set <deviceName> regSet burstRx on
Auf die Eingabe
ReadingsVal('Thermostat_WZ_ClimRT_tr','desired-temp','')
bekomme ich:
Unknown command ReadingsVal('Thermostat_WZ_ClimRT_tr','desired-temp',''), try help.
Was ist falsch?
LG, Bernd
Zitat von: stpkle schrieb am Do, 10 Oktober 2013 00:15ReadingsVal('Thermostat_WZ_ClimRT_tr','desired-temp','')
Richtig muss es lauten:
{ ReadingsVal('Thermostat_WZ_ClimRT_tr','desired-temp','') }
Die Eingabe:
{ ReadingsVal('Thermostat_WZ_ClimRT_tr','desired-temp','') }
gibt zwar keine Fehlermeldung, aber wo sehe ich jetzt das Ergebnis?
Cioa, BK
set <deviceName> regSet burstRx on
Danke!
Zitat von: stpkle schrieb am Do, 10 Oktober 2013 00:21Die Eingabe:
{ ReadingsVal('Thermostat_WZ_ClimRT_tr','desired-temp','') }
gibt zwar keine Fehlermeldung, aber wo sehe ich jetzt das Ergebnis?
Cioa, BK
Ausgabe erfolgt unmittelbar nach der Eingabe.
Wenn FHEM aber noch keine Werte hat, weil das Thermostat vielleicht noch nicht gepairt ist, dann bekommst natürlich auch nichts zurück. ;-)
@Mr. P
sehr wenig info zum Disconnect
sicher ist,dass zwischen den beiden disconnects quasi nichts los ist.
Auch ein timeout schiedet aus.
Der Disconnect wird von DevIo erkannt - es fällt wohl die tcp-session runter.
Wer das initiiert weiss ich nicht. Warum HMLAN dies machen soll ist unklar, es passiert ja nichts von FHEM seite.
Gruss Martin
Hallo Zusammen,
ich habe mir auch dieses Termostat besorgt.
ich habe diesen Regler heute morgen angebaut und bekomme die ganze Zeit nur
protCmdPend 14 CMDs_pending.
nach einiger Zeit bekomme ich bei Activity nur noch Dead angezeigt.
Ich glaube ich stehe aktuell total auf dem Schlauch.
Was muss ich machen ,dass es läuft so wie bei den anderen ?!?!
Hej deluxe41,
auch an dich die Frage:
Hast du das Gerät vorher gepairt?
also einfach in der Konsole:
set <hmLAN> hmPairForSec <sec>
eingeben und dann binnen der definierten Zeit auf dem Thermostat den Anlernknopf drücken.
Ab dem Zeitpunkt sollte FHEM mit dem Gerät "sprechen" können. ;-)
Guten Morgen Mr. P
Ja, das habe ich.
ich bekomme, nach dem ich "set CUL_HM_HM_CC_RT_DN_21C2AD pair" nur noch RESPONSE TIMEOUT:SerialRead.
Nachdem ich selbst auch erst kürzlich angefangen habe, mich mit HM zu beschäftigen, kann ich noch nicht allzu viel anbieten und hätte vorgeschlagen, einfach das Device einmal komplett aus der Config zu entfernen, den Thermostat selbst auf Werkseinstellungen zurück zu setzen und dann ganz frisch mit 'pairForSec' in FHEM anlernen.
Allerdings habe ich parallel dazu auch diesen aktuellen Thread gefunden, wo es ähnliche Probleme, jedoch mit einem anderen Device gibt.
http://forum.fhem.de/index.php?t=msg&goto=98624&rid=45&srch=RESPONSE+TIMEOUT%3ASerialRead#msg_98624 (//forum.fhem.de/index.php?t=msg&goto=98624&rid=45&srch=RESPONSE+TIMEOUT%3ASerialRead#msg_98624)
Vielleicht einfach mal abwarten, bis Martin wieder vorbei kommt... der kann sicher konkretere Vorschläge machen und Ideen äußern, als ich das gerade tue. ;-)
Hallo,
jetzt muss ich mich doch auch mal wieder zu Wort melden.
Irgendwie bin ich ja scheinbar nicht der einzige, der solche Meldungen (disconnect) vom HMLAN bekommt. ich kann wirklich nachvollziehen, dass diese Meldungen erst nach dem Update (update in fhem) am Samstagmittag den 05.10. auftraten. Ob es nur in direktem Zusammenhang mit dem Update steht oder mehrere Faktoren eine Rolle spielen (ich hatte am Vormittag weitere Thermostate installiert) kann ich nicht sagen. Wenn ich mir das log-file anschaue, so kommt es häufig nachts, wenn wenig los ist, zu einer Häufung der Meldungen.
Für sachdienliche Hinweise bin ich sehr dankbar, da das System teilweise verzögert reagiert und somit manche Funktionen zeitverzögert ausgeführt werden.
Gruß
Burchard
ja, das habe ich gerade nochmal gemacht.
-alle Einträge des Termostates aus FHEM entfernt,
-Termostat auf Werkszustand versetzt,
-set CUL1 pairForSec 600
-anlernen am Termostat aktiviert
Wie es scheint werden die protCmdPend 14 CMDs_pending nicht abgearbeitet.
Ist das Termostat nicht richtig mit mit fhem gepairt ?
Es ist ja heute nicht das erstemal, dass ich einen Homematic aktor mit fhem verbinde, aber diesmal ist irgendwie der Wurm drin.
Ich bedanke mich schonmal im Vorfeld !!
@deluxe41
die kommandos werden abgearbeitet, wenn
a) config(anlernen) gedrückt wird
b) das device aufwacht (nacht es nur, wenn es gepairt ist)
c) burstmode eingestellt ist und beantwortet wird.
ich bin mir ziemlich sicher, dass es noch nicht angelernt ist. das kannst du zum einen sehen wenn "pairedTo" korrekt angezeigt wird und zum anderen am thermostat. An thermostat sollte das funk-symbol stehen und im menue verschwindet die option zum löschen der peers.
ggf einmal den Stack löschen, damit nichts verstopft:
set <rt> clear msgEvents
dann pairforsec wie vor erwähnt und anlernen drücken
ein getConfig abschicken und pairedTo prüfen
getConfig kann so 3 min pending sein, da burstRx = off und das device so lange schläfchen hält
@Buri - disconnects
wie schon erwähnt - ist mir nicht klar. meiner ist stabil.
müssen wir einmal fakten sammeln:
- welche module sind aktiv in eueren setups?
- welche IOdevices sind in betrieb - ausser HMLAN?
- welche Platform? FB oder andere?
Ich gehe davon aus, dass der trigger/die Erkennung immer von DevIo kommt. Das heisst dann, dass der socket wohl die Verbindung abgebrochen hat - und das ohne weitere Kommandos von CUL_HM oder HMLAN.
müssen wir forschen...
Gruss Martin
Hallo Martin,
wo finde ich denn die Option PairedTo ?
Hallo Martin,
ich betreibe fhem auf einem RPI und habe den HMLAN direkt am Router laufen, vorher war am Switch im Arbeitszimmer. Ich werde ihn heute abend mal wieder umstecken und schauen ob es daran liegt.
Folgende Devices sind im Betrieb
8 Thermostate von denen 4 mit Innentemperatursensoren gepeer sind und zwei mit Fensterkontakten.
2 Fensterkontakte, die noch nicht gepeert sind; werden noch montiert.
2 Bewegungsmelder innen
1 4fach-Schalter für Hutschiene
2 Bewegungsmelder für außen
1 Unterputzaktor 1 Kanal
1 Außentemperatursensor
1 Statusanzeige (16 LEDS)
Ein paar Testdevices, die aber wieder entfernt wurden.
Gruß Burchard
pairedTo ist ein Reading. da wird aus dem Device einiges ausgelesen unter anderen ob und mit welcher HMID eine Zentrale angelernt ist.
Eigentlich ist es das Register "pairCentral".
Das Problem an der Geschichte ist, dass FHEM/HMLAN Daten nicht oder nicht immer auslesen darf, wenn es nicht als Zentrale eingetragen ist. daher könnte das lesen an sich schon schief gehen.... gerade hier ist es ein henne/ei Problem.
Nach dem Verhalten ist dein RT nicht gepairt - aber schaue doch auf dessen Anzeige - und porbiere das pairen noch einmal.
hmPairForSec hat bei meinen gut funktioniert
hmPairSerial kannst du auch probieren
Gruss Martin
@deluxe41
Zitatwo finde ich denn die Option PairedTo ?
unter den Readings des Device selbst...
Hallo,
ich habe nochmal alles auf anfang gesetzt.
So sieht es aktuell bei mir aus.
Mmh, wo liegt der Fehler...
man man man...ich stell mich ja an hier...
Drück halt mal die Konfigurationstaste am Thermostaten, damit die 32 rumhängenden Befehle auch irgendwann mal an das Gerät übertragen werden.
Von einem erfolgten pairing sehe ich aber irgendwie keine Spur.
Hallo Deluxe41,
das Verhalten hatte ich gestern auch - meine es wie folgt gelöst zu haben:
1) set <rt> clear msgEvents | bei dir ist die queue verstopft (siehe die noch 32 ausstehenden cmd's)
2) Prüfen, ob die queue leer ist => Reading "protcmdsPend" müsste was von CMDs_cleared oder 0 stehen => weiß es aber nicht mehr so genau?
2) set <hmlan> hmPairSerial KEQ0579448 (bitte die Seriennummer prüfen)
3) dann die Anlerntaste auf dem RT drücken -> dann ein wenig warten -> bis die CMDs abgearbeitet sind.
Kannst es ja mal versuchen - bei mir hat das so funktioniert.
Viele Grüße
Arthur
Hallo betateilchen,
ich glaube ich habe es jetzt, gerade hat es geklappt.
Ich kann mich noch daran erriner, dass ich das selbe mit meinem Magnetkontakten hatte.
Ich muss bei mir warscheinlich ziemlich häufig versuchen zu Pairen, ich glaube bei dem Termostat habe ich es ca. 40 mal versucht.
Erst jetzt von ca. 5 Minuten habe ich die Meldung "AC" bekommen.
Da haut bestimmt was anderes nicht bei mir hin ;)
Ich danke euch vielmals !!
Zitat von: deluxe41 schrieb am Do, 10 Oktober 2013 13:46ich glaube bei dem Termostat habe ich es ca. 40 mal versucht.
...
Erst jetzt von ca. 5 Minuten habe ich die Meldung "AC" bekommen.
Vielleicht hast Du beim Experimentieren während des Einrichtens einfach soviel Funktraffic erzeugt, dass der HMLAN in "overload" ging und erstmal gar nix mehr gesendet hat.
Ich habe nun auch zwei HM-CC-RT-DN. Im fhem-Log fällt mir auf, dass immer ein Eintrag
Batteriewarnung batteryLevel: 2.9 V
vorhanden ist. Die eigentliche Warnung ist jedoch bei 2.1 V konfiguriert.
Wieso erscheint diese Batteriewarnung?
das ist eine messung, keine Warnung.
Die Warnung ist battery:low
Zitat von: hypnorex am 12 Oktober 2013, 17:22:09Wieso erscheint diese Batteriewarnung?
Weil Du das notify für die Batteriewarnung 1:1 aus dem WIKI abgeschrieben hast, und das funktioniert mit dem RT nicht mehr.
Ändere mal Dein notify so ab:
.*:[Bb]attery:.* { if("%" !~ m/ok/) { Log 3, "@: Batteriewarnung %"; } }dann sollte das Logging wieder passen.
Vielen Dank, das war die Ursache.
Hallo,
als lang mitlesender Neuling möchte ich nun einmal danke, insbes. an Martin, sagen.
Ich hatte eben mit nur 4 RTs, 2 Fensterkontakten und einem HMLAN auch das Problem, dass der HMLAN beim Setzen der desired-temp oder noch schneller beim setzen der Temperaturlisten in den Overload gegangen ist und die Änderungen nicht bei den Thermostaten ankamen. Das Problem trat aber komischerweise nur bei 2 der 4 Thermostate auf, nämlich der, die ich zum Schluss installiert hatte.
Ich habe dann aus dem SVN die heute aktuelle Version des CUL_HM-Moduls gezogen und dann gesehen, dass bei den 2 Thermostaten, die gut performten, ich wahrscheinlich im Zuge des endlosen rumprobierens den Burst-Modus aktiviert hatte und bei den anderen nicht. Bei den anderen gingen die Kommandos einfach nicht durch, es kamen Missing_ACKs und irgendwann war der HMLAN dadurch dicht und es ging gar nichts mehr. Mein Vorgehen für alle Anfänger wie mich, die es einmal an einer Stelle haben wollen:
Per ssh:
cd /opt/fhem/FHEM/
sudo wget http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw -O 10_CUL_HM.pm
sudo /etc/init.d/fhem stop
sudo /etc/init.d/fhem start
Dann in Fhem:
set <RT> regSet burstRx on (für jeden Thermostaten und ggf. Mehrfach und vorher den HMLAN mal kurz vom Strom trennen).
Richtiges Pairing vorher beachten!
Jetzt, wo alle Thermostate dadurch auf protCondBurst = on stehen, geht es super.
Meine Vermutung: Martin hatte in irgendeinem anderen Thread einen Load-Test mit dem HMLAN gemacht und kam irgendwie auf 600 Befehle / Zeiteinheit. Ich vermute laiisch, dass MISSING-ACKs den Overloadzähler von dem Ding schneller erhöhen. Anders kann ich mir nicht erklären, dass nach einem Reset und ca. 3 Versuchen, die Temp-Listen ohne Burst-Modus draufzuspielen beim HMLAN schluss ist ... ist aber nur ne auf Halbwissen basierende Vermutung.
P.S.: Die aktuelle Ausgabe von HMInfo hätte ich gern angefügt, aber nach dem Checkout aus dem SVN läuft das nicht mehr und wirft lauter Fehler beim restarten des fhem-services, da müsste ich erstmal noch gucken warum ...
Hi,
kurze Info
ich werde in kurze eine neue Version herausgeben - und eine Erklärung dazu, da es zu ein paar änderungen kommen wird.
Ein Problem ist der Burst mode, einiges von der HMLAN-stunden-performance auffrisst. Insbesondere wenn es nicht klappt.
Daher wird der burst-wakeup per default ausgeschaltet, das "austesten" ist ein klares Performance-problem. Es kann zu overload führen, wenn zu viele dieser Devices an start sind.
Der User muss es also je device ein "burstAccess 1_auto" setzen, will er burst nutzen. default, wenn das Attribut nicht gesetzt ist, ist "0_off".
Mehr in einem neuen Thread
Gruss Martin
Besteht eigentlich noch Erkundungsbedarf, was das Reading Unknown0 angeht? Ich habe mir das heute mal plotten lassen ... siehe Annhang. Zur Erklärung: Bad(klein) hat noch keinen Fensterkontakt und entsprechend drehe ich bei Lüften ggf. mal die Solltemperatur am Drehrad runter, und wenn ich das fenster schließe, drücke ich ein paar mal auf die linke Taste, bis er wieder im Automodus bei der ursprünglichen Soll-Temp ist ... und offensichtlich in diesem Zusammenhang ändert sich unknown0 - wird aber nur größer. Bei allen anderen Thermostaten (Mit fensterkontakt) habe ich konstant unknown0 = 24... Es könnten also die gedrehten Ticks am Stellrad sein, was ja genial wäre...
Anderer Gedanke: Könnte vllt. auch die Zeit in Minuten sein, die er intern ein WindowOpen erkannt hat....
OK das Drehen am Stellrad ist es schonmal nicht ... gerade verifiziert ;)
Zitat von: peterk_de am 14 Oktober 2013, 23:20:00Könnte vllt. auch die Zeit in Minuten sein, die er intern ein WindowOpen erkannt hat.
Der Wert ändert sich nicht, wenn das Fenster aufgeht.
Betateilchen: Du hast recht. Gerade geprüft. Mit folgender Erkenntnis: Er erhöht sich, wenn man während der internen Fenster-Auf-Erkennung die Temperatur per Stellrad verändert:
Vorher lag unknown0 bei mir bei 44; der Soll-Wert war 12 Grad (Absenktemperatur, da Offenes Fenster erkannt). Nach Hochdrehen der Solltemperatur am Thermostaten auf 20 Grad (während das Fenster noch als offen im Thermostat angezeigt wurde) war unkown0 bei 47.
Das ist zwar im Grunde leider ein völlig nutzlose Information ... aber ... öhm ... na ich wollte im Rahmen meiner Möglichkeiten auch mal was beitragen ;)
Hallo FHEM Community,
ich stehe gerade am Anfang mit dem Thema Heimautomatisierung und wollte mit der Heizungssteuerung starten.
Zum Anfang habe ich mir ein COC Modul für nen RPi besorgt und ein HM-CC-RT-DN.
Das Pairing hat auch wunderbar geklappt und ich kann das Thermostat auch ansteuern und bekomme die gemessenen Werte zurück. Was mir aber in den Log´s aufgefallen ist, dass im 3 Minuten Intervall die Temperatur abgefragt wird. Lässt sich das ändern? Mir würden da z.B. 10 oder 15 Minuten reichen. Schont sicher auch ein wenig die Batterien.
@peterk_de: Wie bekommst du die Plots so hin? Da steig ich auch noch nicht wirklich durch.
Viele Grüße
Jan
Hallo Jan,
lässt sich nicht ändern. das ist auch die Zeit der Regelung - und wenn nur alle 15min geregelt würde wäre das eher negativ.
zu den Plots musst du erst die readings in ein file loggen, welches dann ausgewertet wird
define mylog FileLog <logfile> rc_Clima:.*T:.*
so in der art
dann im webInterface aufmachen und CreateSVG_Plot drücken
Gruss Martin
Zitat von: Jan am 15 Oktober 2013, 22:38:18Was mir aber in den Log´s aufgefallen ist, dass im 3 Minuten Intervall die Temperatur abgefragt wird. Lässt sich das ändern? Mir würden da z.B. 10 oder 15 Minuten reichen.
Die Temperatur wird nicht aktiv abgefragt, sondern autark vom RT in diesem Rhythmus regelmäßig ausgesendet.
Hi,
vielen Dank für die Antworten. Gibt es denn schon irgendwelche Erfahrungen wie lange ein Satz Batterien hält? Oder was wurde bei dem Vorgänger Modul für eine Laufzeit erreicht?
@martinp876: Das mit dem Plot hat super funktioniert. Danke
Viele Grüße
Jan
Hallo Zusammen,
auch wenn ich jetzt vielleicht der Tausendste bin, der die Frage stellt, aber ich habe nichts gefunden was mir weiterhilft.
Ich habe einen Fensterkontakt erfolgreich an den HM-CC-RT-DN peeren können:
set Fnstr_Bad peerChan 0 Hzkp_Bad_WindowRec single
In der peerList beim WindowRec sehe ich dann auch den Sensor.
Sollte jetzt nicht beim Öffnen des Sensors automatisch die Window-Open-Funktion ausgelöst werden???
Danke für Aufhellung und Grüße
Christoph
@CQuadrat genau. Es erscheint dann auf dem Thermostat nach ner gefühlten Sekunde unten links ein kleines Fenstersymbol und die Temperatur aktualisiert sich im Display auf die Absenk-Temperatur (default: 12 Grad). Ich hab grad aber auch wieder Ärger nen neuen Fensterkontakt anzulernen - so richtig flutschen tut das noch nicht. Da es aber schon ein paar mal geklappt hat bin ich grad sehr geduldig :-)
Zitat von: peterk_de am 16 Oktober 2013, 23:23:25
@CQuadrat genau. Es erscheint dann auf dem Thermostat nach ner gefühlten Sekunde unten links ein kleines Fenstersymbol und die Temperatur aktualisiert sich im Display auf die Absenk-Temperatur (default: 12 Grad). Ich hab grad aber auch wieder Ärger nen neuen Fensterkontakt anzulernen - so richtig flutschen tut das noch nicht. Da es aber schon ein paar mal geklappt hat bin ich grad sehr geduldig :-)
Leider bei mir nicht. :-\
Trotz großer Geduld :'(
CQuadrat, hattest du eigentlich mit deinem HM-WDS10-TH-O (siehe Signatur) mehr Erfolg beim Peeren mit dem Thermostat? Ich hab heute auch eins bekommen aber trau mich kaum es zu versuchen ;)
Edit: Sorry das is ja der für außen ... ich hab den -I für innen.
Ich habe weiter oben gelesen, dass peerNeedsBurst=on sein muss.
Bei mir ist der Status schon seit Stunden set_on und ich habe 9 CMDS_pending.
Ich warte einmal bis morgen ab, was da noch passiert.
du redest von Fensterkontakt?
der meldet sich nicht von selbst - du musst einmal kurz anlernen drücken - nur dann ist fhem in der Lage die Kommandos abzusenden.
wenn du im SC cyclic-info-message einschaltest sollte sich der regelmässig melden. Leider wacht er da nicht korrekt auf (meines Wissens, ich habe leider keinen zum testen). Somit bleibt nur der Anlernknopf - bis wie das Aufwachen verstehen...
Hey CQuadrat,
ich habe an exakt der gleichen Stelle gehangen wie du und mir gerade die aktuellen Updates aus dem SVN gezogen - nun gehts problemlos!
Unter Linux:
cd /opt/fhem/FHEM
sudo wget http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?format=raw -O 10_CUL_HM.pm
sudo wget http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/98_HMinfo.pm?format=raw -O 98_HMinfo.pm
cd /etc/init.d/
./fhem stop
./fhem start
Dann in FHEM neu paaren und ab gehts:
set HMLAN hmPairForSec 100
--Paarungstaste am Fensterkontakt drücken, dann blinkt er kurz gelb-grün--
set bad.klein.fenster peerChan 0 bad.klein.thermostat_WindowRec single
-- nun mal nochmal kurz die Paarungstaste drücken--
Und schwupps - Fertig - läuft wie geölt!
Ich glaube, dass ich nach dem pairen zu früh gepeert hatte und der Sensor so noch nicht "vollständig" gepairt wurde: die Register expectAES und peerNeedBurst stehen noch auf set und das lässt sich auch nicht ändern. Außerdem heißen die Register R-Hzkp_Bad_WindowRec-expectAES und R-Hzkp_Bad_WindowRec-peerNeedsBurst. Ist das korrekt?
Wenn ich nachträglich mit
set Fnstr_Bad regset peerNeedsBurst on
das Register nochmal schreiben will, kommt die Fehlermeldung
Peer not specified.
Ich probiere es heute Abend nochmal neu aus.
erstens hast Du regset falsch geschrieben (das heißt nämlich regSet), zweitens hast Du in der Tat keinen Peer angegeben und drittens musste ich diese Parameter überhaupt noch nie verändern, damit die Fensterkontakte korrekt mit dem Thermostaten funktionieren.
Zitat von: betateilchen am 17 Oktober 2013, 09:49:55
erstens hast Du regset falsch geschrieben (das heißt nämlich regSet), zweitens hast Du in der Tat keinen Peer angegeben und drittens musste ich diese Parameter überhaupt noch nie verändern, damit die Fensterkontakte korrekt mit dem Thermostaten funktionieren.
Aha.
Und wie ist dann die Syntax? So:
set Fnstr_Bad regSet peerNeedsBurst <device>_WindowRec onNaja, ändern will ich die, da hier set_on als Inhalt steht. Das heißt doch, dass noch nicht geschrieben wurde. Oder?
nein, diese Meldungen mit set_ am Anfang sind ein völliger Krampf, weil in > 80% der Fälle diese Anzeige schlichtweg falsch ist. Teilweise ist die Änderung längst erfolgt und es steht immer noch set_ da...
Die Syntax sieht schon besser aus, ich kann Dir allerdings nicht genau sagen, wierum die Peers angegeben werden. Ich habe diesen Befehl erst einmal gebraucht, das war aber vor längerem bei einem TC, der nicht so richtig mit dem FEnsterkontakt zusammenarbeiten wollte.
Bei einem RT, wie hier im Thread, hat das Peeren der Fensterkontakte bei allen 6 Kontakten und 3 RT in meiner Wohnung automatisch funktioniert und die richtigen Werte gesetzt.
leider falsch siehe commandref (dafür ist es eigentlich gedacht...)
regSet <regName> [prep|exec] <value> <peerChannel>
merken kann man es sich, da peerChannel weggelassen werden kann, wenn es ein register ohne peers ist.
prep/exec sind optional -( da es feste Begriffe sind kann ich sie auch an dieser stelle erkennen)
"set_" bleibt - auch bei Registern - so lange in den readings bis es durch lesen bestätigt ist -alles andere wäre raten.
Du musst also entweder ein getConfig nachschieben (für Freunde des manuellen betriebs) oder autoRegRead auf 4 setzen, dann geht es automatisch.
Das Lesen kann ggf dauern - beim TC bis zum nächsten erwachen, set burtsXmit (falls eingerichtet), HMLAN load leven,...
set Fnstr_Bad regSet peerNeedsBurst on <device>_WindowRecGruss
Zitat"set_" bleibt - auch bei Registern - so lange in den readings bis es durch lesen bestätigt ist -alles andere wäre raten.
Wozu hat Homematic ein bidirektionales Protokoll, wenn ich nach jedem Befehl erstmal das Device fragen soll, ob es auch das getan hat, was ich ihm gesagt habe? Wenn ich ein Kommando abschicke und das Device die Nachricht bestätigt, muss ich davon ausgehen können, dass alles ok ist. DAS erwarte ich von einem bidirektionalen Protokoll. Alles andere macht für mich keinen Sinn.
Zitat von: martinp876 am 17 Oktober 2013, 12:40:01
leider falsch siehe commandref (dafür ist es eigentlich gedacht...)
Schon richtig...
Aber vielleicht sollte man die deutsche Commandref abschalten. Dort steht das nämlich nicht drin. Die deutsche Commandref wird vermutlich nicht gepflegt.
Naja, ich hätte ja auch suchen können...
Zitat von: CQuadrat am 17 Oktober 2013, 14:28:04Die deutsche Commandref wird vermutlich nicht gepflegt.
Die commandref wird weder in deutsch noch in englisch explizit gepflegt, sondern aus dem Dokumentationsteil innerhalb eines Modules automatisch generiert. Für die Einbindung eines Moduls in fhem ist der englischsprachige Teil dieser Doku Pflicht, der deutsche ist optional. Deshalb gibt es für manche Modul eben nur eine englischsprachige Dokumentation. Aber zumindest diese englische Variante müsste für JEDES Modul vorhanden sein.
ZitatWozu hat Homematic ein bidirektionales Protokoll, wenn ich nach jedem Befehl erstmal das Device fragen soll, ob es auch das getan hat, was ich ihm gesagt habe? Wenn ich ein Kommando abschicke und das Device die Nachricht bestätigt, muss ich davon ausgehen können, dass alles ok ist. DAS erwarte ich von einem bidirektionalen Protokoll. Alles andere macht für mich keinen Sinn.
guter Gedanke -leider nicht real. Mann kann ganze Blöcke von Kommandos absetzen - und wenn einer schief geht, was dann? wieder alles rückwärts rechnen?
auch Stati gehen mit unter verloren - HM devices senden per default 3mal - und das reicht nicht immer.
Aber richtig ist: wenn das Ack incl status kommt wird das set_ entfernt. wenn es nicht kommt ist der Zustand unklar - kam das Kommando nicht am device an oder das ACK nicht bei FHEM?
Bei registern - welche wohl nur selten in notifies verwendet werden - sollte ein set_ sowieso nicht stören sondern helfen. Insbesondere da "prep" vorhanden ist.
Bei wakeup-device gibt es m.E. sowieso keine Diskussion. Der Zustand "set_", also "change in progress" hat hier quasi immer eine längere Lebensdauer.
Ich bin hier langsam am verzweifeln:
- Fensterkontakt nochmal in den Anfangszustand zurückversetzt
- Neu gepairt -> Statusänderungen können in Fhem nachverfolgt werden
- gepeert mit _WindowRec-> auch das sehe ich in Fhem
aber: keine Reaktion am Thermostat >:(
@CQuadrat kannst du eigentlich am betroffenen Thermostaten die desiredTemp per fhem so setzen, dass er sie umsetzt? (Also im Display anzeigt)?
was du alles sehen solltest:
- fenster ist gepeert, RT_windowRec ist gepeert
- fenster hat "peerneedsburst" gesetzt (sonst wacht der RT nicht auf)
- fenster sendet beim öffnen einen trigger an den RT - notify und readings sind in FHEM zu sehen.
peerneedsburst sollte automatisch gesetzt werden... wenn nicht, lass es mich wissen
Man sollte das Fenster-symbol im RT sehen
Gruss Martin
Zitat von: peterk_de am 17 Oktober 2013, 18:50:26
@CQuadrat kannst du eigentlich am betroffenen Thermostaten die desiredTemp per fhem so setzen, dass er sie umsetzt? (Also im Display anzeigt)?
Ja. Aber das dauert heute sehr lange (an allen Thermostaten). Ich kenne das eigentlich nur so, dass die Änderung fast sofort erfolgt.
das automatisch senden durch burst ist per default aus. du kannst es freigeben (attr burstAccess) oder durch das Kommando set burstXmit triggern.
@CQuadrat
Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.
Danach geht's eigentlich generell...
Hat eigentlich sich schoneinmal jemand mit dem Feintuning mit des Teils etwas intensiver befasst?
Ich hab heute mal mitgeplottet. Umstände: Außentemperatur 9-14 Grad, Altbau, Zimmer ca. 30m², mit der zusätzlichen Regelungs-Schwierigkeit einer unverschlossenen Treppe in ein darüberliegendes Zimmer (Maisonette, dort läuft der gleiche Thermostat mit identischem Programm)
Das oben ist die Kurve vom HM-CC-RT-DN mit Programmtabelle und Lüftungsknick morgens. Der läuft jetzt eine Woche und ist noch komplett "default" was die Regelung angeht, Offset ist 0,0K. Das unten ist ein HM-WDS10-TH-I mitten im Raum in ca. 1,5m Höhe.
LG Peter
Zitat von: martinp876 am 17 Oktober 2013, 19:06:58
- fenster hat "peerneedsburst" gesetzt (sonst wacht der RT nicht auf)
peerneedsburst sollte automatisch gesetzt werden... wenn nicht, lass es mich wissen
Da scheint es irgendwie zu hängen. Ich sehe:
R-Hzkp_Bad_WindowRec-peerNeedsBurst set_on 2013-10-17 21:37:51Und das bleibt auch so.
@CQuadrat
also das sollte sich ändern - und mit getConfig sollte das set_ verschwinden.
nach getConfig ist der Hzkp_Bad_WindowRec in der peerList - korrekt?
wenn nicht bitte expert auf 2 setzen und ein "list" posten
@Peter,
meiner schwingt auch etwa in der Form - mit unter sogar, wenn das Ventil NICHT aufmacht.
man sollte es über die P und I werte glätten können. Ich denke I zu Verkleinern sollte die schwinger niedriger machen...
ob das zusammen mit auto-einstellung der Regelung funktionert... keine Erfahrung
Zitat von: rtv am 17 Oktober 2013, 21:07:20
@CQuadrat
Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.
Danach geht's eigentlich generell...
So, jetzt hatte ich die Faxen digge und es genau so gemacht, wie es rtv vorgeschlagen hat.
Und jetzt funzt es 8)
Nachtrag:
Nur
winOpnTemp
scheint nicht am Thermostat übernommen zu werden. Dort bleiben immer 12.0 °C stehen, wenn das Fenster geöffnet wird.
Frage:
ist das Register gesetzt und mit getConfig verifiziert? und trotzdem klappt es nicht?
nur das sich es probieren kann. Setzen hat gerade funktioniert
Zitat von: martinp876 am 18 Oktober 2013, 12:22:33
Frage:
ist das Register gesetzt und mit getConfig verifiziert? und trotzdem klappt es nicht?
nur das sich es probieren kann. Setzen hat gerade funktioniert
Ja, Register ist gesetzt und per getConfig auch verifiziert.
Am Thermostat bleibt aber die 12°C-Voreinstellung stehen.
Hi,
habe es gerade ausprobiert - da hast du recht. Parameter stimmen aber alle, ich kann keinen Fehler erkennen.
schade...
Gruss Martin
Zitat von: martinp876 am 18 Oktober 2013, 19:31:20
Hi,
habe es gerade ausprobiert - da hast du recht. Parameter stimmen aber alle, ich kann keinen Fehler erkennen.
schade...
Gruss Martin
Das ist blöd.
Kann das an der Firmware liegen?
entweder ist die Angabe im xml-file incorrekt oder die FW hat einen Fehler.
Ich denke nicht, dass es mit den modi zu tun hat und sehe sonst nichts, was für mich sinn macht.
habe gerade nachgesehen, es gibt eine SW 1.511 -
nein, leider keine Änderung -evtl mal bei ELV nachfragen... wenn die das gleiche Problem haben, hat sicher schon einer gemeckert. Wenn nicht, müssen wir ein Problem in FHEM lösen...
Gibt es eigentlich etwas neues zum Peering? Ich habe in meinem Wohnzimmer 4 Thermostate, habe sie alle auf einen Thermostat gepeert - diese tauchen dort auch in der Peerlist auf (im jeweils anderen Thermostat taucht der andere auch auf, jeweils ClimaTeam gegen RT, wie hier auch beschrieben).
Trotzdem sehe ich keinen Funktionsunterschied. Ich möchte natürlich mein Programm nur auf einem einzigen Thermostat ablegen und die anderen sollen jeweils mitschalten. Das tun sie aber leider nicht :-(
Woran könnte das liegen?
Liebe Grüße
Markus
Wenn ich den Night-Modus einschalten will, springt er leider immer auf Auto zurück. Der Party-Modus dagegen funktioniert.
Hab ich da etwas falsch bverstanden, bzw. schaltet sich dieser nur automatisch mit den in tempList vorgegebenen Zeiten ein?
Der Manuelle Modus ist ja, wenn ich es korrekt mitbekommen habe, in den letzten Versionen wieder verschwunden?
@Markus
nach meinen erfahrungen gehen team-member immer davon aus, dass sie ihre Kollegen benachrichtigen müssen, wenn LOKAL etwas geändert wird.
Wenn sie eine Anweisung über Funk empfangen schicken sie diese nicht weiter. Die Zentrale muss also alle einzeln benachrichtigen.
Jede Änderung vor-Ort hingegen wird weitergereicht.
@JoeALLb
Night und Day sind ja quasi nur begrenzt modi - auch wenn sie mit diesem Kommando eingegeben werden (will HM so...) da wird (so lese ich es) eine Temperatur eingestellt, quasi manuell. Nur dass der Wert schon definiert ist. Wenn du im Auto-mode bist (der verändert sich ja nicht) wird zum nächstenSchaltpunkt die Temp geändert.. In Manu sollte es bleiben.
=>? ist es dass, was passiert?
den manu-mode gibt es noch - ist ControlManu - und man muss eine Temperatur mitgeben (daher ein anderes Kommando in FHEM)
Party ist hingegen tatsächlich ein Mode - er ist auch klar mit Zeiten abgegrenzt.
Gruss Martin
Kann der RT inzwischen irgendwie sinnvoll mit dem TC gekoppelt werden?
nicht direkt, denke ich. Man könnte versuchen die temp-readings des TC dem RT unterzujubeln. Geht aber nur über die Zentrale. Der TC wird den RT nicht "aufwecken".
wenn man aber den RT über die Zentrale "regeln" will braucht man ein alle 2,5min ein Kommando = ~24/h.
"burst -wecken" des RT sollte man dann nicht nutzen, da es ganz schnell zu HMLAN overload kommen wird.
Also nicht wirklich einfach.
Genau, für den Night und den Day-Modus kann man ja Temperaturen voreinstellen. Diese werden (lt. meinem Test) auch für die Anzeige der Heizzeiten im Automatikmodus am LCD-Display(unten die langen Balken) des Reglers verwendet.
Ich habe aktuell den Partymodus eingestellt und wollte NICHT in den Automatikmodus wechseln, sondern in den Night-Modus. Da dort 17° voreingestellt sind, erwartte ich, dass er auf diese Temperatur geht. Stattdessen wechselte er in den Modus Auto.
Und was ist mit dem Urlaubmodus, den ich am Regler selbse einstellen kann? Ist dies eine Art "Dauermanueller Modus" mir den wöchentlichen Entkalkungsfahrten?
@Martin
Vielen Dank für die Antwort. Verstehen tue ich es aber immer noch nicht. Welchen Sinn macht es denn, die Geräte in FHEM zu peeren, wenn nur lokale Änderungen weitergegeben werden? Aber auch das funktioniert bei mir nicht - ich kann am Regler drehen wie ich will, die anderen ändern sich nicht.
Wie kann man eine zentrale synchrone Steuerung in FHEM erreichen? Mit STRUCTURE?
Kann man da z.B. Mittels Templist die Programme für alle Regler gleichzeitig vorgeben.
Später würde ich ja gerne alles über Google Steuern, aber das erscheint mir noch zu schwierig.
Vielen Dank und einen schönen Abend
Markus
@JoeALLb,
party und Urlaubsmode ist identisch.
Manueller mode schaltet die automatische temperatureinstellung ab - sprich der RT schaltet nicht mehr mit templist um, wenn ein Schaltzeitpunkt erreicht wäre. Die Temp bleibt bis zum Sankt-nimmerleinstag. decalc und Fenser-offen sollten noch funktionieren.
party/Urlaub ist eine zeitlich begrenste Einstellung - quasi auch auf manuell. Unterschied ist, dass du vorab einstellen kannst, wann er eingeschaltet wird und wann wieder aus. Also in einer Woche fahre ich in Urlaub und bleibe 2 Wochen. kann ch heute schon setzen.
@Markus
ich hatet auch mit einem "team" getestet - egal wie ich gepeert hatte - die Änderungen gingen immer nur in eine Richtung. Einer der beiden wollte nie senden.
Die denke ist m.E. einfach (kommt nicht von mir, ist eQ3-gegeben):
die Zentrale kann/muss änderungen immer an alle geben. Die RTs sollen da nicht reinpfuschen. Das ist eine Klare vorgaben und verhindert mehrfach senden.
Der RT sendet nur, wenn die Zentrale dies nicht "kann", also wenn die Änderung im RT getriggert wird.
Man kann sicher etwas mit structure machen. Ich habe mir ein notify gemacht - am einfachsten wenn man strukturierte Namen hat:
h_wz_f1 :Heizung im Wohnzimmer Fenster1
h_wz_f2 :Heizung im Wohnzimmer Fenster2
h_wz_.*_Clima:mode.* {
if ($EVTPART1 ne ReadingsVal("h_wz_f1_Clima","mode","")){
if ($EVTPART1 =~ m/(auto|boost)/){
fhem "set h_wz_f1_Clima controlMode $EVTPART1"}
elsif($EVTPART1 eq 'manu'){
fhem "set h_wz_f1_Clima controlManu ".ReadingsVal("h_wz_f1_Clima","desired-temp","")}
}
if ($EVTPART1 ne ReadingsVal("h_wz_f2_Clima","mode","")){
if ($EVTPART1 =~ m/(auto|boost)/){
fhem "set h_wz_f2_Clima controlMode $EVTPART1"}
elsif($EVTPART1 eq 'manu'){
fhem "set h_wz_f2_Clima controlManu ".ReadingsVal("h_wz_f2_Clima","desired-temp","")}
}
}
das ist jetzt für ein Zimmer. Man kann es sicher auch umbauen, dass immer alle "h_wz" gesucht und gleich geschaltet werden. Und auch alle "h_kz"... also ein notify für "alle" teams.
Die Einstellung ist, dass die Änderung erst beim nächsten "aufwachen" gesendet wird - was performance im HMLAN spart. Du kannst auch das Attribut "burstAccess" setzen oder "set burstXmit" nachschicken um die Änderung sofort wirksam zu machen
Gruss Martin
Ich habe heute Nacht noch die Lösung mittels structure gefunden, manchmal ist es ja auch einfach ;-) :
define hz.wohnzimmer structure room hz.wz hz.wz1 hz.wz2 hz.wz3
Jetzt kann ich die hz.wohnzimmer schalten wie ich will, und alle Änderungen gehen an jede einzelne Heizung raus. Vielen Dank für die Hilfe.
Was aber bisher nicht klappt, ist das manuelle Änderungen an einem Thermostat an die anderen Heizkörper weitergegeben werden. Hier tut sich einfach gar nichts. Ich habe das Peering nur in FHEM durchgeführt (hier taucht auch alles korrekt auf). Muss ich die Thermostate auch noch hardwaremässig peeren? Wenn ja, wie? Laut Bedienungsanleitung soll ich ein Gerät in den Anlernmodus bringen, danach das andere. Also habe ich bei einem Thermostat die Boost-Taste lange gedrückt, es erscheint ganz kurz 30 ohne herunterzuzählen. Wenn ich jetzt an dem anderen Thermostaten dasselbe mache sehe ich nichts.
Eine Frage habe ich noch: Kann man ein Gerät gleichzeitig in mehreren Räumen haben? Ich habe bisher Wohnzimmer, Küche und Bad. Und würde gerne einen zusätzlichen Raum Heizung haben, auf dem alle Heizkörper der Wohnung sichtbar und veränderbar sind.
Viele Grüsse
Markus
Hallo,
kann ein HM-CC-RT-DN eigentlich ein HM-CC-VD steuern oder mache ich das mit FHEM?
Gruß Otto
Hallo Otto,
bisher hat keiner es fertig gebracht den VD sicher "aufzuwecken". daher kann man den VD aus FHEM nicht steuern.
Der RT kann keine anderen Ventile steuern, auch keinen VD
Gruss Martin
@juelich, Markus
ja, auf der commandozeile.
Gib einfach
> attr xx root Heizung,Wohnzimmer
ein, dann siehst du es in beiden räumen
Zitat von: rtv am 17 Oktober 2013, 21:07:20
@CQuadrat
Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.
Danach geht's eigentlich generell...
Hat bei meinem einen Fensterkontakt, der Partout nicht wollte, geklappt - d.h. jetzt erkennt der RT das Fensteröffnen ... danke! Nur: Jetzt bekomme ich den Kontakt selbst nicht mehr im FHEM zu Gesicht, das heißt er wird nicht mehr per Autocreate wie sonst angelegt, hmPairSerial und hmPairForSec gehen auch nicht ...!?
Edit: HM-Device-ID aus einem alten Logfile gesucht, manuell definiert per define mein_tfk CUL_HM 2xxxxE - dann einmal getConfig + Anlernknopf am Fensterkontakt, nun gehts soweit... Achtung, es ist nicht exakt die Id die beim RT in der peerlist steht, bei mir wurde da eine 01 angehängt...
Noch eine Sache, die ich einem kleinen Zimmer beobachtet habe: Nach ca. 2 Wochen Betrieb haben sich die reguInt* readings verändert:
R-regAdaptive on
R-reguExtI 15
R-reguExtP 30
R-reguExtPstart 30
R-reguIntI 13
R-reguIntP 28
R-reguIntPstart 18
Das ist ein gutes Zeichen und untermauert die Theorie, dass der RT das Heizverhalten eines Raumes selbsttätig "lernt"
Zitat:
@CQuadrat
Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.
Danach geht's eigentlich generell...
Gilt das auch, um die RTs untereinander zu pairen? Wenn ja, wie mache ich einen Hardware-Reset an den RTs? Wie bekomme ich FHEM eigentlich noch einmal komplett zurückgesetzt, sprich alle Geräte noch einmal herausgelöscht? Muss man FHEM komplett löschen und neu installieren?
Liebe Grüsse
Markus
um einen RT zu löschen (komplett) einfach das device 'deleten' - dann sind auch alle Kanäle weg
Am besten save und restart oder rereadcfg
am rt kann man alle peers löschen - siehe Handbuch.
Ein reset-kommando habe ich nicht getestet - könnte aber auch Funktionieren
Vielleicht ein wenig Offtopic, ich suche die ganze Zeit etwas zur Hardware Qualität des HM-CC-RT-DN finde, aber keine Informationen. Mich würde vor allem interessieren ob der Stellantrieb genauso rappelt wie der alte oder ob die Qualität höher ist.
Bisher habe ich nur FHTs im Einsatz und überlege auf Homematic oder Max! zu wechseln. Da ich nun einige Räume habe bei denen ich keine Wandzentrale brauche, da würde mir ein autarker Stellantrieb reichen und dann ist Homematic und Max günstiger als FHT. Mir würde die Entscheidung noch leichter fallen, wenn ich wüsste wie die Wandzentrale bei Homematic aussehen wird. Die finde ich bei MAX! doch sehr elegant. Vielleicht kennt auch jemand Max und die neuen Homematic teile und kann die Vergleichen?
Danke und Grüße
strauch
Qualität ist ja da vll sehr subjektiv. Toll ist anders, mir reichts. Man hört auch wenn sie stellen. Aber mich störts nicht. Zumal man bei mir die Heizungspumpe im ganzen Haus rauschen hört (ein Grund sie abzuschalten, wenn sie nicht benötigt wird).
Kann nur anbieten ein kleines YouTube Video zu erstellen wo man sieht wie das Ding sich so verhält und sich anhört...
Ich will keine Umstände machen. Aber ein Video wäre schon interessant. Mir ist auch klar das Qualität subjektiv ist. Als Beispiel ich hab von Honeywell Antriebe die sind sehr leise und die von ELV rappeln total und das scheint bei Max! genauso zu sein wie bei FHT und den alten Homematic. Auf den Bildern sehen die neuen Homematic Komponenten schon alle etwas hochwertiger aus, aber das heißt ja nichts.
Zitat von: strauch am 21 Oktober 2013, 10:38:17Als Beispiel ich hab von Honeywell Antriebe die sind sehr leise und die von ELV rappeln total und das scheint bei Max! genauso zu sein wie bei FHT und den alten Homematic.
Die Geräuschentwicklung scheint eher zufällig verteilt zu sein. Ich hatte auch lange die Honeywell, die sind superleise (nahezu unhörbar), dann hatte ich einige FHT, die sind deutlich hörbar, wobei hier eine sehr große Schwankungsbreite bei der Geräuschentwicklung besteht. Als ich den ersten Homematic-Stellantrieb (VD) in Betrieb nahm, stellte ich fest, dass dieser wiederum leiser war als die FHT, obwohl mechanisch baugleich.
Der RT läuft auf jeden Fall leiser als die FHT (ich habe jetzt 3 RT im Einsatz, die sich da gleich verhalten), aber nicht so leise wie Honeywell. Eine Verbesserung in der mechanischen Qualität sehe ich nur in der Tatsache, dass der große Rändelring zur Montage jetzt aus Metall und nicht mehr aus Kunststoff ist. Ansonsten ist beim RT auf jeden Fall das Design "gewöhnungsbedürftig" - einen Designpreis wird eq3 damit vermutlich nicht gewinnen. Und der Batteriewechsel an der Unterseite des Antriebs ist auch nicht gerade benutzerfreundlich, eigentlich muss man den ganzen Antrieb abmontieren, um die Batterien vernünftig wechseln zu können.
Hallo zusammen
ich habe heute mal wieder ein Update (10 Tage) gemacht und musste feststellen, das meine Regler wieder sehr häufig MISSING ACK bringen. Dies hatte ich die letzten zwei Wochen nicht gehabt. Ist da schon was bekannt dazu ?
LG
Stefan
Zitat von: JoeALLb am 20 Oktober 2013, 13:07:31
@juelich, Markus
ja, auf der commandozeile.
Gib einfach
> attr xx root Heizung,Wohnzimmer
ein, dann siehst du es in beiden räumen
Das funktioniert bei mir leider nicht, es kommt "hz.wohnzimmer: unknown attribute root, choose one of verbose:0,1,2,3,4,5 room group". Ist nicht ganz so schlimm, es wäre ja nur schön, wenn man eine Übersichtsseite hätte, wo man alle Heizungen der Wohnungen aufgelistet hat und gezielt die Temperatur verändern können.
Vielen Dank an alle, die mir bisher geholfen haben. Ich habe heute Morgen noch einmal ganz von vorne angefangen, und die 4 Heizungen im Wohnzimmer hardwaremässig gekoppelt. Es funktioniert jetzt alles wie es soll. Macht es eigentlich Sinn, sie zusätzlich noch in FHEM zu peeren? Ich halte das für überflüssig, da bei der Steuerung über FHEM die Einstellungen für einen Heizkörper ja sowieso nicht an die anderen weitergegeben werden, aber vielleicht habe ich ja auch etwas übersehen.
Viele Grüsse
Markus
@betateilchen danke für deine Einschätzung
Zitat von: juelich am 21 Oktober 2013, 11:31:41
Das funktioniert bei mir leider nicht, es kommt "hz.wohnzimmer: unknown attribute root, choose one of verbose:0,1,2,3,4,5 room group".
Bisschen mitdenken vielleicht? Man muss doch nicht jeden Tippfehler
Zitat> attr xx root Heizung,Wohnzimmer
einfach gedankenlos abschreiben. Wenn Du einen room setzen willst, solltest Du selbstverständlich auch room schreiben und nicht root...
@Betateilchen
Vielen Dank, Du hast natürlich vollkommen recht.
Aber jeder Anfang ist natürlich schwer, besonders wenn man man mit dieser Materie bisher nie zu tun hatte.
Viele Grüße
Markus
@Betateilchen,
Du hast im Forum beschrieben, wie man mittels zweier Notify die Heizung über einen Google-Kalender steuern kann.
Leider komme ich damit nicht klar.
Ich habe einen Google Kalender angelegt und in FHEM eingelesen. (define Kalender_Heizung Calendar...) - das klappt auch.
Dann wollte ich mittels Deines Codes ein >Notify anlegen:
define HZ.WZan notify Kalender_Heizung:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,$dtemp,undef)= split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }
und bekomme folgende Fehlermeldung:
Unknown command my, try help.
Unknown command my, try help.
Unknown command if(defined, try help.
Unknown command }, try help.
Was mache ich verkehrt?
Es tut mir leid, wenn ich nerve, aber ich stecke noch nicht so tief in der ganzen Programmierung drin.
Viele Grüße
Markus
Gehe in die Detailansicht des notify , klicke auf "DEF" und übernehme den Coding-Teil einfach mittels copy&paste, dann funktioniert es.
Kalender_Heizung:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($actor,$dtemp,undef)= split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp"); } }
Hallo zusammen
jetzt haben alle HM Geräte MISSING ACK
:-[
Werde heute Abend einen kompletten Rückfall vom HM aus dem Backup machen.
LG
Stefan
Zitat von: strauch am 21 Oktober 2013, 10:30:47
Vielleicht ein wenig Offtopic, ich suche die ganze Zeit etwas zur Hardware Qualität des HM-CC-RT-DN finde, aber keine Informationen. Mich würde vor allem interessieren ob der Stellantrieb genauso rappelt wie der alte oder ob die Qualität höher ist.
Ich finde das ganz und gar nicht offtopic. Gerade die Qualität der VDs hat mich einige Male überlegen lassen, den Homematic Krempel raus zu werfen. Wenn von 6 VDs ganze 2 schon das erste Jahr nicht überstehen und bereits wieder einer anfängt, das Ventil nicht ganz zu zu drehen...
Die Lautstärke ist auch bei meinen VD sehr unterschiedlich. Richtig leise ist keiner, die lautesten sind deutlich hörbar (wie ein leises Gespräch) und machen dabei sehr unregelmäßige Geräusche: *rappel*, *knirsch*, *knirsch*, *gnarrr*, *knirsch*, ...
Den lautesten - ausgerechnet im Schlafzimmer - hab' ich jetzt durch den RT-DN ersetzt.
- wenn man die Tasten nicht verwendet, wirkt er geringfügig hochwertiger.
- das Fehlen von Humidity readings schmerzt sehr
- die Temperatur weicht weniger stark vom (3m entfernten) HM-CC-TC ab als befürchtet (jedes Programm + 1° C und es passt ungefähr)
- den Boost direkt am Ventil auszulösen gefällt meiner Frau besser als erst das Webinterface aufzurufen...
- man kann bei der Anzeige lediglich Datum und Zeit umschalten, leider sieht man immer die Soll-Temperatur, nicht die aktuelle Ist-Temperatur.
- der RT-DN ist nicht viel "leiser", aber deutlich schneller und das Geräusch klingt vertrauenserweckender, höher, gleichmäßiger und kräftiger.
Die Ventilöffnung dauert nur ca. 10 Sekunden und das Geräusch klingt eher wie ein ganz kleiner Akkuschrauber: *siiiiiiiit*
Zitat von: rtv am 21 Oktober 2013, 15:35:38und machen dabei sehr unregelmäßige Geräusche: *rappel*, *knirsch*, *knirsch*, *gnarrr*, *knirsch*
Aufschrauben und die Zahnräder fetten - wirkt Wunder!
Zitat von: betateilchen am 21 Oktober 2013, 15:37:35
Aufschrauben und die Zahnräder fetten - wirkt Wunder!
Meine rappeln auch so, guter Hinweis.
@rtv danke für deine Einschätzung, ich denke ich werde mal einen Homematic Antrieb bestellen und mal anschauen. Vielleicht auch einen Max! und mal vergleichen und den anderen dann verkaufen.
Zitat von: strauch am 21 Oktober 2013, 10:30:47
Vielleicht ein wenig Offtopic, ich suche die ganze Zeit etwas zur Hardware Qualität des HM-CC-RT-DN finde, aber keine Informationen. Mich würde vor allem interessieren ob der Stellantrieb genauso rappelt wie der alte oder ob die Qualität höher ist.
Ich hatte in der letzten Heizsaison 8 Honeywells montiert - diese hier: http://www.amazon.de/Homexpert-Honeywell-HR30-Comfort-Heizk%C3%B6rperthermostat/dp/B0083SIV2U - Ganz große Katastrophe. Von den 8 Stück haben 4 den einen Winter nicht überlebt und haben sich verklemmt, der erste schon nach nem Monat. Ich habe dann alle zurückgeschickt und jetzt "erstmal" 4 HM-CC-RT-DN.
Die alten waren deutlich kleiner, aber nach meinem Empfinden auch wesentlich lauter. Die HM-CC-RT-DN sind größer und optisch nicht so futuristisch, dafür aber zeitlos - man kann sicher drüber streiten, aber ich finde sie designtechnisch sehr gelungen. Außerdem jaulen sie nicht so - man hat nicht wie bei den alten das Gefühl, sie würden sich an den eigentlich leichtgängigen Ventilen quälen. Das nicht klappbare Display sowie die altbacken grüne statt weiße Beleuchtung bei den Honeywells kann man verschmerzen.
Wielang die neuen nun durchhalten wird sich zeigen ... aber die Regelung funktioniert bislang prima und zuverlässig und von meinem Gefühl her würde ich daher auch sagen, dass die ordentlich verarbeitet sind. Auch scheinen sie die Regelparameter langsam aber vernünftig an den Raum anzupassen.
Hallo zusammen
ich hab nun die Versionen wieder aktiv und es ist wieder alles stabil.
# $Id: 10_CUL_HM.pm 4010 2013-10-05 18:23:40Z martinp876 $
# $Id: 00_HMLAN.pm 4005 2013-10-04 14:28:11Z martinp876 $
@Martin hast Du schon eine Idee ?
LG
Stefan
Zitat von: Stefan M. am 21 Oktober 2013, 11:27:39ich habe heute mal wieder ein Update (10 Tage) gemacht und musste feststellen, das meine Regler wieder sehr häufig MISSING ACK bringen. Dies hatte ich die letzten zwei Wochen nicht gehabt. Ist da schon was bekannt dazu
Das Fehlverhalten kann ich bestätigen, allerdings tritt das (bisher) hier nur bei einem einzigen der drei installierten Regler auf. Und zwar exakt beim einzigen Regler, bei dem es
keine gepeerten Fensterkontakte gibt (weil mein Bad kein Fenster hat).
Hallo Stefan,
ich hab etwas am conditional-burst gearbeitet - wie an einigen Stellen beschrieben.
Es gibt jetzt folgende Optionen beim RT (und den anderen conditional Burst devices:
a) register burstRx on/off
b) attribut burstAccess 0_off/1_auto - default 0_off
c) kommando burstXmit
d) wakeup
will man "burst" nutzen muss das Register im Device "on" sein.
Wenn register ="off"
- setzt am das attribut auf auto oder nutzt burstXmit NACH einem kommando wird versucht einen burstAccess zu starten. Wenn es nicht funktioniert wird der versuch beendet und auf das Aufwachen den device gewartet. Es wird KEIN missingACK vermeldet (ist ja nichts verloren gegangen)
wenn register "on"
- setzt man das Attribut auf auto wird jede message sofort mittels burst gesendet. sollte das Device nicht antworten(kann vorkommen, zeitverzögerungen...) wird wie oben verfahren.
- nutzt man burstXmit wird einversuch gestartet zu senden, was normal funktioniert. Im prinzip wie beim Attribut, nur dass man den zeitpunkt steuern kann. man kann also erst alle kommandos einstellen und dann den burst starten - deutlich ergonomischer.
In zwischenversionen gab es missing-acks wenn der burst-start-versuch fehlschlug. Könnte dass dein Problem gewesen sein?
Sollte es aus irgendwelchen Gründen zu delays kommen kann der RT natürlich "wegpennen" und es wird ein missing-ack geben. Das wäre dann gerechtfertigt.
Ein weiteres Problem des RT (und bisher nur dort beobachtet) ist, dass das schreiben von registern (auch templist) entsetzlich lange dauert. Eigentlich ist das kein Problem, sondern dass der RT ACK meldet (message empfangen) aber noch mitten beim schreiben ins flash ist.
Will sagen - nach dem configurieren nimmt der RT eine Auszeit - nachfolgende kommandos timen aus. Das könnte ich noch abfangen. Würde darin resultieren, dass weiteres schreiben erst beim nächsten Aufwachen stattfindet, also in 2,5min.
Um diese sache zu entschärfen gibt es "prep/exec" - da wird nur einmal geschrieben - nachfolgende abfragen müssen immer noch warten - aber man muss nur einmal "warten".
Und noch eine Anmerkung: beim peeren in FHEM wurde bisher burstRx nicht auf "on" gesetzt. Das werde ich jetzt ändern. Ansonsten reagiert der RT nicht auf trigger anderer Devices...
Findest du dein Problem in einer der Beschreibungen wieder? oder war es ein anderes Problem
Gruss Martin
Bei mir ist das register burstRx "on" und wenn ich ein getConfig absetze, werden von den 13 anstehenden Befehlen 12 abgearbeitet (sofort) und einer landet im Error. Und das Resultat ist ein Missing Ack. Wie gesagt - nur bei dem einen RT, bei dem es keine Fensterkontakte als peers gibt.
ein log bitte - damit ich sehe, welche message nicht abgearbeitet wird
Hallo Martin
ich werde es nochmal auf einem meiner anderen FHEMs nachstellen.
Es war auf jeden Fall so das das Attribut burstAccess überhaupt nicht gesetzt war, da ich kein neu Anlernen der Regler durchgeführt habe. burstRx ist auf on. Mit der Zeit sind alle HM Geräte nicht nur die Regler auf missing-ack gegangen.
Ich bin dann wie bereits geschrieben zurückgefallen auf die alte Version und da geht alles wieder.
LG
Stefan
Da bei mir vor einigen Tagen auch viele HM-Geräte (u.U. alle Fensterkontakte) nachmittags (seit Stunden also keine Benutzer-Interaktion) auf MISSING ACK standen hab' ich noch einen anderen Denkanstoß:
Das Problem gehört nicht hier her, sondern in den Overload-Thread.
Die Kontakte zeigten z.B. noch anstehende Kommandos an - ich weiß aber sicher, dass die grüne Bestätigungs-LED kam, als ich eines der Fenster morgens schloß. Wurden diese (Nicht-Burst-Empfänger) vielleicht von FHEM aufgrund der letzten Änderungen abgefragt und haben darauf nicht geantwortet?
Hallo Stefan,
ich dachte du bist auf der neuen Version und es ist stabil.
warum führst du 4010 an? Aktuell sind wir bei 4096 - und da gibt es jeden mengen änderungen zwischendrin.
Bitte teste mit der letzten Version - ich repariere keine alten Versionen
Gruss Martin
Hallo Martin
wie oben beschrieben habe ich gestern ein Update gemacht (vorher ca. zwei Wochen keins) und danach war die ... am dampfen. Aus diesem Grund bin ich auf die Version im letzten Backup zurückgefallen (Stand vorgestern). Du brauchst keine alten Versionen warten aber die aktuelle Version sollte laufen. Was gestern bei mir nicht der Fall war. Wie geschrieben werde ich es heute Abend mal testen. Das mit den falschen Thread kann schon sein aber es hat bei mir mit den Reglern angefangen und hat sich dann den ganzen Tag hochgeschaukelt bis zum Totalausfall von HM obwohl HMLan sagte alles OK kein overload.
lg
Stefan
Zunächst einmal vielen Dank. Ich habe es tatsächlich geschafft, eine Heizungsanlage zu basteln, die ich über einen Googlekalender steuern kann. Das wäre ohne Eure Hilfe nicht möglich gewesen!
Ich habe nun aber versucht, das Ganze noch mehr an meine Bewdürfnisse anzupassen, was teilweise gelungen ist:
Ich habe mir für jeden Raum einen eigenen Kalender geschaffen, so dass ich im Betreff nur die Anfangs- und Endtemperatur angeben muss (in Anlehnung an den Code von Betateilchen).
Nun habe ich zwei notifys:
Kalender_Wohnzimmer:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Wohnzimmer summary $uid")); { fhem("set hz.wohnzimmer desired-temp $dtemp"); } }
zum Setzen der 1. Temperatur und
Kalender_Wohnzimmer:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my (undef,$dtemp)= split(/ /,fhem("get Kalender_Wohnzimmer summary $uid")); { fhem("set hz.wohnzimmer desired-temp $dtemp"); } }
zum Setzen der 2.
Das erste klappt auch wunderbar, allerdings wird zum Ende des Termins die Temperatur nicht auf den 2. Wert abgesenkt.
Wo liegt mein Denkfehler?
Viele Grüße
Markus
Nachtrag: Jetzt das Ganze mal mit Komma probiert, da funktionierts, auch wenn ein \, übergeben wird, aber das liegt sicherlich an der PERL-Syntax. Aber warum gehts nicht mit Space, funktioniert im Originacode von Betateilchen doch auch
Zitat von: CQuadrat am 17 Oktober 2013, 23:15:54
Nur
winOpnTemp
scheint nicht am Thermostat übernommen zu werden. Dort bleiben immer 12.0 °C stehen, wenn das Fenster geöffnet wird.
Hat das vielleicht mal jemand mit original HomeMatic-Software ausprobiert? Ist es dort genauso?
Hallo Martin
ich habe nun meine HM Geräte zum testen an einem BeagleBoard mit aktuellem FHEM dran. MISSING ACK kommen immer noch einige aber nicht mehr so viele.
mir ist folgendes aufgefallen
Der Regler im Bad (gilt auch für die anderen Regler) reagiert nicht gleich auf das Fenster öffnen und schließen.
Erst wenn ich den Regler aufwecke (längeres drücken der mittleren Taste) reagiert er kurzzeitig auf den Fensterkontakt bevor er wieder einschläft.
Das konnte ich so nicht in der vorherigen Installation feststellen.
Welche Einstellungen müssen da noch gemacht werden ?
autoReadReg
4_reqStatus
burstAccess
0_off
R-burstRx
on
2013.10.26 23:00:05.707 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6D52F6 d:FF r:FFAE m:B9 8610 21CEA2 000000 0A88D60F0018
2013.10.26 23:00:05.713 1: RCV L:0F N:B9 F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:broadcast 0A88D60F0018 (INFO_TEMP SET:0x88D6 ACT:0x88D6 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2013.10.26 23:00:13.482 1: HMLAN_Parse: HML R:E21CEB3 stat:0000 t:0A6D715A d:FF r:FFCE m:2B 8610 21CEB3 000000 0A88D30F0018
2013.10.26 23:00:13.485 1: RCV L:0F N:2B F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_21CEB3 DST:broadcast 0A88D30F0018 (INFO_TEMP SET:0x88D3 ACT:0x88D3 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2013.10.26 23:00:24.186 1: HMLAN_Send: HML I:K
2013.10.26 23:00:24.554 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6D9B51 IDcnt:000B
2013.10.26 23:00:49.211 1: HMLAN_Send: HML I:K
2013.10.26 23:00:49.216 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6DFD0B IDcnt:000B
2013.10.26 23:00:52.512 1: HMLAN_Parse: HML R:E21968B stat:0000 t:0A6E09E8 d:FF r:FFA4 m:21 A441 21968B 1EA224 011CC8
2013.10.26 23:00:52.517 1: RCV L:0C N:21 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011CC8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1C NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:00:52.519 1: HMLAN_Send: HML S:SF691CEE8 stat: 00 t:00000000 d:01 r:F691CEE8 m:21 8002 1EA224 21968B 0101C800
2013.10.26 23:00:52.525 1: SND L:0D N:21 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:00:52.556 1: HMLAN_Send: HML S:SF691CF09 stat: 00 t:00000000 d:01 r:F691CF09 m:84 A441 100030 21CEA2 0116C8
2013.10.26 23:00:52.559 1: SND L:0C N:84 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 0116C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x16 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:00:52.893 1: HMLAN_Parse: HML R:RF691CEE8 stat:0002 t:00000000 d:FF r:7FFF m:21 8002 1EA224 21968B 0101C800
2013.10.26 23:00:53.222 1: HMLAN_Parse: HML R:RF691CF09 stat:0008 t:00000000 d:FF r:7FFF m:84 A441 100030 21CEA2 0116C8
2013.10.26 23:00:53.223 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:00.759 1: HMLAN_Parse: HML R:E21968B stat:0000 t:0A6E2A23 d:FF r:FF9F m:22 A441 21968B 1EA224 011D00
2013.10.26 23:01:00.762 1: RCV L:0C N:22 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011D00 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1D NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:00.764 1: HMLAN_Send: HML S:SF691EF1D stat: 00 t:00000000 d:01 r:F691EF1D m:22 8002 1EA224 21968B 0101C800
2013.10.26 23:01:00.770 1: SND L:0D N:22 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:00.801 1: HMLAN_Send: HML S:SF691EF41 stat: 00 t:00000000 d:01 r:F691EF41 m:85 A441 100030 21CEA2 011700
2013.10.26 23:01:00.803 1: SND L:0C N:85 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011700 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x17 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:01.102 1: HMLAN_Parse: HML R:E21968B stat:0000 t:0A6E2B1E d:FF r:FFA1 m:22 A041 21968B 1EA224 011D00
2013.10.26 23:01:01.390 1: HMLAN_Parse: HML R:RF691EF1D stat:0002 t:00000000 d:FF r:7FFF m:22 8002 1EA224 21968B 0101C800
2013.10.26 23:01:01.464 1: HMLAN_Parse: HML R:RF691EF41 stat:0008 t:00000000 d:FF r:7FFF m:85 A441 100030 21CEA2 011700
2013.10.26 23:01:01.465 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:07.474 1: HMLAN_Parse: HML R:E1F06B1 stat:0000 t:0A6E4463 d:FF r:FFD5 m:A5 A610 1F06B1 1EA224 06011A00
2013.10.26 23:01:07.477 1: RCV L:0D N:A5 F:A6 CMD:10 SRC:CUL_HM_HM_Sen_Wa_Od_1F06B1 DST:1EA224 06011A00 (INFO_ACTUATOR_STATUS) (,WAKEMEUP,CFG,BIDI,RPTEN)
2013.10.26 23:01:07.481 1: SND L:0A N:A5 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_Sen_Wa_Od_1F06B1 00 (ACK) (,RPTEN)
2013.10.26 23:01:08.449 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E4832 d:FF r:FFAC m:1B 8400 21CEA2 1EA224 1000954B4551303537393935325900FFFF
2013.10.26 23:01:08.452 1: RCV L:1A N:1B F:84 CMD:00 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:1EA224 1000954B4551303537393935325900FFFF (DEVICE_INFO FIRMWARE:0x10 TYPE:0x0095 SERIALNO:0x4B455130353739393532 CLASS:0x59 PEER_CHANNEL_A:0x00 PEER_CHANNEL_B:0xFF UNKNOWN:0xFF) (,CFG,RPTEN)
2013.10.26 23:01:11.255 1: HMLAN_Parse: HML R:E21968B stat:0000 t:0A6E532A d:FF r:FFA9 m:23 A441 21968B 1EA224 011EC8
2013.10.26 23:01:11.258 1: RCV L:0C N:23 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011EC8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1E NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:11.262 1: HMLAN_Send: HML S:SF692181E stat: 00 t:00000000 d:01 r:F692181E m:23 8002 1EA224 21968B 0101C800
2013.10.26 23:01:11.264 1: SND L:0D N:23 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:11.297 1: HMLAN_Send: HML S:SF6921841 stat: 00 t:00000000 d:01 r:F6921841 m:86 A441 100030 21CEA2 0118C8
2013.10.26 23:01:11.312 1: SND L:0C N:86 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 0118C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x18 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:11.613 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E5435 d:FF r:FFB3 m:86 8002 21CEA2 100030 00
2013.10.26 23:01:11.615 1: RCV L:0A N:86 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:11.651 1: HMLAN_Parse: HML R:RF692181E stat:0002 t:00000000 d:FF r:7FFF m:23 8002 1EA224 21968B 0101C800
2013.10.26 23:01:11.695 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E54CE d:FF r:FFB3 m:86 8002 21CEA2 100030 00
2013.10.26 23:01:11.828 1: HMLAN_Parse: HML R:RF6921841 stat:0008 t:00000000 d:FF r:7FFF m:86 A441 100030 21CEA2 0118C8
2013.10.26 23:01:11.829 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:11.830 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E5567 d:FF r:FFB1 m:86 8002 21CEA2 100030 00
2013.10.26 23:01:13.504 1: HMLAN_Parse: HML R:E21968B stat:0000 t:0A6E5BF4 d:FF r:FFA4 m:24 A441 21968B 1EA224 011F00
2013.10.26 23:01:13.507 1: RCV L:0C N:24 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011F00 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1F NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:13.513 1: HMLAN_Send: HML S:SF69220E9 stat: 00 t:00000000 d:01 r:F69220E9 m:24 8002 1EA224 21968B 0101C800
2013.10.26 23:01:13.519 1: SND L:0D N:24 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:13.550 1: HMLAN_Send: HML S:SF6922109 stat: 00 t:00000000 d:01 r:F6922109 m:87 A441 100030 21CEA2 011900
2013.10.26 23:01:13.553 1: SND L:0C N:87 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011900 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x19 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:13.861 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E5CFF d:FF r:FFB1 m:87 8002 21CEA2 100030 00
2013.10.26 23:01:13.864 1: RCV L:0A N:87 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:13.900 1: HMLAN_Parse: HML R:RF69220E9 stat:0002 t:00000000 d:FF r:7FFF m:24 8002 1EA224 21968B 0101C800
2013.10.26 23:01:13.943 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E5D98 d:FF r:FFB1 m:87 8002 21CEA2 100030 00
2013.10.26 23:01:14.076 1: HMLAN_Parse: HML R:RF6922109 stat:0008 t:00000000 d:FF r:7FFF m:87 A441 100030 21CEA2 011900
2013.10.26 23:01:14.077 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:14.079 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E5E31 d:FF r:FFB1 m:87 8002 21CEA2 100030 00
2013.10.26 23:01:14.214 1: HMLAN_Send: HML I:K
2013.10.26 23:01:14.218 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6E5EC5 IDcnt:000B
2013.10.26 23:01:24.002 1: HMLAN_Parse: HML R:E21968B stat:0000 t:0A6E84FD d:FF r:FFA7 m:25 A441 21968B 1EA224 0120C8
2013.10.26 23:01:24.007 1: RCV L:0C N:25 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 0120C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x20 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:24.009 1: HMLAN_Send: HML S:SF69249EA stat: 00 t:00000000 d:01 r:F69249EA m:25 8002 1EA224 21968B 0101C800
2013.10.26 23:01:24.015 1: SND L:0D N:25 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:24.046 1: HMLAN_Send: HML S:SF6924A0B stat: 00 t:00000000 d:01 r:F6924A0B m:88 A441 100030 21CEA2 011AC8
2013.10.26 23:01:24.049 1: SND L:0C N:88 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011AC8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1A NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:24.361 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E8608 d:FF r:FFB2 m:88 8002 21CEA2 100030 00
2013.10.26 23:01:24.363 1: RCV L:0A N:88 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:24.400 1: HMLAN_Parse: HML R:RF69249EA stat:0002 t:00000000 d:FF r:7FFF m:25 8002 1EA224 21968B 0101C800
2013.10.26 23:01:24.442 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E86A1 d:FF r:FFB2 m:88 8002 21CEA2 100030 00
2013.10.26 23:01:24.575 1: HMLAN_Parse: HML R:RF6924A0B stat:0008 t:00000000 d:FF r:7FFF m:88 A441 100030 21CEA2 011AC8
2013.10.26 23:01:24.576 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:24.579 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E873A d:FF r:FFB2 m:88 8002 21CEA2 100030 00
2013.10.26 23:01:25.749 1: HMLAN_Parse: HML R:E21968B stat:0000 t:0A6E8BD1 d:FF r:FFA4 m:26 A441 21968B 1EA224 012100
2013.10.26 23:01:25.752 1: RCV L:0C N:26 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 012100 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x21 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:25.754 1: HMLAN_Send: HML S:SF69250BB stat: 00 t:00000000 d:01 r:F69250BB m:26 8002 1EA224 21968B 0101C800
2013.10.26 23:01:25.760 1: SND L:0D N:26 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:25.793 1: HMLAN_Send: HML S:SF69250E1 stat: 00 t:00000000 d:01 r:F69250E1 m:89 A441 100030 21CEA2 011B00
2013.10.26 23:01:25.795 1: SND L:0C N:89 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011B00 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1B NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:26.107 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E8CDC d:FF r:FFB2 m:89 8002 21CEA2 100030 00
2013.10.26 23:01:26.109 1: RCV L:0A N:89 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:26.146 1: HMLAN_Parse: HML R:RF69250BB stat:0002 t:00000000 d:FF r:7FFF m:26 8002 1EA224 21968B 0101C800
2013.10.26 23:01:26.189 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E8D75 d:FF r:FFB3 m:89 8002 21CEA2 100030 00
2013.10.26 23:01:26.322 1: HMLAN_Parse: HML R:RF69250E1 stat:0008 t:00000000 d:FF r:7FFF m:89 A441 100030 21CEA2 011B00
2013.10.26 23:01:26.323 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:26.324 1: HMLAN_Parse: HML R:E21CEA2 stat:0000 t:0A6E8E0E d:FF r:FFB3 m:89 8002 21CEA2 100030 00
2013.10.26 23:01:39.217 1: HMLAN_Send: HML I:K
2013.10.26 23:01:39.221 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6EC07F IDcnt:000B
Hallo Stefan,
welchen fensterkontakt nutzt du? wenn ich es richtig sehe hast den Fensterkontalt mit FHEM gepeert und triggerst den RT über ein notify? Solchen Info ist natürlich wichtig und sollte bei einem Problem vermerkt werden.
Dann ist dein Problem also, dass das Kommando postEvent vom RT nicht abgearbeitet wird?
das sollte klar sein.
R-burstRx on # der RT kann burst - man KANN burst kommandos schicken
burstAccess off # FHEM started den burst zugriff NICHT automatisch
autoReadReg # hat damit garnichts zu tun
wenn bustAccess off ist kannst du den zugriff manuell starten, indem zu das kommando set burstXmit hinterher schickst.
Du kannst aber auch warten, bis der RT aufwacht - so alle 2,5min dann wird das Kommando auch abgearbeitet.
ein burstXmit (wie jeder burst-start) belastet den HMLAN und dessen Stunden kontingent. Eine Idee. wo dein system liegt kannst du in HMInfo protocol einsehen
Hallo Martin
Ja die Fensterkontakte sind so wie du es beschreibst eingebunden. Ich habe nun mal burstAccess auf 1 Auto gesetzt und werde es mal beobachten.
Hast Du ein Manuel über eine aus Deiner Sicht beste Konfiguration von HM auf fhem ?
Das mit dem burstAccess ist bei mir bis heute morgen nicht richtig angekommen das es auf 1 stehen soll damit der Regler sofort aufwacht.
LG
Stefan
Hallo Stefan,
mit burstAccess musst du in sofern vorsichtig sein, da dies entsprechend Performance am HMLAN kostet. Da kann ich keine Empfehlung geben sondern nur raten, aufzupassen. .
Evtl überarbeite ich das Fehlerhandling - jedenfalls überdenke ich es gerade. Dazu werden ich evtl eine Empfehlung schreiben, jedenfalls ein paar erklärungen. Dauert aber noch....
Im Commandref ist es schon (etwas) geschrieben - in Englisch
Gruss Martin
Hallo,
ich habe derzeit folgendes Problem: Ich habe 6 Stück HW-CC-RT-DN im Manu-Modus, welche von einem Raspberry Pi mit COC gesteuert werden. Grundsätzlich funktioniert alles, nur wenn ich z.B. zur Nachtabsenkung an alle RT's eine desired-temp schicken will, bekomme ich in 1 aus 3 Fällen bei einem beliebigen RT einen IOerr, und die Temp wird nicht gesetzt. Es lässt sich nicht auf einen RT festnageln, es sind immer unterschiedliche.
Wie kann ich bei einem COC den debug-modus einschalten und die raw-messages mitschneiden? Was bedeutet IOerr, wird mehrmals versucht, die temp zu setzen?
vielen dank,
lg
Tom
Hallo Tom,
IOerr ist ein Problem des HMLAN. dort gab es entweder ein disconnect oder ein overload - ok, bei COC evtl noch einen andern zustand...
kannst du mitloggen, welchen Zustand der COC hat, wenn das Problem auftritt? ist coc dann evtl disconnected?
Dann die Frage, wie du den RT ansprichst im bezug auf burst mode
attr burstAccess
register burstRx
commando burstXmit
Gruss Martin
Zitat von: martinp876 am 27 Oktober 2013, 16:46:03
kannst du mitloggen, welchen Zustand der COC hat, wenn das Problem auftritt? ist coc dann evtl disconnected?
tja, das ist die Frage, ich weiß leider nicht wie das geht beim COC?
danke,
Tom
probiere
attr global verbose 1
attr COC loglevel 1
attr COC verbose 5
attr global mseclog 1
Hallo,
seit dem ich gestern meine 2 HM-CC-RT-DN in betrieb genommen habe und FHEM upgedatet habe, bekomme ich leider auch bei mehreren Fensterkontakten (HM-SEC-SC) das Missing Ack im Status. Das hatte ich vorher nie.
Kurze Frage: war das Missing Ack schon immer im state eines Devices?
Weil der eigentliche Status 'closed' wurde korrekt an FHEM gemeldet:
contact closed (to HMLAN1) 2013-10-27 15:13:24
state MISSING ACK 2013-10-27 15:13:29
Das ärgerliche daran ist, das ich mehrere Kontakte in einer structure zusammenfasse und diese structure durch den state Missing Ack insgesamt undefined ist, obwohl FHEM den eigentlichen Status 'closed' ja korrekt empfangen hat.
Kurzum: wenn das Missing Ack nicht im state stehen würden, würde es micht gar nicht so sehr stören. Deshalb frage ich ob es schon immer im 'state' angezeigt wurde oder früher an andere Stelle und mir es einfach deshalb nie aufgefallen ist.
Zitat von: martinp876 am 27 Oktober 2013, 19:18:53
probiere
attr global verbose 1
attr COC loglevel 1
attr COC verbose 5
attr global mseclog 1
das loglevel hat er nicht genommen, den rest schon. jetzt kommen im log folgende einträge:
2013.10.27 20:28:28.176 5: COC: A0F0E8610236D7E0000000AC0E60F6458 -66.5
2013.10.27 20:28:28.178 5: COC dispatch A0F0E8610236D7E0000000AC0E60F6458::-66.5:COC
2013.10.27 20:28:55.214 5: CUL/RAW: /A0FD0861
2013.10.27 20:28:55.217 5: CUL/RAW: A0FD0861/0236C810
2013.10.27 20:28:55.221 5: CUL/RAW: A0FD08610236C810/000000AB0DB0F435
2013.10.27 20:28:55.224 5: CUL/RAW: A0FD08610236C810000000AB0DB0F435/80B
2013.10.27 20:28:55.226 5: COC: A0FD08610236C810000000AB0DB0F4358 -68.5
2013.10.27 20:28:55.228 5: COC dispatch A0FD08610236C810000000AB0DB0F4358::-68.5:COC
reicht das? wenn ja, poste ich morgen die log-datei, bei der die umstellung geloggt wird.
dankeschön,
lg
Tom
Zitat von: Samsi am 27 Oktober 2013, 20:17:35Kurze Frage: war das Missing Ack schon immer im state eines Devices?
Ja.
Und dass das MISSING ACK kommt, obwohl der Status korrekt gemeldet wurde, hängt mit der logischen Reihenfolge der Datenkommunikation zusammen. Das erste, was passiert, ist die Meldung des Fenstersensors. Deshalb kommt die erstmal korrekt in fhem an, und erst danach tritt das Kommunikationsproblem auf, das letztendlich zur Meldung MISSING ACK kommt. Und da das eine Statusmeldung ist, gehört die auch völlig korrekterweise in das state.
Ok, danke. Dann weiss ich ja jetzt zumindest mal, das ich also seit über einem Jahr nie Missing Ack hatte und das erst seit dem Update passiert.
Zitatund erst danach tritt das Kommunikationsproblem auf, das letztendlich zur Meldung MISSING ACK kommt.
Wie muss ich mir das vorstellen:
Der Fensterkontakt sendet close, bekommt keine Bestätigung und sendet dann 5 Sekunden Später MissingAck?
Müsste er es dann nicht mehrmals Probieren, immerhin ist per Default eingestellt es 6 mal zu wiederholen (habs gerade noch mal überprüft) ?
Im Log steht es jedenfalls nur einmal:
2013-10-27_15:13:24 kontakt_1OG_Schlafzimmer_3 closed
2013-10-27_15:13:24 kontakt_1OG_Schlafzimmer_3 contact: closed (to HMLAN1)
2013-10-27_15:13:29 kontakt_1OG_Schlafzimmer_3 MISSING ACK
Und wird die Bestätigung automatisch vom HMLAN versendet oder wird das Ack erst gesendet wenn FHEM dem HMLAN den Befehl gibt das Ack zu senden?
Wenn Letzters der Fall ist, dann könnte es ja daran liegen, das FHEM evtl. gerade sehr beschäftigt war und deshalb das Ack ausblieb. Nach dem Update gestern ist mir FHEM auch nachdem ich ein paar Einstellungen am Thermostat gemacht habe zum ersten mal so abgeschmiert das ich die FB neu starten musste, weil ich nicht mehr auf das FHEM Frontend zugreifen konnte. Die FritzBox selbst war aber noch erreichbar.
Und nach dem Neustart hat es auch sehr lange gedauert, bis das FHEM Web Frontend wieder lief, das war auch sehr ungewöhnlich.
Nochmals Danke und viele Grüße
Samsi
Zitat von: tomballarino am 27 Oktober 2013, 20:29:50
das loglevel hat er nicht genommen, den rest schon. jetzt kommen im log folgende einträge:
2013.10.27 20:28:28.176 5: COC: A0F0E8610236D7E0000000AC0E60F6458 -66.5
2013.10.27 20:28:28.178 5: COC dispatch A0F0E8610236D7E0000000AC0E60F6458::-66.5:COC
2013.10.27 20:28:55.214 5: CUL/RAW: /A0FD0861
2013.10.27 20:28:55.217 5: CUL/RAW: A0FD0861/0236C810
2013.10.27 20:28:55.221 5: CUL/RAW: A0FD08610236C810/000000AB0DB0F435
2013.10.27 20:28:55.224 5: CUL/RAW: A0FD08610236C810000000AB0DB0F435/80B
2013.10.27 20:28:55.226 5: COC: A0FD08610236C810000000AB0DB0F4358 -68.5
2013.10.27 20:28:55.228 5: COC dispatch A0FD08610236C810000000AB0DB0F4358::-68.5:COC
reicht das? wenn ja, poste ich morgen die log-datei, bei der die umstellung geloggt wird.
dankeschön,
lg
Tom
soooo, jetzt habe ich die log-einträge des COC studiert, und es geschafft, des öfteren einen IOerr zu provozieren, hier meine bisherigen Erkenntnisse:
das Problem mit IOerr hat nichts mit burst zu tun, ich habe burstAccess bei allen -DN's einmal auf 0_off gestellt, um besser mitschauen zu können.
Hier ein log-Auszug, wenn der Tranfer der desired-temp funktioniert:
2013.10.27 22:01:41.714 5: CUL/RAW: /A0FA1861
2013.10.27 22:01:41.717 5: CUL/RAW: A0FA1861/021C1F10
2013.10.27 22:01:41.720 5: CUL/RAW: A0FA1861021C1F10/000000AA0DA10005
2013.10.27 22:01:41.723 5: CUL/RAW: A0FA1861021C1F10000000AA0DA10005/805
2013.10.27 22:01:41.726 5: COC: A0FA1861021C1F10000000AA0DA100058 -71.5
2013.10.27 22:01:41.728 5: COC dispatch A0FA1861021C1F10000000AA0DA100058::-71.5:COC
2013.10.27 22:01:41.734 1: RCV L:0F N:A1 F:86 CMD:10 SRC:HeizK_Kueche DST:broadcast 0AA0DA100058 (INFO_TEMP SET:40 ACT:218 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2013.10.27 22:01:41.738 5: COC sending As09DAA112F1123421C1F1
2013.10.27 22:01:41.820 5: SW: As09DAA112F1123421C1F1
2013.10.27 22:01:41.836 1: SND L:09 N:DA F:A1 CMD:12 SRC:F11234 DST:HeizK_Kueche (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.10.27 22:01:41.990 5: CUL/RAW: /A0ADA800221C1F1F112340007
2013.10.27 22:01:41.992 5: COC: A0ADA800221C1F1F1123400 -70.5
2013.10.27 22:01:41.995 5: COC dispatch A0ADA800221C1F1F1123400::-70.5:COC
2013.10.27 22:01:42.000 1: RCV L:0A N:DA F:80 CMD:02 SRC:HeizK_Kueche DST:F11234 00 (ACK) (,RPTEN)
2013.10.27 22:01:42.005 5: COC sending As0CDBA011F1123421C1F186042A
2013.10.27 22:01:42.089 5: SW: As0CDBA011F1123421C1F186042A
2013.10.27 22:01:42.105 1: SND L:0C N:DB F:A0 CMD:11 SRC:F11234 DST:HeizK_Kueche 86042A (,BIDI,RPTEN)
2013.10.27 22:01:42.249 5: CUL/RAW: /A0ADB800
2013.10.27 22:01:42.252 5: CUL/RAW: A0ADB800/221C1F1F
2013.10.27 22:01:42.256 5: CUL/RAW: A0ADB800221C1F1F/112340008
2013.10.27 22:01:42.258 5: COC: A0ADB800221C1F1F1123400 -70
2013.10.27 22:01:42.261 5: COC dispatch A0ADB800221C1F1F1123400::-70:COC
2013.10.27 22:01:42.266 1: RCV L:0A N:DB F:80 CMD:02 SRC:HeizK_Kueche DST:F11234 00 (ACK) (,RPTEN)für mich als Homematic-Protkoll unkundigen meldet sich der HeizK_Kueche, FHEM sagt: HAVE_DATA, dann kommt ein ACK des DN, dann werden die Daten? übertragen, dann kommt noch ein ACK des DN.
Dieser protokollierte Vorgang hat funktioniert.
Nun ein Mitschnitt von einem fehlgeschlagenen:
2013.10.27 22:03:16.279 5: CUL/RAW: /A0FF5861
2013.10.27 22:03:16.282 5: CUL/RAW: A0FF5861/0236C810
2013.10.27 22:03:16.286 5: CUL/RAW: A0FF58610236C810/000000AA8EB0F1D5
2013.10.27 22:03:16.289 5: CUL/RAW: A0FF58610236C810000000AA8EB0F1D5/80A
2013.10.27 22:03:16.291 5: COC: A0FF58610236C810000000AA8EB0F1D58 -69
2013.10.27 22:03:16.294 5: COC dispatch A0FF58610236C810000000AA8EB0F1D58::-69:COC
2013.10.27 22:03:16.300 1: RCV L:0F N:F5 F:86 CMD:10 SRC:HeizK_WZ_R DST:broadcast 0AA8EB0F1D58 (INFO_TEMP SET:42 ACT:235 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2013.10.27 22:03:16.304 5: COC sending As09DEA112F11234236C81
2013.10.27 22:03:16.386 5: SW: As09DEA112F11234236C81
2013.10.27 22:03:16.402 1: SND L:09 N:DE F:A1 CMD:12 SRC:F11234 DST:HeizK_WZ_R (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.10.27 22:03:16.556 5: CUL/RAW: /A0ADE8002236C81F11234000A
2013.10.27 22:03:16.558 5: COC: A0ADE8002236C81F1123400 -69
2013.10.27 22:03:16.561 5: COC dispatch A0ADE8002236C81F1123400::-69:COC
2013.10.27 22:03:16.566 1: RCV L:0A N:DE F:80 CMD:02 SRC:HeizK_WZ_R DST:F11234 00 (ACK) (,RPTEN)
2013.10.27 22:03:16.571 5: COC sending As0CDFA011F11234236C8186042A
2013.10.27 22:03:16.654 5: SW: As0CDFA011F11234236C8186042A
2013.10.27 22:03:16.670 1: SND L:0C N:DF F:A0 CMD:11 SRC:F11234 DST:HeizK_WZ_R 86042A (,BIDI,RPTEN)
...danach kommt 10 sekunden nichts...hier fehlt das letzte ACK des DN, die Anzeige im Webinterface geht auf IOerr, es wird nicht mehr versucht, den Befehl beim nächsten Aufwachen abzusetzen.
Sollte das nicht der Fall sein? Es kann ja durchaus vorkommen, dass Pakete verloren gehen, deshalb gibt es ja diese bidirektionale Kommunikation.
danke für die Hilfe,
lg
Tom
IOErr kommt, wenn dein IO-device "nicht Sendebereit" signalisiert. Es muss sich also der state geaendert haben. kannst du dies prüfen? CUL_HM würde/sollte ansonsten einen timeout erkennen.
voraussichtlich ist der state nicht mehr "opened"
Gruss Martin
in den logs kommt sonst nichts mehr. der COC ist ja direkt über die serielle Schnittstelle des Raspberry angebunden, also auch kein USB, das sich disconnecten könnte....
Hallo zusammen
Frage zur Kindersicherung der Regler.
Kann ich die Kindersicherung mit modusBtnLock=1 von FHEM einschalten ?
lg
Stefan
Zitat von: tomballarino am 28 Oktober 2013, 09:54:18
in den logs kommt sonst nichts mehr. der COC ist ja direkt über die serielle Schnittstelle des Raspberry angebunden, also auch kein USB, das sich disconnecten könnte....
ich glaube, ich habe das Problem gefunden:
in 10_CUL_HM.pm, Zeile 3653:
if ($hash->{IODev}->{STATE} ne "opened"){#IO errors
CUL_HM_eventP($hash,"IOerr");
readingsSingleUpdate($hash,"state","IOerr",1);
}
Es wird überprüft, ob das IO-Device in state "opened" ist. Mein COC ist aber soweit ich das sehen kann, immer im State "Initialized".
Wenn ich den Code ändere auf:
if ($hash->{IODev}->{STATE} ne "opened" && $hash->{IODev}->{STATE} ne "Initialized"){#IO errorsdann wird kein IOerr mehr gemeldet, sondern ein MISSING ACK
lg
Tom
nun - ist mir soweit klar. Daher hatte ich immer gefragt, welchen state COC hat, damit ich es berücksichtigen kann.
Eigentlich sollte die COC auf "opened" gesetzt werden - durch DevIO.
Ich werde auch initialized als "sendebereit" zulassen.
das MissingAck ist ein anderen Problem, klar
@Martin, ich hab mir jetzt auch ein HM-CC_RT-DN bestellt. Würde es dir helfen, wenn ich dir das Gerät zum "entwickeln" schicke und du schickst es mir zurück wenn du es "durchtesten" konntest? Oder reicht dir die Ferndiagnose?
@Strauch
einen RT habe ich - so weit ist die Entwicklung eigentlich beendet - ist quasi in der maintenance Phase
danke
Ok, vielen Dank für Deine/Eure Arbeit.
Ich habe bei mir vier HM-CC-RT-DN im Einsatz, die ich jetzt in FHEM einbinden möchte. Beim Pairen werden automatisch eine ganze Reihe von Kanälen definiert:
ActionDetector
CUL_HM_HM_CC_RT_DN_xxxxxx_Climate
CUL_HM_HM_CC_RT_DN_xxxxxx_ClimaTeam
CUL_HM_HM_CC_RT_DN_xxxxxx_ClimRT_tr
CUL_HM_HM_CC_RT_DN_xxxxxx_remote
CUL_HM_HM_CC_RT_DN_xxxxxx_Weather
CUL_HM_HM_CC_RT_DN_xxxxxx_WindowRec
Brauche ich die alle, oder macht es Sinn, einige davon wieder zu löschen? Gibt es Empfehlungen, wie diese ganzen Kanäle (oder sind das Devices?) gruppiert und konfiguriert werden sollten?
Guten Abend zusammen,
Ich habe einen Raum mit zwei von diesen Thermostatventilköpfen. Nun möchte ich diese "peeren". Nach lesen dieses Threads habe ich folgendes versucht:
set CUL_HM_HM_CC_RT_DN_21CF98_ClimaTeam peerChan 0 CUL_HM_HM_CC_RT_DN_236CD0_ClimRT_tr single
und umgekehrt. Ausserdem glaube ich auch, dass ich es mit beiden ClimaTeam Channels versucht habe.
Meldung von FHEM gab es darauf keine.
Wenn ich an einem Thermostat drehe, passiert am anderen nichts...
Wie kann ich checken, ob das peering aktiv ist?
Ausserdem: Wenn ich noch zwei weitere Thermostate Beeren möchte, müsste ich dann einen anderen Channel wählen? Und was bedeutet "single" ?
Vielen Dank für das beantworten meiner vielen Fragen :)
Grüsse
Hallo HardwarW
ZitatWenn ich noch zwei weitere Thermostate Beeren möchte, müsste ich dann einen anderen Channel wählen?
Du musst immer Channel 4 mit cahnnel 5 peeren. Channel 4 ist der Sender und CH5 immer der Empfänger.
Wenn Du willst, das Thermostat 1 (T1) das Thermostat 2 (T2) steuert, dann peerst Du T1:CH4 mit T2:CH5.
Wenn Du auch noch willst, das T1 ein drittes T3 Steuert, dann musst Du zusätzlich T1:CH4 mit T3:CH5 peeren.
Und das musst Du dann alles noch umgekehrt machen. Also wenn Du willst das T3 auch T2 und T1 steuert, dann peerst Du noch T3:CH4 mit T2:CH5 und T1:CH5
Grüße
Eine Frage zu dem peeren habe ich aber selbst noch:
Ich habe 2 Thermostate gegenseitig gepeert und entsprechend sendet das Thermostat, welches ich manuell einstelle, die Solltemperatur zu dem anderen. So weit so gut.
Wenn ich das per FHEM ändere, dann wird aber nur das eine Eingestellt, das andere bleibt leider unverändert. Gibt es eine Möglichkeit einzustellen, dass das Thermostat, welches ich per FHEM einstelle seine Einstellung dann an seine peers weiter sendet? Ich würde nämlich gerne vermeiden, von dem HMLAN zu viele Funkbefehle zu senden.
Grüße
Zitat von: Samsi am 01 November 2013, 23:16:49
Du musst immer Channel 4 mit cahnnel 5 peeren. Channel 4 ist der Sender und CH5 immer der Empfänger.
Danke für deine Antwort Sams.
Leider blicke ich immer noch nicht ganz durch.
Bei mir ist bei Channel 4 der Parameter peerChan gar nicht verfügbar (nur peerBulk). Bei Channel 5 dagegen schon.
Hallo, seit gestern "betreibe" ich auch vorerst 2 HM-CC-RT-DN. Nachdem ich die TempList in 99_myUtils an die Thermostaten geschickt habe, zeigen beide RT´s Missing Ack. Hatte sämtliche Temp. Werte erst mit prep zusammengefasst und zum Schluss mit exec abgeschickt. Angekommen sind die Listen auch aber bis heute Missing Ack.
Meine Frage, ist schon eine Lösung in Sicht?
VG
Frank
Hallo Franky,
es könnte daran liegen, dass fhem die Werte wieder rücklesen will, der RT aber zu langsam ist beim Schreiben.
ich werden es mir noch einmal ansehen - im Prinzip muss beim RT nach dem Schreiben immer eine zwangspause eingebaut werden - das habe ich noch nicht, muss aber noch kommen.
Gruss Martin
HardwareW:
ZitatBei mir ist bei Channel 4 der Parameter peerChan gar nicht verfügbar (nur peerBulk). Bei Channel 5 dagegen schon.
Ich denke dann musst Du es einfach nur umgekehrt machen:
Also wenn Du willst das T3 auch T2 und T1 steuert, dann peerst Du t T2:CH5 mit T3:CH4 und T1:CH5 mit T3:CH4
Das Thema Peeren haben wir doch gerade ein paar Seiten zurück noch einmal ausführlich abgehandelt. Laut Aussage von Martin ist das Peeren über FHEM in der von Dir gewünschten Form gar nicht möglich, d.h. auch wenn die Geräte im FHEM gepeert sind, werden manuelle Änderungen an einem Thermostaten nicht auf den anderen übertragen. Um dieses zu erreichen, muss man sie direkt über die Thermostaten peeren, Reset machen und dann erneut im FHEM einlesen (vorher dort löschen).
Ich habe es so gemacht und habe jetzt 4 Thermostate im Wohnzimmer, die alle miteinander verbunden sind. Im FHEM habe ich mir dann über structure ein gemeinsames Device heizung.wohnzimmer geschaffen, so dass alle FHEM-Befehle zeitgleich an alle Thermostate geschickt werden.
Viele Grüße
Markus
Hallo,
ZitatLaut Aussage von Martin ist das Peeren über FHEM in der von Dir gewünschten Form gar nicht möglich, d.h. auch wenn die Geräte im FHEM geppert sind, werden manuelle Regler an einem Thermostaten nicht auf den anderen übertragen. Um dieses zu erreichen, muss man sie direkt über die Thermostaten peeren, Reset machen und dann erneut im FHEM einlesen (vorher dort löschen).
Dann ist das aber ein Problem von FHEM, denn mit der Windows Software kann man auch nachträglich die Thermostate zu verknüpfen. Ich bin sicher, der Martin bekommt das auch irgendwann hin ;)
Hallo,
habe ich noch nicht getestet - also man kann ein "RT Thermometer" als ausgang mit einem RT Thermometer als Eingang peeren?
Kann jemand, der dies erstellt hat, ein List der beiden RTs senden? Am besten von allen channels.
oder alternativ (evtl besser) ein getConfig mitloggen (roh) von beiden RTs
Prinzipiell erscheint es möglich - der RT hat einen Thermostat-sensor und einen Empfänger - warum also nicht?
Danke
Martin
Hallo Martin,
die Win-Software peert den Kanal 4 (Sender) mit dem Kanal 5( Empfänger, ClimaTeam).
Am Ende steht dann im Kanal 4 gar nichts in den PeerIDs und im Kanal 5 steht die PeerID des Senders und 000000. Ich vermute, das der Sender (Kanal 4) einfach nur ein Broadcast mit seiner ID macht, und alle anderen schauen ob das ein Sender ist den Sie empfangen sollen, sonst müsste das Thermostat ja jedes mal eine Reihe von Funkbefehlen absetzen.
Könnte ich da nicht ein virtuelles Device mit ID ABCDEF04 in FHEM machen (und der HMLAN sendent dann einen Befehl mit dieser ID) und dann alle 5 Kanäle mit der ID pairen, so das ich von FHEM aus nur einmal einen Funkbefehl absenden muss?
Das mit dem Loggen muss ich mal in einer ruhigen Minute ausprobieren.
Grüße
Hallo Samsi,
jetzt habe ich den Faben verloren - muss vielleicht noch einmal nachlesen worum es ging.
wenn man ein "team" bauen will muss man die beiden RTs peeren wie du gesagt hast. Das habe ich schon eingebaut. Es werden dann informationen über Solltemperaturen ausgetauscht (nicht alle...).
Man könnte auch einen virtuellen schalter dafür erschaffen (noch nicht) - aber mir ist nicht klar was das sollte - die Temperatur kannst du auch so setzen - flexibler.
Das sollte aber schon bekannt sein und funktionieren.
Was ich erstanden hatte ist, dass ein RT der temp-fühler werden soll und der 2. (die anderen...) die auf den einen als Thermometer hören. Dazu müsste man irgendetwas mit channel 01 peeren - so viel ist klar.
Der RT kann von einem externen Fühler "geführt" werden. Die Frage ist - kann er auch führen?
Was ist jetzt die Frage gewesen?
Gruss Martin
Hallo Martin,
Zitatwenn man ein "team" bauen will muss man die beiden RTs peeren wie du gesagt hast.
Also ich meinte man muss nicht 2RTs peeren (der RT ist ja kanal 4) sondern man muss immer Kanal 5 mit kanal 4 peeren.
HardwareW hat es jedenfalls so versucht(erfolglos) aber
juelich meinte das würde gar nicht funktionieren:
Zitatauch wenn die Geräte im FHEM gepeert sind, werden manuelle Änderungen an einem Thermostaten nicht auf den anderen übertragen.
Zitat
Man könnte auch einen virtuellen schalter dafür erschaffen (noch nicht) - aber mir ist nicht klar was das sollte
Also im Moment, wenn ich ich bei 2 Thermostaten die Temperatur setzen will, muss ich 2x set desired-temp ausführen und HMLAN sendet dann auch 2x mit Funkverkehr. Meine Idee war, das mit einem Virtuellen Device der HMLAN nur 1x Funken muss und alle echten Thermostate auf den einen Funkbefehl des virtuellen Devices reagieren. juelich hat z.B. 4 Thermostate im Wohnzimmer und somit 4 Funkbefehle.
ZitatDer RT kann von einem externen Fühler "geführt" werden. Die Frage ist - kann er auch führen?
Das war zwar nicht die Frage gewesen, aber trotzdem interessant.
Hallo Samsi,
FHEM "teamet" seit einiger Zeit RTs. Dazu
set <rt1_team> peerChan 0 <rt2_team> single
Es werden die Channels 04/05 verwendet. Einrichten per FHEM sollte kein Problem sein.
Nach meiner Erfahrung tauschen Teams temperaturen NUR aus, wenn sie "lokal" eingestellt werden. Die Temperaturen werden NICHT ausgetauscht, wenn die Quelle 'in der Lage ist' es an alle RTs zu verteilen (so verstehe ich die HM Philosophie hier).
Nicht weiter gegeben werden
-Änderungen wegen Fensterkontakten (der user hätte gepeert, wenn er es wollte)
- temp vorgaben der Zentrale (der User hätte es programmiert)
- Temperaturlisten/Wochenplan - der User hätte es programmiert
weitergegeben werden
- drehen am Handrad - der User will nicht durch den Raum laufen
- boot am Handrad
Wenn du es anders willst solltest du ein Notify nehmen (habe ich gemacht, weil einer der RTs gesponnen hat). Da synche ich mode und temperatur - immer.
Gruss Martin
Hallo Martin,
ja so hatte ich es auch verstanden.
Zitattemp vorgaben der Zentrale (der User hätte es programmiert)
Genau, und da habe ich mir gedacht, vielleicht könnte man das mit einem Virtuellen RT device machen, das man dann alle Thermostate damit peeren kann und somit die Zentrale (das virtuelle Device) den Befehl nur einmal senden muss.
Hallo Samsi,
müsste ich mir erst ansehen, ob das sinn macht. Viel Nutzen sehe ich nicht, aber viele Fallen.
- gedacht ist es für einen Raum - da hat man meist nicht mehr als 2 oder 3 heizkörper.
- Es besteht die Frage ob es als broadcast zu senden ist - ich vermute nicht - FHEM muss mit jeden einzeln reden
- der RT sendet einen burst um die Änderung sofort zu machen. Würde dies die Zentrale auch machen belastet dies das HMLAN. mehr als 100 burst gehen nicht in 1h. Alternativ wartet man 2,5min auf das Aufwachen...
- fhem unterstützt schon lange "structure" - damit sollte man es schon jetzt lösen können
So etwas zu bauen bedarf einiger einstellungen weil es ansonsten zu HMLAN overloads kommt - oder verzögerungen. Ich denke das soll jeder bauen wie er will.
ich nutze ein notify. alle HK in einem Raum (kann ich am Namen erkennen) werden auf den gleichen mode und die gleiche temperatur gesetzt - egal woher die Änderung kommt. Mit einer Verzögerung von 2,5min kann ich leben. Das ist meine Lösung...
Gruss Martin
Hallo Samsi,
Ich habe auch versucht, meine Heizkörper in FHEM zu peeren, habe es aber aufgegeben, da es nach den Ausführungen von Martin nicht möglich ist, einem Heizkörper per FHEM einen Befehl zu senden und darauf zu hoffen, das dieser diesen Befehl dann an seine Peers weitergibt. Ich habe die Heizkörper dann außerhalb von FHEM gepeert und mittels Structure in FHEM ein virtuelles Device geschaffen, an welches alle Befehle von FHEM gehen:
define Hz.Wohnzimmer structure hz.wz1,hz.wz2,hz.wz3,hz.wz4
Natürlich werden vom HMLAN jedesmal 4 Befehle gesendet, aber was schadet das? Gerade Heizkörper Werden doch nicht alle 5 Minuten angesteuert! Habe jedenfalls kein Overload, es werden alle Befehle zeitnah an alle Geräte übertragen. Ändere ich die Temperatur manuell an einem Heizkörper, wird auch die Temperatur an den anderen Heizkörpern mitgeändert.
Viele Grüße
Markus
Hallo Markus,
es sollte nicht zu Probleme führen, wenn du keinen burst erzwingst. Burst würde ich vermeiden, da gehen je Stunde nicht mehr als 100 - also jeder burst verbraucht somit etwa 6 andere Kommados.
Meine implementierung ist ein notify. Im Gegensatz zu stricture wird desired-temp immer "ge-synct", egal wo du sie einstellst. Auch der mode wird "copiert". Regel ist, dass das letzte Ändern an einem RT auf die anderen kopiert wird.
Es wird nur geschrieben, wenn der Wert noch nicht stimmt - was messages "spart"
Nachteil: es kann 5min dauern bis alles durch ist. Grund: der erste RT wird verstellt und ich warte bis er es meldet. dann wird der 2. geschrieben - aber erst wenn der aufwacht.
ok - es sind 2 notifies... eins für temp und eins für mode.
Mit etwas lieben kann man es optimieren...
define h_ab_team_temp notify h_.*_Clima:desired-temp.* {\
if ($EVTPART1 ne ReadingsVal("h_HK1_Clima","desired-temp","")){\
fhem "set h_HK1_Clima desired-temp $EVTPART1"}\
if ($EVTPART1 ne ReadingsVal("h_HK2_Clima","desired-temp","")){\
fhem "set h_HK2_Clima desired-temp $EVTPART1"}\
}
define h_ab_team_mode notify h_.*_Clima:mode.* {\
if ($EVTPART1 ne ReadingsVal("h_HK1_Clima","mode","")){\
if ($EVTPART1 =~ m/(auto|boost)/){\
fhem "set h_HK1_Clima controlMode $EVTPART1"}\
elsif($EVTPART1 eq 'manu'){\
fhem "set h_HK1_Clima controlManu ".ReadingsVal("h_HK1_Clima","desired-temp","")}\
}\
if ($EVTPART1 ne ReadingsVal("h_HK2_Clima","mode","")){\
if ($EVTPART1 =~ m/(auto|boost)/){\
fhem "set h_HK2_Clima controlMode $EVTPART1"}\
elsif($EVTPART1 eq 'manu'){\
fhem "set h_HK2_Clima controlManu ".ReadingsVal("h_HK2_Clima","desired-temp","")}\
}\
}
Gruss Martin
Das wird ja noch mal spannend wenn das Wandthermostat kommt, wie dann die Steuerung abläuft. Gestern habe ich mein HM-CC-RT-DN in Betrieb genommen. Gefällt mir Hardwaretechnisch schon wesentlich besser als meine FHTs. Der Stellantrieb ist bei mir wesentlich leiser, aber ich will die FHT Stellantriebe mal fetten und schauen wie laut sie dann noch sind.
Die Optik gefällt mir. Verarbeitung ist ok, aber kein besonders hohes Niveau. Aber auch hier deutlich besser als bei meinen FHTs, da streiken schon mal die Knöpfe am FHT80b. Mal gespannt wie die Optik der ganzen Homematic Geräte so wird, gefällt mir wesentlich besser als die "Segel"-optik der bisherigen Geräte.
Womit ich jetzt aber erst mal umgehen muss ist der ganz andere Umgang von FHEM mit einem Homematic Regler als mit einem FHT Regler. Es wird kein automatischer Plot angelegt (warum eigtl. nicht? Ist das bewusst entschieden oder hat einfach niemand eine plot Datei dafür geschrieben?) Und ich hab 8 Geräte für die Heizung. Die tauchen auch alle in andFHEM auf, sind aber für den Betrieb eher uninteressant. Wie habt ihr das gemacht die ganzen Geräte in einen anderen Raum ausquatiert oder einfach stehen lassen?!
Edit: Hier noch ein Screenshot der 8 geräte
Zitat von: strauch am 04 November 2013, 10:47:07oder hat einfach niemand eine plot Datei dafür geschrieben?
Es gibt seit kurzem eine Plot-Datei für den RT, die sollte per Update automatisch in Dein fhem kommen (oder dort schon sein)
hm-rt.gplot wieso ist mir die gestern Abend nicht aufgefallen. Danke für den Hinweis. Gibts irgendwo auch ein gplot File für den Tür Fensterkontakt? HM-SEC-SC? Hab mir jetzt einen gebastelt, aber so richtig funktioniert er nicht. Ansonsten muss ich mich da mal reinhängen.
Ich verstehe das sowieso nicht - ich habe noch nie eine vorgefertigte Plot-Datei verwendet. Es geht doch viel schneller, die selbst zu definieren, als an einem Muster irgendwelche Änderungen/Anpassungen zu machen und dabei irgendwas zu vergessen.
Entscheidend ist für mich immer die Logdatei, wenn dort alles drinsteht, ist das Plotten doch in zwei Minuten erledigt.
Wenn man über das Wissen verfügt ja, wenn nicht muss man sich das Wissen erst aneignen, du hast es, dann ist es kein Problem. Ich fing dann gestern Abend an, viel zu lesen und zu suchen, macht mir ja auch Spaß. Aber ich muss sagen bei den FHTs hat mit der Plot auch einfach gereicht. Ich musste gar nichts machen.
Gut nun ist FHEM nicht an Leute gerichtet die sich nicht damit beschäftigen wollen und sich alles von alleine einrichtet. Ich fands beim FHT praktisch und wer es anders möchte, der macht ebend ein neues.
Hallo,
nachdem die Steuerung meiner Geräte über den Google-Kalender seit 2 Wochen super läuft, ist mir gestern Abend ein neues Problem im Log aufgefallen (ich weiß nicht, wie lange das Problem schon existiert, ich schaue nicht regelmäßig auf die Logs):
2013.11.04 09:25:25 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 09:25:25 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 09:25:25 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 09:25:25 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 09:25:26 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 09:25:26 3: HZ.Bad_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 09:25:26 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 09:25:26 3: HZ.Bad_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:25 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:25 3: HZ.Kueche_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:25 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:25 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:26 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:26 3: HZ.Bad_an return value: desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:26 3: set hz.bad desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 10:25:26 3: HZ.Bad_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
Offensichtlich wird exakt jede Stunde in Bad und Küche versucht, die Heizung auf eine nichtdefinierte Temperatur einzustellen (im Wohnzimmer nicht), was natürlich nicht funktioniert.
Wo kommen diese Befehle her?
Ich habe lediglich für jede Heizung 2 Notifys, die nach einem Kalender die Heizung stellen. Mehr Befehle gibt es nicht.
Wie kann ich herausbekommen, was da los ist?
Viele Grüße
Markus
Ich bevorzuge Learning-by-Doing und nicht Learning-by-Copying 8) aber ich hab schon verstanden, was Du meinst.
Aber ganz ehrlich: ein paar einfache Kurven plotten ist in fhem m.E. eine der geringsten Herausforderungen.
Regel 1: erstelle ein Logfile, in dem alle Werte stehen, die Du plotten willst.
Regel 2: Klicke in der Detailansicht des Logfiles auf "Create SVG..."
Regel 3: wähle die Daten aus der vorgegebenen Liste, die im Plot ausgegeben werden sollen
Zitat von: juelich am 04 November 2013, 11:43:28Wo kommen diese Befehle her?
Ich habe lediglich für jede Heizung 2 Notifys, die nach einem Kalender die Heizung stellen. Mehr Befehle gibt es nicht.
Wie kann ich herausbekommen, was da los ist?
Zeig halt mal die beiden notifies her. (Gefühlsmäßig würde ich sagen, die Krux liegt an einem Kalendereintrag und nicht in fhem selbst)
Zitat von: martinp876 am 04 November 2013, 09:23:32
Meine implementierung ist ein notify. Im Gegensatz zu stricture wird desired-temp immer "ge-synct", egal wo du sie einstellst. Auch der mode wird "copiert". Regel ist, dass das letzte Ändern an einem RT auf die anderen kopiert wird.
Es wird nur geschrieben, wenn der Wert noch nicht stimmt - was messages "spart"
Nachteil: es kann 5min dauern bis alles durch ist. Grund: der erste RT wird verstellt und ich warte bis er es meldet. dann wird der 2. geschrieben - aber erst wenn der aufwacht.
Hallo Martin,
das verstehe ich nicht ganz. Da die Thermostate bei mir untereinander geppert sind, wird jede manuelle Änderung eines Thermostaten ohne Beteiligung des HMLAN direkt untereinander weitergegeben. Möchte ich jetzt aus FHEM eine andere Wohnzimmertemperatur haben (egal ob über Kalender oder manuell) muss das Kommando doch sowieso vom HMLAN an alle 4 Thermostate geschickt werden, auch beim Notify, oder sehe ich das falsch? Beim Notify läuft doch auch jede manuelle Änderung beim Thermostaten über den HMLAN, oder habe ich das jetzt falsch verstanden? Rückmeldung über die Änderung eines Thermostaten an FHEM -> Korrektur wenn nötig der anderen Thermostate. Da sehe ich sogar mehr Befehle.
Viele Grüße
Markus
Zitat von: betateilchen am 04 November 2013, 11:46:57
Ich bevorzuge Learning-by-Doing und nicht Learning-by-Copying 8) aber ich hab schon verstanden, was Du meinst.
Aber ganz ehrlich: ein paar einfache Kurven plotten ist in fhem m.E. eine der geringsten Herausforderungen.
Du hast ja recht :-). Soweit bin ich auch, was mir dann eher Schwierigkeiten bereitet ist beim Tür Fensterkontakt, das open close ausfiltern und das entsprechend zu plotten. Da kann man dann solche Sachen machen:
Tics as ("Txt" val, ...): ("Zu" 0, "Auf" 1) wobei ich da schon viel kopiere, ich schau wie es an anderer Stelle gemacht wird und teste dann durch und versuche das natürlich auch zu verstehen. Ist nicht unbedingt die "nachhaltigste" Vorgehensweise, mir fehlt aber einfach auch die Zeit mich entsprechend Tief einzudenken..... leider.
Aber das wird jetzt auch offtopic
Zitat von: betateilchen am 04 November 2013, 11:48:46
Zeig halt mal die beiden notifies her. (Gefühlsmäßig würde ich sagen, die Krux liegt an einem Kalendereintrag und nicht in fhem selbst)
Die Notifys sind:
Kalender_Kueche:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/,,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }Kalender_Kueche:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my (undef,$dtemp)= split(/,,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }Wie man am Log sieht, funktioniert das auch einwandfrei um 11:00 Uhr, um 11.25 dann wieder eine undefinierte Temperatur setzen zu wollen:
2013.11.04 11:00:00 3: get Kalender_Kueche summary xxx : 21\,17
2013.11.04 11:00:00 2: CUL_HM set hz.kueche desired-temp 17
2013.11.04 11:25:25 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
Ich habe für jede Heizung einen eigenen Kalender mit dem Betreff: Temp.start,temp.ende.
Hat auch immer gut funktioniert - und die Temperaturen werden ja auch korrekt ausgelesen.
Viele Grüße
Markus
Wahrscheinlich lieght das Problem ja bei einem fehlerhaften SPLIT - leider ist diese Funktion nirgendwo vernünftig beschrieben. Ich habe mich einfach bei Betateilchen bedient, aber scheinbar nicht richt :-(
In meinem Kalender habe ich für jede Heizung einen Kalender, es werden Ereignisse definiert, mit dem Betreff "temp.beginn,temp.ende".
Lieber wäre mir ja ein Space zwischen den Temperaturen gewesen, aber das habe ich gar nicht hinbekommen.
Wie ist denn nun die genaue Syntax von Split? Kann mir da jemand helfen?
Viele Grüße
Markus
Hallo Markus,
nun, das split solltest du aber schon alleine klären können - da gibt es Tonnen von Doku im Rahmen von perl.
split trenner,string
evtl
split(",",fhem("get Kalender_Kueche summary $uid"))
Hallo Martin, habe ewig nach "split FHEM" gegooglet und nichts definitives gefunden, auch nicht in der Reference.
Das mit "," habe ich auch versucht, die gleiche Fehlermeldung. Von Google wird auch nicht "," zurückgeliefert, sondern "\," - könnte das daran liegen?
Viele Grüße
Markus
Und des Merkwürdige ist, es funktioniert ja:
2013.11.04 13:00:00 3: get Kalender_Wohnzimmer summary xxx: 24\,16
2013.11.04 13:00:00 2: CUL_HM set hz.wz desired-temp 24\
2013.11.04 13:00:00 2: CUL_HM set hz.wz1 desired-temp 24\
2013.11.04 13:00:00 2: CUL_HM set hz.wz2 desired-temp 24\
2013.11.04 13:00:00 2: CUL_HM set hz.wz3 desired-temp 24\
2013.11.04 13:01:00 3: get Kalender_Kueche summary yyy: 21.0\,19.0
2013.11.04 13:01:00 2: CUL_HM set hz.kueche desired-temp 21.0\
2013.11.04 13:01:00 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 13:01:00 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
Temperatur wird sowohl im Wohnzimmer als auch in der Küche korrekt gesetzt (obwohl noch ein"\" dran hängt - warum kommt in der Küche eine Fehlermeldung, im Wohnzimmer nicht? Das notify ist bei beiden identisch aufgebaut.
Liebe Grüße
Markus
Hallo Markus,
split ist kein FHEM kommando sondern einfach perl -also musst du dort suchen.
\ ist das "nehme explizit" Zeichen. Das nachfolgende wird nicht interpretiert. Wenn du es in "" packst funktioniert es ähnlich (nicht gleich!).
Gruss Martin
Also ich habe nochmal bei PERL nachgeschaut, die Syntax ist tatsächlich wie von mir verwendet split(/ / ...) und nicht split(" " ...).
Im Log sieht man ja auch, das die Splitfunktion korrekt funktioniert:
2013.11.04 13:35:00 3: get Kalender_Kueche summary xxx: 18 21
Damit wird der Kalendereintrag geholt.
2013.11.04 13:35:00 2: CUL_HM set hz.kueche desired-temp 18
Scheinbar wurde die 18 korrekt extrahiert und als desired Temperatur gesetzt.
2013.11.04 13:35:00 3: set hz.kueche desired-temp : desired-temp requires parameter: [on|off|5.0..30.0]
2013.11.04 13:35:00 3: HZ.Kueche_aus return value: desired-temp requires parameter: [on|off|5.0..30.0]
Jezt kommen die Fehlermeldungen, die ich nicht nachvollziehen kann. Gebe ich denselben Befehl per Hand ein, gibt es keine Fehlermeldung. Auch im Wohnzimmer mit demselben Notify gibt es keine Fehlermeldungen.
Nur in Küche und Bad.
Ich bin tatsächlich etwas ratlos, aber immerhin werden die Thermostate ja korrekt gestellt, ohne die Einträge im Log wäre mir das ja gar nicht aufgefallen.
Liebe Grüße
Markus
Zitat von: juelich am 04 November 2013, 13:42:52Also ich habe nochmal bei PERL nachgeschaut, die Syntax ist tatsächlich wie von mir verwendet split(/ / ...)
aber in Deinen oben zitierten notifies steht:
... split(/,,fhem( ... da fehlt irgendwo ein /
Zitat von: betateilchen am 04 November 2013, 13:49:35
aber in Deinen oben zitierten notifies steht: ... split(/,,fhem( ...
da fehlt irgendwo ein /
Du hast recht, ich hatte heute Morgen ein wenig rumexperimentiert und verschiedene Varianten durchgespielt, korrekt ist:
split(/ /,fhem("get Kalender_Kueche summary $uid")) mit einem Space als Trennzeichen wie in Deinem Skript,Betateilchen
Bei Dir sah das Ganze so aus:
my ($actor,$dtemp,undef)= split(/ /,fhem("get Kalender_Heizung summary $uid")); if(defined $actor) { fhem("set $actor desired-temp $dtemp")Da ich für jedes Zimmer einen eigenen Kalender habe, brauche ich den Actor nicht, sondern kann die Geräte direkt ansprechen.
Aber irgendwo sitzt da ein Fehler.
Viele Grüße
Markus
weisst Du, was grade etwas nervig ist?
Erstens, dass das Thema überhaupt nichts mit dem RT-DN zu tun hat, um den es hier im Thread eigentlich geht, sondern ein Problem mit Deiner Kalendernutzung. Mach doch einfach unter "Unterstützende Dienste" ein eigenes Thema dazu auf.
Zweitens, dass Du immer nur Bruchstücke von dem postest, was bei Dir definiert ist.
Drittens, dass wir uns den Rest immer zusammenreimen sollen.
Poste doch in dem neuen Thema dann eine komplette Aufstellung:
- Deine notify (in der TATSÄCHLICHEN Fassung)
- Deinen Kalendereintrag (irgendwo müssen die unterschiedlichen Zeiten ja herkommen)
Hallo Betateilchen,,
ich will natürlich niemanden nerven, bin aber trotzdem der Meinung, das es in diesem Thread korrekt ist, schließlich beziehe ich mich auf einen Beitrag und ein Skript von Dir in genau DIESEM Thread.
Und es geht um die Ansteuerung des HM-CC-RT-DN und Fehlermeldungen dabei. Ich bin mir auch wirklich nicht sicher, das die Fehlermeldungen am Notify liegen, denn (siehe LOG-Eintrag oben):
1. der Kalender wird richtig ausgelesen
2. Der HM-CC-RT-DN wird richtig programmiert
3. die Fehlermeldungen kommen 1x pro Stunde - wahrscheinlich (Vermutung) wenn der Kalender aktualisiert wird und sind HM-CC-RT-DN-spezifisch.
Meine Notify entspricht genau der die Du gepostet hast - mit dem Unterschied, das der $actor fehlt:
define HZ.Kueche_an notify Kalender_Kueche:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my ($dtemp,undef)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }
define HZ.Kueche_aus notify Kalender_Kueche:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my (undef,$dtemp)= split(/ /,fhem("get Kalender_Kueche summary $uid")); { fhem("set hz.kueche desired-temp $dtemp"); } }
Im Kalender sind Ereignisse definiert, die als Betreff die Temperaturen zu Beginn und Ende grennt durch ein " " enthalten. Genau so, wie Du es auch beschrieben hast und wie es auch in der Praxis bei mir funktioniert.
Viele Grüße
Markus
Zitat von: juelich am 04 November 2013, 14:25:52
3. die Fehlermeldungen kommen 1x pro Stunde - wahrscheinlich (Vermutung) wenn der Kalender aktualisiert wird und sind HM-CC-RT-DN-spezifisch.
Nein, dann sind sie
kalender-spezifisch. Denn der RT weiss überhaupt nichts von Deinem Kalender!
Und Deinem Kalender ist es im Gegenzug dazu auch
schnurzpiepegal, welche Art von Aktor er ansprechen soll.
Nochmal: Dein Problem kommt aus der Kalenderverarbeitung.
Hallo,
ich bin ein blutiger Anfänger und habe noch einmal eine Frage zum pairen.
Ich betreibe einen CUL an einer Fritzbox. Ich habe versucht, meinen CC-RT-DN zu pairen, wie es weiter vorne beschrieben wurde.
Es funktioniert aber nicht so richtig.
Der RT ist resetted. Ich schaffe es, die Message-queue zu leeren und den BurstMode einzuschalten (der set-Befehlt erzeugt 3 CMDs und diese werden beim drücken der Pairing-Taste am RT übertragen).
Leider gelingt kein vollständiges paring - der RT beendet die Suche nicht mit ACC - das FHEM legt aber alle Geräte bzw Kanäle an. Danach redet der RT nicht mehr mit dem FHEM - db ich sehe noch für ein paar Minuten, wenn ich am RT die desired Temperatur ändere (also am weissen Rad drehe), danach herrscht Funkstille.
Ferner habe ich festgestellt, dass der CUL an der Fritzbox immer paired, sobald ich die Taste am RT drücke. Das finde ich ein wenig merkwürdig, weil dadurch sich ja jedes Gerät ohne meine Kontrolle pairen könnte.
Was mache ich falsch?
Mir ist heute noch etwas interessantes aufgefallen:
Ist der RT mit keinem externen Temp-Sensor gepeered, regelt der Thermostat die Temperatur immer ca. 1° über die eingestellte Solltemperatur.
Gibt es aber einen gepeerten Sensor, fällt diese Differenz weg und die Solltemperatur wird sehr genau eingehalten.
Jetzt muss ich noch rausfinden, ob tempOffset im ClimRT_tr überhaupt noch eine Auswirkung hat, wenn die Temperaturdaten vom externen Sensor kommen. Im Moment sieht es nicht so aus.
Hallo Wagenrad,
was du sagst stimmt so nicht.
wenn du anlernen drückst erkennt FHEM das device und stellt es dar - es pairt aber nicht. Das Darstellen eines Devices und das pairen sind 2 paar Stiefel.
Das eintragen aller Devices (selbst die des Nachbarn) macht sinn - wenn sie im Empfangsbereich liegen. Die vom Nachbarn solltest du auf "ignore" setzen (sollte irgendwo geschrieben sein - oberhalb von HM!). Dann soll FHEM diese nicht weiter behandeln.
Auch der Nachbar wird deine Devices sehen - ist ja Funk - kann man nichts machen.
Daher musst du auch klar unterschieden zwischen "device ist angelegt in FHEM" und "device ist mit deinem FHEM gepairt".
ZitatLeider gelingt kein vollständiges paring - der RT beendet die Suche nicht mit ACC
was ist ein vollständiges pairen - und wer SUCHT was?
gepairt ist nur dann, wenn du im Reading PairedTo die HMId deines HMLAN/CUL/HMUSB findest.
ZitatDanach redet der RT nicht mehr mit dem FHEM - db ich sehe noch für ein paar Minuten, wenn ich am RT die desired Temperatur ändere (also am weissen Rad drehe), danach herrscht Funkstille.
dann hast du sicher nicht gepairt - der RT sendet die Änderung - wahrscheinlich nach broadcast. wenn er gepairt ist wird er die Zentrale regelmässig informieren.
Kontrolliere einmal genau, was eingetragen und gepairt ist.
Gruss Martin
Zitat von: martinp876 am 05 November 2013, 09:14:33was ist ein vollständiges pairen - und wer SUCHT was?
gepairt ist nur dann, wenn du im Reading PairedTo die HMId deines HMLAN/CUL/HMUSB findest.
martin, versuch einfach mal, als unbedarfter Anfänger zu denken:
Zitat von: wagenradich bin ein blutiger Anfänger
Der CUL (oder welche HM-Hardware auch immer) wird auf hmPairForSec gestellt und dann die Konfigurationstaste am RT gedrückt. Damit beginnt dort ein Zähler von 30 auf 0 rückwärts zu laufen und wird hoffentlich irgendwann mit der Meldung AC beendet. Das kann vom Verständnis eines neuen Homematic-Benutzers durchaus als eine vom RT ausgehende "Suche" nach einer Zentrale/Verbindung interpretiert und beschrieben werden ;)
Vielen Dank für die schnelle und gute Erklärung - es hat sofort geklappt!
Hallo!
gibt es neben den (teuren) externen Original-HM-Temp-Sensoren eigentlich (Eigenbau)-Alternativen?
Kann man beispielsweise einen JeeNode dazu bringen, mit HM zu kommunizieren?
Ich war kurz davor, diese Airwick-Lösung nachzubauen, bis mir dann eingefallen ist, dass ich sie dann ja gar nicht mit den HM-CC-RT-DN peeren kann. :o
Gruß
Spiff
mit genügend Lieben kann man viel nachbauen. JeeNode kenne ich nicht. Es gibt gerade eine Project mit einem panStamp HM devices zu simulieren - ist schon ziemlich weit. Die Impelmentierung hat einen "platform-gedanken" - soll also verscheidene Applikationen beherbengen können
Hallo,
Hab im Moment 2 HM-CC-RT-DN am laufen.
Morgen kommt meine Bestellung und 6 weitere dazu.
Wobei in einem Raum ( Esszimmer ) 2 Stück kommen.
Muss man was beachten wenn man dann 8 Stck am laufen hat ?
Gruß Josty
Hi Josty,
wenn man viele Devices am laufen hat sollte man mir "burst" vorsichtig sein. Die Kapazität des HMLAN ist begrenzt - und burst kostet Performance. Per default in FHEM wird es nicht genutzt.
Zur Klarstellung - das Register in RT kannst du gerne auf "on" stellen. Einziger Nachteil, es kostet mehr Batterie. Wenndu Fensterkontakte hast o.ä. ist es eh Pflicht. Aber das Attribut burstAccess sollte (eigentlich immer) besser off sein. Das Kommando burstXmit mit bedacht nutzen.
ein HMLAN kann in 1h ca. 100 mal burstXmit - wenn sonst nichts zu tun ist!
Besser ist es die Kommandos absetzen und auf das wakeup zu warten.
Ausserdem empfehle ich nach dem Programmieren der Bausteine ein "saveConfig". ggf systemweit mit HMinfo. Damit die Arbeit nicht verloren ist, sollte etwas crashen
Gruss Martin
Gibt es eigtl. neue Erfahrungen zu der zu hohen Temperatur die der DN regelt? Hat sich das mit der Zeit erledigt? Meiner regelt knapp 1,5°C zu hoch. Hab jetzt den ganzen Thread durchgeackert, aber keine Neuigkeiten dazu mehr gefunden auf den letzten 15 Seiten.
Zitat von: betateilchen am 02 Oktober 2013, 09:40:08
Wobei: Von der Traumvorstellung "Homematic auf RaspberryPi" bin ich inzwischen komplett abgekommen. Der Wechsel auf das Beaglebone Black hatte bereits > 90% aller HM-Probleme beseitigt. Alles was zeitkritisch ist (und das Homematic-Protokoll IST zeitkritisch) gehört nach meinen bisherigen Erfahrungen nicht auf den Raspberry. Dabei ist es auch unerheblich, ob man HMLAN oder HMUSB nutzt - ich habe beides probiert und hatte mit beidem auf dem Raspi massive Probleme.
Mhh ich nutze einen Raspberry Pi und einen CUL mit HM und habe keinerlei Probleme. Der CUL hängt mit einem weiteren für FS20 an einem USB billig Hub von Belkin. Wie kann ich denn die Timings checken? Oder ist das ein Problem, was man nur mit HMLAN und HMUSB hat?
Hallo,
was ist denn der unterschied zwichen dem Beaglebone Black und dem Raspberry Pi.
jetzt hast du mir aber Angst gemacht Betateilchen.
bin ja erst von Fritzbox auf raspberry umgestiegen mus ich jetzt wieder umsteigen ?
@ Betateilchen wieso kann ich dir keine Pn's schicken ?
Gruß Josty
Ist ein neuerer Prozessor er hat mehr Takt, den Arm v7, statt v6 Befehlssatz inkl NEON.
Hallo strauch,
8 Posts über deinem.
http://forum.fhem.de/index.php?topic=14738.msg104905#msg104905
Anscheinend ist bei einem Offset von 0°C mit dem internen Sensor in Wirklichkeit mind. +1°C eingestellt, um die Abwärme des Heizkörpers zu kompensieren - vielleicht stimmt das im Schnitt sogar, um dann die gewünschte Raumtemperatur zu erreichen.
Der Offset müsste eigentlich angepasst werden, wenn sich die Temperatur draußen ändert.
Wenn es knackekalt (und die Isolierung schlecht) ist, muss der Heizkörper mehr Wärme abstrahlen, um den Raum auf Temperatur zu halten. Insofern müsste der Offset dann eigentlich höher eingestellt werden, als wenn er nur lauwarm vor sich hinwärmt und relativ nah an der Innentemperatur liegt.
Gruß
Spiff
@Spiff vielen Dank, ich muss zugeben so ab Seite 30, hab ich mehr Überflogen als gelesen, ist doch sehr viel hier im Thread. Ich werde das mal im Wiki einfügen. Edit: Oder auch nicht, mein Konto im Wiki scheint es nicht mehr zu geben.
Hallo,
kann man die am Handrad Maximal einstellbare Temperatur festsetzen.
Die Kinder drehen gern auf 30 Grad und stellen nicht mehr runter.
würde das gern auf max 22 grad einstellen.
wie lautet dazu der Befehl ?
Gruß Josty
Hallo Josty
hilfe zur selbsthilfe...
mache ein
get <rt_Clima> regList
und du siehst was einstellbar ist Da findest du u.a. die Register
7: tempMax | 15 to 30.5C | | maximum temperatur
7: tempMin | 4.5 to 14.5C | | minimum temperatur
Und dann register setzen:
set <rt_Clima> regSet tempMax 22
ist zu finden, glaube ich.
Der maxwert gilt dann immer - vermute ich. Aber hier kannst du selbst testen.
Gruss Martin
Hallo
ja so hab ich es versucht
Zitatset Heizung_EZ regset tempMax 22
da kommt aber ein e Fehlermeldung.
kann es sein das das noch nicht implementiert ist bei den neuen Thermostaten?
ZitatUnknown argument regset, choose one of clear:readings,register,rssi,msgEvents desired-temp:on,off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0 getConfig getRegRaw mode peerBulk regBulk regSet sign:on,off sysTime tempListFri tempListMon tempListSat tempListSun tempListThu tempListTue tempListWed
Achte mal auf Groß- und Kleinschreibung, dann sollte es klappen.
set Heizung_EZ regSet tempMax 22
@betateilchen zum Thema Thermostat mit Temp. Sensor peeren: Habe ich gerade einmal getan, nachdem ich ersteinmal ein paar Wochen die Thermostate allein hab regeln lassen, der Temperatursensor lag im selben Raum zwecks logging. Als das Peering durch war, übernahm der Thermostat dann direkt den Temperaturwert vom Thermometer als measured-Temp und regelt danach - der nach wie vor eingestellte Offset wird offensichtlich ignoriert im Gegensatz zu vorher.
Hallo, ich habe Probleme beim übertragen meines Wochenprogramms.
Wenn ich es sende, sehe ich es in dem ClimRT_tr log. Aber bekomme ein CMDs_done_error und der Wochenplan wird nicht übernommen.
Kennt jemand das Problem?
wie überträgst du die Daten? nutzt du "prep/exec"? Siehe commandref. hast du die neuste SW? da ist noch eine weitere vebesserung (verzögerung) beim schreiben eingebaut, das vor allem dem langsamen RT zu gute kommen sollte
Habe am 05.11.13 das letzte Fhem update gemacht über "update check und update".
Meine TempListe ist mit "prep exec".
Gibt es seit dem 05.11. weitere Änderungen? Bzw. ist dieses Poblem bekannt?
Hallo Phil___
Am 5.11. hat es Änderungen in dieser Richtung gegeben. Die sind dann in einem Update am 6.11. per update verfügbar.
wenn du mir sagst, das "dieses Problem" ist, werde ich es prüfen. Will sagen deine du schreibst dass es Probleme gibt, ohne anzugeben, welche das sind. HMLAN overload, disconnect, missing ACK, NACK,...
Zum ersten ist wichtig, was GENAU du sendest.
weiter stellt FHEM zähler bereit, die Aussagen welcher Typ Fehler aufgetreten ist. - siehe prot... Einträge. Schön wäre, wenn du diese Zähler vor einem relevanten Versuch reseten würdest (clear msgEvents).
Hilfreich immer eine Beschreibung.
In vielen Fällen wichtig ist das loggen der roh-messages.
Probiere es jetzt erst einmal mit der neuen SW - natürlich kannst du gleich alle informationen erfassen und posten
Hallo,
neuste updates eingespielt. Aber die TempListen werden immer noch nicht übernommen.
Meine TempListe aus der 99_Utils.pm:
######################################################
## Temperatur-Liste Bad
## setzen per Aufruf von "{SetTempList_Bad_Heizung}"
######################################################
sub
SetTempList_Bad_Heizung()
{
{ fhem ("set BA_HTH_ClimRT_tr tempListMon prep 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0")};
{ fhem ("set BA_HTH_ClimRT_tr tempListTue prep 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0")};
{ fhem ("set BA_HTH_ClimRT_tr tempListWed prep 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0")};
{ fhem ("set BA_HTH_ClimRT_tr tempListThu prep 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0")};
{ fhem ("set BA_HTH_ClimRT_tr tempListFri prep 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0")};
{ fhem ("set BA_HTH_ClimRT_tr tempListSat prep 08:00 19.0 09:30 22.0 18:00 19.0 20:30 21.0 24:00 19.0")};
{ fhem ("set BA_HTH_ClimRT_tr tempListSun exec 08:00 19.0 09:30 22.0 18:00 19.0 20:30 21.0 24:00 19.0")};
}
# End SetTempList_Bad_Heizung
Log aus dem ClimRT_tr Channel:
2013-11-08_17:12:14 BA_HTH_ClimRT_tr motorErr: ok
2013-11-08_17:12:14 BA_HTH_ClimRT_tr measured-temp: 21.8
2013-11-08_17:12:14 BA_HTH_ClimRT_tr desired-temp: 21
2013-11-08_17:12:14 BA_HTH_ClimRT_tr ValvePosition: 23 %
2013-11-08_17:12:14 BA_HTH_ClimRT_tr mode: auto
2013-11-08_17:12:14 BA_HTH_ClimRT_tr unknown0: 24
2013-11-08_17:12:14 BA_HTH_ClimRT_tr T: 21.8 desired: 21 valve: 23 %
2013-11-08_17:12:18 BA_HTH_ClimRT_tr R-sign: off
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-reguIntI: 15
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-regAdaptive: on
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-winOpnMode: on
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-nightTemp: 17 C
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-winOpnDetFall: 1.4 K
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-winOpnTemp: 12 C
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-tempOffset: 0.0K
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-dayTemp: 21 C
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-reguIntPstart: 30
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-reguExtI: 15
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-reguExtP: 30
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-reguIntP: 30
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-showWeekday: off
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-winOpnPeriod: 15 min
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-tempMin: 4.5 C
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-tempMax: 30.5 C
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-winOpnBoost: off
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-valveMaxPos: 100 %
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-modePrioManu: all
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-daylightSaveTime: on
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-boostPos: 80 %
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-decalcWeekday: Sat
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-showInfo: time
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-btnNoBckLight: off
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-decalcTime: 11:00
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-reguExtPstart: 30
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-noMinMax4Manu: off
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-modePrioParty: all
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-valveErrPos: 15 %
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-boostPeriod: 5 min
2013-11-08_17:12:22 BA_HTH_ClimRT_tr R-valveOffset: 0 %
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempList_State: verified
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempListSat: 06:00 17.0 22:00 21.0 24:00 17.0
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempListSun: 06:00 17.0 22:00 21.0 24:00 17.0
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempListMon: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempListTue: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempListWed: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempListThu: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-08_17:12:22 BA_HTH_ClimRT_tr tempListFri: 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-08_17:15:02 BA_HTH_ClimRT_tr motorErr: ok
2013-11-08_17:15:02 BA_HTH_ClimRT_tr measured-temp: 21.9
2013-11-08_17:15:02 BA_HTH_ClimRT_tr desired-temp: 21
2013-11-08_17:15:02 BA_HTH_ClimRT_tr ValvePosition: 23 %
2013-11-08_17:15:02 BA_HTH_ClimRT_tr mode: auto
Ich kann da nur erkennen das da irgendwie nicht meine TempListe übertragen wird!?!?!
und hier das Logfile:
2013.11.08 17:11:40 1: HMLAN_Send: HMLAN1 I:K
2013.11.08 17:11:40 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707067 d:1E9E87 O:BADB33 t:F6B87FCB IDcnt:0005
2013.11.08 17:12:05 1: HMLAN_Send: HMLAN1 I:K
2013.11.08 17:12:05 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707067 d:1E9E87 O:BADB33 t:F6B8E17A IDcnt:0005
2013.11.08 17:12:14 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B90598 d:FF r:FFCD m:FC 8610 236D14 000000 0AA8DA0F1718
2013.11.08 17:12:14 1: RCV L:0F N:FC F:86 CMD:10 SRC:BA_HTH DST:broadcast 0AA8DA0F1718 (INFO_TEMP SET:42 ACT:218 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2013.11.08 17:12:14 2: CUL_HM set BA_HTH getConfig
2013.11.08 17:12:14 1: HMLAN_Send: HMLAN1 S:S387C3AE7 stat: 00 t:00000000 d:01 r:387C3AE7 m:09 A112 BADB33 236D14
2013.11.08 17:12:14 1: SND L:09 N:09 F:A1 CMD:12 SRC:BADB33 DST:BA_HTH (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.11.08 17:12:14 1: HMLAN_Parse: HMLAN1 R:R387C3AE7 stat:0001 t:F6B9069B d:FF r:FFCD m:09 8002 236D14 BADB33 00
2013.11.08 17:12:14 1: RCV L:0A N:09 F:80 CMD:02 SRC:BA_HTH DST:BADB33 00 (ACK) (,RPTEN)
2013.11.08 17:12:14 1: HMLAN_Send: HMLAN1 I:+236D14,00,00,
2013.11.08 17:12:14 1: HMLAN_Send: HMLAN1 S:S387C3BCB stat: 00 t:00000000 d:01 r:387C3BCB m:0A A001 BADB33 236D14 00040000000000
2013.11.08 17:12:14 1: SND L:10 N:0A F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 00040000000000 (CONFIG_PARAM_REQ CHANNEL:0x00 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x00) (,BIDI,RPTEN)
2013.11.08 17:12:15 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B90837 d:FF r:FFCD m:0A A010 236D14 BADB33 020100020109010ABA0BDB0C330E0A0F00
2013.11.08 17:12:15 1: RCV L:1A N:0A F:A0 CMD:10 SRC:BA_HTH DST:BADB33 020100020109010ABA0BDB0C330E0A0F00 (INFO_PARAM_RESPONSE_PAIRS DATA:0x0100020109010ABA0BDB0C330E0A0F00) (,BIDI,RPTEN)
2013.11.08 17:12:15 1: SND L:0A N:0A F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:15 1: HMLAN_Parse: HMLAN1 R:R387C3BCB stat:0001 t:F6B9083C d:FF r:FFCD m:0A A010 236D14 BADB33 020100020109010ABA0BDB0C330E0A0F00
2013.11.08 17:12:15 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B90937 d:FF r:FFCD m:0B 8010 236D14 BADB33 02110012151600180019001A000000
2013.11.08 17:12:15 1: RCV L:18 N:0B F:80 CMD:10 SRC:BA_HTH DST:BADB33 02110012151600180019001A000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x110012151600180019001A000000) (,RPTEN)
2013.11.08 17:12:15 1: HMLAN_Send: HMLAN1 S:+236D14,00,01,
2013.11.08 17:12:15 1: HMLAN_Send: HMLAN1 S:S387C3E76 stat: 00 t:00000000 d:01 r:387C3E76 m:0B A001 BADB33 236D14 0103
2013.11.08 17:12:15 1: SND L:0B N:0B F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 0103 (CONFIG_PEER_LIST_REQ CHANNEL:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:15 1: HMLAN_Parse: HMLAN1 R:R387C3E76 stat:0001 t:F6B90A41 d:FF r:FFCD m:0B 8010 236D14 BADB33 0100000000
2013.11.08 17:12:15 1: RCV L:0E N:0B F:80 CMD:10 SRC:BA_HTH DST:BADB33 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,RPTEN)
2013.11.08 17:12:15 1: HMLAN_Send: HMLAN1 S:S387C3F6D stat: 00 t:00000000 d:01 r:387C3F6D m:0C A001 BADB33 236D14 01040000000001
2013.11.08 17:12:15 1: SND L:10 N:0C F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 01040000000001 (CONFIG_PARAM_REQ CHANNEL:0x01 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:16 1: HMLAN_Parse: HMLAN1 R:R387C3F6D stat:0001 t:F6B90BD7 d:FF r:FFCD m:0C 8010 236D14 BADB33 0208000000
2013.11.08 17:12:16 1: RCV L:0E N:0C F:80 CMD:10 SRC:BA_HTH DST:BADB33 0208000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x08000000) (,RPTEN)
2013.11.08 17:12:16 1: HMLAN_Send: HMLAN1 S:+236D14,00,01,
2013.11.08 17:12:16 1: HMLAN_Send: HMLAN1 S:S387C4105 stat: 00 t:00000000 d:01 r:387C4105 m:0D A001 BADB33 236D14 0203
2013.11.08 17:12:16 1: SND L:0B N:0D F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 0203 (CONFIG_PEER_LIST_REQ CHANNEL:0x02) (,BIDI,RPTEN)
2013.11.08 17:12:16 1: HMLAN_Parse: HMLAN1 R:R387C4105 stat:0001 t:F6B90D6E d:FF r:FFCE m:0D 8010 236D14 BADB33 0100000000
2013.11.08 17:12:16 1: RCV L:0E N:0D F:80 CMD:10 SRC:BA_HTH DST:BADB33 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,RPTEN)
2013.11.08 17:12:16 1: HMLAN_Send: HMLAN1 S:S387C429E stat: 00 t:00000000 d:01 r:387C429E m:0E A001 BADB33 236D14 02040000000001
2013.11.08 17:12:16 1: SND L:10 N:0E F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 02040000000001 (CONFIG_PARAM_REQ CHANNEL:0x02 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:16 1: HMLAN_Parse: HMLAN1 R:R387C429E stat:0001 t:F6B90F05 d:FF r:FFCE m:0E 8010 236D14 BADB33 0208000000
2013.11.08 17:12:17 1: RCV L:0E N:0E F:80 CMD:10 SRC:BA_HTH DST:BADB33 0208000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x08000000) (,RPTEN)
2013.11.08 17:12:17 1: HMLAN_Send: HMLAN1 S:+236D14,00,01,
2013.11.08 17:12:17 1: HMLAN_Send: HMLAN1 S:S387C4433 stat: 00 t:00000000 d:01 r:387C4433 m:0F A001 BADB33 236D14 0303
2013.11.08 17:12:17 1: SND L:0B N:0F F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 0303 (CONFIG_PEER_LIST_REQ CHANNEL:0x03) (,BIDI,RPTEN)
2013.11.08 17:12:17 1: HMLAN_Parse: HMLAN1 R:R387C4433 stat:0001 t:F6B9109B d:FF r:FFCD m:0F 8010 236D14 BADB33 0100000000
2013.11.08 17:12:17 1: RCV L:0E N:0F F:80 CMD:10 SRC:BA_HTH DST:BADB33 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,RPTEN)
2013.11.08 17:12:17 1: HMLAN_Send: HMLAN1 S:S387C45C7 stat: 00 t:00000000 d:01 r:387C45C7 m:10 A001 BADB33 236D14 03040000000001
2013.11.08 17:12:17 1: SND L:10 N:10 F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 03040000000001 (CONFIG_PARAM_REQ CHANNEL:0x03 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:17 1: HMLAN_Parse: HMLAN1 R:E1B59EE stat:0000 t:F6B91208 d:FF r:FFC5 m:11 8670 1B59EE 000000 007959
2013.11.08 17:12:17 1: HMLAN_Parse: HMLAN1 R:R387C45C7 stat:0001 t:F6B91232 d:FF r:FFCD m:10 8010 236D14 BADB33 0208000000
2013.11.08 17:12:17 1: RCV L:0E N:10 F:80 CMD:10 SRC:BA_HTH DST:BADB33 0208000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x08000000) (,RPTEN)
2013.11.08 17:12:17 1: HMLAN_Send: HMLAN1 S:+236D14,00,01,
2013.11.08 17:12:17 1: HMLAN_Send: HMLAN1 S:S387C4763 stat: 00 t:00000000 d:01 r:387C4763 m:11 A001 BADB33 236D14 04040000000001
2013.11.08 17:12:17 1: SND L:10 N:11 F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 04040000000001 (CONFIG_PARAM_REQ CHANNEL:0x04 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:18 1: HMLAN_Parse: HMLAN1 R:R387C4763 stat:0001 t:F6B913C8 d:FF r:FFCD m:11 8010 236D14 BADB33 0208000000
2013.11.08 17:12:18 1: RCV L:0E N:11 F:80 CMD:10 SRC:BA_HTH DST:BADB33 0208000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x08000000) (,RPTEN)
2013.11.08 17:12:18 1: HMLAN_Send: HMLAN1 S:S387C48F7 stat: 00 t:00000000 d:01 r:387C48F7 m:12 A001 BADB33 236D14 04040000000007
2013.11.08 17:12:18 1: SND L:10 N:12 F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 04040000000007 (CONFIG_PARAM_REQ CHANNEL:0x04 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x07) (,BIDI,RPTEN)
2013.11.08 17:12:18 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91565 d:FF r:FFCD m:12 A010 236D14 BADB33 03012A22093D18030016073000640F0500
2013.11.08 17:12:18 1: RCV L:1A N:12 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 03012A22093D18030016073000640F0500 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x01 DATA:0x2A22093D18030016073000640F0500) (,BIDI,RPTEN)
2013.11.08 17:12:18 1: SND L:0A N:12 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:18 1: HMLAN_Parse: HMLAN1 R:R387C48F7 stat:0001 t:F6B9156A d:FF r:FFCD m:12 A010 236D14 BADB33 03012A22093D18030016073000640F0500
2013.11.08 17:12:18 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91666 d:FF r:FFCD m:13 A010 236D14 BADB33 03100000098E4448550845204520452045
2013.11.08 17:12:18 1: RCV L:1A N:13 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 03100000098E4448550845204520452045 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x10 DATA:0x0000098E4448550845204520452045) (,BIDI,RPTEN)
2013.11.08 17:12:18 1: SND L:0A N:13 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:19 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91767 d:FF r:FFCD m:14 A010 236D14 BADB33 031F204520452045204520452045204520
2013.11.08 17:12:19 1: RCV L:1A N:14 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 031F204520452045204520452045204520 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x1F DATA:0x204520452045204520452045204520) (,BIDI,RPTEN)
2013.11.08 17:12:19 1: SND L:0A N:14 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:19 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91868 d:FF r:FFCD m:15 A010 236D14 BADB33 032E444855084520452045204520452045
2013.11.08 17:12:19 1: RCV L:1A N:15 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 032E444855084520452045204520452045 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x2E DATA:0x444855084520452045204520452045) (,BIDI,RPTEN)
2013.11.08 17:12:19 1: SND L:0A N:15 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:19 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91969 d:FF r:FFCD m:16 A010 236D14 BADB33 033D20452045204520452045204448546C
2013.11.08 17:12:19 1: RCV L:1A N:16 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 033D20452045204520452045204448546C (INFO_PARAM_RESPONSE_SEQ OFFSET:0x3D DATA:0x20452045204520452045204448546C) (,BIDI,RPTEN)
2013.11.08 17:12:19 1: SND L:0A N:16 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:19 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91A6A d:FF r:FFCD m:17 A010 236D14 BADB33 034C44CC55084520452045204520452045
2013.11.08 17:12:19 1: RCV L:1A N:17 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 034C44CC55084520452045204520452045 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x4C DATA:0x44CC55084520452045204520452045) (,BIDI,RPTEN)
2013.11.08 17:12:19 1: SND L:0A N:17 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:20 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91B6B d:FF r:FFCD m:18 A010 236D14 BADB33 035B204520452045204448546C44CC5508
2013.11.08 17:12:20 1: RCV L:1A N:18 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 035B204520452045204448546C44CC5508 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x5B DATA:0x204520452045204448546C44CC5508) (,BIDI,RPTEN)
2013.11.08 17:12:20 1: SND L:0A N:18 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:20 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91C6C d:FF r:FFCD m:19 A010 236D14 BADB33 036A452045204520452045204520452045
2013.11.08 17:12:20 1: RCV L:1A N:19 F:A0 CMD:10 SRC:BA_HTH DST:BADB33 036A452045204520452045204520452045 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x6A DATA:0x452045204520452045204520452045) (,BIDI,RPTEN)
2013.11.08 17:12:20 1: SND L:0A N:19 F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:20 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91D6D d:FF r:FFCE m:1A A010 236D14 BADB33 03792045204448546C44CC550845204520
2013.11.08 17:12:20 1: RCV L:1A N:1A F:A0 CMD:10 SRC:BA_HTH DST:BADB33 03792045204448546C44CC550845204520 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x79 DATA:0x2045204448546C44CC550845204520) (,BIDI,RPTEN)
2013.11.08 17:12:20 1: SND L:0A N:1A F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:20 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91E6E d:FF r:FFCD m:1B A010 236D14 BADB33 0388452045204520452045204520452044
2013.11.08 17:12:20 1: RCV L:1A N:1B F:A0 CMD:10 SRC:BA_HTH DST:BADB33 0388452045204520452045204520452044 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x88 DATA:0x452045204520452045204520452044) (,BIDI,RPTEN)
2013.11.08 17:12:20 1: SND L:0A N:1B F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:21 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B91F6F d:FF r:FFCE m:1C A010 236D14 BADB33 039748546C44CC55084520452045204520
2013.11.08 17:12:21 1: RCV L:1A N:1C F:A0 CMD:10 SRC:BA_HTH DST:BADB33 039748546C44CC55084520452045204520 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x97 DATA:0x48546C44CC55084520452045204520) (,BIDI,RPTEN)
2013.11.08 17:12:21 1: SND L:0A N:1C F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:21 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B92070 d:FF r:FFCE m:1D A010 236D14 BADB33 03A6452045204520452045204448546C44
2013.11.08 17:12:21 1: RCV L:1A N:1D F:A0 CMD:10 SRC:BA_HTH DST:BADB33 03A6452045204520452045204448546C44 (INFO_PARAM_RESPONSE_SEQ OFFSET:0xA6 DATA:0x452045204520452045204448546C44) (,BIDI,RPTEN)
2013.11.08 17:12:21 1: SND L:0A N:1D F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:21 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B92171 d:FF r:FFCD m:1E A010 236D14 BADB33 03B5CC5508452045204520452045204520
2013.11.08 17:12:21 1: RCV L:1A N:1E F:A0 CMD:10 SRC:BA_HTH DST:BADB33 03B5CC5508452045204520452045204520 (INFO_PARAM_RESPONSE_SEQ OFFSET:0xB5 DATA:0xCC5508452045204520452045204520) (,BIDI,RPTEN)
2013.11.08 17:12:21 1: SND L:0A N:1E F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:21 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B9226F d:FF r:FFCD m:1F A010 236D14 BADB33 03C44520452045200F1E1E0F1E1E
2013.11.08 17:12:21 1: RCV L:17 N:1F F:A0 CMD:10 SRC:BA_HTH DST:BADB33 03C44520452045200F1E1E0F1E1E (INFO_PARAM_RESPONSE_SEQ OFFSET:0xC4 DATA:0x4520452045200F1E1E0F1E1E) (,BIDI,RPTEN)
2013.11.08 17:12:21 1: SND L:0A N:1F F:80 CMD:02 SRC:BADB33 DST:BA_HTH 00 (ACK) (,RPTEN)
2013.11.08 17:12:22 1: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:F6B92366 d:FF r:FFCD m:20 8010 236D14 BADB33 0300
2013.11.08 17:12:22 1: RCV L:0B N:20 F:80 CMD:10 SRC:BA_HTH DST:BADB33 0300 (INFO_PARAM_RESPONSE_SEQ OFFSET:0x00) (,RPTEN)
2013.11.08 17:12:22 1: HMLAN_Send: HMLAN1 S:+236D14,00,01,
2013.11.08 17:12:22 1: HMLAN_Send: HMLAN1 S:S387C58C9 stat: 00 t:00000000 d:01 r:387C58C9 m:13 A001 BADB33 236D14 0503
2013.11.08 17:12:22 1: SND L:0B N:13 F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 0503 (CONFIG_PEER_LIST_REQ CHANNEL:0x05) (,BIDI,RPTEN)
2013.11.08 17:12:22 1: HMLAN_Parse: HMLAN1 R:R387C58C9 stat:0001 t:F6B9244E d:FF r:FFCD m:13 8010 236D14 BADB33 0100000000
2013.11.08 17:12:22 1: RCV L:0E N:13 F:80 CMD:10 SRC:BA_HTH DST:BADB33 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,RPTEN)
2013.11.08 17:12:22 1: HMLAN_Send: HMLAN1 S:S387C5979 stat: 00 t:00000000 d:01 r:387C5979 m:14 A001 BADB33 236D14 05040000000001
2013.11.08 17:12:22 1: SND L:10 N:14 F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 05040000000001 (CONFIG_PARAM_REQ CHANNEL:0x05 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:22 1: HMLAN_Parse: HMLAN1 R:R387C5979 stat:0001 t:F6B925E5 d:FF r:FFCD m:14 8010 236D14 BADB33 0208000000
2013.11.08 17:12:22 1: RCV L:0E N:14 F:80 CMD:10 SRC:BA_HTH DST:BADB33 0208000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x08000000) (,RPTEN)
2013.11.08 17:12:22 1: HMLAN_Send: HMLAN1 S:+236D14,00,01,
2013.11.08 17:12:22 1: HMLAN_Send: HMLAN1 S:S387C5B12 stat: 00 t:00000000 d:01 r:387C5B12 m:15 A001 BADB33 236D14 0603
2013.11.08 17:12:22 1: SND L:0B N:15 F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 0603 (CONFIG_PEER_LIST_REQ CHANNEL:0x06) (,BIDI,RPTEN)
2013.11.08 17:12:23 1: HMLAN_Parse: HMLAN1 R:R387C5B12 stat:0001 t:F6B9277B d:FF r:FFCD m:15 8010 236D14 BADB33 0100000000
2013.11.08 17:12:23 1: RCV L:0E N:15 F:80 CMD:10 SRC:BA_HTH DST:BADB33 0100000000 (INFO_PEER_LIST PEER1:broadcast) (,RPTEN)
2013.11.08 17:12:23 1: HMLAN_Send: HMLAN1 S:S387C5CEA stat: 00 t:00000000 d:01 r:387C5CEA m:16 A001 BADB33 236D14 06040000000001
2013.11.08 17:12:23 1: SND L:10 N:16 F:A0 CMD:01 SRC:BADB33 DST:BA_HTH 06040000000001 (CONFIG_PARAM_REQ CHANNEL:0x06 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:23 1: HMLAN_Parse: HMLAN1 R:R387C5CEA stat:0001 t:F6B92912 d:FF r:FFCD m:16 8010 236D14 BADB33 0208000000
2013.11.08 17:12:23 1: RCV L:0E N:16 F:80 CMD:10 SRC:BA_HTH DST:BADB33 0208000000 (INFO_PARAM_RESPONSE_PAIRS DATA:0x08000000) (,RPTEN)
2013.11.08 17:12:30 1: HMLAN_Parse: HMLAN1 R:E20E087 stat:0000 t:F6B94225 d:FF r:FFC6 m:79 8670 20E087 000000 00DD56
2013.11.08 17:12:30 1: RCV L:0C N:79 F:86 CMD:70 SRC:BA_WTH DST:broadcast 00DD56 (WeatherEvent TEMP:22.1 HUM:86) (,WAKEMEUP,CFG,RPTEN)
2013.11.08 17:12:30 2: CUL_HM set BA_WTH statusRequest
2013.11.08 17:12:30 1: HMLAN_Send: HMLAN1 S:S387C7757 stat: 00 t:00000000 d:01 r:387C7757 m:17 A112 BADB33 20E087
2013.11.08 17:12:30 1: SND L:09 N:17 F:A1 CMD:12 SRC:BADB33 DST:BA_WTH (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.11.08 17:12:30 1: HMLAN_Send: HMLAN1 I:K
2013.11.08 17:12:30 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707067 d:1E9E87 O:BADB33 t:F6B94329 IDcnt:0006
2013.11.08 17:12:30 1: HMLAN_Parse: HMLAN1 R:R387C7757 stat:0001 t:F6B9432C d:FF r:FFC6 m:17 8002 20E087 BADB33 00
2013.11.08 17:12:30 1: RCV L:0A N:17 F:80 CMD:02 SRC:BA_WTH DST:BADB33 00 (ACK) (,RPTEN)
2013.11.08 17:12:30 1: HMLAN_Send: HMLAN1 I:+20E087,00,00,
2013.11.08 17:12:30 1: HMLAN_Send: HMLAN1 S:S387C7858 stat: 00 t:00000000 d:01 r:387C7858 m:18 A001 BADB33 20E087 010E
2013.11.08 17:12:30 1: SND L:0B N:18 F:A0 CMD:01 SRC:BADB33 DST:BA_WTH 010E (CONFIG_STATUS_REQUEST CHANNEL:0x01) (,BIDI,RPTEN)
2013.11.08 17:12:30 1: HMLAN_Parse: HMLAN1 R:R387C7858 stat:0001 t:F6B944C5 d:FF r:FFC6 m:18 8002 20E087 BADB33 01022A003D
2013.11.08 17:12:30 1: RCV L:0E N:18 F:80 CMD:02 SRC:BA_WTH DST:BADB33 01022A003D (ACK_STATUS CHANNEL:0x02 STATUS:0x2A UP:0 DOWN:0 LOWBAT:0 RSSI:-61) (,RPTEN)
2013.11.08 17:12:30 1: HMLAN_Send: HMLAN1 S:+20E087,00,01,
2013.11.08 17:12:30 1: HMLAN_Send: HMLAN1 S:S387C79F2 stat: 00 t:00000000 d:01 r:387C79F2 m:19 A001 BADB33 20E087 020E
2013.11.08 17:12:30 1: SND L:0B N:19 F:A0 CMD:01 SRC:BADB33 DST:BA_WTH 020E (CONFIG_STATUS_REQUEST CHANNEL:0x02) (,BIDI,RPTEN)
2013.11.08 17:12:31 1: HMLAN_Parse: HMLAN1 R:R387C79F2 stat:0001 t:F6B9465E d:FF r:FFC6 m:19 8002 20E087 BADB33 01022A003D
2013.11.08 17:12:31 1: RCV L:0E N:19 F:80 CMD:02 SRC:BA_WTH DST:BADB33 01022A003D (ACK_STATUS CHANNEL:0x02 STATUS:0x2A UP:0 DOWN:0 LOWBAT:0 RSSI:-61) (,RPTEN)
2013.11.08 17:12:31 1: HMLAN_Send: HMLAN1 S:+20E087,00,01,
2013.11.08 17:12:31 1: HMLAN_Send: HMLAN1 S:S387C7B8B stat: 00 t:00000000 d:01 r:387C7B8B m:1A A001 BADB33 20E087 030E
2013.11.08 17:12:31 1: SND L:0B N:1A F:A0 CMD:01 SRC:BADB33 DST:BA_WTH 030E (CONFIG_STATUS_REQUEST CHANNEL:0x03) (,BIDI,RPTEN)
2013.11.08 17:12:31 1: HMLAN_Parse: HMLAN1 R:R387C7B8B stat:0001 t:F6B947F7 d:FF r:FFC6 m:1A 8002 20E087 BADB33 01022A003D
2013.11.08 17:12:31 1: RCV L:0E N:1A F:80 CMD:02 SRC:BA_WTH DST:BADB33 01022A003D (ACK_STATUS CHANNEL:0x02 STATUS:0x2A UP:0 DOWN:0 LOWBAT:0 RSSI:-61) (,RPTEN)
2013.11.08 17:12:55 1: HMLAN_Send: HMLAN1 I:K
Kann mir da jemand was zu sagen?
Gruss Philipp
Hallo Phillipp,
wieder einmal ist mir etwas nicht klar...
FHEM schreibt alle Daten die geändert wurden. auch die Templist wird nicht pauschal übertragen.
stellt sich also erst einmal die Frage, was nicht übernommen wird.
In deinen registern sehe ich kein "set_" und die templist ist "verified".
Die Register werden alle gelesen - FHEM kann also sauber kommunizieren. Es ist aber nichts zu tun.
Ich kann auch nicht sehen, dass deine Kommandos ausgeführt werden.
hast du einmal probiert ein
set BA_HTH_ClimRT_tr tempListSun exec 08:00 19.0 09:30 22.0 18:00 19.0 20:30 21.0 24:00 19.0
einfach auszuführen? Was passiert?
Zitat von: martinp876 am 08 November 2013, 19:19:44
Ich kann auch nicht sehen, dass deine Kommandos ausgeführt werden.
hast du einmal probiert ein
set BA_HTH_ClimRT_tr tempListSun exec 08:00 19.0 09:30 22.0 18:00 19.0 20:30 21.0 24:00 19.0
einfach auszuführen? Was passiert?
Haben einmal oben stehend Set einzeln ausgeführt. Dieser ist dann anstandslos übernommen worden.
Anschließend habe ich dann noch einmal den kompletten Wochenplan gesendet und siehe da, er wurde komplett übernommen.
Ziehe die Frage zurück. Habe weiter oben etwas gefunden.
Was ist eigentlich genau die Bedeutung von protCondBurst?
Ich habe einige etwas träge reagierende RTs. Bei denen ist protConBurst meistens(!) auf off. Seltsamerweise sind das auch gerade die RTs, die ich mit Fensterkontakten gepeert habe (Zufall?).
burstRx ist überall on.
ein device das conditional burst (also burst einschaltbar ) unterstützt wird, wenn vom User ein burst-transmitt gefordert wird, getestet, ob burst aktuell verfügbar ist oder nicht. FHEM versucht genau einmal nach User-request - ob burst funktioniert und schreibt das Ergebniss in diesen Parameter.
Danke für die Antwort.
Und dass bei den RTs, die mit Fensterkontakten gepeert sind, sehr häufig burst nicht funktioniert ist wohl Zufall. Oder?
verstehe ich nicht.
ein SC der mit einem RT gepeert ist sollte tunlichst burst senden
beim RT sollte tunlichst burst enabled sein.
zufall sollte das nicht sein - das sollte man korrekt konfigurieren. FHEM sollte hier entsprechend burst einschalten, auf beiden Seiten.
Gruss Martin
Zitat von: martinp876 am 10 November 2013, 11:48:27
verstehe ich nicht.
ein SC der mit einem RT gepeert ist sollte tunlichst burst senden
beim RT sollte tunlichst burst enabled sein.
zufall sollte das nicht sein - das sollte man korrekt konfigurieren. FHEM sollte hier entsprechend burst einschalten, auf beiden Seiten.
Gruss Martin
Kann es sein, dass ein RT nur von einem Device aufgeweckt werden kann? Hier dann der gepeerte SC. Befehle von der Zentrale benötigen - zumindest bei mir - bei den SC-gepeerten RTs immer eine gewisse Zeit. Bei den ungepeerten RTs kommen alle Befehle (fast) sofort am RT an.
Viele Grüße
Christoph
Zitat von: CQuadrat am 10 November 2013, 14:03:04
Kann es sein, dass ein RT nur von einem Device aufgeweckt werden kann? Hier dann der gepeerte SC. Befehle von der Zentrale benötigen - zumindest bei mir - bei den SC-gepeerten RTs immer eine gewisse Zeit. Bei den ungepeerten RTs kommen alle Befehle (fast) sofort am RT an.
Hej Christoph,
nein - ist definitiv nicht so. Ich arbeite mich auch gerade in die RT/SC-Thematik ein und es funktioniert alles (mehr oder weniger) problemlos. Also zumindest das Aufwecken tut, wie es soll (sowohl von der Zentrale als auch vom SC). Das melden an die Zentrale + an vier Peers erfolgt (noch) nicht sooo ganz zuverlässig, wie ich es gerne hätte. Da bleibt hier und da schon mal ein RT auf der Strecke.
also noch einmal eine Langform:
ein burst weckt alle devices auf, die burst können. dann folgt die message mit sender-ID. jetzt sehen alle aufgewachten nach, ob die etwas mit dieser senderID zu schaffen haben (gepairt oder gepeert sind). wenn dass der Fall ist schauen sie in die Message hinein, ob sie diese verstehen....
Es ist, wie Mr. P gesagt hat - den RT von mehreren devices zu erwecken.
wenn diese aber nicht gepeert sind, schläft er wieder ein.
Naben zusammen.
Darf ich mich hier kurz mit meinem Problemchen an euch wenden?
Ich habe vier HM-CC-RT-DN und zwei Fensterkontakte gekauft. Das Konfigurieren des Wochenprogramms der HM-CC-RT-DN und das Koppeln mit den Fensterkontakten hat einwandfrei geklappt.
Jetzt wollte ich die Dinger mit meinem CUL_v3 und FHEM bedienen, habe das pairing im FHEM eingeschaltet und bekomme auch einen einigermassen vernünftigen Eintrag in der fhem.cfg.
define CUL_HM_HM_CC_RT_DN_21DDFB CUL_HM 21DDFB
attr CUL_HM_HM_CC_RT_DN_21DDFB .devInfo 00FFFF
attr CUL_HM_HM_CC_RT_DN_21DDFB .stc 59
attr CUL_HM_HM_CC_RT_DN_21DDFB actCycle 000:10
attr CUL_HM_HM_CC_RT_DN_21DDFB actStatus
attr CUL_HM_HM_CC_RT_DN_21DDFB firmware 1.0
attr CUL_HM_HM_CC_RT_DN_21DDFB model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB peerIDs
attr CUL_HM_HM_CC_RT_DN_21DDFB room CUL_HM
attr CUL_HM_HM_CC_RT_DN_21DDFB serialNr KEQ0573577
attr CUL_HM_HM_CC_RT_DN_21DDFB subType thermostat
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_Weather CUL_HM 21DDFB01
attr CUL_HM_HM_CC_RT_DN_21DDFB_Weather model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_Weather peerIDs
attr CUL_HM_HM_CC_RT_DN_21DDFB_Weather room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Weather FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_Weather-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_Weather
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Weather logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Weather room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_Climate CUL_HM 21DDFB02
attr CUL_HM_HM_CC_RT_DN_21DDFB_Climate model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_Climate room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Climate FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_Climate-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_Climate
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Climate logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_Climate room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec CUL_HM 21DDFB03
attr CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_WindowRec room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr CUL_HM 21DDFB04
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimRT_tr room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam CUL_HM 21DDFB05
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_ClimaTeam room CUL_HM
define CUL_HM_HM_CC_RT_DN_21DDFB_remote CUL_HM 21DDFB06
attr CUL_HM_HM_CC_RT_DN_21DDFB_remote model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_21DDFB_remote room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_remote FileLog ./log/CUL_HM_HM_CC_RT_DN_21DDFB_remote-%Y.log CUL_HM_HM_CC_RT_DN_21DDFB_remote
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_remote logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_21DDFB_remote room CUL_HM
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*
attr ActionDetector room CUL_HM
define FileLog_ActionDetector FileLog ./log/ActionDetector-%Y.log ActionDetector
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector room CUL_HM
Wenn ich mir dann den room CUL_HM anschaue bekomme ich
"ActionDetector alive:0 dead:0 unkn:1 off:0"
und hinter allen Einträgen unter CUL_HM stehen drei Fragezeichen, ebenso hinter dem Thermostat Eintrag
Wenn ich die "desired-temp" auf einen anderen Wert setze als 20 fängt es im Logfile ordentlich an zu rappeln:
2013.11.12 01:43:51 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 432
2013.11.12 01:43:55 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:43:55 5: SW: As0901B112F1123421DDFB
2013.11.12 01:43:55 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 433
2013.11.12 01:44:01 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:44:01 5: SW: As0901B112F1123421DDFB
2013.11.12 01:44:01 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 434
2013.11.12 01:44:06 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:44:06 5: SW: As0901B112F1123421DDFB
2013.11.12 01:44:06 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 435
2013.11.12 01:44:11 5: CUL1 sending As0901B112F1123421DDFB
2013.11.12 01:44:11 5: SW: As0901B112F1123421DDFB
2013.11.12 01:44:11 4: CUL_HM_Resend: CUL_HM_HM_CC_RT_DN_21DDFB nr 436
und es passiert genau nix am HM-CC-RT-DN
Wenn ich den Fensterkontakt Paire seh ich den und bekomme auch ordentlich "open" bzw. "close" angezeigt.
Ich hab mir das Funksignal mal mit einem SDR angeschaut, da kommt erst ein ordentlicher Piep-Ton und dann ein paar Daten
Interessant ist, dass der Fensterkontakt diesen Piep-Ton nicht schickt, dafür klappte dann am HM-CC-RT-DN sofort.
Hab das alles auch mit einem anderen HM-CC-RT-DN ausprobiert, gleiches Ergebnis. Ein fhem update habe ich gemacht und ich hab die aktuellste CUL Firmware drauf, ausserdem hab ich den HM-CC-RT-DN komplett auf Werkseinstellungen redetet und noch mal gepaired. Als Antenne hab ich ne Lambda/2, das machte aber wenig Pegel auf meinem SDR komischerweise, hab deshalb ein Kabel vernünftiger Länge genommen, viel besser der Pegel jetzt, trotzdem kann ich mit den Dingern nicht reden. Was mach ich falsch?
Hat sich erledigt, hab's selbst rausgefunden...
Die Antwort ist, wenn man das Set CUL1 hmPairForSec 600 in der fhem.cfg einträgt geht das nicht. Man muss das Kommando in der Kommandozeile eingeben, dann sagen die Thermostate auch sofort AC wenn man in den Pairing mode geht und alles ist gut.
Hallo,
zum Thema peeren von HM-CC-RT-DN mit einem HM-Sec-RHS Fensterkontakt wurde ja hier auf den letzten 37 Seiten einiges geschrieben.
Der Befehl allein bewirkt nicht wirklich viel.
set <fenster-sensor> peerChan 0 <rt_WindowRec> singleVielleicht kennt ja jemand hier eine zuverlässige Anleitung wie das peeren funktioniert und möchte das nocheinmal kundtun????!
Folgendes findet man zB auf den vorherigen 37 Seiten, was aber ziemlich verwirrend ist:
Zitat1) set <rt> clear msgEvents | bei dir ist die queue verstopft (siehe die noch 32 ausstehenden cmd's)
2) Prüfen, ob die queue leer ist => Reading "protcmdsPend" müsste was von CMDs_cleared oder 0 stehen => weiß es aber nicht mehr so genau?
2) set <hmlan> hmPairSerial KEQ0579448 (bitte die Seriennummer prüfen)
3) dann die Anlerntaste auf dem RT drücken -> dann ein wenig warten -> bis die CMDs abgearbeitet sind.
Kannst es ja mal versuchen - bei mir hat das so funktioniert.
Dann in FHEM neu paaren und ab gehts:
set HMLAN hmPairForSec 100
--Paarungstaste am Fensterkontakt drücken, dann blinkt er kurz gelb-grün--
set bad.klein.fenster peerChan 0 bad.klein.thermostat_WindowRec single
-- nun mal nochmal kurz die Paarungstaste drücken--
was du alles sehen solltest:
- fenster ist gepeert, RT_windowRec ist gepeert
- fenster hat "peerneedsburst" gesetzt (sonst wacht der RT nicht auf)
- fenster sendet beim öffnen einen trigger an den RT - notify und readings sind in FHEM zu sehen.
Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.
Danach geht's eigentlich generell...
Eine Schritt für Schritt Anleitung die man dann auch im Wiki platzieren kann wäre doch ganz gut!?
Geräte pairen, peeren und sonstige Einstellungen die notwendig sind wie zB set <RT> regSet burstRx on usw.
Danke und einen schönen Abend
Gruss Philipp
Hallo Philipp,
hmm ja das mit dem Wiki ist so eine Sache ... Zeit un Pflege...
Wie du festgestellt hast fehlt eine genaue Beschreibung.....
Es gibt eigentlich zwei Möglichkeiten (Beschreibung in Wiki folgt):
Variante 1: Peeren ausserhalb von FHEM (Das ganze muss ich aber noch verifizieren *das ganze nur aus dem Gedächtnis)
1) Anlernmodus auf dem RT aktivieren -> langer Tastendruck auf die "boost Taste (Taste in der Mitte)"
2) Anlernmodus auf dem RHS aktivieren -> drucke auf die Anlerntaste auf dem RHS (siehe Beschreibung/Bediensungsanleitung) -> (Meine Anleitung: Batterie-Deckel ab, hier befindet sich der Anlerntaste (liegt etwas tief) die gedrückt werden muss)
?) Bilder/Status fehlen - Wenn du jetzt Fester "auf/kippen lässt - müsste auf dem RT ein Fenter aufgehen bzw. sichbar sein.
Falls nicht, Vorgang wiederholen.
3) Falls alls ein Fenster zu sehen ist dann beginnt die FHEM pair Phase.
4) FHEM pair Prozess überspringe ich mal... Falls unklar einfach melden....
5) Danach sollte alles funktionieren.
Variante 2: Sensor (RHS) / Aktor RT mit FHEM pairen - anschliessend alles via peerChan über FHEM erledigen.
Anmerkung: Diese Variante habe ich bisher nicht erfolgreich getestet "sollte/müsste aber funktionieren" (Ich kämpfe aktuell mit Martin mit dem SC -> RHS folgt).
1) RHS mit FHEM pairen (FHEM pairing klar?)
2) RT mit FHEM pairen (FHEM pairing klar?)
3) set <fenster-sensor-SC/RHS> peerChan 0 <rt_WindowRec> single
4) Anlerntaste SC/RHS drücken "CMDs" prüfen...
5) set <RT>/<SC/RHS> getConfig ausführen -> bei SC/RHS Anlerntaste drücken
6) Channel: DG_HR_Gaestezimmer_WindowRec und Sensor <fenster-sensor> auf peer prüfen.
Sorry muss jetzt leider abbrechen - und stelle das mal zur Schau/Diskussion.
Viele Grüße
Arthur
Zitat von: snoop am 12 November 2013, 18:59:04
Variante 2: Sensor (RHS) / Aktor RT mit FHEM pairen - anschliessend alles via peerChan über FHEM erledigen.
Anmerkung: Diese Variante habe ich bisher nicht erfolgreich getestet "sollte/müsste aber funktionieren" (Ich kämpfe aktuell mit Martin mit dem SC -> RHS folgt).
1) RHS mit FHEM pairen (FHEM pairing klar?)
2) RT mit FHEM pairen (FHEM pairing klar?)
3) set <fenster-sensor-SC/RHS> peerChan 0 <rt_WindowRec> single
4) Anlerntaste SC/RHS drücken "CMDs" prüfen...
5) set <RT>/<SC/RHS> getConfig ausführen -> bei SC/RHS Anlerntaste drücken
6) Channel: DG_HR_Gaestezimmer_WindowRec und Sensor <fenster-sensor> auf peer prüfen.
Punkt 1 bis 3 sind klar und kann ich so beim RHS bestätigen.
Nach Punkt 3 stehen bei mir RT und RHS auf CMD_pending. Bei RT Boost-Taste/Anlerntaste ergibt ein CMD-done, beim RHS die Anlerntaste drücken wirft ein CMD_error aus.
Jetzt steht beim RT die peerID drinnen und beim RHS nicht. Soll das bzw. wie soll das sein?
Auch ein getConfig + anschließend Anlerntatse bringt keine Änderung.
Ich bleibe aber drann und werde morgen wieder ausgiebig Testen.
Gibt es evtl. noch andere Parameter die gesetz werden müssen oder gesetz sein sollten?
Wie zB. burstRx on oder peerNeedsBurst=on??
Gruss Philipp
Hallo Philipp,
mMn hast du bisher nichts falsch gemacht -> da muss jetzt Martin dran - vielleicht gibt es auch einen Zusammenhang mit dem SC (SC und StatusRequest Thema das vielleicht? ein peering blockiert).
@Martin: Die ganzen "vielleicht's" - hast du eine Idee - Logs könnte auch ich liefern ein RHS und einen RT habe ich auch noch hier liegen.
@Philipp: Falls du sofort loslegen möchtest dann nimm V1 - hat bei mir auf Anhieb funktioniert.
Viele Grüße
Arthur
Nabend,
wurde hier schon wieder was geändert, ich bekomme mal wieder kein Temp Liste gesetzt.
Der bleibt bei:
tempListWed set_ 05:20 17.0 06:10 23.0 19:00 17.0 23:00 19.0 24:00 17.0 2013-11-12 21:26:38
tempList_State set 2013-11-12 21:26:38
stehen. Ein get config läd dann wieder die alten Listen raus.
2013.11.12 21:26:38 2: CUL_HM set bz_Heizung_ClimRT_tr tempListWed 05:20 17.0 06:10 23.0 19:00 17.0 23:00 19.0 24:00 17.0
2013.11.12 21:26:42 3: HMLAN_Send: HMLAN1 I:K
2013.11.12 21:26:42 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:0CD443C1 IDcnt:000B
2013.11.12 21:26:44 3: HMLAN_Parse: HMLAN1 R:E1D2544 stat:0000 t:0CD44AD2 d:FF r:FFC0 m:1B 8670 1D2544 000000 00D33D
2013.11.12 21:27:04 3: HMLAN_Parse: HMLAN1 R:E1D2544 stat:0000 t:0CD498F4 d:FF r:FFC0 m:1B A258 1D2544 1D219B 000C
2013.11.12 21:27:04 3: HMLAN_Parse: HMLAN1 R:E1D219B stat:0000 t:0CD49978 d:FF r:FFBB m:1B 8202 1D219B 1D2544 010108003B
2013.11.12 21:27:07 3: HMLAN_Send: HMLAN1 I:K
2013.11.12 21:27:08 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:0CD4A7DA IDcnt:000B
2013.11.12 21:27:15 3: HMLAN_Parse: HMLAN1 R:E1D259A stat:0000 t:0CD4C6B3 d:FF r:FFBA m:16 8670 1D259A 000000 00C83C
2013.11.12 21:27:32 3: HMLAN_Send: HMLAN1 I:K
2013.11.12 21:27:33 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:0CD50987 IDcnt:000B
Viele Grüße
Daniel
Zitat von: Phil__ am 12 November 2013, 20:06:01
Punkt 1 bis 3 sind klar und kann ich so beim RHS bestätigen.
Nach Punkt 3 stehen bei mir RT und RHS auf CMD_pending. Bei RT Boost-Taste/Anlerntaste ergibt ein CMD-done, beim RHS die Anlerntaste drücken wirft ein CMD_error aus.
Jetzt steht beim RT die peerID drinnen und beim RHS nicht. Soll das bzw. wie soll das sein?
Auch ein getConfig + anschließend Anlerntatse bringt keine Änderung.
Ich bleibe aber drann und werde morgen wieder ausgiebig Testen.
Gibt es evtl. noch andere Parameter die gesetz werden müssen oder gesetz sein sollten?
Wie zB. burstRx on oder peerNeedsBurst=on??
Gruss Philipp
Hej Philipp,
hast du auch wirklich die aktuellste FHEM-Version?
Ich frage deshalb, weil Martin erst gestern etwas im Code geändert hat, weil es noch Probleme mit dem automatischen Setzen vom Burst gab.
Damit der Fensterkontakt funktioniert, muss am RT 'burstRx' und am SC/RHS 'peerNeedsBurst' auf 'on' sein. Soweit ich Martin aber verstanden habe, sollte das jetzt von selbst während des peer-Vorganges passieren.
Versuche zur Sicherheit einmal, das Peering vom RT nochmal zu löschen, dann bereits im Vorfeld 'burstRx' am RT aktivieren und dann nochmal die Liste zum Peeren durcharbeiten. Wenn das Peeren nicht gleich beim ersten Mal klappt (du wieder deine Fehlermeldung nach dem 'getConfig' vom RHS bekommst), versuche es gleich nochmal. Wenn es dann geklappt hat, muss in den Registern vom RHS dann der 'peerNeedsBurst'-Eintrag für deinen RT auf 'on' sein. Wenn nicht, dann diesen bitte auch noch händisch umsetzen (set <RHS> regSet peerNeedsBurst on <RT>) und mittels Anlerntaste übertragen. Sobald das geschafft ist, müsste eigentlich alles so klappen, wie du es möchtest.
Probier es nochmal aus, aber aktiviere während des ganzen Vorganges doch bitte einmal das Logging (set global verbose 1;;set global msec 1;;set <HM> verbose 1) in FHEM und lass uns das Ergebnis zukommen, sollte es immer noch nicht geklappt haben.
ist nicht dies die korrekte Schreibweise?
set global msec 1
Zitat von: JoeALLb am 13 November 2013, 09:42:19
ist nicht dies die korrekte Schreibweise?
set global msec 1
Du hast recht, dass ich beim Tippen einen Gedankenfehler gemacht hab... aber du hast diesen 1:1 übernommen. ;-)
Richtig lautet es also:
attr global verbose 1
attr global mseclog 1
attr <HM> loglevel 1
Stimmt, copy-paste Fehler! :D
Was ich aber nicht ganz verstehe... warum wird hier so gerne verbose 1 empfohlen, wenn doch eigentlich verbose 3 als "standard" gilt?
Müsste die Empfehlung für das Debuggen nicht eher verbose 5 sein?
Zitat von: JoeALLb am 13 November 2013, 09:59:29
Stimmt, copy-paste Fehler! :D
Was ich aber nicht ganz verstehe... warum wird hier so gerne verbose 1 empfohlen, wenn doch eigentlich verbose 3 als "standard" gilt?
Müsste die Empfehlung für das Debuggen nicht eher verbose 5 sein?
Die Antwort ist kurz und knackig... Es reicht! :-)
Umso mehr in einem Log steht, desto mehr muss man lesen... und wenn ich die für diesen Fall benötigten Infos bereits in L1 finde, warum mehr. :-)
Mr. P. hat recht (aus meiner sicht)
wenn ich rohmessages dekodieren sind diese aufbereitet und (fast) als Tabelle lesbar (für mich jedenfalls). Es bereitet unnötig Arbeit, den ganzen anderen kollateral-Messages zu entfernen um etwas lesbares zu erhalten.
Sehe es einfach so: wenn du jemandem logs zu Verfügung stellst, damit er ein Problem bei dir untersuchen kann - mache es ihm so einfach wie möglich, so wie er es anfordert. Es ist ja dein Problem, das er versucht zu lösen.
Bereite die Logs für dich nach deinen Vorlieben auf.
Danke!! Ich war nur etwas verwirrt durch die vielen unterschiedlichen Empfehlungen... und da es immer einfach nur hieß "schalte verbose ein" hätte es ja auch bedeuten können, dass jemand verbose1 mit verbose 5 vertauscht...
Hallo,
dieser Thread ist für den Einstieg in hm und die Heizungsthematik echt gold Wert. Danke.
Hier mal ein paar Gedanken von mir.
In der Wiki findet sich ein Artikel zur Heizungsteuerung mit fhem http://www.fhemwiki.de/wiki/Heizungskontrolle_Einfach (http://www.fhemwiki.de/wiki/Heizungskontrolle_Einfach). Meine Situation ist ähnlich. Ein (1) Raumthermostat mit BiMetall Streifen im Wohnzimmer steuert direkt die Pumpe des Heizkreislaufes. (Die Steuerung des Heizkessels bemerkt den Wärmebedarf und kümmert sich um die Temperatur im Kessel). d.h. wenn ich es morgens im Bad warm haben möchte muß ich abends daran denken die Heizung im Bad aufzudrehen und die Zeitschaltuhr heizt dann morgens bad und Wohnzimmer.
Mit einem Relaisbaustein HM-?? (ist im dunklen Keller :-) ) kann ich nun die Pumpe ein und ausschalten wenn eines der HM-CC_RT-DN im Haus Wärme brauchen, dadurch kann ich nun gezielter heizen (morgens im Bad, abends im Wohnzimmer).
Das oben erwähnte Skript ist für FS20 Komponenten die wohl etwas anders funktionieren (Thermostat=FHTS, Relais=FHS20 vs CUL_HM mit model bei homematic).
Daher sind in dem Skript folgende Änderungen notwendig:
Das Relais mit Namen swHKPumpe:
define swHKPumpe CUL_HM <xxxx>
...
jetzt die Thermostate z.B:
define thSchlaf CUL_HM <xxxx>
attr thSchlaf model HM-CC-RT-DN
....
Nun das Skript:
##
# Heizung notify ----------------------------------------------------------------
#
define n_heizung notify n_heizung {\
my $brauche_waerme=0;;\
my $ventile_im_leerlauf=0;;\
my $ventile_zu=0;;\
Die Funktion fs20_c2b kommt aus de 10_FS20.pm und scheint den Statusstring in einen Zahlenwert umzusetzen. Verstehe hier auch den Originalautor nicht warum der die Strings als schwierig ansieht (lasse mich gerne eines besseren belehren).
my $heizung_status=ReadingsVal("swHKPumpe","state","off");;\
So hier wird es spannend habe nur die Möglichkeit gefunden nach subtype zu filtern. MODEL und TYPE liefern viel zu viele devices die keinen actuator kennen.
my @@fhts=devspec2array("subType=thermostat");;\
foreach(@@fhts) {\
my $ventil=ReadingsVal($_, "actuator", "101%");;\
$ventil=(substr($ventil, 0, (length($ventil)-1)));;\
Log(3,"Ventil: " . $ventil);;\
if ($ventil > 20) {\
$brauche_waerme=1\
}\
if ($ventil < 10) {\
$ventile_im_leerlauf++\
}\
if ($ventil == 0) {\
$ventile_zu++\
}\
}\
if ($brauche_waerme != 0) {\
Log(3,"Wärme benoetigt. Vorheriger Heizungsstatus: " . $heizung_status);;\
fhem("set swHKPumpe on") if ($heizung_status ne "on")\
} else {\
if ($ventile_im_leerlauf == @@fhts) {\
Log(3,"Keine Wärme (mehr) benoetigt. Vorheriger Heizungsstatus: " . $heizung_status . $ventile_zu . " von " . @@fhts . " Ventile zu");;\
fhem("set swHKPumpe off") if ($heizung_status eq "on") \
} else {\
Log(3,"Heizbedarf: " . $ventile_im_leerlauf . " of " . @@fhts . " actuators are idle.")\
}\
}\
}
attr n_heizung room Heizung
define a_heizung at +*00:07:30 trigger n_heizung
attr a_heizung room Heizung
Nach einigen Tagen Test funktioniert das so wie es soll.
Ja, ich habe genau das gleiche Problem: Neustes Update und habe die Zeiten und Temperaturen gesetzt.
Trotzdem nimmt er immer die gesetzte R-nightTemp: 17C bzw. die R-dayTemp: 21C.
Hat da jemand genauere Infos wie man die Werte von den tempList übernehmen kann ?
Alternativ wäre es für mich auch schon Okay, wenn ich die R-nightTemp bzw. R-dayTemp ändern kann.
Danke schon mal !
Sorry, hat sich Grade erledigt...war zu ungeduldig :-S
Hallo,
neustes Update eben gemacht.
Aber es funktioniert nch immer nicht! (peering RHS -> RT)
Vllt sagen die Logs ja jemandem was?
Meine Vermutung, es scheinen ja bei perren 4 Messages an den RHS gesendet zu werden wenn man den peering Befehl absetzt "set BA_FDK peerChan 0 BA_HTH_WindowRec single".
Anschliesend wird die Anlerntaste gedrückt, der RHS blinkt Orange uns schließt mit einem roten Aufleuchten ab und gibt ein CMDs_done_Error bei dem RHS aus. Ich glaube der RHS bekommt die 4 Msg nicht alle gelesen??
den macht man das peering Rückgängig mit einem unset und drückt anschlißend die ANlerntaste blinkt es nur ganz kurz orange gefolgt von grün und es wird kein CMDs_done_Error ausgegeben.
RT und RHS resettet und neu mir FHEM gepairt.
Anschliesend: set BA_FDK peerChan 0 BA_HTH_WindowRec single
und Anlerntasten an RHS und RT gedrückt.
set getConfig RHS/RT
Beim RT scheint alles reibungslos zu funktionieren beim RHS bekomme ich ein CMDs_done_Error:1
RHS:
protLastRcv 2013-11-14 14:32:28
protResndFail 1 last_at:2013-11-14 14:32:29
protSnd 2 last_at:2013-11-14 14:32:27
protState CMDs_done_Errors:1
bei peerIDs steht nichtsbei dem RHS
RT:
protLastRcv 2013-11-14 14:32:23
protSnd 4 last_at:2013-11-14 14:32:23
protState CMDs_done
model HM-CC-RT-DN
peerIDs 00000000,1F118401
Log von WindowRec:
2013-11-14_14:32:23 BA_HTH_WindowRec R-sign: off
2013-11-14_14:32:23 BA_HTH_WindowRec R-BA_FDK_chn-01-shCtValLo: 50
Log von RHS:
2013-11-14_14:31:55 BA_FDK R-BA_HTH_WindowRec-expectAES: set_off
2013-11-14_14:31:55 BA_FDK R-BA_HTH_WindowRec-peerNeedsBurst: set_on
2013-11-14_14:32:26 BA_FDK alive: yes
2013-11-14_14:32:26 BA_FDK battery: ok
2013-11-14_14:32:26 BA_FDK cover: offen
2013-11-14_14:32:26 BA_FDK geschlossen
2013-11-14_14:32:26 BA_FDK contact: geschlossen (to HMLAN1)
2013-11-14_14:32:28 BA_FDK Activity: alive
2013-11-14_14:32:29 BA_FDK ResndFail
2013-11-14_14:32:29 BA_FDK MISSING ACK
FHEM Logfile:
2013.11.14 14:32:16 0: HMLAN_Parse: HMLAN1 R:E20E087 stat:0000 t:150DDEB7 d:FF r:FFC5 m:8B 8670 20E087 000000 00D94E
2013.11.14 14:32:17 0: HMLAN_Send: HMLAN1 S:S56CFEFE1 stat: 00 t:00000000 d:01 r:56CFEFE1 m:09 A112 BADB33 20E087
2013.11.14 14:32:17 0: HMLAN_Parse: HMLAN1 R:R56CFEFE1 stat:0001 t:150DDFBD d:FF r:FFC4 m:09 8002 20E087 BADB33 00
2013.11.14 14:32:17 0: HMLAN_Send: HMLAN1 I:+20E087,00,00,
2013.11.14 14:32:17 0: HMLAN_Send: HMLAN1 S:S56CFF0E3 stat: 00 t:00000000 d:01 r:56CFF0E3 m:0A A001 BADB33 20E087 010E
2013.11.14 14:32:17 0: HMLAN_Parse: HMLAN1 R:R56CFF0E3 stat:0001 t:150DE156 d:FF r:FFC4 m:0A 8002 20E087 BADB33 010226003F
2013.11.14 14:32:17 0: HMLAN_Send: HMLAN1 S:+20E087,00,01,
2013.11.14 14:32:17 0: HMLAN_Send: HMLAN1 S:S56CFF27B stat: 00 t:00000000 d:01 r:56CFF27B m:0B A001 BADB33 20E087 020E
2013.11.14 14:32:17 0: HMLAN_Parse: HMLAN1 R:R56CFF27B stat:0001 t:150DE2EF d:FF r:FFC6 m:0B 8002 20E087 BADB33 010226003E
2013.11.14 14:32:18 0: HMLAN_Send: HMLAN1 S:+20E087,00,01,
2013.11.14 14:32:18 0: HMLAN_Send: HMLAN1 S:S56CFF414 stat: 00 t:00000000 d:01 r:56CFF414 m:0C A001 BADB33 20E087 030E
2013.11.14 14:32:18 0: HMLAN_Parse: HMLAN1 R:R56CFF414 stat:0001 t:150DE488 d:FF r:FFC5 m:0C 8002 20E087 BADB33 010226003E
2013.11.14 14:32:21 0: HMLAN_Parse: HMLAN1 R:E236D14 stat:0000 t:150DF260 d:FF r:FFCD m:09 8400 236D14 BADB33 1000954B4551303537383035305900FFFF
2013.11.14 14:32:22 0: HMLAN_Send: HMLAN1 I:+236D14,00,00,
2013.11.14 14:32:22 0: HMLAN_Send: HMLAN1 S:S56D003C9 stat: 00 t:00000000 d:01 r:56D003C9 m:0D A001 BADB33 236D14 03011F11840101
2013.11.14 14:32:22 0: HMLAN_Parse: HMLAN1 R:R56D003C9 stat:0001 t:150DF34F d:FF r:FFCD m:0D 8002 236D14 BADB33 00
2013.11.14 14:32:22 0: HMLAN_Send: HMLAN1 S:S56D00472 stat: 00 t:00000000 d:01 r:56D00472 m:0E A001 BADB33 236D14 0303
2013.11.14 14:32:22 0: HMLAN_Parse: HMLAN1 R:R56D00472 stat:0001 t:150DF4E9 d:FF r:FFCE m:0E 8010 236D14 BADB33 011F11840100000000
2013.11.14 14:32:22 0: HMLAN_Send: HMLAN1 S:S56D00611 stat: 00 t:00000000 d:01 r:56D00611 m:0F A001 BADB33 236D14 03040000000001
2013.11.14 14:32:22 0: HMLAN_Parse: HMLAN1 R:R56D00611 stat:0001 t:150DF67F d:FF r:FFCF m:0F 8010 236D14 BADB33 0208000000
2013.11.14 14:32:23 0: HMLAN_Send: HMLAN1 S:S56D007A5 stat: 00 t:00000000 d:01 r:56D007A5 m:10 A001 BADB33 236D14 03041F11840103
2013.11.14 14:32:23 0: HMLAN_Parse: HMLAN1 R:R56D007A5 stat:0001 t:150DF816 d:FF r:FFCF m:10 8010 236D14 BADB33 0204320000
2013.11.14 14:32:23 0: HMLAN_Send: HMLAN1 I:K
2013.11.14 14:32:23 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707067 d:1E9E87 O:BADB33 t:150DF9D1 IDcnt:0005
2013.11.14 14:32:26 0: HMLAN_Parse: HMLAN1 R:E1F1184 stat:0000 t:150E0461 d:FF r:FFA3 m:66 A610 1F1184 BADB33 0601000E
2013.11.14 14:32:26 0: HMLAN_Send: HMLAN1 I:+1F1184,00,00,
2013.11.14 14:32:26 0: HMLAN_Send: HMLAN1 S:S56D0158A stat: 00 t:00000000 d:01 r:56D0158A m:66 8002 BADB33 1F1184 00
2013.11.14 14:32:26 0: HMLAN_Parse: HMLAN1 R:R56D0158A stat:0002 t:00000000 d:FF r:7FFF m:66 8002 BADB33 1F1184 00
2013.11.14 14:32:27 0: HMLAN_Send: HMLAN1 S:+1F1184,00,01,
2013.11.14 14:32:27 0: HMLAN_Send: HMLAN1 S:S56D017DA stat: 00 t:00000000 d:01 r:56D017DA m:11 A001 BADB33 1F1184 0101236D140300
2013.11.14 14:32:27 0: HMLAN_Parse: HMLAN1 R:R56D017DA stat:0008 t:00000000 d:FF r:7FFF m:11 A001 BADB33 1F1184 0101236D140300
2013.11.14 14:32:27 0: HMLAN_Parse: HMLAN1 no ACK from 1F1184
2013.11.14 14:32:28 0: HMLAN_Parse: HMLAN1 R:E1F1184 stat:0000 t:150E0B72 d:FF r:FFAC m:67 8400 1F1184 000000 2000304B45513030313932373380910101
2013.11.14 14:32:48 0: HMLAN_Send: HMLAN1 I:K
2013.11.14 14:32:48 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707067 d:1E9E87 O:BADB33 t:150E5B8C IDcnt:0005
Gruss Philipp
Sorry ich schieb mal ein Themenwechsel ein.
Wenn ich das Interne Thermostat des DN verwende, heizt er ja immer 1°C über der eingestellten Temperatur. Hier stand die Vermutung, das so der ungeünstig nahe Montageort zur Heizung ausgeglichen werden soll.
Was ich seltsam finde, ich hab z.B. für 2 Tage die Heizung aus, es ist im Raum wärmer als die eingestellten 19,5°C trotzdem fängt das Thermostat schon bei 21°C den Heizkörper aufzudrehen. Da die Heizung aber gar nicht an ist, spielt doch auch die ungünstige Position keine Rolle, da der Heizkörper ja kalt ist. Vielleicht logge ich mal mit einem externen Thermostat mit. Aber für mich würde das für den Abschaltpunkt "nach" dem Heizen Sinn machen, aber doch nicht auch schon wesentlich früher starten, wenn der Heizkörper gar nicht warm ist.
Weiß jemand wie das mit einer Homematiczentrale ausschaut?
Ich kann die Aussage (für Temperaturen über 20 Grad) bestätigen: Regelung ca. 1 Grad über Solltemperatur und "zu frühes" Einschalten,
Ich habe allerdings zwei RTs in (ungenutzten) Räumen, in denen ich die Temperatur auf 15 C geregelt habe. Seltsamerweise ist dort die Ist- und Soll-Temperatur fast identisch.
Hi,
ich schieben einmal ein paar grundsätzliche Gedanken ein - quer Beet...
Ich denke nicht, dass ein HM-Zentrale etwas anders machen kann. Es wird wohl irgendwann einen RT-controller geben (in der SW schon vorgesehen) , aber auch hier kann ich mir keine Veränderung vorstellen.
Eine Regelung - wenn sie gut ist - schaltet nicht ein, wenn der Wert unterschritten ist sondern regiert auf Änderungsgeschwindigkeiten. Wenn also die Temp schnell(er) fällt und sich dem Sollwert nähert sollte der Regler bereits aufmachen (oder zumachen, je nach Richtung). Im End-Ergebnis sollte er sich dann dem Sollwert anpassen - klar soweit.
Weiterer Punkt: der Regler ist erst einmal adaptiv eingestellt. Er wird also seine Regel-koeffizienten dem Raum anpassen. Das kann auch gut gehen - wenn der Raum und seine Parameter stabil sind.
Schwierig wird es, wenn man manchmal offene Türen hat und manchmal nicht. Dann "reagiert" der Raum anders, je nach Größe der Türen und dem Klima im Nebenraum.
Schlimmer noch ist sicher die Vorlauftemperatur der Heizung. Der Regler versucht nun "auszurechnen" wieviel Temperatur-Änderung ein verstellen des Ventils um x% bedeutet. Je nachdem wir Clever jetzt aber die Heizung im Keller ist wird die vorlauf-temp aber verändert - zeitgesteuert, Außentemperatur gesteuert oder sonst noch was. All das KANN der Regler nicht wissen und wird immer wieder stolpern. Ich erwarte daher nicht, dass das adaptive Regler-Einstellen auf dauer taugt. In einem Stabilen Raum mit stabiler - oder wenigstens nur leicht geregelter Vorlauftemperatur sollte es schon gehen.
Was ich vorhabe, wenn ich den RT finetune:
- über den temperatur-offset sollte sich die permanente Regelabweichung ausgleichen lassen. Hierzu sollte man verschiedene Temperaturen einstellen, den Raum einschwingen lassen und die temp im Raum messen. Es kommt hoffentlich eine fixe Regelabweichung heraus.
- die Adaptive Regelung will ich erst einmal beobachten. danach kann man an den Parametern "P" und "I" herumspielen. Ich vermute, dass nur "int" relevant ist - "ext" ist wohl für die Nutzung eines externen Thermostats (glaube ich). P ist der Proportional-Anteil der Regelung, also eine Art Offset/Verstärkung. "I" ist der Integralteil also die "Beschleunigung" wenn Änderungen passieren. Das Thema ist nicht einfach - daher beschreibt es HM auch gar nicht.
Vielleicht hat jemand noch etwas mehr in Regler-theorie drauf als ich und kann ein paar Tips geben. Es wird jedenfalls eine langwierige Messung. Am Schluss will ich den Regler auf "tages-heizung" optimieren und bei der Nachtabsenkung mit Abweichungen leben.
Nach meinen Beobachtungen reagiert der Regler ausschließlich auf die Regel -differenz. Es sollte also egal sein, ob die Temp um 5Grad sinkt oder die soll-temp um 5Grad angehoben wird. Der Regler sagt immer "huch - Änderung: ist die Soll-temp in Gefahr, dann Aktion"
Gruss Martin
@Martin
Kannst du in den Logs das Problem beim Peeren von RT und RHS erkennen?
Gruss Philipp
@Martin,
da hast du schon recht, also bei mir hat er bei 20,7°C gestartet (desired war 19,5) und ist gerade mal runter auf 20,5 und dann wieder gestiegen. Gut wenn er immer 1° drüber sein will hat er es genau geschafft. Vielleicht ist das auch noch ein Lernprozess für den PID. Evtl. kann da betateilchen weiter helfen, er ist ja auch viel im Kaffee Forum unterwegs, da gibts ja auch PID Steuerung und technisch ist er ja gut bewandert.
Müsste man mal dazu einfach Stumpf im ELV Forum fragen, vielleicht erfährt man ja so was die sich dabei gedacht haben. Darauf zielte so ein wenig meine Frage auf die Homematiczentrale ab. Wenn man da was von FHEM schreibt, schieben die das bestimmt darauf.
Grüße
strauch
Hallo Philipp,
ich sehe folgendes:
dem RT wird der RHS als peer für channel 03 zugewiesen, die Register des RT werden upgedated. Alles prima.
der RHS schickt eine status Meldung (ist das Zufall? genau jetzt) autonom. Die Zentrale antwortet und will den peer addieren. Der RHS ist als wakeup definiert und sollte jetzt antworten. Leider tut er das aber nicht.
Das Anlernen kommt 1 sec später - da sind schon alle messages gelöscht.
Was du jetzt tun kannst ist, das kommando wiederholen mit "remote" am ende, dann anlernen am RHS drücken. Dann sollte nur der RHS mit dem RT gepeert werden - der RT bleibt wie er ist (ist ja schon fertig). das sollte ohne Probleme funktionieren.
Evtl muss man dem RHS die "wakeup" Möglichkeit aberkennen..
Gruss Martin
Hallo Martin,
die Status-Meldung des RHS muss zufall gewesen sein, es wurde kein Fenster geöffnet.
Wie erkenne ich dem RHS die "wakeup" Möglichkeit ab?
Gruss Philipp
Hallo Phillip,
kannst du nicht, mache ich. Ist am Model festgemacht.
Er sollte aber nur einmal am Tag aufwachen... so steht es geschrieben.
Kannst du das bestätigen? Einmal am Tag ein Status-update vom RHS?
Gruss Martin
Hallo Martin,
aber nur wie beim SEC-SC mit cyclicInfoMsg on.
Bei einenen der RHS mit "off" habe ich schon seit ein paar Tagen nichts mehr gehört.
Viele Grüße
Arthur
Hallo Arthur,
klar - verstanden. Was ich verstehen und einbauen will ist, mit den Devices zu "reden" wenn sie aufwachen. Bei TC, VD und RT funktioniert dies, bei RHS u.ä. ist dies offensichtlich nicht der Fall.
Dennoch hat das Format, das FHEM senden soll nicht richtig gepasst.
Wenn du Lust zum testen hast konnen wir es noch einmal durchtesten. Zum Einstieg ware es gut, erst einmal die Messages des Device aufzuzeichnen - die Zyklische und die, wenn ein Event passiert ist.
Gruss Martin
Hallo Martin,
ok, Vorschlag - machen wir dann per pm - sonst wird das zu viel für den Thread und es dauert ja ein paar Tage (hoffe nicht) - Vollzugsmeldung dann wieder hier.
Viele Grüße
Arthur
Moin,
also ich bekomme neuerdings immer ein missing ack wenn ich die Templiste setzen möchte. Hängt das damit zusammen das ich die Tastensperre drin habe?!? Alles andere funktioniert, also temp setzen. modus ändern getconf etc...
Gruß
Daniel
Hallo Daniel,
da brauche ich mehr Details. Kannst du die rohmessages aufzeichnen? Wie sind die burst einstellungen? Wieviel temps setzt du? Alle 7? Mit oder ohne prep?
Gruss Martin
Hallo Martin,
Sag mal das attr Loglevel gibts nicht mehr? Wie bekomme ich denn jetzt das debug logging an?
- Ich setze ich immer nur ein Tag und warte bis der geschrieben wurde
- Thema "Bürste" habe ich das hier: R-burstRx on 2013-11-17 09:48:47
Gruß und Danke
Daniel
Ganz frisch von der Pinwand. ;-)
http://forum.fhem.de/index.php/topic,16563.0.html (http://forum.fhem.de/index.php/topic,16563.0.html)
Ahh super, danke, im Wiki hatte ich nichts gefunden ;-)
Dann machen wir das doch gleich mal:
2013.11.17 19:05:11 2: CUL_HM set bz_Heizung_ClimRT_tr tempListMon 05:20 17.0 06:10 23.0 19:00 17.0 23:00 19.0 24:00 17.0
2013.11.17 19:05:24 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:05:24 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:26139E12 IDcnt:000B
2013.11.17 19:05:49 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:05:49 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:2613FFCF IDcnt:000B
2013.11.17 19:06:14 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:06:14 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:2614617D IDcnt:000B
2013.11.17 19:06:39 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:06:39 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:2614C32C IDcnt:000B
2013.11.17 19:07:04 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:07:04 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:26152664 IDcnt:000B
2013.11.17 19:07:06 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26152BE5 d:FF r:FFC0 m:B3 8610 21CE0D 000000 0A88B80F0012
2013.11.17 19:07:06 2: CUL_HM set bz_Heizung_ClimRT_tr getConfig
2013.11.17 19:07:06 0: HMLAN_Send: HMLAN1 S:S673E9EDE stat: 00 t:00000000 d:01 r:673E9EDE m:14 A112 23FF23 21CE0D
2013.11.17 19:07:06 0: HMLAN_Parse: HMLAN1 R:R673E9EDE stat:0001 t:26152CE5 d:FF r:FFC0 m:14 8002 21CE0D 23FF23 00
2013.11.17 19:07:06 0: HMLAN_Send: HMLAN1 S:+21CE0D,00,01,
2013.11.17 19:07:06 0: HMLAN_Send: HMLAN1 S:S673E9FD7 stat: 00 t:00000000 d:01 r:673E9FD7 m:15 A001 23FF23 21CE0D 00050000000007
2013.11.17 19:07:06 0: HMLAN_Parse: HMLAN1 R:R673E9FD7 stat:0001 t:26152E78 d:FF r:FFC0 m:15 8002 21CE0D 23FF23 00
2013.11.17 19:07:06 0: HMLAN_Send: HMLAN1 S:S673EA169 stat: 00 t:00000000 d:01 r:673EA169 m:16 A001 23FF23 21CE0D 000849404B4A
2013.11.17 19:07:07 0: HMLAN_Parse: HMLAN1 R:R673EA169 stat:0001 t:2615300B d:FF r:FFC0 m:16 8002 21CE0D 23FF23 00
2013.11.17 19:07:07 0: HMLAN_Send: HMLAN1 S:S673EA2FD stat: 00 t:00000000 d:01 r:673EA2FD m:17 A001 23FF23 21CE0D 0006
2013.11.17 19:07:08 0: HMLAN_Parse: HMLAN1 R:R673EA2FD stat:0001 t:2615319E d:FF r:FFC0 m:17 8002 21CE0D 23FF23 00
2013.11.17 19:07:08 0: HMLAN_Send: HMLAN1 S:+21CE0D,00,01,
2013.11.17 19:07:08 0: HMLAN_Send: HMLAN1 S:S673EA703 stat: 00 t:00000000 d:01 r:673EA703 m:18 A001 23FF23 21CE0D 04040000000001
2013.11.17 19:07:08 0: HMLAN_Parse: HMLAN1 R:R673EA703 stat:0008 t:00000000 d:FF r:7FFF m:18 A001 23FF23 21CE0D 04040000000001
2013.11.17 19:07:08 0: HMLAN_Parse: HMLAN1 no ACK from 21CE0D
2013.11.17 19:07:29 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:07:29 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:26158837 IDcnt:000B
Wenn ich ein getconfig mache kommt das auch erst teilweise nach Minuten. Kann es sein das mit diesem Burst Mode irgend was nicht richtig hin haut bei mir?
Gruß
Daniel
Ahh jetzt hat er es gemacht eben! Aber sehr verzögert.
2013.11.17 19:08:45 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:08:45 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:2616AE44 IDcnt:000B
2013.11.17 19:09:10 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:09:10 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:26171250 IDcnt:000B
2013.11.17 19:09:28 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:2617589F d:FF r:FFC1 m:B4 8610 21CE0D 000000 0A88B80F0012
2013.11.17 19:09:28 0: HMLAN_Send: HMLAN1 S:S6740CB82 stat: 00 t:00000000 d:01 r:6740CB82 m:19 A112 23FF23 21CE0D
2013.11.17 19:09:28 0: HMLAN_Parse: HMLAN1 R:R6740CB82 stat:0001 t:261759A0 d:FF r:FFC1 m:19 8002 21CE0D 23FF23 00
2013.11.17 19:09:28 0: HMLAN_Send: HMLAN1 S:S6740CC7E stat: 00 t:00000000 d:01 r:6740CC7E m:1A A001 23FF23 21CE0D 04040000000001
2013.11.17 19:09:29 0: HMLAN_Parse: HMLAN1 R:R6740CC7E stat:0001 t:26175B37 d:FF r:FFC1 m:1A 8010 21CE0D 23FF23 0208000000
2013.11.17 19:09:29 0: HMLAN_Send: HMLAN1 S:S6740D070 stat: 00 t:00000000 d:01 r:6740D070 m:1B A001 23FF23 21CE0D 04040000000007
2013.11.17 19:09:30 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26175E3B d:FF r:FFC0 m:1B A010 21CE0D 23FF23 03012A22093D18030016093000640F0500
2013.11.17 19:09:30 0: HMLAN_Parse: HMLAN1 R:R6740D070 stat:0001 t:26175E40 d:FF r:FFC0 m:1B A010 21CE0D 23FF23 03012A22093D18030016093000640F0500
2013.11.17 19:09:30 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26175F3D d:FF r:FFC0 m:1C A010 21CE0D 23FF23 03100000098E4520547844E44D14452045
2013.11.17 19:09:30 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:2617603F d:FF r:FFC0 m:1D A010 21CE0D 23FF23 031F204520452045204520452045204520
2013.11.17 19:09:30 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176141 d:FF r:FFC1 m:1E A010 21CE0D 23FF23 032E4520547844E44D1445204520452045
2013.11.17 19:09:31 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176242 d:FF r:FFC0 m:1F A010 21CE0D 23FF23 033D204520452045204520452044405C4A
2013.11.17 19:09:31 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176344 d:FF r:FFC1 m:20 A010 21CE0D 23FF23 034C44E44D144520452045204520452045
2013.11.17 19:09:31 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176446 d:FF r:FFC0 m:21 A010 21CE0D 23FF23 035B2045204520452044425C4E44E44D14
2013.11.17 19:09:31 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176548 d:FF r:FFC1 m:22 A010 21CE0D 23FF23 036A452045204520452045204520452045
2013.11.17 19:09:32 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:2617664A d:FF r:FFC1 m:23 A010 21CE0D 23FF23 037920452044405C4A44E44D1445204520
2013.11.17 19:09:32 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:2617674B d:FF r:FFC1 m:24 A010 21CE0D 23FF23 0388452045204520452045204520452044
2013.11.17 19:09:32 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:2617684D d:FF r:FFC1 m:25 A010 21CE0D 23FF23 0397425C4E44E44D144520452045204520
2013.11.17 19:09:33 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:2617694F d:FF r:FFC0 m:26 A010 21CE0D 23FF23 03A64520452045204520452044425C4E44
2013.11.17 19:09:33 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176A51 d:FF r:FFC1 m:27 A010 21CE0D 23FF23 03B5E44D14452045204520452045204520
2013.11.17 19:09:33 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176B50 d:FF r:FFC1 m:28 A010 21CE0D 23FF23 03C44520452045200B1A050F1E1E
2013.11.17 19:09:33 0: HMLAN_Parse: HMLAN1 R:E21CE0D stat:0000 t:26176C47 d:FF r:FFC1 m:29 8010 21CE0D 23FF23 0300
2013.11.17 19:09:35 0: HMLAN_Send: HMLAN1 I:K
2013.11.17 19:09:35 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:2617740C IDcnt:000B
Ich hab eben schon schweißausbrüche bekommen!!! Mein FHEM lief beim Start im loop.
Schult war: attr HMLAN1 logIDs sys,bz_Heizung
Also da ist noch irgendwo ein Bug ;-)
Gruß
Daniel
Guten Morgen,
also irgend etwas ist da komisch bei mir, ich hatte gestern 2 Tage gesetzt, das ging auch nach einigen Minuten aber dann hatte ich den Donnerstag noch gesetzt und der steht bis jetzt auf nicht gesendet:
tempListThu set_ 05:20 17.0 06:10 23.0 19:00 17.0 23:00 19.0 24:00 17.0 2013-11-17 21:51:24
Kann ich da noch irgend etwas checken was ich eventuell vergessen habe oder falsch eingestellt/übersehen? Ich habe an dem RT direkt noch ein Fensterkontakt angelernt.
Oder macht es eventuell Sinn das ganze Gerät am FHEM neu an zu lernen?
Gruß
Daniel
Hallo Daniel,
logIDs ist in Version 4243 korrigiert. HMLAN hat die HM devices gesucht bevor sie instanziiert waren. Problem war nur bei neustart wenn das Attribut in fhem.cfg gesetzt war.
ZitattempListThu set_ 05:20 17.0 06:10 23.0 19:00 17.0 23:00 19.0 24:00 17.0 2013-11-17 21:51:24
zuerst:
- ist das Kommando gesendet? Sind noch Kommands "pending"?
- hat FHEM Fehler beim übertragen gemeldet?
du kannst ein "getConfig" machen - das liest die Daten aus dem Device. wenn noch eine Kommunikation möglich ist.
Neu anlernen sollte nicht notwendig sein.
Wie überträgst du die Daten? Config, wakeup oder burst? Das Device sollte alles können
Gruss Martin
Hallo Martin,
ich hab das eben nochmal durchgespielt und da lief es wieder, das ist wieder typisch oO. Aber vielleicht liegt es doch an Funk Störungen. Ich sitze ja jetzt im Büro und nicht zu Hause, da kann ich mit meinen Massen nicht die Funkwellen versauen ;-)
R-burstRx on
protState CMDs_done
--> get config
protCmdPend 13 CMDs_pending
protState CMDs_pending
--> protState CMDs_done
--> Temp liste von Donnerstag setzen
protCmdPend 3 CMDs_pending
protState CMDs_pending
--> nach ca. 20 Sekunden all done
Aber "R-burstRx on" heißt doch das ich diesen Burst Modus benutze oder? Kann ich das an einer anderen Stelle noch verifizieren? Das ist bei mir anscheinend nur ein sporadisches Problem. Mal geht es mal nicht, wobei -nicht- bedeutet das es auch mal 1 Tag dauern kann bis der Befehl durch ist. Mein RSSI ist "HMLAN1_RSSI -63" was ja nun auch nicht unbedingt schlecht ist. Ich habe bestimmt an irgend einer Stelle etwas falsch oder ungünstig konfiguriert. Auffallend ist nur, dass ich immer ein missing ack bekomme wenn es denn mal nicht geht.
Naja falls nicht ist auch egal, ich kann damit leben, so viel mache ich mit dem Ding im Bad nicht und die Temp Liste ändere ich zur Not auch am Gerät. Gibt wichtigeres ;-)
Gruß
Daniel
Zitat von: ext23 am 18 November 2013, 13:00:36Aber "R-burstRx on" heißt doch das ich diesen Burst Modus benutze oder?
Hej Daniel,
wenn du burstRx auf on gesetzt hast, dann läuft der RT im Burst-Mode. Lauscht also ständig und kann jederzeit geweckt werden um Befehle zu empfangen (wichtig zB bei Fensterkontakten).
Solange du unter FHEM aber nicht beim RT unter den Attributen den Wert 'burstAccess' auf '1_auto' gesetzt hast, arbeitet FHEM wie gehabt. Es wartet, bis sich der RT alle 2,5 Minuten meldet und überträgt dann die noch ausstehenden Pakete.
Im Normalfall wird dir das genügen und du sparst eine Menge Funkzeit beim Übertragen von Daten (schließlich muss der RT nicht geweckt werden).
Solltest du dann einmal doch den Burst nutzen wollen, kannst du das ganz einfach, indem du nach zB Eingabe deiner Templiste ein 'set <HM-Device> burstXmit' nach schickst. Dadurch wird der RT sofort aufgeweckt und die Queue abgearbeitet. ;-)
Danke das werde ich mal ausprobieren!
Ich bin eben nur etwas verwundert das nach einigen Minuten dann irgend wann ein:
STATE MISSING ACK
protResndFail 1 last_at:2013-11-18 13:08:41
protSnd 105 last_at:2013-11-18 13:08:40
protState CMDs_done_Errors:1
zu sehen ist. Also wenn es nur verzögert ist, habe ich damit absolut kein Problem, ist ja alles unkritisch aber es schlägt ja dennoch fehl.
Aber trotzdem vielen Dank, ich probiere das mit dem Burst Modus mal aus, aber wenn das auch nichts hilft lebe ich erst mal damit. Solange andere die Problem nicht haben macht das kein Sinn da jetzt Zeit zu investieren, da gehe ich erst mal davon aus das ich hier irgend was falsch mache bzw. Murphy zu Besuch ist.
Gruß
Daniel
Zitat von: ext23 am 18 November 2013, 13:14:06Solange andere die Problem nicht haben macht das kein Sinn da jetzt Zeit zu investieren, da gehe ich erst mal davon aus das ich hier irgend was falsch mache bzw. Murphy zu Besuch ist.
So ganz alleine bist du nicht damit. Verwende aus eben dem selben Grund auch immer '1_auto' bei den Attributen. ;-)
Wenn ich Martin richtig verstanden habe, gibt es wohl ein Timingproblem zwischen dem Aufwecken und Antworten ohne Burst.
Ich lasse es bei mir eingeschalten, da ich:
a) seither keine Probleme mehr habe,
b) mein HMLAN bislang nicht einmal ansatzweise soviel Traffic produziert, dass ich mit der 1%-Grenze in Konflikt geraten könnte und
c) ich meinen Spaß daran habe, dass die Kommandos sofort übermittelt werden. ;-)
Gut bei mir sieht es ähnlich aus ;-) Jetzt scheint es auch zu laufen.
Aber wenn Martin das aufm Schirm hat ist das ja ok, dann brauch ich da auch nicht weiter nerven.
Gruß
Daniel
Zitat von: ext23 am 18 November 2013, 13:49:55Gut bei mir sieht es ähnlich aus ;-) Jetzt scheint es auch zu laufen.
Freut mich... Aber nicht vergessen, abhängig von der Anzahl deiner HM-Devices auch den HMLAN im Auge behalten, damit du nicht doch einmal in ein Overload läufst. ;-)
Zitat von: ext23 am 18 November 2013, 13:49:55Aber wenn Martin das aufm Schirm hat ist das ja ok, dann brauch ich da auch nicht weiter nerven.
Im Moment ist zwar etwas Ruhe eingekehrt, aber im Grunde bin ich mit Martin an der Sache dran. ;-)
kleine Anmerkung:
protResnd ist eine Wiederholung, keine Problem, ein Hinweis
ResndFail ist ein Problem. Die Resends habe nicht geholfen. Da sollte man schon hinsehen.
Was für ein Problem es ist hängt von der Message ab, die nicht erfolgreich gesendet wurde. Es kann eine status.abfrage gewesen ein (kein Problem) oder ein regSet, ein schalten,... Eine Auswertung, was schief gegangen ist gibt es (noch) nicht. Auf msg-ebene wäre es einfach, es anzuzeigen - aber der Otto-Normal-User will/braucht sicher eine high-level Aufbereitung. Das gibt es noch nicht.
Wichtiger ist natürlich, es erst garnich tso weit kommen zu lassen.
Gruss Martin
Hallo Philipp,
ich habe auch versucht den Code in die 99_utils.pm und den Aufruf in die fhem.cfg zu nehmen.
Beim speichern der fhem.cfg bekomme ich folgendes angezeigt:
Unknown argument tempListSun, choose one of clear getConfig getRegRaw mode peerBulk regBulk regSet sign statusRequest
Hast du das auch gehabt?
Gruß
Wolfgang
Zitat von: Kruemel am 18 November 2013, 21:17:39Unknown argument tempListSun, choose one of clear getConfig getRegRaw mode peerBulk regBulk regSet sign statusRequest
Ohne jetzt genau zu wissen, was du gemacht hast, würde ich einmal behaupten, du hast beim Zugriff zumindest einen falschen Channel aber wahrscheinlich irrtümlich sogar ein ganz falsches Device, auf das du die Werte schreiben möchtest. ;-)
Kannst du mir mal ein 'list <dein-HM-Device>' hierher pasten und anschließend noch den Befehl, den du absetzt?
Thx a lot!
Hallo,
ich habe einen HM-CC-RT-DN bei fhem angelernt.
Dann wollte ich eine Kommandozeile aus diesem Thread ausprobieren um dem Ventil Solltemperaturen zu schicken.
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr tempListMon exec 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0
Ich frage mich wo tempListMon definiert ist. Im Listing des devices/channels ist es nicht dabei.
Gruß
Wolfgang
------------------------------------------------------------------
Internals:
DEF 22337804
NAME CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr
NR 415
STATE ???
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_CC_RT_DN_223378
Readings:
2013-11-18 23:39:09 R-boostAftWinOpen off
2013-11-18 23:39:09 R-boostPeriod 5
2013-11-18 23:39:09 R-boostPos 80 %
2013-11-18 23:39:09 R-btnNoBckLight off
2013-11-18 23:39:09 R-daylightSaveTime on
2013-11-18 23:39:09 R-decalcTime 666.666666666667
2013-11-18 23:39:09 R-decalcWeekday Sat
2013-11-18 23:39:09 R-modePrioManu all
2013-11-18 23:39:09 R-modePrioParty all
2013-11-18 23:39:09 R-noMinMan4Manu off
2013-11-18 23:39:09 R-regAdaptive on
2013-11-18 23:39:09 R-reguExtI 15
2013-11-18 23:39:09 R-reguExtP 30
2013-11-18 23:39:09 R-reguExtPstart 30
2013-11-18 23:39:09 R-reguIntI 18
2013-11-18 23:39:09 R-reguIntP 33
2013-11-18 23:39:09 R-reguIntPstart 45
2013-11-18 23:39:09 R-showInfo time
2013-11-18 23:39:09 R-showWeekday off
2013-11-18 23:39:09 R-tempComfort 21
2013-11-18 23:39:09 R-tempFallWinOpen 12
2013-11-18 23:39:09 R-tempFallWinPerio 15 min
2013-11-18 23:39:09 R-tempLowering 17
2013-11-18 23:39:09 R-tempMax 30.5
2013-11-18 23:39:09 R-tempMin 4.5
2013-11-18 23:39:09 R-tempOffset 0.0K
2013-11-18 23:39:09 R-valveErrPos 15 %
2013-11-18 23:39:09 R-valveMaxPos 100 %
2013-11-18 23:39:09 R-valveOffset 0 %
Helper:
Role:
chn 1
Shadowreg:
Attributes:
expert
model HM-CC-RT-DN
peerIDs
room CUL_HM
---------------------------------------------
define CUL_HM_HM_CC_RT_DN_223378 CUL_HM 223378
attr CUL_HM_HM_CC_RT_DN_223378 .devInfo 00FFFF
attr CUL_HM_HM_CC_RT_DN_223378 .stc 59
attr CUL_HM_HM_CC_RT_DN_223378 firmware 1.0
attr CUL_HM_HM_CC_RT_DN_223378 model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_223378 room CUL_HM
attr CUL_HM_HM_CC_RT_DN_223378 serialNr KEQ0517369
attr CUL_HM_HM_CC_RT_DN_223378 subType thermostat
define FileLog_CUL_HM_HM_CC_RT_DN_223378 FileLog ./log/CUL_HM_HM_CC_RT_DN_223378-%Y.log CUL_HM_HM_CC_RT_DN_223378
attr FileLog_CUL_HM_HM_CC_RT_DN_223378 logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_223378 room CUL_HM
define CUL_HM_HM_CC_RT_DN_223378_Weather CUL_HM 22337801
attr CUL_HM_HM_CC_RT_DN_223378_Weather model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_223378_Weather peerIDs
attr CUL_HM_HM_CC_RT_DN_223378_Weather room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_223378_Weather FileLog ./log/CUL_HM_HM_CC_RT_DN_223378_Weather-%Y.log CUL_HM_HM_CC_RT_DN_223378_Weather
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_Weather logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_Weather room CUL_HM
define CUL_HM_HM_CC_RT_DN_223378_Climate CUL_HM 22337802
attr CUL_HM_HM_CC_RT_DN_223378_Climate model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_223378_Climate room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_223378_Climate FileLog ./log/CUL_HM_HM_CC_RT_DN_223378_Climate-%Y.log CUL_HM_HM_CC_RT_DN_223378_Climate
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_Climate logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_Climate room CUL_HM
define CUL_HM_HM_CC_RT_DN_223378_WindowRec CUL_HM 22337803
attr CUL_HM_HM_CC_RT_DN_223378_WindowRec model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_223378_WindowRec room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_223378_WindowRec FileLog ./log/CUL_HM_HM_CC_RT_DN_223378_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_223378_WindowRec
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_WindowRec logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_WindowRec room CUL_HM
define CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr CUL_HM 22337804
attr CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr FileLog ./log/CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr room CUL_HM
define CUL_HM_HM_CC_RT_DN_223378_ClimRT_r CUL_HM 22337805
attr CUL_HM_HM_CC_RT_DN_223378_ClimRT_r model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_223378_ClimRT_r room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_223378_ClimRT_r FileLog ./log/CUL_HM_HM_CC_RT_DN_223378_ClimRT_r-%Y.log CUL_HM_HM_CC_RT_DN_223378_ClimRT_r
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_ClimRT_r logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_ClimRT_r room CUL_HM
define CUL_HM_HM_CC_RT_DN_223378_rCtrl CUL_HM 22337806
attr CUL_HM_HM_CC_RT_DN_223378_rCtrl model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_223378_rCtrl room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_223378_rCtrl FileLog ./log/CUL_HM_HM_CC_RT_DN_223378_rCtrl-%Y.log CUL_HM_HM_CC_RT_DN_223378_rCtrl
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_rCtrl logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_223378_rCtrl room CUL_HM
Zitat von: Kruemel am 18 November 2013, 23:07:01Ich frage mich wo tempListMon definiert ist. Im Listing des devices/channels ist es nicht dabei.
Naja... das ist so nicht ganz richtig... denn für gewöhnlich stehen diese Werte sehr wohl genau dort. ;-)
Daher würde ich dir empfehlen, einmal die folgenden zwei Befehle abzusetzen.
attr CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr expert 1_on
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr getConfigWenn der RT dann das nächste Mal aufwacht, sollten sich dann die Readings alle neu füllen.
Beobachte dabei auch bitte deine decalcTime. Die dürfte mWn nur als Uhrzeit dort angezeigt werden.
Andernfalls den Wert einfach einmal überschreiben:
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr regSet decalcTime 11:00Bin schon gespannt auf deine Rückmeldung. :-)
Huhu Krümel,
richtiges device und richtiger channel ... mach mal nochmal, direkt danach mach ein burstXmit und dann ein getconfig (und ggf. noch ein BurstXmit), also:
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr tempListMon 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr burstXmit
Das exec kannst du bei nur einem set der Templisten weglassen. Das BurstXmit weckt den Thermosten, sonst wird es erst in 1-2 Minuten zu einer sichtbaren Reaktion kommen, falls du das AutoBurstdingens nicht an hast. Dann kurz warten und gucken was passiert - im STATE sollte sowas wie CMDs Processing und dann CMDs Done stehen, dann:
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr getConfig
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr burstXmit
Wieder kurz warteb, nun sollte in den Reading sowas hier auftauchen:
tempListMon 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0
Hallo,
habe jetzt erfolgreich den HM-CC-RT-DN mit einem Tür/Fensterkontakt gepeert.
set <thermoSensor> peerChan 0 <rt_WindowRec> single set
Dabei habe ich mit an den Wiki-Eintrag von hier gehalten:
http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Channel_.28Kanal.29_03_WindowRec (http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Channel_.28Kanal.29_03_WindowRec)
Danach habe ich den Temperaturwert für "winOpnTemp" von 12 auf 5 geändert.
Das steht jetzt auch so richtig in den Readings vom Channel 3 (WindowRec).
Leider scheint das den Thermostaten nicht zu interessieren, denn der behält beharrlich die 12 C.
Was mache ich denn falsch?
Gruß
Thomas
Zitat von: Papaloewe am 19 November 2013, 18:25:51Leider scheint das den Thermostaten nicht zu interessieren, denn der behält beharrlich die 12 C.
Ja, ist mir auch schon aufgefallen - allerdings noch keine Zeit, dem weiter nachzugehen. Weiß nicht, ob es sich dabei nicht um ein Firmwareproblem vom RT handelt. :-/
wird aktuell als FW problem gesehen. Ich habe die Register (XML) geprüft und das setzen - konnte kein Problem finden.
Entweder stimmt das XML nicht (dann wird es in einer späteren Version von EQ3 korrigiert) oder es ist ein FW bug.
Wenn es wiederum ein FW bug ist, kann man es evtl auch in anderen Foren finden - und eQ3 könnte/wird eine neue FW ausgeben.
Mal sehen - vielleicht findet jemand etwas
Hallo zusammen,
kurze Frage zum Thema: "winOpnTemp" aber auch generell zum RT.
Habt ihr auch alle die FW Version 1.0? und hat jemand schon eine neuere?
Viele Grüße
Arthur
[
richtiges device und richtiger channel ... mach mal nochmal, direkt danach mach ein burstXmit und dann ein getconfig (und ggf. noch ein BurstXmit), also:
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr tempListMon 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr burstXmit
tempListMon 05:30 19.0 07:00 22.0 18:00 19.0 20:30 21.0 24:00 19.0
[/quote]
Hallo peterk_de,
danke für dein FeedBack. Aber bei diesen beiden Befehlen wird jeweils "unknown tempListMon" oder "unknown burstXmit" gemeldet.
Gruß
Wolfgang
Zitat von: Mr. P am 19 November 2013, 00:02:12
Naja... das ist so nicht ganz richtig... denn für gewöhnlich stehen diese Werte sehr wohl genau dort. ;-)
Daher würde ich dir empfehlen, einmal die folgenden zwei Befehle abzusetzen.
attr CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr expert 1_on
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr getConfig
Wenn der RT dann das nächste Mal aufwacht, sollten sich dann die Readings alle neu füllen.
Beobachte dabei auch bitte deine decalcTime. Die dürfte mWn nur als Uhrzeit dort angezeigt werden.
Andernfalls den Wert einfach einmal überschreiben:
set CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr regSet decalcTime 11:00
Bin schon gespannt auf deine Rückmeldung. :-)
Hallo Mr.P.,
hat leider nicht geklappt. TempListMon wird immer noch nicht angezeigt.
An der Gesamtsituation hat sich leider nichts verändert.
Gruß
Wolfgang
Zitat von: Kruemel am 19 November 2013, 23:54:56hat leider nicht geklappt. TempListMon wird immer noch nicht angezeigt.
An der Gesamtsituation hat sich leider nichts verändert.
Zeig doch mal bitte, welche Versionen du von den zuständigen Versionen auf deinem System hast.
version HMLAN
version CUL_HM
Zitat von: martinp876 am 19 November 2013, 19:17:17Mal sehen - vielleicht findet jemand etwas
Gesagt, getan. ;-)
http://www.elv.de/topic/fenster-auf-temperatur-wirkt-nicht.html (http://www.elv.de/topic/fenster-auf-temperatur-wirkt-nicht.html)
Kannst du damit etwas anfangen?
Ja, wenn ich jetzt noch wüsste, wie man die Absenktemperatur beim peeren mit übergibt?
Zitat...Wie wird Deine Fensteröffnung erkannt?
- Wenn sie über den Thermostat mittels Abfall der Temp ermittelt wird, sollte die 5 Grad in den Einstellungen des Thermostats wirken.
- Wenn sie über Fensterkontakte ermittelt wird, musst Du die Absenktemp in der Direktverknüpfung einstellen.....
Zitat von: Papaloewe am 20 November 2013, 08:15:50
Ja, wenn ich jetzt noch wüsste, wie man die Absenktemperatur beim peeren mit übergibt?
War eigentlich mehr auf Martin gemünzt.
Ich glaube, da ist noch etwas Entwicklungsarbeit notwendig.
ja, kann ich etwas mit anfangen - muss ich aber testen.
das scheint ja ein saustall bei dem RT zu sein.....
Melde mich
Zitat von: martinp876 am 20 November 2013, 10:46:23das scheint ja ein saustall bei dem RT zu sein.....
Ich bin gespannt, ob eq-3 ein wenig lernt und das bei den kommenden Updates auch einfließen lässt. :-)
Jetzt hab ich gerade etwas Neues entdeckt.
Für normal würde ich meinen, es sind Übertragungsfehler. Aber diese kamen nur ein paar Mal und dann auch noch hintereinander.
Hab es leider auch erst heute bemerkt und das waren die einzigen Male, dass die Readings aufgetaucht sind.
2013-11-14_21:45:46 heating_bedroom_ClimRT_tr unknown1: 00C0018
2013-11-14_21:47:52 heating_bedroom_ClimRT_tr unknown1: 00C0018
2013-11-14_21:50:47 heating_bedroom_ClimRT_tr unknown1: 00C0018
2013-11-14_21:53:28 heating_bedroom_ClimRT_tr unknown1: 10C0018
2013-11-14_21:55:55 heating_bedroom_ClimRT_tr unknown1: 10C0018
2013-11-14_21:58:07 heating_bedroom_ClimRT_tr unknown1: 10C0018
2013-11-14_22:01:08 heating_bedroom_ClimRT_tr unknown1: 10C0018
2013-11-14_22:03:55 heating_bedroom_ClimRT_tr unknown1: 10C0018
2013-11-14_22:06:28 heating_bedroom_ClimRT_tr unknown1: 10C0018
2013-11-14_22:08:46 heating_bedroom_ClimRT_tr unknown1: 00C0018
Any ideas? Anyone? :-)
Hallo, nachdem ich jetzt dachte, es würde gut funktionieren, ist mir ein neues Problem aufgefallen:
Ich nutze nur die interen Fenster-auf-Erkennung und habe die Absenktemperatur auf 5°C eingestellt. Als ich gestern Abend sicherheitshalber vom Dienst aus meine Regler abgefragt habe, war ich nicht schlecht erstaunt, dass im Wohnzimmer ALLE 4 Regler auf 5°C eingestellt waren. Es war niemand in der Wohnung. Es ist also offensichtlich beim Lüften die Temperatur auf 5°C eingestellt worden, aber danach nicht wieder zurück. Diese Steuerung läuft nicht über FHEM, das muss also ein internes Problem des RT-DN sein. Elegent wäre natürlich, diese Regelung ganz zu deaktivieren (geht das?) und das Ganze über ein Notify in FHEM zu realisieren.
Wie könnte so etwas aussehen?
Wenn Fenster auf, merke die aktuelle Temperatur, stelle für 15 Minuten auf 5°C, setze danach wieder die vorige Temperatur ein.
Viele Grüße
Markus
Hej Markus,
also ich habe die interne Regelung vom RT probiert und die hat anstandslos funktioniert.
Runter auf 7° und nach 15 Minuten wieder rauf auf die ursprüngliche Temperatur.
Die Regelung kannst du im RT schon deaktivieren und theoretisch auch mit einem Notify über FHEM lösen. Aber bedenke die Verzögerungen, die dadurch entstehen, bis der RT den Temperaturabfall erkennt und dann noch alle Übertragungen abgeschlossen sind.
Versuche es doch nochmal unter deiner Beobachtung. Schau dir auch den Register ClimRT_tr vom RT noch genau an. Dort ist ersichtlich (und kann auch eingestellt werden) wie lange die Temperatur unten bleiben soll. Vielleicht ist dort irgendwo der Hund begraben.
Hallo Mr. P,
ein Register ClimRT_tr habe ich bei mir nicht, bei mir sieht das so aus:
R-winOpnBoost
off
2013-11-05 20:31:25
R-winOpnDetFall
1.4 K
2013-10-21 11:06:00
R-winOpnMode
on
2013-11-05 20:31:25
R-winOpnPeriod
15 min
2013-10-21 11:06:00
R-winOpnTemp
5 C
2013-10-21 11:46:46
Das sollte doch 5°C für 15 min realisieren, oder irre ich mich da?
Viele Grüße
Markus
PS: Dasselbe Problem habe ich vor ein paar Wochen schon mal beobachtet, da waren aber nur einige Heizkörper auf 5°C eingestellt, gestern waren es alle 4 (es sind alle miteinander gepeert)
Das ist schon der ClimRT_tr-Register. Wirst du vermutlich nur umbenannt haben. ;-)
Aber du hast schon recht, sieht alles recht ordentlich aus. Was ich natürlich nicht weiß, ist das zusätzliche Detail, das du gerade verraten hast. Das alle RTs miteinander gepeert sind. Vielleicht liegt da das Problem.
Hast du die Geräte direkt untereinander gepeert oder es über FHEM realisiert?
SCNR ;)
Zitat von: Mr. P am 20 November 2013, 15:35:17Das ist schon der ClimRT_tr-Register. Wirst du vermutlich nur umbenannt haben. ;-)
Nix umbenannt... du hast aus einem
Channel ein "Register" gemacht :o
Gruß und nix für ungut.
Thomas
*hust*
Ja, das könnte auch der Grund sein. Danke fürs korrigieren. :-)
Gesendet von meinem GT-I9100 mit Tapatalk
Hi,
ein paar updates...
winOpenTemp kann man ab morgen (version 4255) selektiv für jeden gepeerten SC einstellen. Das geht in WindowRec. Das setting ist zu sehen, wenn man gepeert hat, klar.
Die interne Fenster-auf Erkennung kann man in "clima" channel einstellen, gleicher name, kein peer. Angezeigt wird sie der volständighei halber auch in windowRec. Ich habe den Namen auf winOpnTemp-int geändert - hoffe das macht es klarer - was meint ihr?
die interne fernster-auf erkennung kann man abschalten - siehe regList (immer ein guter tip, sollte man optionen durchgehen)
7: winOpnMode | literal | | enable internal Windoe open in modes: options:on,auto,auto_party,auto_manu,off
ich habe es bei mir abgeschaltet - da derSonnen/schatten Umschlag an einem Fühler regelmässig "Fenster-auf" signalisiert hat. Sollte man SCs nutzen, ist eine Abschaltung sowieso ratsam (meine Meinung)
habe ich etwas vergessen/Überlesen?
Gruss Martin
Zitat von: Mr. P am 20 November 2013, 15:35:17
Das ist schon der ClimRT_tr-Register. Wirst du vermutlich nur umbenannt haben. ;-)
Aber du hast schon recht, sieht alles recht ordentlich aus. Was ich natürlich nicht weiß, ist das zusätzliche Detail, das du gerade verraten hast. Das alle RTs miteinander gepeert sind. Vielleicht liegt da das Problem.
Hast du die Geräte direkt untereinander gepeert oder es über FHEM realisiert?
Ich habe die Geräte alle (jedes mit jedem) untereiander gepeert, mit FHEM fiunktionierte das nicht so ganz (siehe irgendwo in diesem Megathread). Denke auch, das da irgendwo das Problem liegt (beispielsweise: 1 RT erkennt "Fenster auf", schaltet auf 5°C, meldet dies den Peers und diese senden eventuell die 5°C als desired Temp an alle Peers zurück. So wäre so ungefähr mein Erklärungsversuch.
Kann man die RTs eigentlich nachträglich auslesen, d.h. bekommt man raus, wann diese Temperatur gesetzt wurde und ob dabei WinOpen erkannt wurde? Das Ganze lief ja nicht FHEM, deshalb ist das Log da ja auch leer...
Viele Grüße
Markus
Hallo Markus,
lies mal 1 Post über deinem. Martin(p876) hat da Änderungen vorgenommen, die bei normalem Update ab Morgen genutzt werden können und dein Problem evtl. lösen helfen ;)
Gruß
Thomas
Edit: Nickname korrigiert und ein "n" gekauft
Die aktuellen temp eines RT kann nicht gelesen werden, wird aber regelmässig vom RT freiwillig gemeldet. Der unterschied ist, dass es in FHEM zeitverzögert eingetraben wird.
der RT (wie der TC) melden NICHT wenn sie im Fenster-offen-mode sind. Wird ein externen SC genutzt und sind die peer-listen komplett wird FHEM einen entsprechenden Eintrag in die Readings machen, dass ein Trigger dieses Sensors gekommen ist. Mehr ist nicht möglich (meines Wissens)
Gruss Martin
Hallo Martin,
Anmerkungen / offene (Verständnis-)Fragen zum Thema "winOpnTemp":
- Fehler beim schreiben: "cannot calculate value. Please issue set <rt_WindowRec> getConfig first - invalid". Ein "getConfig" - auf beiden Seiten (RHS bereits gpeert - vor dem Update) als auch RT brachte kein Erfolg. Was mache ich falsch?
- wie kommst du auf "tempWinOpen" wenn das Resgister "winOpnTemp" heißt? ;o) (Sowohl init als auch bei peer) - ok meine Idee, 1st (Verständliche-Schreibweise) 2nd (Technische-Schreibweise) - will sagen -> irritierend ;o).
- Verständnisfrage:
- Sensor 1 (Terrasse) geppert mit RT1
- Sensor 2 (kleines Fenster) geppert mit RT1
"winOpnTemp" kann nicht separat definiert werden richtig?
Hier das Motto: Fenster auf dann alles auf peer "winOpnTemp" SC/RHCs egal welches(wieviele) peer(s) - RICHTIG? Falls Antwort = "ja" dann verstehe ich dises "peer"-winOpnTemp Konstrukt nicht.
- winOpnTemp-int wenn dies die interne "Fenster 'auf'" Erkennung ist was hat das mit dem WindowRec zu tun - will sagen -> weg lassen und in "clima" lassen - so gibt es eine klare Zuordnung. Oder? Was war deine Idee?
Viele Grüße
Arthur
EDIT: command 'set <rt_WindowRec> regSet winOpnTemp 10'
Zitat von: Mr. P am 20 November 2013, 00:08:46
Zeig doch mal bitte, welche Versionen du von den zuständigen Versionen auf deinem System hast.
version HMLAN
version CUL_HM
Hallo, hier meine Versionen
# $Id: 00_HMLAN.pm 4232 2013-11-16 14:00:26Z martinp876 $
# $Id: 10_CUL_HM.pm 4232 2013-11-16 14:00:26Z martinp876 $
Gruß
Wolfgang
Zitat von: Kruemel am 18 November 2013, 23:07:01ich habe einen HM-CC-RT-DN bei fhem angelernt.
Und du bist dir sicher, dass FHEM deinen RT nicht nur erkannt und die Channels per Autocreate erstellt hat, sondern du ihn auch wirklich gepairt hast?
Also am Display des RT erscheint das Antennensymbol und auch in FHEM steht er als mit FHEM gepairt?
Postest du bitte mal den Output von:
list CUL_HM_HM_CC_RT_DN_223378Thx a lot!
Zitat von: Mr. P am 21 November 2013, 23:59:31
Und du bist dir sicher, dass FHEM deinen RT nicht nur erkannt und die Channels per Autocreate erstellt hat, sondern du ihn auch wirklich gepairt hast?
Also am Display des RT erscheint das Antennensymbol und auch in FHEM steht er als mit FHEM gepairt?
Postest du bitte mal den Output von:
list CUL_HM_HM_CC_RT_DN_223378
Thx a lot!
Hallo Mr.P.,
erstmal Danke für die schnellen Antworten.
Hier das Listing.
Zeigt diese Zeile das Pairing an?
2013-11-19 23:45:57 R-pairCentral 0x123ABC
Das MissingACK irritiert mich etwas, es war nicht immer da.
Es gibt doch auch eine Firmware im Thermostaten? Wie zeigt man sich diese Version an? Wie macht man hier ein Update?
Ich habe im Thread gelesen das Martin eine neue Version rausgegeben hat. Habe überlegt diese upzudaten, mich aber entschieden zu warten, bis du dich wieder gemeldet hast.
Vielen Dank.
Gruß
Wolfgang
Internals:
DEF 223378
EVENTS 2099
HMLAN1_MSGCNT 2118
HMLAN1_RAWMSG E223378,0000,6E1490DD,FF,FFA7,2086102233780000000A9CE410002B
HMLAN1_RSSI -89
HMLAN1_TIME 2013-11-22 07:51:40
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 2118
NAME CUL_HM_HM_CC_RT_DN_223378
NR 407
STATE MISSING ACK
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_RT_DN_223378_Weather
channel_02 CUL_HM_HM_CC_RT_DN_223378_Climate
channel_03 CUL_HM_HM_CC_RT_DN_223378_WindowRec
channel_04 CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr
channel_05 CUL_HM_HM_CC_RT_DN_223378_ClimRT_r
channel_06 CUL_HM_HM_CC_RT_DN_223378_rCtrl
lastMsg No:20 - t:10 s:223378 d:000000 0A9CE410002B
protCmdDel 14
protLastRcv 2013-11-22 07:51:40
protNack 1 last_at:2013-11-19 22:04:15
protResnd 27 last_at:2013-11-19 23:46:13
protResndFail 10 last_at:2013-11-19 23:46:17
protSnd 223 last_at:2013-11-19 23:46:05
protState CMDs_done_events:9
rssi_at_HMLAN1 avg:-77.94 min:-102 max:-72 lst:-89 cnt:2118
Readings:
2013-11-19 23:45:56 CommandAccepted yes
2013-11-19 23:45:57 PairedTo 0x123ABC
2013-11-19 23:45:57 R-backOnTime 10 s
2013-11-19 23:45:57 R-btnLock unlock
2013-11-19 23:45:57 R-burstRx off
2013-11-19 23:45:57 R-cyclicInfoMsg on
2013-11-19 23:45:57 R-cyclicInfoMsgDis 0
2013-11-19 23:45:57 R-globalBtnLock off
2013-11-19 23:45:57 R-intKeyVisib invisib
2013-11-19 23:45:57 R-localResDis off
2013-11-19 23:45:57 R-lowBatLimitRT 2.1 V
2013-11-19 23:45:57 R-modusBtnLock off
2013-11-19 23:45:57 R-pairCentral 0x123ABC
2013-11-19 23:45:57 RegL_00: 01:00 02:01 09:01 0A:12 0B:3A 0C:BC 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2013-11-22 07:51:40 noReceiver src:223378 8610 0A9CE410002B
2013-11-19 23:46:17 state MISSING ACK
Helper:
burstEvtCnt 9
mId 0095
rxType 12
Respwait:
Role:
dev 1
Rssi:
At_hmlan1:
avg -77.948536355052
cnt 2118
lst -89
max -72
min -102
Shadowreg:
Attributes:
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room CUL_HM
serialNr KEQ0517369
subType thermostat
Hallo Wolfgang,
sieht nach einem korrekt durchgeführten Pairing aus. Aber deine RSSI-Werte von bis zu -102 erscheinen mir doch sehr niedrig. Vlt. führt das zu den Kommunikationsstörungen? Und deine Firmwareversion im RT ist 1.0 (steht auch da ;) ). Update kann nur von eQ-3/ELV durchgeführt werden (so es eine neue gibt?). Dafür musst du den RT dann einschicken.
Gruß
Thomas
Zitat von: Rohan am 22 November 2013, 08:04:50sieht nach einem korrekt durchgeführten Pairing aus. Aber deine RSSI-Werte von bis zu -102 erscheinen mir doch sehr niedrig. Vlt. führt das zu den Kommunikationsstörungen? Und deine Firmwareversion im RT ist 1.0 (steht auch da ;) ). Update kann nur von eQ-3/ELV durchgeführt werden (so es eine neue gibt?). Dafür musst du den RT dann einschicken.
Hej ihr beiden,
also bezüglich Firmwareversion und RSSI-Werte kann ich Rohan nur recht geben. Firmwareversion steht in den Attributen und RSSI ist wirklich schwach. Versuche doch einmal zum Testen den Thermostat und den Sender ein wenig näher aneinander zu bringen, dass du Werte von max. -80 (besser -70) zusammen bekommst.
Nur was die Sache mit dem Firmwareupdate anbelangt, glaube ich, dass Rohan daneben liegt. Wenn ich das jetzt nicht falsch im Hinterkopf habe, Ist der RT doch die erste Komponente, die der User selbst updaten können sollte (bitte korrigiert, aber steinigt mich nicht, wenn ich mich irre). Aber so oder so, von einer neueren Version als der 1.0 ist mir bislang nichts bekannt. :-)
Interessieren würden mich auch die Rohdaten, die du bei der Kommunikation bekommst. Da wären Verbindungsabbrüche auch recht gut erkennbar. Wäre toll, wenn du uns diese noch zur Verfügung stellen könntest.
Kleine Anmerkung noch am Rande: In den neuesten Versionen funktioniert das Logging jetzt etwas anders - bitte beachten, solltest du bereits eine solche Version haben. :-)
Edit: Hier noch der Link zu den neuen Logparametern:
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848 (http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848)
Hi,
Zitat von: Mr. P am 22 November 2013, 08:19:01... Nur was die Sache mit dem Firmwareupdate anbelangt, glaube ich, dass Rohan daneben liegt. Wenn ich das jetzt nicht falsch im Hinterkopf habe, Ist der RT doch die erste Komponente, die der User selbst updaten können sollte (bitte korrigiert, aber steinigt mich nicht, wenn ich mich irre). ...
Gerade mal Manual gelesen ;) Dort steht in der Beschreibung der Status-/Fehlermeldungen:
CRC - CRC-Fehler nachFirmwareupdate - Firmwareupdate erneut durchführen
FUP - Firmwareupdate wird durchgeführt - /
Sieht also so aus, wie du es geschrieben hast 8)
Gruß
Thomas
Hallo Arthur
Zitat- Fehler beim schreiben: "cannot calculate value. Please issue set <rt_WindowRec> getConfig first - invalid".
Ein
set rt_WindowRec getConfig
oder
set rt getConfig
sollte das Problem lösen.
Natürlich musst du das Kommando absetzen UND ausführen. Also mittels burst (so enabled) oder warte, bis der RT aufgewacht ist, und es abgeholt hat.
Du solltest dann sehen, dass
- im rt keine Kommandos "pending" sind
- im rt_WindowRec die peers zu sehen sind.
ein getConfig auf den RHS ist nicht notwendig.
Zitat- wie kommst du auf "tempWinOpen" wenn das Resgister "winOpnTemp" heißt? ;o) (Sowohl init als auch bei peer) - ok meine Idee, 1st (Verständliche-Schreibweise) 2nd (Technische-Schreibweise) - will sagen -> irritierend ;o).
tempWinOpen ist es beim TC, winOpnTemp beim RT. Habe ich es irgendwo vertauscht? Wo?
Zitat- Verständnisfrage:
- Sensor 1 (Terrasse) geppert mit RT1
- Sensor 2 (kleines Fenster) geppert mit RT1
"winOpnTemp" kann nicht separat definiert werden richtig?
ja, kannst du.
ZitatFenster auf dann alles auf peer "winOpnTemp" SC/RHCs egal welches(wieviele) peer(s) - RICHTIG?
falschZitat- winOpnTemp-int wenn dies die interne "Fenster 'auf'" Erkennung ist was hat das mit dem WindowRec zu tun - will sagen -> weg lassen und in "clima" lassen - so gibt es eine klare Zuordnung.
das Register winOpnTemp-int ist in "Clima". Daher auch kein "R-" prefix.
Der Gedanke ist, dass im WindowRec die daten des Fenster-offen sichtbar sind. Das betrifft alle 5 "interneFenster register".
Zumindest sollte man sehen, und es einem Auffallen, dass ein interner Fenster-erkenner AUCH aktiv ist, oder eben nicht. Die Daten gehören dann dazu.
Die Idee ist, Daten eines Themas in einem Kontext darzustellen.
ZitatEDIT: command 'set <rt_WindowRec> regSet winOpnTemp 10'
wo ist den dein peer? regSet für peer-related-register ist
set <rt_WindowRec> regSet winOpnTemp 10
<peer>die SW kann den peer "" auch nach getConfig nicht finden ;-)
Interessant wird es übrigens, wenn du 4 Fenster hast, alle mit verschiedenen Temperaturen, und diese dann abwechselnd auf und zu machst. Ob der RT das sauber abarbeitet?
Achtung: ich habe gerade einen Bug bei burstXmit (hoffentlich) behoben V4258
Gruss Martin
Zitat von: martinp876 am 22 November 2013, 09:57:51... tempWinOpen ist es beim TC, winOpnTemp beim RT. Habe ich es irgendwo vertauscht? Wo? ...
Stand auch im Wiki so (falscher Registername
und fehlender Peer) verkehrt drin. Ist korrigiert.
Gruß
Thomas
Hallo Martin,
ZitatEin
set rt_WindowRec getConfig
oder
set rt getConfig
sollte das Problem lösen.
Natürlich musst du das Kommando absetzen UND ausführen. Also mittels burst (so enabled) oder warte, bis der RT aufgewacht ist, und es abgeholt hat.
Du solltest dann sehen, dass
- im rt keine Kommandos "pending" sind
- im rt_WindowRec die peers zu sehen sind.
ein getConfig auf den RHS ist nicht notwendig.
- getConfig auf Device inkl. pendings abgearbeitet -> sollte damit sauber sein. Die peers sehe ich auch -> ich habe offensichtlich (noch nciht getestet) einen Fehler beim regSet gemacht - ich versuche später mal wie von dir vorgeschlagen mit
set <rt_WindowRec> regSet winOpnTemp 10 <peer>Zitatdas Register winOpnTemp-int ist in "Clima". Daher auch kein "R-" prefix.
Der Gedanke ist, dass im WindowRec die daten des Fenster-offen sichtbar sind. Das betrifft alle 5 "interneFenster register".
Zumindest sollte man sehen, und es einem Auffallen, dass ein interner Fenster-erkenner AUCH aktiv ist, oder eben nicht. Die Daten gehören dann dazu.
Die Idee ist, Daten eines Themas in einem Kontext darzustellen.
Hmmm ja ok verstanden.
Zitatwo ist den dein peer? regSet für peer-related-register ist
set <rt_WindowRec> regSet winOpnTemp 10 <peer>
die SW kann den peer "" auch nach getConfig nicht finden ;-)
Ja das wird wohl der (mein) Fehler sein -> Test folgt.
Zitat
Interessant wird es übrigens, wenn du 4 Fenster hast, alle mit verschiedenen Temperaturen, und diese dann abwechselnd auf und zu machst. Ob der RT das sauber abarbeitet?
Ja, darauf will ich hinaus - Tests (zwar nur mit zwei Fenstersensoren) folgen.
ZitatAchtung: ich habe gerade einen Bug bei burstXmit (hoffentlich) behoben V4258
Danke für den Hinweis.
Danke und Viele Grüße
Arthur
Hallo Thomas,
danke für die Anpassung.
In der ersten Fassung hatte ich das hier eingetragen:
set <tc_WindowRec> regSet tempWinOpen 23 <SensorFensterLinks>
und war offensichtlich auch korrekt ;o)
Anmerkung/Vorschlag für den Wiki Eintrag:
set <tc_WindowRec> regSet tempWinOpen 10 <SensorFenster>
?
Viele Grüße
Arthur
Hallo Arthur,
Zitat von: snoop am 22 November 2013, 10:45:36... Anmerkung/Vorschlag für den Wiki Eintrag:
set <tc_WindowRec> regSet tempWinOpen 10 <SensorFenster>
? ...
Jetzt bin ich etwas verwirrt.
Laut Martin (martinp876) soll es heißen beim HM-CC-RT-DN:
set <rt_WindowRec> regSet winOpnTemp 10 <peer>Wir sollten beim HM-CC-RT-DN nicht von "
tc_WindowRec" schreiben und beim HM-CC-RT-DN heißt das Register wohl "winOpnTemp", wohingegen es beim HM-CC-TC "tempWinOpen" lautet.
Oder liege ich da jetzt komplett daneben?
Gruß
Thomas
Hallo Thomas,
absolut korrekt danke und damit:
set <rt_WindowRec> regSet winOpnTemp 10 <SensorFenster>
Sorry für die Verwirrung.
Viele Grüße
Arthur
lässt sich die Fensteroffenerkennung irgendwie deaktivieren? Sollte das winOpnMode Register sein, oder? Aber das lässt sich leider nicht setzen.
Hmmm....
Gegenfrage ;) : Warum willst / möchtest du das?
Gruß
Thomas
Zitat von: Rohan am 22 November 2013, 11:19:01Gegenfrage ;) : Warum willst / möchtest du das?
Ich hab auf externe Sensoren umgestellt, weil die Internen:
a) nur bei jenen Heizkörpern gut funktioniert haben, wo der RT direkt unter dem Fenster ist und
b) er setzt die Temperatur für eine bestimmte Zeit herab und danach wieder hinauf. Die Wahrscheinlichkeit, dass er zB nach 15 Minuten nochmals ein 'Fenster offen' erkennt und wieder abdreht, ist auch recht gering.
Beides ist bei mir leider schon vorgekommen. :-/
Hallo Mr. P,
Zitat von: Mr. P am 22 November 2013, 12:12:06Ich hab auf externe Sensoren umgestellt, weil ...
Edith ergänzt noch: Die Frage von HardwareW ist auch eine andere 8)
Hmmm... Jetzt kenne ich
deine Gründe, aber
dich habe ich ja auch
nicht gefragt ;)
Vlt. hat der Fragesteller ja eine (gänzlich) andere Bedarfslage?
Gruß
Thomas
Zitat von: Rohan am 22 November 2013, 12:18:12Hmmm... Jetzt kenne ich deine Gründe, aber dich habe ich ja auch nicht gefragt ;)
Vlt. hat der Fragesteller ja eine (gänzlich) andere Bedarfslage?
Ich weiß, ich hab mich hinein geschummelt und wollte auch nicht für jemand anders antworten. Fand es einfach gerade passend, auch meine Beweggründe zur Umstellung von den internen auf externe Sensoren hier zu vermelden. Könnte ja mal jemanden von nutzen sein. ;-)
Zitat von: martinp876 am 22 November 2013, 09:57:51Achtung: ich habe gerade einen Bug bei burstXmit (hoffentlich) behoben V4258
Und scheint auch die Übertragung mit 'burstAccess 1_auto' betroffen zu haben... denn auch das funktioniert jetzt wieder. :-)
Hallo zusammen,
kurze Frage zu den RSSI Werten beim RT.
Im HMinfo rssi sehe ich beim RT nur einen RSSI Wert, nämlich Empfang der Zentrale (CUL) vom Thermostat. Bei allen anderen HM Aktoren sehe ich die Werte in beiden Richtungen.
Der RT ist bei meinem Output in der letzten Zeile:
rssi done:
Device :receive from last avg min<max count
az_podFS1010 :CUL_HM az_podFS1010 -65.0 -59.6 -66.0< -53.5 6
az_podFS1010 :az_podFS1010 CUL_HM -72.0 -64.5 -72.0< -58.0 4
ke_Pumpe :CUL_HM ke_Pumpe -78.0 -78.5 -79.0< -78.0 3
ke_Pumpe :ke_Pumpe CUL_HM -75.0 -74.3 -75.0< -73.0 3
ke_Switch4 :CUL_HM ke_Switch4 -77.0 -77.2 -78.0< -76.5 10
ke_Switch4 :ke_Switch4 CUL_HM -79.0 -79.3 -80.0< -79.0 4
wz_Markise :CUL_HM wz_Markise -73.0 -74.7 -75.5< -73.0 6
wz_Markise :wz_Markise CUL_HM -77.0 -77.0 -77.0< -77.0 1
wz_Thermostat :CUL_HM wz_Thermostat -65.0 -62.1 -75.5< -58.0 381
Ist das nur bei mir so?
Tobi
Zitat von: Rohan am 22 November 2013, 11:19:01
Hmmm....
Gegenfrage ;) : Warum willst / möchtest du das?
Gruß
Thomas
Ich stelle die Sollwerte über ein anderes System ein, das auch in der Lage sein wird ein offenes Fenster zu erkennen.
Generell kann ich mein Problem umgehen, aber hätte mich dennoch interessiert.
@tobi,
die auswertung der RSSI werte ist "generisch" - also für alle Devices identisch. Werte des HMLAN werden von diesem gemeldet, also mit jeder empfangenen Message. Das device meldet den Empfangspegel auch, aber nicht in jeder message. Kann man auch an den Zählerständen ablesen, wie viele messages ausgewertet würden.
Das RT hat bis dato also keine entsprechende message gesendet. Ich glaube jetzt einmal, dass es den level in keiner message unterstützt...
@Thomas
set <rt_clima> winOpnMode off
funktioniert bei mit.
Im "windowRec" channel ist dies nicht eingebaut - da steht auch nicht R-winOpnMode.
Ich halte es auch für sinnvoll den internen winopen auszuschalten, sollte ein externer genutzt werden. Es kommt in jedem Fall zu Überlagerungen - und früher oder später zu Problemen.
@Mr. P.
ja, alle aufweck-jobs....
Gruss Martin
nur mal so nebenbei: der RT regelt ziemlich exakt: Die +/- 0,1° um die Solltemperatur sind sehr ordentlich.
(http://up.picr.de/16544073jm.png)
grün = Ist-Temp, rot = Soll-Temp, violett = Ventilöffnung
Hallo Martin, Hallo zusammen,
ich möchte zum Thema "winOpnTemp" kurz berichten.
1) Zunächst der Befehl lautet:
set <rt_WindowRec> regSet winOpnTemp 10 <FensterSensor>
Ein Config/Anlerntaste auf Seiten des SC/RHS (beide getestet) ist nicht notwendig (eigentlich klar da die Register des RT's bearbeitet werden).
2) Zum Thema "winOpnTemp" Test mit mehreren Fenster Sensoren:
- Testkonfiguration/Umfeld:
1 x RT (gepairt)
1 x SC (mit RT gepeert) "winOpnTemp" 10
1 X RHS (mit RT gepeert) "winOpnTemp" 18
- Test 1:
- RT Modus Manuell
- Soll Temeratur 24°C
- Aktion: SC "auf"
- Fenster auf wird angezeigt "neue Soll Temp" = 10°C
- Aktoin: RHS "auf"
- "Soll Temp" = (unverändert) 10°C
- Test 2:
- RT Modus Manuell
- Soll Temeratur 24°C
- Aktion: RHS "auf"
- Fenster auf wird angezeigt "neue Soll Temp" = 18°C
- Aktoin: SC "auf"
- "Soll Temp" wird auf 10°C
- Test 3: (mMn der interessanteste zumindest vom verhalten)
- RT Modus Manuell
- Soll Temeratur 24°C
- Aktion: RHS "auf"
- Fenster auf wird angezeigt "neue Soll Temp" = 18°C
- Aktoin: SC "auf"
- "Soll Temp" wird auf 10°C gestellt
- Aktoin: SC "zu"
- "Soll Temp" "bleibt" auf 10°C
- Aktoin: RHS "zu"
- "Soll Temp" wird auf 24°C gestellt
Fazit: Eine Konfiguration mit mehreren Sensoren wird grds. unterstützt. Der Sensor mit dem niedrigsten"winOpnTemp" Wert gewinnt. Bisher keine Langzeittests und Erfahrungen.
Dies zur Info.
Viele Grüße
Arthur
Zitat von: Rohan am 22 November 2013, 08:04:50
Hallo Wolfgang,
sieht nach einem korrekt durchgeführten Pairing aus. Aber deine RSSI-Werte von bis zu -102 erscheinen mir doch sehr niedrig. Vlt. führt das zu den Kommunikationsstörungen? Und deine Firmwareversion im RT ist 1.0 (steht auch da ;) ). Update kann nur von eQ-3/ELV durchgeführt werden (so es eine neue gibt?). Dafür musst du den RT dann einschicken.
Gruß
Thomas
Hallo Thomas,
danke für die Hilfe. LAN-CFG steht jetzt näher am RT. Hier ein neues Listing. Die Werte sind jetzt besser. Funktionen konnte ich noch nicht prüfen.
Mach ich dann wahrscheinlich heute Abend.
Internals:
DEF 223378
EVENTS 33
HMLAN1_MSGCNT 256
HMLAN1_RAWMSG E223378,0000,02281E15,FF,FFD3,6986102233780000000AA8E210162B
HMLAN1_RSSI -45
HMLAN1_TIME 2013-11-23 08:32:51
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 256
NAME CUL_HM_HM_CC_RT_DN_223378
NR 407
STATE CMDs_done
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_RT_DN_223378_Weather
channel_02 CUL_HM_HM_CC_RT_DN_223378_Climate
channel_03 CUL_HM_HM_CC_RT_DN_223378_WindowRec
channel_04 CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr
channel_05 CUL_HM_HM_CC_RT_DN_223378_ClimRT_r
channel_06 CUL_HM_HM_CC_RT_DN_223378_rCtrl
lastMsg No:69 - t:10 s:223378 d:000000 0AA8E210162B
protLastRcv 2013-11-23 08:32:51
protSnd 33 last_at:2013-11-23 07:59:11
protState CMDs_done
rssi_at_HMLAN1 avg:-45 min:-47 max:-43 lst:-45 cnt:256
Readings:
2013-11-22 23:18:52 Activity alive
2013-11-22 23:23:28 CommandAccepted yes
2013-11-22 23:23:29 PairedTo 0x123ABC
2013-11-19 23:45:57 R-backOnTime 10 s
2013-11-22 23:23:29 R-btnLock unlock
2013-11-22 23:23:29 R-burstRx off
2013-11-22 23:23:29 R-cyclicInfoMsg on
2013-11-22 23:23:29 R-cyclicInfoMsgDis 0
2013-11-22 23:23:29 R-globalBtnLock off
2013-11-22 22:53:14 R-intKeyVisib invisib
2013-11-22 23:23:29 R-localResDis off
2013-11-19 23:45:57 R-lowBatLimitRT 2.1 V
2013-11-22 23:23:29 R-modusBtnLock off
2013-11-22 23:23:29 R-pairCentral 0x123ABC
2013-11-22 23:23:29 RegL_00: 01:00 02:01 09:01 0A:12 0B:3A 0C:BC 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2013-11-23 08:32:51 actuator 22 %
2013-11-23 08:32:51 battery ok
2013-11-23 08:32:51 batteryLevel 3.1 V
2013-11-23 08:32:51 desired-temp 21
2013-11-23 08:32:51 measured-temp 22.6
2013-11-22 23:15:57 noReceiver src:223378 8610 0A88C310002B
2013-11-23 07:59:11 state CMDs_done
2013-11-23 07:59:11 time-request -
Helper:
mId 0095
rxType 12
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -45.0078125
cnt 256
lst -45
max -43
min -47
Shadowreg:
Attributes:
actCycle 020:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room CUL_HM
serialNr KEQ0517369
subType thermostat
webCmd getConfig:burstXmit
Zitat von: Kruemel am 23 November 2013, 08:37:58
2013-11-23 07:59:11 state CMDs_done
Der state-Wert sieht jetzt auf alle Fälle schon mal besser aus. Vielleicht klappts jetzt dann auch mit dem Nachbarn. :-)
Ich habe noch ein Problem mit meinen Thermostaten ::)
Ich möchte den Offset der Thermostate per FHEM einstellen. Nun hat das bei einem Thermostat mit
set <Thermostat> regSet tempOffset <Offset>
hervorragend funktioniert. Bei einem anderen kommt ständig ich solle vorher
set <Thermostat> getConfig
ausführen. Leider hilft das nicht.
Auffallend ist das auf der Seite des Thermostats bei dem es funktioniert in der Sektion wesentlich mehr aufgeführt ist (z.B. auch der Offset).
Nun meine Fragen:
1. Warum ist das getConfig notwendig?
2. Warum liefert getConfig bei manchen Thermostaten kein Ergebnis oder vielleicht werden auch nur ein Bruchteil der Register ausgelesen?
Vielen Dank für eure Hilfe :)
Hallo HardwareW,
Zitat von: HardwareW am 23 November 2013, 20:20:36... Bei einem anderen kommt ständig ich solle vorher
set <Thermostat> getConfig
ausführen. Leider hilft das nicht.
Auffallend ist das auf der Seite des Thermostats bei dem es funktioniert in der Sektion wesentlich mehr aufgeführt ist (z.B. auch der Offset).
Dann liegt ein Fehler in der Kommunikation zwischen Fhem/HMLAN und dem Thermostaten vor.
Steht dort (also auf der Device-Seite)
protCmdPend 3 CMDs_pending
sind die Befehle noch nicht abgearbeitet.
Steht dann irgendwann ein "Missing ACK" oder "NACK", dann hast du ein Problem in der Kommunikation.
Zitat
Nun meine Fragen:
1. Warum ist das getConfig notwendig?
Um alle Readings/Register-Inhalte des (hier) Thermostaten in Fhem einlesen zu können. Nur Parameter, deren Inhalte bekannt sind, werden angezeigt.
Edith möchte ergänzen: Und nur Parameter, deren Inhalt bekannt sind (bezogen auf das jeweilige Device), können geändert werden.
Zitat
2. Warum liefert getConfig bei manchen Thermostaten kein Ergebnis oder vielleicht werden auch nur ein Bruchteil der Register ausgelesen?
Siehe oben... Kommunikationsprobleme, nicht richtig gepairt ...
Gruß
Thomas
Danke Rohan für die ausführliche Antwort.
Komisch ist, dass ich bei getConfig ganz normal CMD Pending und und danach CMD done bekomme ohne irgendwelche Fehler.
Setzen von Temperaturen geht auch ohne Probleme.
Ich benutze übrigens einen Raspberry Pi + COC
Hi HardwareW
Zitat von: HardwareW am 23 November 2013, 21:59:25... Komisch ist, dass ich bei getConfig ganz normal CMD Pending und und danach CMD done bekomme ohne irgendwelche Fehler.
Setzen von Temperaturen geht auch ohne Probleme.
Das alles bei dem "nicht richtig funktionierenden" Thermostaten?
Mach doch bitte einmal ein
list <devicename> von dem funktionierenden und dem nicht funktionierenden Thermostat und
poste es hier mit dem entsprechenden Hinweis (bitte zwischen "code"-Klammern => siehe "#"-Zeichen im Editier-Fenster).
Edit: Oben "setze" gegen '
poste' ausgetauscht.
Zitat
Ich benutze übrigens einen Raspberry Pi + COC
Hmmm ... mM kein Grund, vor allem, wenn es mit dem einen Thermostaten klappt und mit dem anderen nicht.
Gruß
Thomas
Gruß
Thomas
Hallo Thomas,
Hier das nicht funktionierende Thermostat:
Internals:
COC_MSGCNT 767
COC_RAWMSG A0FC1861021BA4F0000000A80A0100D5820
COC_RSSI -58
COC_TIME 2013-11-23 22:53:06
DEF 21BA4F04
EVENTS 767
LASTInputDev COC
MSGCNT 767
NAME CUL_HM_HM_CC_RT_DN_21BA4F_ClimRT_tr
NR 84
STATE T: 16.0 desired: 16 valve: 13 %
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_CC_RT_DN_21BA4F
Attributes:
autoReadReg 3_onChange
expert 2_full
model HM-CC-RT-DN
peerIDs
room CUL_HM
Readings:
2013-11-23 22:53:06 ValvePosition 13 %
2013-11-23 22:53:06 desired-temp 16
2013-11-23 22:53:06 measured-temp 16.0
2013-11-23 22:53:06 mode manu
2013-11-23 22:53:06 motorErr ok
2013-11-23 22:53:06 state T: 16.0 desired: 16 valve: 13 %
2013-11-23 22:53:06 unknown0 24
Helper:
getCfgListNo
Prt:
wakeup 1
Role:
chn 1
Attributes:
autoReadReg 3_onChange
expert 2_full
model HM-CC-RT-DN
peerIDs
room CUL_HM
und hier das funktionierende Thermostat:
Internals:
COC_MSGCNT 765
COC_RAWMSG A0FF5861021BA4C0000000A80A0100E6A27
COC_RSSI -54.5
COC_TIME 2013-11-23 22:53:34
DEF 21BA4C04
EVENTS 765
LASTInputDev COC
MSGCNT 765
NAME CUL_HM_HM_CC_RT_DN_21BA4C_ClimRT_tr
NR 56
STATE T: 16.0 desired: 16 valve: 14 %
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_CC_RT_DN_21BA4C
Attributes:
autoReadReg 3_onChange
expert 2_full
model HM-CC-RT-DN
peerIDs
room CUL_HM
Readings:
2013-11-21 17:19:50 R-boostPeriod 5 min
2013-11-21 17:19:50 R-boostPos 80 %
2013-11-21 17:19:50 R-btnNoBckLight off
2013-11-21 17:19:50 R-dayTemp 21 C
2013-11-21 17:19:50 R-daylightSaveTime on
2013-11-21 17:19:50 R-decalcTime 11:00
2013-11-21 17:19:50 R-decalcWeekday Sat
2013-11-21 17:19:50 R-modePrioManu all
2013-11-21 17:19:50 R-modePrioParty all
2013-11-21 17:19:50 R-nightTemp 17 C
2013-11-21 17:19:50 R-noMinMax4Manu off
2013-11-21 17:19:50 R-regAdaptive on
2013-11-21 17:19:50 R-reguExtI 15
2013-11-21 17:19:50 R-reguExtP 30
2013-11-21 17:19:50 R-reguExtPstart 30
2013-11-21 17:19:50 R-reguIntI 15
2013-11-21 17:19:50 R-reguIntP 30
2013-11-21 17:19:50 R-reguIntPstart 30
2013-11-21 17:19:50 R-showInfo time
2013-11-21 17:19:50 R-showWeekday off
2013-11-21 17:19:46 R-sign off
2013-11-21 17:19:50 R-tempMax 30.5 C
2013-11-21 17:19:50 R-tempMin 4.5 C
2013-11-21 17:19:50 R-tempOffset 0.0K
2013-11-21 17:19:50 R-valveErrPos 15 %
2013-11-21 17:19:50 R-valveMaxPos 100 %
2013-11-21 17:19:50 R-valveOffset 0 %
2013-11-21 17:19:50 R-winOpnBoost off
2013-11-21 17:19:50 R-winOpnDetFall 1.4 K
2013-11-21 17:19:50 R-winOpnMode on
2013-11-21 17:19:50 R-winOpnPeriod 15 min
2013-11-21 17:19:50 R-winOpnTemp 12 C
2013-11-23 22:53:34 ValvePosition 14 %
2013-11-23 22:53:34 desired-temp 16
2013-11-23 22:53:34 measured-temp 16.0
2013-11-23 22:53:34 mode manu
2013-11-23 22:53:34 motorErr ok
2013-11-23 22:53:34 state T: 16.0 desired: 16 valve: 14 %
2013-11-21 17:19:50 tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-21 17:19:50 tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-21 17:19:50 tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
2013-11-21 17:19:50 tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
2013-11-21 17:19:50 tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-21 17:19:50 tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-21 17:19:50 tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2013-11-21 17:19:50 tempList_State verified
2013-11-23 22:53:34 unknown0 42
Helper:
getCfgListNo
Prt:
wakeup 1
Role:
chn 1
Attributes:
autoReadReg 3_onChange
expert 2_full
model HM-CC-RT-DN
peerIDs
room CUL_HM
Hallo HardwareW,
Zitat von: HardwareW am 23 November 2013, 22:59:07... Hier das nicht funktionierende Thermostat: ...
Sorry, aber ich sehe da (aus meiner beschränkten Sichtweise) auf Anhieb keine Probleme / Anhaltspunkte.
Vlt. kann ja ein anderer Mitleser etwas damit anfangen.
Ich lese weiter mit (bin ja auch noch Anfänger).
Gruß
Thomas
Zitat von: Rohan am 23 November 2013, 23:11:35
Sorry, aber ich sehe da (aus meiner beschränkten Sichtweise) auf Anhieb keine Probleme / Anhaltspunkte.
Trotzdem vielen Dank dir, Thomas.
Hoffe, dass noch jemand eine Idee hat :)
Zitat von: Mr. P am 23 November 2013, 08:46:59
Der state-Wert sieht jetzt auf alle Fälle schon mal besser aus. Vielleicht klappts jetzt dann auch mit dem Nachbarn. :-)
Hallo,
jetzt klappts auch mit dem Nachbarn ;-)
Ich kann jetzt schon mal dem Thermostaten eine Liste von Sollwerten geben, er nimmt sie an und stellt die Temp ein.
2013-11-24 08:57:07 tempListSun 08:00 14.0 09:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
Ist es richtig dass diese Liste beschreibt, bis 8.00 ist 14 Grad, von 8.00-9.30 Uhr ist 19.0 Grad eingestellt?
So schein es jedenfalls bei mir zu sein.
Eine Frage habe ich noch zu den Reaktionszeiten.
Ich stelle die Werte über 99_myUtils.pm ein.
In der fhem.cfg rufe ich die Sub mit der Zeile
{SetTempList_EG_Kueche_Heizung()}
auf.
Wenn ich die Liste ändern will, ändere ich die Sub und starte fhem.cfg neu.
Dann dauert es immer etwas, bis ich die Änderungen auch im fhem angezeigt bekommen.
Gibt es hier einen besseren Weg?
Vielen Dank.
Gruß
Wolfgang
------------------------------------------
sub SetTempList_EG_Kueche_Heizung()
# das Paar aus Zeit und Solltemp. bedeutet immer, das bis zu der Zeit diese
# Temperatur gilt
{
{ fhem ("set HZ01_EG_Kueche_ClimRT_tr tempListMon prep 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0")};
{ fhem ("set HZ01_EG_Kueche_ClimRT_tr tempListTue prep 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0")};
{ fhem ("set HZ01_EG_Kueche_ClimRT_tr tempListWed prep 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0")};
{ fhem ("set HZ01_EG_Kueche_ClimRT_tr tempListThu prep 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0")};
{ fhem ("set HZ01_EG_Kueche_ClimRT_tr tempListFri prep 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0")};
{ fhem ("set HZ01_EG_Kueche_ClimRT_tr tempListSat prep 08:00 14.0 09:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0")};
{ fhem ("set HZ01_EG_Kueche_ClimRT_tr tempListSun exec 08:00 14.0 09:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0")};
}
# End SetTempList_UG_Treppe_Heizung
Internals:
DEF 22337804
EVENTS 4
NAME HZ01_EG_Kueche_ClimRT_tr
NR 415
STATE T: 22.2 desired: 19 valve: 0 %
TYPE CUL_HM
chanNo 04
device HZ01_EG_Kueche
Readings:
2013-11-23 22:53:46 R-boostPeriod 5 min
2013-11-23 22:53:46 R-boostPos 80 %
2013-11-24 08:57:07 R-btnNoBckLight off
2013-11-23 22:53:46 R-dayTemp 21 C
2013-11-24 08:57:07 R-daylightSaveTime on
2013-11-24 08:57:07 R-decalcTime 11:00
2013-11-24 08:57:07 R-decalcWeekday Sat
2013-11-24 08:57:07 R-modePrioManu all
2013-11-24 08:57:07 R-modePrioParty all
2013-11-23 22:53:46 R-nightTemp 17 C
2013-11-24 08:57:07 R-noMinMax4Manu off
2013-11-24 08:57:07 R-regAdaptive on
2013-11-24 08:57:07 R-reguExtI 15
2013-11-24 08:57:07 R-reguExtP 30
2013-11-24 08:57:07 R-reguExtPstart 30
2013-11-24 08:57:07 R-reguIntI 18
2013-11-24 08:57:07 R-reguIntP 33
2013-11-24 08:57:07 R-reguIntPstart 45
2013-11-24 08:57:07 R-showInfo time
2013-11-24 08:57:07 R-showWeekday off
2013-11-24 08:57:03 R-sign off
2013-11-23 22:53:46 R-tempMax 30.5 C
2013-11-23 22:53:46 R-tempMin 4.5 C
2013-11-24 08:57:07 R-tempOffset 0.0K
2013-11-23 22:53:46 R-valveErrPos 15 %
2013-11-23 22:53:46 R-valveMaxPos 100 %
2013-11-23 22:53:46 R-valveOffset 0 %
2013-11-24 08:57:07 R-winOpnBoost off
2013-11-23 22:53:46 R-winOpnDetFall 1.4 K
2013-11-24 08:57:07 R-winOpnMode on
2013-11-23 22:53:46 R-winOpnPeriod 15 min
2013-11-23 22:53:46 R-winOpnTemp 12 C
2013-11-24 09:02:47 ValvePosition 0 %
2013-11-24 09:02:47 desired-temp 19
2013-11-24 09:02:47 measured-temp 22.2
2013-11-24 09:02:47 mode auto
2013-11-24 09:02:47 motorErr ok
2013-11-24 09:02:47 state T: 22.2 desired: 19 valve: 0 %
2013-11-24 08:57:07 tempListFri 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
2013-11-24 08:57:07 tempListMon 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
2013-11-24 08:57:07 tempListSat 08:00 14.0 09:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
2013-11-24 08:57:07 tempListSun 08:00 14.0 09:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
2013-11-24 08:57:07 tempListThu 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
2013-11-24 08:57:07 tempListTue 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
2013-11-24 08:57:07 tempListWed 05:30 14.0 08:30 19.0 18:00 16.0 19:00 19.0 20:00 16.0 24:00 14.0
2013-11-24 08:57:07 tempList_State verified
2013-11-24 09:02:47 unknown0 14
Templist:
Fri:
0:
HOUR 05
MINUTE 30
TEMP 14.0
1:
HOUR 08
MINUTE 30
TEMP 19.0
2:
HOUR 18
MINUTE 00
TEMP 16.0
3:
HOUR 19
MINUTE 00
TEMP 19.0
4:
HOUR 20
MINUTE 00
TEMP 16.0
5:
HOUR 24
MINUTE 00
TEMP 14.0
Mon:
0:
HOUR 05
MINUTE 30
TEMP 14.0
1:
HOUR 08
MINUTE 30
TEMP 19.0
2:
HOUR 18
MINUTE 00
TEMP 16.0
3:
HOUR 19
MINUTE 00
TEMP 19.0
4:
HOUR 20
MINUTE 00
TEMP 16.0
5:
HOUR 24
MINUTE 00
TEMP 14.0
Sat:
0:
HOUR 08
MINUTE 00
TEMP 14.0
1:
HOUR 09
MINUTE 30
TEMP 19.0
2:
HOUR 18
MINUTE 00
TEMP 16.0
3:
HOUR 19
MINUTE 00
TEMP 19.0
4:
HOUR 20
MINUTE 00
TEMP 16.0
5:
HOUR 24
MINUTE 00
TEMP 14.0
Sun:
0:
HOUR 08
MINUTE 00
TEMP 14.0
1:
HOUR 09
MINUTE 30
TEMP 19.0
2:
HOUR 18
MINUTE 00
TEMP 16.0
3:
HOUR 19
MINUTE 00
TEMP 19.0
4:
HOUR 20
MINUTE 00
TEMP 16.0
5:
HOUR 24
MINUTE 00
TEMP 14.0
Thu:
0:
HOUR 05
MINUTE 30
TEMP 14.0
1:
HOUR 08
MINUTE 30
TEMP 19.0
2:
HOUR 18
MINUTE 00
TEMP 16.0
3:
HOUR 19
MINUTE 00
TEMP 19.0
4:
HOUR 20
MINUTE 00
TEMP 16.0
5:
HOUR 24
MINUTE 00
TEMP 14.0
Tue:
0:
HOUR 05
MINUTE 30
TEMP 14.0
1:
HOUR 08
MINUTE 30
TEMP 19.0
2:
HOUR 18
MINUTE 00
TEMP 16.0
3:
HOUR 19
MINUTE 00
TEMP 19.0
4:
HOUR 20
MINUTE 00
TEMP 16.0
5:
HOUR 24
MINUTE 00
TEMP 14.0
Wed:
0:
HOUR 05
MINUTE 30
TEMP 14.0
1:
HOUR 08
MINUTE 30
TEMP 19.0
2:
HOUR 18
MINUTE 00
TEMP 16.0
3:
HOUR 19
MINUTE 00
TEMP 19.0
4:
HOUR 20
MINUTE 00
TEMP 16.0
5:
HOUR 24
MINUTE 00
TEMP 14.0
Helper:
Role:
chn 1
Shadowreg:
Attributes:
expert 1
model HM-CC-RT-DN
peerIDs
room EG-Kueche
Hallo Wolfgang,
die Zeit ist immer der End-zeitpunkt, stimmt also.
wenn du mehrere Tage setzen willst solltest du "prep" und "exec" im Kommando nutzen, siehe commandref.
zum neu laden deines util kannst du
reload 99_myUtil
machen. FHEM bleibt bestehen und muss nicht alles neu aufsetzen. Alle internen Variablen bleiben erhalten.
Gruss Martin
Hallo Martin,
seit Update auf die Version
# $Id: 10_CUL_HM.pm 4257 2013-11-21 18:17:30Z martinp876 $
listet der HMinfo configCheck folgende Meldungen - bin mir sehr sicher, dass sie vorher nicht da waren.
configCheck done:
missing register list
wz_Thermostat: RegL_00:
wz_Thermostat_ClimRT_tr: .RegL_01:,.RegL_07:
wz_Thermostat_ClimaTeam: .RegL_01:
wz_Thermostat_Climate: .RegL_01:
wz_Thermostat_Weather: .RegL_01:
wz_Thermostat_WindowRec: .RegL_01:
wz_Thermostat_remote: .RegL_01:
incomplete register list
peer list not read
peer list incomplete
peer not verified
Weiter oben im Thread hast Du geschrieben:
bei solchen Fehlern sollte man
a) das device clearen : clear readings
b) neu lesen: getConfig
Hat nichts geändert. Mein RT ist nur mit der FHEM-Zentrale gepaired - es gibt keine peers.
Da eigentlich alles funktioniert - gibt's da Handlungsbedarf oder einfach ignorieren?
Gruss
Tobi
Hallo Tobi,
deinem RT wz_Thermostat fehlen alle Register. Diese sind nicht gelesen.
Es könnte auch am sichtbarschalten liegen (attr expert). Hier muss ich die Readings umbenennen von ".RegL_00" nach "RegL_00" oder umgekehrt.
Nimm ein Beispiel: wz_Thermostat_remote. Wenn du "list" machst - wo steht "expert" und kannst du RegL_01 sehen?
wenn du expert einmal nach 2 und dann nach 0 schaltest - hintereinander. Ist dann das Problem verschwuden?
hast du expert im Config-file geändert oder gelöscht? Also nicht im web-interface oder konsole?
und - hast du nach dem getConfig gewartet, bis das Kommando auch abgearbeitet war?
Gruss Martin
Hallo Martin,
Zitat von: martinp876 am 24 November 2013, 14:20:35
deinem RT wz_Thermostat fehlen alle Register. Diese sind nicht gelesen.
Es könnte auch am sichtbarschalten liegen (attr expert). Hier muss ich die Readings umbenennen von ".RegL_00" nach "RegL_00" oder umgekehrt.
Nimm ein Beispiel: wz_Thermostat_remote. Wenn du "list" machst - wo steht "expert" und kannst du RegL_01 sehen?
Nein - RegL_01 fehlt:
list wz_Thermostat_remote
Internals:
DEF 21F22006
NAME wz_Thermostat_remote
NR 87
STATE ???
TYPE CUL_HM
chanNo 06
device wz_Thermostat
Readings:
Helper:
getCfgList all
getCfgListNo ,3
Role:
chn 1
Attributes:
expert 1
model HM-CC-RT-DN
peerIDs 00000000,
room hiddenZitat
wenn du expert einmal nach 2 und dann nach 0 schaltest - hintereinander. Ist dann das Problem verschwuden?
Leider nein.
Zitat
hast du expert im Config-file geändert oder gelöscht? Also nicht im web-interface oder konsole?
Vorher garnicht. Für den Test mit 2 und dann 0 über das Web-Interface.
Zitat
und - hast du nach dem getConfig gewartet, bis das Kommando auch abgearbeitet war?
Ja. Ich arbeite ohne Burst-Modus - also immer brav gewartet, bis das Kommando von pending in cmd_done wechselt.
Auch wenn ich derzeit keine Probleme habe, hätte ich ja schon gerne einen sauberen Konfigcheck. Wie bringe denn FHEM dazu, die Register einzulesen bzw. sie wieder sichtbar zu machen?
Danke & Gruss
Tobi
expert steht in deinem Beispiel auf "1" - da sieht man alle dekodierten Register - aber keine rohdaten.
Stelle einmal auf "2".
ZitatAuch wenn ich derzeit keine Probleme habe, hätte ich ja schon gerne einen sauberen Konfigcheck. Wie bringe denn FHEM dazu, die Register einzulesen bzw. sie wieder sichtbar zu machen?
Lesen der Config mit "getConfig". Dann sind alle register und peers gelesen. Wenn nicht hat es evtl. ein Problem bei der Übertragung gegeben. hast du protokol-fehler gelendet bekommen?
Sichtbar machen:
expert = 0: eine Auswahl dekodierter Register ist sichtbar
expert = 1: alle dekodierten Register sichtbar
expert = 2: alle dekodierten Register sichtbar und rohdaten
expert ist hierarchisch. Wenn du es im device setzt gilt es für alle channels. Wenn du es im Channel setzt wird ein möglicher wert aus dem Device überschrieben.
Alternativ gibt es das global attribut "showInternalValues". Wenn das auf "1" werden alle Unsichtbaren Variables sichtbar geschaltet. Expert ist dann nicht (nicht wirklich) relevant.
getConfig funktioniert (wie das meiste in CUL_HM) hierarchisch. Du kannst einen Channel lesen oder das gesamte device incl channels.
ein fehlerfreies "checkConfig" strebe ich auch an ;-). Sollte (muss) erreichbar sein.
Gruss Martin
Hallo Martin,
vielen Dank für die Erklärungen. Das ganze Experimentieren mit expert und get_config hat allerdings zunächst nichts gebracht. Protokollfehler habe ich keine gesehen.
Vielleicht lag es tatsächlich an der Version 4257 von 10_CUL_HM.pm. Mit dieser Version waren mir die fehlenden Register beim configCheck erstmalig aufgefallen. Oder ein anderer temporärer Dreckeffekt...
Nach einem Update auf die derzeit aktuelle Version
# $Id: 10_CUL_HM.pm 4276 2013-11-23 16:56:20Z martinp876 $
und Neustart des FHEM-Servers gefolgt von einem weiteren get_config ist wieder alles sauber. Der configCheck meckert nichts an und ich sehe die Register im Frontend und via list.
In jedem Fall habe ich wieder ein paar HM-Details (Hierarchie, Bedeutung von Attribut expert) gelernt.
Nochmals besten Dank & Gruss
Tobi
Hallo,
ist es möglich, R-nightTemp und R-tempLowering zu ändern? Ab Werk sind diese ja auf 17°C gesetzt. Irgendwie steige ich da nicht hinter. Was genau ist überhaupt der Unterschied zwischen diesen beiden Werten?
schöne Grüße
Jo
Hallo Jo,
loweringTemp gibt es doch garnicht mehr. Steht das noch irgendwo? Die beiden sind identisch.
regSet ist das Kommando zum Ändern
set <clima> regSet nightTemp 20
Gruss Martin
Hallo Martin,
super, vielen Dank! Da stand ich wohl auf dem Schlauch.
Das reading R-tempLowering ist bei mir auch schon älter (Oktober). Wie lösche ich denn diese alten Einträge?
schöne Grüße
Jo
set <name> clear readings
Danke betateilchen! Jetzt sind alle gelöscht. Kann ich sie auch wieder anzeigen lassen? :-\
schöne Grüße
Jo
set <Name> getConfig
Gesendet von meinem GT-I9100 mit Tapatalk
Zitat von: Mr. P am 27 November 2013, 17:48:27
set <Name> getConfig
Gesendet von meinem GT-I9100 mit Tapatalk
Danke!
schöne Grüße
Jo
Nochmal was zur adaptiven Regelung in Verbindung mit einem externen Temp. Sensor: Ja, die Regelparameter des Thermostaten ändern sich auch wenn ein Thermometer gepeert ist! Aber ganz abstrus. Nach ca. 3 Wochen mit gepeertem Sensor (vorher ca. 4 Wochen ohne) sehen sie in meinem kleinen Bad nun so aus:
R-reguExtI 15
R-reguExtP 30
R-reguExtPstart 30
R-reguIntI 18
R-reguIntP 33
R-reguIntPstart 250
Krasse Änderung beim IntPStart - so weit haben sich die Parameter vorher ohne externem Sensor nicht geändert. Und die Regelung ist dadurch jetzt ... Schrecklich schlecht! Er dreht den Heizkörper bei leichter Unterschreitung der Solltemperatur sofort komplett auf und Heizt den Raum deutlich zu stark - logisch - P-Anteil des PIs halt ... Jetzt werd ich die Adaptive Regelung abschalten müssen. Das geht so gar nicht...
und du hast einen externen Thermostat gepeert? Die Internen werte werden geändert?
Verstehe ich nicht. Hätte ich so nicht erwartet (abgesehen von den schlechten Einstellungen)
pStart ist wohl der Stellwert des Ventils beim start der Regelung - 250 ist dann "max"
Ja, genau so ist es, da hab ich einen HM-WDS40-TH-I mit gepeert, dessen Werte auch übernommen werden (Temperaturreading des RT-DN entspricht dem des TH-Sensors).
Es ist aber nur bei diesem einen Thermostaten so. Bei den anderen beiden, die ich mit dem Gleichen Temp-Sensor gepeert habe, änderten sich die Int-Werte ein bisschen, die Ext-Werte blieben gleich. Das Int/Ext scheint sich also nicht auf externes Thermometer oder internes Thermometer zu beziehen. Leider habe ich aber auch keinen Raum wo ich, ohne meine bessere Hälfte zum Auszug zu treiben, einmal extreme Parameter gut testen könnte ...
Seitdem ich die Adaptive regelung abgeschaltet habe läuft er ansonsten übrigens wieder super ... naja.
Hallo zusammen,
ich habe mein fhem auf mein debian wheezy mit folgendem paket installiert: fhem-5.5.deb.
Da ich nun auch einen thermostat gekauft habe, wollte ich diesen auch gleich in fhem nutzen. Somit habe ich fhem über die update-funktion mit folgenden vier Modulen versorgt: 00_HMLAN.pm, 10_CUL_HM.pm, 98_HMinfo.pm und HMConfig.pm. Ich nutze als Hardware ein HMLAN-Modul. Nach den Updates habe ich fhem beendet und neugestartet. Dann habe ich über set HMLAN1 hmPairForSec 60 den HM-CC-RT-DN gepairt. Auch dies lief ohne Probleme und ich kann den Thermostaten wie erwartet steuern.
Ich habe zuzätzlich noch drei HM-PB-2-WM55 welche nach dem Wiki-Eintrag (http://www.fhemwiki.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster) mit Virtuellen Actoren eingerichtet wurden. Diese Schalter haben mir immer als Bestätigung eine grüne LED geliefert. Doch nach diesem Updates leuchten diese nun immer rot. Der Schaltbefehl wird jedoch korrekt ausgeführt und auch als DONE von FHEM quittiert.
Wenn ich nun mein Backup von vor der Umstellung wieder einspiele werden auch meine Schaltbefehle wieder mit der grünen LED bestätigt.
Gibt es hier vielleicht einen Bug oder eine Änderung die mir nicht bekannt ist?
Für eine Info oder Ratschlag wäre ich echt dankbar.
Vielen Dank im Voraus,
mit freundlichen Grüßen
rufus999
@peterk_de
kannst du einmal rohmessages loggen, wie der Fühler den RT ansteuert - und die register von einem "guten" und einem "schlechten" RT
@rufus999
dein problem ist also nicht RT sondern der PB-2 - sollte ein anderes Thema sein.
Die eingetragenen Peers der virtuellen Aktoren sind bei den Tests identisch!?
Ich habe es nachgestellt - mit einer anderen FB - die wird grün.
=> wenn alle peers beidseitig vorhanden sind sollte es funktionieren. Ansonsten bitte die Konfiguration:
- list der beiden gepeerten Channels
- rohmessages des tastendrucks
Gruss Martin
Hallo,
Ich hatte auch Probleme bei meinen 3 RTs und den TFK. Das letzte Thermostat wollte garnicht mit dem TFK harmonieren.
Bin jetzt nach der bewährten Methode aus der Anleitung Post#548 vorgegangen und es hat funktioniert.
Doch jetzt wird mir der TFK im FHEM nicht angezeigt. Nur unter WindowRec wird die peerIDs aufgelistet.
Wie kann ich den jetzt zu meinen anderen TFKs hinzufügen oder anzeigen lassen?
Gruß
@Martin Logge ich gerne mal mit. Ansonsten, ich glaube ich habe da etwas verpasst gehabt - eben mal wieder geupdatet, jetzt gibt es laut reglist für R-regAdaptive zwei verschiedene Offs - offdef und offdetrmine - kannst du mir da evtl. nen Tipp geben wo der Unterschied liegt?
@Peter,
man kann die Adaptive Regelung einschalten (on)
oder ausschalten (off)
Beim Ausschalten gibt es 2 möglichkeiten, a) der RT nutzt die defaults oder b) der RT nutzt die bisher erarbeiteten Werte (determined)
Ich werde die Beschreibung in Reglist etwas anpassen
@Jens:
wenn der TFK nicht mehr in FHEM vorhanden ist fehlt er offenbar in fhem.cfg. Du solltest noch einmal anlernen drücken (pairen sollte nicht notwendig sein, wenn du den TFK nicht rückgesetzt hast) - dann kennt FHEM wieder das Device. Danach musst du deine attribute wieder eintragen, renamen,...
Und dann speichern - und, wie immer, sichern
Gruss Martin
Ich hatte das so gemacht.
1. das RT und den TFK zurückgesetzt
2. in der FHEM.cfg alles gelöscht von den Beiden
3. FHEM und HM-LAN ausgeschaltet
4. RT mit TFK gepairt
5. FHEM und HM-LAN wieder an und mit RT gepairt
6. den RT wieder umbenannt und interne Festererkennung abgeschaltet sowie Fenster auf Temperatur abgesenkt
wie muss ich jetzt genau vorgehen?
Den Eintrag aus der FHEM.cfg von vorher habe ich noch für den TFK.
Der TFK ist also nicht mit FHEM gepairt. Das würde ich machen, es sollte (meine Meinung) ALLES mit FHEM gepairt werden.
Dann würde ich alle Register auslesen, auch die des TFK - also ein getConfig,falls du die Automatic ausgeschaltet hast.
Das Peering sollte dann in FHEM sichtbar und änderbar sein.
Der TFK wird auch ohne pairing mit dem RT zusammen arbeiten - aber nicht wirklich mit der Zentrale...
Ok. Nur wie mach das jetzt am besten?
Habe gestern soviel gemacht und jedesmal wenn ich so gut wie fertig war hat der TFK nur noch rot geleuchtet und das RT wurde nicht mehr angesteuert. Reicht es wenn ich die gespeicherten Textzeilen vom TFK in die FHEM.cfg einfüge? Mit meine anderen Teilen hat das Super geklappt. Denk schon das da ein eventueller Defekt vorliegen könnte.
Also pairen geht "wie immer"
- hmPairForSec 300
- anlernen drücken
ggf. werden gleich alle reigster gelesen. Wenn nicht noch einmal getConfig und anlerenn noch einmal drücken.
Das sollte nichts an der LED ändern.
Wenn du eine rote LED bekommst, kontrollieren die Peers.
Wenns nicht klappt zeichne die Rohmessages auf und schicke die Konfiguration der Devices ("list")
Gruss Martin
@martinp
Hallo martin,
habe wie gewünscht einen neuen Beitrag eröffnet. http://forum.fhem.de/index.php/topic,17281.0.html
Wäre schön wenn du da ein Auge trauf werfen könntest.
Vielen Dank im Voraus,
rufus999
Ich hoffe ich habe nichts übersehen, ich habe das Problem, das in meinen Schaltzeiten manchmal vorne in set_ steht. Als Beispiel ich hab heute die Schaltzeiten geändert und in FHEM steht jetzt fogendes:
Zitat
tempListFri 05:45 16.0 07:00 20.0 13:30 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListMon 05:45 16.0 07:00 20.0 19:00 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListSat 09:00 16.0 24:00 20.0 2013-12-11 17:39:08
tempListSun 10:00 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListThu 05:45 16.0 07:00 20.0 18:00 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListTue 05:45 16.0 07:00 20.0 14:30 16.0 18:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListWed set_ 13:30 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
Starte ich ein getconfig, ist es anschließend weg. Der Thermostat funktioniert auch ganz normal, nur andFHEM hat das nicht gefallen. Nach dem letzten Update dachte ich erst es wäre weg. Wie kommt es dazu, ich konnte mit google nichts finden, auch so nicht im commandref das es irgendwie einen Grund dafür gibt.
Danke
Zitat von: strauch am 11 Dezember 2013, 17:45:53
Ich hoffe ich habe nichts übersehen, ich habe das Problem, das in meinen Schaltzeiten manchmal vorne in set_ steht. Als Beispiel ich hab heute die Schaltzeiten geändert
Das ist ein Zeichen dafür, dass zumindest FHEM noch keine Bestätigung vom RT erhalten hat, dass die Daten auch am Thermostat angekommen sind.
Zitat von: strauch am 11 Dezember 2013, 17:45:53Starte ich ein getconfig, ist es anschließend weg.
Dann gibt es wohl Übertragungsschwierigkeiten am Rückweg vom RT zum HMLAN. Denn durch das getConfig wird der RT nochmals abgefragt und dann klappt es wohl mit der Verbindung. Was hast du denn für Verbindungswerte am RT-Device? Poste einfach ein 'list <RT>' und dann poste hier die Rssi-Abschnitt aus dem Ergebnis.
Weitere Tips:
mit "regSet" oder verwanten Kommandos (auch templist) werden die geänderten Readings auf "set_" gesetzt - also "unbestätigt"
nach getConfig werden alle "set_" der Register gelöscht und die Werte aus dem Device eingetragen. Es wird NICHT geprüft, ob der "set_" Wert auch der aktuelle ist.
Frage:
- waren die Werte schon geschrieben? War protoState auf CMDs_done?
- gab es Fehler bei der übertragung (proto... variablen)
Gruss Martin
Danke für die Antworten, jetzt verstehe ich was da passiert. Ich werde das noch mal checken um die Fragen zu beantworten. Jetzt gerade kann ich den Fehler nicht nachvollziehen.
Die Sendequalität sieht so aus:
avg:-51.55 min:-79 max:-46 lst:-73 cnt:3711
avg:-63.63 min:-86 max:-53 lst:-66 cnt:3755
Ich verwende ein CUL für die Homeamtic Komponenten. Ich hatte durchaus schonmal "Empfangsfehler" die ich nicht verstanden habe.
Danke für Eure Hilfe.
Zitat von: strauch am 11 Dezember 2013, 23:45:02
Die Sendequalität sieht so aus:
avg:-51.55 min:-79 max:-46 lst:-73 cnt:3711
avg:-63.63 min:-86 max:-53 lst:-66 cnt:3755
Sieht eigentlich ganz normal aus.
Noch eine Sache aus eigener Erfahrung:
Ich wollte meine RTs ursprünglich möglichst funklastarm betreiben, bis ich zwei Dinge feststelle:
a) es gibt ständig Übertragungsprobleme und
b) ich ohnehin die Konfiguration für meinen SC noch anpassen muss.
Daraufhin hab ich im RT den Register burstRx auf 'on' gestellt, damit dieser auch zwischen den üblichen 2,5 Minuten aufgeweckt werden kann und anschließend beim Übermitteln der Wochenprogramme immer ein 'burstXmit' nachgeschmissen. Dadurch wird der RT zum Einen sofort geweckt und zum Anderen scheint er auch nicht wieder so schnell schlafen zu gehen, was eine gute Übertragung ermöglicht. Kehrseite der Medaille, wenn du mit 'burstXmit' arbeitest, ist der erhöhte Funktraffic und der erhöhte Strombedarf vom Thermostat.
Versuch es einmal damit... ich bin seither sehr zufrieden damit.
Danke für den Tipp dann hab ich mal ein bisschen zum testen :-)
Gesendet von meinem Nexus 4 mit Tapatalk
Moin,
wie kann ich das HM-CC-RT-DN denn via FHEM sperren? Da gibt es doch eine Tastenkombination um das Gerät vor Bedienung zu "schützen" und das nur noch via Funk zuzulassen. Wie kann ich das via FHEM einschalten ohne am Gerät die Tasten drücken zu müssen? Ich weiß, dass es diese Funktion in der HM-Software gibt. In FHEM auch?
Danke, Laurine
zum Burst noch eine Kommentar: ein burst verbraucht Batterie in ALLEN devices, die burst unterstützen, egal wer an wen sendet!
- wenn du also burstXmit oder das Attribut burstAccess nutzt geht es auf die Batterie ALLER devices in funkreichweite (auch die des Nachbarn)
- wenn im device burstRx = on gesetzt wird verbraucht sich demnach die batterie schneller - und zwar inbesondere im Masse, wie bursts in Funkreichweite angestossen werden.
Im konkreten Fall sehe ich aber kein Problem. Beim RT burst einzuschalten ist bei der Nutzung von Fensterkontakten sowieso notwendig. Das gelegentliche Übertragen von templisten sehe ich auch nicht als wirkliche Belastung - je nachdem wir oft man es startet.
@Laurine
inhibit war nicht eingebaut - kommt in der nächsten Version.
ausserdem gibt es die Register für manu und party mode
modePrioManu | literal | allow tempChange for manual only by... options:CCU,RT_TC_CCU_SELF,self,RT_TC_SC_SELF,all
modePrioParty | literal | allow tempChange for party only by... options:CCU,RT_TC_CCU_SELF,self,RT_TC_SC_SELF,all
Gruss Martin
Ich habe vor drei Wochen meine Heizungen mit HM-CC-RT-DN ausgestattet. Dazu einen HM-CFG-USB-2, der über hmland an meinen Debian Heimserver angeschlossen ist. Dazu ein einzelnes HM-WDS10-TH-O.
Ich hatte wochenlang -- die HM-CC-RT-DN waren im "wakeup" Modus -- das Problem dass ich keinerlei Befehle an meine Heizungen senden konnte, obwohl die HM-CC-RT-DN an den HM-CFG-USB-2 gepaired waren. Keine desired-temp, keine Wochenzeiten, nichts. Das ging immer nur dann, wenn ich den HM-CC-RT-DN manuell über fünf Sekunden Burstknopf geweckt habe. Alles andere führte zu ewig langem CMDs_pending und später MISSING ACK. An allen Geräten.
Die einzige Abhilfe war für mich, die ganze Kommunikation von "wakeup" auf "burst" umzustellen. Dazu musste ich:
1. Bei den HM-CC-RT-DNs jeweils den burst mode aktivieren:
set CUL_HM_HM_CC_RT_DN_123456 regSet burstRx on
und dann schnell rüber laufen und fünf Sek drücken, sonst nimmt er es nicht!
2. Danach fhem sagen, dass es über burst senden darf. Dazu in der fhem.cfg einen Eintrag für jedes HM-CC-RT-DN ergänzen, der etwa so aussieht:
attr CUL_HM_HM_CC_RT_DN_123456 burstAccess 1_auto
und anschließendes rereadcfg
Nun ließen sich schlagartig sämtliche Funktionalitäten im web-interface auch endlich nutzen, wie getConfig, set desired-temp... endlich geht die Grundfunktionalität!
Ich wollte das hier einfach mal posten, da es mich extrem viel Zeit gekostet hat und man hier im Thread (habe alles gelesen) auch recht viel zusammenpuzzeln muss, damit man als Anfänger darauf kommt, dass der wakeup-Modus möglicherweise nicht so recht gut will wie der burst-Modus.
Wie gesagt, ohne diese Änderung nur CMDs_pending und später MISSING ACK an allen Geräten. Ich habe auch fhem seit ca. Mitte November immer mal wieder aktualisiert, keine Abhilfe. Und ja, die HM-CC-RT-DN sind gepaired, das war das Erste. Die Zentrale ist im pairedTo-Register und in dem anderen Register (Bezeichner vergessen) eingetragen und das Antennensymbol auf den HM-CC-RT-DN leuchtet jetzt dauerhaft. Vorher fing es immer wieder mal an zu blinken und ich hatte dann auch motorErr: communicationErr.
Bin froh, dass es jetzt läuft, gehe in wenigen Tagen in den Weihnachtsurlaub und will die Heizungen dann remote steuern.....
Jetzt nur noch eben VPN einrichten... ::)
Viele Grüße, ich hoffe es hilft jemandem,
Christian
@Christian: Da bist du nicht der Erste und wohl auch nicht der Letzte mit dem Problem.
Das Timing scheint bei den RTs sehr knifflig zu sein und durch den burstMode und dem burstAccess werden sie scheinbar toleranter (wenn auch auf Kosten der Batterie und Sendezeit).
Hallo Christian,
das Attribut burstAccess ist möglich - empfehle ich aber nicht. Es gibt die Variante des Kommandos
set <rt-device> burstXmit
beim Attribut sendet fhem automatisch einen "halloWach" an den RT - danach die messages, die vorliegen.
mit dem Kommando hast du in der Hand, wann "halloWach" gesendet werden soll. Du kannst zum einen Warten, bis der RT aufwacht.
Du kannst mehrere Kommandos in die queue stellen, und dann erst burstXmit senden.
Zu beachten ist dabei, dass "halloWach" den HMLAN 'belasten'. Mehr als 100 sendet er nicht, je Stunde - abzüglich aller anderen messages! Wenn er wiederholen muss nur ein Drittel.
Was mich interessieren würden ist, warum es beim wakeup nicht klappt, also ohne burst. Falls du einen log rohmessages aufnehmen kannst, werde ich es durchsehen. (burstAccess natürlich ausgeschaltet)
Gruss Martin
Zitat von: martinp876 am 14 Dezember 2013, 13:35:48
das Attribut burstAccess ist möglich - empfehle ich aber nicht. Es gibt die Variante des Kommandos
set <rt-device> burstXmit
Hej Martin,
Christian hat wohl das selbe Problem wie auch ich es habe. Und wenn >95% aller Befehle mittels Wakeup-Methode im Sand verlaufen, dann wird burstXmit recht uninteressant und man nutzt burstAccess stattdessen.
meine RTs funktionieren im wakeup - ich kann es also nicht testen.
Wenn einer noch logs schicken kann, werde ich es prüfen.
Beachten muss man die Verzögerung. Der Ablauf ist:
user setzt tempSoll auf 22
warten - 0-2,5min
rt meldet temp soll 21
fhem setzt tempSoll auf 22
rt setzt temp auf 22
nach 2,5 min
rt meldet temp soll 22
Also kann es 0-2,5min dauern bis die temp gesetzt ist, 2,5-5min dauern bis FHEM das Ergebnis darstellt.
Alles andere wären Fehler
Gruss Martin
Zitat von: martinp876 am 14 Dezember 2013, 10:22:27
@Laurine
inhibit war nicht eingebaut - kommt in der nächsten Version.
ausserdem gibt es die Register für manu und party mode
modePrioManu | literal | allow tempChange for manual only by... options:CCU,RT_TC_CCU_SELF,self,RT_TC_SC_SELF,all
modePrioParty | literal | allow tempChange for party only by... options:CCU,RT_TC_CCU_SELF,self,RT_TC_SC_SELF,all
Gruss Martin
Hallo Martin,
danke für die Antwort, ich habe aber nichts davon verstanden. Was ist inhibit? In der nächsten Version wovon? FHEM? Wofür sind die von Dir genannten Register?
Gruß, Laurine
PS: Ich haber hier 6 von den Thermostaten verbaut und an zwei davon drehen immer die Kinder rum, deswegen möchte ich die gern sperren.
inhibit ist ein kommando
set h_FstH inhibit on|off
Inhibit sperrt den Kanal/die Entity
habe es gerade probiert - leider ohne den gewünschten Erfolg.
- der RT akzeptiert das inhibit auf jedem Kanal
- eine Änderung der temp war immer noch möglich -was bei anderen Devices besser klappt
=> entweder habe ich noch nicht gefunden, was inhibit beim RT sperren soll - oder es ist ein Bug in der FW, zumindest in Version 1.0
wenn du eine andere Version hast kannst du es probieren
Ansonsten kannst du mit
set h_Clima regSet modePrioManu CCU
einstellen, das im Manu-mode die temp nur von der CCU (hier also FHEM) geändert werden kann.
Für Auto-mode sehe ich keine Möglichkeit.
Gruss Martin
jetzt habe ich es doch noch gefunden
set <device> regSet btnLock lock
Nicht im clima channel sondern im Device
Es lohnt sich immer wieder einmal, regList anzuschauen...
Zitat von: martinp876 am 15 Dezember 2013, 10:55:53
jetzt habe ich es doch noch gefunden
set <device> regSet btnLock lock
Nicht im clima channel sondern im Device
Es lohnt sich immer wieder einmal, regList anzuschauen...
Danke für die Recherchearbeit und die auch die anderen Erklärungen. Es funktioniert wie von Dir beschrieben.
Gruß, Laurine
Ich habe seit einigen Tagen den HM-CC-RT-DN im Einsatz. Allerdings bekomme ich den noch nicht so richtig zum laufen. Das Pairen hat soweit geklappt denke ich. Hier mal ein Auszug aus der cfg:
attr CUL_HM_HM_CC_RT_DN_220733 .devInfo 00FFFF
attr CUL_HM_HM_CC_RT_DN_220733 .stc 59
attr CUL_HM_HM_CC_RT_DN_220733 actCycle 000:10
attr CUL_HM_HM_CC_RT_DN_220733 actStatus alive
attr CUL_HM_HM_CC_RT_DN_220733 autoReadReg 4_reqStatus
attr CUL_HM_HM_CC_RT_DN_220733 burstAccess 1_auto
attr CUL_HM_HM_CC_RT_DN_220733 expert 2_full
attr CUL_HM_HM_CC_RT_DN_220733 firmware 1.0
attr CUL_HM_HM_CC_RT_DN_220733 model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_220733 peerIDs
attr CUL_HM_HM_CC_RT_DN_220733 room CUL_HM
attr CUL_HM_HM_CC_RT_DN_220733 serialNr KEQ0510374
attr CUL_HM_HM_CC_RT_DN_220733 subType thermostat
attr CUL_HM_HM_CC_RT_DN_220733 webCmd getConfig:burstXmit
define FileLog_CUL_HM_HM_CC_RT_DN_220733 FileLog ./log/CUL_HM_HM_CC_RT_DN_220733-%Y.log CUL_HM_HM_CC_RT_DN_220733
attr FileLog_CUL_HM_HM_CC_RT_DN_220733 logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_220733 room CUL_HM
define CUL_HM_HM_CC_RT_DN_220733_Weather CUL_HM 22073301
attr CUL_HM_HM_CC_RT_DN_220733_Weather expert
attr CUL_HM_HM_CC_RT_DN_220733_Weather model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_220733_Weather peerIDs
attr CUL_HM_HM_CC_RT_DN_220733_Weather room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_220733_Weather FileLog ./log/CUL_HM_HM_CC_RT_DN_220733_Weather-%Y.log CUL_HM_HM_CC_RT_DN_220733_Weather
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_Weather logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_Weather room CUL_HM
define CUL_HM_HM_CC_RT_DN_220733_Climate CUL_HM 22073302
attr CUL_HM_HM_CC_RT_DN_220733_Climate expert
attr CUL_HM_HM_CC_RT_DN_220733_Climate model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_220733_Climate peerIDs
attr CUL_HM_HM_CC_RT_DN_220733_Climate room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_220733_Climate FileLog ./log/CUL_HM_HM_CC_RT_DN_220733_Climate-%Y.log CUL_HM_HM_CC_RT_DN_220733_Climate
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_Climate logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_Climate room CUL_HM
define CUL_HM_HM_CC_RT_DN_220733_WindowRec CUL_HM 22073303
attr CUL_HM_HM_CC_RT_DN_220733_WindowRec expert
attr CUL_HM_HM_CC_RT_DN_220733_WindowRec model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_220733_WindowRec peerIDs
attr CUL_HM_HM_CC_RT_DN_220733_WindowRec room CUL_HM
attr CUL_HM_HM_CC_RT_DN_220733_WindowRec stateFormat last:trigLast
define FileLog_CUL_HM_HM_CC_RT_DN_220733_WindowRec FileLog ./log/CUL_HM_HM_CC_RT_DN_220733_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_220733_WindowRec
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_WindowRec logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_WindowRec room CUL_HM
define CUL_HM_HM_CC_RT_DN_220733_Clima CUL_HM 22073304
attr CUL_HM_HM_CC_RT_DN_220733_Clima expert
attr CUL_HM_HM_CC_RT_DN_220733_Clima model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_220733_Clima peerIDs
attr CUL_HM_HM_CC_RT_DN_220733_Clima room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_220733_Clima FileLog ./log/CUL_HM_HM_CC_RT_DN_220733_Clima-%Y.log CUL_HM_HM_CC_RT_DN_220733_Clima
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_Clima logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_Clima room CUL_HM
define CUL_HM_HM_CC_RT_DN_220733_ClimaTeam CUL_HM 22073305
attr CUL_HM_HM_CC_RT_DN_220733_ClimaTeam expert
attr CUL_HM_HM_CC_RT_DN_220733_ClimaTeam model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_220733_ClimaTeam peerIDs
attr CUL_HM_HM_CC_RT_DN_220733_ClimaTeam room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_220733_ClimaTeam FileLog ./log/CUL_HM_HM_CC_RT_DN_220733_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_220733_ClimaTeam
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_ClimaTeam logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_ClimaTeam room CUL_HM
define CUL_HM_HM_CC_RT_DN_220733_remote CUL_HM 22073306
attr CUL_HM_HM_CC_RT_DN_220733_remote expert
attr CUL_HM_HM_CC_RT_DN_220733_remote model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_220733_remote peerIDs
attr CUL_HM_HM_CC_RT_DN_220733_remote room CUL_HM
define FileLog_CUL_HM_HM_CC_RT_DN_220733_remote FileLog ./log/CUL_HM_HM_CC_RT_DN_220733_remote-%Y.log CUL_HM_HM_CC_RT_DN_220733_remote
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_remote logtype text
attr FileLog_CUL_HM_HM_CC_RT_DN_220733_remote room CUL_HM
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*
attr ActionDetector room CUL_HM
define FileLog_ActionDetector FileLog ./log/ActionDetector-%Y.log ActionDetector
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector room CUL_HM
Mein Problem ist das setzten der Temperaturliste. Den Kanal 4 gibt es bei mir nicht als "ClimRT_tr" sonder als "Clima"!
channel_04
CUL_HM_HM_CC_RT_DN_220733_Clima
Das setzten der Temperaturliste habe ich wie folgt angelegt:
######################################################
# Temperatur-Liste für Esszimmer/Küche
# setzen per Aufruf von "{SetTempList_UG_Treppe_Heizung}"
# Vorsicht, da kein HM-CC-TC, sondern HM-CC-RT-DN, ist hier ein anderer Channel
# zu nehmen. Zudem wird mit prep|exec gearbeitet, um nicht alle Zeilen als
# einzelnen Befehl zu senden, sondern per "prep" erst alles
# zusammenzufassen und dann per "exec" an das Thermostat zu senden.
# Also als ein einziger Befehl statt sieben. Vermeidet "NACKs"
######################################################
sub
SetTempList_CUL_HM_HM_CC_RT_DN_220733()
{
{ fhem ("set CUL_HM_HM_CC_RT_DN_220733_Clima tempListMon prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_220733_Clima tempListTue prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_220733_Clima tempListWed prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_220733_Clima tempListThu prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_220733_Clima tempListFri prep 05:30 16.0 07:00 18.0 15:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_220733_Clima tempListSat prep 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
{ fhem ("set CUL_HM_HM_CC_RT_DN_220733_Clima tempListSun exec 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
}
# End SetTempList_CUL_HM_HM_CC_RT_DN_220733
Irgendwie kommt die Liste am HM_CC_RT_DN nicht an.
Habe das auch schon zurückgesetzt und neu gepairt, aber ohne erfolg.
Hi holzwurm83
Zitat von: holzwurm83 am 16 Dezember 2013, 22:51:44... Das Pairen hat soweit geklappt denke ich. Hier mal ein Auszug aus der cfg: ...
Wichtiger als der Auszug aus der
fhem.cfg wäre (wegen des "Pairens") die Ausgabe von
list CUL_HM_HM_CC_RT_DN_220733
Gruß
Thomas
Zitat von: Rohan am 16 Dezember 2013, 23:21:31
Hi holzwurm83
Wichtiger als der Auszug aus der fhem.cfg wäre (wegen des "Pairens") die Ausgabe von
list CUL_HM_HM_CC_RT_DN_220733
Gruß
Thomas
Hier...
Internals:
DEF 220733
EVENTS 2
IODev cuno
LASTInputDev cuno
MSGCNT 10
NAME CUL_HM_HM_CC_RT_DN_220733
NR 380
STATE CMDs_pending
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_RT_DN_220733_Weather
channel_02 CUL_HM_HM_CC_RT_DN_220733_Climate
channel_03 CUL_HM_HM_CC_RT_DN_220733_WindowRec
channel_04 CUL_HM_HM_CC_RT_DN_220733_Clima
channel_05 CUL_HM_HM_CC_RT_DN_220733_ClimaTeam
channel_06 CUL_HM_HM_CC_RT_DN_220733_remote
cuno_MSGCNT 10
cuno_RAWMSG A150286102207330000000A88E1900018800D18800DCC14
cuno_RSSI -64
cuno_TIME 2013-12-16 23:21:25
lastMsg No:02 - t:10 s:220733 d:000000 0A88E1900018800D18800DCC
protCmdDel 18
protCmdPend 14 CMDs pending
protCondBurst off
protLastRcv 2013-12-16 23:21:25
protResnd 3 last_at:2013-12-16 23:08:50
protResndFail 1 last_at:2013-12-16 23:11:03
protSnd 12 last_at:2013-12-16 23:21:25
protState CMDs_pending
rssi_at_cuno avg:-65.05 min:-66.5 max:-63.5 lst:-64 cnt:10
CHANGETIME:
Helper:
Dblog:
Activity:
Mydblog:
TIME 1387231242.27421
VALUE alive
Actuator:
Mydblog:
TIME 1387232485.83231
VALUE 0
Battery:
Mydblog:
TIME 1387232485.83231
VALUE ok
Batterylevel:
Mydblog:
TIME 1387232485.83231
VALUE 3.1 V
Desired-temp:
Mydblog:
TIME 1387232485.83231
VALUE 17
Measured-temp:
Mydblog:
TIME 1387232485.83231
VALUE 22.5
Poweron:
Mydblog:
TIME 1387232281.03349
VALUE -
State:
Mydblog:
TIME 1387231863.92637
VALUE MISSING ACK
Readings:
2013-12-16 23:00:42 Activity alive
2013-12-16 22:56:18 CommandAccepted yes
2013-12-16 22:12:45 R-pairCentral set_0xF11234
2013-12-16 23:21:25 actuator 0 %
2013-12-16 23:21:25 battery ok
2013-12-16 23:21:25 batteryLevel 3.1 V
2013-12-16 23:21:25 desired-temp 17
2013-12-16 23:21:25 measured-temp 22.5
2013-12-16 22:41:57 noReceiver src:220733 A010 05000000000007484448546C44CC550845
2013-12-16 23:18:01 powerOn -
2013-12-16 23:18:00 recentStateType info
2013-12-16 23:21:26 state CMDs_pending
2013-12-16 22:13:16 time-request -
cmdStack:
++A011F1123422073386042A
++A001F1123422073300040000000000
++A001F112342207330103
++A001F1123422073301040000000001
++A001F112342207330203
++A001F1123422073302040000000001
++A001F112342207330303
++A001F1123422073303040000000001
++A001F1123422073304040000000001
++A001F1123422073304040000000007
++A001F112342207330503
++A001F1123422073305040000000001
++A001F112342207330603
++A001F1123422073306040000000001
Helper:
mId 0095
rxType 140
Prt:
awake 0
bErr 0
sProc 2
wakeup 0
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_cuno:
avg -65.05
cnt 10
lst -64
max -63.5
min -66.5
Attributes:
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
burstAccess 1_auto
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room CUL_HM
serialNr KEQ0510374
subType thermostat
webCmd getConfig:burstXmit
Hallo holzwurm83,
tut mir ja leid, aber ...
Zitat von: holzwurm83 am 16 Dezember 2013, 23:23:37
Hier...
STATE CMDs_pending
... dein RT verarbeitet deine Befehle nicht. CMDs_pending heißt, dass da noch etwas in der Sendewarteschleife von Fhem wartet.
Zitat
...
protCmdPend 14 CMDs pending
....
protState CMDs_pending
...
rssi_at_cuno avg:-65.05 min:-66.5 max:-63.5 lst:-64 cnt:10
...
State:
Mydblog:
TIME 1387231863.92637
VALUE MISSING ACK
Readings:
...
2013-12-16 22:12:45 R-pairCentral set_0xF11234
...
2013-12-16 23:21:26 state CMDs_pending
... und zwar 14 Befehle ("14 CMDs pending"). "MISSING ACK" heißt, dass Fhem keine Empfangsbestätigung vom RT bekommen hat und "R-pairCentral
set_0xF11234" bedeutet, dass das Pairing noch nicht durchgeführt wurde, sonst stünde dort
R-pairCentral 0xF11234, also ohne "set_" davor.
Und ohne ein Pairing mit einem abgearbeiteten
set getConfig wird das nichts werden. Also bitte den RT erst mal richtig an Fhem binden ("pairen").
Edith meinte ich sollte noch nachtragen: Die Zeile mit dem "rssi_at_cuno avg:" habe ich drin gelassen, denn daran wird deutlich: An der Sende-/Empfangsqualität liegt es wohl eher
nicht.
Gruß
Thomas
Hallo Thomas,
habe jetzt mal das RT zurückgesetzt und aus der Fhem cfg alles gelöscht. Habe jetzt das pairing noch durchgeführt.
Hier das Ergebnis:
Internals:
CFGFN
DEF 22080E
EVENTS 18
IODev cuno
LASTInputDev cuno
MSGCNT 23
NAME CUL_HM_HM_CC_RT_DN_22080E
NR 319
STATE CMDs_pending
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_RT_DN_22080E_Weather
channel_02 CUL_HM_HM_CC_RT_DN_22080E_Climate
channel_03 CUL_HM_HM_CC_RT_DN_22080E_WindowRec
channel_04 CUL_HM_HM_CC_RT_DN_22080E_Clima
channel_05 CUL_HM_HM_CC_RT_DN_22080E_ClimaTeam
channel_06 CUL_HM_HM_CC_RT_DN_22080E_remote
cuno_MSGCNT 23
cuno_RAWMSG A1A11A01022080EF1123403100000098E44485508452045204520454C
cuno_RSSI -36
cuno_TIME 2013-12-17 09:18:50
lastMsg No:11 - t:10 s:22080E d:F11234 03100000098E4448550845204520452045
protCmdPend 4 CMDs pending
protLastRcv 2013-12-17 09:18:50
protResnd 1 last_at:2013-12-17 09:18:52
protSnd 19 last_at:2013-12-17 09:18:50
protState CMDs_pending
rssi_at_cuno avg:-38.1 min:-54.5 max:-35.5 lst:-36 cnt:23
CHANGETIME:
Helper:
Dblog:
Activity:
Mydblog:
TIME 1387268108.5141
VALUE alive
R-paircentral:
Mydblog:
TIME 1387268097.46899
VALUE set_0xF11234
Actuator:
Mydblog:
TIME 1387268323.75154
VALUE 0
Battery:
Mydblog:
TIME 1387268323.75154
VALUE ok
Batterylevel:
Mydblog:
TIME 1387268323.75154
VALUE 3.1 V
Desired-temp:
Mydblog:
TIME 1387268323.75154
VALUE 17
Measured-temp:
Mydblog:
TIME 1387268323.75154
VALUE 22.7
Time-request:
Mydblog:
TIME 1387268128.35213
VALUE -
Readings:
2013-12-17 09:15:08 Activity alive
2013-12-17 09:18:44 CommandAccepted yes
2013-12-17 09:18:45 PairedTo 0xF11234
2013-12-17 09:18:45 R-backOnTime 10 s
2013-12-17 09:18:45 R-btnLock unlock
2013-12-17 09:18:45 R-burstRx off
2013-12-17 09:18:45 R-cyclicInfoMsg on
2013-12-17 09:18:45 R-cyclicInfoMsgDis 0
2013-12-17 09:18:45 R-globalBtnLock off
2013-12-17 09:18:45 R-localResDis off
2013-12-17 09:18:45 R-lowBatLimitRT 2.1 V
2013-12-17 09:18:45 R-modusBtnLock off
2013-12-17 09:18:45 R-pairCentral 0xF11234
2013-12-17 09:18:45 RegL_00: 01:00 02:01 09:01 0A:F1 0B:12 0C:34 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2013-12-17 09:18:43 actuator 0 %
2013-12-17 09:18:43 battery ok
2013-12-17 09:18:43 batteryLevel 3.1 V
2013-12-17 09:18:43 desired-temp 17
2013-12-17 09:18:43 measured-temp 22.7
2013-12-17 09:18:52 state CMDs_pending
2013-12-17 09:15:28 time-request -
cmdStack:
++A001F1123422080E04040000000007
++A001F1123422080E0503
++A001F1123422080E05040000000001
++A001F1123422080E0603
++A001F1123422080E06040000000001
Helper:
mId 0095
rxType 140
Prt:
bErr 0
sProc 2
wuReSent 2
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_cuno:
avg -38.1086956521739
cnt 23
lst -36
max -35.5
min -54.5
Shadowreg:
Attributes:
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room CUL_HM
serialNr KEQ0510590
subType thermostat
webCmd getConfig:burstXmit
Das Pairing sollte jetzt passen, oder?
Zitat2013-12-17 09:18:45 PairedTo 0xF11234
ja
Zitat von: martinp876 am 17 Dezember 2013, 09:28:48
ja
Leider bestehen die Probleme die ich oben geschrieben habe weiterhin. Irgendwas stimmt da immer noch nicht?
Hallo holzwurm83,
von deiner Postgeschwindigkeit ausgehend, bist du zu ungeduldig.
set getConfig durchführen, warten bis der RT geantwortet hat (alle 2,5 Minuten)
es dürfen danach kein "CMDs pending" mehr sein
Jetzt kannst du mal langsam anfangen ...
Hallo Thomas,
tut mir leid, wenn ich etwas zu forsch war!
Zitatset getConfig durchführen, warten bis der RT geantwortet hat (alle 2,5 Minuten)
das habe ich jetzt mal durchgeführt. "CMDs pending" ist leider immer noch da.
Es steht jetzt auch folgendes drin:
protCmdPend 46 CMDs pendingBraucht ihr noch weitere Infos?
Jetzt steht sogar
STATE
MISSING ACKdrin.
Hi,
gibst du mal bitte ein "version" in die Befehlszeile der Web-GUI ein und postest das Ergebnis?
Gruß
Thomas
Hi Thomas,
hier ist das Ergebnis:
# $Id: fhem.pl 4386 2013-12-15 17:09:05Z rudolfkoenig $
# $Id: 00_CUL.pm 4388 2013-12-15 18:55:16Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4380 2013-12-14 12:06:17Z martinp876 $
# $Id: 10_CUL_IR.pm 3580 2013-08-02 16:17:38Z betateilchen $
# $Id: 14_CUL_WS.pm 4229 2013-11-15 17:29:55Z rudolfkoenig $
# $Id: 93_DbLog.pm 3855 2013-09-04 17:57:38Z tobiasfaust $
# $Id: 72_FB_CALLMONITOR.pm 4368 2013-12-12 16:22:58Z markusbloch $
# $Id: 01_FHEMWEB.pm 4384 2013-12-15 10:45:37Z rudolfkoenig $
# $Id: 95_FLOORPLAN.pm 3971 2013-09-29 08:16:39Z ulimaass $
# $Id: 10_FS20.pm 3764 2013-08-22 07:09:38Z rudolfkoenig $
# $Id: 92_FileLog.pm 3759 2013-08-21 08:13:08Z rudolfkoenig $
# $Id: 13_KS300.pm 4229 2013-11-15 17:29:55Z rudolfkoenig $
# $Id: 99_SUNRISE_EL.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_SVG.pm 4384 2013-12-15 10:45:37Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 59_Weather.pm 4321 2013-12-03 20:13:08Z borisneubert $
# $Id: 99_XmlList.pm 1840 2012-09-12 13:52:08Z rudolfkoenig $
# $Id: 98_autocreate.pm 4234 2013-11-17 10:19:41Z rudolfkoenig $
# $Id: 98_dummy.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 91_notify.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 4381 2013-12-14 13:03:46Z justme1968 $
# $Id: 98_structure.pm 4379 2013-12-14 09:11:03Z rudolfkoenig $
# $Id: 98_telnet.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 91_watchdog.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id:
# $Id: 98_weblink.pm 3770 2013-08-23 13:29:58Z rudolfkoenig $
Gruß
Also liegt es schon mal nicht an einer zu alten Fhem-Version. Mich wundern nur deine 46 pending CMDs aus deinem Post vorher. Und solange du keinen Channel 4 mit dem Namen "...ClimRT_tr" hast, kannst du wohl auch keine TempListen setzen.
Hmmmm .... Sorry, aber da muss ich erst mal passen.
Gruß
Thomas
Zitat von: Rohan am 17 Dezember 2013, 10:08:48
Also liegt es schon mal nicht an einer zu alten Fhem-Version. Mich wundern nur deine 46 pending CMDs aus deinem Post vorher. Und solange du keinen Channel 4 mit dem Namen "...ClimRT_tr" hast, kannst du wohl auch keine TempListen setzen.
Hmmmm .... Sorry, aber da muss ich erst mal passen.
Gruß
Thomas
Hmm, dass ist schade...
Kann es an dem CUNO2 liegen? Ich habe diese Firmware hier vom letzten Beitrag wegen dem IR eingespielt.
http://forum.fhem.de/index.php/topic,15013.msg96864.html#msg96864
Ich habe jetzt insgesamt drei RTs Gepaird. Das Pairing passt soweit nur zeigt der state irgendwann immer "MISSING ACK" an und folgendes:
protState CMDs_done_Errors:1
Hallo Holzwurm,
mit de CUNO2 haben wir viele Probleme. Der Verdacht ist, dass die CUNO kein stabiles timing liefert - die Varianz beim Senden der messages ist zu gross und kann nicht gehändelt werden.
Es muss von CUNO entwicklern behoben werden. So lange kann ich leider nicht weiterhelfen.
Gruss Martin
Hallo Martin,
danke für dein Feedback. Lesen die CUNO-Entwickler hier mit? Oder sollte ich das besser noch mal wo anders Posten?
Gruß
Solltest du am besten hier (http://forum.fhem.de/index.php/board,49.0.html) mit Verweis auf diesen Thread posten.
Zitat von: Mr. P am 17 Dezember 2013, 15:23:27
Solltest du am besten hier (http://forum.fhem.de/index.php/board,49.0.html) mit Verweis auf diesen Thread posten.
Da habe ich wohl keine Berechtigung was zu schreiben. :'(
Zitat von: holzwurm83 am 17 Dezember 2013, 15:27:12
Da habe ich wohl keine Berechtigung was zu schreiben. :'(
Stimmt, darauf hab ich vorhin erst gar nicht geachtet.
Aber martinp876 war ohnehin schon schneller. ;-)
Link (http://forum.fhem.de/index.php/topic,17635.0.html)
Das ist ja super! Danke Martin! :)
Ich hab noch mal eine Verständnisfrage ich habe 2 HM-CC-RT-DN und 2 HM-SEC-SC Fensterkontakte. Jeweils 1 für einen Raum.
Zuerst hatte ich 1DN und 1SC, die habe ich erst unter einander bekannt gemacht und dann jeweils beide mit dem FHEM Server (ich verwende ein CUL zur Kommunikation).
Dann habe ich mir noch ein DN gekauft und den mit FHEM gepairt. Gestern hab ich noch ein HM-SEC-SC bekommen und diesen ebenfalls mit FHEM gepairt und dann mit dem DN gepeert, das hat auch soweit geklappt. Was mich wundert, das die beiden wesentlich mehr Informationen tauschen, als die ersten beiden die ich erst untereinander bekannt gemacht habe. Bei den ersten beiden stehen auch keine PeerIDs obwohl der Tür Fensterkontakt funktioniert.
Die ersten beiden spucken folgendes im Protokoll aus:
2013-12-19 08:43:12 CUL_HM bz_Fenster open
2013-12-19 08:43:12 CUL_HM bz_Fenster contact: open (to CUL_HM)
2013-12-19 08:43:13 CUL_HM bz_Fenster open
2013-12-19 08:43:13 CUL_HM bz_Fenster contact: open (to bz_Heizung)
Die über FHEM gepeerten spucken das hier aus:
2013-12-19 08:44:16 CUL_HM lz_Fenster open
2013-12-19 08:44:16 CUL_HM lz_Fenster contact: open (to CUL_HM)
2013-12-19 08:44:16 CUL_HM lz_Heizung_WindowRec trig_lz_Fenster: open
2013-12-19 08:44:16 CUL_HM lz_Heizung_WindowRec trigLast: lz_Fenster :open
2013-12-19 08:44:17 CUL_HM lz_Fenster open
2013-12-19 08:44:17 CUL_HM lz_Fenster contact: open (to lz_Heizung)
2013-12-19 08:44:17 CUL_HM lz_Heizung_WindowRec trig_lz_Fenster: open
2013-12-19 08:44:17 CUL_HM lz_Heizung_WindowRec trigLast: lz_Fenster :open
Dort steht dann auch im Kanal lz_Heizung_WindowRec der letzte Zustand des Sensors und die PeerIDs stehen dort und im Fensterkontakt.
Nun kann ich die beiden ersten auch einfach über FHEM peeren. Ist ja alles kein Problem, nur warum ist das so?
die tauschen nicht mehr infos aus. FHEM kann aber mehr auswerten.
bist du sicher, das da keine peers drin stehen? Hast du den ein getConfig gemacht?
Wenn FHEM die peerIDs kennt werden auch die trigger-readings gesetzt. Ohne diese Infos ist es nicht möglich.
Wen du die Config komplett gelesen hast werden auch die peerIDs gefüllt werden. Wenn du dann ein save machst bleiben sie auch da. Und wenn du ein autoReadReg 4 eingestellt hast sollte FHEM es lesen, wenn die Daten nicht komplett sind.
Also ich hab gestern bei bz_Heizung schon testweise ein peering Gemacht, seit dem tauchen da auch das Peering mit dem HM-SEC-SC auf, beim SC war ich zu faul den Knopf zu drücken, da stehts noch nicht drin, da kann ich mal ein getconfig machen und den Knopf drücken.
Getconfig hab ich vorher schon öfter gemacht, unter anderem wegem dem _set Problem. Aber dann weiß ich jetzt das die Zusatzinfos primär für FHEM sind und die Geräte selber das nicht juckt, es müssten aber die PeerIDs da stehen, was ja auch logisch ist. Ich werd nachher mal schauen. Ansonsten werde ich mal neu testen, wenn ich wieder ein DN und SC gekauft hab :-).
Danke für die Infos.
Ich hab heute morgen mal ein getConfig durchgeführt, jetzt überträgt auch der erste SC die gleichen Informationen und die PeerIDs sind vorhanden. Aber da ich vorgestern schon ein peering in FHEM durchgeführt habe, denke ich wird das auch reingespielt haben. Wenn ich die dritte Kombi kaufe werde ich mir das noch mal anschauen. Aber jetzt verstehe ich das. Danke.
hallo erstmal,
kann es sein das es mit der aktuellen fhem version probleme mit der kombination pi+coc + HM-CC-RT-DN gibt.
ich habe seit 2 tagen ein coc auf dem pi. mit der version aus "wget http://fhem.de/fhem-5.5.deb && sudo dpkg -i fhem-5.5.deb" kann ich den HM-CC-RT-DN pairen.
sobald jedoch in fhem ein update durchgeführt wurde ist es mir nicht mehr möglich das thermostat zu pairen. er legt max. das gerät in der fhem.cfg an, jedoch kein AC am rt und keine infos in fhem.
mach ich ein apt-get --purge remove fhem und ziehe die normal 5.5deb drauf, läuft wieder alles (coc reset in /etc/init.d/fhem unter start eintragen, fhem stop/start, coc wird autom. in fhem angelegt, rfmode noch setzen und hmpairforsec schalten, am rt taste drücken --> sofort AC!).
Hej chris1284,
wenn der RT in FHEM erst einmal gepairt ist, kannst du ihn nicht nochmal pairen.
Sichere einmal deine Config, lösche die Einträge für den RT, starte FHEM neu und versuche es dann nochmal.
Es sollte zwar auch einen Weg innerhalb von FHEM geben, neu pairen zu können, aber bislang hat sich dieser als am zuverlässigsten erwiesen. ;-)
Hi,
ich hatte bereits den rt mehrmals reseted, batterien raus , den pi neu installiert usw usw. der rt hatte auch immer keinen "funkmasten" im display (war also nie gepaired).
was mir neben bei noch aufällt ist das die led am COC dauer an ist nach dem fhem staret. füre ich dann zb ein getconfig durch oder schalte eine meiner itr 1500 geht die led aus... ist dies normal?
EDIT: Habe jetz mal die 5.5 installiert, den rt paired und dann das update durchgeführt. bis jetzt läufts
@chris1284: Danke für den Tip. Ich habe seit gestern versucht ein Pairing mit der letzten SVN Version hinzubekommen. Ohne Erfolg. Jetzt nach einem downgrade auf 5.5 ging es sofort. Mich würde interessieren, was da kaputt gegangen ist. Evtl. ein SVN bisect machen? Aber ich gehe davon aus, dass Martin weiß woher die Problematik kommt...
Ansonsten teste ich gerne weiter.
Gruß
Chris
so wie es aussieht ist das einzige was für ein erfolgreiches paaren noch fehlt eine bestätigung seitens fhem. meine vermutung wenn ich mir die logs anschaue, bin ja nur "leihe".
wenn man schaut wird durch autocreate das device angelegt, das sieht auch alles normal aus, am rt jedoch keine AC-meldung. der "sendemast" ist auch nicht zu sehen.
Kann ich so bestätigen, ja. Es erscheint weder Sendemast noch ein Ack, die Devices werden aber angelegt.
Zitat von: chris1284 am 23 Dezember 2013, 09:24:28so wie es aussieht ist das einzige was für ein erfolgreiches paaren noch fehlt eine bestätigung seitens fhem. meine vermutung wenn ich mir die logs anschaue, bin ja nur "leihe".
wenn man schaut wird durch autocreate das device angelegt, das sieht auch alles normal aus, am rt jedoch keine AC-meldung. der "sendemast" ist auch nicht zu sehen.
Hej chris1284,
genau so ist es. Ein autocreate alleine führt noch kein pairing durch. Es legt lediglich die Geräte in FHEM an (eben autocreate und nicht autopair). ;-)
Ist als Einsteiger durchaus nicht gleich zu durchschauen. Geräte werden schließlich angezeigt, warum also nicht auch gepairt.
Jedenfalls ist es unumgänglich, dass du für deine RTs auch immer noch ein Pairing durchführst, damit diese auch wirklich wissen, mit wem sie zukünftig plaudern müssen. :-)
hi mr.p,
schon klar, nur das funktioniert nicht meiner meinung nach. wie gesagt wenns in der 5.5 geht, aber in der aktuellsten svn nicht liegt wohl genau da der fehler, nicht bei mir. da es reproduzierbar ist, erhärtet sich der verdacht. und mehr als hmpairforsec und hmpairserial kann ich ja nicht ausführen zum pairen.
noch mal etwas deutlicher:
ausgehend von gleich aufgesetztem pi, gleicher softwarestand
fhem 5.5
-> set cul hmpairforsec 600
-> knopf am rt gedrückt
-> sofort AC
-> gerät in fhem paired und angelegt
aktueller svn
-> set cul hmpairforsec 600
-> knopf am rt gedrückt
-> zeit läuft die 30sec auf 0, kein AC, kein "sendemast"(visuelle bestätigung das paired)
-> in fhem wurde das gerät wie gewohnt angelegt, keine komunikation (klar, ist ja auch nicht erfolgreich paired)
nehm ich das gleiche system und haue nur die svn-version runter, ziehe danach wieder 5.5 drauf klappt es auf anhieb. natürlich wurde jedes mal der rt komplet resetet
Hej chris1284,
folgender Vorschlag: Ich muss heute ohnehin noch eine HM-Installation vorbereiten und dabei sind auch 4RTs zu pairen.
Ich schau mir das heute am Abend an und dann kann ich dann kann ich dir auch um einiges besser helfen.
Muss zuvor nur noch ein paar Weihnachtseinkäufe erledigen. ;-)
So... gerade eben noch ein Update gemacht und FHEM neu gestartet.
Im Anschluss die Batterien in den RT, schnell durchgegeklickt, bis 'Ins' erscheint, 'set myCUN hmPairForSec 20' in die Konsole gehämmert und den Boost-Button lang gedrückt.
Autocreate tut seinen Job, der ActionDetector wurde angelegt und der Sendemasten am RT ist ebenfalls da.
Hallo zusammen,
da es aktuell mit dem CUNO noch Schwierigkeiten gibt und ich noch einen CUL besitze habe ich dies für die Zeit bis zur Problem Behebung getauscht und fürs erste zwei RTs mit dem CUL gepairt.
Ich habe allerdings immer noch kein Kanal der "ClimRT_tr"!? Nach einem "getconfig" verändert sich das auch nicht!? Ich weiß nicht warum? Heißt der nur anders?
Hier mal die "list" noch dem RT. Mit meinem Anfängerauge betrachtet sollte, aber alles passen???
ZitatInternals:
CUL_1_MSGCNT 6
CUL_1_RAWMSG A0FA686102207330000000A80C310000148
CUL_1_RSSI -38
CUL_1_TIME 2013-12-24 01:06:46
DEF 220733
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 6
NAME CUL_HM_HM_CC_RT_DN_220733
NR 316
STATE CMDs_done
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_RT_DN_220733_Weather
channel_02 CUL_HM_HM_CC_RT_DN_220733_Climate
channel_03 CUL_HM_HM_CC_RT_DN_220733_WindowRec
channel_04 CUL_HM_HM_CC_RT_DN_220733_Clima
channel_05 CUL_HM_HM_CC_RT_DN_220733_ClimaTeam
channel_06 CUL_HM_HM_CC_RT_DN_220733_remote
lastMsg No:A6 - t:10 s:220733 d:000000 0A80C3100001
protLastRcv 2013-12-24 01:06:46
rssi_at_CUL_1 avg:-37.66 min:-38 max:-37.5 lst:-38 cnt:6
CHANGETIME:
Helper:
Dblog:
Activity:
Mydblog:
TIME 1387842798.12048
VALUE alive
Actuator:
Mydblog:
TIME 1387843606.25386
VALUE 0
Battery:
Mydblog:
TIME 1387843606.25386
VALUE ok
Batterylevel:
Mydblog:
TIME 1387843606.25386
VALUE 3.1 V
Desired-temp:
Mydblog:
TIME 1387843606.25386
VALUE 16
Measured-temp:
Mydblog:
TIME 1387843606.25386
VALUE 19.5
Readings:
2013-12-24 00:53:18 Activity alive
2013-12-24 00:51:41 CommandAccepted yes
2013-12-24 00:33:18 PairedTo 0xF11134
2013-12-23 18:10:30 R-backOnTime 10 s
2013-12-24 00:33:18 R-btnLock unlock
2013-12-24 00:33:18 R-burstRx off
2013-12-24 00:33:18 R-cyclicInfoMsg on
2013-12-24 00:33:18 R-cyclicInfoMsgDis 0
2013-12-24 00:33:18 R-globalBtnLock off
2013-12-24 00:33:18 R-localResDis off
2013-12-23 18:10:30 R-lowBatLimitRT 2.1 V
2013-12-24 00:33:18 R-modusBtnLock off
2013-12-24 00:33:18 R-pairCentral 0xF11134
2013-12-24 00:33:18 RegL_00: 01:00 02:01 09:01 0A:F1 0B:11 0C:34 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2013-12-24 01:06:46 actuator 0 %
2013-12-24 01:06:46 battery ok
2013-12-24 01:06:46 batteryLevel 3.1 V
2013-12-24 01:06:46 desired-temp 16
2013-12-24 01:06:46 measured-temp 19.5
2013-12-23 18:07:12 powerOn -
2013-12-23 18:07:12 recentStateType info
2013-12-24 00:51:42 state CMDs_done
2013-12-23 18:09:38 time-request -
Helper:
mId 0095
rxType 140
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_cul_1:
avg -37.6666666666667
cnt 6
lst -38
max -37.5
min -38
Attributes:
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room CUL_HM
serialNr KEQ0510374
subType thermostat
webCmd getConfig:burstXmit
Zitat von: holzwurm83 am 24 Dezember 2013, 01:19:06Ich habe allerdings immer noch kein Kanal der "ClimRT_tr"!? Nach einem "getconfig" verändert sich das auch nicht!? Ich weiß nicht warum? Heißt der nur anders?
Ja, der Kanal *ClimRT_tr heißt jetzt *Clima und der ist bei dir vorhanden. Auch sonst sieht alles gut aus. ;-)
Wichtig für ein erfolgreiches Pairing ist immer das Register: pairCentral und das ist bei dir befüllt.
Hej chris1284,
hab gerade eine neue Version eingecheckt. Sollte in der Früh zur Verfügung stehen.
Probier es doch bitte einmal damit. ;-)
so früh / spät noch unterwegs ;-)
habe das update eingespielt, folge: FHEM kommuniziert nicht mehr mit RT.
also rt zurück gesetzt. gerät aus fhem geschmissen (fhem.cfg, logs usw). danach war ein pairing sofort (<5sec) möglich. Gerät ist angelegt und es wird sich unterhalten.
Zitat von: chris1284 am 24 Dezember 2013, 08:35:34
so früh / spät noch unterwegs ;-)
Was sein muss, muss sein. ;-)
Zitat von: chris1284 am 24 Dezember 2013, 08:35:34habe das update eingespielt, folge: FHEM kommuniziert nicht mehr mit RT.
Tut nicht?
Zitat von: chris1284 am 24 Dezember 2013, 08:35:34
also rt zurück gesetzt. gerät aus fhem geschmissen (fhem.cfg, logs usw). danach war ein pairing sofort (<5sec) möglich. Gerät ist angelegt und es wird sich unterhalten.
Tut doch? Kann dir nicht ganz folgen. :-)
Hab gerade nochmal ein Gerät gepairt und dann auch die Temperatur über die Console eingestellt - hat alles funktioniert.
ZitatKann dir nicht ganz folgen. :-)
ja, funktioniert nun. musste nach dem update nur den rt nochmal neu paaren und dann ging alles wieder, temp-listen eingefügt, temps manuel gesetzt usw.
mal eine verständisfrage. warum taucht das gerät (rt) an sich als
Zitatthermostat
auf, aber alle channels die dazu gehören als
ZitatCUL_HM
. wäre es nicht sinvoller die mit unter dem thermostat zu listen?
des weiteren, ist der automatisch erstellte ActionDetector unter CUL_HM nur diesem thermostat zugeordnet?
sprich wenn ich den CUL_HM_HM_CC_RT_DN_xxxxxx der ordunghalber umbenne sollte der ActionDetector der zugehörigkeit halber auch umbenannt werden?
Hi Chris,
Ich bin kein Freund vom platten kopieren von Attributen. Das Device ist von subtype Thermostat - alle seine Channels nutzen diese Info. Ich weigere mich die liste der Attribute vom device in alle channels zu kopieren. Diese sind zwar alle auch für channels gültig (serien-nummer, FW version, ....) das macht die Liste unübersichtlich.
Wer will kann des gerne tun - macht nichts kaputt.
Ich sortiere meine entities gerne von hand. Es ist möglich im Attribut room eine liste zu hinterlegen - damit kann man Gruppen erzeugen
attr <entity1> room actor,licht,wohnzimmer
attr <entity2> room actor,licht,kinderzimmer
attr <entity3> room device,actor,rollo,kinderzimmer
attr <entity4> room device,actor,rollo,wohnzimmer
attr <entity5> room notify,heizung,wohnzimmer
Zitatdes weiteren, ist der automatisch erstellte ActionDetector unter CUL_HM nur diesem thermostat zugeordnet?
es ist nicht möglich, dass nur ein kanal tot ist - nur ein Device kann sterben -dann sind auch alle Channels tot. Wie verstehst du den ActionDetector?
Zitatsprich...
was hat dies mit der Frage oben zu tun?
Zitatwenn ich den CUL_HM_HM_CC_RT_DN_xxxxxx der ordunghalber umbenne sollte der ActionDetector der zugehörigkeit halber auch umbenannt werden?
einfach probieren - Probleme?
Gruss Martin
Hallo Martin,
ZitatWie verstehst du den ActionDetector?
noch nicht so richtig. Ich denke das er , wenn ich die dokus richtig deute, regelmäßig schaut ob ein gerät aktiv ist (welches die option actcycle hat).
in der doku steht
ZitatThis actiondetect will be autocreated for each device with build in cyclic status report.
Controlling entity is a pseudo device "ActionDetector" with HMId "000000".
(ich habe zur zeit nur ein gerät mit option actCycle sollte ich anmerken) Wird nun für jedes gerät (zb. 2. rt) ein 2. actiondetector angelegt oder wird das gerät nur im 1. mit eingetragen?
meiner sieht zur zeit so aus:
ZitatReadings
state alive:1 dead:0 unkn:0 off:0 2013-12-27 16:52:53
status_Buero.Heizung alive 2013-12-27 16:52:53
würde er mit 2 rts so aussehen
NAME ActionDetector
ZitatReadings
state alive:1 dead:0 unkn:0 off:0 2013-12-27 16:52:53
status_<2.erRT> alive 2013-12-27 16:52:53
oder würde es einen 2.ActionDetector geben?
Hallo Chris,
nun. der Status deuted es schon an, der ActionDetector überwacht mehrere devices (beliebig viele) auf Aktivität. Sinn ist zu erkennen, ob dieses noch lebt (also ob die Batterie leer ist oder nicht)
wenn ich von device rede ist es ein Gerät (wird von anderen entwicklern evtl. auch für Kanäle und Funktionen verwendet, hier nicht).
Den Text kann man falsch verstehen, geben ich dir recht.
Du kannst jedem Device das Attribut actCycle geben - dann prüft der Action detector einfach, ob in dem gegebenen Zeitraum auch eine message vom device gekommen ist. Wenn nicht ist es tot.
Einige devices melden sich regelmässig. Für diese wird das Attribut automatisch angelegt. Für alle anderen nicht - FHEM kann nicht garantieren, dass und in welchen Abstand diese reagieren sollen.
Wenn du es für andere einbaust solltest du einen 'poll' einbauen, der ggf eine Message zum Device schickt und aktiv prüft, ob es noch lebt.
mit dem 2. RT wurde es so aussehen
state alive:2 dead:0 unkn:0 off:0 2013-12-27 16:52:53
status_Buero.Heizung alive 2013-12-27 16:52:53
status_Kinder.Heizung alive 2013-12-27 16:52:53
Gruss Martin
hallo,
habe seit ca 24h bei meinem rt immer ein "MISSING ACK" als status. hier mal das filelog
Zitat2013-12-28_19:53:36 Buero.Heizung battery: ok
2013-12-28_19:53:36 Buero.Heizung batteryLevel: 3 V
2013-12-28_19:53:36 Buero.Heizung measured-temp: 16.7
2013-12-28_19:53:36 Buero.Heizung desired-temp: 16
2013-12-28_19:53:36 Buero.Heizung actuator: 0 %
2013-12-28_19:53:41 Buero.Heizung ResndFail
2013-12-28_19:53:41 Buero.Heizung MISSING ACK
und hier mal die internals
ZitatCFGFN ./FHEM/mycfg_02_device_thermostate.cfg
CUL_0_MSGCNT 13
CUL_0_RAWMSG A0FB086102222750000000A80A70F001050
CUL_0_RSSI -34
CUL_0_TIME 2013-12-28 20:06:25
DEF 222275
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 13
NAME Buero.Heizung
NR 61
STATE MISSING ACK
TYPE CUL_HM
channel_01 Buero.Heizung_Weather
channel_02 Buero.Heizung_Climate
channel_03 Buero.Heizung_WindowRec
channel_04 Buero.Heizung_Clima
channel_05 Buero.Heizung_ClimaTeam
channel_06 Buero.Heizung_remote
lastMsg No:B0 - t:10 s:222275 d:000000 0A80A70F0010
protCmdDel 20
protLastRcv 2013-12-28 20:06:25
protResnd 6 last_at:2013-12-28 19:51:38
protResndFail 2 last_at:2013-12-28 19:53:41
protSnd 8 last_at:2013-12-28 19:53:36
protState CMDs_done_Errors:1
rssi_at_CUL_0 avg:-33.23 min:-35.5 max:-32 lst:-34 cnt:13
das komische ist, er tut. ich kann temps setzen, die stati (tmp, motor usw) werden gelesen.
was hat das zu bedeuten bzw / wie bekomm ich es weg?
ZitatprotResndFail 2 last_at:2013-12-28 19:53:41
protCmdDel 20
der Fehler ist (zum 2. Mal) um 19:53:41 aufgetreten. Im zuge wurden wohl je 10 messages gelöscht/nicht ausgeführt
ZitatlastMsg No:B0 - t:10 s:222275 d:000000 0A80A70F0010
protLastRcv 2013-12-28 20:06:25
Diese Nachricht ist die regelmässige - um 20:06:25 empfangen
ZitatprotSnd 8 last_at:2013-12-28 19:53:36
Es wurden 8 messages gesendet - 2 waren fehlerhaft somit 6 erfolgreich
ZitatprotResnd 6 last_at:2013-12-28 19:51:38
es gab 6 Wiederholversuche - das waren wohl 3 versuche je message, dann wegen überschreitung der max wiederholungen gestoppt
ZitatprotState CMDs_done_Errors:1
der letzte Block war fehlerhaft
Was alles ausgeführt werden sollte ist unklar, da ich nicht weiss, welches kommando du eingegben hast. Evtl wollte FHEM noch einen status oder register abfragen um diese korrekt darzustellen.
Ggf zeichne die rohmessages auf
Gruss Martin
es ist zum mäusemelken mit fhem ...
ich habe den rt nochmal entfernt, am rt einen reset durchgeführt, am rt die batterien für ein paar minuten entfernt. habe dann das jungfräuliche fhem gestartet (aktuelle version) und wollte ihn wieder paaren. gleiches problem wie vor ein paar tagen (fhem ist wohlgemerkt heute neu installiert und up-to-date ):
Zitatset CUL_0 hmPairForSec 20
2013.12.29 09:14:27 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_222275, please define it
2013.12.29 09:14:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_222275 CUL_HM 222275 A1A0184002222750000001000954B4551303531343330345900FFFF
2013.12.29 09:14:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_222275 FileLog ./log/CUL_HM_HM_CC_RT_DN_222275-%Y.log CUL_HM_HM_CC_RT_DN_222275
Gerät wir nicht richtig angelegt
für ich danach nochmal einen
Zitatset CUL_0 hmPairForSec 200
aus kommt erst der rest....
Zitat2013.12.29 09:22:32 2: autocreate: define ActionDetector CUL_HM 000000
2013.12.29 09:22:32 2: autocreate: define FileLog_ActionDetector FileLog ./log/ActionDetector-%Y.log ActionDetector
2013.12.29 09:22:32 3: Device CUL_HM_HM_CC_RT_DN_222275 added to ActionDetector with 000:10 time
2013.12.29 09:22:32 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_222275 thermostat, model HM-CC-RT-DN serialNr KEQ0514304
2013.12.29 09:22:32 2: CUL_HM set CUL_HM_HM_CC_RT_DN_222275 getConfig
2013.12.29 09:22:33 2: autocreate: define CUL_HM_HM_CC_RT_DN_222275_Weather CUL_HM 22227501
2013.12.29 09:22:33 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_222275_Weather FileLog ./log/CUL_HM_HM_CC_RT_DN_222275_Weather-%Y.log CUL_HM_HM_CC_RT_DN_222275_Weather
2013.12.29 09:22:34 2: autocreate: define CUL_HM_HM_CC_RT_DN_222275_Climate CUL_HM 22227502
2013.12.29 09:22:34 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_222275_Climate FileLog ./log/CUL_HM_HM_CC_RT_DN_222275_Climate-%Y.log CUL_HM_HM_CC_RT_DN_222275_Climate
2013.12.29 09:22:35 2: autocreate: define CUL_HM_HM_CC_RT_DN_222275_WindowRec CUL_HM 22227503
2013.12.29 09:22:35 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_222275_WindowRec FileLog ./log/CUL_HM_HM_CC_RT_DN_222275_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_222275_WindowRec
2013.12.29 09:22:36 2: autocreate: define CUL_HM_HM_CC_RT_DN_222275_Clima CUL_HM 22227504
2013.12.29 09:22:36 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_222275_Clima FileLog ./log/CUL_HM_HM_CC_RT_DN_222275_Clima-%Y.log CUL_HM_HM_CC_RT_DN_222275_Clima
2013.12.29 09:22:37 2: autocreate: define CUL_HM_HM_CC_RT_DN_222275_ClimaTeam CUL_HM 22227505
2013.12.29 09:22:37 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_222275_ClimaTeam FileLog ./log/CUL_HM_HM_CC_RT_DN_222275_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_222275_ClimaTeam
2013.12.29 09:22:38 2: autocreate: define CUL_HM_HM_CC_RT_DN_222275_remote CUL_HM 22227506
2013.12.29 09:22:38 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_222275_remote FileLog ./log/CUL_HM_HM_CC_RT_DN_222275_remote-%Y.log CUL_HM_HM_CC_RT_DN_222275_remote
2013.12.29 09:24:30 2: CUL_HM set CUL_HM_HM_CC_RT_DN_222275_Climate getConfig
#halbe stunde später
es sind unter keinem kanal alle optionen gelistet. beim Clima fehlt nun zb die tmpList.
erst nach einem schutdown restart habe ich beim CUL_HM_HM_CC_RT_DN_222275 CUL_HM 222275 getConfig und burstXmit
der actiondetector geht mittlerweile auf alive:0 dead:0 unkn:1 off:0
#1 stunde später
habe nun wieder die 5.5.deb installiert. siehe da, ohne nochmal den rt zu reseten sofortiges paaren möglich.
Hallo Chris
ZitatGerät wir nicht richtig angelegt
woran siehst du dies? Ist PairedTo korrekt gesetzt?
Zum debuggen immer die rohmessages aufgezeichnen
Zitatfür ich danach nochmal einen
set CUL_0 hmPairForSec 200
aus kommt erst der rest....
hmPairForSec 200 setzt deine CUL in bereitschafft, nach anlernbereiten devices ausschau zu halten. Nach 200sec ist schluss. Es passiert also garnichts? hast du noch einmal anlernen gedrückt?
Zitaterst nach einem schutdown restart habe ich beim CUL_HM_HM_CC_RT_DN_222275 CUL_HM 222275 getConfig und burstXmit
sollte nicht sein. Die kommandos werden immer frisch zusammengebaut. Wie stehen die Attribute des Device und des channel?
Zitatder actiondetector geht mittlerweile auf alive:0 dead:0 unkn:1 off:0
der RT hat ~10min zeit sich zu melden - so lange ist er unknown. Danach entweder dead oder alive
Gruss Martin
Hallo Zusammen,
ich beschäftige mich seid ca. 2 Wochen mit FHEM und den Komponenten siehe Signatur.
Das Forum und die Wiki hat mir schon viel weitergeholfen jedoch bin ich jetzt an einem Punkt dessen Verhalten ich mir nicht erklären kann.
Ich möchte die 3 Thermostate im Wohnzimmer miteinander in FHEM peeren um diese synchron zu nutzen.
Dazu habe ich folgenden Befehle genutzt:
set CUL_HM_HM_CC_RT_DN_232501_ClimaTeam peerChan 0 CUL_HM_HM_CC_RT_DN_22E5D5_ClimaTeam single
set CUL_HM_HM_CC_RT_DN_232501_ClimaTeam peerChan 0 CUL_HM_HM_CC_RT_DN_22DF54_ClimaTeam single
set CUL_HM_HM_CC_RT_DN_22E5D5_ClimaTeam peerChan 0 CUL_HM_HM_CC_RT_DN_22DF54_ClimaTeam single
Die Peerings sind auch aus meiner Sicht richtig in den einzelnen Kanälen eingetragen. Jedoch Synchronisieren sich die einzelnen Thermostate nicht.
Wenn ich diese jedoch manuell (ohne FHEM) untereinander peere und dann zu FHEM paire funktioniert die Steuerung.
Könnt Ihr mir weiterhelfen. Ich würde die Thermostate natürlich gern über die peerChan mittels FHEM peeren.
Mfg neph
Hallo neph,
ich hatte einmal ein ähnliches Problem - das ich aber auch durch direktes peeren nicht lösen konnte. Da ich aber mittlerweile das synchen aus verschiedenen Gründen eh anders mache ist es weit hinter gerutscht.
Kannst du die Aktionen einmal loggen?
Loggen einschalten gemäß
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
das direkte peeren ist interessant - falls du es noch einmal wiederholen könntest.
Zusammen mit einem list des channels 4 und 5 des RT
Danke
Martin
Hallo Martin,
das direkte peering mache ich gern noch einmal. Dazu hatte ich jedoch meinen HM Stick nicht an der Firtz Box. So mit angeschlossen Stick ging es einfach nicht. Dann kann ich jedoch nichts loggen!
OK das mit dem loggen habe ich noch nicht ganz verstanden. Wo müssen den die einträge hin in die fhem.cfg oder wo.
Edit: Ok die eintragungen kommen in die fhem.cfg oder über die Konsole oben sorry.
Wie mache in den ein list der Kanäle 4 und 5?
Ich versuche es jedoch bis zu deiner antwort über das Forum herauszufinden.
Es wäre nett von dir das schritt für schritt mit mir durchzugehen. Damit du die Daten bekommst die du brauchst.
Die Materie ist noch etwas zu komplex für mich.
fhem logt in das zentrale logfile.
Du kannst die Level mit dem Attribut verbose einstellen
attr global verbose 3
ist default - alle entites ohne "verbose" sind auf level 3
Rohmessages logt man (bei HM) mit
attr global verbose 1 # abschalten aller 'anderen' logs wegen der Übersichtlichkeit
attr global mseclog 1 #einschalten der milisec auflösung der Zeitstempel
attr <hmlan> all,sys # setzt den verbose level den HMLAN gezielt mit speziellen Filtern
dann im Logfile nachsehen.
Ein list einer Entity machst du im kommando-textfeld (oben im webfenster) mit
list <entity_kanal04>
Gruss Martin
Hallo Martin,
anbei die entsprechende Log File. Ich hoffe alles richtig gemacht zu haben.
Das mit dem List muss noch warten ich habe jetz bei pairing permanent pending stehen und die Thermostate werden nicht gepairt.
hi nephdrasil,
hast du beim 232501 das Attribut burstAccess gesetzt? Und das Register burstRx nicht? Da werden jede Menge "wach-auf" Burst gesendet. Da es nicht antwortet wird HMLAN sehr beansprucht und geht bereits in HighLoad!
burstRx ist gesetzt in
22DF54
22E5D5
aber wohl nicht in
232501
Der 232501 kann nicht aufgeweckt werden - wird demnach auch keine Messages der anderen RTs entgegen nehmen
Gruss Martin
Hallo Martin,
so habe jetzt nocheinmal alles durchgespielt und neu eingestellt jetzt funzt es.
anbei die neuen Dateien. Ich hoffe alles mitgelogt zu haben.
Damit du die peering siehst musste ich zusätzlich zum getConfig noch ein getRegRaw machen wieso keine Ahnung.
ohne getRegRaw
Internals:
CFGFN
DEF 22DF5404
LASTInputDev hmusb
MSGCNT 6
NAME CUL_HM_HM_CC_RT_DN_22DF54_Clima
NR 81
STATE T: 22.2 desired: 20 valve: 0 %
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_CC_RT_DN_22DF54
hmusb_MSGCNT 6
hmusb_RAWMSG E22DF54,0000,000BCD5F,FF,FFCF,18861022DF540000000AA0DE0F0026
hmusb_RSSI -49
hmusb_TIME 2013-12-29 19:12:39
Readings:
2013-12-29 19:07:46 R-boostPeriod 5 min
2013-12-29 19:07:46 R-boostPos 80 %
2013-12-29 19:07:46 R-btnNoBckLight off
2013-12-29 19:07:46 R-dayTemp 20 C
2013-12-29 19:07:46 R-daylightSaveTime on
2013-12-29 19:07:46 R-decalcTime 11:00
2013-12-29 19:07:46 R-decalcWeekday Sat
2013-12-29 19:07:46 R-modePrioManu all
2013-12-29 19:07:46 R-modePrioParty all
2013-12-29 19:07:46 R-nightTemp 15 C
2013-12-29 19:07:46 R-noMinMax4Manu off
2013-12-29 19:07:46 R-regAdaptive on
2013-12-29 19:07:46 R-reguExtI 15
2013-12-29 19:07:46 R-reguExtP 30
2013-12-29 19:07:46 R-reguExtPstart 30
2013-12-29 19:07:46 R-reguIntI 15
2013-12-29 19:07:46 R-reguIntP 30
2013-12-29 19:07:46 R-reguIntPstart 30
2013-12-29 19:07:46 R-showInfo time
2013-12-29 19:07:46 R-showWeekday off
2013-12-29 19:07:41 R-sign off
2013-12-29 19:07:46 R-tempMax 30.5 C
2013-12-29 19:07:46 R-tempMin 4.5 C
2013-12-29 19:07:46 R-tempOffset 0.0K
2013-12-29 19:07:46 R-valveErrPos 15 %
2013-12-29 19:07:46 R-valveMaxPos 100 %
2013-12-29 19:07:46 R-valveOffsetRt 0 %
2013-12-29 19:07:46 R-winOpnBoost off
2013-12-29 19:07:46 R-winOpnDetFall 1.4 K
2013-12-29 19:07:46 R-winOpnMode on
2013-12-29 19:07:46 R-winOpnPeriod 15 min
2013-12-29 19:07:46 R-winOpnTemp 12 C
2013-12-29 19:11:54 RegL_01: 08:00 00:00
2013-12-29 19:11:58 RegL_07: 01:28 02:1E 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:3C 15:60 16:50 17:F0 18:3D 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:3C 2F:60 30:50 31:F0 32:3D 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:3C 49:5A 4A:50 4B:F0 4C:3D 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:3C 63:5A 64:50 65:F0 66:3D 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:3C 7D:5A 7E:50 7F:F0 80:3D 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:3C 97:5A 98:50 99:F0 9A:3D 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:3C B1:5A B2:50 B3:F0 B4:3D B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
2013-12-29 19:12:39 ValvePosition 0 %
2013-12-29 19:12:39 desired-temp 20
2013-12-29 19:12:39 measured-temp 22.2
2013-12-29 19:12:39 mode auto
2013-12-29 19:12:39 motorErr ok
2013-12-29 19:12:39 state T: 22.2 desired: 20 valve: 0 %
2013-12-29 19:11:58 tempListFri 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListMon 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListSat 08:00 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListSun 08:00 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListThu 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListTue 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListWed 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempList_State verified
Helper:
getCfgListNo
Role:
chn 1
Shadowreg:
Attributes:
expert
model HM-CC-RT-DN
peerIDs
room CUL_HM
mit getRegRaw
Internals:
CFGFN
DEF 22DF5404
LASTInputDev hmusb
MSGCNT 10
NAME CUL_HM_HM_CC_RT_DN_22DF54_Clima
NR 81
STATE T: 22.0 desired: 20 valve: 0 %
TYPE CUL_HM
chanNo 04
device CUL_HM_HM_CC_RT_DN_22DF54
hmusb_MSGCNT 10
hmusb_RAWMSG E22DF54,0000,001268C7,FF,FFCF,1B861022DF540000000AA0DC0F0026
hmusb_RSSI -49
hmusb_TIME 2013-12-29 19:19:51
peerList CUL_HM_HM_CC_RT_DN_22E5D5_ClimaTeam,CUL_HM_HM_CC_RT_DN_232501_ClimaTeam,
Readings:
2013-12-29 19:07:46 R-boostPeriod 5 min
2013-12-29 19:07:46 R-boostPos 80 %
2013-12-29 19:07:46 R-btnNoBckLight off
2013-12-29 19:07:46 R-dayTemp 20 C
2013-12-29 19:07:46 R-daylightSaveTime on
2013-12-29 19:07:46 R-decalcTime 11:00
2013-12-29 19:07:46 R-decalcWeekday Sat
2013-12-29 19:07:46 R-modePrioManu all
2013-12-29 19:07:46 R-modePrioParty all
2013-12-29 19:07:46 R-nightTemp 15 C
2013-12-29 19:07:46 R-noMinMax4Manu off
2013-12-29 19:07:46 R-regAdaptive on
2013-12-29 19:07:46 R-reguExtI 15
2013-12-29 19:07:46 R-reguExtP 30
2013-12-29 19:07:46 R-reguExtPstart 30
2013-12-29 19:07:46 R-reguIntI 15
2013-12-29 19:07:46 R-reguIntP 30
2013-12-29 19:07:46 R-reguIntPstart 30
2013-12-29 19:07:46 R-showInfo time
2013-12-29 19:07:46 R-showWeekday off
2013-12-29 19:07:41 R-sign off
2013-12-29 19:07:46 R-tempMax 30.5 C
2013-12-29 19:07:46 R-tempMin 4.5 C
2013-12-29 19:07:46 R-tempOffset 0.0K
2013-12-29 19:07:46 R-valveErrPos 15 %
2013-12-29 19:07:46 R-valveMaxPos 100 %
2013-12-29 19:07:46 R-valveOffsetRt 0 %
2013-12-29 19:07:46 R-winOpnBoost off
2013-12-29 19:07:46 R-winOpnDetFall 1.4 K
2013-12-29 19:07:46 R-winOpnMode on
2013-12-29 19:07:46 R-winOpnPeriod 15 min
2013-12-29 19:07:46 R-winOpnTemp 12 C
2013-12-29 19:17:49 RegL_01: 08:00 00:00
2013-12-29 19:11:58 RegL_07: 01:28 02:1E 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:3C 15:60 16:50 17:F0 18:3D 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:3C 2F:60 30:50 31:F0 32:3D 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:3C 49:5A 4A:50 4B:F0 4C:3D 4D:20 4E:45 4F:20 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:3C 63:5A 64:50 65:F0 66:3D 67:20 68:45 69:20 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:3C 7D:5A 7E:50 7F:F0 80:3D 81:20 82:45 83:20 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:3C 97:5A 98:50 99:F0 9A:3D 9B:20 9C:45 9D:20 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:3C B1:5A B2:50 B3:F0 B4:3D B5:20 B6:45 B7:20 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
2013-12-29 19:19:51 ValvePosition 0 %
2013-12-29 19:19:51 desired-temp 20
2013-12-29 19:19:51 measured-temp 22.0
2013-12-29 19:19:51 mode auto
2013-12-29 19:19:51 motorErr ok
2013-12-29 19:18:32 peerList CUL_HM_HM_CC_RT_DN_22E5D5_ClimaTeam,CUL_HM_HM_CC_RT_DN_232501_ClimaTeam,
2013-12-29 19:19:51 state T: 22.0 desired: 20 valve: 0 %
2013-12-29 19:11:58 tempListFri 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListMon 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListSat 08:00 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListSun 08:00 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListThu 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListTue 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempListWed 07:30 15.0 20:00 20.0 24:00 15.0
2013-12-29 19:11:58 tempList_State verified
Helper:
peerIDsRaw ,23250105,22E5D505,00000000
Role:
chn 1
Shadowreg:
Attributes:
expert
model HM-CC-RT-DN
peerIDs 00000000,22E5D505,23250105,
room CUL_HM
Ist das alles was du brauchst? Kannst du mir sagen wieso das über peerChan nicht funktioniert.
ich vermute, dass das Register burstRx nicht korrekt gesetzt wurde. Dann sind die Devices gepeert, aber sie wachen ggf nicht auf
Wie kann ich die Register setzen?
set <Name> regset brustRx on
Edit: die Änderungen kann ich jedoch am stellrad vornehmen und sie werden übernommen.
Besteht da problem mit den Fehelenden Registern immer noch. Es funktioniert doch augenscheinlich alles.
Wie sehe ich das die Register nicht richtig gesetzt sind.
Hi,
Die Register sind bei deinen 3 RTs wohl gesetzt. Die wachen ja auf und beantworten die Änderung.
Der Log war vom funktionierenden Ablauf - oder muss ich einen Fehler suche?
An stellrad kann am immer ändern - nur beim aufwecken über die Luft, also den peer - das ist ein Problem
Gruss Martin
Nein du musst keinen Fehler suchen.
Die ursprüngliche Frage war. Wieso das peering über FHEM per peerchan nicht funktioniert. Aber manuel geht es.
DIe Log mit dem jetzigen durchlauf hänge ich nocheinmal an, DU wolltest ja das Logging für das manuelle Peering direkt nur mit den Thermostaten.
Sorry für die falsche Datei.
Danke für deine Mühen
Hi,
ganz bin ich nicht hinter das team-pairen gekommen.
Ich kann meine pairen - die Übertragung geht aber immer nur von A nach B, aber nicht von B nach A.
Der eine will seine Daten einfach nicht senden.
Gruss Martin
Hallo Zusammen,
ich habe in der Vergangenheit schon mehrmals beobachten müssen, dass das Senden eines Befehls an einen RT zum "Aufhänger" führt:
"CMDs_pending" geht in "CMDs_processing..." und anschließend wieder in "CMDs_pending". Das ganze wiederholt sich endlos (zumindest mehrere Stunden).
Löschen der "hängenden" Befehle set <device> clear msgEvents nutzt nichts. Beim nächsten Befehl tritt das Problem dann an diesem RT wieder auf.
Das einzige was dann hilft ist: Batterien am RT raus. Danach funktioniert er wieder.
Aktuell habe ich wieder einen "hängenden" RT. Der "Hänger" tritt aktuell wieder seit 04:37 auf, wo ich per at mit set Hzkp_.* regSet btnLock lock alle RTs sperre. Bei allen, bis auf einem, hat das auch funktioniert. Und dieser eine RT hat in der Vergangenheit hier auch noch keine Probleme gemacht.
Ich habe mal ein Log beigefügt. Der betroffene RT hat die ID 21CDC5.
Da diese Problem schon öfters, bei verschiedenen RTs bei jeweils verschiedenen Befehlen aufgetreten ist, wäre es nett, die Ursache zu fixen.
Viele Grüße
Christoph
Hi Christoph,
ich denke in der neusten Version sollte es nicht mehr passieren. sollte in den letzten Tagen gefixt worden sein.
Melde dich, wenn es noch einmal auftritt.
Grund war zumindest eine fehlgeschlagene message. Die kann immer auftreten - hängt evtl von deinem System ab
Gruss Martin
Hallo Martin,
vielleicht hilft dieser hinweis. Bei dem peering der Kanäle musste ich das für jeden einzelnes Thermostat machen ansonsten wollten diese nicht zusammenarbeiten.
Also Thermostat 1 zu 2
Thermostat 2 zu 1
Thermostat 3 zu 2
Thermostat 2 zu 3
Thermostat 3 zu 1
Thermostat 1 zu 3
Leider kann ich dir nicht wirklich weiterhelfen bin noch ein Noob.
Mfg nepg
Hi nepg,
schon klar, dass jeder mit jedem gepeert werden muss. Zum einen muss er auf die Kameraden hören, wenn etwas kommt und zum anderen muss er an alle senden, wenn er etwas weiss.
Vielen Dank für den Hinweis.
Dass ich den Unterschied nicht finde ist ärgerlich. Aber ich werden weiter mit dem notify arbeiten, da es sowieso kompletter ist. das team syncht 'nur' das Drehen des Handrades - kein Wochenprogramm, kein stellen der Zentrale, keine mode Verstellung
Gruss Martin
Irgendwie fehlt mir beim letzten Thermostat die Einstellung der Temperatur.
Woran kanns liegen?
schau dir die Attribute des CLIMA_TR an - fehlen da welche?
machen ein
set <dev>Clima_tr ?
kommen bei allen die gleichen Optionen?
Hallo Martin,
ich habe wieder einen Hänger: CMD_pending -> CMD_processing... -> CMD_pending -> usw.
Der Fehler ist wie folgt nachstellbar:
1) alle RTs sind gesperrt und alle Register sind vollständig gelesen
2) ich entsperre (mind.) einen RT per "set Hzkp_Kueche regSet btnLock unlock" oder manuell direkt am Gerät
3) ich sperre alle RTs mit "set Hzkp_.* regSet btnLock lock"
4) der Befehl bleibt wie dann oben beschrieben hängen; dies betrifft dann alle vorher entsperrten Geräte; am jeweiligen Gerät sieht man, dass der Befehl angekommen ist; die Bestätigung kommt hier aber in FHEM nie an -> Hänger
Sperre ich aber nur gezielt einen RT mit "set Hzkp_Kueche regSet btnLock lock" geht der Befehl durch.
Ist das ein Software- oder ein Firmware-Bug?
Viele Grüße
Christoph
Nachtrag: Mit "set Hzkp_.* regSet btnLock lock" geht der Befehl ja auch an alle Channels. Vielleicht verschluckt sich hier der RT.
Hallo Christoph,
ich denke, was passiert ist folgendes:
- du sendest ein Kommando - kommt in den Stack
Der RT wacht auf, FHEM sendet => CMDs processing
der RT antwortet nicht - etwas an der Message oder Übertragung ist faul. Kommando wird wieder zurückgehängt, damit es wiederhohlt werden kann. => CMDs pending
der RH wacht wieder auf.......
das Kommando wird 3 mal wiederholt - das dauert demnach ~7-10 min - je kommando.
Sieht es so aus? Nimmt die Anzahl der pending commands langsam ab?
Du kannst das Attribut msgRepeat auf '0' setzen, dann wird eine Message nur einmal gesendet. Es ist das Dilemma des wiederholens - macht es sinn
Eine 2. Frage ist, warum wiederholt werden muss. Kannstu du mitloggen und erklären, was du sendest - ggf das zugehörige setting/peering
Gruss Martin
Zitat von: martinp876 am 06 Januar 2014, 14:18:05
schau dir die Attribute des CLIMA_TR an - fehlen da welche?
machen ein
set <dev>Clima_tr ?
kommen bei allen die gleichen Optionen?
finde irgendwie keinen Fehler.
Kann ich das Device noch mal löschen und neu einlesen?
Zitat von: martinp876 am 07 Januar 2014, 19:52:00
das Kommando wird 3 mal wiederholt - das dauert demnach ~7-10 min - je kommando.
Sieht es so aus? Nimmt die Anzahl der pending commands langsam ab?
Das ist definitiv nicht der Fall. In meinem beschriebenem Fall nehmen die Pendings nicht ab. Ich muss die Messages dann irgendwann händisch löschen. Die längste Zeitspanne, wo ich den beschriebenen Hänger beobachtet hatte (Zeit zwischen erst- und einmaligem Abschicken des Befehls und finalem manuellen Löschen), waren ca. 18 Stunden.
zeige doch einmal was gesendet werden soll. machen ein "list" auf das device und schicken die daten (speziell den kommandstack)
Hallo
Habe heute mal Fhem geupdatet jetzt kann ich keine temperaturen mehr verstellen auf der Web oberfläche.
anbei ein Bild, vorhher war hinten die auswahlbo für die Solltemperatur.
Gruß Josty
Hallo!
Zitat von: jostmario am 08 Januar 2014, 18:42:35
Habe heute mal Fhem geupdatet jetzt kann ich keine temperaturen mehr verstellen auf der Web oberfläche.
Ich habe gestern mal ein update gemacht:
# $Id: fhem.pl 4565 2014-01-05 22:17:37Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4573 2014-01-06 13:41:57Z martinp876 $
# $Id: 01_FHEMWEB.pm 4566 2014-01-05 22:19:11Z rudolfkoenig $
# $Id: 92_FileLog.pm 4574 2014-01-06 14:12:42Z rudolfkoenig $
# $Id: 00_HMLAN.pm 4562 2014-01-05 15:22:54Z martinp876 $
# $Id: 30_HUEBridge.pm 4418 2013-12-19 17:21:19Z justme1968 $
# $Id: 31_HUEDevice.pm 4569 2014-01-06 00:43:57Z justme1968 $
# $Id: 98_PID.pm 3988 2013-11-01 09:20:26Z john $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 98_SVG.pm 4503 2013-12-29 18:38:50Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 90_at.pm 4246 2013-11-18 20:35:20Z rudolfkoenig $
# $Id: 98_autocreate.pm 4234 2013-11-17 10:19:41Z rudolfkoenig $
# $Id: 98_dewpoint.pm 3832 2013-09-01 18:45:32Z wherzig $
# $Id: 98_dummy.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 91_notify.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_telnet.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $Damit ist die Auswahl noch da und das Temp-Ändern geht funktioniert auch.
Evtl. mal Style ändern, Browser-Reload, shutdown-restart oder anderen Browser probieren?
Ich hatte mal so einen eigenartigen Effekt (neuer Raum wollte nicht auftauchen) nach Änderungen, weil der Browser irgendwas noch im Cache hatte.
HTH
Herr 3x
Hallo
hab das Update jetzt nochmal durchlaufen lassen per Telnet Console
Da steht am Ende
2014-01-08 19:56:09 Global global backup tar: ./log/Heizung_Bad_Oben-2014.log: file changed as we read it
2014-01-08 19:56:09 Global global backup done: FHEM-20140108_195315.tar.gz (24162326 Bytes)
2014-01-08 19:56:09 Global global update Can't write ./FHEM/00_HMLAN.pm: Permission denied
2014-01-08 19:56:09 Global global update Can't write ./FHEM/HMConfig.pm: Permission denied
2014-01-08 19:56:09 Global global update No files have been updated because one or more errors have occurred!
Könntest du dir das evtl mal per Teamviewer Anschauen
kann es an den fehlermeldungen beim Update liegen ?
Gruß Josty
Hallo Josty,
ich habe keine Ahnung, warum das Update nicht klappt.
Doch, was ich zuerst schauen würde: Ist noch Speicher frei?
Herr 3x
Hallo
Ja ist ne 8 GB Karte.
Hab den fehler aber gefunden.
es waren wohl Schreibrechte vom fhem verzeichnis.
Da ich von Linux kein Plan habe, hat mich das 2 std Google gekostet :-( .
letzendlich war es dieser befehl: sudo chmod -R a+w fhem
dann nochmal Update dann lief wieder alles wie gehabt.
Trotzdem Danke,
Gruß Josty
Hallo liebes Forum,
bin noch relativ neu im Thema FHEM. Habe allerdings die PDF's zu FHEM und Homematic mittlerweile durch.
Pairing und Sollwerforgabe an das HM-CC-RT-DN via CUL auf Raspberry Pi funktionieren.
Nun würde ich gerne im Web-Frontend die Solltemperatur über einen Slider einstellen. Es wäre schön wenn man diesen auf 15 bis 25°C begrenzen könnte.
Habe mittlerweile den ganzen Thread durch und auch diverse Seiten mir im Web zum Thema Slider bei Jalousie & Dimmer angesehen. Aber leider funktioniert das hier alles nicht. Habt Ihr vielleicht eine Lösung?
Wäre sehr nett, wenn mir jemand helfen könnte.
Danke
Hallo Jon_realdesign,
{$HMConfig::culHmChanSets{"HM-CC-RT-DN04"}{"desired-temp"}="[on|off|15..25]"}
In Perl und FHEM kann man alles verändern... das sind bereits "internas". Bei Veränderungen dieser Art erlischt natürlich die Garantie ;)
Will sagen - es sollte gehen. Ist kein dokumentiertes Feature - eventuelle Fehler muss der User auf diesem Level selbst korrigieren.
Des ändert nicht den Möglichen eingabebereich, der wird nicht aus diesem String abgeleitet
Gruss Martin
Danke Martin für die schnelle Antwort.
Mache mir erst ein BackUp von der HMconfig.pm und werde es dann testen. Die Zeile gehört doch selbst in die fhem.cfg?
Habe momentan eine andere Variante getestet, welche aber noch nicht ganz optimal ist:
define TempChange dummy
attr TempChange room Arbeitszimmer
attr TempChange setList state:slider,15,1,25
attr TempChange webCmd state
define AZ_TemperaturChange notify TempChange set AZ_Heizung_ClimRT desired-temp %
Habe den Code nochmal modifiziert, um nach einem Restart den zuletzt gespeicherten Wert zu benutzen. Leider funktioniert es noch nicht. Hat da evtl. jemand eine Idee?
define TempChange dummy
attr TempChange room Arbeitszimmer
attr TempChange setList state:slider,15,1,25
attr TempChange webCmd state
define AZ_TemperaturChange notify (TempChange|global:INITIALIZED|global:REREADCFG) set AZ_Heizung_ClimRT desired-temp {ReadingsVal("TempChange","state","17.0")}
Hallo Jon_realdesign,
ZitatDie Zeile gehört doch selbst in die fhem.cfg?
ja/nein. Eigentlich schon, aber save löscht alles ausser comment, define und attr. Also keine gute Idee. Besser du schreibst ein eigenes File und lässt es ausführen.
Ich habe mir erst einmal ein directory setup gemacht, damit ich meine settings speichern kann (da kommen noch ein paar mehr zusammen).
Dass es ausgeführt wird (file fhemUserCfg.cfg im setup directory)
Zitatdefine userCfg notify global:INITIALIZED include setup/fhemUserCfg.cfg
in diesem File kannst du es dann hinterlegen - und es wird nicht gelöscht.
attr TempChange setList state:slider,15,1,25Space separated list of commands.... siehe commandref!!!
Options mit ':'
attr TempChange setList state slider:15,1,25was soll das webCmd 'state' machen? Welchen state soll es setzen?
Gruss Martin
Hallo Martin,
Danke für die INfos. Habe inzwischen folgendes erreicht
(http://d:%5CFHEM01.gif)
Hallo Martin,
Danke für die Infos. Habe inzwischen Folgendes erreicht.
(1)
Folgenden Code von Dir habe ich in ein separates File unter setup/fhemUserCfg.cfg kopiert.
{$HMConfig::culHmChanSets{"HM-CC-RT-DN04"}{"desired-temp"}="[on|off|15..25]"}
Dieses lasse ich durch die "fhem.cfg" ausführen analog deiner Beschreibung. Das Ausführen kappt auch, was man daran erkennen kann, das sich die Dropdown-Auswahlmöglichkeit für den Sollwert ändert. Allerdings habe dann immer noch eine Dropdownliste und nicht den gewünschten Schieberegler (Slider)!
(2)
Parallel habe ich an dem Ansatz mit einem Dummy-Objekt und einem Notify gearbeitet. Hierzu habe ich folgenden Script benutzt.
define AZ_Temperatur dummy
attr AZ_Temperatur room Arbeitszimmer
attr AZ_Temperatur setList state:slider,15,1,25
attr AZ_Temperatur webCmd state
define AZ_TemperaturChange notify AZ_Temperatur set AZ_Heizung_ClimRT desired-temp %
Dann bekomme ich einen Slider, mit dem ich den Sollwert ändern kann. Das sieht dann so aus, wie in dem angehängten Bild zu sehen.
Mein Problem ist aber jetzt immer noch, dass ich den eingestellten Sollwert aus dem Thermostat nicht rücklesen und an den Slider (=Dummy) senden kann. Damit meine ich inbesondere, wenn man über das Wahlrad am Thermostat die Temperatur manuell verändert, dann erscheint dieser Wert nicht am Slider. Das gleiche Problem besteht auch beim Neustarten des FHEM-Servers.
Das Reading 'desired-temp' existiert ja unter den Device-Readings. Dieses müsste man zyklisch oder nur nach Veränderung an den Slider (=Dummy) schicken. Hättest Du hierfür eine Idee? Oder bin evtl völlig auf dem Holzweg und es gibt eine viel einfachere Lösung?
Viele Grüße
Joachim
P.S.:
Zu deiner Frage nach dem "webCmd state':
Das hatte ich aus der CommandRef. Siehe hierzu folgenden Ausschnitt:
Zitat
webCmd
...
if the modifier is of the form ":slider,<min>,<step>,<max>", then a javascript driven slider is displayed
...
If the command is state, then the value will be used as a command.
...
define d2 dummy
attr d2 webCmd state
attr d2 setList state:slider,0,1,10
...
nun, du kannst ein notify auf das desired-temp machen und abfangen, wenn sich dies ändert. Dann musst du deinen dummy ändern. Dort musst du wohl den state setzen, entsprechend dem wert.
Zyklisch abfragen macht m.E. keinen Sinn.
Moin,
ich hab gestern einen zweiten Regler in Betrieb genommen. Der RT_tr Kanal heißt jetzt aber nur noch Clima richtig? Ich habe burst aktiviert aber dennoch hatte ich Probleme die Temp Listen einzuspielen. Immer alles schön nacheinander, den Sonntag aber ich immer noch nicht rein bekommen :-( Den Offset bekomme ich auch nicht gesetzt. Noch Ideen? Nochmal neu pairen? Aber ich meine scheinbar sieht ja alles gut aus. Ein Boost wird auch sofort angenommen und ausgeführt.
PairedTo 0x23FF23
R-pairCentral 0x23FF23
R-burstRx on
2014.01.31 07:37:49 2: CUL_HM set az_Heizung_Clima tempListSun 09:00 17.0 23:00 19.0 24:00 17.0
2014.01.31 07:37:49 0: HMLAN_Send: HMLAN1 S:SE704846C stat: 00 t:00000000 d:01 r:E704846C m:04 B112 23FF23 21F758
2014.01.31 07:37:49 0: HMLAN_Parse: HMLAN1 R:RE704846C stat:0001 t:CFA8817A d:FF r:FFD6 m:04 8002 21F758 23FF23 00
2014.01.31 07:37:49 0: HMLAN_Send: HMLAN1 S:SE704866E stat: 00 t:00000000 d:01 r:E704866E m:05 A001 23FF23 21F758 00050000000007
2014.01.31 07:37:50 0: HMLAN_Parse: HMLAN1 R:RE704866E stat:0001 t:CFA8830D d:FF r:FFD6 m:05 8002 21F758 23FF23 00
2014.01.31 07:37:50 0: HMLAN_Send: HMLAN1 S:SE70489AC stat: 00 t:00000000 d:01 r:E70489AC m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:37:51 0: HMLAN_Parse: HMLAN1 R:RE70489AC stat:0008 t:00000000 d:FF r:7FFF m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:37:51 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
2014.01.31 07:37:54 0: HMLAN_Send: HMLAN1 S:SE70497F0 stat: 00 t:00000000 d:01 r:E70497F0 m:07 B112 23FF23 21F758
2014.01.31 07:37:54 0: HMLAN_Parse: HMLAN1 R:RE70497F0 stat:0001 t:CFA894FF d:FF r:FFD6 m:07 8002 21F758 23FF23 00
2014.01.31 07:37:54 0: HMLAN_Send: HMLAN1 S:SE70499F1 stat: 00 t:00000000 d:01 r:E70499F1 m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:37:55 0: HMLAN_Parse: HMLAN1 R:RE70499F1 stat:0008 t:00000000 d:FF r:7FFF m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:37:55 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
2014.01.31 07:37:58 0: HMLAN_Send: HMLAN1 S:SE704A873 stat: 00 t:00000000 d:01 r:E704A873 m:08 B112 23FF23 21F758
2014.01.31 07:37:59 0: HMLAN_Parse: HMLAN1 R:RE704A873 stat:0001 t:CFA8A583 d:FF r:FFD6 m:08 8002 21F758 23FF23 00
2014.01.31 07:37:59 0: HMLAN_Send: HMLAN1 S:SE704AB70 stat: 00 t:00000000 d:01 r:E704AB70 m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:37:59 0: HMLAN_Parse: HMLAN1 R:RE704AB70 stat:0008 t:00000000 d:FF r:7FFF m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:37:59 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
2014.01.31 07:38:02 0: HMLAN_Send: HMLAN1 S:SE704B99F stat: 00 t:00000000 d:01 r:E704B99F m:09 B112 23FF23 21F758
2014.01.31 07:38:03 0: HMLAN_Parse: HMLAN1 R:RE704B99F stat:0001 t:CFA8B6AE d:FF r:FFD6 m:09 8002 21F758 23FF23 00
2014.01.31 07:38:03 0: HMLAN_Send: HMLAN1 S:SE704BB9F stat: 00 t:00000000 d:01 r:E704BB9F m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:38:04 0: HMLAN_Parse: HMLAN1 R:RE704BB9F stat:0008 t:00000000 d:FF r:7FFF m:06 A001 23FF23 21F758 00082F6C304D3114
2014.01.31 07:38:04 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
Gruß
Daniel
Hallo Martin,
habe jetzt mein Problem mit dem Slider und dessen Aktualsierung bei manueller Änderung am Thermostat, nach der von dir beschriebenen Methode, lösen können. Die 'desired-temp' wird nun nicht mehr zyklisch abgefragt, sondern über ein Event nur bei Änderung. Man muss allerdings vorher am Thermostat (Device) das Attribut 'event-on-change-reading' auf 'desired-temp' setzen.
Falls jemand Interesse hat, kann ich meinen Code gerne hier 'posten'.
Viele Grüße und Danke
Joachim
Hallo Joachim,
ich hätte auf jeden Fall Interesse an Deiner Lösung. Vielleicht kannst Du sie ja aber auch gleich ins Wiki schreiben? Dann hätten alle was davon.
Gruß,
Reiner.
Hi Daniel,
wie sind die Kommandos/register die du änderst?
kannst du das nächste Mal attr global mseclog 1 setzen?
Auf der neusten Version bist du schon? Die weiteren Versuche müssen scheitern, da die erste message fehlt. Das sollte eignetlich abgefangen werden in neueren Versionen.
Du solltest ein clear msgevents voranstellen - zumindest in diesem Fall
Gruss Martin
Hallo Martin,
Version habe ich immer die aktuelle, ich mache jeden morgen um 9 ein FHEM Update.
- attr global mseclog 1 habe ich jetzt gesetzt
- Register geändert habe ich:
set az_Heizung_Clima tempListSun 09:00 17.0 23:00 19.0 24:00 17.0 (Das ging jetzt mit einmal wieder, also Temp Listen sind jetzt alle drin)
set az_Heizung_Clima regSet tempOffset 1.0K --> Da kommt wieder ein missing ack:
2014.01.31 10:08:22 2: CUL_HM set az_Heizung_Clima regSet tempOffset 1.0K
2014.01.31 10:08:22 0: HMLAN_Send: HMLAN1 S:SE78E5BB4 stat: 00 t:00000000 d:01 r:E78E5BB4 m:1F B112 23FF23 21F758
2014.01.31 10:08:23 0: HMLAN_Parse: HMLAN1 R:RE78E5BB4 stat:0001 t:D0325DF3 d:FF r:FFD5 m:1F 8002 21F758 23FF23 00
2014.01.31 10:08:23 0: HMLAN_Send: HMLAN1 S:SE78E5EF2 stat: 00 t:00000000 d:01 r:E78E5EF2 m:20 A001 23FF23 21F758 00050000000007
2014.01.31 10:08:24 0: HMLAN_Parse: HMLAN1 R:RE78E5EF2 stat:0001 t:D0325FAD d:FF r:FFD4 m:20 8002 21F758 23FF23 00
2014.01.31 10:08:24 0: HMLAN_Send: HMLAN1 S:+21F758,00,01,
2014.01.31 10:08:24 0: HMLAN_Send: HMLAN1 S:SE78E620E stat: 00 t:00000000 d:01 r:E78E620E m:21 A001 23FF23 21F758 04080909
2014.01.31 10:08:25 0: HMLAN_Parse: HMLAN1 R:RE78E620E stat:0008 t:00000000 d:FF r:7FFF m:21 A001 23FF23 21F758 04080909
2014.01.31 10:08:25 0: HMLAN_Parse: HMLAN1 no ACK from 21F758Ein set az_Heizung_Clima clear msgEvents bringt folgendes:
2014.01.31 10:10:20 2: CUL_HM set az_Heizung_Clima clear msgEvents
2014.01.31 10:10:20 0: HMLAN_Send: HMLAN1 S:SE79025B0 stat: 00 t:00000000 d:01 r:E79025B0 m:22 B112 23FF23 21F758
2014.01.31 10:10:20 0: HMLAN_Parse: HMLAN1 R:RE79025B0 stat:0001 t:D03427DD d:FF r:FFD4 m:22 8002 21F758 23FF23 00
2014.01.31 10:10:20 0: HMLAN_Send: HMLAN1 S:SE79027B1 stat: 00 t:00000000 d:01 r:E79027B1 m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:21 0: HMLAN_Parse: HMLAN1 R:RE79027B1 stat:0008 t:00000000 d:FF r:7FFF m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:21 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
2014.01.31 10:10:23 0: HMLAN_Send: HMLAN1 S:SE790350B stat: 00 t:00000000 d:01 r:E790350B m:24 B112 23FF23 21F758
2014.01.31 10:10:24 0: HMLAN_Parse: HMLAN1 R:RE790350B stat:0001 t:D034373A d:FF r:FFD4 m:24 8002 21F758 23FF23 00
2014.01.31 10:10:24 0: HMLAN_Send: HMLAN1 S:SE79037F9 stat: 00 t:00000000 d:01 r:E79037F9 m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:25 0: HMLAN_Parse: HMLAN1 R:RE79037F9 stat:0008 t:00000000 d:FF r:7FFF m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:25 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
2014.01.31 10:10:27 0: HMLAN_Send: HMLAN1 S:SE790410A stat: 00 t:00000000 d:01 r:E790410A m:25 B112 23FF23 21F758
2014.01.31 10:10:28 0: HMLAN_Parse: HMLAN1 R:RE790410A stat:0001 t:D034433A d:FF r:FFD4 m:25 8002 21F758 23FF23 00
2014.01.31 10:10:28 0: HMLAN_Send: HMLAN1 S:SE790459E stat: 00 t:00000000 d:01 r:E790459E m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:28 0: HMLAN_Parse: HMLAN1 R:RE790459E stat:0008 t:00000000 d:FF r:7FFF m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:28 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
2014.01.31 10:10:28 0: HMLAN_Send: HMLAN1 S:SE790488B stat: 00 t:00000000 d:01 r:E790488B m:26 B112 23FF23 21F758
2014.01.31 10:10:29 0: HMLAN_Parse: HMLAN1 R:RE790488B stat:0001 t:D0344B1F d:FF r:FFD4 m:26 8002 21F758 23FF23 00
2014.01.31 10:10:29 0: HMLAN_Send: HMLAN1 S:SE7904B81 stat: 00 t:00000000 d:01 r:E7904B81 m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:30 0: HMLAN_Parse: HMLAN1 R:RE7904B81 stat:0008 t:00000000 d:FF r:7FFF m:23 A001 23FF23 21F758 04080909
2014.01.31 10:10:30 0: HMLAN_Parse: HMLAN1 no ACK from 21F758
2014.01.31 10:10:56 0: HMLAN_Parse: HMLAN1 R:E21F758 stat:0000 t:D034B444 d:FF r:FFD4 m:94 8610 21F758 000000 0A98F3100018FW Version von meinen beiden Reglern ist übrigens 1.0
Zitat von: martinp876 am 31 Januar 2014, 09:57:41
Hi Daniel,
wie sind die Kommandos/register die du änderst?
kannst du das nächste Mal attr global mseclog 1 setzen?
Auf der neusten Version bist du schon? Die weiteren Versuche müssen scheitern, da die erste message fehlt. Das sollte eignetlich abgefangen werden in neueren Versionen.
Du solltest ein clear msgevents voranstellen - zumindest in diesem Fall
Gruss Martin
Hi,
da wird aber ein kramp gesendet.... das kann nicht funktionieren.
Was sendest du eigentlich, dass so einen Message gebaut wird?
was sagt HMInfo configCheck dazu?
Gruss Martin
Das fragst du mich was ich sende ;-) Ich habe nur das eingegeben was ich geschrieben habe ;-) Wie gesagt das Teil ist out of the box gestern ausgepackt und angebunden an FHEM auf dem üblichen Weg.
configCheck done:
missing register list
CUL_HM_HM_SCI_3_FM_208212: RegL_00:
CUL_HM_HM_SCI_3_FM_208212_Sw_01: .RegL_01:
CUL_HM_HM_SCI_3_FM_208212_Sw_02: .RegL_01:
CUL_HM_HM_SCI_3_FM_208212_Sw_03: .RegL_01:
bz_Fenster: RegL_00:
fl_Eingang: RegL_00:
sz_Fenster: RegL_00:
sz_Stellantrieb_links: RegL_00:
wz_Fenster: RegL_00:
wz_Stellantrieb_rechts: RegL_00:
Register changes pending
az_Heizung_Clima
peer list not read
empty: CUL_HM_HM_SCI_3_FM_208212_Sw_01
empty: CUL_HM_HM_SCI_3_FM_208212_Sw_02
empty: CUL_HM_HM_SCI_3_FM_208212_Sw_03
empty: sz_Stellantrieb_links
empty: wz_Stellantrieb_rechts
peer not verified
sz_Thermostat_Climate p:sz_Stellantrieb_links
wz_Thermostat_Climate p:wz_Stellantrieb_rechts
peerNeedsBurst cannot be determined
bz_Fenster
PairedTo missing/unknown
CUL_HM_HM_SCI_3_FM_208212
bz_Fenster
sz_Stellantrieb_links
wz_Stellantrieb_rechts
Vielleicht doch noch mal löschen und neu anlegen lassen?
Gruß
Daniel
Zitat von: martinp876 am 31 Januar 2014, 10:48:23
Hi,
da wird aber ein kramp gesendet.... das kann nicht funktionieren.
Was sendest du eigentlich, dass so einen Message gebaut wird?
was sagt HMInfo configCheck dazu?
Gruss Martin
wäre interessant zu suchen, was hier schief steht. dazu brauche ich alle List und das Kommando
Aber du kannst auch einfach das device in FHEM löschen (kanäle verschwinden dann auch) und dann einfach anlernendrücken. (Pair nicht notwendig).
FHEM legt alles wieder an. Ggf ein getConfig, falls es nicht automatisch passiert.
Am Device liegt es nicht, die seltsame message baut FHEM zusammen
Nö naja, du wenn wir der Sache auf den Grund gehen wollen können wir das gerne machen. Das ist mir jetzt nicht so wichtig, dass der Regler zu 100% funktioniert, vielleicht ist ja da wirklich irgend eine Konstellation Schuld die nur ich hier habe. Ich lass das erst mal so stehen wie es steht und schicke dir die Outputs. Ein List möchtest du noch haben, sollst du bekommen. Ich schick es dir mal eben per PM, dass wird hier sonst so voll.
Gruß
Daniel
Nabend,
habe heute Mittag meinen 3.RT bekommen. Pairing hat scheinbar sofort funktioniert. Ich weiss nicht ob es gewollt ist aber ich kann an dem Device kein GetConfig klicken da der Link nicht vorhanden ist.
Siehe Scrennshot. Bad ist neu und sieht anderst aus als Wohnzimmer / Buero. Evtl. hat es was damit zu tun das Bad a] firmware 1.1 und nicht wie die anderen 1.0 hat und / oder b] es das erste Device ist was mit HMLAN stat Coc paired wurde.
Als /erstma) Workaround habe ich dem attr WebCMD getConfig zusätzlich zum burstXmit verpasst. Das Dropdwonfeld ist nun weg. Bleibt die Frage ob dies ein Bug ist?
Ja ist bei mir auch, aber das liegt wohl eher daran, das zwischen den beiden autocreates deiner Geräte ein paar Tage liegt wo sich einiges getan hat :-)
Der Name des einen Kanals ist ja auch etwas kürzer geworden.
Gruß
Daniel
ok - muss ich nachbessern.
du kannst es einsellen mit webCmd. FHEM versucht einen default zu setzen.
Ich würde vorschlagen:
webCmd getConfig:clear msgEvents:burstXmit
Nur mal nebenbei angemerkt: der RT hat mit der Firmware 1.2 ein deutlich anderes (im Sinne von besser) Regelverhalten als vorher mit 1.0. Das "Flattern" durch ständiges Auf- und Zuregeln ist nahezu vollständig verschwunden.
mmm. Da scheint die Variante den Pi kurz als CCU2 zu nutzen (zum Firmwareupdate, auf einer extra SSD ) immer interessanter
Die Variante HM-USB-CFG + Update-Software von eq3 finde ich da noch viel einfacher.
http://forum.fhem.de/index.php/topic,19556.0.html
Kann man eigentlich irgendwie einen externen Temperatursensor aus FHEM an dem Ding anlernen? Der interne ist der letzte scheiß. Ist die Heizung aus passt alles, geht die Heizung an habe ich 27 Grad obwohl nur 19 im Zimmer sind...
Aber das war mir klar, daher verstehe ich nicht wieso die so ein Misst entwickelt haben wie bei den ganzen Reglern vom Grabbeltisch. Das war viel besser mit der zentralen Steuerung und ohne Display und anderen Schnickschnack an den Reglern.
Schade dass das Update nicht über die Windows Software vom HMLan Adapter geht, das wäre doch mal sinnvoll für einen "Konfigurationsadapter"
Ups und gerade schreibt jemand das mit dem Konfig Adapter, dass das jetzt geht, na gleich mal schauen ;-)
Gruß
Daniel
Such mal nach virtTemp hier im HM Bereich. Inzwischen geht das anscheinend.
@Reiner
Sorry für die späte Antwort, anbei mein Code. Wichtig ist vorher am Thermostat (bei mir "AZ_Heizung") das Event beim Empfang einer neuen Solltemperatur zu aktivieren. Das geht hiermit:
define AZ_Heizung ...
attr AZ_Heizung room Arbeitszimmer
...
attr AZ_Heizung event-on-change-reading desired-temp
Dann habe ich mir folgendes Dummy-Objekt "AZ_SollTemperatur" angelegt:
# Slider Solltemperatur (Advanced)
# Dieser sendet keine gleichen Werte und das Thermostat und
# beruecksichtigt auch eine mauelle Verstellung am Thermostat.
define AZ_SollTemperatur dummy
attr AZ_SollTemperatur group 3.SollTemperatur
attr AZ_SollTemperatur icon temp_temperature
attr AZ_SollTemperatur room Arbeitszimmer
attr AZ_SollTemperatur setList state:slider,15,1,25
attr AZ_SollTemperatur webCmd state
#SollTemperaturOnChange
define AZ_SollTemperaturOnChange notify (AZ_SollTemperatur|global:INITIALIZED|global:REREADCFG) { if (ReadingsVal("AZ_Heizung","desired-temp",17) != %) { fhem "set AZ_Heizung_ClimRT desired-temp %" } }
#SollTemperatur_OnExternalChange
define AZ_SollTemperatur_OnExternalChange notify AZ_Heizung:desired-temp.* set AZ_SollTemperatur $EVTPART1
Damit sollte schon alles laufen!
Viel Spass!
Hallo,
gibt es eine Möglichkeit, die desired-temp in fhemweb auch auf smallscreen-devices zu setzen? Standardmäßig ist im Browser ja ein dropdown-Menü zu sehen, im smallscreen-mode (ich nutze "darksmallscreen") allerdings nichts dergleichen. Falls das dropdown-Menü nicht möglich ist, kann man evtl. 2-3 feste Werte als Links einrichten, ohne über einen dummy gehen zu müssen? Vielleicht übersehe ich aber auch etwas? :-\
schöne Grüße
Jo
Nach einem clear und einem getconfig sehe ich in fhemweb keine reading mehr für die programmierten tagestemperaturen bei dem entsprechenden Device. Bei den anderen ist es noch da. Mache ich was falsch?
Gesendet von meinem Xperia Pro mit Tapatalk
wenn du alles clearst ist alles weg - klar so weit
wenn du ein getConfig nachst sind alle register wieder da. Sollte dem nicht so sein, pruefen, ob noch kommandos pending sind oder ob protokollfehler aufgetreten sind.
Danke Martin,
die ersten beiden Punkte waren mir klar, damit habe ich auch gerechnet.
Leider sind bei mir, trotz aktuellem fhem, eben nicht wieder alle Readings erschienen.
FHEM ist aktuell von gestern. Ich sehe keine Kommando pending, zumindest nicht wie früher, jedoch steht bei allen Readings mit R-Werten ein "Set_" als prefix,
Anbei alle Readings, die ich erhalte.
R-boostPeriod set_5 min 2014-02-03 22:07:37
R-boostPos set_80 % 2014-02-03 22:07:37
R-btnNoBckLight set_off 2014-02-03 22:07:37
R-dayTemp set_21 C 2014-02-03 22:07:37
R-daylightSaveTime set_on 2014-02-03 22:07:37
R-decalcTime set_11:00 2014-02-03 22:07:37
R-decalcWeekday set_Sat 2014-02-03 22:07:37
R-modePrioManu set_all 2014-02-03 22:07:37
R-modePrioParty set_all 2014-02-03 22:07:37
R-nightTemp set_17 C 2014-02-03 22:07:37
R-noMinMax4Manu set_off 2014-02-03 22:07:37
R-regAdaptive set_on 2014-02-03 22:07:37
R-reguExtI set_15 2014-02-03 22:07:37
R-reguExtP set_30 2014-02-03 22:07:37
R-reguExtPstart set_30 2014-02-03 22:07:37
R-reguIntI set_15 2014-02-03 22:07:37
R-reguIntP set_30 2014-02-03 22:07:37
R-reguIntPstart set_30 2014-02-03 22:07:37
R-showInfo set_time 2014-02-03 22:07:37
R-showWeekday set_off 2014-02-03 22:07:37
R-tempMax set_25 C 2014-02-03 22:07:37
R-tempMin set_4.5 C 2014-02-03 22:07:37
R-tempOffset set_0.0K 2014-02-03 22:07:37
R-valveErrPos set_15 % 2014-02-03 22:07:37
R-valveMaxPos set_100 % 2014-02-03 22:07:37
R-valveOffsetRt set_0 % 2014-02-03 22:07:37
R-winOpnBoost set_off 2014-02-03 22:07:37
R-winOpnDetFall set_1.4 K 2014-02-03 22:07:37
R-winOpnMode set_on 2014-02-03 22:07:37
R-winOpnPeriod set_15 min 2014-02-03 22:07:37
R-winOpnTemp set_12 C 2014-02-03 22:07:37
ValvePosition 7 % 2014-02-17 09:43:20
desired-temp 13 2014-02-17 09:43:20
measured-temp 13.0 2014-02-17 09:43:20
mode auto 2014-02-17 09:43:20
motorErr ok 2014-02-17 09:43:20
state T: 13.0 desired: 13 valve: 7
Hi Joe,
nun, dann ist das getConfig nicht gelaufen. Wie du an die set_ gekommen bist ist mir nicht klar.... da waeren wohl register geschreiben worden. Koennte sein, dass es vom Loeschen kommt - da macht es sinn. Device-reading ist geloescht, kopie noch da -> alle register sind zweifelhaft - passt.
Bleibt die Frage, warum nicht gelesen wird.
a) dein device ist korrekt geschrieben (list des Device senden
b) nach getConfig werden kommands in den Stack gestellt (pruefen auf pending
c) irgendwann wacht der RT auf, dann wird gesendet -> roh-messages loggen
Gruss Martin
Hallo Martin,
Danke für die schnelle Antwort.
Ich hoffe, ich habe alle Informationen zusammen.
Was mir aufgefallen ist:
Er scheibnt die Temperaturänderung angenommen zu haben.
Der Thermostat zeigt jetzt eine desired-temp von 13 an. Gestern war es noch 14.
Diesen Befehl habe ich gestern abgesetzt. Eine zeit lang war danach von "pending" zu lesen,
was aber später verschwunden ist. Soll ich den nochmal absetzen?
set hg.Heizung_ClimRT_tr tempListMon prep 24:00 13.0
set hg.Heizung_ClimRT_tr tempListTue prep 24:00 13.0
set hg.Heizung_ClimRT_tr tempListWed prep 24:00 13.0
set hg.Heizung_ClimRT_tr tempListThu prep 24:00 13.0
set hg.Heizung_ClimRT_tr tempListFri prep 24:00 13.0
set hg.Heizung_ClimRT_tr tempListSat prep 24:00 13.0
set hg.Heizung_ClimRT_tr tempListSun exec 24:00 13.0Zitat von: martinp876 am 17 Februar 2014, 11:04:36
a) dein device ist korrekt geschrieben (list des Device senden
Anbei das Ergebnis. Ich hatte zwischenzeitlich nochmal getconfig abgesetzt.
fhem> list hg.Heizung_ClimRT_tr
Internals:
CFGFN ./FHEM/fhem-heizung.cfg
DEF 21C2DB04
HMLAN1_MSGCNT 530
HMLAN1_RAWMSG E21C2DB,0000,45C3F7AD,FF,FFD7,CC861021C2DB0000000A68820A0917
HMLAN1_RSSI -41
HMLAN1_TIME 2014-02-17 11:09:01
LASTInputDev HMLAN1
MSGCNT 530
NAME hg.Heizung_ClimRT_tr
NR 90
STATE T: 13.0 desired: 13 valve: 9 %
TYPE CUL_HM
chanNo 04
device hg.Heizung
CHANGETIME:
Helper:
Dblog:
R-sign:
Mydblog:
TIME 1392627219.57853
VALUE off
Mydblogsql:
TIME 1392627219.59655
VALUE off
T:
Mydblog:
TIME 1392631741.74933
VALUE 13.0 desired: 13 valve: 9
Mydblogsql:
TIME 1392631743.9854
VALUE 13.0 desired: 13 valve: 9
Valveposition:
Mydblog:
TIME 1392631741.74933
VALUE 9
Mydblogsql:
TIME 1392631743.9854
VALUE 9
Desired-temp:
Mydblog:
TIME 1392631741.74933
VALUE 13
Mydblogsql:
TIME 1392631743.9854
VALUE 13
Measured-temp:
Mydblog:
TIME 1392631741.74933
VALUE 13.0
Mydblogsql:
TIME 1392631743.9854
VALUE 13.0
Mode:
Mydblog:
TIME 1392631741.74933
VALUE auto
Mydblogsql:
TIME 1392631743.9854
VALUE auto
Motorerr:
Mydblog:
TIME 1392631741.74933
VALUE ok
Mydblogsql:
TIME 1392631743.9854
VALUE ok
Readings:
2014-02-03 22:07:37 R-boostPeriod set_5 min
2014-02-03 22:07:37 R-boostPos set_80 %
2014-02-03 22:07:37 R-btnNoBckLight set_off
2014-02-03 22:07:37 R-dayTemp set_21 C
2014-02-03 22:07:37 R-daylightSaveTime set_on
2014-02-03 22:07:37 R-decalcTime set_11:00
2014-02-03 22:07:37 R-decalcWeekday set_Sat
2014-02-03 22:07:37 R-modePrioManu set_all
2014-02-03 22:07:37 R-modePrioParty set_all
2014-02-03 22:07:37 R-nightTemp set_17 C
2014-02-03 22:07:37 R-noMinMax4Manu set_off
2014-02-03 22:07:37 R-regAdaptive set_on
2014-02-03 22:07:37 R-reguExtI set_15
2014-02-03 22:07:37 R-reguExtP set_30
2014-02-03 22:07:37 R-reguExtPstart set_30
2014-02-03 22:07:37 R-reguIntI set_15
2014-02-03 22:07:37 R-reguIntP set_30
2014-02-03 22:07:37 R-reguIntPstart set_30
2014-02-03 22:07:37 R-showInfo set_time
2014-02-03 22:07:37 R-showWeekday set_off
2014-02-17 09:53:39 R-sign off
2014-02-03 22:07:37 R-tempMax set_25 C
2014-02-03 22:07:37 R-tempMin set_4.5 C
2014-02-03 22:07:37 R-tempOffset set_0.0K
2014-02-03 22:07:37 R-valveErrPos set_15 %
2014-02-03 22:07:37 R-valveMaxPos set_100 %
2014-02-03 22:07:37 R-valveOffsetRt set_0 %
2014-02-03 22:07:37 R-winOpnBoost set_off
2014-02-03 22:07:37 R-winOpnDetFall set_1.4 K
2014-02-03 22:07:37 R-winOpnMode set_on
2014-02-03 22:07:37 R-winOpnPeriod set_15 min
2014-02-03 22:07:37 R-winOpnTemp set_12 C
2014-02-17 09:53:39 RegL_01: 08:00 00:00
2014-02-17 09:53:41 RegL_07: 01:2A 02:22 03:09 04:32 05:18 06:03 07:00 08:16 09:05 0A:70 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:35 15:20 16:40 17:54 18:3C 19:C6 1A:41 1B:08 1C:3D 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:35 2F:20 30:40 31:54 32:3C 33:C6 34:41 35:08 36:3D 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:35 49:20 4A:40 4B:54 4C:3C 4D:C6 4E:41 4F:08 50:3D 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:35 63:20 64:40 65:54 66:3C 67:C6 68:41 69:08
2014-02-17 11:09:01 ValvePosition 9 %
2014-02-17 11:09:01 desired-temp 13
2014-02-17 11:09:01 measured-temp 13.0
2014-02-17 11:09:01 mode auto
2014-02-17 11:09:01 motorErr ok
2014-02-17 11:09:01 state T: 13.0 desired: 13 valve: 9 %
Helper:
getCfgListNo
Role:
chn 1
Shregr:
07 00
Shadowreg:
Attributes:
expert 2_full
group Heizung
model HM-CC-RT-DN
peerIDs
room Device
fhem>Zitat von: martinp876 am 17 Februar 2014, 11:04:36
b) nach getConfig werden kommands in den Stack gestellt (pruefen auf pending
Keine sichtbar.
Zitat von: martinp876 am 17 Februar 2014, 11:04:36
c) irgendwann wacht der RT auf, dann wird gesendet -> roh-messages loggen
Das habe ich gefunden, falls das gemeint ist.
2014.02.17 11:10:36 4: CUL_Parse: CUL_0 S37466C011E0000AE28000107774E000D18 -62
2014.02.17 11:10:36 5: CUL_0 dispatch S37466C011E0000AE28000107774E000D
2014.02.17 11:10:36 5: ESA2000 msg s37466c011e0000ae28000107774e000d
2014.02.17 11:10:36 5: ESA2000 seq 37
2014.02.17 11:10:36 5: ESA2000 device 466c
2014.02.17 11:10:36 5: ESA2000 code 011e
2014.02.17 11:10:43 1: HttpUtils url=<hidden>
2014.02.17 11:10:44 1: <hidden>: HTTP response code 200
2014.02.17 11:10:44 1: HttpUtils <hidden>: Got data, length: 4928
2014.02.17 11:12:14 1: 192.168.178.62:1000 disconnected, waiting to reappear
2014.02.17 11:12:15 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.17 11:12:15 1: 192.168.178.62:1000 reappeared (HMLAN1)
2014.02.17 11:12:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.17 11:12:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.17 11:13:18 5: CUL/RAW: /E0101AAE22E3500040016
2014.02.17 11:13:18 4: CUL_Parse: CUL_0 E0101AAE22E3500040016 -63
2014.02.17 11:13:18 5: CUL_0 dispatch E0101AAE22E35000400Über inform raw habe ich folgendes erhalten,
das JeeLink zeug gehört vermutlich einfach entfernt.
sollte ich beim nächsten mal
inform
fhem> fhem> set hg.Heizung_ClimRT_tr getConfig
fhem> HMLAN HMLAN1 A0C6886701F4D62000000007C3C::-66:HMLAN1
JeeLink PCAJeeLink OK 24 2 4 2 242 65 1 0 4 15 25
JeeLink JLLaCR OK 9 76 1 4 32 79
JeeLink JLLaCR OK 9 144 1 4 18 106
JeeLink JLLaCR OK 9 76 1 4 32 79
JeeLink PCAJeeLink OK 24 1 4 12 60 24 1 1 14 15 55
HMLAN HMLAN1 A0F46861022382E0000000A78AF8A0016::-54:HMLAN1
JeeLink PCAJeeLink OK 24 3 4 2 65 15 1 1 102 26 25
JeeLink PCAJeeLink OK 24 2 4 2 242 65 1 0 5 15 25
JeeLink JLLaCR OK 9 144 1 4 18 106
JeeLink JLLaCR OK 9 76 1 4 32 79
JeeLink JLLaCR OK 9 76 1 4 33 79
JeeLink JLLaCR OK 9 76 1 4 33 79
JeeLink PCAJeeLink OK 24 1 4 12 60 24 1 1 12 15 55
JeeLink JLLaCR OK 9 76 1 4 32 79
JeeLink JLLaCR OK 9 144 1 4 18 106
JeeLink JLLaCR OK 9 76 1 4 33 79
JeeLink JLLaCR OK 9 76 1 4 33 79
HMLAN HMLAN1 A0F798610220FFD0000000A74910E0657::-75:HMLAN1
JeeLink JLLaCR OK 9 144 1 4 18 106
JeeLink JLLaCR OK 9 76 1 4 33 79
JeeLink JLLaCR OK 9 144 1 4 18 106Anbei nochmal mit grep HMLAN
HMLAN HMLAN1 A0C6886701F4D62000000007C3C::-66:HMLAN1
HMLAN HMLAN1 A0F46861022382E0000000A78AF8A0016::-54:HMLAN1
HMLAN HMLAN1 A0F798610220FFD0000000A74910E0657::-75:HMLAN1
HMLAN HMLAN1 A0F3986102237930000000A78980E060D::-58:HMLAN1
HMLAN HMLAN1 A0FCE861022382C0000000A78B00A0019::-61:HMLAN1
HMLAN HMLAN1 A0F0B86102236360000000A80A88E0018::-53:HMLAN1
HMLAN HMLAN1 A0CEB8670206CF200000000274B::-65:HMLAN1
HMLAN HMLAN1 A0FD1861021C2DB0000000A68820A0917::-40:HMLAN1
HMLAN HMLAN1 A0C6986701F4D62000000007C3C::-66:HMLAN1
HMLAN HMLAN1 A0C9786701FC9E500000000B648::-48:HMLAN1
HMLAN HMLAN1 A0F47861022382E0000000A78AF8A0016::-54:HMLAN1
HMLAN HMLAN1 A0F7A8610220FFD0000000A74910E0657::-75:HMLAN1
HMLAN HMLAN1 A0F0C86102236360000000A80A88E0018::-53:HMLAN1
HMLAN HMLAN1 A0F3A86102237930000000A78980E050D::-58:HMLAN1
HMLAN HMLAN1 A0CEC8670206CF200000000274B::-65:HMLAN1
HMLAN HMLAN1 A0FCF861022382C0000000A78B10A0019::-61:HMLAN1
HMLAN HMLAN1 A0C6A86701F4D62000000007C3C::-66:HMLAN1
HMLAN HMLAN1 A0FD2861021C2DB0000000A68820A0917::-40:HMLAN1
HMLAN HMLAN1 A0C9886701FC9E500000000B648::-48:HMLAN1
HMLAN HMLAN1 A0F48861022382E0000000A78B08A0016::-53:HMLAN1
HMLAN HMLAN1 A0F7B8610220FFD0000000A74910E0657::-75:HMLAN1
HMLAN HMLAN1 A0F3B86102237930000000A78990E030D::-58:HMLAN1
HMLAN HMLAN1 A0F0D86102236360000000A80A88E0018::-53:HMLAN1
HMLAN HMLAN1 A0CED8670206CF200000000284B::-65:HMLAN1
HMLAN HMLAN1 A0FD0861022382C0000000A78B10A0019::-61:HMLAN1
HMLAN HMLAN1 A0FD3861021C2DB0000000A68830A0917::-40:HMLAN1
HMLAN HMLAN1 A0C6B86701F4D62000000007C3C::-66:HMLAN1
HMLAN HMLAN1 A0C9986701FC9E500000000B647::-48:HMLAN1
HMLAN HMLAN1 A0F7C8610220FFD0000000A74910E0657::-75:HMLAN1
Hi,
rohmessages loggen gemaess
http://forum.fhem.de/index.php/topic,16563.0.html
wenn erst garkeine messages geschreiben werden - werden die Kommandos akzeptiert? Keine Fehlermeldungen?
Was macht die Cul hier? Ist das IODev des RT auf HMLAN gesetzt? Bitte ein list des Device
Gruss Martin
Anbei das List des Devices.
Habe jedoch gerade nochmals das set tempListMon ausgeführt.
list hg.Heizung
Internals:
CFGFN ./FHEM/fhem-heizung.cfg
DEF 21C2DB
HMLAN1_MSGCNT 599
HMLAN1_RAWMSG E21C2DB,0000,4610A97F,FF,FFD7,ED861021C2DB0000000A68840A0517
HMLAN1_RSSI -41
HMLAN1_TIME 2014-02-17 12:32:45
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 599
NAME hg.Heizung
NR 85
STATE CMDs_pending
TYPE CUL_HM
channel_01 hg.Heizung_Weather
channel_02 hg.Heizung_Climate
channel_03 hg.Heizung_WindowRec
channel_04 hg.Heizung_ClimRT_tr
channel_05 hg.Heizung_ClimaTeam
channel_06 hg.Heizung_remote
lastMsg No:ED - t:10 s:21C2DB d:000000 0A68840A0517
protCmdDel 5
protCmdPend 2 CMDs pending
protLastRcv 2014-02-17 12:32:45
protResnd 7 last_at:2014-02-17 12:32:49
protResndFail 1 last_at:2014-02-17 11:24:18
protSnd 43 last_at:2014-02-17 12:32:45
protState CMDs_pending
rssi_at_HMLAN1 avg:-40.74 min:-45 max:-39 lst:-41 cnt:599
CHANGETIME:
Helper:
Dblog:
Activity:
Mydblog:
TIME 1392549678.74327
VALUE alive
Mydblogsql:
TIME 1392549678.75104
VALUE alive
Actuator:
Mydblog:
TIME 1392636765.95555
VALUE 5
Mydblogsql:
TIME 1392636768.48528
VALUE 5
Battery:
Mydblog:
TIME 1392636765.95555
VALUE ok
Mydblogsql:
TIME 1392636768.48528
VALUE ok
Batterylevel:
Mydblog:
TIME 1392636765.95555
VALUE 2.5 V
Mydblogsql:
TIME 1392636768.48528
VALUE 2.5 V
Desired-temp:
Mydblog:
TIME 1392636765.95555
VALUE 13
Mydblogsql:
TIME 1392636768.48528
VALUE 13
Measured-temp:
Mydblog:
TIME 1392636765.95555
VALUE 13.2
Mydblogsql:
TIME 1392636768.48528
VALUE 13.2
State:
Mydblog:
TIME 1392632658.91804
VALUE MISSING ACK
Mydblogsql:
TIME 1392632658.9294
VALUE MISSING ACK
Time-request:
Mydblog:
TIME 1392620267.74568
VALUE -
Mydblogsql:
TIME 1392620267.7599
VALUE -
Readings:
2014-02-16 12:21:18 Activity alive
2014-02-17 12:14:06 CommandAccepted yes
2014-02-12 09:46:50 D-firmware 1.0
2014-02-12 09:46:50 D-serialNr KEQ0579404
2013-11-14 21:39:19 PairedTo 0x1E9B80
2013-11-14 21:39:19 R-backOnTime 10 s
2013-11-14 21:39:19 R-btnLock lock
2013-11-14 21:39:19 R-burstRx on
2013-11-14 21:39:19 R-cyclicInfoMsg on
2013-11-14 21:39:19 R-cyclicInfoMsgDis 0
2013-11-14 21:39:19 R-globalBtnLock off
2013-11-14 21:39:19 R-localResDis off
2013-11-14 21:39:19 R-lowBatLimitRT 2.1 V
2013-11-14 21:39:19 R-modusBtnLock off
2013-11-14 21:39:19 R-pairCentral 0x1E9B80
2013-11-14 21:39:19 RegL_00: 01:01 02:01 09:01 0A:1E 0B:9B 0C:80 0E:0A 0F:01 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2014-02-17 12:32:45 actuator 5 %
2014-02-17 12:32:45 battery ok
2014-02-17 12:32:45 batteryLevel 2.5 V
2014-02-17 12:32:45 desired-temp 13
2014-02-17 12:32:45 measured-temp 13.2
2014-02-17 12:32:49 state CMDs_pending
2014-02-17 07:57:47 time-request -
Regl_07::
VAL
cmdStack:
++A0011E9B8021C2DB04040000000001
++A0011E9B8021C2DB00040000000007
Helper:
cSnd 011E9B8021C2DB00040000000007
mId 0095
rxType 140
Io:
nextSend 1392636606.81779
Prt:
bErr 0
sProc 2
sleeping 1
wuReSent 2
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -40.7479131886478
cnt 599
lst -41
max -39
min -45
Shregw:
07 04
Attributes:
AlleThermostate2 AlleThermostate
actCycle 000:10
actStatus alive
autoReadReg 0_off
event-min-interval battery:300,batteryLevel:300,measured-temp:300,desired-temp:300,actuator:300
event-on-change-reading measured-temp
event-on-update-reading .*
expert 2_full
firmware 1.0
model HM-CC-RT-DN
peerIDs
room CUL_HM
serialNr KEQ0579404
subType thermostat
webCmd getConfig
fhem>
Den CUL verwende ich nur für ESA2000, also CUL_EM.
anbei die RAW messages, hoffentlich richtig?
2014.02.17 12:14:35.747 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4600218B IDcnt:0001
2014.02.17 12:14:43.521 0: HMLAN_Parse: HMLAN1 R:E22382E stat:0000 t:46003FE6 d:FF r:FFCA m:5C 8610 22382E 000000 0A78AF8A0016
2014.02.17 12:14:55.469 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:46006E93 d:FF r:FFBE m:7E 8670 1F4D62 000000 007C3C
2014.02.17 12:15:00.193 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:46007C3E d:FF r:FFC3 m:E3 8610 22382C 000000 0A78B80A0019
2014.02.17 12:15:00.901 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:15:00.916 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460083DB IDcnt:0001
2014.02.17 12:15:21.879 0: HMLAN_Parse: HMLAN1 R:E220FFD stat:0000 t:4600D5C1 d:FF r:FFB5 m:8F 8610 220FFD 000000 0A74930E0557
2014.02.17 12:15:25.911 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:15:25.921 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4600E591 IDcnt:0001
2014.02.17 12:15:39.341 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:460111A2 d:FF r:FFCB m:21 8610 223636 000000 0A80A78E0018
2014.02.17 12:15:50.923 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:15:50.933 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46014748 IDcnt:0001
2014.02.17 12:15:52.912 0: HMLAN_Parse: HMLAN1 R:E206CF2 stat:0000 t:46014D03 d:FF r:FFBF m:01 8670 206CF2 000000 002E4A
2014.02.17 12:16:15.932 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:16:15.955 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4601A908 IDcnt:0001
2014.02.17 12:16:40.956 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:16:40.967 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46020AC1 IDcnt:0001
2014.02.17 12:16:54.742 0: HMLAN_Parse: HMLAN1 R:E1FC9E5 stat:0000 t:46022DB7 d:FF r:FFD0 m:AD 8670 1FC9E5 000000 00B647
2014.02.17 12:16:56.273 0: HMLAN_Parse: HMLAN1 R:E22382E stat:0000 t:46024689 d:FF r:FFCA m:5D 8610 22382E 000000 0A78AF8A0016
2014.02.17 12:17:00.717 0: HMLAN_Parse: HMLAN1 R:E21C2DB stat:0000 t:460257E8 d:FF r:FFD8 m:E7 8610 21C2DB 000000 0A68840A0517
2014.02.17 12:17:22.113 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:17:22.229 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:46027A16 d:FF r:FFC3 m:E4 8610 22382C 000000 0A78B90A0019
2014.02.17 12:17:22.927 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:4602A9F6 d:FF r:FFBE m:7F 8670 1F4D62 000000 007C3C
2014.02.17 12:17:23.117 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4602AB8C IDcnt:0001
2014.02.17 12:17:46.084 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:4602FEE0 d:FF r:FFCA m:22 8610 223636 000000 0A80A78E0018
2014.02.17 12:17:47.123 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:17:47.133 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46030D41 IDcnt:0001
2014.02.17 12:17:50.718 0: HMLAN_Parse: HMLAN1 R:E223793 stat:0000 t:46031B3F d:FF r:FFC6 m:50 8610 223793 000000 0A78A20E000D
2014.02.17 12:18:13.575 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:18:13.585 0: HMLAN_Parse: HMLAN1 R:E220FFD stat:0000 t:4603509F d:FF r:FFB6 m:90 8610 220FFD 000000 0A74930E0457
2014.02.17 12:18:14.288 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4603749A IDcnt:0001
2014.02.17 12:18:40.338 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:18:40.348 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4603DD28 IDcnt:0001
2014.02.17 12:18:49.663 0: HMLAN_Parse: HMLAN1 R:E206CF2 stat:0000 t:46040187 d:FF r:FFBF m:02 8670 206CF2 000000 002F4A
2014.02.17 12:19:06.157 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:19:06.170 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46044208 IDcnt:0001
2014.02.17 12:19:31.206 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:19:31.219 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4604A3E4 IDcnt:0001
2014.02.17 12:19:33.475 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:4604ACB3 d:FF r:FFBE m:80 8670 1F4D62 000000 007C3C
2014.02.17 12:19:37.674 0: HMLAN_Parse: HMLAN1 R:E1FC9E5 stat:0000 t:4604BD1A d:FF r:FFD0 m:AE 8670 1FC9E5 000000 00B647
2014.02.17 12:19:41.217 0: HMLAN_Parse: HMLAN1 R:E21C2DB stat:0000 t:4604CAF4 d:FF r:FFD7 m:E8 8610 21C2DB 000000 0A68840A0517
2014.02.17 12:19:56.218 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:19:56.229 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4605059C IDcnt:0001
2014.02.17 12:19:58.776 0: HMLAN_Parse: HMLAN1 R:E22382E stat:0000 t:46050F8B d:FF r:FFCA m:5E 8610 22382E 000000 0A78AF8A0016
2014.02.17 12:20:12.158 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:46053952 d:FF r:FFC3 m:E5 8610 22382C 000000 0A78BA0A0019
2014.02.17 12:20:17.728 0: HMLAN_Parse: HMLAN1 R:E223793 stat:0000 t:46055995 d:FF r:FFC6 m:51 8610 223793 000000 0A78A30E000D
2014.02.17 12:20:23.246 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:20:23.261 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46056F33 IDcnt:0001
2014.02.17 12:20:39.072 0: HMLAN_Parse: HMLAN1 R:E220FFD stat:0000 t:460593D0 d:FF r:FFB6 m:91 8610 220FFD 000000 0A74930E0457
2014.02.17 12:20:40.853 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:4605AD82 d:FF r:FFCA m:23 8610 223636 000000 0A80A78E0018
2014.02.17 12:20:48.327 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:20:48.341 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4605D131 IDcnt:0001
2014.02.17 12:21:13.338 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:21:13.349 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460632E7 IDcnt:0001
2014.02.17 12:21:32.419 0: HMLAN_Parse: HMLAN1 R:E206CF2 stat:0000 t:46067D64 d:FF r:FFBF m:03 8670 206CF2 000000 002F4A
2014.02.17 12:21:38.350 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:21:38.360 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4606949F IDcnt:0001
2014.02.17 12:22:03.362 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:22:03.374 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4606F658 IDcnt:0001
2014.02.17 12:22:12.022 0: HMLAN_Parse: HMLAN1 R:E21C2DB stat:0000 t:4607055A d:FF r:FFD7 m:E9 8610 21C2DB 000000 0A68840A0517
2014.02.17 12:22:12.919 0: HMLAN_Parse: HMLAN1 R:E1FC9E5 stat:0000 t:460713D6 d:FF r:FFD0 m:AF 8670 1FC9E5 000000 00B647
2014.02.17 12:22:33.380 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:22:33.390 0: HMLAN_Parse: HMLAN1 R:E223793 stat:0000 t:46075F36 d:FF r:FFC6 m:52 8610 223793 000000 0A78A40E000D
2014.02.17 12:22:34.037 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46076B9D IDcnt:0001
2014.02.17 12:22:34.980 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:460771CE d:FF r:FFBE m:81 8670 1F4D62 000000 007C3C
2014.02.17 12:22:46.385 0: HMLAN_Parse: HMLAN1 R:E220FFD stat:0000 t:46079E5B d:FF r:FFB6 m:92 8610 220FFD 000000 0A74930E0457
2014.02.17 12:22:59.812 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:22:59.822 0: HMLAN_Parse: HMLAN1 R:E22382E stat:0000 t:46079FE6 d:FF r:FFCA m:5F 8610 22382E 000000 0A78AF8A0016
2014.02.17 12:23:00.109 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:4607C0E2 d:FF r:FFC3 m:E6 8610 22382C 000000 0A78BB0A0019
2014.02.17 12:23:00.785 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4607D2E1 IDcnt:0001
2014.02.17 12:23:23.853 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:4608237D d:FF r:FFCA m:24 8610 223636 000000 0A80A78E0018
2014.02.17 12:23:24.935 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:23:24.945 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46083507 IDcnt:0001
2014.02.17 12:23:50.285 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:23:50.295 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46089811 IDcnt:0001
2014.02.17 12:24:00.925 0: HMLAN_Parse: HMLAN1 R:E206CF2 stat:0000 t:4608C194 d:FF r:FFBF m:04 8670 206CF2 000000 00314A
2014.02.17 12:24:15.295 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:24:15.305 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4608F9C7 IDcnt:0001
2014.02.17 12:24:18.719 0: HMLAN_Parse: HMLAN1 R:E21C2DB stat:0000 t:4609071A d:FF r:FFD7 m:EA 8610 21C2DB 000000 0A68840A0517
2014.02.17 12:24:32.693 0: HMLAN_Parse: HMLAN1 R:E1FC9E5 stat:0000 t:460932E7 d:FF r:FFD0 m:B0 8670 1FC9E5 000000 00B647
2014.02.17 12:24:40.303 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:24:40.313 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46095B7B IDcnt:0001
2014.02.17 12:25:05.311 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:25:05.322 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:4609BD2F IDcnt:0001
2014.02.17 12:25:20.644 0: HMLAN_Parse: HMLAN1 R:E22382E stat:0000 t:4609F79B d:FF r:FFCA m:60 8610 22382E 000000 0A78AF8A0016
2014.02.17 12:25:21.984 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:4609FE43 d:FF r:FFBE m:82 8670 1F4D62 000000 007C3C
2014.02.17 12:25:26.473 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:460A0FCB d:FF r:FFC3 m:E7 8610 22382C 000000 0A78BC0A0019
2014.02.17 12:25:30.321 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:25:30.332 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460A1EE5 IDcnt:0001
2014.02.17 12:25:32.221 0: HMLAN_Parse: HMLAN1 R:E223793 stat:0000 t:460A2642 d:FF r:FFC6 m:53 8610 223793 000000 0A78A60E000D
2014.02.17 12:25:47.461 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:460A61CC d:FF r:FFCA m:25 8610 223636 000000 0A80A68E0018
2014.02.17 12:25:49.635 0: HMLAN_Parse: HMLAN1 R:E220FFD stat:0000 t:460A6A4A d:FF r:FFB5 m:93 8610 220FFD 000000 0A74940E0357
2014.02.17 12:25:55.330 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:25:55.341 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460A8099 IDcnt:0001
2014.02.17 12:26:17.292 0: HMLAN_Parse: HMLAN1 R:E206CF2 stat:0000 t:460ACD1E d:FF r:FFBF m:05 8670 206CF2 000000 00314A
2014.02.17 12:26:20.342 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:26:20.353 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460AE250 IDcnt:0001
2014.02.17 12:26:35.499 0: HMLAN_Parse: HMLAN1 R:E1FC9E5 stat:0000 t:460B1950 d:FF r:FFD0 m:B1 8670 1FC9E5 000000 00B647
2014.02.17 12:26:45.352 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:26:45.361 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460B4406 IDcnt:0001
2014.02.17 12:27:10.367 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:27:10.378 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460BA5C1 IDcnt:0001
2014.02.17 12:27:19.983 0: HMLAN_Parse: HMLAN1 R:E21C2DB stat:0000 t:460BCB37 d:FF r:FFD7 m:EB 8610 21C2DB 000000 0A68840A0517
2014.02.17 12:27:35.378 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:27:35.391 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460C0778 IDcnt:0001
2014.02.17 12:27:39.532 0: HMLAN_Parse: HMLAN1 R:E22382E stat:0000 t:460C17A3 d:FF r:FFCB m:61 8610 22382E 000000 0A78AF8A0016
2014.02.17 12:27:43.223 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:460C260E d:FF r:FFC3 m:E8 8610 22382C 000000 0A78BD0A0019
2014.02.17 12:27:58.132 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:460C5211 d:FF r:FFBE m:83 8670 1F4D62 000000 007C3C
2014.02.17 12:27:59.963 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:460C6775 d:FF r:FFCB m:26 8610 223636 000000 0A80A68E0018
2014.02.17 12:28:00.388 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:28:00.399 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460C692D IDcnt:0001
2014.02.17 12:28:22.055 0: HMLAN_Parse: HMLAN1 R:E223793 stat:0000 t:460CB5A2 d:FF r:FFC6 m:54 8610 223793 000000 0A78A70E000D
2014.02.17 12:28:25.398 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:28:25.408 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460CCAE3 IDcnt:0001
2014.02.17 12:28:46.915 0: HMLAN_Parse: HMLAN1 R:E220FFD stat:0000 t:460CFD93 d:FF r:FFB5 m:94 8610 220FFD 000000 0A74940E0157
2014.02.17 12:28:50.407 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:28:50.419 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460D2C98 IDcnt:0001
2014.02.17 12:29:15.416 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:29:15.426 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460D8E4C IDcnt:0001
2014.02.17 12:29:18.439 0: HMLAN_Parse: HMLAN1 R:E206CF2 stat:0000 t:460D9A0D d:FF r:FFBF m:06 8670 206CF2 000000 00324A
2014.02.17 12:29:28.440 0: HMLAN_Parse: HMLAN1 R:E1FC9E5 stat:0000 t:460DC11E d:FF r:FFD0 m:B2 8670 1FC9E5 000000 00B647
2014.02.17 12:29:40.613 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:29:40.627 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460DF0BD IDcnt:0001
2014.02.17 12:29:44.283 0: HMLAN_Parse: HMLAN1 R:E22382E stat:0000 t:460DFF05 d:FF r:FFCA m:62 8610 22382E 000000 0A78AF8A0016
2014.02.17 12:29:45.473 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:460E03AB d:FF r:FFC3 m:E9 8610 22382C 000000 0A78BE0A0019
2014.02.17 12:30:05.767 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:30:05.779 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460E5304 IDcnt:0001
2014.02.17 12:30:06.720 0: HMLAN_Parse: HMLAN1 R:E21C2DB stat:0000 t:460E56AF d:FF r:FFD7 m:EC 8610 21C2DB 000000 0A68840A0517
2014.02.17 12:30:12.741 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:460E6E32 d:FF r:FFBD m:84 8670 1F4D62 000000 007C3C
2014.02.17 12:30:31.186 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:30:31.196 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460EB652 IDcnt:0001
2014.02.17 12:30:54.137 0: HMLAN_Parse: HMLAN1 R:E223793 stat:0000 t:460F0C5C d:FF r:FFC6 m:55 8610 223793 000000 0A78A80E000D
2014.02.17 12:30:56.195 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:30:56.205 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460F1806 IDcnt:0001
2014.02.17 12:31:01.964 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:460F2E81 d:FF r:FFCB m:27 8610 223636 000000 0A80A68E0018
2014.02.17 12:31:12.888 0: HMLAN_Parse: HMLAN1 R:E220FFD stat:0000 t:460F592F d:FF r:FFB6 m:95 8610 220FFD 000000 0A74940E0157
2014.02.17 12:31:21.205 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:31:21.216 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460F79BC IDcnt:0001
2014.02.17 12:31:46.216 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:31:46.226 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:460FDB72 IDcnt:0001
2014.02.17 12:32:07.699 0: HMLAN_Parse: HMLAN1 R:E206CF2 stat:0000 t:46102F4F d:FF r:FFBF m:07 8670 206CF2 000000 00324A
2014.02.17 12:32:08.193 0: HMLAN_Parse: HMLAN1 R:E1FC9E5 stat:0000 t:46103140 d:FF r:FFD0 m:B3 8670 1FC9E5 000000 00B647
2014.02.17 12:32:20.133 0: HMLAN_Send: HMLAN1 I:K
2014.02.17 12:32:20.143 0: HMLAN_Parse: HMLAN1 R:E1F4D62 stat:0000 t:461051AE d:FF r:FFBE m:85 8670 1F4D62 000000 007C3C
2014.02.17 12:32:20.328 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:46105FF5 IDcnt:0001
2014.02.17 12:32:37.476 0: HMLAN_Parse: HMLAN1 R:E22382C stat:0000 t:4610A3A7 d:FF r:FFC3 m:EA 8610 22382C 000000 0A78C00A0019
Hi
protLastRcv 2014-02-17 12:32:45
protResnd 7 last_at:2014-02-17 12:32:49
protResndFail 1 last_at:2014-02-17 11:24:18
protSnd 43 last_at:2014-02-17 12:32:45
12:15:00.193 Parse: R:E22382C stat:0000 t:46007C3E d:FF r:FFC3 m:E3 8610 22382C 000000 0A78B80A0019
12:32:37.476 Parse: R:E22382C stat:0000 t:4610A3A7 d:FF r:FFC3 m:EA 8610 22382C 000000 0A78C00A0019
seltam, dass ich nichts sehe. Leider sind die Zeitstempel der protoEvents alle nicht im Log.
Du koenntest aber mit einem clear msgEvents einmal aufraeumen, dann noch einmal probieren.
Zitat von: martinp876 am 17 Februar 2014, 13:16:55
Du koenntest aber mit einem clear msgEvents einmal aufraeumen, dann noch einmal probieren.
Hi,
hab ich gemacht und TATA, sie sind da!
Anbei das list dazu. Muss ich noch etwas machen, oder soll ich mich einfach über diese lösung freuen :D
Danke für die Hilfe jedenfalls!
fhem> list hg.Heizung_ClimRT_tr
Internals:
CFGFN ./FHEM/fhem-heizung.cfg
DEF 21C2DB04
HMLAN1_MSGCNT 588
HMLAN1_RAWMSG E21C2DB,0000,4642E2EA,FF,FFD7,03861021C2DB0000000A68840A0517
HMLAN1_RSSI -41
HMLAN1_TIME 2014-02-17 13:27:39
LASTInputDev HMLAN1
MSGCNT 588
NAME hg.Heizung_ClimRT_tr
NR 90
STATE T: 13.2 desired: 13 valve: 5 %
TYPE CUL_HM
chanNo 04
device hg.Heizung
CHANGETIME:
Helper:
Dblog:
R-boostperiod:
Mydblog:
TIME 1392637025.38695
VALUE 15 min
Mydblogsql:
TIME 1392637025.77901
VALUE 15 min
R-boostpos:
Mydblog:
TIME 1392637025.38695
VALUE 80
Mydblogsql:
TIME 1392637025.77901
VALUE 80
R-btnnobcklight:
Mydblog:
TIME 1392637025.38695
VALUE off
Mydblogsql:
TIME 1392637025.77901
VALUE off
R-daytemp:
Mydblog:
TIME 1392637025.38695
VALUE 21 C
Mydblogsql:
TIME 1392637025.77901
VALUE 21 C
R-daylightsavetime:
Mydblog:
TIME 1392637025.38695
VALUE on
Mydblogsql:
TIME 1392637025.77901
VALUE on
R-decalctime:
Mydblog:
TIME 1392637025.38695
VALUE 11:00
Mydblogsql:
TIME 1392637025.77901
VALUE 11:00
R-decalcweekday:
Mydblog:
TIME 1392637025.38695
VALUE Sat
Mydblogsql:
TIME 1392637025.77901
VALUE Sat
R-modepriomanu:
Mydblog:
TIME 1392637025.38695
VALUE all
Mydblogsql:
TIME 1392637025.77901
VALUE all
R-modeprioparty:
Mydblog:
TIME 1392637025.38695
VALUE all
Mydblogsql:
TIME 1392637025.77901
VALUE all
R-nighttemp:
Mydblog:
TIME 1392637025.38695
VALUE 17 C
Mydblogsql:
TIME 1392637025.77901
VALUE 17 C
R-nominmax4manu:
Mydblog:
TIME 1392637025.38695
VALUE off
Mydblogsql:
TIME 1392637025.77901
VALUE off
R-regadaptive:
Mydblog:
TIME 1392637025.38695
VALUE on
Mydblogsql:
TIME 1392637025.77901
VALUE on
R-reguexti:
Mydblog:
TIME 1392637025.38695
VALUE 15
Mydblogsql:
TIME 1392637025.77901
VALUE 15
R-reguextp:
Mydblog:
TIME 1392637025.38695
VALUE 30
Mydblogsql:
TIME 1392637025.77901
VALUE 30
R-reguextpstart:
Mydblog:
TIME 1392637025.38695
VALUE 30
Mydblogsql:
TIME 1392637025.77901
VALUE 30
R-reguinti:
Mydblog:
TIME 1392637025.38695
VALUE 15
Mydblogsql:
TIME 1392637025.77901
VALUE 15
R-reguintp:
Mydblog:
TIME 1392637025.38695
VALUE 30
Mydblogsql:
TIME 1392637025.77901
VALUE 30
R-reguintpstart:
Mydblog:
TIME 1392637025.38695
VALUE 30
Mydblogsql:
TIME 1392637025.77901
VALUE 30
R-showinfo:
Mydblog:
TIME 1392637025.38695
VALUE time
Mydblogsql:
TIME 1392637025.77901
VALUE time
R-showweekday:
Mydblog:
TIME 1392637025.38695
VALUE off
Mydblogsql:
TIME 1392637025.77901
VALUE off
R-sign:
Mydblog:
TIME 1392627219.57853
VALUE off
Mydblogsql:
TIME 1392627219.59655
VALUE off
R-tempmax:
Mydblog:
TIME 1392637025.38695
VALUE 25 C
Mydblogsql:
TIME 1392637025.77901
VALUE 25 C
R-tempmin:
Mydblog:
TIME 1392637025.38695
VALUE 4.5 C
Mydblogsql:
TIME 1392637025.77901
VALUE 4.5 C
R-tempoffset:
Mydblog:
TIME 1392637025.38695
VALUE -1.0K
Mydblogsql:
TIME 1392637025.77901
VALUE -1.0K
R-valveerrpos:
Mydblog:
TIME 1392637025.38695
VALUE 15
Mydblogsql:
TIME 1392637025.77901
VALUE 15
R-valvemaxpos:
Mydblog:
TIME 1392637025.38695
VALUE 100
Mydblogsql:
TIME 1392637025.77901
VALUE 100
R-valveoffsetrt:
Mydblog:
TIME 1392637025.38695
VALUE 0
Mydblogsql:
TIME 1392637025.77901
VALUE 0
R-winopnboost:
Mydblog:
TIME 1392637025.38695
VALUE off
Mydblogsql:
TIME 1392637025.77901
VALUE off
R-winopndetfall:
Mydblog:
TIME 1392637025.38695
VALUE 1.4 K
Mydblogsql:
TIME 1392637025.77901
VALUE 1.4 K
R-winopnmode:
Mydblog:
TIME 1392637025.38695
VALUE on
Mydblogsql:
TIME 1392637025.77901
VALUE on
R-winopnperiod:
Mydblog:
TIME 1392637025.38695
VALUE 15 min
Mydblogsql:
TIME 1392637025.77901
VALUE 15 min
R-winopntemp:
Mydblog:
TIME 1392637025.38695
VALUE 12 C
Mydblogsql:
TIME 1392637025.77901
VALUE 12 C
T:
Mydblog:
TIME 1392640059.11817
VALUE 13.2 desired: 13 valve: 5
Mydblogsql:
TIME 1392640059.17603
VALUE 13.2 desired: 13 valve: 5
Valveposition:
Mydblog:
TIME 1392640059.11817
VALUE 5
Mydblogsql:
TIME 1392640059.17603
VALUE 5
Desired-temp:
Mydblog:
TIME 1392640059.11817
VALUE 13
Mydblogsql:
TIME 1392640059.17603
VALUE 13
Measured-temp:
Mydblog:
TIME 1392640059.11817
VALUE 13.2
Mydblogsql:
TIME 1392640059.17603
VALUE 13.2
Mode:
Mydblog:
TIME 1392640059.11817
VALUE auto
Mydblogsql:
TIME 1392640059.17603
VALUE auto
Motorerr:
Mydblog:
TIME 1392640059.11817
VALUE ok
Mydblogsql:
TIME 1392640059.17603
VALUE ok
Templistfri:
Mydblog:
TIME 1392637025.38695
VALUE 24:00 13.0
Mydblogsql:
TIME 1392637025.77901
VALUE 24:00 13.0
Templistmon:
Mydblog:
TIME 1392637025.38695
VALUE 24:00 13.0
Mydblogsql:
TIME 1392637025.77901
VALUE 24:00 13.0
Templistsat:
Mydblog:
TIME 1392637025.38695
VALUE 24:00 13.0
Mydblogsql:
TIME 1392637025.77901
VALUE 24:00 13.0
Templistsun:
Mydblog:
TIME 1392637025.38695
VALUE 24:00 13.0
Mydblogsql:
TIME 1392637025.77901
VALUE 24:00 13.0
Templistthu:
Mydblog:
TIME 1392637025.38695
VALUE 24:00 13.0
Mydblogsql:
TIME 1392637025.77901
VALUE 24:00 13.0
Templisttue:
Mydblog:
TIME 1392637025.38695
VALUE 24:00 13.0
Mydblogsql:
TIME 1392637025.77901
VALUE 24:00 13.0
Templistwed:
Mydblog:
TIME 1392637025.38695
VALUE 24:00 13.0
Mydblogsql:
TIME 1392637025.77901
VALUE 24:00 13.0
Templist_state:
Mydblog:
TIME 1392637025.38695
VALUE verified
Mydblogsql:
TIME 1392637025.77901
VALUE verified
Readings:
2014-02-17 12:37:04 R-boostPeriod 15 min
2014-02-17 12:37:04 R-boostPos 80 %
2014-02-17 12:37:04 R-btnNoBckLight off
2014-02-17 12:37:04 R-dayTemp 21 C
2014-02-17 12:37:04 R-daylightSaveTime on
2014-02-17 12:37:04 R-decalcTime 11:00
2014-02-17 12:37:04 R-decalcWeekday Sat
2014-02-17 12:37:04 R-modePrioManu all
2014-02-17 12:37:04 R-modePrioParty all
2014-02-17 12:37:04 R-nightTemp 17 C
2014-02-17 12:37:04 R-noMinMax4Manu off
2014-02-17 12:37:04 R-regAdaptive on
2014-02-17 12:37:04 R-reguExtI 15
2014-02-17 12:37:04 R-reguExtP 30
2014-02-17 12:37:04 R-reguExtPstart 30
2014-02-17 12:37:04 R-reguIntI 15
2014-02-17 12:37:04 R-reguIntP 30
2014-02-17 12:37:04 R-reguIntPstart 30
2014-02-17 12:37:04 R-showInfo time
2014-02-17 12:37:04 R-showWeekday off
2014-02-17 09:53:39 R-sign off
2014-02-17 12:37:04 R-tempMax 25 C
2014-02-17 12:37:04 R-tempMin 4.5 C
2014-02-17 12:37:04 R-tempOffset -1.0K
2014-02-17 12:37:04 R-valveErrPos 15 %
2014-02-17 12:37:04 R-valveMaxPos 100 %
2014-02-17 12:37:04 R-valveOffsetRt 0 %
2014-02-17 12:37:04 R-winOpnBoost off
2014-02-17 12:37:04 R-winOpnDetFall 1.4 K
2014-02-17 12:37:04 R-winOpnMode on
2014-02-17 12:37:04 R-winOpnPeriod 15 min
2014-02-17 12:37:04 R-winOpnTemp 12 C
2014-02-17 12:34:57 RegL_01: 08:00 00:00
2014-02-17 12:37:04 RegL_07: 01:2A 02:22 03:09 04:32 05:18 06:03 07:00 08:16 09:05 0A:70 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:35 15:20 16:40 17:54 18:3C 19:C6 1A:41 1B:08 1C:3D 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:35 2F:20 30:40 31:54 32:3C 33:C6 34:41 35:08 36:3D 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:35 49:20 4A:40 4B:54 4C:3C 4D:C6 4E:41 4F:08 50:3D 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:35 63:20 64:40 65:54 66:3C 67:C6 68:41 69:08 6A:3D 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:35 7D:20 7E:40 7F:54 80:3C 81:C6 82:41 83:08 84:3D 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:35 97:20 98:40 99:54 9A:3C 9B:C6 9C:41 9D:08 9E:3D 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 01:2A 02:22 03:09 04:32 05:18 06:03 07:00 08:16 09:05 0A:70 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:35 15:20 16:40 17:54 18:3C 19:C6 1A:41 1B:08 1C:3D 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:35 2F:20 30:40 31:54 32:3C 33:C6 34:41 35:08 36:3D 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:35 49:20 4A:40 4B:54 4C:3C 4D:C6 4E:41 4F:08 50:3D 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:35 63:20 64:40 65:54 66:3C 67:C6 68:41 69:08 6A:3D 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:35 7D:20 7E:40 7F:54 80:3C 81:C6 82:41 83:08 84:3D 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:35 97:20 98:40 99:54 9A:3C 9B:C6 9C:41 9D:08 9E:3D 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:35 B1:20 B2:40 B3:54 B4:3C B5:C6 B6:41 B7:08 B8:3D B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
2014-02-17 13:27:39 ValvePosition 5 %
2014-02-17 13:27:39 desired-temp 13
2014-02-17 13:27:39 measured-temp 13.2
2014-02-17 13:27:39 mode auto
2014-02-17 13:27:39 motorErr ok
2014-02-17 13:27:39 state T: 13.2 desired: 13 valve: 5 %
2014-02-17 12:37:04 tempListFri 24:00 13.0
2014-02-17 12:37:04 tempListMon 24:00 13.0
2014-02-17 12:37:04 tempListSat 24:00 13.0
2014-02-17 12:37:04 tempListSun 24:00 13.0
2014-02-17 12:37:04 tempListThu 24:00 13.0
2014-02-17 12:37:04 tempListTue 24:00 13.0
2014-02-17 12:37:04 tempListWed 24:00 13.0
2014-02-17 12:37:04 tempList_State verified
Templist:
Fri:
0:
HOUR 24
MINUTE 00
TEMP 13.0
Mon:
0:
HOUR 24
MINUTE 00
TEMP 13.0
Sat:
0:
HOUR 24
MINUTE 00
TEMP 13.0
Sun:
0:
HOUR 24
MINUTE 00
TEMP 13.0
Thu:
0:
HOUR 24
MINUTE 00
TEMP 13.0
Tue:
0:
HOUR 24
MINUTE 00
TEMP 13.0
Wed:
0:
HOUR 24
MINUTE 00
TEMP 13.0
Helper:
getCfgListNo
Role:
chn 1
Shregr:
07 00
Shadowreg:
RegL_07: 01:2A 02:22 03:09 04:32 05:18 06:03 07:00 08:16 09:05 0A:70 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:35 15:20 16:40 17:54 18:3C 19:C6 1A:41 1B:08 1C:3D 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:35 2F:20 30:40 31:54 32:3C 33:C6 34:41 35:08 36:3D 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:35 49:20 4A:40 4B:54 4C:3C 4D:C6 4E:41 4F:08 50:3D 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:35 63:20 64:40 65:54 66:3C 67:C6 68:41 69:08 6A:3D 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:35 7D:20 7E:40 7F:54 80:3C 81:C6 82:41 83:08 84:3D 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:35 97:20 98:40 99:54 9A:3C 9B:C6 9C:41 9D:08 9E:3D 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 01:2A 02:22 03:09 04:32 05:18 06:03 07:00 08:16 09:05 0A:70 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:35 15:20 16:40 17:54 18:3C 19:C6 1A:41 1B:08 1C:3D 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:35 2F:20 30:40 31:54 32:3C 33:C6 34:41 35:08 36:3D 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:35 49:20 4A:40 4B:54 4C:3C 4D:C6 4E:41 4F:08 50:3D 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:35 63:20 64:40 65:54 66:3C 67:C6 68:41 69:08 6A:3D 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:35 7D:20 7E:40 7F:54 80:3C 81:C6 82:41 83:08 84:3D 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:35 97:20 98:40 99:54 9A:3C 9B:C6 9C:41 9D:08 9E:3D 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:35 B1:20 B2:40 B3:54 B4:3C B5:C6 B6:41 B7:08 B8:3D B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
Attributes:
expert 2_full
group Heizung
model HM-CC-RT-DN
peerIDs
room Device
fhem>
das reicht erst mal ;)
Nochmals danke!
Jetzt stellt sich bei mir die Frage, oh ich alle HM-Komponenten mal "aktualisieren" sollte.
Seit meinem Einstieg in HM sind doch schon viele Monate vergangen, gewisse readings gibt es nicht mehr,
andere sind neu dazugekommen...
Um Probleme im Betrieb (wenn meine Frauetwas verstellen will), könnte ich mir vorstellen, dass
diese Befehle bei allen Komponenten mal ausgeführtt werden sollen?!
Stimmt diese reihenfolge?
clear msgEvents
clear readings
set getConfig
nutze HMInfo
da kannst du alle Register readings clearen, auch alle protokol-events.
Dann kannst du ein autoReadReg anstossen (geht evtl auch automatisch) - fuer alle devices, die du freigeschaltet hast.
mit protoEvents short pruefen, wann fertig ist und dass alles glatt gelaufen ist. ggf einzelne Devices wieder loeschen (readings und protokol - wegen der uebersichtlichkeit) - kann man ggf aus HMInfo durch fitler erreichen
mit configCheck pruefen, dass alles da ist
saveConfig speichert die Regiserlisten - das File evtl sichern... man kann es zuruecklesen, z.B. fuer config devices, die nicht einfach zu lesen sind.
Danke für die tolle Liste an Befehlen:
Da scheint ja einiges iM Argen zu sein bei mir.
Gibt es irgendwo eine Info, was diese Einträge alles bedeuten und was ich hier machen sollte?
commandref gibt zu configCheck nicht viel hilfreiches her...
fhem> set hminfo configCheck
configCheck done:
missing register list
aussenThermometerHM: RegL_00:
bz.Hyygro: RegL_00:
temp.og.Gaestezimmer_ClimRT_tr: .RegL_01:,.RegL_07:
temp.og.Gaestezimmer_ClimaTeam: .RegL_01:
temp.og.Gaestezimmer_Climate: .RegL_01:
temp.og.Gaestezimmer_Weather: .RegL_01:
temp.og.Gaestezimmer_WindowRec: .RegL_01:
temp.og.Gaestezimmer_remote: .RegL_01:
ug.Stauraum: RegL_00:
wz.Bedienung.device: RegL_00:
wz.Bedienung_01: .RegL_01:
wz.Bedienung_02: .RegL_01:,.RegL_04:wz.Bedienung.virt_Btn2
wz.Bedienung_03: .RegL_01:
wz.Bedienung_04: .RegL_01:,.RegL_04:wz.Bedienung.virt_Btn4
wz.Bedienung_05: .RegL_01:,.RegL_04:wz.Bedienung.virt_Btn5
wz.Bedienung_06: .RegL_01:,.RegL_04:wz.Bedienung.virt_Btn6
xx.Neigungsmesser: RegL_00:
Register changes pending
bd.Handtuchtrockner
hg.Heizung_ClimRT_tr
peer list not read
empty: aussenThermometerHM
empty: wz.Bedienung_01
empty: xx.Neigungsmesser
peer list incomplete
incomplete: wz.Bedienung_02:12345602,
incomplete: wz.Bedienung_04:12345604,
incomplete: wz.Bedienung_05:12345605,
incomplete: wz.Bedienung_06:12345606,
peer not verified
wz.Sonos p:wz.Bedienung.virt_Btn2
PairedTo missing/unknown
aussenThermometerHM
wz.Bedienung.device
xx.Neigungsmesser
fhem>
nein, gibt es so nicht.
Ich dachte die Namen sind hilfe genug
missing register listDiese Listen fehlen - sollte sich mit getConfig beheben lassen
Register changes pendingEs sind Aenderungen vorgenommen worden, aber nicht durchgeführt oder zumindest nicht bestätigt. Es sollte irgendwo ein set_ stehen
peer list not readListe der Peers ist nicht gelesen -> getConfig
peer list incompletepeerliste nicht komplett - -> getConfig
Zitatpeer not verified
peering konnte nicht verifiziert werden. wz.Sonos ist mit p:wz.Bedienung.virt_Btn2 gepeert, aber bei p:wz.Bedienung.virt_Btn2 konnte kein peering zu wz.Sonos gefunden werden.
=> koennte sein, p:wz.Bedienung.virt_Btn2 schlecht auszulesen ist (config device?). Hier kann man die Registerlisten einmal lesen und dann in einem File speichern (saveConfig). Beim Booten kann man dann einbauen, dass die Register/peers dieses Devices aus dem File geladen werden. Da muss man dann etwas aufpassen...
Auch möglich - archConfig! - und daraus laden...
PairedTo missing/unknownes kann nicht gelesen werden ob und wohin das device gepeert ist. (registerliste 0 fehlt evtl).
Das configCheck werden ich immer wieder erweitern, wenn es sinnvolle prüfungen gibt, auf die man User hinweisen sollte
Mal ehrlich - ist die Überschrift zu verstehen?
Gruss Martin
Zitat von: martinp876 am 17 Februar 2014, 15:01:06
saveConfig speichert die Regiserlisten - das File evtl sichern... man kann es zuruecklesen, z.B. fuer config devices, die nicht einfach zu lesen sind.
Hallo Martin,
kann man die non-wake-up devices (HM-SEC-SC etc.) excluden?
Edit: Hintergrund - die die es können automatisiert aktualisieren - den Rest mauell/dediziert.
Die Infos müssten bekannt sein - zumindest von den unterstützen devices - oder?
Viele Grüße
Arthur
Hallo Arthur,
Zitatkann man die non-wake-up devices (HM-SEC-SC etc.) excluden?
ungern. Wenn ich z.b. das peering pruefen, ob es beidseitig ist, brauche ich die Daten sowieso.
ZitatEdit: Hintergrund - die die es können automatisiert aktualisieren - den Rest mauell/dediziert.
ich sehe das Problem. Es gibt mehrere optionen, es zu loesen. Den praxistest muessen sie noch bestehen.
a) config devices separat speichern und einlesen.
a1) getConfig dieser Devices lesen(
device getConfig), pruefen(ggf einzeln) (
hm checkConfig -f device) und speichern in ein separates file
hm saveConfig -f device myConfigDeviceRegister.cfga2) der User kann/muss es nach jeder Aenderung wieder ausfuehren.
a3) der User legt sich ein fhemUsr.cfg an, das er per notify aus den fhem.cfg ausfuehrt. in diesem file macht er ein loadConfig myConfigDeviceRegister.cfg. Die Register sind entsprechend dem letzten save vorhanden.
b) archConfig einschalten (siehe docu). FHEM speichert alle register automatisch (also ein automatisches saveConfig) wenn register neu gelesen wurden. default filename ist
regSave.cfgb1) der User sollte sich wieder ein fhemUsr.cfg anlegen und es aus fhem.cfg triggern lassen. In dem file macht er ein loadConfig regSave.cfg -f device1|device2|device3 - oder mehrere loadConfig, eins fuer jedes config device
Fuer guten stil halte ich, config daten in einer eigenen directoy unterzubringen. Siehe hierzu
configDir configFilename aus HMInfo
kommt das hin? Andere Vorschlaege?
Man sollte, wenn es zusagt, ein best-current-practice in wiki eerstellen, das so etwas erklaert - wiki mache ich nicht, vielleicht findet sich jemand.
p.s. - aus dem file gelesene readings erhalten einen gesonderten Zeitstempel - kein Uhrzeit. Abgeleitete Readings (also register R-... ) haben den des Restart
- loadConfig ueberschreibt nicht vorhandene Readings, es ersetzt nur fehlende.
Gruss Martin
Zitat von: martinp876 am 18 Februar 2014, 08:39:58
Hallo Arthur,
ungern. Wenn ich z.b. das peering pruefen, ob es beidseitig ist, brauche ich die Daten sowieso.
ich sehe das Problem. Es gibt mehrere optionen, es zu loesen. Den praxistest muessen sie noch bestehen.
a) config devices separat speichern und einlesen.
a1) getConfig dieser Devices lesen(device getConfig), pruefen(ggf einzeln) (hm checkConfig -f device) und speichern in ein separates file hm saveConfig -f device myConfigDeviceRegister.cfg
a2) der User kann/muss es nach jeder Aenderung wieder ausfuehren.
a3) der User legt sich ein fhemUsr.cfg an, das er per notify aus den fhem.cfg ausfuehrt. in diesem file macht er ein loadConfig myConfigDeviceRegister.cfg. Die Register sind entsprechend dem letzten save vorhanden.
b) archConfig einschalten (siehe docu). FHEM speichert alle register automatisch (also ein automatisches saveConfig) wenn register neu gelesen wurden. default filename ist regSave.cfgb1) der User sollte sich wieder ein fhemUsr.cfg anlegen und es aus fhem.cfg triggern lassen. In dem file macht er ein loadConfig regSave.cfg -f device1|device2|device3 - oder mehrere loadConfig, eins fuer jedes config device
Fuer guten stil halte ich, config daten in einer eigenen directoy unterzubringen. Siehe hierzu
configDir configFilename aus HMInfo
kommt das hin? Andere Vorschlaege?
Man sollte, wenn es zusagt, ein best-current-practice in wiki eerstellen, das so etwas erklaert - wiki mache ich nicht, vielleicht findet sich jemand.
p.s. - aus dem file gelesene readings erhalten einen gesonderten Zeitstempel - kein Uhrzeit. Abgeleitete Readings (also register R-... ) haben den des Restart
- loadConfig ueberschreibt nicht vorhandene Readings, es ersetzt nur fehlende.
Gruss Martin
Hallo Martin,
sorry, meine Frage bezog sich auf "clearReadings".
Man (ich) könnte dann "auch manuell" ein "clearReadings" auf wake-up devices triggern - bei non-wake-up eben dediziert (manuell).
Mit saveConfig habe ich mich noch nicht beschäftigt.
Viele Grüße
Arthur
Hallo,
wie setzt man denn die Werte mit dem R-davor? z.B R-dayTemp?
Mit set <device> dayTemp oder R-dayTemp beschwert fhem sich.
Gruß George
mit regSet -> siehe commandref Dokumentation
danke, hat bedingt geklappt. Ich habe mit
set <device>_Clima regSet prep dayTemp 20
set <device>_Clima regSet exec nightTemp 17
Werte verändern wollen, jetzt steht da
R-dayTemp set_20
R-nightTemp set_17
sollte da nicht jetzt 20 und 17 statt set_20 set_17 stehen?
Hab ich auch ;-)
Macht mal ein getConfig und wartet 5 Minuten.
Warten hilft !
Hi,
wie bekomme ich denn den adaptive mode wieder eingeschaltet?
fhem> set ug_kr_heiz_climrt regSet regAdaptive on
invalid value. use:offDefault,offDeter,on
Rainer
set ug_kr_heiz_climrt regSet regAdaptive offDefault
sollte funzen
nein.
offDefault schaltet adaptive aus und nutzt die default parametern von HM
On wäre korrekt. geht bei mir auch.
ist die SW aktuell? Update?
Update habe ich kurz vorher gemacht - incl. restart.
# $Id: 10_CUL_HM.pm 5262 2014-03-20 19:02:12Z martinp876 $
# $Id: 00_HMLAN.pm 5246 2014-03-17 19:15:05Z martinp876 $
# $Id: 98_HMinfo.pm 5255 2014-03-18 22:28:22Z martinp876 $
Das ist auf nem Debian wheezy mit perl 5.14.2.
offDefault hat er genommen - auch wenns - wie du bestaetigst was anderes ist. Hatte letztens noch ein anderes Register das kein "on" wollte obwohls in der Liste gueltiger optionen stand... kann mich aber nicht an details erinnern, leider.
fhem> list ug_kr_heiz_climrt
Internals:
DEF 221F1C04
HMUG_MSGCNT 43
HMUG_RAWMSG E221F1C,0000,50DB82BC,FF,FFCE,CA8610221F1C0000000AA0C40E6458
HMUG_RSSI -50
HMUG_TIME 2014-03-21 17:09:23
LASTInputDev HMUG
MSGCNT 43
NAME ug_kr_heiz_climrt
NR 820
STATE T: 19.6 desired: 20.0 valve: 100
TYPE CUL_HM
chanNo 04
device ug_kr_heiz
Readings:
2014-01-19 16:58:10 R-boostPeriod 5 min
2014-01-26 20:14:25 R-boostPos 100 %
2014-03-15 11:05:01 R-btnNoBckLight desired-temp
2014-01-19 16:58:10 R-dayTemp 21 C
2014-03-15 11:05:01 R-daylightSaveTime desired-temp
2014-03-15 11:05:01 R-decalcTime 11:00
2014-03-15 11:05:01 R-decalcWeekday Sat
2014-03-15 11:05:01 R-modePrioManu all
2014-03-15 11:05:01 R-modePrioParty all
2014-01-19 16:58:10 R-nightTemp 17 C
2014-03-15 11:05:01 R-noMinMax4Manu desired-temp
2014-03-15 11:05:01 R-regAdaptive offDefault
2014-03-15 11:05:01 R-reguExtI 10
2014-03-15 11:05:01 R-reguExtP 25
2014-03-15 11:05:01 R-reguExtPstart 5
2014-03-15 11:05:01 R-reguIntI 15
2014-03-15 11:05:01 R-reguIntP 30
2014-03-15 11:05:01 R-reguIntPstart 30
2014-03-15 11:05:01 R-showInfo time
2014-03-15 11:05:01 R-showWeekday desired-temp
2014-03-21 17:06:53 R-sign off
2014-01-19 16:58:10 R-tempMax 30.5 C
2014-01-19 16:58:10 R-tempMin 4.5 C
2014-03-15 11:05:01 R-tempOffset 0.0K
2014-01-26 20:14:25 R-valveErrPos 5 %
2014-01-19 16:58:10 R-valveMaxPos 100 %
2014-01-19 16:58:10 R-valveOffsetRt 0 %
2014-03-15 11:05:01 R-winOpnBoost desired-temp
2014-01-19 16:58:10 R-winOpnDetFall 1.4 K
2014-03-15 11:05:01 R-winOpnMode desired-temp
2014-01-19 16:58:10 R-winOpnPeriod 15 min
2014-01-19 16:58:10 R-winOpnTemp 12 C
2014-03-21 17:06:53 RegL_01: 08:00 00:00
2014-03-21 17:06:57 RegL_07: 01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:34 0B:00 0C:64 0D:05 0E:01 0F:00 10:00 11:00 12:09 13:8E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20
2014-03-21 17:09:23 ValvePosition 100
2014-03-21 17:09:23 desired-temp 20.0
2014-03-21 17:09:23 measured-temp 19.6
2014-03-21 17:09:23 mode manu
2014-03-21 17:09:23 motorErr ok
2014-03-21 17:09:23 state T: 19.6 desired: 20.0 valve: 100
2014-03-15 11:05:01 tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2014-03-15 11:05:01 tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2014-03-15 11:05:01 tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
2014-03-15 11:05:01 tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
2014-03-15 11:05:01 tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2014-03-15 11:05:01 tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2014-03-15 11:05:01 tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2014-03-15 11:05:01 tempList_State verified
Helper:
getCfgListNo
Role:
chn 1
Shregr:
07 00
Shadowreg:
RegL_07: 01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:34 0B:00 0C:64 0D:05 0E:01 0F:00 10:00 11:00 12:09 13:8E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0A CE:19 CF:05 00:00
Attributes:
butler_heizkoerper eco
event-on-change-reading .*
eventMap /desired-temp on:on/desired-temp off:off/desired-temp 12:frost/desired-temp 20:eco/desired-temp 21:comfort/desired-temp 20:home/desired-temp 12:nacht/desired-temp on:summer/
group Heizkoerper
icon sani_heating
model HM-CC-RT-DN
peerIDs
room ug_kr,ug,d_heizung
structexclude .*:.*
webCmd on:off:frost:eco:comfort:home:nacht:summer:desired-temp
hm...
kannst du es einmal probieren - und vorher die eventmap löschen?
Gruss Martin
Ohne eventMap gehts. Danke fürs Augen öffnen.
Mit fortschreitender Nutzung verstehe ich immer weniger wie die eventMap tickt. Aber das ist keine HM Thema also OT ;)
Dear all!
I few days ago I bought 1x Homematic wireless radiator Thermostat HM-CC-RT-DN. I managed to install it and connected (paired) to Fhem server (runs on linux) through USB Stick (HM-CFG-USB USB-2). In fhem.cfg file I used the following definition:
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId F11234
define spalnica_radiator CUL_HM 2553BA
The system without any problems read the data every 2 to 3 minutes but the problem is that I am not able to control the thermostat. I tried to change the following:
set spalnica_radiator_Clima controlMode day
set spalnica_radiator_Clima controlManu 30.0
set spalnica_radiator_Clima contolMode day
set spalnica_radiator_Clima desired-temp 15.0
Unfortunately nothing has changed on thermostat. What I doing wrong?
I am attaching to this message the log file and the definitions of HMUSB + Thermostat device (CUL_HM).
Hej andrejs,
at first sight it seems, you don't have paired your RT.
Possibly autocreate has created the device in FHEM (so you can see some information) but the device doesn't know anything from FHEM. ;-)
So try to open your console, enter:
set hmusb hmPairForSec 60
This command activate the pairing mode in FHEM for 60 seconds.
So go to your RT, press and hold the middle button for some moments. A backward counter starting with 30 should appear and disappear some moments later (after successful pairing).
When this happens, you have paired FHEM with your RT.
After that enter:
set spalnica_radiator getConfig
in your Console and wait some minutes (because the RT wakes up only approximately every 2.5 minutes).
After that you should see a line in your RT device section like
2014-05-10 23:29:40 R-pairCentral 0xF11234
This line (and only this line) tells you, that the RT reported the correct pairing to your FHEM. :-)
Thanks Mr.P for your help. It works!!!!
You're welcome! :-)
Hi,
Situation:
Aus verschiedenen Gründen betreibe ich meine RT-DN im manual mode - leider vergessen die das aber gelegentlich Also habe ich nen Job laufen, der alle 15min prüft, ob sie sich auf auto geschaltet haben (was meißt mit einer Änderung der desired-temp einhergeht) und ihnen mittels "set $name controlManu $temp" wieder den richtigen mode + temp gibt. Das gleiche passiert mir übrigens bei den TC-IT. Kommt nicht vom fhem und ist laut raw log auch kein "Freund".
Soweit egal - nur als Hintergrund, mein "Problem":
Seit einem der letzten updates sehe ich aber in dem Reading "mode" nur noch "set_manual". Früher war da der aktuelle mode drin. Habe ich jetzt umgebaut auf "controlMode" - aber der verwaiste "mode" irritiert mich jedes mal. Ist das Absicht?
Rainer
Hej Rainer,
Zitat von: geek am 16 Juli 2014, 19:56:33
Seit einem der letzten updates sehe ich aber in dem Reading "mode" nur noch "set_manual". Früher war da der aktuelle mode drin. Habe ich jetzt umgebaut auf "controlMode" - aber der verwaiste "mode" irritiert mich jedes mal. Ist das Absicht?
Hab es mir gerade angesehen. Bin mir recht sicher, dass es so nicht geplant war. Aber da müssen wir wohl auf ein Feedback von Martin warten. ;-)
Zitat von: geek am 16 Juli 2014, 19:56:33
Aus verschiedenen Gründen betreibe ich meine RT-DN im manual mode - leider vergessen die das aber gelegentlich Also habe ich nen Job laufen, der alle 15min prüft, ob sie sich auf auto geschaltet haben (was meißt mit einer Änderung der desired-temp einhergeht) und ihnen mittels "set $name controlManu $temp" wieder den richtigen mode + temp gibt. Das gleiche passiert mir übrigens bei den TC-IT. Kommt nicht vom fhem und ist laut raw log auch kein "Freund".
Wenn das von dir gemeldete auch sicher geregelt gehört, würde ich in deinem Fall dennoch aufhören, mich um einen Workaround zu kümmern und stattdessen eher die Ursache ausfindig machen.
Scheinen in deiner FHEM-Installation fremde Geräte auf? Klingt ja beinahe so, als hättest du einen Nachbarn, der dir in die Quere kommt.
Prüfe, ob außer von deinen Geräten noch andere "herumschwirren", ändere einmal deine HMID und wenn alles nichts hilft, würde ich mir doch überlegen, AES zu aktivieren. Es gibt auch irgendwie in FHEM die Möglichkeit zu kontrollieren, ob dein FHEM-Server Daten von Eindringlingen (anderen FHEM-Servern mit der selben HMID) empfängt. Musst du im Forum nachsehen, wie das klappt. ;-)
Zitat von: geek am 16 Juli 2014, 19:56:33
Seit einem der letzten updates sehe ich aber in dem Reading "mode" nur noch "set_manual". Früher war da der aktuelle mode drin. Habe ich jetzt umgebaut auf "controlMode"...
Wann war das letzte Update denn? Die Steuerung war zwischenzeitlich bzgl. Manual etwas derangiert.
Das findest du hier:
http://forum.fhem.de/index.php/topic,24880.msg182270.html#msg182270 (http://forum.fhem.de/index.php/topic,24880.msg182270.html#msg182270)
Mach mal ein Update. Vielleicht ist es ja schon wieder gut...
Zitat von: Mr. P am 17 Juli 2014, 00:50:23
Hab es mir gerade angesehen. Bin mir recht sicher, dass es so nicht geplant war. Aber da müssen wir wohl auf ein Feedback von Martin warten. ;-)
ja, genau das war meine Idee.
Zitat von: Mr. P am 17 Juli 2014, 00:50:23
Wenn das von dir gemeldete auch sicher geregelt gehört, würde ich in deinem Fall dennoch aufhören, mich um einen Workaround zu kümmern und stattdessen eher die Ursache ausfindig machen.
Ich halte das für einen Firmware bug. Habe den HM Traffic ne Weile Raw mitgeschnitten und da ist nix. Weder von Fhem noch von Fremden. Attack detection schlägt auch nicht zu. Window open detection ist auch aus (soll laut changelog vor 1.2 Probleme damit gegeben haben).
Zitat von: Deudi am 17 Juli 2014, 07:44:28
Wann war das letzte Update denn? Die Steuerung war zwischenzeitlich bzgl. Manual etwas derangiert.
Das findest du hier:
http://forum.fhem.de/index.php/topic,24880.msg182270.html#msg182270 (http://forum.fhem.de/index.php/topic,24880.msg182270.html#msg182270)
Mach mal ein Update. Vielleicht ist es ja schon wieder gut...
Vor meinen letzten updates in den letzten Tagen lief die Installation länger ohne Änderungen. Der Thread könnte also was damit zu tun haben.
Das letzte update war gestern, bevor ich geposted habe.
Rainer
Zitat von: geek am 17 Juli 2014, 08:50:22
Ich halte das für einen Firmware bug. Habe den HM Traffic ne Weile Raw mitgeschnitten und da ist nix. Weder von Fhem noch von Fremden. Attack detection schlägt auch nicht zu. Window open detection ist auch aus (soll laut changelog vor 1.2 Probleme damit gegeben haben).
Wäre es ein Firmwarebug, dann müssten aber alle RTs von allen davon betroffen sein. Da ich aber sonst niemanden mit dem Problem kenne, halte ich das für sehr unwahrscheinlich. ;-)
Könntest du rein Interesse halber einmal das Logging für einen deiner RTs aufdrehen und nach besagten umschalten das Log gemeinsam mit einem Listing von deinem RT (Device + Channels) einmal posten? Würde trotz allem gerne einmal einen Blick darauf machen.
Also meine Laufen seit Anfang des Sommers im Manual-mode und schalten sich nicht allein nach Auto. Firmware 1.2. Das einzige, was ich mir spontan noch vorstellen könnte, ist dass jemand ausversehen auf die linke Taste kommt. Bei uns passierte das ab und an mal - durch unsere Katze, die es sich auf der Heizung bequem gemacht hat. Bei ihren Lieblingsheizkörpern hab ich deshalb nun die Tastensperre gesetzt ;-)
Abstauben und abwischen führt bei mir zuhause immer wieder zu solchen Effekten :-)
Deswegen habe ich generell auch die globale Tastensperre drin :o
Hi,
Tastensperre hatte ich auch ne weile drin - ohne Veränderung.
Meine RT-DN haben erst vor ner Woche die 1.2 firmware bekommen. Habe das raw logging (für Mr. P) erst wieder seit gestern an. Die RT-DN haben bisher noch nicht wieder selbstständig umgeschaltet. Raw log kommt, sobald das wieder aufgetreten ist.
Das log zeigt aber, das nach einem "set xx controlManu yy" der RT-DN beim nächsten update oft controlMode=auto meldet.
Die TC-IT zeigen übrigens die gleichen Symptome.
set:
2014.07.17 22:06:45.268 3: CUL_HM set eg_of_heiz_climrt controlManu on
2014.07.17 22:07:00.148 0: HMLAN_Parse: HMEG R:E2217DC stat:0000 t:1154BBB5 d:FF r:FFCE m:4D 8610 2217DC 000000 0A90F10E0022
2014.07.17 22:07:00.244 0: HMLAN_Send: HMEG S:S45EF5C7C stat: 00 t:00000000 d:01 r:45EF5C7C m:75 A112 83D2E0 2217DC
2014.07.17 22:07:00.263 0: HMLAN_Parse: HMUG R:E2217DC stat:0000 t:02D7C7FF d:FF r:FFA2 m:4D 8610 2217DC 000000 0A90F10E0022
2014.07.17 22:07:00.273 0: HMLAN_Parse: HMUG R:E83D2E0 stat:0000 t:02D7C87A d:FF r:FF9C m:75 A112 83D2E0 2217DC
2014.07.17 22:07:00.401 0: HMLAN_Parse: HMEG R:R45EF5C7C stat:0001 t:1154BCB7 d:FF r:FFCD m:75 8002 2217DC 83D2E0 00
2014.07.17 22:07:00.502 0: HMLAN_Send: HMEG S:+2217DC,02,01,00
2014.07.17 22:07:00.502 0: HMLAN_Send: HMEG S:S45EF5D7A stat: 00 t:00000000 d:01 r:45EF5D7A m:76 A011 83D2E0 2217DC 81043D
2014.07.17 22:07:00.504 0: HMLAN_Parse: HMUG R:E2217DC stat:0000 t:02D7C8FC d:FF r:FF9C m:75 8002 2217DC 83D2E0 00
2014.07.17 22:07:00.679 0: HMLAN_Parse: HMUG R:E83D2E0 stat:0000 t:02D7CA10 d:FF r:FF9A m:76 A011 83D2E0 2217DC 81043D
2014.07.17 22:07:00.808 0: HMLAN_Parse: HMEG R:R45EF5D7A stat:0001 t:1154BE4E d:FF r:FFD0 m:76 8002 2217DC 83D2E0 01043D103262
2014.07.17 22:07:00.823 0: HMLAN_Parse: HMUG R:E2217DC stat:0000 t:02D7CA93 d:FF r:FFA3 m:76 8002 2217DC 83D2E0 01043D103262
und der periodische job findet dann beim nächsten lauf controlMode=auto.
2014.07.17 22:08:30.777 3: heizkoerper_manual eg_of_heiz_climrt: auto
2014.07.17 22:08:30.786 3: CUL_HM set eg_of_heiz_climrt controlManu on
list des obigen RT-DN:
list eg_of_heiz_climrt
Internals:
CFGFN ./cfg/eg_of.cfg
DEF 2217DC04
NAME eg_of_heiz_climrt
NR 828
STATE T: 24.0 desired: on valve: 100
TYPE CUL_HM
chanNo 04
device eg_of_heiz
Readings:
2014-07-18 07:51:59 CommandAccepted yes
2013-12-24 12:42:49 R-boostPeriod 5 min
2014-01-26 20:15:37 R-boostPos 100 %
2014-07-14 15:11:18 R-btnNoBckLight off
2013-12-25 09:49:49 R-dayTemp 22 C
2014-07-14 15:11:18 R-daylightSaveTime on
2014-07-14 15:11:18 R-decalcTime 11:00
2014-07-14 15:11:18 R-decalcWeekday Sat
2014-07-14 15:11:18 R-modePrioManu all
2014-07-14 15:11:18 R-modePrioParty all
2013-12-24 12:48:31 R-nightTemp 18 C
2014-07-14 15:11:18 R-noMinMax4Manu off
2014-07-14 15:11:18 R-regAdaptive on
2014-07-14 15:11:18 R-reguExtI 15
2014-07-14 15:11:18 R-reguExtP 30
2014-07-14 15:11:18 R-reguExtPstart 30
2014-07-14 15:11:18 R-reguIntI 15
2014-07-14 15:11:18 R-reguIntP 30
2014-07-14 15:11:18 R-reguIntPstart 27
2014-07-14 15:11:18 R-showInfo time
2014-07-14 15:11:18 R-showWeekday off
2014-07-14 15:11:14 R-sign off
2013-12-24 12:42:49 R-tempMax 30.5 C
2013-12-24 12:42:49 R-tempMin 4.5 C
2014-07-14 15:11:18 R-tempOffset 0.0K
2014-01-26 20:15:37 R-valveErrPos 5 %
2013-12-24 12:42:49 R-valveMaxPos 100 %
2013-12-24 12:42:49 R-valveOffset 0 %
2014-01-08 11:00:19 R-valveOffsetRt 0 %
2014-07-14 15:11:18 R-winOpnBoost off
2014-04-18 21:16:58 R-winOpnDetFall 1.4 K
2014-07-14 15:11:18 R-winOpnMode off
2013-12-24 12:42:49 R-winOpnPeriod 15 min
2013-12-24 12:42:49 R-winOpnTemp 12 C
2014-07-14 15:27:07 R_0_tempListSat 24:00 18.0
2014-07-14 15:27:07 R_1_tempListSun 24:00 18.0
2014-07-14 15:27:07 R_2_tempListMon 24:00 18.0
2014-07-14 15:27:07 R_3_tempListTue 24:00 18.0
2014-07-14 15:27:07 R_4_tempListWed 24:00 18.0
2014-07-14 15:27:07 R_5_tempListThu 24:00 18.0
2014-07-14 15:27:07 R_6_tempListFri 24:00 18.0
2014-07-14 15:27:07 R_tempList_State verified
2014-07-18 07:58:45 ValvePosition 100
2014-07-18 07:58:45 controlMode manual
2014-07-18 07:58:45 desired-temp on
2014-07-18 07:58:45 measured-temp 24.0
2014-07-18 07:50:31 mode set_manual
2014-07-18 07:58:45 motorErr ok
2014-07-18 07:51:59 recentStateType ack
2014-07-18 07:58:45 state T: 24.0 desired: on valve: 100
2014-03-15 11:09:19 tempList_State verified
Helper:
Role:
chn 1
Shregr:
07 00
Attributes:
event-on-change-reading .*
expert 1
group Heizkoerper
icon sani_heating
model HM-CC-RT-DN
peerIDs 00000000,
room eg_of,eg,D_heizung
structexclude .*:.*
subType thermostat
webCmd desired-temp
Rainer
Zitat von: geek am 18 Juli 2014, 08:04:31...
Das log zeigt aber, das nach einem "set xx controlManu yy" der RT-DN beim nächsten update oft controlMode=auto meldet.
...
Den Effekt habe ich auch schon beobachtet. Wahrscheinlich bin ich aber beim Testen meist zu ungeduldig, ich nächsten Schritt passt es dann.
Wobei ich anfangs auch immer Fehlermeldungen (wie hier auch schon von anderen gepostet) bekommen habe, wenn ich meine Thermostate zusammen (mittels set .*_Heizung_Clima controlManu off) schalten wollte.
Genauso hat mein Wohnzimmer-Thermostat nach dem Fenster öffnen/schliessen auch immer wieder die desired-temp geändert (was ja bei auto auch richtig wäre); jetzt bleibt er auf manu off stehen. ???
Mit dem aktuellen FHEM-Stand und nach einigen get configs läuft es momentan, aber generell machen mich die Dinger wahnsinnig; das leidige Thema mit dem Temperatur-Istwert reicht ja schon. >:(
Hi,
so, und nun für Mr.P die Logs von nem RT-DN, der sich selber umschaltet - auch mit firmware 1.2:
$ egrep 'ug_bd_heiz|22C44C' log/fhem-2014-07.log
2014.07.18 14:06:46.410 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14C38FB3 d:FF r:FFCE m:BE 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:06:46.513 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:06469CB7 d:FF r:FFB2 m:BE 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:09:44.912 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14C64914 d:FF r:FFCE m:BF 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:09:44.932 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:06495618 d:FF r:FFB1 m:BF 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:12:29.165 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14C8CAC9 d:FF r:FFCD m:C0 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:12:29.281 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:064BD7CE d:FF r:FFB1 m:C0 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:14:58.916 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14CB13D8 d:FF r:FFCC m:C1 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:14:58.975 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:064E20DC d:FF r:FFB0 m:C1 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:17:14.169 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14CD243F d:FF r:FFCC m:C2 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:17:14.273 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:06503146 d:FF r:FFB1 m:C2 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:19:14.920 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14CEFC02 d:FF r:FFCC m:C3 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:19:14.943 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:06520908 d:FF r:FFAF m:C3 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:22:05.422 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14D19622 d:FF r:FFCC m:C4 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:22:05.441 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:0654A328 d:FF r:FFB0 m:C4 8610 22C44C 000000 0AF4CB0D6458
2014.07.18 14:24:41.424 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14D3F79B d:FF r:FFCC m:C5 8610 22C44C 000000 0A88CB0D0018
2014.07.18 14:24:41.445 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:065704A3 d:FF r:FFB1 m:C5 8610 22C44C 000000 0A88CB0D0018
2014.07.18 14:27:02.928 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14D6206F d:FF r:FFCC m:C6 8610 22C44C 000000 0A88CB0D0018
2014.07.18 14:27:03.030 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:06592D79 d:FF r:FFB1 m:C6 8610 22C44C 000000 0A88CB0D0018
2014.07.18 14:28:30.554 3: heizkoerper_manual ug_bd_heiz_climrt: auto
2014.07.18 14:28:30.568 3: CUL_HM set ug_bd_heiz_climrt controlManu on
2014.07.18 14:29:10.178 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14D81197 d:FF r:FFCC m:C7 8610 22C44C 000000 0A88CB0D0018
2014.07.18 14:29:10.274 0: HMLAN_Send: HMEG S:S49728FEB stat: 00 t:00000000 d:01 r:49728FEB m:B3 A112 83D2E0 22C44C
2014.07.18 14:29:10.301 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:065B1EA0 d:FF r:FFB1 m:C7 8610 22C44C 000000 0A88CB0D0018
2014.07.18 14:29:10.303 0: HMLAN_Parse: HMUG R:E83D2E0 stat:0000 t:065B1F1C d:FF r:FFA2 m:B3 A112 83D2E0 22C44C
2014.07.18 14:29:10.432 0: HMLAN_Parse: HMEG R:R49728FEB stat:0001 t:14D81299 d:FF r:FFCC m:B3 8002 22C44C 83D2E0 00
2014.07.18 14:29:10.532 0: HMLAN_Send: HMEG S:+22C44C,02,01,00
2014.07.18 14:29:10.532 0: HMLAN_Send: HMEG S:S497290F1 stat: 00 t:00000000 d:01 r:497290F1 m:B4 A011 83D2E0 22C44C 81043D
2014.07.18 14:29:10.534 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:065B1F9D d:FF r:FFB1 m:B3 8002 22C44C 83D2E0 00
2014.07.18 14:29:10.710 0: HMLAN_Parse: HMUG R:E83D2E0 stat:0000 t:065B20B1 d:FF r:FFA2 m:B4 A011 83D2E0 22C44C 81043D
2014.07.18 14:29:10.838 0: HMLAN_Parse: HMEG R:R497290F1 stat:0001 t:14D81430 d:FF r:FFCC m:B4 8002 22C44C 83D2E0 01043D103858
Rainer
schaltet einfach um... verstehe ich nicht.
Ausser es kommt eine andere Message (broadcast) die du weggefiltert hast.
Also alles zwischen
14:22:05.441 0: HMLAN_Parse: HMUG R:E22C44C stat:0000 t:0654A328 m:C4 8610 22C44C 000000 0A F4CB 0D 64 58
und
14:24:41.424 0: HMLAN_Parse: HMEG R:E22C44C stat:0000 t:14D3F79B m:C5 8610 22C44C 000000 0A 88CB 0D 00 18
wenn da nichts ist - und niemand an den Tasten gespielt hat - ist das Device wohl defekt.
Remotes oder so sind nicht eingerichtet? Die können so etwas erzeugen.
Also noch eine Frage: Was ist da so alles gepeert - in irgend einem Channel?
Zitat von: martinp876 am 19 Juli 2014, 21:01:53
wenn da nichts ist - und niemand an den Tasten gespielt hat - ist das Device wohl defekt.
Wenn ich Rainer richtig verstanden habe, passiert das bei mehreren (oder sogar allen) von seinen RTs (zumindest hat er in einem Post in der Mehrzahl geschrieben), was einen Gerätedefekt zwar immer noch nicht ausschließt, aber die Wahrscheinlichkeit gegen null sinken lässt.
Zitat von: martinp876 am 19 Juli 2014, 21:01:53
Remotes oder so sind nicht eingerichtet? Die können so etwas erzeugen.
Also noch eine Frage: Was ist da so alles gepeert - in irgend einem Channel?
Deshalb wollte ich auch ein Listing von sämtlichen Channels. ;-)
Hi,
ja, das passiert bei allen RT-DN und TC-IT.
Unten ist der list von dem RT-DN, log für den Zeitraum ist angehängt.
Es ist nur der weather channel mit dem weather channel eines TC-IT gepeered. Sonst nix.
An den Tasten war niemand. Hatte auch ohne Erfolg mit den Button locks experimentiert (jetzt wieder aus).
Wie gesagt - ich halte das nicht für ein Fhem Problem. Kann ich mit leben - wenn meine fhem Probleme gelöst sind:
- altes? "mode" reading statt controlMode bei set controlMode http://forum.fhem.de/index.php/topic,24880.msg184677.html#msg184677 (http://forum.fhem.de/index.php/topic,24880.msg184677.html#msg184677) sowie dieser thread
- falscher controlMode aus ack messages bei TC-IT http://forum.fhem.de/index.php/topic,25472.msg184674.html#msg184674 (http://forum.fhem.de/index.php/topic,25472.msg184674.html#msg184674)
- virtual CCU nimmt falschen HMLAN forum.fhem.de/index.php/topic,23008.msg184641.html#msg184641 (http://forum.fhem.de/index.php/topic,23008.msg184641.html#msg184641)
fhem> list ug_bd_heiz
Internals:
CFGFN ./cfg/ug_bd.cfg
DEF 22C44C
HMEG_MSGCNT 1503
HMEG_RAWMSG E22C44C,0000,1BBDD082,FF,FFCF,C3861022C44C0000000AF4D00D6458
HMEG_RSSI -49
HMEG_TIME 2014-07-19 22:37:32
HMUG_MSGCNT 1499
HMUG_RAWMSG E22C44C,0000,0D40DF1E,FF,FFB4,C3861022C44C0000000AF4D00D6458
HMUG_RSSI -76
HMUG_TIME 2014-07-19 22:37:32
IODev HMEG
LASTInputDev HMUG
MSGCNT 3002
NAME ug_bd_heiz
NR 173
STATE CMDs_done
TYPE CUL_HM
channel_01 ug_bd_heiz_weather
channel_02 ug_bd_heiz_climate
channel_03 ug_bd_heiz_window
channel_04 ug_bd_heiz_climrt
channel_05 ug_bd_heiz_climateam
channel_06 ug_bd_heiz_remote
lastMsg No:C3 - t:10 s:22C44C d:000000 0AF4D00D6458
protLastRcv 2014-07-19 22:37:32
protResnd 1 last_at:2014-07-19 06:42:46
protSnd 68 last_at:2014-07-19 22:30:47
protState CMDs_done
rssi_HMEG avg:-53.89 min:-56 max:-52 lst:-53 cnt:38
rssi_at_HMEG avg:-51.04 min:-57 max:-48 lst:-49 cnt:1503
rssi_at_HMUG avg:-79.39 min:-83 max:-76 lst:-76 cnt:1499
Readings:
2014-07-17 09:58:36 Activity alive
2014-07-19 22:30:47 CommandAccepted yes
2014-07-14 16:06:43 D-firmware 1.2
2014-07-14 16:06:43 D-serialNr KEQ0730665
2014-07-14 16:06:45 PairedTo 0x83D2E0
2014-02-12 19:58:21 R-backOnTime 10 s
2014-07-14 15:23:52 R-btnLock off
2014-07-14 15:23:52 R-burstRx on
2014-07-14 15:23:52 R-cyclicInfoMsg on
2014-07-14 15:23:52 R-cyclicInfoMsgDis 0
2014-07-14 15:23:52 R-globalBtnLock off
2014-07-14 15:23:52 R-localResDis off
2014-02-12 19:58:21 R-lowBatLimitRT 2.1 V
2014-07-14 15:25:12 R-modusBtnLock off
2014-07-14 16:06:45 R-pairCentral 0x83D2E0
2014-07-14 16:06:45 RegL_00: 01:01 02:01 09:01 0A:83 0B:D2 0C:E0 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2014-07-14 16:06:50 RegL_07: 0
2014-07-19 22:37:32 actuator 100
2014-07-19 22:37:32 battery ok
2014-07-19 22:37:32 batteryLevel 2.8
2014-07-19 22:37:32 desired-temp on
2014-07-19 22:37:32 measured-temp 20.8
2014-07-14 16:03:52 powerOn -
2014-07-14 16:03:52 recentStateType info
2014-07-14 15:25:19 sabotageAttack ErrIoAttack cnt:1
2014-07-19 22:30:47 state CMDs_done
2014-07-19 09:50:35 time-request -
Helper:
cSnd 1183D2E022C44C81043D
mId 0095
rxType 140
Io:
newChn +22C44C,00,01,00
nextSend 1405802252.85762
prefIO HMEG
rxt 2
vccu VCCU
p:
22C44C
00
01
00
Mrssi:
mNo C3
Io:
HMEG -47
HMUG -76
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
Hmeg:
avg -53.8947368421053
cnt 38
lst -53
max -52
min -56
At_hmeg:
avg -51.0485695276114
cnt 1503
lst -49
max -48
min -57
At_hmug:
avg -79.3929286190792
cnt 1499
lst -76
max -76
min -83
Shregw:
07 04
Attributes:
IODev HMEG
IOgrp VCCU:HMEG
actCycle 000:10
actStatus alive
autoReadReg 5
event-on-change-reading .*
event-on-update-reading (measured-temp|desired-temp|actuator)
expert 2_full
firmware 1.2
group Heizkoerper
model HM-CC-RT-DN
room hidden
serialNr KEQ0730665
structexclude .*:.*
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
fhem> list ug_bd_heiz_climate
Internals:
CFGFN ./cfg/ug_bd.cfg
DEF 22C44C02
NAME ug_bd_heiz_climate
NR 177
STATE unpeered
TYPE CUL_HM
chanNo 02
device ug_bd_heiz
Readings:
2014-07-14 15:25:13 R-sign off
2014-07-14 16:06:46 RegL_01: 08:00 00:00
2014-07-17 09:58:36 state unpeered
Helper:
Role:
chn 1
Attributes:
group Heizkoerper
model HM-CC-RT-DN
peerIDs 00000000,
room hidden
structexclude .*:.*
fhem> list ug_bd_heiz_climateam
Internals:
CFGFN ./cfg/ug_bd.cfg
DEF 22C44C05
NAME ug_bd_heiz_climateam
NR 183
STATE unpeered
TYPE CUL_HM
chanNo 05
device ug_bd_heiz
Readings:
2014-07-14 16:06:53 R-sign off
2014-07-14 16:06:53 RegL_01: 08:00 00:00
2014-07-17 09:58:36 state unpeered
Helper:
Role:
chn 1
Attributes:
group Heizkoerper
model HM-CC-RT-DN
peerIDs 00000000,
room hidden
structexclude .*:.*
fhem> list ug_bd_heiz_climrt
Internals:
CFGFN ./cfg/ug_bd.cfg
CHANGED
DEF 22C44C04
NAME ug_bd_heiz_climrt
NR 181
STATE T: 20.8 desired: on valve: 100
TYPE CUL_HM
chanNo 04
device ug_bd_heiz
Readings:
2014-07-19 22:30:47 CommandAccepted yes
2014-02-12 19:58:28 R-boostPeriod 5 min
2014-02-12 19:58:28 R-boostPos 80 %
2014-07-14 15:25:19 R-btnNoBckLight off
2014-02-12 19:58:28 R-dayTemp 21 C
2014-07-14 15:25:19 R-daylightSaveTime on
2014-07-14 15:25:19 R-decalcTime 11:00
2014-07-14 15:25:19 R-decalcWeekday Sat
2014-07-14 15:25:19 R-modePrioManu all
2014-07-14 15:25:19 R-modePrioParty all
2014-02-12 20:15:29 R-nightTemp 17 C
2014-07-14 15:25:19 R-noMinMax4Manu off
2014-07-14 15:25:19 R-regAdaptive on
2014-07-14 15:25:19 R-reguExtI 18
2014-07-14 15:25:19 R-reguExtP 33
2014-07-14 15:25:19 R-reguExtPstart 45
2014-07-14 15:25:19 R-reguIntI 15
2014-07-14 15:25:19 R-reguIntP 30
2014-07-14 15:25:19 R-reguIntPstart 30
2014-07-14 15:25:19 R-showInfo time
2014-07-14 15:25:19 R-showWeekday off
2014-07-14 15:25:15 R-sign off
2014-02-12 19:58:28 R-tempMax 30.5 C
2014-02-12 19:58:28 R-tempMin 4.5 C
2014-07-14 15:25:19 R-tempOffset 0.0K
2014-02-12 19:58:28 R-valveErrPos 15 %
2014-02-12 19:58:28 R-valveMaxPos 100 %
2014-02-12 19:58:28 R-valveOffsetRt 0 %
2014-07-14 15:25:19 R-winOpnBoost off
2014-03-21 20:55:26 R-winOpnDetFall 1.4 K
2014-07-14 15:25:19 R-winOpnMode off
2014-02-12 19:58:28 R-winOpnPeriod 15 min
2014-02-12 19:58:28 R-winOpnTemp 12 C
2014-07-14 16:06:52 R_0_tempListSat 24:00 17.0
2014-07-14 16:06:52 R_1_tempListSun 24:00 17.0
2014-07-14 16:06:52 R_2_tempListMon 24:00 17.0
2014-07-14 16:06:52 R_3_tempListTue 24:00 17.0
2014-07-14 16:06:52 R_4_tempListWed 24:00 17.0
2014-07-14 16:06:52 R_5_tempListThu 24:00 17.0
2014-07-14 16:06:52 R_6_tempListFri 24:00 17.0
2014-07-14 16:06:52 R_tempList_State verified
2014-07-14 16:06:48 RegL_01: 08:00 00:00
2014-07-14 16:06:52 RegL_07: 01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:0E 14:45 15:20 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:45 2F:20 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:45 49:20 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:45 63:20 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:45 7D:20 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:45 97:20 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:45 B1:20 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:12 CE:21 CF:2D 00:00
2014-07-19 22:37:32 ValvePosition 100
2014-07-19 22:37:32 controlMode manual
2014-07-19 22:37:32 desired-temp on
2014-07-19 22:37:32 measured-temp 20.8
2014-07-19 16:26:58 mode set_manual
2014-07-19 22:37:32 motorErr ok
2014-07-19 22:30:47 recentStateType ack
2014-07-19 22:37:32 state T: 20.8 desired: on valve: 100
2014-03-15 11:06:57 tempList_State verified
Helper:
Role:
chn 1
Shregr:
07 00
Attributes:
event-on-change-reading .*
group Heizkoerper
icon sani_heating
model HM-CC-RT-DN
peerIDs 00000000,
room ug_bd,ug,D_heizung
structexclude .*:.*
webCmd desired-temp
fhem> list ug_bd_heiz_remote
Internals:
CFGFN ./cfg/ug_bd.cfg
DEF 22C44C06
NAME ug_bd_heiz_remote
NR 185
STATE unpeered
TYPE CUL_HM
chanNo 06
device ug_bd_heiz
Readings:
2014-07-14 15:25:20 R-sign off
2014-07-14 16:06:53 RegL_01: 08:00 00:00
2014-07-17 09:58:36 state unpeered
Helper:
Role:
chn 1
Attributes:
group Heizkoerper
model HM-CC-RT-DN
peerIDs 00000000,
room hidden
structexclude .*:.*
fhem> list ug_bd_heiz_weather
Internals:
CFGFN ./cfg/ug_bd.cfg
DEF 22C44C01
NAME ug_bd_heiz_weather
NR 175
STATE 20.8
TYPE CUL_HM
chanNo 01
device ug_bd_heiz
peerList ug_bd_temp,
Readings:
2014-07-14 15:25:12 R-sign off
2014-07-14 16:06:45 RegL_01: 08:00 00:00
2014-07-19 22:40:23 measured-temp 20.8
2014-07-17 09:58:36 peerList ug_bd_temp,
2014-07-19 22:40:23 state 20.8
Helper:
Role:
chn 1
Attributes:
group Heizkoerper
model HM-CC-RT-DN
peerIDs 00000000,26408701,
room hidden
structexclude .*:.*
fhem> list ug_bd_heiz_window
Internals:
CFGFN ./cfg/ug_bd.cfg
DEF 22C44C03
NAME ug_bd_heiz_window
NR 179
STATE last:trigLast
TYPE CUL_HM
chanNo 03
device ug_bd_heiz
Readings:
2014-07-14 15:25:14 R-sign off
2014-07-14 16:06:47 RegL_01: 08:00 00:00
2014-07-17 09:58:36 state unpeered
2014-02-26 21:29:35 winOpnBoost off
2014-02-26 21:29:35 winOpnDetFall 1.4 K
2014-02-26 21:29:35 winOpnMode on
2014-02-26 21:29:35 winOpnPeriod 15 min
2014-02-26 21:29:35 winOpnTemp-int 12 C
Helper:
Role:
chn 1
Attributes:
group Heizkoerper
model HM-CC-RT-DN
peerIDs 00000000,
room hidden
stateFormat last:trigLast
structexclude .*:.*
Hej Rainer,
kann ich mir beim besten Willen nicht erklären.
Schon versucht, einen RT komplett zu resetten und ihn dann nur einmal mit FHEM zu pairen, um zu sehen, ob der Fehler dann noch auftritt? Und erst wenn das passt, das Peering eintragen und dann nochmal kontrollieren.
Hej zusammen,
seht mal, worüber ich vorhin gestolpert bin:
Funk-Heizkörperthermostat Firmware V1.3 (http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_3_001_140314.tgz)
Ich glaube, darauf haben schon einige gewartet. Vorallem um zu testen, ob ein Update auf v1.3 über FHEM nun möglich ist. ;-)
Der Hersteller bringt dabei folgendes Changelog mit:
** Bug
* Change in config_rt(...,...), parameter configuration is start at parameterposition 20.
The weekly program transfer to the partner was incorrect if the first timestep > 21:15 o'clock
* If party-mode bring into action, always the long status-message is send out instead of the
short status-message. The party-temperature is add as last byte at the long status-message.
zwischenstand:
Update von RT-DN 1.2 nach 1.3 erfolgreich.
- IO: CUL V3
- IOgrp sollte (vorläufig) abgeschaltet werden. Es könnte sein (so bei mir) dass mehrere IOs zu verfügung stehen und dann ein HMLAN ausgewählt wird (was nicht gehen kann). Also: IOgrp löschen, IODev auf die gewünschte CUL setzen
- nach dem update bleibt der RT stehen und wartet auf Tastendruck - dann macht er die Adaptionsfahrt. Die Message, das zu automatisieren muss ich noch suchen
- nach dem Update steht die FW so lange auf der alten Version, bis man einmal config drückt. Auch hier kenne ich die Message nicht, es dem Device automatisch zu entlocken. GetConfig leistet dies nicht.
Kommando
set <rtDev> fUpdate <filename>
das tar/zip muss natürlich entpackt werden. Das notwendige File ist das .eq3
habe die SW angepasst. jetzt sind folgenden updates gelaufen:
RT-DN 1.2 nach 1.3
TC-IT 1.0 nach 1.1
more to come....
Hi Martin,
habe gerade gesehen, daß die RT-DN nach einem "controlManu on" erstmal "off" als desired-temp melden. Das ist mit r6295.
In diesem Fall ist das ein Team. Sehe das aber auch bei anderen.
2014-07-22_10:06:48 ug_ws_heiz_links_climrt controlMode: set_manual
2014-07-22_10:06:48 ug_ws_heiz_links CMDs_pending
2014-07-22_10:06:48 ug_ws_heiz_links_climrt set_controlManu on
2014-07-22_10:06:48 ug_ws_heiz_rechts_climrt controlMode: set_manual
2014-07-22_10:06:48 ug_ws_heiz_rechts CMDs_pending
2014-07-22_10:06:48 ug_ws_heiz_rechts_climrt set_controlManu on
...
2014-07-22_10:09:01 ug_ws_heiz_links measured-temp: 21.5
2014-07-22_10:09:01 ug_ws_heiz_links batteryLevel: 2.9
2014-07-22_10:09:01 ug_ws_heiz_links actuator: 100
2014-07-22_10:09:01 ug_ws_heiz_links battery: ok
2014-07-22_10:09:01 ug_ws_heiz_links desired-temp: on
2014-07-22_10:09:01 ug_ws_heiz_links_climrt controlMode: manual
2014-07-22_10:09:01 ug_ws_heiz_links_climrt T: 21.5 desired: on valve: 100
2014-07-22_10:09:01 ug_ws_heiz_links_weather measured-temp: 21.5
2014-07-22_10:09:01 ug_ws_heiz_links_weather 21.5
2014-07-22_10:09:01 ug_ws_heiz_links battery: ok
2014-07-22_10:09:01 ug_ws_heiz_links desired-temp: off
2014-07-22_10:09:01 ug_ws_heiz_links CMDs_done
2014-07-22_10:09:01 ug_ws_heiz_links_climrt desired-temp: off
2014-07-22_10:09:01 ug_ws_heiz_links_climrt T: 21.5 desired: off valve: 100
2014-07-22_10:09:11 ug_ws_heiz_rechts measured-temp: 21.5
2014-07-22_10:09:11 ug_ws_heiz_rechts batteryLevel: 2.9
2014-07-22_10:09:11 ug_ws_heiz_rechts actuator: 100
2014-07-22_10:09:11 ug_ws_heiz_rechts battery: ok
2014-07-22_10:09:11 ug_ws_heiz_rechts desired-temp: on
2014-07-22_10:09:11 ug_ws_heiz_rechts_climrt controlMode: manual
2014-07-22_10:09:11 ug_ws_heiz_rechts_climrt T: 21.5 desired: on valve: 100
2014-07-22_10:09:11 ug_ws_heiz_rechts_weather measured-temp: 21.5
2014-07-22_10:09:11 ug_ws_heiz_rechts_weather 21.5
2014-07-22_10:09:11 ug_ws_heiz_rechts battery: ok
2014-07-22_10:09:11 ug_ws_heiz_rechts desired-temp: off
2014-07-22_10:09:11 ug_ws_heiz_rechts CMDs_done
2014-07-22_10:09:11 ug_ws_heiz_rechts_climrt desired-temp: off
2014-07-22_10:09:11 ug_ws_heiz_rechts_climrt T: 21.5 desired: off valve: 100
...
2014-07-22_10:11:39 ug_ws_heiz_links measured-temp: 21.5
2014-07-22_10:11:39 ug_ws_heiz_links batteryLevel: 2.9
2014-07-22_10:11:39 ug_ws_heiz_links actuator: 100
2014-07-22_10:11:39 ug_ws_heiz_links battery: ok
2014-07-22_10:11:39 ug_ws_heiz_links desired-temp: on
2014-07-22_10:11:39 ug_ws_heiz_links_climrt desired-temp: on
2014-07-22_10:11:39 ug_ws_heiz_links_climrt T: 21.5 desired: on valve: 100
2014-07-22_10:11:39 ug_ws_heiz_links_weather measured-temp: 21.5
2014-07-22_10:11:39 ug_ws_heiz_links_weather 21.5
2014-07-22_10:11:58 eg_of_temp temperature: 24.0
2014-07-22_10:11:58 eg_of_temp humidity: 67
2014-07-22_10:11:58 eg_of_temp dewpoint: 17.5
2014-07-22_10:11:58 ug_ws_heiz_rechts measured-temp: 21.5
2014-07-22_10:11:58 ug_ws_heiz_rechts batteryLevel: 2.9
2014-07-22_10:11:58 ug_ws_heiz_rechts actuator: 100
2014-07-22_10:11:58 ug_ws_heiz_rechts battery: ok
2014-07-22_10:11:58 ug_ws_heiz_rechts desired-temp: on
2014-07-22_10:11:59 ug_ws_heiz_rechts_climrt desired-temp: on
2014-07-22_10:11:59 ug_ws_heiz_rechts_climrt T: 21.5 desired: on valve: 100
2014-07-22_10:11:59 ug_ws_heiz_rechts_weather measured-temp: 21.5
2014-07-22_10:11:59 ug_ws_heiz_rechts_weather 21.5
2014.07.22 10:06:48.425 3: CUL_HM set ug_ws_heiz_links_climrt controlManu on
2014.07.22 10:06:48.437 3: CUL_HM set ug_ws_heiz_rechts_climrt controlManu on
...
2014.07.22 10:09:01.259 0: HMLAN_Parse: HMUG R:E240490 stat:0000 t:1A072740 d:FF r:FFC8 m:01 8610 240490 000000 0AF4D70E6458
2014.07.22 10:09:01.355 0: HMLAN_Send: HMUG S:S5D1DD393 stat: 00 t:00000000 d:01 r:5D1DD393 m:D7 A112 83D2E0 240490
2014.07.22 10:09:01.380 0: HMLAN_Parse: HMEG R:E240490 stat:0000 t:28841619 d:FF r:FFB2 m:01 8610 240490 000000 0AF4D70E6458
2014.07.22 10:09:01.515 0: HMLAN_Parse: HMUG R:R5D1DD393 stat:0001 t:1A072843 d:FF r:FFC7 m:D7 8002 240490 83D2E0 00
2014.07.22 10:09:01.615 0: HMLAN_Send: HMUG S:S5D1DD4A2 stat: 00 t:00000000 d:01 r:5D1DD4A2 m:D8 A011 83D2E0 240490 81043D
2014.07.22 10:09:01.624 0: HMLAN_Parse: HMEG R:E240490 stat:0000 t:28841717 d:FF r:FFB2 m:D7 8002 240490 83D2E0 00
2014.07.22 10:09:01.792 0: HMLAN_Parse: HMEG R:E83D2E0 stat:0000 t:2884182B d:FF r:FF99 m:D8 A011 83D2E0 240490 81043D
2014.07.22 10:09:01.921 0: HMLAN_Parse: HMUG R:R5D1DD4A2 stat:0001 t:1A0729DB d:FF r:FFC8 m:D8 8002 240490 83D2E0 01043D003858
2014.07.22 10:09:01.940 0: HMLAN_Parse: HMEG R:E240490 stat:0000 t:288418AF d:FF r:FFB2 m:D8 8002 240490 83D2E0 01043D003858
2014.07.22 10:09:11.197 0: HMLAN_Parse: HMUG R:E2404AC stat:0000 t:1A074E11 d:FF r:FFC2 m:41 8610 2404AC 000000 0AF4D70E6458
2014.07.22 10:09:11.291 0: HMLAN_Send: HMUG S:S5D1DFA6D stat: 00 t:00000000 d:01 r:5D1DFA6D m:D9 A112 83D2E0 2404AC
2014.07.22 10:09:11.317 0: HMLAN_Parse: HMEG R:E2404AC stat:0000 t:28843CEA d:FF r:FFAD m:41 8610 2404AC 000000 0AF4D70E6458
2014.07.22 10:09:11.319 0: HMLAN_Parse: HMEG R:E83D2E0 stat:0000 t:28843D65 d:FF r:FF9B m:D9 A112 83D2E0 2404AC
2014.07.22 10:09:11.447 0: HMLAN_Parse: HMUG R:R5D1DFA6D stat:0001 t:1A074F13 d:FF r:FFC2 m:D9 8002 2404AC 83D2E0 00
2014.07.22 10:09:11.548 0: HMLAN_Send: HMUG S:S5D1DFB60 stat: 00 t:00000000 d:01 r:5D1DFB60 m:DA A011 83D2E0 2404AC 81043D
2014.07.22 10:09:11.551 0: HMLAN_Parse: HMEG R:E2404AC stat:0000 t:28843DE7 d:FF r:FFAE m:D9 8002 2404AC 83D2E0 00
2014.07.22 10:09:11.726 0: HMLAN_Parse: HMEG R:E83D2E0 stat:0000 t:28843EFB d:FF r:FF9B m:DA A011 83D2E0 2404AC 81043D
2014.07.22 10:09:11.854 0: HMLAN_Parse: HMUG R:R5D1DFB60 stat:0001 t:1A0750AA d:FF r:FFC2 m:DA 8002 2404AC 83D2E0 01043D003F58
2014.07.22 10:09:11.875 0: HMLAN_Parse: HMEG R:E2404AC stat:0000 t:28843F7E d:FF r:FFAE m:DA 8002 2404AC 83D2E0 01043D003F58
...
2014.07.22 10:11:39.011 0: HMLAN_Parse: HMUG R:E240490 stat:0000 t:1A098F8F d:FF r:FFC7 m:02 8610 240490 000000 0AF4D70E6458
2014.07.22 10:11:39.210 0: HMLAN_Parse: HMEG R:E240490 stat:0000 t:28867E68 d:FF r:FFAF m:02 8610 240490 000000 0AF4D70E6458
2014.07.22 10:11:58.578 0: HMLAN_Parse: HMEG R:E1F4BE7 stat:0000 t:2886CAD9 d:FF r:FFDF m:08 8670 1F4BE7 000000 00F043
2014.07.22 10:11:58.649 0: HMLAN_Parse: HMUG R:E1F4BE7 stat:0000 t:1A09DC01 d:FF r:FFA3 m:08 8670 1F4BE7 000000 00F043
2014.07.22 10:11:58.947 0: HMLAN_Parse: HMUG R:E2404AC stat:0000 t:1A09DD71 d:FF r:FFC2 m:42 8610 2404AC 000000 0AF4D70E6458
2014.07.22 10:11:59.145 0: HMLAN_Parse: HMEG R:E2404AC stat:0000 t:2886CC4A d:FF r:FFAD m:42 8610 2404AC 000000 0AF4D70E6458
Rainer
sollte behoben sein.
Änderungsgrund ist die Auswertung der RT-Antwort (hat bisher gefehlt) sowie die auswertung der boost und party-mode settings.
Falls du testen willst...
Hi,
wow, das war fix. Test sieht gut aus.
Danke
Rainer
Ich habe gerade ein Update meines RT von 1.1 auf 1.3 durchgeführt und das hat soweit auch funktioniert.
Leider habe ich auch noch RTs mit FW 1.0. Wie kann ich diese updaten bzw. wo bekomme ich die FW dafür?
mache einen
set rt fwUpdate <file> 100
um dir 100 sec zeit zu geben. In dieser Zeit musst du den RT manuell in updatemode schicken. Das geht (denke ich)...
Batterie raus
beide äusseren tasten drücken, DABEI die Batterie einlegen
=> device sollte FUP anzeigen
das FUP kannst du auch trocken probieren. Wenn sich die Zentrale nicht meldet endet es einfach nach ein paar Sekunden.
Hallo Martin,
geht der Firmware Update per FHEM nur mit einem CUL oder kann dazu auch ein mit hmland an FHEM angebundener HM-CFG-USB2 verwendet werden?
Gruß,
Reiner.
Hallo Reiner,
es sollte gehen - aber da ich keinen habe, kann ich es nicht testen. Wichtig ist die Umschaltung der Datenrate. Eingebaut, aber nicht getestet.
Theoretisch sollte ein test unproblematisch sein - wenn du probieren willst. Das Device wird in FUP gesetzt, dann wird die Datenrate im Device umgeschaltet. Anschliessend schaltet das IO seine eigene Datenrate um (untested). Sollte es nicht klappen wird der download nicht gestartet und das device sollte den FUP automatisch beenden.
wie gesagt - untested.
Gruss Martin
Zitat von: martinp876 am 22 Juli 2014, 22:39:09
mache einen
set rt fwUpdate <file> 100
um dir 100 sec zeit zu geben. In dieser Zeit musst du den RT manuell in updatemode schicken. Das geht (denke ich)...
Batterie raus
beide äusseren tasten drücken, DABEI die Batterie einlegen
=> device sollte FUP anzeigen
das FUP kannst du auch trocken probieren. Wenn sich die Zentrale nicht meldet endet es einfach nach ein paar Sekunden.
Hallo Martin,
habe das so Probiert und zuerst sah das auch gut aus und jetzt steht CrC auf dem RT.
2014.07.23 19:00:20 2: CUL_HM fwUpdate started for AZ_RT_links
2014.07.23 19:00:20 5: CUL_HM AZ_RT_links protEvent:CMDs_processing...
2014.07.23 19:00:20 3: CUL_HM set AZ_RT_links fwUpdate hm_cc_rt_dn_update_V1_3_001_140314.eq3 100
2014.07.23 19:00:22 4: CUL_HM_Resend: AZ_RT_links nr 2
2014.07.23 19:00:22 5: CUL_HM AZ_RT_links protEvent:CMDs_pending pending:1
2014.07.23 19:00:32 2: CUL_HM fwUpdate AZ_RT_links entered mode - switch speed
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM fwUpdate write block 1 of 234: 10 messages
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:32 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:0
2014.07.23 19:00:34 4: CUL_HM_Resend: AZ_RT_links nr 3
2014.07.23 19:00:34 5: CUL_HM AZ_RT_links protEvent:CMDs_pending pending:1
2014.07.23 19:00:37 5: CUL_HM fwUpdate write block 1 of 234: 10 messages
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:37 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:0
2014.07.23 19:00:42 4: CUL_HM_Resend: AZ_RT_links nr 4
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_pending pending:1
2014.07.23 19:00:42 5: CUL_HM fwUpdate write block 1 of 234: 10 messages
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.23 19:00:42 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:0
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done_Errors:1
2014.07.23 19:00:47 5: CUL_HM fwUpdate write block 1 of 234: 10 messages
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:47 5: CUL_HM AZ_RT_links protEvent:CMDs_done
2014.07.23 19:00:48 5: CUL_HM AZ_RT_links protEvent:CMDs_processing...
2014.07.23 19:02:21 4: CUL_HM AZ_RT_links dupe: dont process
2014.07.23 19:03:29 4: CUL_HM AZ_RT_links dupe: dont process
2014.07.23 19:04:18 4: CUL_HM AZ_RT_links dupe: dont process
2014.07.23 19:05:37 4: CUL_HM AZ_RT_links dupe: dont processHabe das Update auch noch mal gestartet, aber es kommt der gleiche Fehler.
Bei einem anderen RT steht in den Reedings:
fwUpdate fail:notInBootLoader 2014-07-22 22:34:14
Hej Martin,
hab das jetzt auch einmal mit zwei meiner RTs und in der selben Konstellation wie holzwurm83 probiert (Update mittels hmland angebundenen hm-cfg-usb-2). Der RT schaltet zwar brav in den Update-Modus, aber bereits Sekunden später restartet er und nichts ist passiert.
Im Logfile des RTs hatte ich dann:2014-07-24_00:00:57 heating_workroom fwUpdate: fail:Block1
stehen. Um auf Nummer sicher zu gehen, habe ich es auch noch mit einem anderen RT probiert: Selbes Verhalten.
Darauf hin habe ich es einmal genauer mitgeloggt, ehe der RT abbricht:
2014.07.24 00:16:02.093 2: CUL_HM fwUpdate started for heating_workroom
2014.07.24 00:16:02.098 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:02.100 0: HMLAN_Send: myHM S:S654BA676 stat: 00 t:00000000 d:01 r:654BA676 m:0A 3011 120408 220F80 CA
2014.07.24 00:16:02.723 0: HMLAN_Parse: myHM R:R654BA676 stat:0001 t:0003DEAE d:FF r:FFD3 m:0A 8002 220F80 120408 00
2014.07.24 00:16:03.331 0: HMLAN_Parse: myHM R:E220F80 stat:0000 t:0003E11C d:FF r:FFD3 m:00 0010 220F80 000000 004B455130353039333737
2014.07.24 00:16:03.334 2: CUL_HM fwUpdate heating_workroom entered mode - switch speed
2014.07.24 00:16:03.434 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.436 0: HMLAN_Send: myHM S:S654BAB4F stat: 00 t:00000000 d:01 r:654BAB4F m:0B 00CB 120408 220F80 105B11F81547
2014.07.24 00:16:03.482 0: HMLAN_Send: myHM I:S654BABE0,00,00000000,01,654BABE0,
2014.07.24 00:16:03.531 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.532 0: HMLAN_Send: myHM S:S654BAC11 stat: 00 t:00000000 d:01 r:654BAC11 m:0D 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:03.541 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.543 0: HMLAN_Send: myHM S:S654BAC1B stat: 00 t:00000000 d:01 r:654BAC1B m:0E 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:03.553 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.555 0: HMLAN_Send: myHM S:S654BAC26 stat: 00 t:00000000 d:01 r:654BAC26 m:0F 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:03.565 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.567 0: HMLAN_Send: myHM S:S654BAC32 stat: 00 t:00000000 d:01 r:654BAC32 m:10 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:03.576 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.579 0: HMLAN_Send: myHM S:S654BAC3E stat: 00 t:00000000 d:01 r:654BAC3E m:11 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:03.589 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.591 0: HMLAN_Send: myHM S:S654BAC4A stat: 00 t:00000000 d:01 r:654BAC4A m:12 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:03.600 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.602 0: HMLAN_Send: myHM S:S654BAC55 stat: 00 t:00000000 d:01 r:654BAC55 m:13 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:03.610 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.612 0: HMLAN_Send: myHM S:S654BAC60 stat: 00 t:00000000 d:01 r:654BAC60 m:14 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 00:16:03.621 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.623 0: HMLAN_Send: myHM S:S654BAC6B stat: 00 t:00000000 d:01 r:654BAC6B m:15 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:03.632 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:03.634 0: HMLAN_Send: myHM S:S654BAC76 stat: 00 t:00000000 d:01 r:654BAC76 m:16 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:03.652 0: HMLAN_Parse: myHM R:R654BAB4F stat:0002 t:00000000 d:FF r:7FFF m:0B 00CB 120408 220F80 105B11F81547
2014.07.24 00:16:03.654 0: HMLAN_Parse: myHM R:R654BABE0 stat:0002 t:00000000 d:FF r:7FFF m:
2014.07.24 00:16:03.779 0: HMLAN_Parse: myHM R:R654BAC11 stat:0002 t:00000000 d:FF r:7FFF m:0D 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:03.908 0: HMLAN_Parse: myHM R:R654BAC1B stat:0002 t:00000000 d:FF r:7FFF m:0E 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:04.035 0: HMLAN_Parse: myHM R:R654BAC26 stat:0002 t:00000000 d:FF r:7FFF m:0F 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:04.163 0: HMLAN_Parse: myHM R:R654BAC32 stat:0002 t:00000000 d:FF r:7FFF m:10 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:04.291 0: HMLAN_Parse: myHM R:R654BAC3E stat:0002 t:00000000 d:FF r:7FFF m:11 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:04.419 0: HMLAN_Parse: myHM R:R654BAC4A stat:0002 t:00000000 d:FF r:7FFF m:12 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:04.547 0: HMLAN_Parse: myHM R:R654BAC55 stat:0002 t:00000000 d:FF r:7FFF m:13 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:04.675 0: HMLAN_Parse: myHM R:R654BAC60 stat:0002 t:00000000 d:FF r:7FFF m:14 00CA 120408 220F80 192D962E6C3CD7579194D69314219C
2014.07.24 00:16:04.931 0: HMLAN_Parse: myHM R:R654BAC6B stat:0002 t:00000000 d:FF r:7FFF m:15 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:05.635 0: HMLAN_Parse: myHM R:R654BAC76 stat:0008 t:00000000 d:FF r:7FFF m:16 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:05.637 0: HMLAN_Parse: myHM no ACK from 220F80
2014.07.24 00:16:08.649 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.652 0: HMLAN_Send: myHM S:S654BC00F stat: 00 t:00000000 d:01 r:654BC00F m:0B 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:08.661 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.664 0: HMLAN_Send: myHM S:S654BC01B stat: 00 t:00000000 d:01 r:654BC01B m:0C 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:08.673 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.678 0: HMLAN_Send: myHM S:S654BC027 stat: 00 t:00000000 d:01 r:654BC027 m:0D 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:08.685 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.687 0: HMLAN_Send: myHM S:S654BC033 stat: 00 t:00000000 d:01 r:654BC033 m:0E 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:08.697 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.699 0: HMLAN_Send: myHM S:S654BC03F stat: 00 t:00000000 d:01 r:654BC03F m:0F 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:08.709 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.711 0: HMLAN_Send: myHM S:S654BC04B stat: 00 t:00000000 d:01 r:654BC04B m:10 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:08.721 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.723 0: HMLAN_Send: myHM S:S654BC056 stat: 00 t:00000000 d:01 r:654BC056 m:11 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:08.733 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.735 0: HMLAN_Send: myHM S:S654BC062 stat: 00 t:00000000 d:01 r:654BC062 m:12 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 00:16:08.744 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.746 0: HMLAN_Send: myHM S:S654BC06E stat: 00 t:00000000 d:01 r:654BC06E m:13 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:08.755 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:08.757 0: HMLAN_Send: myHM S:S654BC079 stat: 00 t:00000000 d:01 r:654BC079 m:14 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:08.803 0: HMLAN_Parse: myHM R:R654BC00F stat:0002 t:00000000 d:FF r:7FFF m:0B 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:08.931 0: HMLAN_Parse: myHM R:R654BC01B stat:0002 t:00000000 d:FF r:7FFF m:0C 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:09.059 0: HMLAN_Parse: myHM R:R654BC027 stat:0002 t:00000000 d:FF r:7FFF m:0D 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:09.187 0: HMLAN_Parse: myHM R:R654BC033 stat:0002 t:00000000 d:FF r:7FFF m:0E 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:09.315 0: HMLAN_Parse: myHM R:R654BC03F stat:0002 t:00000000 d:FF r:7FFF m:0F 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:09.443 0: HMLAN_Parse: myHM R:R654BC04B stat:0002 t:00000000 d:FF r:7FFF m:10 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:09.571 0: HMLAN_Parse: myHM R:R654BC056 stat:0002 t:00000000 d:FF r:7FFF m:11 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:09.699 0: HMLAN_Parse: myHM R:R654BC062 stat:0002 t:00000000 d:FF r:7FFF m:12 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 00:16:09.827 0: HMLAN_Parse: myHM R:R654BC06E stat:0002 t:00000000 d:FF r:7FFF m:13 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:10.531 0: HMLAN_Parse: myHM R:R654BC079 stat:0008 t:00000000 d:FF r:7FFF m:14 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:10.533 0: HMLAN_Parse: myHM no ACK from 220F80
2014.07.24 00:16:13.771 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.777 0: HMLAN_Send: myHM S:S654BD411 stat: 00 t:00000000 d:01 r:654BD411 m:0B 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:13.786 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.788 0: HMLAN_Send: myHM S:S654BD420 stat: 00 t:00000000 d:01 r:654BD420 m:0C 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:13.797 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.798 0: HMLAN_Send: myHM S:S654BD42A stat: 00 t:00000000 d:01 r:654BD42A m:0D 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:13.807 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.810 0: HMLAN_Send: myHM S:S654BD435 stat: 00 t:00000000 d:01 r:654BD435 m:0E 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:13.817 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.819 0: HMLAN_Send: myHM S:S654BD43F stat: 00 t:00000000 d:01 r:654BD43F m:0F 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:13.825 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.827 0: HMLAN_Send: myHM S:S654BD447 stat: 00 t:00000000 d:01 r:654BD447 m:10 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:13.834 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.836 0: HMLAN_Send: myHM S:S654BD450 stat: 00 t:00000000 d:01 r:654BD450 m:11 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:13.842 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.844 0: HMLAN_Send: myHM S:S654BD458 stat: 00 t:00000000 d:01 r:654BD458 m:12 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 00:16:13.851 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.853 0: HMLAN_Send: myHM S:S654BD461 stat: 00 t:00000000 d:01 r:654BD461 m:13 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:13.860 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:13.861 0: HMLAN_Send: myHM S:S654BD46A stat: 00 t:00000000 d:01 r:654BD46A m:14 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:13.923 0: HMLAN_Parse: myHM R:R654BD411 stat:0002 t:00000000 d:FF r:7FFF m:0B 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:14.051 0: HMLAN_Parse: myHM R:R654BD420 stat:0002 t:00000000 d:FF r:7FFF m:0C 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:14.179 0: HMLAN_Parse: myHM R:R654BD42A stat:0002 t:00000000 d:FF r:7FFF m:0D 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:14.307 0: HMLAN_Parse: myHM R:R654BD435 stat:0002 t:00000000 d:FF r:7FFF m:0E 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:14.435 0: HMLAN_Parse: myHM R:R654BD43F stat:0002 t:00000000 d:FF r:7FFF m:0F 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:14.563 0: HMLAN_Parse: myHM R:R654BD447 stat:0002 t:00000000 d:FF r:7FFF m:10 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:14.691 0: HMLAN_Parse: myHM R:R654BD450 stat:0002 t:00000000 d:FF r:7FFF m:11 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:14.819 0: HMLAN_Parse: myHM R:R654BD458 stat:0002 t:00000000 d:FF r:7FFF m:12 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 00:16:14.947 0: HMLAN_Parse: myHM R:R654BD461 stat:0002 t:00000000 d:FF r:7FFF m:13 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:15.513 0: HMLAN_Send: myHM I:K
2014.07.24 00:16:15.555 0: HMLAN_Parse: myHM V:03C7 sNo:JEQ0534552 d:1DAEE3 O:120408 t:000410D1 IDcnt:000D
2014.07.24 00:16:15.651 0: HMLAN_Parse: myHM R:R654BD46A stat:0008 t:00000000 d:FF r:7FFF m:14 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:15.654 0: HMLAN_Parse: myHM no ACK from 220F80
2014.07.24 00:16:16.036 0: HMLAN_Parse: myHM R:E220F80 stat:0000 t:000412B4 d:FF r:FFD3 m:00 A410 220F80 120408 06000030
2014.07.24 00:16:18.179 0: HMLAN_Parse: myHM R:E220F80 stat:0000 t:00041B16 d:FF r:FFD3 m:01 A03F 220F80 120408
2014.07.24 00:16:18.307 0: HMLAN_Parse: myHM R:E220F80 stat:0000 t:00041B16 d:FF r:FFD3 m:01 A03F 220F80 120408
2014.07.24 00:16:18.874 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.896 0: HMLAN_Send: myHM S:S654BE7FF stat: 00 t:00000000 d:01 r:654BE7FF m:0B 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:18.910 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.914 0: HMLAN_Send: myHM S:S654BE822 stat: 00 t:00000000 d:01 r:654BE822 m:0C 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:18.932 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.937 0: HMLAN_Send: myHM S:S654BE838 stat: 00 t:00000000 d:01 r:654BE838 m:0D 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:18.949 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.951 0: HMLAN_Send: myHM S:S654BE84B stat: 00 t:00000000 d:01 r:654BE84B m:0E 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:18.961 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.963 0: HMLAN_Send: myHM S:S654BE856 stat: 00 t:00000000 d:01 r:654BE856 m:0F 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:18.973 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.974 0: HMLAN_Send: myHM S:S654BE862 stat: 00 t:00000000 d:01 r:654BE862 m:10 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:18.984 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.986 0: HMLAN_Send: myHM S:S654BE86E stat: 00 t:00000000 d:01 r:654BE86E m:11 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:18.996 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:18.998 0: HMLAN_Send: myHM S:S654BE879 stat: 00 t:00000000 d:01 r:654BE879 m:12 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 00:16:19.007 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:19.009 0: HMLAN_Send: myHM S:S654BE885 stat: 00 t:00000000 d:01 r:654BE885 m:13 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:19.020 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 00:16:19.021 0: HMLAN_Send: myHM S:S654BE892 stat: 00 t:00000000 d:01 r:654BE892 m:14 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:19.048 0: HMLAN_Parse: myHM R:R654BE7FF stat:0002 t:00000000 d:FF r:7FFF m:0B 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 00:16:19.171 0: HMLAN_Parse: myHM R:R654BE822 stat:0002 t:00000000 d:FF r:7FFF m:0C 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 00:16:19.299 0: HMLAN_Parse: myHM R:R654BE838 stat:0002 t:00000000 d:FF r:7FFF m:0D 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 00:16:19.427 0: HMLAN_Parse: myHM R:R654BE84B stat:0002 t:00000000 d:FF r:7FFF m:0E 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 00:16:19.555 0: HMLAN_Parse: myHM R:R654BE856 stat:0002 t:00000000 d:FF r:7FFF m:0F 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 00:16:19.683 0: HMLAN_Parse: myHM R:R654BE862 stat:0002 t:00000000 d:FF r:7FFF m:10 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 00:16:19.811 0: HMLAN_Parse: myHM R:R654BE86E stat:0002 t:00000000 d:FF r:7FFF m:11 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 00:16:19.939 0: HMLAN_Parse: myHM R:R654BE879 stat:0002 t:00000000 d:FF r:7FFF m:12 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 00:16:20.067 0: HMLAN_Parse: myHM R:R654BE885 stat:0002 t:00000000 d:FF r:7FFF m:13 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 00:16:20.771 0: HMLAN_Parse: myHM R:R654BE892 stat:0008 t:00000000 d:FF r:7FFF m:14 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 00:16:20.774 0: HMLAN_Parse: myHM no ACK from 220F80
Vielleicht hast du eine Idee dazu? :-)
Thx a lot!
ist euer hmland auch ota-fähig?
gruss frank
problem scheint zu sein, dass der HMUSB den speed-change nicht klappt. Kann ich leider nicht testen.
@martin: Du schickst schon G64 an den hmcfgusb, nachdem Du das Umschaltsignal an den RT gesendet hast? Ich hab das in dem Log weiter oben gerade nicht gefunden (aber evtl. wurde es einfach nicht geloggt).
Nach G64 ist der hmcfgusb definitiv im 100k-Modus (wenn der hmland mindestens vom 15.2. ist, davor kam er mit G nicht richtig zurecht, 0.093-git geht sicher und der hmcfgusb eine OTA-fähige Firmware (>= 0.967) hat).
Gruß
Michael
das könnte es gewesen sein. das hat nicht geklappt.
Es gibt ein neues 00_HMLAN.
Zitat von: martinp876 am 24 Juli 2014, 15:27:31
das könnte es gewesen sein. das hat nicht geklappt.
Es gibt ein neues 00_HMLAN.
Das Problem scheint gelöst. Mit der neuen Version schaltet der HM-CFG-USB-2 um, wie er soll.
Danach bricht bei mir zwar die Verbindung zusammen - aber das dürfte wohl kein FHEM-Problem mehr sein. ;-)
ok.
wenn du dann noch einmal einen log schicken kannst (reicht der Anfang, isT sonst zu lang... ). Ich denke, da kommen noch zu viele kontrollmessages zwischendurch.
Zitat von: martinp876 am 24 Juli 2014, 17:29:31
wenn du dann noch einmal einen log schicken kannst (reicht der Anfang, isT sonst zu lang... ). Ich denke, da kommen noch zu viele kontrollmessages zwischendurch.
Gerne. Hoffe, das passt so. ;-)
2014.07.24 18:05:53.232 2: CUL_HM fwUpdate started for heating_workroom
2014.07.24 18:05:53.237 0: HMLAN_Send: myHM S:+220F80,00,01,00
2014.07.24 18:05:53.239 0: HMLAN_Send: myHM S:S691F211A stat: 00 t:00000000 d:01 r:691F211A m:0A 3011 120408 220F80 CA
2014.07.24 18:05:53.247 0: HMLAN_Send: myHM I:+220F80,02,01,00
2014.07.24 18:05:55.153 0: HMLAN_Parse: myHM R:R691F211A stat:0008 t:00000000 d:FF r:7FFF m:0A 3011 120408 220F80 CA
2014.07.24 18:05:55.156 0: HMLAN_Parse: myHM no ACK from 220F80
2014.07.24 18:05:56.690 0: HMLAN_Parse: myHM R:E220F80 stat:0000 t:00323233 d:FF r:FFD1 m:9D 0C10 220F80 000000 004B455130353039333737
2014.07.24 18:05:56.693 2: CUL_HM fwUpdate heating_workroom entered mode - switch speed
2014.07.24 18:05:56.793 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.795 0: HMLAN_Send: myHM S:S691F2E9E stat: 00 t:00000000 d:01 r:691F2E9E m:0B 00CB 120408 220F80 105B11F81547
2014.07.24 18:05:56.842 0: HMLAN_Send: myHM I:G64
2014.07.24 18:05:56.888 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.890 0: HMLAN_Send: myHM S:S691F2F5E stat: 00 t:00000000 d:01 r:691F2F5E m:0D 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 18:05:56.899 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.901 0: HMLAN_Send: myHM S:S691F2F68 stat: 00 t:00000000 d:01 r:691F2F68 m:0E 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 18:05:56.911 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.913 0: HMLAN_Send: myHM S:S691F2F74 stat: 00 t:00000000 d:01 r:691F2F74 m:0F 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 18:05:56.923 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.925 0: HMLAN_Send: myHM S:S691F2F80 stat: 00 t:00000000 d:01 r:691F2F80 m:10 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 18:05:56.935 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.937 0: HMLAN_Send: myHM S:S691F2F8C stat: 00 t:00000000 d:01 r:691F2F8C m:11 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 18:05:56.948 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.949 0: HMLAN_Send: myHM S:S691F2F99 stat: 00 t:00000000 d:01 r:691F2F99 m:12 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 18:05:56.959 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.960 0: HMLAN_Send: myHM S:S691F2FA4 stat: 00 t:00000000 d:01 r:691F2FA4 m:13 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 18:05:56.969 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.971 0: HMLAN_Send: myHM S:S691F2FAF stat: 00 t:00000000 d:01 r:691F2FAF m:14 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 18:05:56.980 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.982 0: HMLAN_Send: myHM S:S691F2FBA stat: 00 t:00000000 d:01 r:691F2FBA m:15 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 18:05:56.992 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:56.994 0: HMLAN_Send: myHM S:S691F2FC5 stat: 00 t:00000000 d:01 r:691F2FC5 m:16 20CA 120408 220F80 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.24 18:05:57.014 0: HMLAN_Parse: myHM R:R691F2E9E stat:0002 t:00000000 d:FF r:7FFF m:0B 00CB 120408 220F80 105B11F81547
2014.07.24 18:05:57.105 0: HMLAN_Parse: myHM R:R691F2F5E stat:0002 t:00000000 d:FF r:7FFF m:0D 00CA 120408 220F80 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.24 18:05:57.233 0: HMLAN_Parse: myHM R:R691F2F68 stat:0002 t:00000000 d:FF r:7FFF m:0E 00CA 120408 220F80 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.24 18:05:57.361 0: HMLAN_Parse: myHM R:R691F2F74 stat:0002 t:00000000 d:FF r:7FFF m:0F 00CA 120408 220F80 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.24 18:05:57.489 0: HMLAN_Parse: myHM R:R691F2F80 stat:0002 t:00000000 d:FF r:7FFF m:10 00CA 120408 220F80 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.24 18:05:57.617 0: HMLAN_Parse: myHM R:R691F2F8C stat:0002 t:00000000 d:FF r:7FFF m:11 00CA 120408 220F80 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.24 18:05:57.745 0: HMLAN_Parse: myHM R:R691F2F99 stat:0002 t:00000000 d:FF r:7FFF m:12 00CA 120408 220F80 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.24 18:05:57.873 0: HMLAN_Parse: myHM R:R691F2FA4 stat:0002 t:00000000 d:FF r:7FFF m:13 00CA 120408 220F80 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.24 18:05:58.001 0: HMLAN_Parse: myHM R:R691F2FAF stat:0002 t:00000000 d:FF r:7FFF m:14 00CA 120408 220F80 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.24 18:05:58.129 0: HMLAN_Parse: myHM R:R691F2FBA stat:0002 t:00000000 d:FF r:7FFF m:15 00CA 120408 220F80 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.24 18:05:58.418 0: HMLAN_Parse: myHM R:R691F2FC5 stat:0001 t:003238E9 d:FF r:FFD8 m:16 0002 220F80 120408 00
2014.07.24 18:05:58.521 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.523 0: HMLAN_Send: myHM S:S691F355F stat: 00 t:00000000 d:01 r:691F355F m:17 00CA 120408 220F80 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D
2014.07.24 18:05:58.533 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.534 0: HMLAN_Send: myHM S:S691F35CB stat: 00 t:00000000 d:01 r:691F35CB m:18 00CA 120408 220F80 A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8
2014.07.24 18:05:58.544 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.546 0: HMLAN_Send: myHM S:S691F35D6 stat: 00 t:00000000 d:01 r:691F35D6 m:19 00CA 120408 220F80 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4
2014.07.24 18:05:58.556 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.558 0: HMLAN_Send: myHM S:S691F35E2 stat: 00 t:00000000 d:01 r:691F35E2 m:1A 00CA 120408 220F80 B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B
2014.07.24 18:05:58.568 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.571 0: HMLAN_Send: myHM S:S691F35EE stat: 00 t:00000000 d:01 r:691F35EE m:1B 00CA 120408 220F80 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6
2014.07.24 18:05:58.580 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.583 0: HMLAN_Send: myHM S:S691F35FA stat: 00 t:00000000 d:01 r:691F35FA m:1C 00CA 120408 220F80 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F
2014.07.24 18:05:58.592 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.595 0: HMLAN_Send: myHM S:S691F3606 stat: 00 t:00000000 d:01 r:691F3606 m:1D 00CA 120408 220F80 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9
2014.07.24 18:05:58.604 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.607 0: HMLAN_Send: myHM S:S691F3612 stat: 00 t:00000000 d:01 r:691F3612 m:1E 00CA 120408 220F80 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C
2014.07.24 18:05:58.616 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.618 0: HMLAN_Send: myHM S:S691F361E stat: 00 t:00000000 d:01 r:691F361E m:1F 00CA 120408 220F80 D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9
2014.07.24 18:05:58.635 0: HMLAN_Send: myHM S:+220F80,02,01,00
2014.07.24 18:05:58.636 0: HMLAN_Send: myHM S:S691F362F stat: 00 t:00000000 d:01 r:691F362F m:20 20CA 120408 220F80 7A83FB88752801F31504577AEB99CBFC580448707721
2014.07.24 18:05:58.648 0: HMLAN_Parse: myHM R:R691F355F stat:0002 t:00000000 d:FF r:7FFF m:17 00CA 120408 220F80 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D
Sollte dir doch was abgehen... hier ist der gesamte Output, bevor er abbricht:
https://owncloud.isengard.at/public.php?service=files&t=a8715abfc73c1deefe57da99fe6c0808 (https://owncloud.isengard.at/public.php?service=files&t=a8715abfc73c1deefe57da99fe6c0808)
Ich habe das Update mit einer CUL durchgeführt. Ist das Problem bei mir somit ein anderes?
Zitat von: holzwurm83 am 24 Juli 2014, 22:02:17
Ich habe das Update mit einer CUL durchgeführt. Ist das Problem bei mir somit ein anderes?
auf alle fälle, denn martin hat seine auch mit cul geflasht.
fwUpdate fail:notInBootLoader 2014-07-22 22:34:14hier warst du vielleicht zu langsam.
welche fw hat dein cul? muss glaube ich >=1.58 sein. ist der funk gut? ist fhem aktuell? wenn alles aktuell einfach noch mal probieren. sollte funktionieren. ist die fw-datei ok?
gruss frank
Zitatwelche fw hat dein cul? muss glaube ich >=1.58 sein.
Ist 1.58
Zitatst der funk gut?
Ist ca. 2m entfernt
Zitatist fhem aktuell?
Die Updates von heute hatte ich noch nicht probiert.
Zitatist die fw-datei ok?
Ein Update hat mit der Datei funktioniert. kann diese denn danach kaputt gehen?
ZitatEin Update hat mit der Datei funktioniert. kann diese denn danach kaputt gehen?
dann ist dein system doch ok! :)
vielleicht hilft es ja wenn du bei den anderen mal ein getconfig machst und schaust ob die aktion mit cmds_done beendet wird. anschliessend nochmal updaten.
Zitat von: holzwurm83 am 24 Juli 2014, 22:27:10
Ist ca. 2m entfernt
Es hat schon Fälle gegeben, da war das Funkmodul zu Nahe an der Zentrale (wodurch es zu einer Übersteuerung des Funksignales kommt). Bei den Standardübertragungen im 10k-Mode fällt es mit der einen oder anderen Wiederholung vielleicht nicht auf. Im 100k-Mode beim FW-Update könnte es hingegen wieder anders aussehen. Versuche einmal die Distanz zwischen den beiden Geräten zu vergrößern.
Hallo zusammen ich reihe mich mal der Problematik an mit ein paar Fragen :
1. Muss die Cul FW 1.58 sein und darf die auch höher sein das das fwupdate funktioniert ?? Meine ist momentan 1.61 .
Der HM-CC-RT-DN steht in CrC und wenn ich die mittelere Taste drück wechselt er in FUP .
Als Fehlermeldung kommt in FHEM fail:Block2 .
2. Der momentane FW Stand des HM-CC-RT-DN ist 1.1 kann ich gleich auf 1.3 update oder muss ich den zwischenschritt auf 1.2 machen ?? Wenn ja kann die mir jemand schicken auf der EQ3 Seite finde
ich die 1.2 nicht mehr .
2014.07.24 20:50:31.908 2: CUL_HM fwUpdate started for HZ_Bad
2014.07.24 20:50:31.930 1: SND L:0A N:0A F:30 CMD:11 SRC:F11034 DST:HZ_Bad CA (EnterBootLoader) (,BURST,BIDI)
2014.07.24 20:50:31.963 3: CUL_HM set HZ_Bad fwUpdate ./hm_cc_rt_dn_update_V1_3_001_140314.eq3 100
2014.07.24 20:51:41.411 2: CUL_HM fwUpdate HZ_Bad entered mode - switch speed
2014.07.24 20:51:41.529 1: SND L:0F N:0B F:00 CMD:CB SRC:F11034 DST:HZ_Bad 105B11F81547 ()
2014.07.24 20:51:41.654 1: SND L:27 N:0D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34 ()
2014.07.24 20:51:41.685 1: SND L:27 N:0E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F ()
2014.07.24 20:51:41.717 1: SND L:27 N:0F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF ()
2014.07.24 20:51:41.749 1: SND L:27 N:10 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB ()
2014.07.24 20:51:41.781 1: SND L:27 N:11 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6 ()
2014.07.24 20:51:41.813 1: SND L:27 N:12 F:00 CMD:CA SRC:F11034 DST:HZ_Bad F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518 ()
2014.07.24 20:51:41.843 1: SND L:27 N:13 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74 ()
2014.07.24 20:51:41.874 1: SND L:27 N:14 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1 ()
2014.07.24 20:51:41.906 1: SND L:27 N:15 F:00 CMD:CA SRC:F11034 DST:HZ_Bad B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA ()
2014.07.24 20:51:41.938 1: SND L:1F N:16 F:20 CMD:CA SRC:F11034 DST:HZ_Bad BC38887AD05570ED214EF26881E22B6A46FE912372CC (,BIDI)
2014.07.24 20:51:41.974 1: SND L:0A N:26 F:30 CMD:11 SRC:F11034 DST:HZ_Bad CA (EnterBootLoader) (,BURST,BIDI)
2014.07.24 20:51:42.108 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.24 20:51:42.138 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.24 20:51:42.166 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.24 20:51:42.195 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.24 20:51:42.225 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.24 20:51:42.253 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.24 20:51:42.282 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.24 20:51:42.313 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.24 20:51:42.343 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.24 20:51:42.374 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
2014.07.24 20:51:47.410 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.24 20:51:47.440 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.24 20:51:47.469 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.24 20:51:47.499 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.24 20:51:47.529 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.24 20:51:47.559 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.24 20:51:47.588 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.24 20:51:47.619 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.24 20:51:47.649 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.24 20:51:47.681 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
2014.07.24 20:51:52.613 3: set WWBSteuerung on-for-timer 60 : FW update in progress - please wait
2014.07.24 20:51:52.614 3: WWBEINAUS: FW update in progress - please wait
2014.07.24 20:51:52.715 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.24 20:51:52.745 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.24 20:51:52.774 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.24 20:51:52.803 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.24 20:51:52.832 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.24 20:51:52.861 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.24 20:51:52.890 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.24 20:51:52.918 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.24 20:51:52.947 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.24 20:51:52.978 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
2014.07.24 20:51:58.012 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.24 20:51:58.053 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.24 20:51:58.082 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.24 20:51:58.111 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.24 20:51:58.140 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.24 20:51:58.168 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.24 20:51:58.198 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.24 20:51:58.227 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.24 20:51:58.255 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.24 20:51:58.287 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
Momentan wenn ich den Heizungsregler neustarte bleibt er immer in CrC stehen .
Wenn mir jemand helfen könnte wäre ich sehr dankbar .
Zitat1. Muss die Cul FW 1.58 sein und darf die auch höher sein das das fwupdate funktioniert ?? Meine ist momentan 1.61 .
bei mir auch.
hast du auch ein passendes 00_CUL? Ich denke Rudi hat die timing-updates noch nicht eingebaut
warum schaltest du hmProtokoEvents ein? Schalte es aus und logge die rohmessages 'normal' - das spart performance
ZitatDer HM-CC-RT-DN steht in CrC und wenn ich die mittelere Taste drück wechselt er in FUP .
dann ist ein updateversuch schief gegangen. mache clear mgEvents (sicherheitshalber) und fwUpdate <file> 30. dann versetze den RT nach FUP. Dann wird es noch einmal gestartet.
Du kannst von 1.1 direkt nach 1.3
ZitatMomentan wenn ich den Heizungsregler neustarte bleibt er immer in CrC stehen .
die FW ist "kaputt geschrieben". Der rt hat noch den bootlader und kann einen update machen. Die operationelle FW ist "hin". Faktisch hat er aktuell also KEINE FW mehr. Wie gesagt, der Update sollte immer noch funktionieren - hat bei mir auch
Vielen Dank für die Antworten,
Wie muss ich die 00_CUL abändern finde den einstieg nicht wo es beschrieben ist . Sorry
Ansonsten immer wieder hammer wie hier geholfen wird .
anbei mein 00_CUL.
Gruss Martin
hi martin,
es gibt aktuell v1.61 als standard. hat glaube ich nichts mit "deiner v1.61" zu tun, falls du diese meinst http://forum.fhem.de/index.php/topic,25058.msg181910.html#msg181910 (http://forum.fhem.de/index.php/topic,25058.msg181910.html#msg181910). nicht das es hier verwechslungen und komplikationen gibt.
ZitatVersion 1.61 (2014-06-28)
- Fix asksin "garbage" message, after X00 followed by X21 (fhem restart)
Version 1.60 (2014-06-22)
- RX/TX switch bugfix (saves 2ms when switching)
Version 1.59 (2014-06-15)
- added display_hex8 function in display.h/.c. Is compiled with #define
HAS_DISPLAY_32BIT_HEX8. by noansi
- added cc1101 PLL lock check functions and task, see cc1101_pllcheck.h/.c.
by noansi
- added receiving support of wireless m-bus (T or S mode)
- SOMFY/Simu send routines by thdankert
- rpiaddon: initial version for Raspberry PI addon board by Damian Nelson
- SCC: inital addition of new RPi extension
- UNIROLL send routines (currently CUL only) by C_Herrmann
Version 1.58 (2014-03-14)
- CUNO2: support for KWL EC 200/300/500 Helios Lueftungen (HAS_HELIOS) via
RS485
- !CUL: extended command for reading unique eeprom values provided by Dudette
bootloader. (RM: MAC addr / RP: 128bit RSA private key)
- all: added sending support for "Kxxxx" messages (requires RAWSEND enabled)
- all: IT & REVOLT receive support from mehf (disabled per default)
- all: add AskSin-support for OTA firmware-update
nur mal so als hinweis.
gruss frank
möglich....
mal sehen, ob das projekt CUL-Timing schon verworfen wurde. Wäre schade.
Jetzt sthet leider in der Logfile mit der neuen 00_CUL :
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
sollte kein Problem sein. Deine CUL ist wahrscheinlich noch nicht "timing-fähig".
Den Fehler werden ich entfernen.
"Meine" 1.61 ist im Anhang. Leider mit der gleichen nummer. Die kann timestamps und damit eine timing korrektur
Leider nicht Cul wurde mit FLIP geflasht !
Fhem neugestart
2014.07.25 16:49:43.346 2: CUL_HM fwUpdate HZ_Bad entered mode - switch speed
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5210.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5210.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5210.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
Use of uninitialized value in division (/) at ./FHEM/00_CUL.pm line 602.
wenn du die CUL nicht flashst wird dir die neue SW nichts bringen.
Der Fehler sollte verschwinden, wenn du in Zeile 895 addierst
} else {
$dmsgLog = " ".join(" ",(unpack'A1A2A2A4A6A6A*',$dmsg));
$hash->{helper}{ref}{dly} = 0;
}
Hallo zusammen,
ich habe das mit dem Update noch einige mal probiert, aber leider ohne erfolg. >:(
Es steht weiterhin CRC auf dem RT.
Zitat2014.07.25 20:00:09 2: CUL_HM fwUpdate started for AZ_RT_links
2014.07.25 20:00:09 5: CUL_HM AZ_RT_links protEvent:CMDs_processing...
2014.07.25 20:00:09 3: CUL_HM set AZ_RT_links fwUpdate hm_cc_rt_dn_update_V1_3_001_140314.eq3 30
2014.07.25 20:00:14 4: CUL_HM_Resend: AZ_RT_links nr 2
2014.07.25 20:00:14 5: CUL_HM AZ_RT_links protEvent:CMDs_pending pending:1
2014.07.25 20:00:17 2: CUL_HM fwUpdate AZ_RT_links entered mode - switch speed
2014.07.25 20:00:17 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM fwUpdate write block 1 of 234: 10 messages
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:1
2014.07.25 20:00:18 5: CUL_HM AZ_RT_links protEvent:CMDs_processing... pending:0
2014.07.25 20:00:22 4: CUL_HM_Resend: AZ_RT_links nr 3
2014.07.25 20:00:22 5: CUL_HM AZ_RT_links protEvent:CMDs_pending pending:1
Kann ich überhaupt von 1.0 auf 1.3 Updaten?
Ich hoffe wir reden nicht aneinander vorbei mit die CUL meinst du doch den CUL USB STICK ??
Ich habe deine hex datei runtergeladen und mit FLIP geflasht .
Abänderung der 00_CUL.pm brachte besserung keine Fehlermeldung mehr seitens Subroutine mehr .
Aber leider beendet er das update mit Fehlermeldung immer noch mit fail:Block2 .
2014.07.25 20:16:54.241 2: CUL_HM fwUpdate started for HZ_Bad
2014.07.25 20:16:54.284 3: CUL_HM set HZ_Bad fwUpdate ./hm_cc_rt_dn_update_V1_3_001_140314.eq3 100
2014.07.25 20:17:02.409 3: set WWBSteuerung on-for-timer 60 : FW update in progress - please wait
2014.07.25 20:17:02.411 3: WWBEINAUS: FW update in progress - please wait
2014.07.25 20:17:04.798 2: CUL_HM fwUpdate HZ_Bad entered mode - switch speed
Hallo zusammen,
ich habe es nun endlich geschafft alle meine RTs upzudaten! ;D
Die RTs zeigen beim Start immer 1.3 an, aber in Fhem steht immer noch 1.1 oder 1.0. Muss ich da noch mal was machen?
Mir ist auch noch in diesem Zusammenhang aufgefallen, dass Fhem nicht für alle RTs LogFiles angelegt hat. Kann ich das irgendwie automatisch nachholen?
Des weiteren sind die RTs von Fhem unterschiedlich angelegt worden. Liegt denke ich daran das ich mir die RTs nach und nach gekauft habe und zum teil mit unterschiedlichen FWs? Kann ich das auch irgendwie automatisch anpassen?
Zitatdefine BAD_RT_rechts CUL_HM 22080F
attr BAD_RT_rechts .devInfo 00FFFF
attr BAD_RT_rechts .stc 59
attr BAD_RT_rechts IODev CUL_1
attr BAD_RT_rechts actCycle 000:10
attr BAD_RT_rechts actStatus alive
attr BAD_RT_rechts autoReadReg 4_reqStatus
attr BAD_RT_rechts expert 2_full
attr BAD_RT_rechts firmware 1.0
attr BAD_RT_rechts model HM-CC-RT-DN
attr BAD_RT_rechts room CUL_HM
attr BAD_RT_rechts serialNr KEQ0510505
attr BAD_RT_rechts subType thermostat
attr BAD_RT_rechts webCmd getConfig:burstXmit
define BAD_RT_links CUL_HM 240233
attr BAD_RT_links IODev CUL_1
attr BAD_RT_links actCycle 000:10
attr BAD_RT_links actStatus alive
attr BAD_RT_links autoReadReg 4_reqStatus
attr BAD_RT_links expert 2_full
attr BAD_RT_links firmware 1.1
attr BAD_RT_links model HM-CC-RT-DN
attr BAD_RT_links room CUL_HM
attr BAD_RT_links serialNr KEQ0909222
attr BAD_RT_links subType thermostat
attr BAD_RT_links verbose 5
attr BAD_RT_links webCmd getConfig:clear msgEvents:burstXmit
Hallo holzwurm83,
wie hast du das geschafft ich habe den Cul Stick geflasht und die 00_CUL wie beschrieben von martin hergenommen aber bei gehts einfach nicht .
Zitat von: Mani007 am 26 Juli 2014, 18:14:03
Hallo holzwurm83,
wie hast du das geschafft ich habe den Cul Stick geflasht und die 00_CUL wie beschrieben von martin hergenommen aber bei gehts einfach nicht .
Ich habe das mit der CUL FW Version 1.58 gemacht. Und habe das meine Fhemumgebung die ich mir vor einigen Tagen in einer VirtualBox mit Linux Debian aufgebaut habe noch mal probiert. Anfangs ging es nicht allerdings lag das dann wohl eher daran, das ich das letzte Fhem update da noch nicht drauf hatte. Da die VirtualBox auf meinem MacBook Pro läuft habe ich die CUL da angesteckt und bin zu jedem RT um die Sendequalität sicher zu stellen.
ZitatDie RTs zeigen beim Start immer 1.3 an, aber in Fhem steht immer noch 1.1 oder 1.0. Muss ich da noch mal was machen?
das sollte sich ändern, wenn du den rt in den anlernmodus bringst. nur den rt. fhem nicht.
ZitatMir ist auch noch in diesem Zusammenhang aufgefallen, dass Fhem nicht für alle RTs LogFiles angelegt hat. Kann ich das irgendwie automatisch nachholen?
Des weiteren sind die RTs von Fhem unterschiedlich angelegt worden. Liegt denke ich daran das ich mir die RTs nach und nach gekauft habe und zum teil mit unterschiedlichen FWs? Kann ich das auch irgendwie automatisch anpassen?
wenn du das nicht manuell machen möchtest, kannst du natürlich auch alles löschen und nochmal neu anlegen lassen (pair). dann sind deine änderungen aber auch weg.
und immer an save denken. ;)
gruss frank
Weiss noch jemand rat oder muss ich den thermostat einschicken oder einen neuen kaufen . Ich trau mich keinen 2 rt zu flashen .
poste doch mal ein aussagekräftiges log vom flashvorgang mit den dateien, die du von martin bekommen hast. deine funkverbindung ist gut? wo hast du die eq3 datei her? ist die ok?
benutze zum downloaden keinen ms internetexplorer.
Hallo Frank ich habe die hex Datei aus den post von Seite 59 genommen sowie die 00_CUL.pm von der gleichen Seite .
Die Firmware habe ich von der http://www.eq-3.de/downloads.html Seite und auf die Nas der Fritzbox hochgeladen die hat entpackt
132,92 kb laut fritznas heruntergeladen habe ich es mit firefox .
Vorgang : set HZ_Bad fw Update eq3File 100 und drücke dann beim Thermostat die mittlere Taste und das Thermo zeigt FUP an.
Aber nicht lange wechselt ziemlich schnell wieder in CrC .
fwUpdate Fhem schreibt dann Fail:Block2
state CMDs_done_FWupdate
Funkverbindung CUL_0_RSSI -59.5
2014.07.27 06:35:43.568 1: SND L:0A N:0A F:30 CMD:11 SRC:F11034 DST:HZ_Bad CA (EnterBootLoader) (,BURST,BIDI)
2014.07.27 06:35:43.611 3: CUL_HM set HZ_Bad fwUpdate ./hm_cc_rt_dn_update_V1_3_001_140314.eq3 100
2014.07.27 06:36:04.293 3: set Patis_Lieblings_Lampe off : FW update in progress - please wait
2014.07.27 06:36:04.294 3: PatiLiebllampe return value: FW update in progress - please wait
2014.07.27 06:36:04.333 3: set Patis_Lieblings_Lampe off : FW update in progress - please wait
2014.07.27 06:36:04.334 3: PatiLiebllampe return value: FW update in progress - please wait
2014.07.27 06:36:04.369 3: set Patis_Lieblings_Lampe off : FW update in progress - please wait
2014.07.27 06:36:04.370 3: PatiLiebllampe return value: FW update in progress - please wait
2014.07.27 06:36:04.404 3: set Patis_Lieblings_Lampe off : FW update in progress - please wait
2014.07.27 06:36:04.406 3: PatiLiebllampe return value: FW update in progress - please wait
2014.07.27 06:36:04.440 3: set Patis_Lieblings_Lampe off : FW update in progress - please wait
2014.07.27 06:36:04.441 3: PatiLiebllampe return value: FW update in progress - please wait
2014.07.27 06:36:04.477 3: set Patis_Lieblings_Lampe off : FW update in progress - please wait
2014.07.27 06:36:04.480 3: PatiLiebllampe return value: FW update in progress - please wait
2014.07.27 06:36:09.739 3: set WWBSteuerung off : FW update in progress - please wait
2014.07.27 06:36:09.741 3: WWBEINAUS: FW update in progress - please wait
2014.07.27 06:36:10.855 3: set Terassenlicht inhibit on : FW update in progress - please wait
2014.07.27 06:36:10.858 3: TerasseSunset: FW update in progress - please wait
2014.07.27 06:36:33.509 2: CUL_HM fwUpdate HZ_Bad entered mode - switch speed
2014.07.27 06:36:33.621 1: SND L:0F N:0B F:00 CMD:CB SRC:F11034 DST:HZ_Bad 105B11F81547 ()
2014.07.27 06:36:33.764 1: SND L:27 N:0D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34 ()
2014.07.27 06:36:33.800 1: SND L:27 N:0E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F ()
2014.07.27 06:36:33.835 1: SND L:27 N:0F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF ()
2014.07.27 06:36:33.870 1: SND L:27 N:10 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB ()
2014.07.27 06:36:33.905 1: SND L:27 N:11 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6 ()
2014.07.27 06:36:33.940 1: SND L:27 N:12 F:00 CMD:CA SRC:F11034 DST:HZ_Bad F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518 ()
2014.07.27 06:36:33.975 1: SND L:27 N:13 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74 ()
2014.07.27 06:36:34.010 1: SND L:27 N:14 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1 ()
2014.07.27 06:36:34.043 1: SND L:27 N:15 F:00 CMD:CA SRC:F11034 DST:HZ_Bad B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA ()
2014.07.27 06:36:34.079 1: SND L:1F N:16 F:20 CMD:CA SRC:F11034 DST:HZ_Bad BC38887AD05570ED214EF26881E22B6A46FE912372CC (,BIDI)
2014.07.27 06:36:34.215 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.27 06:36:34.249 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.27 06:36:34.285 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.27 06:36:34.320 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.27 06:36:34.355 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.27 06:36:34.391 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.27 06:36:34.426 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.27 06:36:34.460 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.27 06:36:34.495 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.27 06:36:34.529 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
2014.07.27 06:36:39.570 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.27 06:36:39.604 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.27 06:36:39.639 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.27 06:36:39.673 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.27 06:36:39.708 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.27 06:36:39.743 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.27 06:36:39.777 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.27 06:36:39.814 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.27 06:36:39.849 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.27 06:36:39.882 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
2014.07.27 06:36:44.925 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.27 06:36:44.959 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.27 06:36:44.993 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.27 06:36:45.026 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.27 06:36:45.060 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.27 06:36:45.094 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.27 06:36:45.127 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.27 06:36:45.161 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.27 06:36:45.195 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.27 06:36:45.229 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
2014.07.27 06:36:50.269 1: SND L:27 N:17 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D ()
2014.07.27 06:36:50.303 1: SND L:27 N:18 F:00 CMD:CA SRC:F11034 DST:HZ_Bad A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8 ()
2014.07.27 06:36:50.338 1: SND L:27 N:19 F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4 ()
2014.07.27 06:36:50.372 1: SND L:27 N:1A F:00 CMD:CA SRC:F11034 DST:HZ_Bad B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B ()
2014.07.27 06:36:50.406 1: SND L:27 N:1B F:00 CMD:CA SRC:F11034 DST:HZ_Bad 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6 ()
2014.07.27 06:36:50.441 1: SND L:27 N:1C F:00 CMD:CA SRC:F11034 DST:HZ_Bad 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F ()
2014.07.27 06:36:50.478 1: SND L:27 N:1D F:00 CMD:CA SRC:F11034 DST:HZ_Bad 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9 ()
2014.07.27 06:36:50.512 1: SND L:27 N:1E F:00 CMD:CA SRC:F11034 DST:HZ_Bad 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C ()
2014.07.27 06:36:50.546 1: SND L:27 N:1F F:00 CMD:CA SRC:F11034 DST:HZ_Bad D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9 ()
2014.07.27 06:36:50.581 1: SND L:1F N:20 F:20 CMD:CA SRC:F11034 DST:HZ_Bad 7A83FB88752801F31504577AEB99CBFC580448707721 (,BIDI)
dass die RTs unterschiedlich angelegt sind, dann ich nicht sehen. OK, die reihenfolgen und das webkommand.
Die Reihenfolge ist Rudis sache.
um default webcommands zu haben lösche das Attribut, speichere und starte neu, speichere wieder. Der Vorgang ist: wenn ein webcmd gesetzt ist, wird es nicht verändert. Wenn beim booten kein webCmd eingetragen ist wird ggf. ein default gesetzt.
@Mani,
schalte hmProtocolEvents ab. Logge rohmessages wie in Sniffen beschrieben.
Probieren es noch einmal mit diese settings - hmProtocolEvents ist evtl. zeitraubend.
Hallo Martin,
ich habe es gemacht wie im wiki beschrieben ist habe hmprotocol events ausgeschaltet und attr cul verbose 4 eingeschaltet .
Zeigt sich leider keine besserung .
2014.07.27 09:00:04.519 4: CUL_send: CUL_0 As 0E EB A011 F11034 23E657 0201000000
2014.07.27 09:00:04.806 4: CUL_Parse: CUL_0 A 0C E6 8670 223EF9 000000 00E264 -69.5
2014.07.27 09:00:04.931 4: CUL_Parse: CUL_0 A 0E EB 8002 23E657 F11034 0101000053 -80.5
2014.07.27 09:00:05.032 4: CUL_send: CUL_0 As 0E EC A011 F11034 23E657 0201000000
2014.07.27 09:00:05.193 4: CUL_Parse: CUL_0 A 0E EC 8002 23E657 F11034 0101000053 -80.5
2014.07.27 09:00:05.293 4: CUL_send: CUL_0 As 0E ED A011 F11034 23E657 0201000000
2014.07.27 09:00:05.454 4: CUL_Parse: CUL_0 A 0E ED 8002 23E657 F11034 0101000053 -80
2014.07.27 09:00:05.555 4: CUL_send: CUL_0 As 0E EE A011 F11034 23E657 0201000000
2014.07.27 09:00:05.715 4: CUL_Parse: CUL_0 A 0E EE 8002 23E657 F11034 0101000052 -80
2014.07.27 09:00:05.816 4: CUL_send: CUL_0 As 0E EF A011 F11034 23E657 0201000000
2014.07.27 09:00:06.639 4: CUL_Parse: CUL_0 A 0F C7 8610 22E52F 000000 0A30DB0D0018 -63.5
2014.07.27 09:00:09.762 4: CUL_send: CUL_0 As 0E F0 A011 F11034 22638F 0201000000
2014.07.27 09:00:09.923 4: CUL_Parse: CUL_0 A 0E F0 8002 22638F F11034 0101000050 -79
2014.07.27 09:00:10.101 4: CUL_send: CUL_0 As 0E EF A011 F11034 23E657 0201000000
2014.07.27 09:00:10.262 4: CUL_Parse: CUL_0 A 0E EF 8002 23E657 F11034 0101000052 -80
2014.07.27 09:00:10.363 4: CUL_send: CUL_0 As 0E F1 A011 F11034 23E657 0201000000
2014.07.27 09:00:10.523 4: CUL_Parse: CUL_0 A 0E F1 8002 23E657 F11034 0101000052 -81
2014.07.27 09:00:19.568 4: CUL_send: CUL_0 As 0A 0A 3011 F11034 22E470 CA
2014.07.27 09:00:21.691 4: CUL_Parse: CUL_0 A 0F 23 8610 22E4C8 000000 0A30D40E0029 -58
2014.07.27 09:00:26.677 4: CUL_Parse: CUL_0 A 0F 31 8610 22E518 000000 0A30DE0C0019 -69.5
2014.07.27 09:00:29.192 4: CUL_Parse: CUL_0 A 14 EE 7510 22E470 000000 004B455130373333373936 -59.5
2014.07.27 09:00:29.293 4: CUL_send: CUL_0 As 0F 0B 00CB F11034 22E470 105B11F81547
2014.07.27 09:00:29.347 4: CUL_send: CUL_0 AR
2014.07.27 09:00:29.405 4: CUL_send: CUL_0 As 27 0D 00CA F11034 22E470 012200CA89997B1356A99599FC97B51B2E93E851AC0FD87443CAED392B34
2014.07.27 09:00:29.420 4: CUL_send: CUL_0 As 27 0E 00CA F11034 22E470 5B3F1C5CDB3492C3DAAD3BEAC7474BD2670EC00359D9358EBEE6CBBE592F
2014.07.27 09:00:29.436 4: CUL_send: CUL_0 As 27 0F 00CA F11034 22E470 D090BBF52DAD224F72068C335DDB71FE2597E4A9D5F6AF3C955C014868AF
2014.07.27 09:00:29.452 4: CUL_send: CUL_0 As 27 10 00CA F11034 22E470 06A7FD6D6F28AE164A7075573F5C23B21B786D3AE79868C9A3F2F6083FCB
2014.07.27 09:00:29.468 4: CUL_send: CUL_0 As 27 11 00CA F11034 22E470 721FE837B555A041BFD89ACBA38AE9A75A6A0C372F4810253F4ECC1438D6
2014.07.27 09:00:29.485 4: CUL_send: CUL_0 As 27 12 00CA F11034 22E470 F12AFE2D6D8EE06695BE5F2B281D8EEE2E847431A2E078B7F3A56AF8E518
2014.07.27 09:00:29.501 4: CUL_send: CUL_0 As 27 13 00CA F11034 22E470 4A031DBB51D5705A32A688A548A6CDDB943BE1E717503371423FA11EFB74
2014.07.27 09:00:29.516 4: CUL_send: CUL_0 As 27 14 00CA F11034 22E470 192D962E6C3CD7579194D69314219C025E90419932BBB1133D7410DD70C1
2014.07.27 09:00:29.532 4: CUL_send: CUL_0 As 27 15 00CA F11034 22E470 B8E33C2E4427FA3678D651B647AE30549914F632CE5844A9BC07337CCCBA
2014.07.27 09:00:29.548 4: CUL_send: CUL_0 As 1F 16 20CA F11034 22E470 BC38887AD05570ED214EF26881E22B6A46FE912372CC
2014.07.27 09:00:29.576 4: CUL_Parse: CUL_0 A 0A 16 0002 22E470 F11034 00 -63
2014.07.27 09:00:29.677 4: CUL_send: CUL_0 As 27 17 00CA F11034 22E470 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D
2014.07.27 09:00:29.692 4: CUL_send: CUL_0 As 27 18 00CA F11034 22E470 A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8
2014.07.27 09:00:29.708 4: CUL_send: CUL_0 As 27 19 00CA F11034 22E470 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4
2014.07.27 09:00:29.725 4: CUL_send: CUL_0 As 27 1A 00CA F11034 22E470 B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B
2014.07.27 09:00:29.740 4: CUL_send: CUL_0 As 27 1B 00CA F11034 22E470 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6
2014.07.27 09:00:29.756 4: CUL_send: CUL_0 As 27 1C 00CA F11034 22E470 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F
2014.07.27 09:00:29.772 4: CUL_send: CUL_0 As 27 1D 00CA F11034 22E470 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9
2014.07.27 09:00:29.788 4: CUL_send: CUL_0 As 27 1E 00CA F11034 22E470 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C
2014.07.27 09:00:29.804 4: CUL_send: CUL_0 As 27 1F 00CA F11034 22E470 D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9
2014.07.27 09:00:29.820 4: CUL_send: CUL_0 As 1F 20 20CA F11034 22E470 7A83FB88752801F31504577AEB99CBFC580448707721
2014.07.27 09:00:34.843 4: CUL_send: CUL_0 As 27 17 00CA F11034 22E470 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D
2014.07.27 09:00:34.859 4: CUL_send: CUL_0 As 27 18 00CA F11034 22E470 A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8
2014.07.27 09:00:34.875 4: CUL_send: CUL_0 As 27 19 00CA F11034 22E470 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4
2014.07.27 09:00:34.891 4: CUL_send: CUL_0 As 27 1A 00CA F11034 22E470 B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B
2014.07.27 09:00:34.906 4: CUL_send: CUL_0 As 27 1B 00CA F11034 22E470 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6
2014.07.27 09:00:34.923 4: CUL_send: CUL_0 As 27 1C 00CA F11034 22E470 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F
2014.07.27 09:00:34.939 4: CUL_send: CUL_0 As 27 1D 00CA F11034 22E470 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9
2014.07.27 09:00:34.954 4: CUL_send: CUL_0 As 27 1E 00CA F11034 22E470 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C
2014.07.27 09:00:34.970 4: CUL_send: CUL_0 As 27 1F 00CA F11034 22E470 D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9
2014.07.27 09:00:34.986 4: CUL_send: CUL_0 As 1F 20 20CA F11034 22E470 7A83FB88752801F31504577AEB99CBFC580448707721
2014.07.27 09:00:40.010 4: CUL_send: CUL_0 As 27 17 00CA F11034 22E470 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D
2014.07.27 09:00:40.026 4: CUL_send: CUL_0 As 27 18 00CA F11034 22E470 A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8
2014.07.27 09:00:40.042 4: CUL_send: CUL_0 As 27 19 00CA F11034 22E470 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4
2014.07.27 09:00:40.058 4: CUL_send: CUL_0 As 27 1A 00CA F11034 22E470 B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B
2014.07.27 09:00:40.074 4: CUL_send: CUL_0 As 27 1B 00CA F11034 22E470 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6
2014.07.27 09:00:40.090 4: CUL_send: CUL_0 As 27 1C 00CA F11034 22E470 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F
2014.07.27 09:00:40.106 4: CUL_send: CUL_0 As 27 1D 00CA F11034 22E470 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9
2014.07.27 09:00:40.123 4: CUL_send: CUL_0 As 27 1E 00CA F11034 22E470 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C
2014.07.27 09:00:40.139 4: CUL_send: CUL_0 As 27 1F 00CA F11034 22E470 D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9
2014.07.27 09:00:40.155 4: CUL_send: CUL_0 As 1F 20 20CA F11034 22E470 7A83FB88752801F31504577AEB99CBFC580448707721
2014.07.27 09:00:45.178 4: CUL_send: CUL_0 As 27 17 00CA F11034 22E470 012217578B6969A2005A1AD97561EB0DE35B3089B34F8C735AEF4498216D
2014.07.27 09:00:45.194 4: CUL_send: CUL_0 As 27 18 00CA F11034 22E470 A1D2B9A175281A3AE02F5BDE2D7CB85DC91729D2116664B9ABFA9A94EDA8
2014.07.27 09:00:45.210 4: CUL_send: CUL_0 As 27 19 00CA F11034 22E470 1C706ED330F9108D88CBAB0A89B7813FA2A02DB2CAE6D0E4343A475B08B4
2014.07.27 09:00:45.227 4: CUL_send: CUL_0 As 27 1A 00CA F11034 22E470 B2F57AF6D16359241000DBDF2F639A2E7D56155FDE060BAC7FE96E94645B
2014.07.27 09:00:45.244 4: CUL_send: CUL_0 As 27 1B 00CA F11034 22E470 72D1B8065424126ED5E2531AEB31C5236D35D54376CAB33EED5116C504C6
2014.07.27 09:00:45.260 4: CUL_send: CUL_0 As 27 1C 00CA F11034 22E470 025F83D8848CB755BEABAA31790E3D05EBF004F55CFE2F50A534F29F1C8F
2014.07.27 09:00:45.276 4: CUL_send: CUL_0 As 27 1D 00CA F11034 22E470 722D4A5F0E876550D0D8AA8D5D36757457596D5FE6C8C1AD98A4CFB024C9
2014.07.27 09:00:45.291 4: CUL_send: CUL_0 As 27 1E 00CA F11034 22E470 1018246FFC919B426E35B07A6B80D86FC1CC3CE9083AFA882DA6C1C3FA5C
2014.07.27 09:00:45.307 4: CUL_send: CUL_0 As 27 1F 00CA F11034 22E470 D461AD57E22BB03758365C90D0F59E208B9D906F6C8857C9A3EF3D1320E9
2014.07.27 09:00:45.324 4: CUL_send: CUL_0 As 1F 20 20CA F11034 22E470 7A83FB88752801F31504577AEB99CBFC580448707721
der Anfang sieht gut aus, das Device akzeptiert das erste Packet...
aber dann mag es nicht mehr. Grund sehe ich keinen. Timing stimmt, daten stimmen. quasi identisch zu meinem log.
Nur antworten mag es ab dem 2. Packet nicht mehr.
Da bin ich erst einmal am Ende - sorry.
Ok dann weiß ich schonmal das ich wenigstens nichts falsch mache .
Ganz ehrlich das glaube ich jetzt nicht !!!!!!!
http://homematic-forum.de/forum/viewtopic.php?f=26&t=15587&start=110
und das wars ich bin zu nahe an den Thermo gestanden . Ohman
Zitat von: Mani007 am 27 Juli 2014, 10:17:28
und das wars ich bin zu nahe an den Thermo gestanden . Ohman
Erinnert mich irgendwie daran, was ich euch hier in diesem Thread vor nicht allzu langer Zeit gesagt habe: ;-)
http://forum.fhem.de/index.php/topic,14738.msg186498.html#msg186498 (http://forum.fhem.de/index.php/topic,14738.msg186498.html#msg186498)
Hallo @ All
ich habe:
4x HM-CC-RT-DN mit FW: 1.0
1x HMLan mit FW: 0.961
aktuellstes FHEM mit einem Update von heute vor 5 min
FRAGE:
- kann ich mit dem HMLan nun die Firmware der HM-CC-RT-DN auf 1.3 updaten oder nicht?
(Ich frage, weil laut Wiki die Aussage ist, dass es bisher nicht geht)
ZitatErinnert mich irgendwie daran, was ich euch hier in diesem Thread vor nicht allzu langer Zeit gesagt habe: ;-)
wie mit der heissen herdplatte. man muss sich erst die hand verbrennen, bevor man die erfahrungen anderer versteht. ;)
Zitat- kann ich mit dem HMLan nun die Firmware der HM-CC-RT-DN auf 1.3 updaten oder nicht?
nein.
Zitat von: frank am 27 Juli 2014, 13:34:36
- kann ich mit dem HMLan nun die Firmware der HM-CC-RT-DN auf 1.3 updaten oder nicht?
nein.
Danke!
Dann muss ich warten bis ich meinen CUL wieder habe.
Wie es Murphy so will habe ich den grad am Freitag verliehen um einen Arbeitskollegen "anzufixen" was FHEM angeht.
@frank,
Ja hast recht so nachn motto wer lesen kann ist klar im vorteil . Bin trotzdem froh das funktioniert . Vielen dank für eure hilfe und geduld .
Zitat von: martinp876 am 27 Juli 2014, 07:41:30
dass die RTs unterschiedlich angelegt sind, dann ich nicht sehen. OK, die reihenfolgen und das webkommand.
Die Reihenfolge ist Rudis sache.
um default webcommands zu haben lösche das Attribut, speichere und starte neu, speichere wieder. Der Vorgang ist: wenn ein webcmd gesetzt ist, wird es nicht verändert. Wenn beim booten kein webCmd eingetragen ist wird ggf. ein default gesetzt.
Das mit der Reihenfolge ist mir nicht so wichtig. Manche RTs haben das hier drin stehen:
Zitatattr BAD_RT_rechts .devInfo 00FFFF
attr BAD_RT_rechts .stc 59
Kann das nicht zuordnen. Was ist das?
Das mit dem webCmd hat wunderbar funktioniert.
devInfo und stc.
das sind beides Werte, die das Device mit der Anlernmessage sendet.
Beides speichere ich mittlerweile in Readings. Das gleiche gilt für die Serial Number und die FW-version. Es fällt unter HM-Device-config-data. Funktionen aus HMInfo (save/load/verify/arch/purge -Config) speichern und verwalten - hier fallen dann auch die Register und peers drunter.
Als attribut braucht man keines der 4.
stc ist die nummer des subType wie eq3 sie vergibt. FHEM leitet den Subtype direkt aus dem attribut "Model" (des device, nicht der channel!) ab.
devInfo habe ich noch nicht entschlüsselt. Es sollte infos beinhalten wie
- anzahl der Kanäle
- kommunikations-mode (wakeup, config,...)
- evtl. zustand des pairens
der Wert wird nicht ausgewertet - vielleicht irgend wann einmal.
Einst waren die 4 Werte teil der Attribute. stc und defInfo kannst du gerne löschen.
Hallo wollte heute mal mit den Thermostaten bischen rumspielen aber irgendwie funkioniert es vom Handy aus nicht die Schaltzeiten bzw. Themperaturen zu ändern ?
geb ich z.B. einen Wert bei ändern ein 17.4 steht am RT 11.0 und andFhem stürtzt ab.
Habe HM-CC-RT-DN firmware 1.3
andFhem 3.1.3
Gruß otto
Hallo zusammen,
bin gerade darauf gestoßen, dass es eine eine FW 1.4.001 vom 20.10.2014 gibt:
http://www.eq-3.de/Downloads/Software/Firmware/changelog_hm_cc_rt_dn_update_V1_4_001_141020.txt
Hat die schon jemand ausprobiert? Funktioniert die besser oder schlechter als die 1.3?
Danke und Grüße,
Michi
Hallo michi1983
Wahrscheinlich, sicher besser....!
Siehe hier http://forum.fhem.de/index.php/topic,25527.0.html (http://forum.fhem.de/index.php/topic,25527.0.html)
CK
Hallo zusammen,
habe schon einiges durchstöbert, aber nicht so richtig auf den Nenner gekommen.
Ich habe habe mir Drahtgebundene Fensterkontakte über ein Wiredmodul eingebaut.
Würde gerne diese nun mit den RTs peeren und habe dazu auch schon was zu Virtuelle Entities gelesen. Aber ich komme nicht wirklich weiter.
Der Fensterstaus wird wird mit dieser *.cfg realisiert:
define WZ_Fenster_SUED_R DOIF ([HMW_Sen_SC_12_DR_JEQ0545703_01:sensor] == 51200 and [HMW_Sen_SC_12_DR_JEQ0545703_02:sensor] == 0) DOELSEIF ([HMW_Sen_SC_12_DR_JEQ0545703_01:sensor] == 0 and [HMW_Sen_SC_12_DR_JEQ0545703_02:sensor] == 51200) DOELSEIF ([HMW_Sen_SC_12_DR_JEQ0545703_01:sensor] == 51200 and [HMW_Sen_SC_12_DR_JEQ0545703_02:sensor] == 51200)
attr WZ_Fenster_SUED_R alias SÜD R
attr WZ_Fenster_SUED_R cmdState zu|gekippt|offen
attr WZ_Fenster_SUED_R devStateIcon zu:fts_window_1w offen:fts_window_1w_open@red gekippt:fts_window_1w_tilt@red
attr WZ_Fenster_SUED_R group Fenster
attr WZ_Fenster_SUED_R icon fts_door_right
attr WZ_Fenster_SUED_R room Wohnzimmer
Hallo holzwurm83
Vielleicht hilft Dir das etwas weiter
define Fensteroffen_Forian DOIF ([Fenster_Florian] eq "open") (set ThermostatFlorian_Clima controlManu off) DOELSEIF ([Fenster_Florian] eq "closed")(set ThermostatFlorian_Clima controlManu 18)
Fenster_Florian ist ein Funk-Tür-/Fensterkontakt, optisch und der Rest sollte/könnte selbsterklärend sein.
Beides ist nur an Fhem angelernt. Vielleicht hift es Dir weiter.
CK
Hallo le66ck,
Danke für dein Feedback. Ich würde das gerne so umsetzen, das man den Kanal für die Fensterkontakte am RT ansteuert. Das sollte doch auch gehen?
Zitat von: le66ck am 16 November 2014, 16:45:24
Hallo michi1983
Wahrscheinlich, sicher besser....!
Siehe hier http://forum.fhem.de/index.php/topic,25527.0.html (http://forum.fhem.de/index.php/topic,25527.0.html)
CK
Danke!
Hallo le66ck,
Danke für dein Feedback. Ich würde das gerne so umsetzen, das man den Kanal für die Fensterkontakte am RT ansteuert. Das sollte doch auch gehen?
Hallo holzwurm83
ZitatIch würde das gerne so umsetzen, das man den Kanal für die Fensterkontakte am RT ansteuert. Das sollte doch auch gehen?
Wenn Du direkt peeren meinst, also ohne Fhem (hört nur mit), ja!?
Fhem-Befehl dazu habe ich gerade nicht vorrätig...
CK
Ich habe einen HM-CC-RT-DN. Dazu ein virtuelles HM-Thermometer, welches seine Temperatur direkt von einem realen Thermometer erhält. Der Kanal Clima des Heizkörperthermostats ist mit diesem virtuellen HomeMatic Device gepeert. Dazu habe ich folgenden Befehl in der FHEM Kommandozeile ausgeführt:
set Temp_Esszimmer_Weather peerChan 0 HZ_Esszimmer_Weather single set
Auch habe ich es mit folgendem Befehl getestet, bin mir aber über dessen Bedeutung im Vergleich zum vorherigen nicht sicher:
set Temp_Esszimmer_Weather peerChan 0 HZ_Esszimmer_Weather single
In unregelmäßigen Abständen zeigt der Kanal Clima jedoch Temperaturen an, die von der Temperatur des virtuellen Homematic Devices abweichen. Die abweichenden Temperaturen sind allgemein höher als die Temperatur des virtuellen Devices. Daher gehe ich davon aus, dass der Heizkörperthermostat auf den internen Temperaturfühler umschaltet.
Wie kann ich dieses Verhalten unterbinden? Der HM-CC-RT-DN soll immer die Temperatur des virtuellen Devices als aktuelle Temperatur benutzen.
Hallo Alexander,
Zitat von: Alexander am 19 November 2014, 16:21:52
Wie kann ich dieses Verhalten unterbinden? Der HM-CC-RT-DN soll immer die Temperatur des virtuellen Devices als aktuelle Temperatur benutzen.
Ich habe ähnliche Erfahrungen mit einem 1wire TemperaturSensor, der einen virtuellen HomeMatic Temperatursensor versorgt, gemacht - siehe hier: http://forum.fhem.de/index.php/topic,19686.msg137522.html#msg137522 (http://forum.fhem.de/index.php/topic,19686.msg137522.html#msg137522)
Die gleichen Probleme gibt es auch mit Dirks HM Universalsensor, siehe hier: http://forum.fhem.de/index.php/topic,27980.msg208769.html#msg208769 (http://forum.fhem.de/index.php/topic,27980.msg208769.html#msg208769)
In letzterem Thread hat Martin erklärt, wie das Senden der extern gemessenen Temperatur an den RT-DN funktioniert. Da ist genaues Timing wichtig.
Meine Vermutung ist, daß der Algorithmus zur Berechnung des genauen Sendezeitpunkts manchmal danebenliegt. Die gleiche Formel verwendet Dirk nämlich in seiner Firmware für den Eigenbausensor. Empfängt der RT-DN dann über einige Zeit keinen externen Temperaturwert, schaltet er kurz - bis zum erneuten Empfang des richtigen Temperaturwertes - wieder auf seinen internen Sensor um. Das erzeugt dann die hässlichen Peaks oder Drops, die bei mir außerdem zu wilden Regelsprüngen des RT-DN führen.
Eine Lösung gibt es leider (noch) nicht.
Gruß
Tobias
Hallo Tobias,
vielen Dank für die ausführliche Antwort. Also handelt es sich nicht um eine Fehlfunktion meiner beiden Heizkörperthermostate. Hoffentlich kann das Timing-Problem behoben werden. Ich würde gerne noch die übrigen Heizungen mit dem HM-CC-RT-DN ausstatten.
Momentan habe ich durch die Temperaturänderungen Schwankungen von ca. 1-1.5°C im Raum. Ich werde auch mit einer kleineren Öffnung des Ventils testen, ob es dann besser wird.
Das timing ist mit VDs getestet worden - sollte m.E. immer identisch sein. Ich habe es nicht in Betrieb, habe also keine eigenen Messwerte.
schalte bei deinem virtuellen Aktor einmal loglevel auf 5 und die messages der Aktoren ein. dann logge über einige Zeit.
Hallo Martin, Alexander,
Zitat von: tpm88 am 19 November 2014, 18:34:00
Meine Vermutung ist, daß der Algorithmus zur Berechnung des genauen Sendezeitpunkts manchmal danebenliegt. Die gleiche Formel verwendet Dirk nämlich in seiner Firmware für den Eigenbausensor. Empfängt der RT-DN dann über einige Zeit keinen externen Temperaturwert, schaltet er kurz - bis zum erneuten Empfang des richtigen Temperaturwertes - wieder auf seinen internen Sensor um. Das erzeugt dann die hässlichen Peaks oder Drops, die bei mir außerdem zu wilden Regelsprüngen des RT-DN führen.
Eine Lösung gibt es leider (noch) nicht.
Ich muß meine Vermutung revidieren. Ich habe gestern meinen virtuellen Temperatursensor reaktiviert und jetzt 24h mitgeloggt. Resultat - KEIN EINZIGER Aussetzer!!
Seit meinen letzten Tests damit im letzten Winter & Frühjar hat sich natürlich einiges am Code getan. Zusätzlich habe ich mein FHEM auf einen schnelleren CubieTruck umgezogen. Offenbar hat damals etwas anderes ab und an das Timing verhunzt.
Ich werde jetzt noch weitere 24h verbose5 und raw packets mitloggen. Wenn das aber so stabil bleibt, bin ich schlicht begeistert.
Tobias
Hallo zusammen,
rein Interessehalber - kommt man eigentlich noch an die realen Messwerte, wenn der Clima-Kanal gepeert ist?
Grüße
Phel
Zitat von: phel am 27 November 2014, 01:33:11
rein Interessehalber - kommt man eigentlich noch an die realen Messwerte, wenn der Clima-Kanal gepeert ist?
Definiere "reale Messwerte". Wenn Du die vom Thermostat intern gemessenen meinst, dann Nein.
Gruß
Tobias
Hallo Alexander,
was muss man tun um ein virtuelles HM-Device zu erstellen, dass mit einem realen HM-Device gepeert werden kann??
Also wie bist du vorgegangen?
Hattest du eine Vorlage (vorhandenes Device) die du angepasst hast?
Oder von scratch?
Ich würde gerne ein virtuelles Heizkörperthermostat mit einem realen Wandthermostat peeren um bestimmte Werte zu bekommen.
Direktes auslesen aus dem Wandthermostat geht (bei mir) zumindest nicht.
Konkret:
wenn ich beim Wandthermostat den party Modus einstelle werden/würden die Werte (partyStart usw.) an einen gepeerten Heizkörperthermostaten übertragen, intern in den Readings des Wandthermostaten (wo die Einstellungen vorgenommen wurden) gibt es aber keine Werte bzgl. partyStart etc.
Diese gibt es nur, wenn sie einmal per "set Device partyMode Temp partyStart ..." gesetzt wurden, welche sich aber egal was ich per Hand einstelle danach nicht mehr ändern.
Aber die per Hand eingestellten Werte werden an einen gepeerten Heizungsthermostaten gesendet, dort könnte ich sie dann ja auslesen (also aus dem virtuellen Device).
Danke, Joachim
Hallo zusammen,
ich habe mehrere Thermostate dieser Art im Einsatz, zur Zeit noch im Manuel-Modus. Zum Testen hab ich bei einem ein TemperaturTemplate eingespielt und funktioniert.
Meine Frage dazu: Wenn das Thermostat im Automodus läuft lässt sich das Thermostat nicht auf off stellen, es bleibt bei 5 Grad stehen. Ist das normal oder muss ich irgendwas zusätzlich einstellen?
Danke.
Zitat von: skuggy am 22 Oktober 2015, 07:17:29
Meine Frage dazu: Wenn das Thermostat im Automodus läuft lässt sich das Thermostat nicht auf off stellen, es bleibt bei 5 Grad stehen. Ist das normal oder muss ich irgendwas zusätzlich einstellen
Scheint normal zu sein, ist bei mir genauso.
"Off" geht nur über Webfrontend oder durch setzen der Templist auf 0 Grad.
setz es im atuomode einfach auf 4.5 °C über webif oder templiste ( 4.5 = off). am rt gehts nicht
ich möchte verhindern, dass mein Ventil zw.40 und 60% geöffnet wird, weil da die Heizung ein lautes Geräusch macht. Kann ich irgendwo einstellen, dass es entweder drunter oder drüber bleiben soll? Wäre der boost Modus eine alternative? Wie könnte das notify fair aussehen?
du kannst nur die valveMaxPos festlegen (wie weit wird das ventil max geöffnet). bei dir wäre das dann 39%.
und du kannst boostPos festlegen (öffnung beim boost), standard 80% sollte also kein krach machen.
ob nun die valveMaxPos von 39 verhindern würde das beim boost auf 80 geöffnet wird kann ich dir leider nicht sagen. wenn dem so ist und boost dann auch nur auf 39 geht kannst du die boostPeriod verlängern
notify brauchst du dafür garnicht, das stelts du am rt selbst über regset ein
du kannst auch immer die solltemp auf 30°C stellen wenn du heizt, dann sollte er das ventil auf die valveMaxPos aufreißen (100% wenn du nichts änderst). das wäre dann was wo du mit notify / doif arbeiten müsstest umd di soltemp wieder auf einen wert zu bringen wo er zu macht wenn die ist-temp deinem wusch eintspricht.
heizung mal entlüftet wenn sie so einen krach macht? evtl. ist es einfacher das geräusch zu entfernen ;-)
Hallo
Ja valveMaxPos begrenzt auch den Boost.
Ich habe mit dem ValveMaxPos meinen Hydraulichen Abgleich der Heizung realisiert.
Die meisten meiner Heizungen sind auf Ca 40-50% begrenzt Versuch doch ob dein Raum auch mit 40 % auch warm wird wenn nicht ist evtl auch der Heizkörper unterdimensioniert.
Gruß Josty
Danke, ich werde mein Glück versuchen....
Zitat von: JoeALLb am 13 November 2015, 22:35:12
ich möchte verhindern, dass mein Ventil zw.40 und 60% geöffnet wird, weil da die Heizung ein lautes Geräusch macht.
So etwas hatte ich auch mal, da waren Vorlauf und Rücklauf vertauscht. Dadurch gehen auf Dauer wahrscheinlich sogar die Ventile kaputt.
Kannst Du das ausschließen?
Gruß,
Thorsten
Noch eine Frage: Kann ich verhindern, dass über den Funk änderungen geschickt werden, wenn der Aktor diesen Wert schon hat?
Beispielsweise möchte ich
set HM-CC-RT-DN_Clima controlMode auto nocht nochmal per funk senden, wenn dieser schon auf auto steht. Mein Funk ist manchmal schon so überlastet.
Ich möchte auch gerne vermeiden, dass ich jedesmal dazu ein für mich komplexes IF schreiben muss... gibt es dafür eine allgemeingültige Möglichkeit/Funktion?
Meine Thermostate werden manchmal komplett über die Anwesenheitserkennung verändert.
Du kannst doch die FILTER Option verwenden.
Zitat von: stromer-12 am 17 Dezember 2015, 18:39:41
Du kannst doch die FILTER Option verwenden.
Ach, so einfach! Danke, genau da dran habe ich nicht gedacht!!
Hallo
das mit dem Filter würde mich auch interresieren wie geht das ?
ich hab ein Notify das alle 10 Heizungsregler um 09:30 auf auto setzt.
hab das so im DEF
*09:30:00 set Heizung_.* controlMode auto
wie kann ich das machen das er es nur bei Thermostaten anwendet ( funkt ) die nicht auf Auto stehen ?
Gruß Josty
Zitat von: jostmario am 18 Dezember 2015, 15:59:59
das mit dem Filter würde mich auch interresieren wie geht das ?
set .*_Clima:FILTER=controlMode!=auto controlMode autoOder mit derner Bezeichnung vermutlich
set .Heizung_.*:FILTER=controlMode!=auto controlMode autoDas ! ist in perl die negierung, != bedeutet also NICHT.
Dazu habe ich aber auch noch eine Frage: Wie matche ich auf einen Zeitstempel?
Folgendes funktioniert nicht! Habs natürlich auch mit " versucht!
list .*_Clima:FILTER=partyEnd=15-12-19 0:30
Du musst das Leerzeichen durch \x20 ersetzen.
Zitat von: stromer-12 am 20 Dezember 2015, 23:34:40
Du musst das Leerzeichen durch \x20 ersetzen.
Vielen Dank, funktioniert auf der Kommandozeile, aber nicht, wenn ich den Wert mit ReadingsVal() auslese und übergebe.
Noch eine Frage: Ich habe in einem Raum 2 HM-CC-RT-DN, einen am Handtuchtrockner, einen am Fenster. Nun würde ich gerne den Handtuchtrocknet zuerst einsetzen(damit die Handtücher auch tatsächlich trocknen) und nur wenn dieser nicht ausreicht, den Fenster-Heizer dazunehmen.
Ich sehe dazu folgende Varianten:
1: Beide mit dem Raumtermostat peeren und beim Handtuchtrockner die "tempOffset" auf +2 setze
2: Die Temperatur des Raumthermostat auf einen Dummy kopieren und dem Fenster HM-CC-RT-DN eine um 1° höhere Raumtemperatur vorgaukeln.
Dann etwa so
my $pe = ReadingsVal($dev,"partyEnd","nA");
my $pes = $pe;
$pes =~ s/ /\\x20/g;
Jetzt hast du in $pe deinen ausgelesenen Wert und in $pes mit ersetzten Leerzeichen.
Hallo,
ich habe folgende Konstellation:
2 RTs als ClimaTeam gepeert mit jeweils einem SCO-Fenstersensor.
Über LightScene sollen beide auf eine bestimmte Solltemperatur gesetzt werden.
Das desired-temp 20.0 geht an beide laut log raus, aber nur einer stellt die Temperatur ein.
Meine Versuche:
beide über structure - Ergebnis das gleiche
mit Verzögerung arbeiten (bis 5 min) - Ergebnis das gleiche
mit notifys von martinp876 (team_temp) - Ergebnis das gleiche
mit burstAccess = 1 - Ergebnis das gleiche
Kann es sein, dass ein RT den Befehl nicht mitbekommt und wie kann ich da Abhilfe schaffen?
Eigentlich dürfte das mit verzögerter Befehlsfolge ja nicht der Fall sein :(
Bei der notify-Variante gibts außerdem das Problem, dass bei wieder geschlossenem Fenster die Temperatur aus 12.0 bleibt, dort hab ich dann die Auswertung des offenen Fensters mit als Bedingung ins notify eingetragen.
Wenn ich die RTs einzeln per Hand setze, funktioniert es wunderbar.
Wer hat Ideen?
Danke !
Das scheint unwahrscheinlich. Logge die messages beider rts. Schicke die Logs und die ids der RTS und zentrale ( hilft beim dekodieren)
Hallo liebe FHEM-Gemeinde! ;D
Nach etlichem Durchforsten in diesem Forum und anderen Quellen mittels Google fühle ich mich gezwungen hier mal einen Beitrag zu erstellen. :-\
Es stellt sich folgende Problematik dar: Mein HM-CC-RT-DN Thermostat lässt sich nicht korrekt pairen und spuckt jedes Mal nach dem Pairing Vorgang den Status "MISSING ACK" raus, obwohl das Thermostat das Pairing immer mit "AC" bestätigt. Ich kann dubioserweise alles aus dem Thermostat auslesen, Commands kann ich aber nicht ausführen.
Folgendes Setup ist vorhanden:
- Raspberr Pi 2 B
- Busware Stackable CC1101 Transceiver mit jeweils einer 3dBi Antenne mit RP-SMA Sockel
- fhem Version 5.7
- Homematic HM-CC-RT-DN mit der Firmware Version 1.4
Soweit, so gut. jetzt habe ich den Pairingprozess gemäß dem Tutorial http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen (http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen) durchgeführt.
- SCC hmId wurde gesetzt.
- set SCC2 hmPairForSec 600
- Ich halte die Boost-Taste auf dem Thermostat für mindestens 3 Sekunden gedrückt
- warte was FHEM macht
Die Channels vom Thermostat werden von FHEM alle erkannt, jedoch bekomme ich ständig ein MISSING ACK wenn ich das Gerät mit dem SCC und FHEM paire. Alle Daten vom Thermostat werden ausgelesen, Befehle werden aber nur ausgeführt wenn ich die Boost-Taste nach bestätigen des Befehls wieder für 3 Sekunden gedrückt halte (Thermostat im Pairing Modus). Ein Log vom List-Command ist in den Dateien zu finden.
Mir ist bekannt dass R-pairCentral auf "set_" noch steht, heißt da lief was mit dem Pairing schief. Jedoch hab ich auch hier schon des Öfteren den Pairingprozess ohne Erfolg nochmals und nochmals probiert.
Jemand vielleicht eine Idee?
ZitatIch kann dubioserweise alles aus dem Thermostat auslesen, Commands kann ich aber nicht ausführen.
das geht schon mal gar nicht. augelesen wird ein device mit set getconfig und das ist ein cmd.
ZitatMir ist bekannt dass R-pairCentral auf "set_" noch steht, heißt da lief was mit dem Pairing schief. Jedoch hab ich auch hier schon des Öfteren den Pairingprozess ohne Erfolg nochmals und nochmals probiert.
Jemand vielleicht eine Idee?
sniffe das pairen, wie im wiki homematic sniffen.
da ist garnichts ausgelesen.
beachte, dass der Stackable voraussichtlich das Timing von HM nicht korrekt abarbeitet. für CUL haben wir (leider) einen Zweig aufgemacht, damit wir timing sicherstellen können. bei Stackable gibt es vorausichtlich noch nichts.
nach dem loggen wissen wir mehr
Zitatdas geht schon mal gar nicht. augelesen wird ein device mit set getconfig und das ist ein cmd.
Das dachte ich mir schon halber, ergibt selbstverständlich auch Sinn. Mit Commands meinte ich "set"-Commands wie bspw desired-temp o.Ä., bei denen man ja dann eigentlich am Thermostat mitverfolgen kann ob sich was geändert hat. Gelöst habe ich dieses Problem mit der Variable burstAccess: Nachdem ich diese auf 01_auto gestellt habe, lief alles einwandfrei. Dennoch ist die R-PairCentral gem. Wiki noch nicht richtig gesetzt. Da stellen sich von meiner Seite aus die Fragen: Kann das mit der hmid zusammenhängen? wird die hmid (Variable in CULs/SCCs) überhaupt von den SCCs benötigt? oder ist das nur relevant für den HM-CFG-Adapter?
Zitatsniffe das pairen, wie im wiki homematic sniffen.
Anbei wieder die list_Thermostat-Datei, dieses Mal mit dem Reiter cmdStack (die X's sind jeweils die hmid und Internal DEF)
Außerdem ein Auszug aus der Log:
2016.04.11 17:19:06.019 4: CUL_Parse: SCC2 A 0F 11 8610 XXXXXX 000000 0A50F610004021 -57.5
2016.04.11 17:21:41.022 4: CUL_Parse: SCC2 A 0F 12 8610 XXXXXX 000000 0A50F61000401C -60
2016.04.11 17:24:01.524 4: CUL_Parse: SCC2 A 0F 13 8610 XXXXXX 000000 0A50F71000401D -59.5
2016.04.11 17:26:07.526 4: CUL_Parse: SCC2 A 0F 14 8610 XXXXXX 000000 0A50F710004027 -54.5
2016.04.11 17:29:03.279 4: CUL_Parse: SCC2 A 0F 15 8610 XXXXXX 000000 0A50F710004021 -57.5
2016.04.11 17:31:44.532 4: CUL_Parse: SCC2 A 0F 16 8610 XXXXXX 000000 0A50F71000401E -59
2016.04.11 17:34:11.284 4: CUL_Parse: SCC2 A 0F 17 8610 XXXXXX 000000 0A50F610004029 -53.5
2016.04.11 17:36:23.537 4: CUL_Parse: SCC2 A 0F 18 8610 XXXXXX 000000 0A50F610004024 -56
2016.04.11 17:38:11.213 4: CUL_Parse: SCC2 A 0A 19 8002 XXXXXX 123456 001E -59
2016.04.11 17:38:11.414 4: CUL_Parse: SCC2 A 0F 1A 8002 XXXXXX 123456 01041C10384023 -56.5
2016.04.11 17:38:11.618 4: CUL_Parse: SCC2 A 0F 1B 8002 XXXXXX 123456 01041C00384021 -57.5
2016.04.11 17:39:07.477 4: CUL_Parse: SCC2 A 0A 1C 8002 XXXXXX 123456 0024 -56
2016.04.11 17:39:07.679 4: CUL_Parse: SCC2 A 0F 1D 8002 XXXXXX 123456 01041420374022 -57
2016.04.11 17:39:07.881 4: CUL_Parse: SCC2 A 0F 1E 8002 XXXXXX 123456 01041400384021 -57.5
2016.04.11 17:39:25.540 4: CUL_Parse: SCC2 A 0F 19 8610 XXXXXX 000000 0A50F61000402A -53
2016.04.11 17:42:13.042 4: CUL_Parse: SCC2 A 0F 1A 8610 XXXXXX 000000 0A50F510004029 -53.5
2016.04.11 17:44:46.045 4: CUL_Parse: SCC2 A 0F 1B 8610 XXXXXX 000000 0A50F41000401D -59.5
2016.04.11 17:47:04.797 4: CUL_Parse: SCC2 A 0F 1C 8610 XXXXXX 000000 0A50F410004022 -57XXXXXX entspricht dem Internal DEF vom Thermostat.
Danke schonmal soweit für die Hilfe! Ein Problem wäre ja schonmal gelöst :)
LG Thomas
das manipulieren der id's bringt, ausser viel arbeit, nichts.
ausserdem fehlen im log die messages der zentrale und eine anlernmessage des thermostaten gibt es auch nicht. so wird das nichts.
ZitatDennoch ist die R-PairCentral gem. Wiki noch nicht richtig gesetzt.
mach getconfig.
@TommyElroy
das setzen von burst führt dazu, dass du "sofort" am Thermostat die Wertänderung "siehst", habe das auch für einige Thermostate gemacht (damit meine Freundin immer gleich die gewünschte Reaktion mitbekommt)...
...allerdings braucht der Thermostat dann mehr Batterie (weil er sofort aufwacht).
Ansonsten wird der Befehl von FHEM rausgeschickt, sobald sich der Thermostat "freiwillig" meldet...
...kann halt bis zu 3min dauern...
Wenn das nicht stört, dann wg. Batterieverbrauch evtl. wieder zurück stellen...
Ich musste (aus diesem Grund?) bei getConfig den "Anlernknopf" öfter mal drücken, damit die Kommandos (getConfig -> cmds-pending) abgearbeitet wurden...
...vielleicht hilft das...
Eigentlich muss man anlernen nicht druecken. Falls es viele Kommandos sind kann es vorkommen, dass abgebrochen wird. Dann geht es in der nächsten Sequenz weiter. Anlernen startet auch die Sequenz, gleiches Ergebnis, nur schneller.
Typisch ist 3min keine Zeit. Natürlich nutze ich auch burst, wenn ich konfiguriere und vorwärts kommen will. Das sind aber Ausnahmen.
ZitatAnlernen startet auch die Sequenz, gleiches Ergebnis, nur schneller.
Genau das meinte ich ;-)
Also nicht "muss" aber wenn ich neue Heizkörperthermostate (und Fensterkontakte) anlerne mache ich es meist so, dann geht (gefühlt) getConfig etc. schneller...
Anlernen ist ein Sonderfall. Je nach Device (nicht konsequent von eQ3) reagiert ein ungepairtes Device nicht auf pairen ohne den Tastendruck. Erst nach dem Pairen ist die CCU (also FHEM) immer ermächtigt zu kommunizieren. Ohne pairen nur manchmal. Dann geht auch Pairen nicht.
Hallo,
ich kann den HM-CC-RT-DN nicht mit meinen Android (5.0) Smartphone regeln.
Mit dem PC kein Problem da habe ich ein Pulldown-Menü, wähle die gewünschte Temp und schon geht es (siehe Bilder).
Beim Smartphone fehlt mir das Pulldown-Menü leider.
Deswegen habe ich den Slider von @jon_realdesign eingebaut, ohne Erfolg, ich kann da einstellen was ich will egal ob am PC oder am Smartphone den HM-CC-RT-DN beeindruckt das nicht.
Gruß
betaxax
Zitat von: jon_realdesign am 09 Februar 2014, 14:09:59
@Reiner
Sorry für die späte Antwort, anbei mein Code. Wichtig ist vorher am Thermostat (bei mir "AZ_Heizung") das Event beim Empfang einer neuen Solltemperatur zu aktivieren. Das geht hiermit:
define AZ_Heizung ...
attr AZ_Heizung room Arbeitszimmer
...
attr AZ_Heizung event-on-change-reading desired-temp
Dann habe ich mir folgendes Dummy-Objekt "AZ_SollTemperatur" angelegt:
# Slider Solltemperatur (Advanced)
# Dieser sendet keine gleichen Werte und das Thermostat und
# beruecksichtigt auch eine mauelle Verstellung am Thermostat.
define AZ_SollTemperatur dummy
attr AZ_SollTemperatur group 3.SollTemperatur
attr AZ_SollTemperatur icon temp_temperature
attr AZ_SollTemperatur room Arbeitszimmer
attr AZ_SollTemperatur setList state:slider,15,1,25
attr AZ_SollTemperatur webCmd state
#SollTemperaturOnChange
define AZ_SollTemperaturOnChange notify (AZ_SollTemperatur|global:INITIALIZED|global:REREADCFG) { if (ReadingsVal("AZ_Heizung","desired-temp",17) != %) { fhem "set AZ_Heizung_ClimRT desired-temp %" } }
#SollTemperatur_OnExternalChange
define AZ_SollTemperatur_OnExternalChange notify AZ_Heizung:desired-temp.* set AZ_SollTemperatur $EVTPART1
Damit sollte schon alles laufen!
Viel Spass!
Hallo, kleine Vereinfachung:
Ich würde diese IF-Abfrage
define AZ_SollTemperaturOnChange notify (AZ_SollTemperatur|global:INITIALIZED|global:REREADCFG) { if (ReadingsVal("AZ_Heizung","desired-temp",17) != %) { fhem "set AZ_Heizung_ClimRT desired-temp %" } }
durch einen solchen Filter ersetzen... lässt sich schöner lesen, und der Device muss nur 1x angegeben werden. Die Funktion ist die selbe.
define AZ_SollTemperaturOnChange notify (AZ_SollTemperatur|global:INITIALIZED|global:REREADCFG) { fhem "set AZ_Heizung_ClimRT:FILTER=desired-temp!=% desired-temp %" }
Hinweis 2: ClimRT heist jetzt meist Clima.
Hallo zusammen,
ich nutze ein DOIF zusammen mit einem Dummy um Temperaturänderungen an meiner Steuerung an die Thermostate zu übertragen:
Internals:
DEF ([FL_Steuerung:desired-temp] != [FL_Steuerung_desiredTemp_dummy:state])
(set FL_Steuerung_desiredTemp_dummy [FL_Steuerung:desired-temp],
set AZ_Heizung_Clima desired-temp [FL_Steuerung_desiredTemp_dummy:state],
set KZ_Heizung_Clima desired-temp [FL_Steuerung_desiredTemp_dummy:state],
set SZ_Heizung_Clima desired-temp [FL_Steuerung_desiredTemp_dummy:state])
NAME FL_Steuerung_desiredTemp_di
NR 94
NTFY_ORDER 50-FL_Steuerung_desiredTemp_di
STATE cmd_1
TYPE DOIF
Readings:
2016-11-27 09:15:16 Device FL_Steuerung
2016-11-27 09:15:15 cmd 1
2016-11-27 09:15:15 cmd_event FL_Steuerung
2016-11-27 09:15:15 cmd_nr 1
2016-11-27 09:15:16 e_FL_Steuerung_desired-temp 20.0
2016-11-26 21:01:47 mode enable
2016-11-27 09:15:15 state cmd_1
Condition:
0 ReadingValDoIf($hash,'FL_Steuerung','desired-temp','','',AttrVal($hash->{NAME},'notexist',undef)) != ReadingValDoIf($hash,'FL_Steuerung_desiredTemp_dummy','state','','',AttrVal($hash->{NAME},'notexist',undef))
Devices:
0 FL_Steuerung FL_Steuerung_desiredTemp_dummy
all FL_Steuerung FL_Steuerung_desiredTemp_dummy
Do:
0:
0 set FL_Steuerung_desiredTemp_dummy [FL_Steuerung:desired-temp], set AZ_Heizung_Clima desired-temp [FL_Steuerung_desiredTemp_dummy:state], set KZ_Heizung_Clima desired-temp [FL_Steuerung_desiredTemp_dummy:state], set SZ_Heizung_Clima desired-temp [FL_Steuerung_desiredTemp_dummy:state]
1:
Helper:
event CMDs_done
globalinit 1
last_timer 0
sleeptimer -1
timerdev FL_Steuerung
timerevent desired-temp: 20.0
triggerDev FL_Steuerung
timerevents:
desired-temp: 20.0
timereventsState:
desired-temp: 20.0
triggerEvents:
CMDs_done
triggerEventsState:
state: CMDs_done
Internals:
Itimer:
Readings:
0 FL_Steuerung:desired-temp FL_Steuerung_desiredTemp_dummy:state
all FL_Steuerung:desired-temp FL_Steuerung_desiredTemp_dummy:state
Regexp:
0:
All:
State:
Trigger:
Attributes:
disable 0
do always
Das funktioniert soweit gut.
Wie könnte ich nun noch die andere Richtung realisieren? Also: es dreht jemand manuell an den Thermostaten und dann soll auch die Fl_Steuerung die desired-temp auf den Wert selten. Ich hatte dies gestern mit einem zweiten dummy und einem zweiten DOIF probiert, aber das Ergebnis war ein totales Chaos... Jemand Ideen?
Gruß desmo
Nachdem mein Raspi nach einem Neustart keine richtige Zeit bekommen hat stimmt die Zeit meiner Thermostate nicht mehr. Mittlerweile haben ein paar die Richtige, ein paar eine Falsche. Mit welchem Befehl kann ich die Zeit an die Thermostate senden? Interessehalber, wann wird automatisch synchronisiert?
Moin,
mit set device systime, erklärt sich aber durch aufklappen des Set - Menü selbst ;-)
Grüße
Achim
Gesendet von meinem SM-P605 mit Tapatalk
Danke. Ja, da hätte man selbst drauf kommen können...
Hallo
Ich habe eine Frage zu meinem HM-CC-RT-DN und HM-TC-IT-WM-W-EU
Ich habe das Wandthermostat mit dem Heizungsventil über fehm verbunden und über den befehl :
setWandthermostat_Climate tempList Mon 06:00 17.0 09:00 16.0 12:00 15.5 14:00 16.0 16:30 21.0 22:00 19.0 22:30 16.0 24:00 16.0 eingegeben (bei beiden devices und get Configgemacht) .das ganze für die ganze Woche.
Reicht es wenn ich danach "set controlMode day" mache
Oft funktioniert das ganze nähmlich leider nicht
Im Bad habe ich nur ein HM-CC-RT-DN wo ich das gleiche eingetragen habe und auch da funktioniert es nicht wirklich zufriedenstellend. Zu verschiedenen Zeiten wird die Temp. einfach angehoben
Gruß
tkaiser(Anfänger)
Zitat von: tkaiser am 04 Januar 2017, 20:09:28Reicht es wenn ich danach "set controlMode day" mache
Ich denke, dass das Teil dann einfach auf die als Tagestemperatur eingestellte Temperatur geht. (Irgendwo gibt's dafür auch ein Register, denke ich.) Was Du willst ist wahrscheinlich "set controlMode auto".
Gruß,
Thorsten
Hallo Thorsten,
Danke erstmal für deine Antwort
Was ich möchte ist das die devices die Tagesprogramme
Abspulen,wenn ich set controlMode day eingebe
In den Readings steht dann auch unter controMode set day.
Nach einer Weile steht da aber wieder auto.
Sollte da dann nicht controlMode day stehen?
Gruß
auch Thorsten
Hi Thorsten (tkaiser),
was controlMode day genau ist weiß ich nicht (steht auch nicht im Manual) aber da es auch ein controlMode night gibt und sowas wie "Tag und Nacht-Temps" glaube ich eher, dass es (kurzzeitig) auf die eingestellte (Register) Tag bzw. Nacht-Temperatur eingestellt wird.
Was du willst ist definitiv: controlMode auto!
Mit controlMode auto wird abgearbeitet, was in den Templisten steht.
Allerdings hast du sehr eigenartige Temperaturwerte:
06:00 17.0 09:00 16.0 12:00 15.5 14:00 16.0 16:30 21.0 22:00 19.0 22:30 16.0 24:00 16.0
00:00 bis 06:00 17.0
06:00 bis 09:00 16.0
09:00 bis 12:00 15.5
12:00 bis 14:00 16.0
14:00 bis 16:30 21.0
16:30 bis 22:00 19.0
22:00 bis 22:30 16.0
22:30 bis 24:00 16.0
Gruß, Joachim
Hallo Joachim,
Ich hatte das mit den tempListen falsch verstanden
Ich habe gestern nich neue tempLisgen erstellt und eingegeben und heute lief das Programm so ab wie
Ich sie eingehen habe bei set contolMode auto
Danke für deine Hilfe
Gruß
Thorsten
Hi Thorsten,
bitte gerne!
Viel Spaß! Joachim
Hallo! :)
Ich probiere gerade per FHEM und CCU2 ein Heizungsthermostat HM-CC-RT-DN anzusprechen.
Folgendes funktioniert:
define HM_HM_CC_RT_DN_NEQ1011241 HMCCUDEV NEQ1011241
attr HM_HM_CC_RT_DN_NEQ1011241 IODev HMLAN1
attr HM_HM_CC_RT_DN_NEQ1011241 alias Bad_Thermostat
attr HM_HM_CC_RT_DN_NEQ1011241 ccureadingfilter (^UNREACH|LOWBAT|TEMPERATURE|VALVE_STATE|CONTROL)
attr HM_HM_CC_RT_DN_NEQ1011241 ccureadingformat datapoint
attr HM_HM_CC_RT_DN_NEQ1011241 cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr HM_HM_CC_RT_DN_NEQ1011241 controldatapoint 4.SET_TEMPERATURE
attr HM_HM_CC_RT_DN_NEQ1011241 event-on-change-reading .*
attr HM_HM_CC_RT_DN_NEQ1011241 eventMap /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
attr HM_HM_CC_RT_DN_NEQ1011241 group Raumklima
attr HM_HM_CC_RT_DN_NEQ1011241 room Wohnzimmer
attr HM_HM_CC_RT_DN_NEQ1011241 stateFormat Temperatur: 4.ACTUAL_TEMPERATURE°C\
Batterie: 4.BATTERY_STATE[V]\
Ventil: 4.VALVE_STATE%
attr HM_HM_CC_RT_DN_NEQ1011241 statedatapoint 4.SET_TEMPERATURE
attr HM_HM_CC_RT_DN_NEQ1011241 stripnumber 1
attr HM_HM_CC_RT_DN_NEQ1011241 substexcl control
attr HM_HM_CC_RT_DN_NEQ1011241 substitute UNREACH,LOWBAT!(0|false):no,(1|true):yes;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
attr HM_HM_CC_RT_DN_NEQ1011241 webCmd control:Auto:Manu:Boost:on:off
attr HM_HM_CC_RT_DN_NEQ1011241 widgetOverride control:slider,3.5,0.5,30.5,1
Daraus ergibt sich die folgende Darstellung Heizung1.JPG. So weit läuft das alles bestens, das Thermostat reagiert auf alle Befehle.
Ich würde jedoch gerne meine Darstellung wie in Heizung2.JPG zum Laufen kriegen. Der Code dafür sieht momentan wie unten eingefügt aus, funktioniert aber NICHT. Das Auslesen funktioniert ohne Probleme, das Setzen jedoch nicht. Ich habe mich an den Beispielen aus https://wiki.fhem.de/wiki/ReadingsGroup#Heizungsteuerung_f.C3.BCr_HM_Wand-_und_Heizk.C3.B6rperthermostate orientiert. Mein Problem bezieht sich dabei auf das attr commands. Es funktioniert z.B. set %DEVICE datapoint 4.SET_TEMPERATURE 22.0 ohne Probleme, als "Button" steht dann sollsetz in der Darstellung. Ich hätte aber gerne eine Dropdown-List, mit der ich mich aber sehr schwer tue :-[ In der Art wie ich es jetzt versucht habe (s. unten), erhalte ich die Meldung invalid datapoint. Kann mir bitte jemand damit auf die Sprünge helfen? :-/
define HeizungRg readingsGroup <%sani_heating@D4BA90>,<>,<Soll neu>,<>,<Ist>,<>,<Ventil>,<>,<Modus>,<>,<Batterie>,<>,<Boost>,<>,<Auto On>,<>,<Manu On>\
HM_HM_CC_RT_DN_NEQ1011241:<>,<sollsetz>,<>,4.ACTUAL_TEMPERATURE,<>,4.VALVE_STATE,<>,controlMode,<>,<{if(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"%4.BATTERY_STATE","0")>=3.0){"%measure_battery_100\@green"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"%4.BATTERY_STATE","0")>=2.7){"%measure_battery_75\@green"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"%4.BATTERY_STATE","0")>=2.5){"%measure_battery_50\@orange"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"%4.BATTERY_STATE","0")>=2.2){"%measure_battery_25\@orange"}else{"%measure_battery_0\@red"}}>,<>,<%sani_heating_boost>,<>,<%sani_heating_automatic>,<>,<%sani_heating_manual>\
HM_HM_CC_RT_DN_NEQ1005861:,<>,desired-temp,<>,measured-temp,<>,ValvePosition,<>,controlMode,<>,<{if(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"batteryLevel","0")>=3.0){"%measure_battery_100\@green"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"batteryLevel","0")>=2.7){"%measure_battery_75\@green"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"batteryLevel","0")>=2.5){"%measure_battery_50\@orange"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"batteryLevel","0")>=2.2){"%measure_battery_25\@orange"}else{"%measure_battery_0\@red"}}>,<>,<%sani_heating_boost>,<>,<%sani_heating_automatic>,<>,<%sani_heating_manual>
attr HeizungRg commands {'HeizungRg.sollsetz'=>'set %DEVICE datapoint 4.SET_TEMPERATURE:off,5.0,7.0,20.0,22.0,23.0',"HeizungRg.sani_heating_boost"=>"set %DEVICE controlMode boost","HeizungRg.sani_heating_automatic"=>"set %DEVICE controlMode auto","HeizungRg.sani_heating_manual"=>"set %DEVICE controlMode manu"}
attr HeizungRg group Raumklima
attr HeizungRg nameStyle style="text-align:left;;"
attr HeizungRg nolinks 1
attr HeizungRg room Wohnzimmer
attr HeizungRg valueFormat {if(($READING eq "4.ACTUAL_TEMPERATURE")or( $READING eq "4.SET_TEMPERATURE") ){ "$VALUE °C"}elsif(($READING eq "4.VALVE_STATE")){"$VALUE %"}}
attr HeizungRg valueIcon {'controlMode.manual' => 'sani_heating_manual','controlMode.auto' => 'sani_heating_automatic','ValvePosition.0' => 'sani_heating@blue','ValvePosition.1' => 'sani_heating@red'}
Lässt sich dabei nichts machen? :-/ Die Solltemperatur muss doch nach wie vor auch in der Readingsgroup einstellbar sein, auch wenn es scheinbar den Eintrag desired-temp nun unter diesem Namen nicht mehr gibt. Oder?
Die Umschaltung zwischen Auto Manu Boost läuft inzwischen. Folgender Code dafür:
DEF:
<%sani_heating@D4BA90>,<>,<Soll>,<>,<Soll neu>,<>,<Ist>,<>,<Ventil>,<>,<Modus>,<>,<Batterie>,<>,<Boost>,<>,<Auto On>,<>,<Manu On>,<>,<An>,<>,<Aus>
HM_HM_CC_RT_DN_NEQ1011241:<>,4.SET_TEMPERATURE,<>,<sollsetz>,<>,4.ACTUAL_TEMPERATURE,<>,4.VALVE_STATE,<>,<%sani_heating@D4BA90>,<>,<{if(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"ubatterie","0")>=3.0){"%measure_battery_100"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"ubatterie","0")>=2.7){"%measure_battery_75"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"ubatterie","0")>=2.5){"%measure_battery_50"}elsif(ReadingsVal(substr("$DEVICE",0,length("$DEVICE")-6),"ubatterie","0")>=2.2){"%measure_battery_25"}else{"%measure_battery_25"}}>,<>,<%sani_heating_boost>,<>,<%sani_heating_automatic>,<>,<%sani_heating_manual>,<>,<%general_an>,<>,<%general_aus>
Und folgende Attribute:
commands
{"HeizungRg.sollsetz" => "set %DEVICE 4. SET_TEMPERATURE sollsetz","HeizungRg.sani_heating_boost"=>"set %DEVICE Boost","HeizungRg.sani_heating_automatic"=>"set %DEVICE Auto","HeizungRg.sani_heating_manual"=>"set %DEVICE Manu","HeizungRg.general_an"=>"set %DEVICE on","HeizungRg.general_aus"=>"set %DEVICE off","HeizungRg.ubatterie"=>"get %DEVICE datapoint 4.BATTERY_STATE"}
deleteattr
eventMap
/datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
Jetzt brauche ich aber nach wie vor Hilfe bei dem Setzen der Solltemperatur. Auch die Anzeige des aktuellen Modus sowie der Batteriespannung hab ich noch nicht hinbekommen:-(
Bin für jeden Hinweis dankbar! :-/
@ChHerrm: ein wenig mehr Kontext wäre wohl hilfreich.
Ich kann nur raten:
HM-CC-RT-DN an CCU2 Anbindung dann per HMCCU-Modul??
Hier im Thread geht es zwar prinzipiell um den HM-CC-RT-DN aber wenn ich die Historie so durchschaue eher um direkte Anbindung an fhem also per HM-IODev...
Vielleicht gibt es schneller/bessere Hilfe, wenn du einen neuen Thread aufmachst: "Probleme/Fragen bzgl. HM-CC-RT-DN an CCU2 Anbindung per HMCCU-Modul" oder so...
Weil bei der Konstellation HM-CC-RT-DN an CCU2 und eingebunden per HMCCU-Modul kenne ich mich leider nicht aus...
...evtl./wahrsch. auch kein anderer der "Mitleser"...
Gruß und sorry, Joachim
Denke inzwischen eher, dass es ein Thema zwecks readingsgroup ist. Ich scheitere scheinbar eher daran, sollsetz als dropdown-Menü zu gestalten.
Thematisch ging es um die Einbindung des Thermostats per CCU2 über FHEM per HMCCUDEV.
Trotzdem danke für die Antwort, werde es dann mal woanders versuchen!
Inzwischen habe ich meine Probleme mit dem Thermostat endlich alle gelöst. Für Interessenten, die ggf. mal vor dem selben Problem stehen, hier nochmal meine fertige Lösung auf die ich nun nach vielen Stunden und Versuchen gekommen bin. Im Anhang ein Bild der fertigen readingsgroup.
# Homematic-Konfiguration
define HMLAN1 HMCCU 192.168.0.21
attr HMLAN1 rpcport 2001,9292
attr HMLAN1 rpcserver on
attr HMLAN1 stateFormat rpcstate/state
#attr HMLAN1 rpcinterval 5
#set HMLAN1 rpcserver on
# Schlafzimmer-Thermostat
define HM_HM_CC_RT_DN_NEQ1005861 HMCCUDEV NEQ1005861
attr HM_HM_CC_RT_DN_NEQ1005861 IODev HMLAN1
attr HM_HM_CC_RT_DN_NEQ1005861 alias Schlafzimmer
attr HM_HM_CC_RT_DN_NEQ1005861 ccureadingfilter (^UNREACH|LOWBAT|TEMPERATURE|VALVE_STATE|CONTROL|BATTERY_STATE)
attr HM_HM_CC_RT_DN_NEQ1005861 ccureadingformat datapoint
attr HM_HM_CC_RT_DN_NEQ1005861 cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr HM_HM_CC_RT_DN_NEQ1005861 controldatapoint 4.SET_TEMPERATURE
attr HM_HM_CC_RT_DN_NEQ1005861 event-on-change-reading .*
attr HM_HM_CC_RT_DN_NEQ1005861 eventMap /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
attr HM_HM_CC_RT_DN_NEQ1005861 stateFormat Temperatur: 4.ACTUAL_TEMPERATURE°C\
Batterie: 4.BATTERY_STATE[V]\
Ventil: 4.VALVE_STATE%
attr HM_HM_CC_RT_DN_NEQ1005861 statedatapoint 4.SET_TEMPERATURE
attr HM_HM_CC_RT_DN_NEQ1005861 stripnumber 1
attr HM_HM_CC_RT_DN_NEQ1005861 substexcl control
attr HM_HM_CC_RT_DN_NEQ1005861 substitute UNREACH,LOWBAT!(0|false):no,(1|true):yes;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;;SET_TEMPERATURE!#0-3.5:off,#30.5-40:on
attr HM_HM_CC_RT_DN_NEQ1005861 webCmd control:Auto:Manu:Boost:on:off
attr HM_HM_CC_RT_DN_NEQ1005861 widgetOverride control:5.0,17.0,20.0,21.0,22.0
# Readinggroup der Werte
define HeizungRg readingsGroup <%sani_heating@D4BA90>,<Soll>,<Vorgabewert>,<Ist>,<Ventil>,<Modus>,<Batterie>,<Boost>,<Auto>,<Manu>,<An>,<Aus>\
HM_HM_CC_RT_DN_NEQ1011241:4.SET_TEMPERATURE,<sollsetz>,4.ACTUAL_TEMPERATURE,4.VALVE_STATE,4.CONTROL_MODE,4.BATTERY_STATE,<%sani_heating_boost>,<%sani_heating_automatic>,<%sani_heating_manual>,<%general_an>,<%general_aus>\
HM_HM_CC_RT_DN_NEQ1005861:4.SET_TEMPERATURE,<sollsetz>,4.ACTUAL_TEMPERATURE,4.VALVE_STATE,4.CONTROL_MODE,4.BATTERY_STATE,<%sani_heating_boost>,<%sani_heating_automatic>,<%sani_heating_manual>,<%general_an>,<%general_aus>\
HM_HM_CC_RT_DN_NEQ1011150:4.SET_TEMPERATURE,<sollsetz>,4.ACTUAL_TEMPERATURE,4.VALVE_STATE,4.CONTROL_MODE,4.BATTERY_STATE,<%sani_heating_boost>,<%sani_heating_automatic>,<%sani_heating_manual>,<%general_an>,<%general_aus>\
HM_HM_CC_RT_DN_NEQ1011157:4.SET_TEMPERATURE,<sollsetz>,4.ACTUAL_TEMPERATURE,4.VALVE_STATE,4.CONTROL_MODE,4.BATTERY_STATE,<%sani_heating_boost>,<%sani_heating_automatic>,<%sani_heating_manual>,<%general_an>,<%general_aus>
attr HeizungRg alias Heizungsübersicht
attr HeizungRg commands {'HeizungRg.sollsetz' => 'control:17.0,18.0,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,24.0,25.0',"HeizungRg.sani_heating_boost"=>"set %DEVICE Boost","HeizungRg.sani_heating_automatic"=>"set %DEVICE Auto","HeizungRg.sani_heating_manual"=>"set %DEVICE Manu","HeizungRg.general_an"=>"set %DEVICE on","HeizungRg.general_aus"=>"set %DEVICE off"}
attr HeizungRg eventMap /datapoint 4.MANU_MODE 20.0:Manu/datapoint 4.AUTO_MODE 1:Auto/datapoint 4.BOOST_MODE 1:Boost
attr HeizungRg group Raumklima
attr HeizungRg nameStyle style="color:white;;font-weight:bold"
attr HeizungRg room Wohnzimmer
attr HeizungRg sortDevices 1
attr HeizungRg valueFormat {if(($READING eq "4.ACTUAL_TEMPERATURE")or( $READING eq "4.SET_TEMPERATURE") ){ "$VALUE °C"}elsif(($READING eq "4.VALVE_STATE")){"$VALUE %"}}
attr HeizungRg valueIcon {if($READING eq "4.BATTERY_STATE" && $VALUE > 3.0){'measure_battery_100@green'}elsif($READING eq "4.BATTERY_STATE" && $VALUE > 2.8){'measure_battery_75@lightgreen'}elsif($READING eq "4.BATTERY_STATE" && $VALUE > 2.6){'measure_battery_50@yellow'}elsif($READING eq "4.BATTERY_STATE" && $VALUE >= 2.3){'measure_battery_25@orange'}elsif($READING eq "4.BATTERY_STATE" && $VALUE <= 2.2){'measure_battery_0@red'}elsif($READING eq "4.CONTROL_MODE" && $VALUE eq "AUTO"){'sani_heating_automatic@yellow'}elsif($READING eq "4.CONTROL_MODE" && $VALUE eq "MANU"){'sani_heating_manual@yellow'}elsif($READING eq "4.CONTROL_MODE" && $VALUE eq "BOOST"){'sani_heating_boost@red'}}
attr HeizungRg valueStyle {if($READING eq "4.VALVE_STATE" && $VALUE < 10){ 'style="color:blue;;;;font-weight:bold"'}elsif($READING eq "4.VALVE_STATE" && $VALUE >= 80){ 'style="color:red;;;;font-weight:bold"'}elsif($READING eq "4.ACTUAL_TEMPERATURE" && $VALUE < 19){ 'style="color:blue;;;;font-weight:bold"'}elsif($READING eq "4.ACTUAL_TEMPERATURE" && $VALUE >= 22){ 'style="color:red;;;;font-weight:bold"'}elsif($READING eq "4.SET_TEMPERATURE" && $VALUE < 19){ 'style="color:blue;;;;font-weight:bold"'}elsif($READING eq "4.SET_TEMPERATURE" && $VALUE >= 22){ 'style="color:red;;;;font-weight:bold"'}}
Hallo zusammen,
ich habe eine Frage zur Mechanik der Homematic Thermostate.
Diese passen ja auf Heimeier Ventile und werden mit der silbernen Überwurfmutter (bzw. geriffelter Ring) befestigt.
Es geht mir nur um diesen Ring. Geht das Gewinde da drin über die gesamte Breite des Rings? (oder eher "Tiefe"?).
Verweise auf eventuell beiliegendes Adaptermaterial helfen mir nicht. Ich will nur wissen wie der Ring von innen gestaltet ist.
Ein Foto würde auch helfen.
Beste Grüße
Jan
Hi Jan,
hoffe, dass es das ist, was Du brauchst?
LG Jörg