HM-CC-TC Temperatur einstellen

[Wolf]

Hallo,

ich bin gerade dabei mich in die FHEM Einstellungen zu stürzen. Den HM-CC-TC habe ich mit dem HM-CC-VD verbunden anschließen mit FHEM gepairt (CUL_HM). Das hat auch alles toll geklappt.

Nun wollte ich mit der Steuerung Anfangen (bevor es Kalt wird sollte es funktionieren, sonst gibt's trouble mi der Frau(: ) Wenn es so heiß ist wie jetzt und die Raumtemperatur über den 20Grad liegt dann wird ja auch nichts gesteuert oder???

habe folgenden Befehl geschrieben:

an Wochentagen soll die Heizung, morgens ca. 30min vor dem aufstehen (also 6:15Uhr) auf 20Grad Aufheizen, dann ab 8Uhr wieder etwas runter (ist ja niemand zuhause) und um 15Uhr wieder normal

define ES_Heizung0545 at *05:45 { if (!we) {fhem("set desired 20")}}

define ES_Heizung0800 at *08:00 { if (!we) {fhem("set desired 16")}}

define ES_Heizung1500 at *15:00 { if (!we) {fhem("set desired 20")}}

an Wochenende morgens erst ab 7:30Uhr Aufheizen

define ES_Heizung0730 at *07:30 { if (we) {fhem("set desired 20")}}

Nachtabschaltung ab 22Uhr täglich

define ES_Heizung2200 at *22:00 et desired 16

Dies funktioniert aber glaube ich nicht denn in der Log oder im Plot wird keine Änderung angezeigt!! Wo liegt mein Fehler???

Danke

[PoLe23]

Hallo,

was bekommst du denn für eine Fehlermeldung?

Muss es nicht "desired-temp" heissen??

[Wolf]

Danke für deine Antwort. Stimmt ich habe es auf "desired-temp" geändert und das HMdev hinzugefügt und schon sendet er. 

Allerdings kann ich am Wandthermostat keine veränderung feststellen. Hier steht noch 21Grad statt die gesendeten 20Grad. Bekomme aber keine Fehlermeldung. Konnte zumindestens keine feststellen. 

hier mal die neue Programmierung:

define <Variable> at *<Uhrzeit> { if (!$we) {fhem("set <HMDev> desired-temp 20")}}

z.B.

define ES_Heizung0545 at *05:45 { if (!$we) {fhem("set ES_Wandthermostat desired-temp 20")}}
bedeutet damit der Thermostat nur an Wochentagen (Mo-Fr) schaltet.

Nun muss er es nur noch am Wandthermostat anzeigen!!! Hat jemand noch eine Idee oder habe ich einen fehler in der Programmierzeile???

Gruß

Wolf

[oelidoc]

Hallo,

warum so kompliziert?

Hab das laut fhem reference gelöst. Funktioniert prima, die
Programmzeiten werden auch im Menü am Wandthermostat angezeigt und ich
kann durch entsprechende Befehle die Temp auch akut und aus der Ferne
ändern...

tempListSat HH:MM temp ... 24:00 temp
tempListSun HH:MM temp ... 24:00 temp
tempListMon HH:MM temp ... 24:00 temp
tempListTue HH:MM temp ... 24:00 temp
tempListThu HH:MM temp ... 24:00 temp
tempListWed HH:MM temp ... 24:00 temp
tempListFri HH:MM temp ... 24:00 temp
Specify a list of temperature intervals. Up to 24 intervals can be
specified for each week day, the resolution is 10 Minutes. The last
time spec must always be 24:00.
Example: set th tempListSat 06:00 19 23:00 22.5 24:00 19
Meaning: until 6:00 temperature shall be 19, from then until 23:00
temperature shall be 22.5, thereafter until midnight, 19 degrees
celsius is desired

day-temp <tmp>
night-temp <tmp>
party-temp <tmp>
desired-temp <tmp>
Set different temperatures. Temp must be between 6 and 30 Celsius, and
precision is half a degree.

Gruß

oelidoc

[Wolf]

OK dann werde ich diese Variante mal versuchen

Danke

[dou...@gmx.de]

...und im Übrigen sind die HM-CC-VD "intelligent".

So was  wie "an Wochentagen soll die Heizung, morgens ca. 30min vor dem aufstehen (also 6:15Uhr) auf 20Grad Aufheizen" ist kontraproduktiv.

Gib einfach mit der tempList vor, wann es wie warm sein soll und stell den HM-CC-VD auf "Auto" - der Rest ist sein Job.

Anders gesagt: er "lernt" wie lange er zum Aufheizen eines Raum braucht und passt sich an. Ziel ist es dann zum eingestellten Zeitpunkt die Wunschtemperatur erreicht zu haben. 

VG
Ralf

[dou...@gmx.de]

....hier noch eine Funktion, die ich mir in meine MyUtils geschrieben hab, um das zukünftig bequem ändern zu können.

#

sub

SetTempList_Esszimmer()

 {

   { fhem ("set Esszimmer tempListMon 06:00 18.0 09:30 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListTue 06:00 18.0 09:30 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListWed 06:30 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListThu 06:30 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListFri 06:30 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListSat 07:00 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListSun 07:00 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

}

#

[Wolf]

Gibt es hierzu einen Unterschied??

set Esszimmer tempListMon 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListTue 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListWed 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListThu 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListFri 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListSat 07:30 20 22:00 16 24:00 16

set Esszimmer tempListSun 07:30 20 22:00 16 24:00 16

oder

#

sub

SetTempList_Esszimmer()

 {

   { fhem ("set Esszimmer tempListMon 06:00 18.0 09:30 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListTue 06:00 18.0 09:30 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListWed 06:30 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListThu 06:30 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListFri 06:30 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListSat 07:00 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

   { fhem ("set Esszimmer tempListSun 07:00 18.0 09:00 21.0 15:00 19.0 22:00 21.0 24:00 18.0")};

}

#

Gruß

[dou...@gmx.de]

Ist beides das Gleiche, 

nur ... in meinem Fall gibst du einfach 

SetTempList_Esszimmer 

in der Kommandozeile ein, und das "Programm" setzt dann alle Tage auf einmal. Finde ich praktischer und übersichtlicher, wenn ich schnell mal Änderungen am Wochenplan vornehmen möchte.

Im vorherigen Post meinte ich natürlich die HM-VC-TC  und nicht die VD :-)

[Wolf]

Hallo,

ich habe den Befehl "set Esszimmer tempListWed 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16" mal direkt in die Eingabeleiste eingegeben. In der Log wird folgendes geschrieben:

2012.08.22 13:11:21 4: HTTP FHEMWEB:192.168.0.41:61117 GET /fhem?detail=ES_Wandthermostat&detail=ES_Wandthermostat&dev.setES_Wandthermostat=ES_Wandthermostat&cmd.setES_Wandthermostat=set&arg.setES_Wandthermostat=tempListWed&val.setES_Wandthermostat=06%3A15+20.0+08%3A00+16.0+15%3A00+20.0+22%3A00+16.0+24%3A00+16.0
2012.08.22 13:11:21 2: CUL_HM set ES_Wandthermostat tempListWed 06:15 20.0 08:00 16.0 15:00 20.0 22:00 16.0 24:00 16.0
2012.08.22 13:11:21 4: HTTP FHEMWEB:192.168.0.41:61117 GET /fhem?detail=ES_Wandthermostat
2012.08.22 13:11:21 4: /fhem?detail=ES_Wandthermostat / RL: 3173 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2012.08.22 13:11:21 4: HTTP FHEMWEB:192.168.0.41:61117 GET /fhem/css/svg.js
2012.08.22 13:11:21 4: /fhem/css/svg.js / RL: 701 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2012.08.22 13:11:42 4: HTTP FHEMWEB:192.168.0.41:61117 GET /fhem?room=Esszimmer
2012.08.22 13:11:42 4: /fhem?room=Esszimmer / RL: 1436 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2012.08.22 13:11:42 4: HTTP FHEMWEB:192.168.0.41:61117 GET /fhem/css/svg.js
2012.08.22 13:11:42 4: /fhem/css/svg.js / RL: 701 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2012.08.22 13:11:42 4: RCV L:0C N:B4 CMD:8670 SRC:ES_Wandthermostat DST:broadcast 012638 (TYPE=112,WAKEMEUP,BCAST,RPTEN)
2012.08.22 13:11:42 4: SND L:09 N:01 CMD:A112 SRC:F11234 DST:ES_Wandthermostat  (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012.08.22 13:11:45 4: HTTP FHEMWEB:192.168.0.41:61117 GET /fhem?cmd=logwrapper%20Log_ES_Ventil%20text%20ES_Ventil.log 

2012.08.22 13:11:45 4: /fhem?cmd=logwrapper%20Log_ES_Ventil%20text%20ES_Ventil.log / RL: 5694 / text/html; charset=UTF-8 / Content-Encoding: gzip 

keine Änderungen am HM-CC-TC zu sehen. Ich kann auch nicht auf Cent stellen. Diese Auswahl steht mir nicht zur Verfügung. Zur zeit habe ich das Teil auf "Auto" eingestellt.

Gruß

Wolf

[AlLe]

keine Änderungen am HM-CC-TC zu sehen. Ich kann auch nicht auf Cent stellen. Diese Auswahl steht mir nicht zur Verfügung. Zur zeit habe ich das Teil auf "Auto" eingestellt.

Gruß

Wolf

 

Hallo Wolf,

ich hab ähnliche Probleme. Bis zur Temperaturlistenerstellung bin ich noch gar nicht gekommen. Desiered-temp einstellen hat erst 3 mal geklappt (seit dem ich teste). Hab "auto" eingestellt.

Wenn ich am Stellrad verstelle wird das von fhem übernommen. Der "Event Monitor " zeigt immer schön alle Veränderungen an, doch an der Termostatanzeige passiert nichts. Das Gleiche bei anderen Einstellungen.

Funktionieren bei Dir andere Einstellungen? Daytemp etc.?

Gruß 

Aloys

 

[Wolf]

ich hab ähnliche Probleme. Bis zur Temperaturlistenerstellung bin ich noch gar nicht gekommen. Desiered-temp einstellen hat erst 3 mal geklappt (seit dem ich teste). Hab "auto" eingestellt.

Wenn ich am Stellrad verstelle wird das von fhem übernommen.

bei mir funktioniert nix  desiered-temp, day-temp, night-temp tempListFri.... am Wandthermostat wird nix geändert!!!

 

Der "Event Monitor " zeigt immer schön alle Veränderungen an, doch an der Termostatanzeige passiert nichts. Das Gleiche bei anderen Einstellungen.

Funktionieren bei Dir andere Einstellungen? Daytemp etc.?

Im Event Monitor wird auch nix angezeigt - ist leer!!!! 

gruß

daniel

[fhem-hm-knecht]

Das HM-CC-TC ist noch nicht fertig implementiert :(

es funktioniert bei mir immoment,

der Manuelle Modus, sprich Fhem kann desired temp setzten,
mit Culhm zu 99,9%,
mit hmlan nicht immer, viele missing ack

der Auto Modus, Fhem kann Liste in das HM-CC-TC setzten
hier gilt auch der unterschied zwischen cul und hmlan wie oben.

Fhem bekommt den aktuellen Status des HM-CC-TC mit, wenn verändert.
Uhrzeit wird mit CulHM jetzt auch neu gesetzt nach 0Uhr :)

bei mir geht noch nicht,
von Fhem aus, umschalten des Modus auto,manual,party,cent

heir noch ein paar beitrage


http://groups.google.com/group/fhem-users/browse_thread/thread/fe89f3aeb28e406a/0995dfd8bbd29474#0995dfd8bbd29474

http://groups.google.com/group/fhem-users/browse_thread/thread/1bf183d124e4b578/6d798f9a69eeb65a#6d798f9a69eeb65a

[AlLe]

es funktioniert  bei mir immoment,

der Manuelle Modus, sprich Fhem kann desired temp setzten,
mit  Culhm zu 99,9%,
mit hmlan nicht immer, viele missing ack

Ich hab ein Tuxradio mit fest verbauter CUL (CUL_HM)

Im manuellem Modus kann ich keine desired temp setzten. Die am Rad eingestellte temp wird übernommen.

Im auto Modus das gleiche.

Der desiered-temp-ack ist 4 Tage alt (?)

der Auto Modus, Fhem kann Liste in das HM-CC-TC setzten
hier gilt auch der unterschied zwischen cul und hmlan wie oben.

Liste hab ich geschrieben, ist auch im "Event Monitor" aufgeführt. Geh ich aber im HM-CC-TC ins Programm, sind da immer noch die alten Vorgaben 

Fhem bekommt den aktuellen Status des  HM-CC-TC mit, wenn verändert.
Uhrzeit wird mit CulHM jetzt auch neu gesetzt nach 0Uhr :)

Uhr klappt :) 

bei mir geht noch nicht,
von Fhem aus, umschalten des Modus auto,manual,party,cent

Kann ich bestätigen :(

>Gib einfach mit der tempList vor, wann es wie warm sein soll und stell den HM-CC-VD auf "Auto" - der Rest ist sein Job.

Wie stell ich das Ventil auf "Auto"?   HM-VC-TC...was ist das? Hab ich noch niergendwo gesehen. Oder ist HM-CC-TC gemeint? Ich denke mal

Hallo Daniel,

 

>
> Im Event Monitor wird auch nix angezeigt - ist leer!!!!
>

Du mußt unter Global "verbose" auf 4 stellen um die Anzeige zu bekommen. Und etwas Gedult haben, da ja erst mal Funkverkehr stattfinden muß.

Gruß

Aloys 

[Wolf]

Hallo,

danke für eure Beiträge. Ich habe festgestellt damit das Gerät nicht richtig gepairt war. Die Temperatur und Luftfeutemessung konnte ich auslesen aber am Gerät den Cent modus nicht auswählen. Habe den Thermostat auf Werkseinstellung gesetzt und neu gepairt, nun kann ich auch Cent-Modus auswählen und im EventMonitor erscheinen auch sofort die Änderungen. 

Leider kann ich aber keine Befehle von FHEM an den HM-CC-TC senden. Egal was eingebe!!!

Daniel

[Carsten]

Hallo,

ich wollte nach längerem Schwanken zwischen FHT und Homematic eigentlich genau das gleiche Setup (HM-CC-TC über HMLAN-Adapter) nehmen um in fhem einzusteigen.

Ich hatte mich für den HMLAN-Adapter entschieden, weil ich es so verstanden hatte, dass es keinen Unterschied macht, ob ich CUL/CUNO oder LAN-Adapter verwende, ich aber mit dem HMLAN die Möglichkeit habe, auch mit der Originalsoftware die Geräte zu konfigurieren, ich damit eine "Originalkomponente" benutze  und nicht zuletzt, weil er auch billiger ist als der CUNO.

Nach diesem Thread und den beiden von fhem-hm-knecht verlinkten bin ich jetzt etwas verunsichert. Da ich bisher keinerlei praktische Erfahrung mit fhem und Co habe, fällt es mir schwer, das Problem einzuschätzen. Ist das jetzt eine Totgeburt, die niemals funktionieren wird, oder lässt sich sowas in den Griff kriegen?

[Rudolf Koenig]

> Ist das jetzt eine Totgeburt, die niemals funktionieren wird, oder laesst

> sich sowas in den Griff kriegen?

Das ist sicher kein Totgeburt, aber jemand mit HM-Verstaendnis und etwas Zeit
(oder jemand ohne HM-Verstaendnis und viel Zeit :) muesste sich dransetzen das
Problem im Detail zu verstehen und im entprechenden fhem Modul (CUL_HM.pm)
zu fixen. Evtl. kann man die Aufgaben verstehen und fixen auch verteilen. Ich
bin auch zuversichtlich, dass das irgendwannmal kommt, das Geraet ist
schliesslich eine zentrale HM-Komponente.

[Carsten]

Hallo,

das klingt ja schonmal besser. :)

Ich habe wenig Zeit und bisher Null HM-Verständnis, dafür aber eine hohe Koffeintoleranz und Erfahrung mit diversen anderen Protokollen. :)

Ich mach mir nur ein wenig Sorgen um den WAF, wenn ich meiner Liebsten die Investition als Komfortsteigerung verkaufe und dann den ganzen Winter damit verbringe, die Heizung zu debuggen.

Verstehe ich das richtig, dass die Probleme vor allem das Setzen der Temperatur betreffen, aber das Auslesen (bzw. Mitlesen) funktioniert?
Das Empfangen der Werte wäre der wichtigere Part, da davon abhängig ja die Therme geschaltet werden soll.
Ist bei dem Schreiben denn übergangsweise ein Workaround möglich in Form von Dauersenden, bis der Wert geschluckt wird oder ähnliches?

Gruß

Carsten

[Wolf]

Hallo,

ich versuche nun seit ca. 1 Woche den Thermostat zum laufen zu bringen - Befehle an ihn zu senden. Leider bis dato ohne erfolg, ich kann nur Temperatur, Luftfeuchtigkeit, Ventilstellung und wenn ich am Stellrad die Temperatur verstelle empfangen. 

Habe mir mal gedacht ich poste mal meine fhem.cfg und Esszimmer.cfg vieleicht habe ich irgendwo einen Fehler der mir bis dato nicht aufgefallen ist. Ich habe ja schon öfters in diesem Board gelesen damit es funktionieren soll.

hier meine fhem.cfg

attr global autoload_undefined_devices 1

attr global logfile ./log/fhem-%Y-%m-%d.log

attr global modpath /var/InternerSpeicher/fhem

attr global room Server

attr global statefile ./log/fhem.save

attr global userattr icon webCmd

attr global verbose 4

#

# pgm2 / autocreate configfile. Take a look at the other examples for more.

#

define CUL CUL /dev/ttyACM0@9600 1234

attr CUL rfmode HomeMatic

attr CUL room Server

# Fake FileLog entry, to access the fhem log from FHEMWEB 

define Logfile FileLog ./log/fhem-%Y-%m-%d.log fakelog

attr Logfile room Server

include /var/InternerSpeicher/fhem/webzugriff.cfg

include /var/InternerSpeicher/fhem/autocreate.cfg

include /var/InternerSpeicher/fhem/kueche.cfg

include /var/InternerSpeicher/fhem/Esszimmer.cfg

-----------------------------------------------------------------

hier meine Esszimmer.cfg

#####################

##  Wandthermostat ##

#####################

define ES_Wandthermostat CUL_HM 193693

attr ES_Wandthermostat devInfo 00FFFF

attr ES_Wandthermostat firmware 2.1

attr ES_Wandthermostat hmClass sender

attr ES_Wandthermostat model HM-CC-TC

attr ES_Wandthermostat protCmdPend 33 CMDs pending. Please activate learning

attr ES_Wandthermostat protLastRcv 2012-08-24 06:58:23

attr ES_Wandthermostat room Esszimmer

attr ES_Wandthermostat serialNr JEQ0044235

attr ES_Wandthermostat subType Climate-Control

## Log fuer Thermostat mit Plotauswertung ##

##      (Datei temp4hum6 geändert)        ##

define Log_ES_Wandthermostat FileLog /var/InternerSpeicher/fhem/log/ES_Wandthermostat.log ES_Wandthermostat

attr Log_ES_Wandthermostat logtype temp4hum6:Plot,text

attr Log_ES_Wandthermostat room Esszimmer

#####################

##     Ventil      ##

#####################

define ES_Ventil CUL_HM 193D0A

attr ES_Ventil devInfo 010100

attr ES_Ventil firmware 2.0

attr ES_Ventil hmClass receiver

attr ES_Ventil model HM-CC-VD

attr ES_Ventil protLastRcv 2012-08-24 06:58:24

attr ES_Ventil room Esszimmer

attr ES_Ventil serialNr JEQ0045633

attr ES_Ventil subType unknown

## Log fuer Ventil ##

define Log_ES_Ventil FileLog /var/InternerSpeicher/fhem/log/ES_Ventil.log ES_Ventil

attr Log_ES_Ventil logtype text

attr Log_ES_Ventil room Esszimmer

set Esszimmer tempListMon 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListTue 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListWed 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListThu 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListFri 06:15 20 08:00 16 15:00 20 22:00 16 24:00 16

set Esszimmer tempListSat 07:30 20 22:00 16 24:00 16

set Esszimmer tempListSun 07:30 20 22:00 16 24:00 16

so nun bin ich mal gespannt ob oder wo ich da einen Fehler habe.

DANKE

[Rudolf Koenig]

> attr ES_Wandthermostat protCmdPend 33 CMDs pending. Please activate learning

Du verwendest das neue, noch nicht in FHEM integrierte CUL_HM.pm von Martin,
mit dem kenne ich mich nicht aus. Am besten warten wir solange, bis Martin
wieder aktiv ist.

In fhem.cfg gehoert kein set, es sei denn man verwendet nie ein save, der diese
Zeilen nicht speichert. Das Problem loest man korrekt mit einem notify, der
auf global:INITIALIZED triggert.

@Martin: ich meine protCmdPend gehoert als Reading, da Attribute vom Benutzer
leicht geaendert werden koennen, was hier sicher nicht gemeint ist.
Dass die anderen HM Attribute wie model/hmClass/serialNr/etc als Attribut
gespeichert werden ist Absicht, damit man auch ohne Anlernen HM-Geraete
definieren kann.

[Wolf]

währe dies dann der richtige Befehl:

define KU_HZ_Config notify global:INITIALIZED.* {

   { fhem ("set Esszimmer tempListMon 06:15 21.0 08:00 16.0 15:00 21.0 22:00 16.0 24:00 16.0")};

   { fhem ("set Esszimmer tempListTue 06:15 21.0 08:00 16.0 15:00 21.0 22:00 16.0 24:00 16.0")};

   { fhem ("set Esszimmer tempListWed 06:15 21.0 08:00 16.0 15:00 21.0 22:00 16.0 24:00 16.0")};

   { fhem ("set Esszimmer tempListThu 06:15 21.0 08:00 16.0 15:00 21.0 22:00 16.0 24:00 16.0")};

   { fhem ("set Esszimmer tempListFri 06:15 21.0 08:00 16.0 13:00 21.0 22:00 16.0 24:00 16.0")};

   { fhem ("set Esszimmer tempListSat 07:15 21.0 22:00 16.0 24:00 16.0")};

   { fhem ("set Esszimmer tempListSun 07:15 21.0 22:00 16.0 24:00 16.0")};

}

Danke

[StefanP]

Hallo,
gibts zum Thema HM-CC-TC-tempList irgendwelche neuen Erkenntnisse? Meine hab ich jetzt direkt programmiert.

Grüße StefanP

[dou...@gmx.de]

...so  mache ich es aktuell auch. Das funktioniert zuverlässig und löst das Problem, bis ich (oder andere) mal Zeit zum forschen hatten.

Was ich aber inzwischen sagen kann:

Das die HM-CC-TC die Intelligenz haben, Temperaturverläufe voraus zu berechnen, halte ich nach Auswertung meiner LogFiles schlichtweg für ein Gerücht.

Selbst die handelsüblichen Raumthermostaten von Honeywell konnten das schon vor 15 Jahren.

Wenn ich an einem (intelligenten) Raumthermostaten so etwas einstelle wie "um 06:00 bitte 20°" dann erwarte ich, das sich das Ding drum kümmert, das um 06:00 auch bitte 20° SIND, und nicht um 06:00 mit dem heizen begonnen wird. Leider ist letzteres der Fall.

Und Wolf.... so wie du deine TempList geschrieben hast, fängt deine Heizung um Mitternacht an das Esszimmer zu heizen :-) Wenn du kein Schichtarbeiter bist, der um halb eins nach Hause kommt, möchtest du das vielleicht anpassen? 

Li(e)st sich bei dir (Beginnend um Mitternacht) bis 06:15 - 21° -> bis 08:00 - 16° -> bis 15:00 - 21° -> bis 22:00 - 16° -> bis Mitternacht - 16°

VG
Ralf

[Carsten]

Hallo,

gibt es eigentlich eine Möglichkeit, zu prüfen, ob die TempList vom Themostaten übernommen wurde?

Bei der desired-temp gibt es ja das desired-temp-ack, aber ein TempListTue-ack oder so gibt es ja nicht.
Ich kann zwar auf Missing_ACKs horchen, aber die TempLists möchte ich gerne für die ganze Woche senden. Da das ja asynchron läuft, weiß ich bei einem Missing_ACK dann nicht (bzw. nur low-level in der CUL_HM), welcher der 7 Befehle abgelehnt wurde.

Gruß

Carsten

[Martin]

Die templisten sind in list 5 und list 6 des Kanal 2 kanal 2 Abgelegt. Die sollte man auslesen koennen

Das raw kommando sollte sein

++A001<srcID><dstId>02040000000005
++A001<srcID><dstId>02040000000006

Abgelegt sind die Daten
Sat 1 timeout (addr 11)
Sat 1 temperatur (addr12
Sat 2......
Sat24 timeout
Sat24 temperatur
Sun 1 timeout
Sun 1 temperatur..........

Gruss
Martin

[Carsten]

Hallo,

danke für die Antwort! Ich hatte zwar eher an eine Möglichkeit über die bestehenden Objekte gedacht, aber eigentlich gefällt mir das aktive Abfragen fast noch besser.

Ich werd mal damit rumtesten, wenn ich zu Hause bin.

Ich nehme mal an, die Antwort wird von CUL_HM als unbekannt ignoriert? Kann man sich für bestimmte Raw-Antworten in die Kommunikation hooken und die Auswertung woanders übernehmen? Ich möchte das ungern direkt in der CUL_HM machen.

Gibt es für diese Kanal/Listen/Adressen-Struktur, von der du immer sprichst, eigentlich irgendwo eine Doku, oder hast du einfach mal alle durchprobiert und geschaut, was kommt?

Gruß

Carsten

[Martin]

Hallo Martin,

Ich nehme mal an, die Antwort wird von CUL_HM als unbekannt ignoriert? Kann man sich für bestimmte Raw-Antworten in die Kommunikation hooken und die Auswertung woanders übernehmen? Ich möchte das ungern direkt in der CUL_HM machen.

ich bastle gerade an der CUL_HM. Registerwerte speichere ich im Rohformat - habe auch schon ein paar Register human readable implementiert. Die aktuelle Loesung fuer TC bleibt bestehen (sicher) aber mir schient sie zu einseitig da sie eben NUR TC beruecksichtigt.
Wenn alles klappt will ich es nach dem Wochenende nach SVN abgeben.

Gibt es für diese Kanal/Listen/Adressen-Struktur, von der du immer sprichst, eigentlich irgendwo eine Doku, oder hast du einfach mal alle durchprobiert und geschaut, was kommt?

es gibt die xml files aus der HM software. Da kann man einiges rauslesen, aber nicht alles. Es sind nicht alle Messages beschrieben - und das Verhalten garnicht. Aber je nach Device steht doch einiges drin.
Ist bei eq3 under sw updates enthalten

Gruss

Martin

[dou...@gmx.de]

...ich les hier echt fleissig mit, und hoffe das ich bald das ein oder andere umsetzen/beitragen kann.

Dafür heute morgen dann mal so ein Fall von Bug oder Feature? Alle HM-CC-TCs laufen plötzlich exact eine Stunde nach. Also statt 07:00 haben sie die Uhrzeit 06:00 und die Hütte ist kalt.

Wo kommt das her? Jemand ne Idee?

VG

Ralf

[Rudolf Koenig]

> Alle HM-CC-TCs laufen pl�tzlich exact eine Stunde nach.

Wenn sie mit fhem gepaart sind, dann beziehen sie einmal am Tag (kurz nach
Mitternacht) Ihre Uhrzeit vom fhem.

[fhem-hm-knecht]

Bei datumswechsel , also in den ersten 3 Minuten frägt das TC Fhem
nach der Uhrzeit,
mein Fhem hat die richtige heute Nacht geschickt

du mußt bei dir schauen wer da die falsche Uhrzeit verbreitet

du kannst dein tc von hand auf 23:58 stellen und warten bis das tc
eine neue Uhrzeitanfrage macht.

> und die Hütte ist kalt.

Haus dämmen?
;)
hary

[dou...@gmx.de]

Alle meine HM-CC-TCs sind mit der fhem Installation auf der Fritz-Box gepairt (und NUR mit der (ausser den Aktoren)). Das HM IO-Device ist ein CUNO.

Die Uhrzeit auf der FritzBox ist korrekt  und auch die Zeiten im LogFile von fhem sind korrekt. 

Hab einen der TCs auf 23:58 gesetzt und *boing* neue Uhrzeit: 08:29  .... eine Stunde zu wenig.... woher kann das kommen?

VG
Ralf

[Carsten]

Am Donnerstag, 27. September 2012 07:43:00 UTC+2 schrieb Martin:

Hallo Martin,

Hallo!
Du bist Martin. Ich bin Carsten. ;)

