HM-CC-RT-DN

[betateilchen]

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)

[juelich]

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:

Code Auswählen Erweitern

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"); } }

Code Auswählen Erweitern

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

[betateilchen]

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.

[wagenrad]

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?

[betateilchen]

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.

[martinp876]

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

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

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.

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

[betateilchen]

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.

martin, versuch einfach mal, als unbedarfter Anfänger zu denken:

ich 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

[wagenrad]

Vielen Dank für die schnelle und gute Erklärung - es hat sofort geklappt!

[Spiff]

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. 

Gruß
Spiff

[martinp876]

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

[jostmario]

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

[martinp876]

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

[strauch]

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.

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?

[jostmario]

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

[strauch]

Ist ein neuerer Prozessor er hat mehr Takt, den Arm v7, statt v6 Befehlssatz inkl NEON.