HM-CC-RT-DN

Begonnen von Alex85, 13 September 2013, 11:03:07

Vorheriges Thema - Nächstes Thema

deluxe41

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 !!
Fritzbox 7490 ( USV + Fall Back ), einige HM komponenten,ESPs

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hypnorex

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?

martinp876

das ist eine messung, keine Warnung.
Die Warnung ist battery:low

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hypnorex

Vielen Dank, das war die Ursache.

peterk_de

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 ...
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

martinp876

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

peterk_de

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....
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

peterk_de

OK das Drehen am Stellrad ist es schonmal nicht ... gerade verifiziert ;)
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

peterk_de

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 ;)
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

Jan

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

martinp876

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

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!