ich bastle gerade an der CUL_HM. Registerwerte speichere ich im Rohformat - habe auch schon ein paar Register human readable implementiert. Die aktuelle Loesung fuer TC bleibt bestehen (sicher) aber mir schient sie zu einseitig da sie eben NUR TC beruecksichtigt.
Wenn alles klappt will ich es nach dem Wochenende nach SVN abgeben.

Also gibts erstmal keine Hoffnung auf Besserung bei der TC-Kommunikation. Ich bin dennoch gespannt. Vielleicht versteh ich das ganze mit dem geänderten Code ja etwas besser.
 

es gibt die xml files aus der HM software. Da kann man einiges rauslesen, aber nicht alles. Es sind nicht alle Messages beschrieben - und das Verhalten garnicht. Aber je nach Device steht doch einiges drin.
Ist bei eq3 under sw updates enthalten

Ah, okay. Werd ich mir mal anschauen. Danke!

Ich hab gestern mal probehalber die list5 angefragt. Nach zwei Missing Acks kamen auch ne Menge Daten vom TC zurück. Habs aber müdigkeitsbedingt nicht mehr geschafft, die Daten auszuwerten.
Was mir aber aufgefallen ist, waren viele identische Wertfolgen. Ich glaube es waren Wiederholungen von 2890. Ich habe die 24 möglichen Zeitslots bei weitem nicht ausgenutzt. Sind das dann die ungenutzten?

