HM-CC-TC Temperatur einstellen

Begonnen von Guest, 20 August 2012, 13:36:06

Vorheriges Thema - Nächstes Thema

Billy

                                                         

@Martin
Bin immer noch am testen,

im Reading eines HM-CC-TT tauchen folgende Fehler?-Meldungen auf

ValveErrorPosition
WZ_EG_HK_li 15 %2012-10-23 14:53:50
ValveOffset
WZ_EG_HK_li 10 %2012-10-23 14:53:50
noReceiver
src:19E3E7 (A001) 010400000000052012-10-23 15:26:01


Kann man die löschen oder verschwinden die wieder alleine?

Billy

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Guest

Originally posted by: <email address deleted>

1) ich denke, die sind nicht 'neu' - oder?
2) READINGS kann man meines Wissens nicht loeschen. Damit meine ich das
User-interface, man muss auf die Kommando-ebene. Hat mich auch schon
gestoert un dich habe keine Loesung fuer mich. Readings verschwinden nie
von alleine und werden gespeichet, sind nach reboot wieder da.
3) das Format ist meines Erachtens nicht korrekt - warum steht hier der
Name drin? Der sollte raus - steht wie bei allen readigns in der
"ueberschrift"

Es handelt sich nicht im Fehlermeldungen sondern um Einstellungen des
Ventils. Mal sortieren: Ausgewertet wird eine gemontorte message in der der
TC dem VD die Einstellungen des Ventils mitteilt. Error-position ist die
Position, die das Ventil einnehmen soll, wenn es ein Problem hat und nicht
mehr gesteuert werden kann - also die Notabschaltung'. Offset ist
warscheinlich eine Rechenwert, ich denke die Nullstellung.

5) die Werte sollten in den Datensatz des VD eingetragen werden - und zwar
mir einer Bemertung, dass sie nicht approved sind - es sind keine gelesenen
sondern Werte sondern der schreibversuch. Also ValveErrorPosition: set_15%.
Wenn der wert aus den Ventil gelesen wird sollte es set_15% zu 15% werden -
dann ist es approved.

6) in FHEM wird nicht zwischen readings und device-settigns unterschieden.
FHEM-interne settings sind attribute. Alles was von device komme sind
readings, ohne weiter Klassifizierung


Frage an den Anwender: Was dagegen, wenn ich es nach VD verschiebe?

Gruss Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hallo,

nun habe ich ein Update durchgeführt und bekomme leider nur noch zu 100%
MISSING ACKS

CUL_HM WZ_Heizung desired-temp 20.5
CUL_HM WZ_Heizung T: 19.3 H: 57
CUL_HM WZ_Heizung measured-temp: 19.3
CUL_HM WZ_Heizung humidity: 57
CUL_HM WZ_Heizung MISSING ACK

Konfiguration: FHEM auf QNAP, HMLAN

Das Update hat bei mir nur die Dateien aktualisiert. Ich habe auch
updatefhem housekeeping aufgerufen, jedoch wurden bei mir keine neuen
Verzeichnisse angelegt. Außerdem wird in der Weboberfläche werden Symbole
beim ausführen von Aktion (wie Z.B. Licht einschalten), ersetzt durch einen
Text z.B set_on. Erst bei einem Reload der Seite steht das korrekte Symbol
zur Verfügung.

Wo liegt das Problem mit der Webdarstellung?
Warum funktioniert update housekeeping nicht?

Danke & Grüße,
Merhan

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hallo,

ich habe auch gerade ein update durchgeführt. Es scheint alles normal zu
laufen jedoch bekomme ich immernoch MISSING-ACK für den HM-CC-TC. Bei mir
hat das noch nie funktioniert:

