HM-CC-RT-DN

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

Vorheriges Thema - Nächstes Thema

Stefan M.

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
FHEM auf 3 x RaspberryPi, 1 x Fritzbox,1 x Win. FS20 über CUL, HomeMatic über HMLan, 6 x  HM_CC_RT_DN,2 x HM_LC_BL1_FM,3 x HM_SEC_KEY,2 x HM_RC_Key4_2,7 x HM_SEC_SC,1 x HM_SEC_WDS,1 x HM_Sen_RD_O, 1x HM_Sen_Wa_Od,2 x HM_RC_Key4_2, 5 x HM-ES-PMSw1-Pl,1 x HM_LC_SW4_WM,1 x HM_SCI_3_FM

rtv

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*

betateilchen

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

strauch

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.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

peterk_de

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

Stefan M.

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
FHEM auf 3 x RaspberryPi, 1 x Fritzbox,1 x Win. FS20 über CUL, HomeMatic über HMLan, 6 x  HM_CC_RT_DN,2 x HM_LC_BL1_FM,3 x HM_SEC_KEY,2 x HM_RC_Key4_2,7 x HM_SEC_SC,1 x HM_SEC_WDS,1 x HM_Sen_RD_O, 1x HM_Sen_Wa_Od,2 x HM_RC_Key4_2, 5 x HM-ES-PMSw1-Pl,1 x HM_LC_SW4_WM,1 x HM_SCI_3_FM

betateilchen

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

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

martinp876

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

betateilchen

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

martinp876

ein log bitte - damit ich sehe, welche message nicht abgearbeitet wird

Stefan M.

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
FHEM auf 3 x RaspberryPi, 1 x Fritzbox,1 x Win. FS20 über CUL, HomeMatic über HMLan, 6 x  HM_CC_RT_DN,2 x HM_LC_BL1_FM,3 x HM_SEC_KEY,2 x HM_RC_Key4_2,7 x HM_SEC_SC,1 x HM_SEC_WDS,1 x HM_Sen_RD_O, 1x HM_Sen_Wa_Od,2 x HM_RC_Key4_2, 5 x HM-ES-PMSw1-Pl,1 x HM_LC_SW4_WM,1 x HM_SCI_3_FM

rtv

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?

martinp876

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

Stefan M.

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
FHEM auf 3 x RaspberryPi, 1 x Fritzbox,1 x Win. FS20 über CUL, HomeMatic über HMLan, 6 x  HM_CC_RT_DN,2 x HM_LC_BL1_FM,3 x HM_SEC_KEY,2 x HM_RC_Key4_2,7 x HM_SEC_SC,1 x HM_SEC_WDS,1 x HM_Sen_RD_O, 1x HM_Sen_Wa_Od,2 x HM_RC_Key4_2, 5 x HM-ES-PMSw1-Pl,1 x HM_LC_SW4_WM,1 x HM_SCI_3_FM

juelich

#449
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