Gruß

Carsten

[fhem-hm-knecht]

1. wo ist das telnet log?

2. meine FBox sendet die richige Uhrzeit zum TC

3. du spielst doch mit dem Rpi rum, läuft da Fhem mit der gleichen id?
weil paring ist beim Uhrzeit verschicken uninteressant.

hary

[dou...@gmx.de]

BINGO!

Ein doofer, ein schlauer, und ein gemeinsamer Gedanke! :-)

Danke dir für den Tipp! Es ist der RPi gewesen. Da es die FB nicht sein konnte, blieb nur diese Möglichkeit. Hab den RPi vom Strom getrennt und noch mal auf 23:58 gesetzt. Jetzt stimmt die Zeit. 

Aber du hast recht: meine TCs sind zwar nicht mit dem RPi gepairt, aber ich habe auf beiden Systmen keine HMid vergeben aber die gleiche FHTID (0000) vergeben. 

Hab auf dem RPi jetzt die FHTID 0001 gesetzt  und dann noch mal einen TC auf 23:58 gestellt. 

Jetzt ist alles korrekt!! :-)

Bleibt die Frage woher fhem auf dem RPi die falsche Uhrzeit bekommt.... aber das ist ne andere Baustelle und soll hier nicht stören.

DANKE! :-)

[Steffen]

Guten Morgen!

Ich habe jetzt auch das Problem das sich über Nacht die Zeit im HM-CC-TC um eine stunde nach hinten verschiebt, woran könnte es liegen???

Denn in meinem System(qnap-ts-119p) wo Fhem läuft ist die Zeit Richtig und in Fhem sowie Fritzbox(7170) auch!

Der Log von HM-CC-TC wird auch in Fhem mit der Richtigen Zeit geschrieben aber die HM-CC-TC hat genau eine Stunde zuürck und regelt ja nach dieser Zeit:-(!

Mfg Steffen

[dou...@gmx.de]

Moin Steffen,

was ich gemacht habe war, das ich mich mit 

telnet fritz-box-ip 7072 

mit der FB verbunden habe und dann mit

inform timer

mir die ganzen Meldungen angesehen habe. Dann einen HM-CC-TC genommen und auf 23:58 gestellt.

Irgendwann kurz nachdem er auf 00:00 umgesprungen ist, gab es bei mir eine Meldung des TC "time request"

Danach war die Uhrzeit wieder okay.

Wie gesagt hatte ich zuvor meine andere fhem-installation deaktiviert bzw. auf eine andere HMid gesetzt.

Vielleicht hilft das den Fehler einzugrenzen? Warum mein Raspberry Pi die falsche Uhrzeit sendete, kann ich aber noch nicht beurteilen.

VG
Ralf

[Steffen]

Hallo!

Danke für den tip aber hat leider nicht geklappt, habe jetzt auch mal auf 23:58 gestellt und dann bei 0:00 sprang die Uhrzeit auf 5:20 was aber jetzt 6:20 seien müsste, also bekommt er von irgendwo die falsche Uhrzeit schätze ich mal, aber von wo???

Was mir noch aufgefallen ist hinter time-request: im log ist keine zeit oder ähnliches, ist das normal???

Mfg Steffen

[dou...@gmx.de]

Setz deinen qnap doch mal zum Test auf die Zeitzone Finland/Helsinki ;-)

[Martin]

Hallo Carsten

Du bist Martin. Ich bin Carsten. ;)

ok - geht klar

ich bastle gerade an der CUL_HM. Registerwerte speichere ich im Rohformat - habe auch schon ein paar Register human readable implementiert. Die aktuelle Loesung fuer TC bleibt bestehen (sicher) aber mir schient sie zu einseitig da sie eben NUR TC beruecksichtigt.
Wenn alles klappt will ich es nach dem Wochenende nach SVN abgeben.

Also gibts erstmal keine Hoffnung auf Besserung bei der TC-Kommunikation. Ich bin dennoch gespannt. Vielleicht versteh ich das ganze mit dem geänderten Code ja etwas besser.

Was ich meinte ist, dass ich das aktuelle Interface nicht beschaedigen will. Es ist recht aufwendig fuer die User und ich vermute, dass jede Aenderung zu grossen Probleme fuehren kann.
Im Wesentlichen werden beim TC Register gesetzt und gelesen. Das ganze ist mit einem TC spezifischen Frontend und Backend versehen.
Meine Version hat ein allgemeines Register- (oder Configuration-)handling. Das kann auch von TC Usern benutzt werden. Bisher habe ich noch keine Anpassungen gemacht aber generell sollte es das Ziel sein, das TC backend verschwinden zu lassen (merkt der User nicht, wenn es korrekt gemacht ist) . Dann kann man Funktionen nutzen wie das manuelle auslesen der Daten und somit ein Update in FHEM.
Stand ist, dass die Registerlisten (die haesslichen HEX listen nach dem lesen durch getRegRax oder getConfig) immer auf dem letzten gelesenen Stand sind - manuell oder automatisch. TC verarbeitet nur die Automatischen.

Zum Konfigurieren ist fuer TC ein recht raumgreifendes Interface geschaffen worden - jeder Parameter hat sein Kommando bekommen. Meine Alternative ist, es ueber set reg zu machen.
So kann man jetzt parallel zu den herkoemmlichen Kommands auch in die Register schreiben
set <name> reg DispTempHum [1|0]
set <name> reg DispTempInfo [1|0]
set <name> reg TempLower [6.0..30] # in grad
set <name> reg PartyEndDay
set <name> reg PartyEndHr
set <name> reg PartyEndMin

Fertig ist die Umstellung fuer TC nicht - da brauche ich noch mehr input (ich habe ja keinen TC...)

Gleich mal eine Frage - wenn du einen Registerwert aenderst - antwortet dann TC automatisch und schickt die neue Regliste zurueck? Kann ich mal einen Log sehen, wenn du einen Wert aenderst?

 

