HM-CC-RT-DN

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

Vorheriges Thema - Nächstes Thema

locodriver

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.
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

unimatrix

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.

BuRi

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

martinp876


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.




unimatrix

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

martinp876

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

Stefan M.

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

unimatrix

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!

Jojo11

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

locodriver

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
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

CQuadrat

Gibt es eigentlich einen Grund dafür, dass ich den Partymode nur zu halben und ganzen Stunden schalten kann?
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

BuRi

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

BuRi

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

martinp876

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

BuRi

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