*2012-10-26 00:26:09 CUL_HM az_Thermostat desired-temp 10.0*
2012-10-26 00:26:23 CUL_HM Vorlauftemperatur T: 26.4 H: 100
2012-10-26 00:26:23 CUL_HM Vorlauftemperatur temperature: 26.4
2012-10-26 00:26:23 CUL_HM Vorlauftemperatur humidity: 100
2012-10-26 00:26:25 CUL_HM sz_Thermostat T: 22.4 H: 60
2012-10-26 00:26:25 CUL_HM sz_Thermostat measured-temp: 22.4
2012-10-26 00:26:25 CUL_HM sz_Thermostat humidity: 60
2012-10-26 00:27:02 CUL_HM az_Thermostat T: 22.9 H: 62
2012-10-26 00:27:02 CUL_HM az_Thermostat measured-temp: 22.9
2012-10-26 00:27:02 CUL_HM az_Thermostat humidity: 62
2012-10-26 00:27:04 CUL_HM wz_Thermostat T: 22.7 H: 60
2012-10-26 00:27:04 CUL_HM wz_Thermostat measured-temp: 22.7
2012-10-26 00:27:04 CUL_HM wz_Thermostat humidity: 60
*2012-10-26 00:27:06 CUL_HM az_Thermostat MISSING ACK*

Zu den Problemen von Merhan kann ich leider nichts beitragen.

Ich verwende den CUL (CUNO) mit FB7390 und bin hier am verzweifeln. Ich
habe mir diesen und viele andere Threads durchgelesen aber es scheint das
Problem ist noch nicht gelöst (?).

@Merhan
Hat das bei dir vor dem update funktioniert?
Gruß,
Christian

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

UliM

                                                 

Webdarstellung: CUL_HM setzt set_on wenn es ein Telegramm absendet, setzt on sobald das ACK eintrifft. Wenn fhemweb vor Eintreffen des ACK mit html-bauen durch ist, wird set_on angezeigt bis zum nächsten refresh. Soweit ich sehe hat (deshalb?) Rudi von Martin angefragt, dass nicht nur on, sondern auch set_on als fhem-Event verfügbar wird. Den Stand dazu kenn ich nicht.

updatefhem housekeeping clean yes - lautet glaub ich der vollständige Befehl, um die Umstellung auf neue Verzeichnisstruktur anzutriggern. Wenn's damit nicht geht, bitte separaten Fred aufmachen - das versandet sonst hier :)

Gruß, Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

Billy

                                                         

Hallo Martin,
danke für die Antwort.

Am Donnerstag, 25. Oktober 2012 13:13:15 UTC+2 schrieb Martin:
>
> 1) ich denke, die sind nicht 'neu' - oder?
>
 
nein, die waren nicht neu

2) READINGS kann man meines Wissens nicht loeschen. Damit meine ich das
> User-interface, man muss auf die Kommando-ebene. Hat mich auch schon
> gestoert un dich habe keine Loesung fuer mich. Readings verschwinden nie
> von alleine und werden gespeichet, sind nach reboot wieder da.
>
 
Ich habe die readings gelöscht, indem ich in der /var/log/fhem/fhem.save
editiert habe, aber das ist nicht wichtig.
 

>
> Frage an den Anwender: Was dagegen, wenn ich es nach VD verschiebe?
>
Nein im Gegenteil!
 
Bei meinem Feintuning ist mir aufgefallen, dass ich beim setzen eines
Offsets im HM-CC-TC für einen Heizkörper HM-CC-VD
im Filelog des HM-CC-TC immer einen Eintrag wie folgt finde?

2012-10-26_14:11:44 EG_WZ noReceiver: src:19E3E7 (A158) 006F
2012-10-26_14:11:44 EG_WZ noReceiver: src:19E3E7 (A001) 010519E3E70105
2012-10-26_14:11:45 EG_WZ noReceiver: src:19E3E7 (A001) 010809140A0F
2012-10-26_14:11:45 EG_WZ noReceiver: src:19E3E7 (A001) 0106

Erwartet hätte ich eigentlich irgendwo einen Eintrag mit dem Offset Wert
des jeweiligen VD's.
Im Einsatz bei mir ist HMLAN mit den neuesten Modulen 00_HMLAN.pm.2018
und 10_CUL_HM.pm.2018

Das setzten der desired temp geht bei mir dank deiner Änderungen jetzt
immer problemlos, wobei ich nur im Manuellen Mode arbeite.