es gibt die xml files aus der HM software. Da kann man einiges rauslesen, aber nicht alles. Es sind nicht alle Messages beschrieben - und das Verhalten garnicht. Aber je nach Device steht doch einiges drin.
Ist bei eq3 under sw updates enthalten

Ah, okay. Werd ich mir mal anschauen. Danke!

Ich hab gestern mal probehalber die list5 angefragt. Nach zwei Missing Acks kamen auch ne Menge Daten vom TC zurück. Habs aber müdigkeitsbedingt nicht mehr geschafft, die Daten auszuwerten.
Was mir aber aufgefallen ist, waren viele identische Wertfolgen. Ich glaube es waren Wiederholungen von 2890. Ich habe die 24 möglichen Zeitslots bei weitem nicht ausgenutzt. Sind das dann die ungenutzten?

in den Registern liegen immer alle moeglichen Werte - also 24 temperatur/timeint paare pro Tag =>24*2*7 = 336 Werte .
2890 ... hex?
28 = 40 => 20 Grad
90 = 144 => 1440min oder 24h
Jo, sieht nach default aus

Gruss
Martin

[eppi]

Am Freitag, 28. September 2012 08:46:24 UTC+2 schrieb dou...@m1n1.de:

Setz deinen qnap doch mal zum Test auf die Zeitzone Finland/Helsinki ;-)

Ich habe seit 2 Tagen auch dieses Problem und habe mir geholfen mit folgendem Workaround:

10_CUL_HM.pm, (Zeile 1964) & 00_HMLAN.pm (Zeile 387)

  $t -= 7200;   # HM Special
durch
  $t -= 3600;   # HM Special
ersetzen

Gruss Dani




 

[Rudolf Koenig]

> Ich habe seit 2 Tagen auch dieses Problem...

Ich jetzt auch. Da ich am SW nichts geaendert habe (meine ich), tippe ich auf
ein "Feature" in dem CC-TC Firmware: Wir haben doch den letzten Sonntag im
September hinter uns...

[dou...@gmx.de]

Aber wäre denn dann nicht auch meine Installation auf der FritzBox betroffen?

Ich hatte das Prob nur in Verbindung mit dem RPi... (oder das war ein Confounder :-) )

[fhem-hm-knecht]

Fbox und Tc-->(noch) kein Problem

Hary

[Martin]

Hat der TC ueberhaupt den Monat? ein Sommerzeitproblem kann es bestenfalls in der Zentrale sein - oder?

[Carsten]

Gleich mal eine Frage - wenn du einen Registerwert aenderst - antwortet dann TC automatisch und schickt die neue Regliste zurueck? Kann ich mal einen Log sehen, wenn du einen Wert aenderst?

Reicht dir das?

 

Setzen von desired-temp:

2012-09-29 14:51:14 CUL_HM bd_Heizung desired-temp 20.0
2012-09-29 14:52:54 HMLAN HMLAN1 RCV L:0C N:B0 CMD:8670 SRC:bd_Heizung DST:broadcast 00E93D (TYPE=112,WAKEMEUP,BCAST,RPTEN)
2012-09-29 14:52:55 HMLAN HMLAN1 SND L:09 N:D7 CMD:A112 SRC:090909 DST:bd_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 14:52:55 HMLAN HMLAN1 RCV L:0A N:D7 CMD:8002 SRC:bd_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 14:52:55 HMLAN HMLAN1 SND L:0C N:D8 CMD:A011 SRC:090909 DST:bd_Heizung 020228 (SET CHANNEL:02 VALUE:28) (TYPE=17,BIDI,RPTEN)
2012-09-29 14:52:55 HMLAN HMLAN1 RCV L:0E N:D8 CMD:8002 SRC:bd_Heizung DST:090909 0102280039 (ACK_STATUS CHANNEL:02 STATUS:28 UP:0 DOWN:0 LOWBAT:0 RSSI:-57) (TYPE=2,RPTEN)
2012-09-29 14:52:55 CUL_HM bd_Heizung desired-temp-ack: 20.0
2012-09-29 14:52:55 CUL_HM bd_Heizung desired-temp: 20.0



Setzen aller tempLists ( aus irgendeinem Grund funktioniert das zuverlässiger als eine einzelne )
2012-09-29 15:26:55 CUL_HM wz_Heizung tempListMon 06:00 18.0 09:30 20.0 18:00 19.0 22:00 20.0 24:00 20.0
2012-09-29 15:26:55 CUL_HM wz_Heizung tempListTue 06:00 18.0 09:30 20.0 18:00 19.0 22:00 20.0 24:00 20.0
2012-09-29 15:26:55 CUL_HM wz_Heizung tempListWed 06:00 18.0 09:30 20.0 18:00 19.0 22:00 20.0 24:00 20.0
2012-09-29 15:26:55 CUL_HM wz_Heizung tempListThu 06:00 18.0 09:30 20.0 18:00 19.0 22:00 20.0 24:00 20.0
2012-09-29 15:26:55 CUL_HM wz_Heizung tempListFri 06:00 18.0 09:30 20.0 18:00 19.0 22:00 20.0 24:00 20.0
2012-09-29 15:26:55 CUL_HM wz_Heizung tempListSat 06:00 18.0 09:30 20.0 18:00 19.0 22:00 20.0 24:00 20.0
2012-09-29 15:26:56 CUL_HM wz_Heizung tempListSun 06:00 18.0 09:30 20.0 18:00 19.0 22:00 20.0 24:00 20.0
2012-09-29 15:28:03 HMLAN HMLAN1 RCV L:0C N:9F CMD:8670 SRC:wz_Heizung DST:broadcast 00CE3F (TYPE=112,WAKEMEUP,BCAST,RPTEN)
2012-09-29 15:28:03 HMLAN HMLAN1 SND L:09 N:E9 CMD:A112 SRC:090909 DST:wz_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 15:28:03 HMLAN HMLAN1 RCV L:0A N:E9 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:04 HMLAN HMLAN1 SND L:10 N:EA CMD:A001 SRC:090909 DST:wz_Heizung 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:05) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:04 HMLAN HMLAN1 RCV L:0A N:EA CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:04 HMLAN HMLAN1 SND L:19 N:EB CMD:A001 SRC:090909 DST:wz_Heizung 02086B246C246D396E286F6C70267184 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 6B:24 6C:24 6D:39 6E:28 6F:6C 70:26 71:84) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:04 HMLAN HMLAN1 RCV L:0A N:EB CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:05 HMLAN HMLAN1 SND L:11 N:EC CMD:A001 SRC:090909 DST:wz_Heizung 0208722873907428 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 72:28 73:90 74:28) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:05 HMLAN HMLAN1 RCV L:0A N:EC CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:05 HMLAN HMLAN1 SND L:0B N:ED CMD:A001 SRC:090909 DST:wz_Heizung 0206 (CONFIG_END CHANNEL:02) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:05 HMLAN HMLAN1 RCV L:0A N:ED CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:06 HMLAN HMLAN1 SND L:09 N:EE CMD:A112 SRC:090909 DST:wz_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 15:28:06 HMLAN HMLAN1 RCV L:0A N:EE CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:06 HMLAN HMLAN1 SND L:10 N:EF CMD:A001 SRC:090909 DST:wz_Heizung 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:05) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:06 HMLAN HMLAN1 RCV L:0A N:EF CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:07 HMLAN HMLAN1 SND L:19 N:F0 CMD:A001 SRC:090909 DST:wz_Heizung 02089B249C249D399E289F6CA026A184 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 9B:24 9C:24 9D:39 9E:28 9F:6C A0:26 A1:84) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:07 HMLAN HMLAN1 RCV L:0A N:F0 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:07 HMLAN HMLAN1 SND L:11 N:F1 CMD:A001 SRC:090909 DST:wz_Heizung 0208A228A390A428 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: A2:28 A3:90 A4:28) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:07 HMLAN HMLAN1 RCV L:0A N:F1 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:08 HMLAN HMLAN1 SND L:0B N:F2 CMD:A001 SRC:090909 DST:wz_Heizung 0206 (CONFIG_END CHANNEL:02) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:08 HMLAN HMLAN1 RCV L:0A N:F2 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:08 HMLAN HMLAN1 SND L:09 N:F3 CMD:A112 SRC:090909 DST:wz_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 15:28:08 HMLAN HMLAN1 RCV L:0A N:F3 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:09 HMLAN HMLAN1 SND L:10 N:F4 CMD:A001 SRC:090909 DST:wz_Heizung 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:05) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:09 HMLAN HMLAN1 RCV L:0A N:F4 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:09 HMLAN HMLAN1 SND L:19 N:F5 CMD:A001 SRC:090909 DST:wz_Heizung 0208CB24CC24CD39CE28CF6CD026D184 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: CB:24 CC:24 CD:39 CE:28 CF:6C D0:26 D1:84) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:09 HMLAN HMLAN1 RCV L:0A N:F5 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:09 HMLAN HMLAN1 SND L:11 N:F6 CMD:A001 SRC:090909 DST:wz_Heizung 0208D228D390D428 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: D2:28 D3:90 D4:28) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:10 HMLAN HMLAN1 RCV L:0A N:F6 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:10 HMLAN HMLAN1 SND L:0B N:F7 CMD:A001 SRC:090909 DST:wz_Heizung 0206 (CONFIG_END CHANNEL:02) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:10 HMLAN HMLAN1 RCV L:0A N:F7 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:10 HMLAN HMLAN1 SND L:09 N:F8 CMD:A112 SRC:090909 DST:wz_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 15:28:10 HMLAN HMLAN1 RCV L:0A N:F8 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:11 HMLAN HMLAN1 SND L:10 N:F9 CMD:A001 SRC:090909 DST:wz_Heizung 02050000000006 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:06) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:11 HMLAN HMLAN1 RCV L:0A N:F9 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:11 HMLAN HMLAN1 SND L:19 N:FA CMD:A001 SRC:090909 DST:wz_Heizung 02080124022403390428056C06260784 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 01:24 02:24 03:39 04:28 05:6C 06:26 07:84) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:11 HMLAN HMLAN1 RCV L:0A N:FA CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:12 HMLAN HMLAN1 SND L:11 N:FB CMD:A001 SRC:090909 DST:wz_Heizung 0208082809900A28 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 08:28 09:90 0A:28) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:12 HMLAN HMLAN1 RCV L:0A N:FB CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:12 HMLAN HMLAN1 SND L:0B N:FC CMD:A001 SRC:090909 DST:wz_Heizung 0206 (CONFIG_END CHANNEL:02) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:13 HMLAN HMLAN1 RCV L:0A N:FC CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:13 HMLAN HMLAN1 SND L:09 N:FD CMD:A112 SRC:090909 DST:wz_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 15:28:13 HMLAN HMLAN1 RCV L:0A N:FD CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:13 HMLAN HMLAN1 SND L:10 N:FE CMD:A001 SRC:090909 DST:wz_Heizung 02050000000006 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:06) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:14 HMLAN HMLAN1 RCV L:0A N:FE CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:14 HMLAN HMLAN1 SND L:19 N:FF CMD:A001 SRC:090909 DST:wz_Heizung 02083124322433393428356C36263784 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 31:24 32:24 33:39 34:28 35:6C 36:26 37:84) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:14 HMLAN HMLAN1 RCV L:0A N:FF CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:14 HMLAN HMLAN1 SND L:11 N:00 CMD:A001 SRC:090909 DST:wz_Heizung 0208382839903A28 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 38:28 39:90 3A:28) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:14 HMLAN HMLAN1 RCV L:0A N:00 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:15 HMLAN HMLAN1 SND L:0B N:01 CMD:A001 SRC:090909 DST:wz_Heizung 0206 (CONFIG_END CHANNEL:02) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:15 HMLAN HMLAN1 RCV L:0A N:01 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:15 HMLAN HMLAN1 SND L:09 N:02 CMD:A112 SRC:090909 DST:wz_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 15:28:15 HMLAN HMLAN1 RCV L:0A N:02 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:16 HMLAN HMLAN1 SND L:10 N:03 CMD:A001 SRC:090909 DST:wz_Heizung 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:05) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:16 HMLAN HMLAN1 RCV L:0A N:03 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:16 HMLAN HMLAN1 SND L:19 N:04 CMD:A001 SRC:090909 DST:wz_Heizung 02080B240C240D390E280F6C10261184 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 0B:24 0C:24 0D:39 0E:28 0F:6C 10:26 11:84) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:17 HMLAN HMLAN1 RCV L:0A N:04 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:17 HMLAN HMLAN1 SND L:11 N:05 CMD:A001 SRC:090909 DST:wz_Heizung 0208122813901428 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 12:28 13:90 14:28) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:17 HMLAN HMLAN1 RCV L:0A N:05 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:17 HMLAN HMLAN1 SND L:0B N:06 CMD:A001 SRC:090909 DST:wz_Heizung 0206 (CONFIG_END CHANNEL:02) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:17 HMLAN HMLAN1 RCV L:0A N:06 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:18 HMLAN HMLAN1 SND L:09 N:07 CMD:A112 SRC:090909 DST:wz_Heizung (HAVE_DATA) (TYPE=18,WAKEUP,BIDI,RPTEN)
2012-09-29 15:28:18 HMLAN HMLAN1 RCV L:0A N:07 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:18 HMLAN HMLAN1 SND L:10 N:08 CMD:A001 SRC:090909 DST:wz_Heizung 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:05) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:18 HMLAN HMLAN1 RCV L:0A N:08 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:19 HMLAN HMLAN1 SND L:19 N:09 CMD:A001 SRC:090909 DST:wz_Heizung 02083B243C243D393E283F6C40264184 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 3B:24 3C:24 3D:39 3E:28 3F:6C 40:26 41:84) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:19 HMLAN HMLAN1 RCV L:0A N:09 CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:19 HMLAN HMLAN1 SND L:11 N:0A CMD:A001 SRC:090909 DST:wz_Heizung 0208422843904428 (CONFIG_WRITE_INDEX CHANNEL:02 DATA: 42:28 43:90 44:28) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:19 HMLAN HMLAN1 RCV L:0A N:0A CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:20 HMLAN HMLAN1 SND L:0B N:0B CMD:A001 SRC:090909 DST:wz_Heizung 0206 (CONFIG_END CHANNEL:02) (TYPE=1,BIDI,RPTEN)
2012-09-29 15:28:20 HMLAN HMLAN1 RCV L:0A N:0B CMD:8002 SRC:wz_Heizung DST:090909 00 (ACK) (TYPE=2,RPTEN)
2012-09-29 15:28:23 HMLAN HMLAN1 RCV L:0B N:9F CMD:A258 SRC:wz_Heizung DST:wz_Stellantrieb 0000 (TYPE=88,WAKEMEUP,BIDI,RPTEN)
 

