HM-CC-RT-DN

[Otto]

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?

Jedes Gerät macht

Code Auswählen Erweitern

CUL_HM set Steckdose1 getSerial
CUL_HM set Steckdose1 getConfig
CUL_HM set Steckdose1 statusRequest

und ich mach öfter rereadcfg

Liegt es dadran?

[martinp876]

@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

[unimatrix]

Hi martin,

das mit dem reload war mal ein guter Tipp für Doofe wie mich! ;) danke!

VG

[Otto]

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

[BuRi]

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

[betateilchen]

ich kann keinen tempOffset setzen und burst funktioniert auch nicht mehr, obwohl an allen Reglern eingeschaltet - und auch als "on" angezeigt wird.

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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

[JayBee]

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

[betateilchen]

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?

[dusti64]

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

[betateilchen]

Betateilchen 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"

[BuRi]

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

[betateilchen]

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.

[BuRi]

Werde ich mal testen, vielleicht bin ich zu ungeduldig!!??

[martinp876]

@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

[betateilchen]

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

zum 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?

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

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

Ich 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!

So 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!


---