Gruss Billy

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Guest

Originally posted by: <email address deleted>

korrekt Uli,
Bei HM werden eigentich alle Zustaende bestaetigt. damit man sehen kann,
dass eine 'transition" angestossen wurde wird der Status geaendert.
Gesichert ist er erst, wenn das Device bestaetigt, alles andere sind
Vermutungen.
Bei anderen Familien ist dies natuerlich nicht so - da bei einigen kein ACK
kommt muss der 'set' befehl als 'final' angenommen werden. HM kann hier
mehr und zeigt somit auch mehr.

Zum TC:
Wir muessen jetzt 2 Varianten unterscheiden: CUL und HMLAN Betrieb.

1) HMLAN: Funktioniert bei mir und bei anderen gut. Vom update letzte nacht
habe ich noch kaum feedback, in meinem System ging das temp-setzen glatt
(sonst haette ich nicht abgegeben).
Zu beachten ist, das hmProtokollEvents in HMLAN unbegingt auf 0 stehen muss
(oder geloescht). Sonst klappt das timing nicht.

2) Bei CUL habe ich kaum eigene Tests (bis jetzt) - aber user hatten erfolg
gemeldet. Hier hat es keinen Update gegeben, das sollte genauso laufen wie
bisher.

@Billy,
Ich habe jetzt erstmal events bei TC und VD gesetzt. Erscheint mir aber
uebertrieben und ich denke der Normalbetreib ist, Zustaende im Aktor zu
setzen, also hier im VD. Dann werde ich den event aus TC entfernen.

Mal sehen, dass ich die messages dekodieren kann. 19E3E7 ist dein TC?

@kohrti
Kannst du mal logs schicken? mit msec Aufloesung bitte

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

                                                         

@ Martin

@Billy,
> Ich habe jetzt erstmal events bei TC und VD gesetzt. Erscheint mir aber
> uebertrieben und ich denke der Normalbetreib ist, Zustaende im Aktor zu
> setzen, also hier im VD. Dann werde ich den event aus TC entfernen.
>
> Mal sehen, dass ich die messages dekodieren kann. 19E3E7 ist dein TC?
>

Ja  19E3E7 ist mein TC!
Optimal wäre, wenn Der VD Offset z.B. 15% in den VD Readings des jeweiligen
VD eingetragen werden kann.
Der Offset wird ja normalerweise nur selten geändert.

Martin besteht eine Chance die Mode Umschaltung über FHEM zum laufen zu
bringen oder läuft die schon?

Danke Billy

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Guest

Originally posted by: <email address deleted>

Mach ich am Montag. Bin gerade nicht zu Hause.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

sollte alles gehen - hoffe ich. Auch der Mode (party... meintest du?)

>
> Ja  19E3E7 ist mein TC!
> Optimal wäre, wenn Der VD Offset z.B. 15% in den VD Readings des
> jeweiligen VD eingetragen werden kann.
> Der Offset wird ja normalerweise nur selten geändert.
>
> Martin besteht eine Chance die Mode Umschaltung über FHEM zum laufen zu
> bringen oder läuft die schon?
>

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

                                                         

Hallo Martin, anbei erste Testergebnisse nach einchecken von 10_CUL_HM.pm
V2024

1. Mode Umschaltung Manuell / Auto klappt jetzt perfekt! (Die hatte ich
gemeint!)

2. VD Heizkörper File Log zeigt jetzt Offset an --> Super
2012-10-28_10:52:58 EG_WZ_HK_li ValveOffset: changeTo 25%
  Wie bekomme ich den ValveOffset: changeTo 25% in die HK Readings
Übersicht?

3. Die Anzeige  ValvePosition: changeTo muss m.E. nicht ständig gelogt
werden. evtl. nur bei Änderung?
2012-10-28_10:57:55 EG_WZ_HK_li ValvePosition: changeTo 47%

4. Im TC File Log allerdings jetzt bei jedem Temp Log auch der Eintrag
2012-10-28_10:52:57 EG_WZ noReceiver: src:19E3E7 (A158) 0079

Danke für diese Verbesserungen
Billy