[Martin]

Gleich mal eine Frage - wenn du einen Registerwert aenderst - antwortet dann TC automatisch und schickt die neue Regliste zurueck? Kann ich mal einen Log sehen, wenn du einen Wert aenderst?

Reicht dir das?

ja danke.
 

[Carsten]

Hallo!

Nach updatefhem sehe ich, dass sich einiges getan hat. Sieht interessant aus. Endlich kann ich meine TCs auch als climate-control definieren.

Allerdings habe ich den Eindruck, dass jetzt gar keine Befehle mehr an die TCs gesendet werden. Sowohl nach set desired-temp als auch nach templistxxx sehe ich kein SND (weder Wakeup noch der eigentliche Befehl) im Eventmonitor. Die Temperatur am Gerät ändert sich auch nicht. Muss ich da noch was anpassen?

Gruß

Carsten

[Carsten]

Hmm...

Ich hab mir jetzt mal ein paar Logmessages in die ProcessCmdStack eingebaut.

Ich bin leider nicht so fit in Perl, aber das "if($hash->{cmdStack} )" ist scheinbar immer false.

Was ich nicht ganz durchschaue, ist, warum der cmdstack manchmal als "$hash->cmdStack" und manchmal als "@{$hash->{cmdStack}}" angesprochen wird.
Sehe ich das richtig, dass die erste Variante einen einfachen (String?)-Wert liefern sollte, und die zweite ein Array?

Ich habe auch mal testweise eine Logmessage hinter ein "if(@{$hash->{cmdStack}})" gepackt. Danach stürzte FHEM ab und in der Konsole gab es folgende Meldung:

Can't use an undefined value as an ARRAY reference at ./FHEM/10_CUL_HM.pm

[Martin]

Carsten

zum einen muss die Zeile
  my $isSender = ($class eq "sender" || $md eq "HM-CC-TC");
geaendert werden in
  my $isSender = ($class eq "sender");

Damit wird der command stack dann wie bei allen devices ueber die HMclass gesteuert. Sollte aber noch kein Problemdarstellen, da es schon immer so war.

Wenn du einen trace einbaust musst du pruefen, ob es den Wert auch gibt.
Ob commands im Stack haengen kann man ueber protCmdPend sehen (protocol - command pending). Hier staht die Anzahl. Die Variable ist immer im device (bei TC warscheinlich nur eines).

Die Abfrage nach dem Stack ist schon ok. Der Stack selbst funktioniert auch einwandfrei. Wenn du eine Fernbedienung hast, kannst du es sehr schoen verfolgen - Kommandos werden gestackt und bei Anlernen ausgegeben.

Das Problem sollte also nur TC betreffen.

Wenn du einen trace eibaust dann in
sub
CUL_HM_PushCmdStack($$)
als letzte zeile
Log 1,"CmdStack Entries:".$entries." for:".$hash->{NAME};


und einen 2. beim leeren des Stack:

CUL_HM_ProcessCmdStack($)
# vor dem return
Log 1,"CmdStack ".(($hash->{cmdStack})?"empty":"avaliable ")." for:".$hash->{NAME};

btw: hmClass steht doch jetzt sender - oder?

Martin

[Martin]

Carsten

 auf die schnelle empfehle ich die folgende Zeile einzubauen, s.u.
Ich gehe davon aus, dass die "8670" immer noch alle 5 min von TC kommt und verarbeitet wird - korrekt?

    $sendAck = ""; #todo why is this special?
    CUL_HM_ProcessCmdStack($shash);
  }
  elsif($model eq "HM-CC-VD") { ###################

Bitte Ergebnisse und Traces

Danke
Martin

[Carsten]

Hallo,

danke erstmal für Deinen Einsatz!

Da ich heute und morgen erst relativ spät zu Hause sein werde, weiß ich noch nicht, wann ich zum Testen komme. Im Moment läuft übergangsweise wieder die alte Version.

Fernbedienung habe ich bisher keine. Zur Zeit nur die TCs, VDs und ein Relais. Das Relais funktioniert auch weiterhin problemlos.

Ich hatte gestern noch gesehen, dass er bei den TCs scheinbar nie in das ProcessCmdStack läuft, sondern scheinbar nur bei den -VDs, für die der Stack natürlich leer ist.
Daraufhin habe ich ans Ende der parseCommon-Funktion noch ein elsif($msgType eq "70" ) eingefügt und darin ein ProcessCmdStack getriggert um auf die 8670 - Meldungen zu reagieren. Die kommen alle ~2 Minuten.

Daraufhin wurden dann auch wieder Telegramme an die TCs gesendet, von denen allerdings kein einziges verarbeitet wurde. Aufgrund der fortgeschrittenen Stunde habe ich das Testen dann erstmal eingestellt, aber die Telegramme kamen mir teilweise "seltsam" vor. Mit seltsam meine ich, dass vor lauter Log-Messages mein Log zu dem Zeitpunkt nur noch schwer lesbar war, ich aber meine, dass zwischendurch trotz Ack des -TCs mit der Meldung Missing-Ack abgebrochen wurde.

Es wurden auch Resend-Versuche geloggt, die in der alten Version für den HMLAN ausgeklammert waren, weil laut Rudi der LAN-Adapter selbst schon Resends vornimmt.

Ich hoffe, dass ich heute Abend vielleicht doch noch ein Stündchen zum Weitertesten finde, denn ansonsten sieht die neue Version gut aus.

Gruß

Carsten

[Martin]

Hallo,

Da ich heute und morgen erst relativ spät zu Hause sein werde, weiß ich noch nicht, wann ich zum Testen komme. Im Moment läuft übergangsweise wieder die alte Version.

klar - sorry

Ich hatte gestern noch gesehen, dass er bei den TCs scheinbar nie in das ProcessCmdStack läuft, sondern scheinbar nur bei den -VDs, für die der Stack natürlich leer ist.

Kommandos gehen bis auf ACKs alle in den Stack - alle devices. Nur ausnahmen (Acks..) duerfen ueberholen.

Daraufhin habe ich ans Ende der parseCommon-Funktion noch ein elsif($msgType eq "70" ) eingefügt und darin ein ProcessCmdStack getriggert um auf die 8670 - Meldungen zu reagieren. Die kommen alle ~2 Minuten.

2 min ist schnell. Ich habe einen trace erhalten mit 5 min. Das passt zu den Info, die ich habe (600sec). Noch habe ich nicht gesehen, dass es einstellbar ist. => welche FW hat dein TC?

Daraufhin wurden dann auch wieder Telegramme an die TCs gesendet, von denen allerdings kein einziges verarbeitet wurde. Aufgrund der fortgeschrittenen Stunde habe ich das Testen dann erstmal eingestellt, aber die Telegramme kamen mir teilweise "seltsam" vor. Mit seltsam meine ich, dass vor lauter Log-Messages mein Log zu dem Zeitpunkt nur noch schwer lesbar war, ich aber meine, dass zwischendurch trotz Ack des -TCs mit der Meldung Missing-Ack abgebrochen wurde.

missing-ACK loescht den Stack, dann ist Schluss.
Dass der Einbau des processCmdStack zum senden der Messages gefuehrt hat beseutet, dass der TC den Stack benutzt  - muss ja...
Der passende Platz zum Einbau waere dann aber im parse TC nach cmd eq '8670'.

Es wurden auch Resend-Versuche geloggt, die in der alten Version für den HMLAN ausgeklammert waren, weil laut Rudi der LAN-Adapter selbst schon Resends vornimmt.

Moeglich, dass es auch einen resend im LAN adapter gibt, kann ich nicht sehen (und in den HMlan habe ich mich nicht eingearbgeitet).
Sicher ist, dass in meinem Setup das resend mit unter zum Erfolg fuehrt. Es sollte unbedingt an sein - ueber Timer und Anzahl der Wiederhohlungen kann man diskutieren

Evtl bekomme ich ein leih-TC  - dann wird es mit dem Testen einfacher fuer mich ;-)

Nebenbei: bei welchen devices welche Kommandos 'postponed' werden muessen und wann das Senden starten sollte ist noch in Untersuchung. Da ist noch ein RC19 und andere devices nicht fertig getestet.

Gruss
Martin

[Carsten]

Am Montag, 1. Oktober 2012 12:19:15 UTC+2 schrieb Martin:

Hallo,

Da ich heute und morgen erst relativ spät zu Hause sein werde, weiß ich noch nicht, wann ich zum Testen komme. Im Moment läuft übergangsweise wieder die alte Version.

klar - sorry

Sorry? Weils noch nicht läuft? Kein Grund. Ich bin mehr als froh, dass sich jemand mit Plan der Sache annimmt.
 

Ich hatte gestern noch gesehen, dass er bei den TCs scheinbar nie in das ProcessCmdStack läuft, sondern scheinbar nur bei den -VDs, für die der Stack natürlich leer ist.

Kommandos gehen bis auf ACKs alle in den Stack - alle devices. Nur ausnahmen (Acks..) duerfen ueberholen.

Ja, aber an die Stellantriebe sendet fhem (bei mir) keine Kommandos. Das übernimmt der TC. Daher ist der Stack für die VDs immer leer.
 

Daraufhin habe ich ans Ende der parseCommon-Funktion noch ein elsif($msgType eq "70" ) eingefügt und darin ein ProcessCmdStack getriggert um auf die 8670 - Meldungen zu reagieren. Die kommen alle ~2 Minuten.

2 min ist schnell. Ich habe einen trace erhalten mit 5 min. Das passt zu den Info, die ich habe (600sec). Noch habe ich nicht gesehen, dass es einstellbar ist. => welche FW hat dein TC?

Laut fhem ist die FW 2.1. Bei Inbetriebnahme habe ich nur drauf geachtet, dass Sie > 2 sind, wegen des Bugs. Ich hab irgendwas von 120 - 180 Sekunden in Erinnerung. Ich hab gerade mal mit dem Handy zugeschaut. 2:53 Minuten zwischen zwei 8670er-Meldungen im Badezimmer. Im fhemwiki steht auch 2 Minuten. Eingestellt habe ich da aktiv nichts.

Es wurden auch Resend-Versuche geloggt, die in der alten Version für den HMLAN ausgeklammert waren, weil laut Rudi der LAN-Adapter selbst schon Resends vornimmt.

Moeglich, dass es auch einen resend im LAN adapter gibt, kann ich nicht sehen (und in den HMlan habe ich mich nicht eingearbgeitet).
Sicher ist, dass in meinem Setup das resend mit unter zum Erfolg fuehrt. Es sollte unbedingt an sein - ueber Timer und Anzahl der Wiederhohlungen kann man diskutieren

Wie gesagt, ich habe mal irgendwo (u.a. auch im alten Source des CUL_HM ) gelesen, dass der LAN-Adapter ( also das Hardwareteil ) selbst 1-3 Retrys macht, ohne auf LAN-Seite darüber Feedback zu geben. Außerdem werden wohl Resends von fhem ignoriert, wenn sie identisch mit dem vorherigen cmd sind. Also Dublettenprüfung.

 

Evtl bekomme ich ein leih-TC  - dann wird es mit dem Testen einfacher fuer mich ;-)

Ist das eine Info oder eine Anfrage? :)

Ich könnte mal mit meiner Schatzmeisterin darüber reden, einen der noch fehlenden TCs schon jetzt zu ordern und per Umweg über dich laufen zu lassen. Bzw. wo bist du denn wohnhaft?
 
Gruß

Carsten

[Carsten]

Am Montag, 1. Oktober 2012 09:36:35 UTC+2 schrieb Martin:

Hallo nochmal,

kurze Rückmeldung:

Habe die vorgeschlagene Änderung vorgenommen und gerade nochmal ein bißchen rumgetestet. Da die cmds erfahrungsgemäß aber nur nach einem 8670-Event angenommen werden, habe ich das ProcessCmdStack in eben diesen Zweig verschoben.

Jetzt funktioniert die Kommunikation wieder ungefähr so zuverlässig ( ca. 50:50 ) wie vorher.

Nach meinen Beobachtungen hat bei mir bisher noch kein Resend funktioniert. Bisher kam entweder das erste cmd an oder es folgten Resend Nr 2, Resend Nr.3 und dann Missing_Ack.

An einigen Stellen verhält sich das System unerwartet.

Es kam z.B. vor, dass der Stack für ein TC irgendwie gar nicht mehr abgearbeitet wurde, während der andere funktionierte. Nach shutdown restart lief es wieder. Als ob sich der cmdstack aufgehängt hätte.

Außerdem wundert mich sowas hier:

2012-10-02 00:48:43 HMLAN HMLAN1 RCV L:0C N:F1 F:86 CMD:70 SRC:wz_Heizung DST:broadcast 00CE3D (WeatherEvent TEMP:20.6 HUM:61) (,WAKEMEUP,BCAST,RPTEN)
2012-10-02 00:48:43 HMLAN HMLAN1 SND L:09 N:1B F:A1 CMD:12 SRC:CB0906 DST:wz_Heizung (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012-10-02 00:48:43 CUL_HM wz_Heizung T: 20.6 H: 61
2012-10-02 00:48:43 CUL_HM wz_Heizung measured-temp: 20.6
2012-10-02 00:48:43 CUL_HM wz_Heizung temperature: 20.6
2012-10-02 00:48:43 CUL_HM wz_Heizung humidity: 61
2012-10-02 00:48:45 CUL_HM wz_Heizung resend nr 2
2012-10-02 00:48:47 HMLAN HMLAN1 SND L:10 N:1C F:A0 CMD:01 SRC:CB0906 DST:wz_Heizung 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000 PEER_CHANNEL:00 PARAM_LIST:05) (,BIDI,RPTEN)
2012-10-02 00:48:47 CUL_HM wz_Heizung MISSING ACK
2012-10-02 00:49:03 HMLAN HMLAN1 RCV L:0B N:F1 F:A2 CMD:58 SRC:wz_Heizung DST:wz_Stellantrieb 0000 (ClimateEvent CMD:00 ValvePos:0) (,WAKEMEUP,BIDI,RPTEN)
2012-10-02 00:49:03 CUL_HM wz_Heizung actuator: 0 %
2012-10-02 00:49:03 HMLAN HMLAN1 RCV L:0E N:F1 F:82 CMD:02 SRC:wz_Stellantrieb DST:wz_Heizung 0101000034 (ACK_STATUS CHANNEL:01 STATUS:00 UP:0 DOWN:0 LOWBAT:0 RSSI:-52) (,WAKEMEUP,RPTEN)

fhem sendet ein wakeup, versucht es noch ein zweites Mal und ohne, dass ein Ack vom TC auftaucht, wird versucht, das Cmd abzusetzen. Danach dann ein Missing Ack, von dem ich nicht weiß ob er zum Wakeup oder zum Wert gehört.

Das muss ich mir aber nochmal mit mehr Zeit in Ruhe anschauen. Jedenfalls funktioniert die neue Version bei mir jetzt mindestens so gut wie die alte und darf darum jetzt live bleiben. ;)

Vielen Dank für Deine Unterstützung!

Gruß

Carsten

[Martin]

Hallo Carsten,

habe inzwischen gelernt welche rx_modes es bei HM gibt
TC reagiert auf config und auf wakeup.

Config und wakeup glaube ich mittlerweile zu verstehen und kann es einbauen (reparieren)
Ausserdem werde ich einen entsprechenden Parameter einfuehren - TC ist da ja kein Einzelfall. Die Steuerung wird demnach voraussichtlich in den common Bereich wandern.


Dann gibt es noch "burst" - z.B. bei winmatic, keymatic und smoke detector. Wie burst funktioniert weiss ich noch nicht.... tips?

Gruss
Martin

[Carsten]

Hallo,

habe inzwischen gelernt welche rx_modes es bei HM gibt
TC reagiert auf config und auf wakeup.

Config und wakeup glaube ich mittlerweile zu verstehen und kann es einbauen (reparieren)
Ausserdem werde ich einen entsprechenden Parameter einfuehren - TC ist da ja kein Einzelfall. Die Steuerung wird demnach voraussichtlich in den common Bereich wandern.

Das klingt vielversprechend! Wenn ich irgendwie hilfreich sein kann, sag Bescheid.
 

Dann gibt es noch "burst" - z.B. bei winmatic, keymatic und smoke detector. Wie burst funktioniert weiss ich noch nicht.... tips?

Habe bisher keins dieser Geräte. Rauchmelder sollen irgendwann mal kommen.

Das einzige, was ich dazu kenne ist dieser Eintrag in den ELV-FAQs: http://www.elv.de/controller.aspx?cid=824&detail=10&detail2=3516

Aber ich nehme an, da bist du schon weiter. :)

Gruß

Carsten

[Steffen]

Hallo! 

Seit update fhem gestern(was ich nie wieder tun werde) was ja viele Änderungen in Sachen Fhem und HM-CC-TC  gebracht hatte, nimmt mein HM-CC-TC keine befehle entgegen und reagiert nicht mehr auf befehle von Fhem:-(.

Vor dem Update lief wirklich alles super und jetzt leider gar nichts mehr, habe schon ein Reset durchgeführt und neu gepairt, wird auch gefunden und das wars dann:-(

Habe mal ein Bild vom HM-CC-TC angehängt nach dem update, vielleicht hat ja jemand eine Ahnung warum es jetzt so verrückt spielt???

Mfg Steffen

[dou...@gmx.de]

...updatefhem sollte doch ein Backup angelegt haben. 

Spiel das doch einfach wieder ein ;-)

[Steffen]

danke, so habe ich es gemacht und schon ist wieder alles in Ordnung...:-)

nie wieder updatefhem;-)

[Martin]

Hallo Carsten,

anbei eine neue Version - kannst du sie mal testen?
Bei meinem leih-TC funktioniert es mit Anlernen sehr gut - aber mit wakeup schlecht. Auch die alten Versionen gehe nicht gut - und selbst HM windows SW hat viele Probleme
Wenn du den "normalzustand" abnehmen kannst, versuche ich darauf aufzubauen

Gruß
Martin

[Martin]

Die vielen Wiederholungen sind nur zum test, die bleiben nicht!

[Carsten]

Hallo,

habe gerade mal auf die Schnelle rumprobiert. Es funktioniert teilweise, aber jetzt werden die Befehle ja immer sofort gesendet und nicht abhängig von einer Meldung des TCs. Ob es klappt, scheint derzeit davon abzuhängen, ob eine der 30 Wiederholungen zufällig in einen Empfangsslot des TCs fällt. Das muss aber interessanterweise gar nicht nach einer 8670-Meldung sein, sondern teilweise werden Meldungen scheinbar wahllos mittendrin akzeptiert.

Unterm Strich würde ich sagen, dass die Erfolgsrate derzeit schlechter ist, als in der "Original"-Version.

Am Mittwoch, 3. Oktober 2012 19:45:33 UTC+2 schrieb Martin:

[Martin]

Hi,

hm - ein Update Problem.
der TC hatte bisher eine Sonderloesung ist aber nicht der einzige (wenn auch wohl der wichtigste) der auf wakeup reagiert. Um die Gruppe der 'Wakeup' Kandidaten festzulegen habe ich ihnen einen Parameter verpasst.
Wenn du rxType auf 'wakeup' setzt sollte nur nach wakeup gesendet werden.
Sorry, haette daran denken sollen, dass es nach upgrade nicht definiert ist.
Bei neudefinition - oder wenn du anlernen druckst (also ok fuer ~10 sec) wird der Parameter korrigiert.

Kannst du noch eine Versuch machen?
Also wenn die neue SW laeuft anlernen druecken => parameter werden korrigiert
Dann Werte setzen - hoffentlich alles wie im Orginal.

Ich denke mal nach, ob ich den Upgrade noch ohne UserAktion hinbekomme

Danke
Martin

[Christoph Zimmermann]

Hallo,

wie genau ist die Definition der TCs in der FHEM.cfg anzupassen und mit welcher Version kann man nun arbeiten? Oder hilft nur ein Downgrade des Moduls?
Ein Neupairen kann ich leider von der Ferne nicht durchführen und wenn es die bessere Hälfte mitbekommt, dass die Heizung nicht geht, bin ich nen Kopf kürzer.

Für Hilfe wäre ich dankbar.

Viele Grüße

Christoph

[Carsten]

Wenn du rxType auf 'wakeup' setzt sollte nur nach wakeup gesendet werden.
Sorry, haette daran denken sollen, dass es nach upgrade nicht definiert ist.
Bei neudefinition - oder wenn du anlernen druckst (also ok fuer ~10 sec) wird der Parameter korrigiert.

Kannst du noch eine Versuch machen?
Also wenn die neue SW laeuft anlernen druecken => parameter werden korrigiert
Dann Werte setzen - hoffentlich alles wie im Orginal.

Hallo, da ich gerade auch nicht daheim bin, habe ich vom Handy aus über VPN das Attribut "rxmode" auf "wakeup" gesetzt. Jetzt sendet er wieder nur nach vorheriger Message. Da die Verbindung hier ziemlich langsam ist, kann ich nicht so wahnsinnig viel testen, aber 2 von 3 Versuchen haben geklappt. Da das Sendeverhalten der Originalversion entspricht ( mit mehr Resends ), sollte es jetzt wieder mindestens so gut funktionieren wie zuvor.

Würde er die Werte denn jetzt auch nach einer Stellantriebssteuerung senden. Da kommt ja auch ein Wakemeup aber mit dst=<actuator> statt broadcast. Das ist in der Originalversion auch so, hat aber nach meinen Beobachtungen nie geklappt.