Am Sonntag, 28. Oktober 2012 10:56:17 UTC+1 schrieb Martin:
>
> sollte alles gehen - hoffe ich. Auch der Mode (party... meintest du?)
>
>>
>>
>> Gruss
> Martin
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Guest

Originally posted by: <email address deleted>

Bei mir funktioniert seit heute Nacht das Auslesen des actuator-Wertes
nicht mehr:

2012-10-27_23:56:05 CUL_HM_thermostat_19B646 desired-temp 17
2012-10-27_23:56:36 CUL_HM_thermostat_19B646 T: 20.7 H: 59
2012-10-27_23:56:36 CUL_HM_thermostat_19B646 measured-temp: 20.7
2012-10-27_23:56:36 CUL_HM_thermostat_19B646 humidity: 59
2012-10-27_23:56:56 CUL_HM_thermostat_19B646 actuator: 0 %
2012-10-27_23:58:38 CUL_HM_thermostat_19B646 T: 20.7 H: 59
2012-10-27_23:58:38 CUL_HM_thermostat_19B646 measured-temp: 20.7
2012-10-27_23:58:38 CUL_HM_thermostat_19B646 humidity: 59
2012-10-27_23:58:59 CUL_HM_thermostat_19B646 noReceiver: src:19B646 (A258) 0000
2012-10-28_00:04:07 CUL_HM_thermostat_19B646 T: 20.6 H: 59
2012-10-28_00:04:07 CUL_HM_thermostat_19B646 measured-temp: 20.6
2012-10-28_00:04:07 CUL_HM_thermostat_19B646 humidity: 59
2012-10-28_00:04:27 CUL_HM_thermostat_19B646 noReceiver: src:19B646 (A258) 0000


Dazu kommt das Problem, dass sich die Uhrzeit des HM-CC-TC im Modus "central" immer eine Stunde nach geht (ich vermute mal, dass er die Uhrzeit von der Zentrale holt? ...dort ist die Uhrzeit laut "date" allerdings korrekt).

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

                                                         

CUL oder HMLAN?
Welche 10_CUL_HM.pm Version?
Bei mir läuft noch die Anzeige des actuator!

Zum Zeitproblem. Kann es sein, dass FHEM bei dir unter Debian auf einer NAS
läuft?
Ich hatte das Problem auch.

Habe in 10_CUL_HM.pm,  & 00_HMLAN.pm   $t -= 3600;   # HM Special wieder
durch   $t -= 7200;   # HM Special ersetzt.

Gruss Billy

Dazu kommt das Problem, dass sich die Uhrzeit des HM-CC-TC im Modus "central" immer eine Stunde nach geht (ich vermute mal, dass er die Uhrzeit von der Zentrale holt? ...dort ist die Uhrzeit laut "date" allerdings korrekt).
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Guest

Originally posted by: <email address deleted>

Selbes Problem bei mir. ich nutze HM-LAN und diese 10_CUL_HM.pm: 2024
2012-10-27 10:36:44Z martinp876

Am Sonntag, 28. Oktober 2012 18:07:43 UTC+1 schrieb littlebilly:
>
> CUL oder HMLAN?
> Welche 10_CUL_HM.pm Version?
>
>>
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Billy

                                                         

Ihr habt recht, mit der 10_CUL_HM.pm: 2024 geht der actuatur unter TC
nicht! (Dafür im VD aber das hilft bei den Plots nicht)
Lösung, wieder zurück auf 10_CUL_HM.pm.2018!

Und warten bis Martin diese Bugs bereinigt.

Am Sonntag, 28. Oktober 2012 18:23:55 UTC+1 schrieb LarsM:
>
> Selbes Problem bei mir. ich nutze HM-LAN und diese 10_CUL_HM.pm: 2024
> 2012-10-27 10:36:44Z martinp876
>
> Am Sonntag, 28. Oktober 2012 18:07:43 UTC+1 schrieb littlebilly:
>>
>> CUL oder HMLAN?
>> Welche 10_CUL_HM.pm Version?
>>
>>>
>>>
>>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*