@Christoph: Wenn du die Version von weiter oben nimmst und das Attribut "rxmode" der Thermostaste händisch auf "wakeup" setzt, sollte es demnach mindestens wieder so zuverlässig sein, wie in der alten Version.

[Christoph Zimmermann]

Danke für die Info. Bin jetzt aber einfach auf die alte SVN Version (vor 1906) und werde das ganze mal am Wochenende richtig machen. Hauptsache der Haussegen hängt nicht schief... ;)

[Martin]

Carsten,
Danke - ich versuche die Version heute Abend einzulagern, damit es wieder funktioniert.
Das mit den verschiedenen wakeup werden ich mir ansehen.
Leider funktioniert es mit meinem Leihgeraet nicht so gut- habe es erst seit ein paar Tagen zum Testen.
Ich warte noch auf ein paar kleine Antworten... -aber der TC hat dann prio

Gruss
Martin

[Martin]

habe meinen Fehler erkannt. Der wakeup mode funktioniert nur, wenn auch ein VD angelernt wurde. Steht ja in der Anleitung. Daher meine Probleme.

[dou...@gmx.de]

wo wir gerade bei Software sind: ich habe noch nie etwas bescheideneres als diese Google Groups gesehen. Das musste jetzt raus.

War gerade dabei zu schreiben, als alles gelöscht wurde, weil neue Nachricht oder so...

Aus dem Handbuch Seite 17:

Sobald der TC an einen Fenster-/Türkontakt angelernt ist, erhöht dieser die Empfangsbereitschaft, um sofort auf ein Öffnen des Fensters reagieren zu können. Effekt: Batterielebensdauer sinkt.

Das Anlernen an den VD sollte eigentlich die normale Kommunikation nicht beeinflussen, weil der TC vom VD nichts empfangen muss. 

Nach meinem Verständnis (Achtung Vermutung) ist der TC so lange im Koma, bis er was sagen will - und dann hört er auch zu. 

Aber ich denke das wisst ihr besser :-)

VG Ralf

[Martin]

Sobald der TC an einen Fenster-/Türkontakt angelernt ist, erhöht dieser die Empfangsbereitschaft, um sofort auf ein Öffnen des Fensters reagieren zu können. Effekt: Batterielebensdauer sinkt.

Das Anlernen an den VD sollte eigentlich die normale Kommunikation nicht beeinflussen, weil der TC vom VD nichts empfangen muss. 

Nach meinem Verständnis (Achtung Vermutung) ist der TC so lange im Koma, bis er was sagen will - und dann hört er auch zu. 

nun - meiner immer noch nicht.
Seite 18
Sobald ein Tür-Fenster-Kontakt bzw. ein Fenster-Drehgriffkontakt an den Wandthermostat angelernt wurde, aktiviert dieser seinen WAKE-ON-RADIO-MODE, damit die Ereignismitteilungen die vom Tür-Fenster-Kontakt bzw. Tür-Fenster-Drehgriff gesendet werden, empfangen werden können. Dies hat zu Folge dass der Stromverbrauchs des Gerätes ansteigt und dadurch die Batterielebensdauer gesenkt wird.

[dou...@gmx.de]

Nur zur Sicherheit: der HM-CC-VD ist der Stellantrieb für die Heizung (Empfänger). Nicht der Tür-/Fensterkontakt (Sender), oder hab ich deine Bemerkung falsch verstanden? 

[Carsten]

nun - meiner immer noch nicht.
Seite 18
Sobald ein Tür-Fenster-Kontakt bzw. ein Fenster-Drehgriffkontakt an den Wandthermostat angelernt wurde, aktiviert dieser seinen WAKE-ON-RADIO-MODE, damit die Ereignismitteilungen die vom Tür-Fenster-Kontakt bzw. Tür-Fenster-Drehgriff gesendet werden, empfangen werden können. Dies hat zu Folge dass der Stromverbrauchs des Gerätes ansteigt und dadurch die Batterielebensdauer gesenkt wird.

-VD ist aber kein TFK.

Hört der TC denn gar nicht oder nur schlecht? Schlecht hören tut er bei mir auch. Das ist ja gerade das Problem.

Wenn er gar nicht hört: Kannst du ihn mit der Menü-Taste auf Cent stellen? Cent steht nur zur Verfügung, wenn das Pairing geklappt hat.

[Martin]

-VD ist aber kein TFK.

ok - der Vergleich war nicht fair - der TFK ist an der 'eingabe' der VD an der Ausgabe

Hört der TC denn gar nicht oder nur schlecht? Schlecht hören tut er bei mir auch. Das ist ja gerade das Problem.

hört garnicht - ausser wen ich ihn ueber Konfig betreibe - dann habe ich keine Probleme

Wenn er gar nicht hört: Kannst du ihn mit der Menü-Taste auf Cent stellen? Cent steht nur zur Verfügung, wenn das Pairing geklappt hat.

ja, cent kann ich einstellen. Ich kann auch das Pairing auslesen - über anlernen, wie gesagt. Aber nach dem wakeup kommt nichts
Ich betreibe ihn an einer 7390 - habe gehört, dass es mit einer strawberry funktioniert - mit den gleiche files!
Habe mal an der FB gemessen und im wireshark analysiert - die 'have Data' werden alle wieder 1:1 empfangen - d.h. irgendjemand reflektiert sie. Wenn ich mit Anlernen arbeite passiert keine einzige Reflektion.

[Carsten]

ja, cent kann ich einstellen. Ich kann auch das Pairing auslesen - über anlernen, wie gesagt. Aber nach dem wakeup kommt nichts
Ich betreibe ihn an einer 7390 - habe gehört, dass es mit einer strawberry funktioniert - mit den gleiche files!
Habe mal an der FB gemessen und im wireshark analysiert - die 'have Data' werden alle wieder 1:1 empfangen - d.h. irgendjemand reflektiert sie. Wenn ich mit Anlernen arbeite passiert keine einzige Reflektion.

Hmm... Bei mir läuft FHEM auch auf einer 7390. Funktioniert zwar bei weitem nicht zu 100 %, aber prinzipiell funktionierts. Mitgesnifft habe ich noch nicht.

Ne Erdbeere kenn ich nicht. Ne Himbeere hab ich hier, aber die ist nicht für fhem gedacht. 

[dou...@gmx.de]

...gleiche Hardware hier. FB7390, 2xCUL, 2xCUNO, 2xRPi, 1xCOC, 1x HM-LAN Adapter

Wenn ich irgendwas tun kann um zu helfen, lasst es mich bitte wissen! (Ausser programmieren :-) )

[Steffen]

Biete meine Hilfe auch gleich mal, vielleicht zum Testen von Hardare...Qnap-ts-119p, 1xHM-LAN, 2xHM-CC-TC, 3xHM-CC-VD

Mfg Steffen

[Martin]

Hi

vielen Dank fuer die angebotene Hilfe.
Ich habe weder eine Erdbeere noch Himbeere :-(. Behauptet wuerde der erfogreiche Versuch auf der Erdbeere... egal.
Das grosse Problem ist aktuell die Steuerung des TC.
Zusammenfassung:
- der neuste Stand ist auf SVN.
- Zu beachten ist, dass die Steuerung der 'Sendeverzoegerung' ueber den Parameter rxType erfolgt. Es gibt 2 Schluesselwoerter 'wackeup' und 'config'.
  + fuer den TC sollte man beide setzen, ',' getrennt also 'wakeup,config'
  + der Parameter wird automatisch gesetzt, wenn man anlernen drueckt
- der TC sollte eigentlich wie 'vor' bedienbar sein

Stand bei mir (7390):
- habe ein Set TC/VD zum Testen.
  + Programmieren funktioniert ohne Probleme, wenn ich Daten mit config (anlernen) zu TC uebertrage
  + Ich habe es noch nie geschafft, Daten bei Wakeup zu uebertragen
- das Timing von config und wakeup habe ich geprueft - zu langsam ist meine 7390 nicht.
- Das Pairing TC/VD scheint nicht komplett zu funktionieren, es startet aber stoppt nach einem Datenrequest des TC

Fragen:
- hat noch jemand Probleme mit dem TC und der heutigen SW? mit welchen Server?
- bei wem funtioniert es wie gewohnt (also 50:50)? und mit welchem server?
 + Bitte mit angeben: ist ein sender (fensterkontakt,...) mit dem TC gepairt
- kann jemand das Anlernen TC <-> VD loggen?
- kann jemand die erfolgreiche Datenuebertragung zum TC im Wakeup Fall am 7390 mitloggen?

Vielen Dank
Martin

[Carsten]

Hallo,

Paring von TC und VD ( und RHS ) funktioniert bei mir nur, wenn der TC zu dem Zeitpunkt noch nicht an FHEM angelernt ist. Sonst gibts NOKs.
Stand bei mir:
Bad: 1 TC, 1 VD, 1 RHS.
WoZi: 1 TC, 1 VD.

TCs jeweils mit VD ( und RHS ) gepairt. Anschließend mit fhem.
Server: FB7390 mit der Version von fhem
Adapter: HMLAN
10_CUL_HM-Version: Die hier aus dem Thread

Erfolgsquote gefühlt wie immer 50:50, wobei nicht jeder zweite Versuch klappt, sondern eher so mal 5 in Folge und dann 5 nicht.
Habe das Gefühl, dass der TC im Bad etwas williger ist, als der im WoZi.

Pairing kann ich auf die Schnelle nicht loggen, aber hier mal ein erfolgreiches set desired-temp:

2012-10-05 07:55:34 CUL_HM bd_Heizung desired-temp 20.5
2012-10-05 07:56:26 HMLAN HMLAN1 RCV L:0C N:65 F:86 CMD:70 SRC:bd_Heizung DST:broadcast 00E155 (WeatherEvent TEMP:22.5 HUM:85) (,WAKEMEUP,BCAST,RPTEN)
2012-10-05 07:56:26 HMLAN HMLAN1 SND L:09 N:5C F:A1 CMD:12 SRC:CB0906 DST:bd_Heizung (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012-10-05 07:56:26 CUL_HM bd_Heizung T: 22.5 H: 85
2012-10-05 07:56:26 CUL_HM bd_Heizung measured-temp: 22.5
2012-10-05 07:56:26 CUL_HM bd_Heizung temperature: 22.5
2012-10-05 07:56:26 CUL_HM bd_Heizung humidity: 85
2012-10-05 07:56:26 HMLAN HMLAN1 RCV L:0A N:5C F:80 CMD:02 SRC:bd_Heizung DST:CB0906 00 (ACK) (,RPTEN)
2012-10-05 07:56:27 HMLAN HMLAN1 SND L:0C N:5D F:A0 CMD:11 SRC:CB0906 DST:bd_Heizung 020229 (SET CHANNEL:02 VALUE:29) (,BIDI,RPTEN)
2012-10-05 07:56:27 HMLAN HMLAN1 RCV L:0E N:5D F:80 CMD:02 SRC:bd_Heizung DST:CB0906 0102290038 (ACK_STATUS CHANNEL:02 STATUS:29 UP:0 DOWN:0 LOWBAT:0 RSSI:-56) (,RPTEN)
2012-10-05 07:56:27 CUL_HM bd_Heizung desired-temp-ack: 20.5
2012-10-05 07:56:27 CUL_HM bd_Heizung desired-temp: 20.5
2012-10-05 07:56:46 HMLAN HMLAN1 RCV L:0B N:65 F:A2 CMD:58 SRC:bd_Heizung DST:bd_Stellantrieb 0000 (ClimateEvent CMD:00 ValvePos:0) (,WAKEMEUP,BIDI,RPTEN)
2012-10-05 07:56:46 CUL_HM bd_Heizung actuator: 0 %
2012-10-05 07:56:46 HMLAN HMLAN1 RCV L:0E N:65 F:82 CMD:02 SRC:bd_Stellantrieb DST:bd_Heizung 0101000032 (ACK_STATUS CHANNEL:01 STATUS:00 UP:0 DOWN:0 LOWBAT:0 RSSI:-50) (,WAKEMEUP,RPTEN)
2012-10-05 07:56:46 CUL_HM bd_Stellantrieb actuator: 0 %
2012-10-05 07:56:46 CUL_HM bd_Stellantrieb motor: ok
2012-10-05 07:56:46 CUL_HM bd_Stellantrieb battery: ok

[dou...@gmx.de]

Am Freitag, 5. Oktober 2012 08:08:47 UTC+2 schrieb Carsten:

Hallo,

Paring von TC und VD ( und RHS ) funktioniert bei mir nur, wenn der TC zu dem Zeitpunkt noch nicht an FHEM angelernt ist. Sonst gibts NOKs.
Stand bei mir:
Bad: 1 TC, 1 VD, 1 RHS.
WoZi: 1 TC, 1 VD.

Das kann ich bestätigen. Reihenfolge IMMER erst alle HM Devices an den TC anlernen, und als letzten Schritt dann an fhem. Das fhem HM-Device ist bei mir ein CUNO.

Hier sind inzwischen 10x HM-CC-TC und 11x HM-CC-VD vorhanden, was das Ganze etwas unübersichtlich macht (alle mit fhem gepairt).

Aktuell mit der Version via updatefhem; Erfolgsrate (z.B. set desired temp oder set controlMode) 0%

CommandAccepted bleibt bei einem Datum aus dem letzten Monat.

VG
Ralf

[Hermann]

Hallo,

bei mir funktioniert die neue Version endlich wieder wie vorher.
FritzBox 7390
2 x cul (HM + FS20)
HM-CC-TC und HM-CC-VD vorher gepairt, dann an fhem angelernt

Eine Frage dazu. Nach jeden updatefhem oder Neustart von fhem muss ich jetzt die HM-CC-TC neu an fhem anlernen damit rxType mit  'wackeup' und 'config' gesetzt wird.
Nach dem Update tauchen meine HM-CC-TC unter "HM-CC-TC" in fhem auf und nach den erneuten anlernen unter "thermostat".

Besteht die Möglichkeit rxType automatisch auf ´wackeup´ und ´config´zu setzen ?

Ich logge auch gerne etwas mit wenn jemand einen Anfänger erklärt wie.

Hermann

[Hermann]

Hallo,
Ich habe mal versucht mittzuloggen nachdem ich einen Befehl mit desired temp abgesetzt habe.

2012.10.05 08:53:49 2: CUL_HM set Temp_AZ desired-temp 22.0
2012.10.05 08:53:49 4: HTTP FHEMWEB:192.168.x.xx:49453 GET /fhem?detail=Temp_AZ
2012.10.05 08:53:49 4: /fhem?detail=Temp_AZ / RL: 4081 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2012.10.05 08:53:55 4: HTTP FHEMWEB:192.168.x.xx:49453 GET /fhem?room=Log
2012.10.05 08:53:55 4: /fhem?room=Log / RL: 1649 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2012.10.05 08:53:57 4: HTTP FHEMWEB:192.168.x.xx:49453 GET /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log
2012.10.05 08:53:57 4: /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log / RL: 15656 / text/html; charset=UTF-8 / Content-Encoding: gzip
 / 
2012.10.05 08:54:33 4: RCV L:0C N:E4 F:86 CMD:70 SRC:Temp_AZ DST:broadcast 00E63C (WeatherEvent TEMP:23 HUM:60) (,WAKEMEUP,BCAST,RPTEN)
2012.10.05 08:54:33 4: SND L:09 N:04 F:A1 CMD:12 SRC:F11034 DST:Temp_AZ  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012.10.05 08:54:33 4: RCV L:0A N:04 F:80 CMD:02 SRC:Temp_AZ DST:F11034 00 (ACK) (,RPTEN)
2012.10.05 08:54:33 4: SND L:0C N:05 F:A0 CMD:11 SRC:F11034 DST:Temp_AZ 02022C (SET CHANNEL:02 VALUE:2C) (,BIDI,RPTEN)
2012.10.05 08:54:33 4: RCV L:0E N:05 F:80 CMD:02 SRC:Temp_AZ DST:F11034 01022C004F (ACK_STATUS CHANNEL:02 STATUS:2C UP:0 DOWN:0 LOWBAT:0 RSSI:-79) (,RPTEN)

Ich hoffe dass ich damit helfen kann.

Übrigens sind auch nach jeden abspeichern der global conig die rxType Einstellungen weg :-(

Hermann

[dou...@gmx.de]

Am Freitag, 5. Oktober 2012 08:51:40 UTC+2 schrieb Hermann:

Hallo,

Nach dem Update tauchen meine HM-CC-TC unter "HM-CC-TC" in fhem auf und nach den erneuten anlernen unter "thermostat".

Ich hab gerade mal den TC von meinem Bür neu an fhem angelernt. Dieser steht jetzt nicht mehr (wie auch zuvor bemerkt) in der HM-CC-TC Liste, sondern in "thermostat".

Ein set controlMode party oder ein set desired temp wird vom TC jedoch ignoriert.

Hermann: mit welcher Einstellung generierst du diese ausführlichen logs?

VG
Ralf

[Hermann]

Hallo,

Einfach in der Globalen confuguration (fhem.cfg) den Wert von

attr global verbose 3 von "3" auf  "4" setzen.

Hermann

[Carsten]

Eine Frage dazu. Nach jeden updatefhem oder Neustart von fhem muss ich jetzt die HM-CC-TC neu an fhem anlernen damit rxType mit  'wackeup' und 'config' gesetzt wird.
Nach dem Update tauchen meine HM-CC-TC unter "HM-CC-TC" in fhem auf und nach den erneuten anlernen unter "thermostat".

Versuch mal nach dem Ändern des Attributs ein "Save" + Enter in der Kommandozeile.
 

Besteht die Möglichkeit rxType automatisch auf ´wackeup´ und ´config´zu setzen ?

Habs heute morgen noch getestet: OK-Button lange drücken ( bis der Countdown kommt ). Danach ists im fhem automatisch geändert. ( Anschließend "Save"+Enter ) .

[Martin]

erst mal danke

1) der TC erhaelt jetzt, wie alle anderen auch, eine subType und hmClass - war nur eine Bereinigung. Die Darstellung im Webinterface ist davon abgeleitet.
2) den automatischen update des rxType: der Parameter ist neu. Wenn man speichertist er das naechste mal gesetzt.Er wird auch automatisch gesetzt bei jedem Anlernen oder bei neuinstallation.
Einen automatischen Update der bestehenden Devices habe ich nicht - das wuerde ja saemtliche Type betreffen...
Vorschlag -
a) entweder von Hand
b) einmal bei jeden TC anlernen Druecken
=> speichern nicht vergessen, fertig

@Hermann: werde es prufen - nach dem Speichern muss rxType erhalten bleiben - ist ein 'normales' attribut und muss wie alle gespeichert werden.

@Ralf: die neue Version funktioniert nicht und die alte schon? Kannst du von beiden Traces schicken?

Anmerkung zum Protokoll:
Kommte es ja noch nicht testen - aber das 'have data' wird immer geschickt ausser bei displayTemp...
scheint also auch ohne zu gehen

[Carsten]

Hallo,

was mir noch aufgefallen ist:

Ich habe einen Dummy TC. Mit Attribut Dummy 1
Der hat noch keine konkrete Funktion. War mittelfristig dazu gedacht, die gewünschten Temperaturlisten irgendwo abzulegen und regelmäßig an alle echten TCs zu pushen und evtl. noch die Durchschnittstemperatur anzuzeigen.

Mit der aktuellen Version versucht FHEM auch, an den Dummy Werte zu senden. Sollte das nicht durch das Dummy-Attribut unterbunden werden?

Gruß

Carsten

[Rudolf Koenig]

> Mit der aktuellen Version versucht FHEM auch, an den Dummy Werte zu senden.
> Sollte das nicht durch das Dummy-Attribut unterbunden werden?

Ein dummy sendet nix, weiss ja auch nie wie und wohin. Natuerlich kann man
aber ein dummy per notify mit einem echten Geraet verbinden. Um diese
Verbindung zu unterbinden muss man das disable Attribut beim notify setzen.

[Carsten]

Ein dummy sendet nix, weiss ja auch nie wie und wohin.  Natuerlich kann man
aber ein dummy per notify mit einem echten Geraet verbinden. Um diese
Verbindung zu unterbinden muss man das disable Attribut beim notify setzen.

Hallo,

ich weiß nicht, ob wir uns richtig verstehen.

Ich habe mir einen Dummy-TC angelegt (zumindest war ich der Meinung) mit
define dmy_Heizung CUL_HM F00BAA
atrr dmy_Heizung model HM-CC-TC
attr dmy_Heizung dummy 1

Eigentlich wie gesagt nur zum Testen, weil ich in einem "echten" Dummy ( also define dmy_Heizung dummy ) ja nur einen Wert setzen kann und dachte, dass ich so vielleicht die Möglichkeit habe, mir quasi einen virtuellen TC mit allen benötigten Werten anzulegen.

Ich war auch der Meinung, dass das funktionierte. Gestern habe ich aber ein Script ausgeführt, dass auch im dummy die Templist setzt und dann in den Events gesehen, dass fhem versucht, den Dummy zu wecken. Das war sonst nicht so, liegt aber bei genauerer Überlegung vermutlich daran, dass in der alten Version auf ein Wakemeup vom TC gewartet wurde, das vom dummy natürlich nie kam. Jetzt wartet der Dummy nicht mehr, weil ich für ihn keinen rxmode gesetzt habe.

Hab ich das Dummy-Attribut missverstanden?

[Rudolf Koenig]

> Hab ich das Dummy-Attribut missverstanden?

Nein, ich habe nur "hab ein dummy angelegt" mit
define XXX dummy
und nicht mit
define XXX CUL_HM ...
attr xxx dummy 1
assoziiert.

[Martin]

mit dummy habe ich in CUL_HM nix am Hut. Das sollte in fhem.pl abgefangen werden und von allen Sendeaktivtaeten im Modul unabhaengig sein.
Ich muss mal in fhem.pl nachsehen - falls es Rudi nicht aus dem Kopf weiss :-)

[Rudolf Koenig]

> Ich muss mal in fhem.pl nachsehen - falls es Rudi nicht aus dem Kopf weiss

Zum Daten loswerden sollten die Module wie CUL_HM IOWrite verwenden, und dieser
testet auf ignore bzw. auf dummy.

[dou...@gmx.de]

So....gerade die neue Version via updatefhem gezogen und mal bei mir im Büro den "ok" Button am TC lange gedrückt.

Dann versucht ein set controlMode party abzusetzen.

Leider ohne Erfolg.

Im Telnet Window:

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in bitwise or (|) at ./FHEM/10_CUL_HM.pm line 1833.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in bitwise or (|) at ./FHEM/10_CUL_HM.pm line 1833.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 2778.

[Martin]

dein TC sollte in den Anlrenmode gekommen sein (blinken den LED). Nach dem Loslassen kommt die deviceInfo.
Ich denke es sind 10 sec bein TC
Hast du so lange gedrueckt?
in rxType sollte dann ein Wert stehen - tut er offensichtlich nicht.

Die Fehlermeldung werde ich korrigieren, klar

2.Punkt: Falls du vor hattest die Daten ueber config zu setzen musst du das Kommando erst absetzen und dann Anlernen. Dann werden die Daten uebertragen.

[littlebilly]

Wenn ich

ein set controlMode manual abzusetze kommt folgende Fehlermeldung
"manualinvalid for controlMode select one of auto central manual party"

d.h. manual wird nicht angenommen!

Gruss Billy

[dou...@gmx.de]

Korrekt! Ist bei mir auch (aber schon seit gestern oder so). :-)

[fhem-hm-knecht]

nicht gestern, sondern ging noch nie

[littlebilly]

Zwei Dinge,

1. seit gestern kommt diese Fehlermeldung

2. Die Mode (remote) Umschaltung hat bei mir auch noch nie funktioniert.

    Weder manual, noch auto, noch party

Billy

[Martin]

Das mit den abgewiesenen Parametern hab ich - wird korrigiert.
Alle '0' werte sind betroffen.
Wird repariert

[Martin]

Korrektur ist drin - Version 1929