HM-CC-TC MISSING-ACK bei Einstellen desired-temp

[kohrti]

Hallo,

ich habe dieses Thema in einem anderen Thread gepostet und da dort kein Feedback kam erstelle ich hiermit ein neues Thema. Ich hoffe das ist in Ordnung.

Nun zum Problem.

Ich verwende den CUL (CUNO) mit FB7390 und aktuellem fhem Server. Ich habe mir viele andere Threads durchgelesen und es heißt, dass die Funktionalität schon da sein soll. Bei mir funktioniert das Setzen der desired-temp nur 1 von 10 mal (ca.).

Ich erhalte folgendes Log:

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

Jemand aus dem anderen Thred meinte ich solle ein msec genaues Log erstellen. Dazu habe ich leider nichts finden können wie ich das erstellen kann. Auch wurde diese Frage leider nicht im anderen Thread beantwortet (kein Vorwurf, ist wahrscheinlich nur untergegangen).

Ich hoffe, dass der eine oder andere mir weiterhelfen kann.

Vielen Dank,
kohrti

[UliM]

Am Montag, 29. Oktober 2012 18:30:27 UTC+1 schrieb kohrti:

msec genaues Log erstellen. Dazu habe ich leider nichts finden können wie ich das erstellen kann.

attr global mseclog 1

[littlebilly]

Ich hatte deinen Beitrag im anderen Thread gelesen.

Was mich gewundert hatte war deine Aussage:

Der Thermostat ist mit keinem Aktor sondern nur mit fhem verknüpft, Mode: Manual oder Auto.!!!

Was soll dein TC steuern, wenn er mit keinem VD verknüpft ist?

Oder habe ich da was falsch verstanden?

Billy

Am Montag, 29. Oktober 2012 18:30:27 UTC+1 schrieb kohrti:

Hallo,

ich habe dieses Thema in einem anderen Thread gepostet und da dort kein Feedback kam erstelle ich hiermit ein neues Thema. Ich hoffe das ist in Ordnung.

Nun zum Problem.

Ich verwende den CUL (CUNO) mit FB7390 und aktuellem fhem Server. Ich habe mir viele andere Threads durchgelesen und es heißt, dass die Funktionalität schon da sein soll. Bei mir funktioniert das Setzen der desired-temp nur 1 von 10 mal (ca.).

[kohrti]

Hallo,

@Billy
Ich weiß, dass sich das eigentlich verrückt anhört. Ich habe mir das PID Modul geschnappt und für meine Fußbodenheizung angepaßt. Ich kann meine Aktoren nur auf ON/OFF setzen, daher mußte ich eine PWM (Pulsweitenmodulation) einbauen. Jetzt heißt das Modul eben PIDPWM (mit zusätzlicher Begrenzung des I-Anteils). Nun werden die Aktoren nicht direkt über die Thermostate angesteuert, sondern dieses PIDPWM Modul steuert sie. Die Thermostate liefern eigentlich nur die Soll/Ist Temperatur und erlauben die Programmierung der Zeiten. So kam ich zu der Aussage, dass ich keine Aktoren direkt verknüpft habe sodern nur fhem. Mit Manual/Auto meinte ich die Programme die man am Thermostat einstellen kann.

@Uli
Vielen Dank, werde ich gleich ausprobieren und Ergebnisse liefern!

Schöne Grüße,
Kohrti

[UliM]

Hi,

wenn ich das richtig verstanden habe, steht in dem anderen fred zum missing ACK bei desired-temp für HM-TC-CC:
Das timing bei der Kommunikation ist sehr fragil. Es funktioniert z.T. nur, wenn Du am HMLAN bzw CUL hmProtocolEvents auf 3 setzt, z.T. nur, wenn Du es auf <3 setzt.
Vll kannst Du damit etwas testen.
=8-)

[kohrti]

Hallo,

hier habe ich nun die Log Ergebnisse aus dem Event monitor. Leider sieht man da auch nicht mehr, oder übersehe ich irgendwas?
Auf jeden Fall werde ich jetzt mal den Vorschlag von Uli testen und berichten.

VG,
Kohrti

2012-10-29 21:55:45.999 CUL_HM az_Thermostat desired-temp 11.0
2012-10-29 21:55:55.911 CUL_HM sz_Thermostat T: 20.6 H: 55
2012-10-29 21:55:55.911 CUL_HM sz_Thermostat measured-temp: 20.6
2012-10-29 21:55:55.911 CUL_HM sz_Thermostat humidity: 55
2012-10-29 21:56:16.495 CUL_HM gz_Thermostat T: 20.8 H: 52
2012-10-29 21:56:16.495 CUL_HM gz_Thermostat measured-temp: 20.8
2012-10-29 21:56:16.495 CUL_HM gz_Thermostat humidity: 52
2012-10-29 21:56:17.663 CUL_HM ka_Heizkreis3 off
2012-10-29 21:56:17.730 Global global DELETED Timer_ka_Heizkreis3
2012-10-29 21:56:17.981 CUL_HM ka_Heizkreis3 deviceMsg: off (to CUNO)
2012-10-29 21:56:17.981 CUL_HM ka_Heizkreis3 off
2012-10-29 21:56:31.367 CUL_HM Aussentemperatur T: 22.1 H: 48
2012-10-29 21:56:31.367 CUL_HM Aussentemperatur temperature: 22.1
2012-10-29 21:56:31.367 CUL_HM Aussentemperatur humidity: 48
2012-10-29 21:56:33.475 CUL_HM az_Thermostat T: 21.4 H: 55
2012-10-29 21:56:33.475 CUL_HM az_Thermostat measured-temp: 21.4
2012-10-29 21:56:33.475 CUL_HM az_Thermostat humidity: 55
2012-10-29 21:56:37.502 CUL_HM az_Thermostat MISSING ACK
2012-10-29 21:57:49.495 CUL_HM ku_Thermostat T: 21.6 H: 59
2012-10-29 21:57:49.495 CUL_HM ku_Thermostat measured-temp: 21.6
2012-10-29 21:57:49.495 CUL_HM ku_Thermostat humidity: 59
2012-10-29 21:58:00.403 CUL_HM sz_Thermostat T: 20.6 H: 55
2012-10-29 21:58:00.403 CUL_HM sz_Thermostat measured-temp: 20.6
2012-10-29 21:58:00.403 CUL_HM sz_Thermostat humidity: 55
2012-10-29 21:58:30.413 CUL_HM gz_Thermostat T: 20.8 H: 52
2012-10-29 21:58:30.413 CUL_HM gz_Thermostat measured-temp: 20.8
2012-10-29 21:58:30.413 CUL_HM gz_Thermostat humidity: 52
2012-10-29 21:58:32.401 CUL_HM ba_Thermostat T: 22.2 H: 55
2012-10-29 21:58:32.401 CUL_HM ba_Thermostat measured-temp: 22.2
2012-10-29 21:58:32.401 CUL_HM ba_Thermostat humidity: 55
2012-10-29 21:58:33.883 CUL_HM wz_Thermostat T: 22.1 H: 57
2012-10-29 21:58:33.883 CUL_HM wz_Thermostat measured-temp: 22.1
2012-10-29 21:58:33.883 CUL_HM wz_Thermostat humidity: 57
2012-10-29 21:59:00.659 CUL_HM Aussentemperatur T: 22.1 H: 48
2012-10-29 21:59:00.659 CUL_HM Aussentemperatur temperature: 22.1
2012-10-29 21:59:00.659 CUL_HM Aussentemperatur humidity: 48
2012-10-29 21:59:28.690 CUL_HM az_Thermostat T: 21.4 H: 55
2012-10-29 21:59:28.690 CUL_HM az_Thermostat measured-temp: 21.4
2012-10-29 21:59:28.690 CUL_HM az_Thermostat humidity: 55

[kohrti]

Hi,

ich habe nun hmProtocolEvents=0/1/2/3 ausprobiert und keine wesentlichen Änderungen feststellen können. Bei hmProtocolEvents=3 sehe ich nur etwas mehr Informationen, die aber (glaube ich) nicht wirklich hilfreich sind.

Kann es vielleicht daran liegen das ich einen CUNO v2 im Einsatz habe und sich dieser anders verhält als HMLan und CUL?

Gruß,
Kohrti

[kohrti]

Hallo,

hab nochmal darüber nachgedacht. Der einzige Workaround wäre in den PIDPWM Reglern einen Parameter "desired-temp" einzufügen, der dann die "desired-temp" der Thermostate überschreibt falls er angelegt wurde. Nicht schön aber immerhin kann ich dann von der Arbeit aus die Temperatur bestimmen - und zu Hause dann die Thermostate verwenden.

Gibt es denn sonst nichts das ich machen kann?

Das Problem ist doch (irgendwie) dass der Thermostat die "desired-temp" nicht annehmen will. Er schläft normalerweise und wacht alle ca. 3 Min. auf. Dann hat fhem die Gelegenheit etwas zu senden, weil er dann ja wach sein sollte. Und genau dieses Timing ist das Problem. Es wurde ja schon mit Resend usw. gearbeitet soweit ich gesehen habe. In welche Ecke muss ich denn schauen?

Gruß,
Kohrti

[UliM]

Hi,
was willst Du denn eigentlich erreichen?
Wenn Du die desired-temp gesetzt hast, dann....?

Der HM-TC-CC schickt NICHT den Sollwert der Ventilstellung, solange noch kein Ventilstelltrieb HM-CC-VD angelernt ist. Genau daran zahne ich auch, siehe https://groups.google.com/d/topic/fhem-users/ux-Vz-pMi7A/discussion
Da ist wohl noch etwas Entwicklungsarbeit zu tun.
Erster Schritt wäre, dass jemand, der ein HM-CC-VD besitzt, den Funkverkehr beim Anlernen des VD an den TC mitschneidet und hier postet. Das kann dann eventuell als Basis für das pairing eines virtuellen VD dienen. Ob's dann wirklich funktioniert, muss man sehen - wahrscheinlich schickt ja der VD auf jede Nachricht des CC einen ACK, auch den müsste man dann emulieren.

Solange hier niemand diesen Funkverkehr kundtut, geht's nicht weiter.

Es bleibt also spannend :)

Gruß, Uli

[kohrti]

Hallo,

grundsätzlich will ich die Solltemperatur "desired-temp" von fhem einstellen können. Manchmal geht es ja sogar (1 v. 10 Versuchen). Momentan geht es nur über das EInstellrad zuverlässig. 

Mein PIDPWM Regler benötigt die Solltemperatur desired-temp, um dann die aktoren für die Fußbodenheizung zu steuern. Die Aktoren werden von dem Modul gesteuert, nicht von dem Thermostat. Letzteres benutze ich nur als Sensor mit etwas Intelligenz weil man dort ja auch Programme hinterlegen kann für die Solltemperatur desried-temp.
Damit sollen Bewohner die Möglichkeit haben die Heizung im Raum zu beeinflussen, aber ich möchte das auch von Remote tun, daher will ich desried-temp setzen können.

Ich hoffe es ist jetzt etwas klarer, dass NICHT der Thermostat den sollwert schickt sondern MEIN Regler.

Gruß,
Kohrti

Hier noch ein aktuelles Log:
2012-10-29 23:33:10.108 CUL_HM az_Thermostat desired-temp 15.0
2012-10-29 23:33:16.757 CUL CUNO RCV L:0C N:BB F:86 CMD:70 SRC:ku_Thermostat DST:broadcast 00D73A (WeatherEvent TEMP:21.5 HUM:58) (,WAKEMEUP,BCAST,RPTEN)
2012-10-29 23:33:16.881 CUL_HM ku_Thermostat T: 21.5 H: 58
2012-10-29 23:33:16.881 CUL_HM ku_Thermostat measured-temp: 21.5
2012-10-29 23:33:16.881 CUL_HM ku_Thermostat humidity: 58
2012-10-29 23:33:24.450 CUL CUNO RCV L:0C N:4D F:86 CMD:70 SRC:az_Thermostat DST:broadcast 00D637 (WeatherEvent TEMP:21.4 HUM:55) (,WAKEMEUP,BCAST,RPTEN)
2012-10-29 23:33:24.673 CUL CUNO SND L:09 N:64 F:A1 CMD:12 SRC:F11234 DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012-10-29 23:33:24.797 CUL_HM az_Thermostat T: 21.4 H: 55
2012-10-29 23:33:24.797 CUL_HM az_Thermostat measured-temp: 21.4
2012-10-29 23:33:24.797 CUL_HM az_Thermostat humidity: 55
2012-10-29 23:33:28.824 CUL_HM az_Thermostat MISSING ACK


--> Sind denn 124ms genug für den Thermostat nach WAKEUP? Ich mache nochmal ein positives Log um das Timing dafür zu sehen....

[Uwe]

Nun will ich mich hier auch mal mit einklinken (habe das spezielle Thema bis jetzt nur mitgelesen).
Mein Fhem (noch 5.2 aber mit neuer Struktur) läuft auch auf der FB 7390 und ich verwende einen CUNO2. Ich habe 2 CC mit einem bzw. zwei VD in Verwendung und jeweils noch einen Drehgriffkontakt (Threestate). Alles erst einzeln gepaired und dann zu Fhem, damit die CCs auch bei Ausfall von Fhem die VDs ansteuern können.
Mir ist es bis jetzt nur einmal gelungen, den CC zu einer Übernahme einer desired-temp zu bewegen. Was ich bei der Kommunikation der Komponenten nicht verstehe: Der CC registriert sofort eine Veränderung des Status' des Threestate und regelt nach ca. 3 Min. die VDs in Frostschutz. Also muss doch der CC immer lauschen und nicht nur alle drei Minuten - der Threestate sendet ja den Statuswechsel nicht drei Minuten lang - oder?
Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet wie der HMLAN und deshalb der CC die Befehlsumsetzung verweigert. Der CUL/CUNO müsste also nicht sagen: "Hallo CC - ich bin der CUNO und schicke dir mal ein paar Befehle" sondern "Ich bin ein CUNO tue aber so als wäre in ein HMLAN und ..."
Loggen und testen geht bei mir nur alle zwei Wochen, da ich sonst nur per VPN zugreife und auch keine Updates darüber einspiele (schlechte Erfahrungen gemacht).

Am Montag, 29. Oktober 2012 23:34:02 UTC+1 schrieb UliM:

[kohrti]

Hallo Uwe,

Am Montag, 29. Oktober 2012 23:53:59 UTC+1 schrieb Uwe:

Der CC registriert sofort eine Veränderung des Status' des Threestate und regelt nach ca. 3 Min. die VDs in Frostschutz.

Gibt es dazu zufällig ein Log?
Wie siehst du denn, dass es SOFORT angenommen wird?

Ich kenne mich (noch) nicht so gut mit den Messages aus, aber ich wäre jetzt eher davon ausgegangen, dass es ein Timing Problem ist. Evtl. Gibt es ja doch die Möglichkeit dem CC sofort aufzuwecken. Mit einem Log täte man sich leichtes das zu beurteilen. Oder die Experten hier können auf Anhieb was dazu sagen.

Gruß,
Kohrti

[Uwe]

Wie gesagt, momentan bin ich nicht zu Hause. Aber sobald ich das Fenster öffne, wird im Display des CC das "Fenstersymbol" angezeigt. Also muss der CC die Änderung sofort mitbekommen. Ob sich dieses "Lauschverhalten" aber nur auf den Fensterkontakt bezieht, weiß ich auch nicht (wäre mir aber etwas unlogisch).

[kohrti]

Hallo nochmal,

 

Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet wie der HMLAN und deshalb der CC die Befehlsumsetzung verweigert.

--> Also das der Sender Typ irgendwie übermittelt wird? Das können hoffentlich auch die Experten hier sagen. Ansonsten glaube ich auch dass der CUNO gegenüber dem HMLAN sich anders verhält. das ist ja das problem. Entweder das Timing oder das Protokoll oder die Message Inhalte stimmen nicht... so ganz allgemein ausgedrückt.

Gruß,
Kohrti

[Merhan]

Habe mit der neusten Version (5.3 + Update) mit HMLAN, leider auch nur MISSING ACKS

Hier mein Post aus dem anderen Thread:

Die alte Version (5.2) akzeptiert mindestens 50 % der Kommandos. Die neue Version hat leider 0% Erfolg.

Folgende Fehlermeldungen tauchen bei mir in der Konsole auf:

[/opt/share/fhem/FHEM] # Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

Use of uninitialized value in substitution (s///) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 3107.

Version:

# CUL HomeMatic handler

# $Id: 10_CUL_HM.pm 2035 2012-10-28 21:28:41Z martinp876 $

Ideen?

Danke & Grüße,

Merhan

[Uwe]

Sehe ich auch so... für heute erst mal "Gute Nacht".

[Uwe]

Noch 'ne Ergänzung: Logeintrag vom Badfenster:

2012-10-29_13:33:24 Bad_Fenster geschlossen
2012-10-29_13:33:24 Bad_Fenster contact: geschlossen (to Bad_Regler)

Logeintrag vom CC:
2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5 

Also nur 3 Sekunden später.

[kohrti]

Moin Uwe,

wäre es möglich dieses Szenario (CC/Türkontakt) mit folgenden Einstellungen nochmal zu loggen:

attr global mseclog 1
attr global verbose 5

Dann sollten wir die Messages sehen können und ich kann vergleichen was denn bei mir anders ist. Evtl. gibt uns das ja die nötige Info um dem CC Messages schicken zu können.

Danke!

Gruß,
Kohrti

[kohrti]

Folgendes ist noch wichtig:

attr global mseclog 1
attr global verbose 5

im CUL/CUNO attr:
hmProtocolEvents 3

Dann müßtest du alles im Log sehen können.

NEUIGKEITEN (für mich zumindest):

Wenn ich "desired-temp" setze und manuell einmal kurz auf "OK" auf dem Thermostaten drücke funktioniert es. Evtl. hilft das ja dem Problem auf die Spur zu kommen.

[kohrti]

Komisch... jetzt geht das gleiche nicht mehr... Ich probiere weiter...

[Uwe]

Hallo Korthi, kann es erst am WE testen, da keiner da ist, der mir mal das Fenster öffnet. :-) Das funzt per VPN noch nicht.

Uwe

[kohrti]

Das wär doch mal eine Erweiterung für VPN... ;)

[fhem-hm-knecht]

@ Kohrti
ich antworte dir einmal

ich hab mir dein Log angeschaut

2012-10-29 23:33:24.450 CUL CUNO RCV L:0C N:4D F:86 CMD:70
SRC:az_Thermostat DST:broadcast 00D637 (WeatherEvent TEMP:21.4 HUM:55)
(,WAKEMEUP,BCAST,RPTEN)
2012-10-29 23:33:24.673 CUL CUNO SND L:09 N:64 F:A1 CMD:12 SRC:F11234
DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)

Vom eintreffen bis zur Sendung sind es 223ms

da schläft das TC schon wieder.
alles über 205 ms ist ein Problem. wobei die Wandelzeiten bei dir,
cuno->fhem fhem->cuno noch garnicht dabei sind.
Zeitfresser sind:
eingeschaltetes hmProtocolEvents
Filelog

ausprobieren könnest du einmal, mit einer minimal config an den Start
gehen, like

wo nur dein Cuno und ein TC definiert ist ohne Filelog, und sonnst
nix, außer das Fhem selber benötigt.
ob es dann geht.

Hary

On 29 Okt., 23:47, kohrti <christ...@kohrt.org> wrote:
> Hallo,
>
> grundsätzlich will ich die Solltemperatur "desired-temp" von fhem
> einstellen können. Manchmal geht es ja sogar (1 v. 10 Versuchen). Momentan
> geht es nur über das EInstellrad zuverlässig.
>
> Mein PIDPWM Regler benötigt die Solltemperatur desired-temp, um dann die
> aktoren für die Fußbodenheizung zu steuern. Die Aktoren werden von dem
> Modul gesteuert, nicht von dem Thermostat. Letzteres benutze ich nur als
> Sensor mit etwas Intelligenz weil man dort ja auch Programme hinterlegen
> kann für die Solltemperatur desried-temp.
> Damit sollen Bewohner die Möglichkeit haben die Heizung im Raum zu
> beeinflussen, aber ich möchte das auch von Remote tun, daher will ich
> desried-temp setzen können.
>
> Ich hoffe es ist jetzt etwas klarer, dass NICHT der Thermostat den sollwert
> schickt sondern MEIN Regler.
>
> Gruß,
> Kohrti
>
> Hier noch ein aktuelles Log:

> *2012-10-29 23:33:10.108 CUL_HM az_Thermostat desired-temp 15.0*

> 2012-10-29 23:33:16.757 CUL CUNO RCV L:0C N:BB F:86 CMD:70
> SRC:ku_Thermostat DST:broadcast 00D73A (WeatherEvent TEMP:21.5 HUM:58)
> (,WAKEMEUP,BCAST,RPTEN)
> 2012-10-29 23:33:16.881 CUL_HM ku_Thermostat T: 21.5 H: 58
> 2012-10-29 23:33:16.881 CUL_HM ku_Thermostat measured-temp: 21.5
> 2012-10-29 23:33:16.881 CUL_HM ku_Thermostat humidity: 58
> 2012-10-29 23:33:24.450 CUL CUNO RCV L:0C N:4D F:86 CMD:70
> SRC:az_Thermostat DST:broadcast 00D637 (WeatherEvent TEMP:21.4 HUM:55)
> (,WAKEMEUP,BCAST,RPTEN)
> 2012-10-29 23:33:24.673 CUL CUNO SND L:09 N:64 F:A1 CMD:12 SRC:F11234
> DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
> 2012-10-29 23:33:24.797 CUL_HM az_Thermostat T: 21.4 H: 55
> 2012-10-29 23:33:24.797 CUL_HM az_Thermostat measured-temp: 21.4
> 2012-10-29 23:33:24.797 CUL_HM az_Thermostat humidity: 55

> *2012-10-29 23:33:28.824 CUL_HM az_Thermostat MISSING ACK*

>
> --> Sind denn 124ms genug für den Thermostat nach WAKEUP? Ich mache nochmal
> ein positives Log um das Timing dafür zu sehen....
>
> Am Montag, 29. Oktober 2012 23:34:02 UTC+1 schrieb UliM:
>
>
>
>
>
>
>
>
>
> > Hi,
> > was willst Du denn eigentlich erreichen?
> > Wenn Du die desired-temp gesetzt hast, dann....?
>
> > Der HM-TC-CC schickt NICHT den Sollwert der Ventilstellung, solange noch
> > kein Ventilstelltrieb HM-CC-VD angelernt ist. Genau daran zahne ich auch,

> > siehehttps://groups.google.com/d/topic/fhem-users/ux-Vz-pMi7A/discussion

[kohrti]

Hallo Hary,

herzlichen Dank für die Infos, die Gold Wert sind.

Ich habe folgende Konfiguration getestet und dabei verbose=0, FileLogs für den CC aus und hmprotocolevents=0:

attr global autoload_undefined_devices 1
attr global backupdir /var/media/ftp/FHEMBackups
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBtablet has no basicAuth attribute.\
telnetPort has no password/globalpassword attribute.\
Running with root privileges.\
Restart fhem for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\

attr global statefile ./log/fhem.save
attr global userattr icon webCmd
attr global verbose 0

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

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone basicAuth Y2tvaHJ0OjM5NTYqS2Vs
attr WEBphone smallscreen 1

define WEBtablet FHEMWEB 8085 global
attr WEBtablet touchpad 1

define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Wetter

define CUNO CUL 192.168.2.34:2323 1234
attr CUNO rfmode HomeMatic
attr CUNO room CUL_HM

define telnetPort telnet 7072 global

define az_Thermostat CUL_HM 1D6A43
attr az_Thermostat actCycle 000:10
attr az_Thermostat actStatus alive
attr az_Thermostat devInfo 00FFFF
attr az_Thermostat firmware 2.1
attr az_Thermostat hmClass receiver
attr az_Thermostat model HM-CC-TC
attr az_Thermostat protCmdDel 11
attr az_Thermostat protLastRcv 2012-10-30 17:50:39
attr az_Thermostat protResndCnt 8
attr az_Thermostat protResndFailCnt 4
attr az_Thermostat protResndFailLast 2012-10-29 21:41:29
attr az_Thermostat protResndLast 2012-10-29 21:41:28
attr az_Thermostat protSndCnt 8
attr az_Thermostat protSndLast 2012-10-29 19:05:12
attr az_Thermostat room Office
attr az_Thermostat serialNr JEQ0195296
attr az_Thermostat subType thermostat

Ich habe auch mal versucht mit nic -15 den fhem Prozess zu beschleunigen - ohne Erfolg.

Also die Zeiten mal zusammengefaßt lauten wie folgt:
CC->CUNO->fhem->Verarbeitung->fhem->CUNO->CC

Ich weiß die Zeiten aus den Logs für "fhem->Verarbeitung->fhem", die sind mittlerweile mit obiger Konfig. (inkl.hmProtocolEvents=1) bei 127ms. Noch jeweils für die Kommunikation 40ms für CC->CUNO->fhem und zurück komme ich auf 127ms+40ms=167ms < 205ms. D.h. nach meiner (zugegeben sehr groben) Rechnung bliebe ich unter 205ms. Slebst mit eingeschalteten hmProtocolEvents (was in den 127ms dabei ist).
So, da muss wohl meine Annahme, dass die Kommunikation hin und zurück 40ms benötigt falsch sein. Hm....

Einmal hat es gerade eben dann doch nochmal funktioniert. Aber leider nur ein mal.

Gruß,
kohrti

[kohrti]

UUUUUps!

Ein Kleiner Fehler ist mir unterlaufen beim Höhersetzen der Prozess Prio auf der FritzBox. Die Sytax des Befehls ist hier etwas anders und der Befehl lautet:

nice -n -10 /var/InternerSpeicher/fhem/startfhem

Damit habe ich in meinem Produktivsystem (mit FileLogs etc.) jetzt desired-temp schon 3 mal nacheinander ändern können!

Ich teste weiter und melde mich wieder!

[kohrti]

Also nochmal ein Update.

Das 3 mal erfolgreiche desired-temp setzen war wohl ein Zufall. Ich werde mich mal bemühen meine zu schnelle Freude und damit verbunden Postings zu unterdrücken.

Hier nun mein aktueller Log:

2012-10-30 20:49:48.185 CUL_HM az_Thermostat desired-temp 13.5
2012-10-30 20:50:15.379 CUL CUNO RCV L:0C N:45 F:86 CMD:70 SRC:az_Thermostat DST:broadcast 00E635 (WeatherEvent TEMP:23 HUM:53) (,WAKEMEUP,BCAST,RPTEN)
2012-10-30 20:50:15.494 CUL CUNO SND L:09 N:03 F:A1 CMD:12 SRC:F11234 DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012-10-30 20:50:15.502 CUL_HM az_Thermostat T: 23 H: 53
2012-10-30 20:50:15.502 CUL_HM az_Thermostat measured-temp: 23
2012-10-30 20:50:15.502 CUL_HM az_Thermostat humidity: 53
2012-10-30 20:50:19.534 CUL_HM az_Thermostat MISSING ACK

Also (mit hmprotocolevents=1) die Zeitdifferenz ist 115ms < 205ms und sollte garnicht so schlecht aussehen. Die Realität zeigt aber, dass es nicht funzt. Langsam gehen mir die Ideen aus.

Gruß,
kohrti

[kohrti]

Zusammenfassung:

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man muß nicht warten bis der CC aufwacht. -->Idee von Uwe
2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint nicht haltbar zu sein, obwohl ich daran glaube. Aus obigem Post sieht man aber, dass die Zeitdifferenz von 115ms + Kommunikation CC<->fhem anscheinend länger ist. Wie man End2End messen soll weiß ich nicht. Selbst mit Wireshark würde man nicht die Strecke CUNO-CC mitmessen. Reduktion des Loggings und LogFiles brachte keine Besserung. --> von kohrti
3. Anscheinend hatte das setzen von desired-temp in einer älteren fhem Version besser funktioniert. -->von Merhan
4. Das beschleunigen des fhem Prozesses brachte keine Abhilfe. --> von kohrti

Ich halte das setzen der desired-temp (und andere Parameter) für wichtig, und dies scheint ja ein generisches Problem zu sein (zumindest für CUNO, CUL und HMLAN weiß ich nicht) da es eben mehrfach benötigt wird (eben für andere Parameter auch; evtl. auch für andere Devices?).

-->Daher verfolge ich Weg 1 und evtl. auch Weg 3, obwohl ich denke, dass wenn ich 3. mache es wohl wenig Sinn macht, aber trotzdem. Noch andere Ideen?

Gruß,
der verzweifelte kohrti

[littlebilly]

Hallo,

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man muß nicht warten bis der CC aufwacht. -->Idee von Uwe

mit CC meinst HM-CC-TC ? 

Ich halte das setzen der desired-temp (und andere Parameter) für wichtig!

 

Ich auch und bei mir läuft es mit dem HMLAN jetzt 100%ig inclusive der Mode Umschaltung und der Offset Rückmeldung!

Mit den alten Versionen lief es bei mir deutlich schlechter bzw. garnicht!

Zu Cuno + Cul kann ich nichts sagen.

Gruss Billy

[kohrti]

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man muß nicht warten bis der CC aufwacht. -->Idee von Uwe

mit CC meinst HM-CC-TC ?

--> Ja

[dou...@gmx.de]

Auch an dieser Stelle noch mal der Hinweis, das der HM-CC-TC sein Empfangsverhalten zu Lasten der Batterielebensdauer ändert, sobald er an einen Fensterkontakt angelernt wurde. :-)

[kohrti]

Danke für den Hinweis dou...@m1n1.de.

Zusammenfassung:

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und Fenterkontakt, der anscheinend eine sofortige Wirkung am HM-CC-TC hat. D.h. man muß nicht warten bis der CC aufwacht. -->Idee von Uwe
Korrektur: Der HM-CC-TC ändert sein Empfangsverhalten beim Anlernen eines Fensterkontakts. Evtl. wäre das ein Workaround, der mehr Energie braucht aber funktioniert. --> von dou...@m1n1.de

2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint nicht haltbar zu sein, obwohl ich daran glaube. Aus obigem Post sieht man aber, dass die Zeitdifferenz von 115ms + Kommunikation CC<->fhem anscheinend länger ist. Wie man End2End messen soll weiß ich nicht. Selbst mit Wireshark würde man nicht die Strecke CUNO-CC mitmessen. Reduktion des Loggings und LogFiles brachte keine Besserung. --> von kohrti
3. Anscheinend hatte das setzen von desired-temp in einer älteren fhem Version besser funktioniert. -->von Merhan
4. Das beschleunigen des fhem Prozesses brachte keine Abhilfe. --> von kohrti

Ich halte das setzen der desired-temp (und andere Parameter) für wichtig, und dies scheint ja ein generisches Problem zu sein (zumindest für CUNO, CUL und HMLAN weiß ich nicht) da es eben mehrfach benötigt wird (eben für andere Parameter auch; evtl. auch für andere Devices?).

-->Daher verfolge ich Weg 1 (nun als Workaround) und evtl. auch Weg 3, obwohl ich denke, dass wenn ich 3. mache es wohl wenig Sinn macht, aber trotzdem. Noch andere Ideen?
-->Kann Weg 3 jemand anschauen (evtl. vielleicht sogar Martin? ich glaube er hatte das ja gemacht und vergleichen was mit dem Code seit dem passiert ist, bzw, was das Verhalten verschlechtert hat?

Gruß
kohrti

[Merhan]

Meine Logs zu dem Thema finden sich in folgendem Thread:

https://groups.google.com/forum/?hl=de&fromgroups=#!topic/fhem-users/5HNaMEx3GQw%5B226-250%5D

Grüße,

Merhan

[Rudolf Koenig]

> Zusammenfassung:

Finde ich gut, bitte weiter machen!

Ich habe diesen Thread nicht exakt verfolgt, kann also sein, dass ich was
uebersehe. Hier meine Punkte:

Bitte die culfw (d.h. CUNO/CUL/COC/etc, bedient ueber 00_CUL.pm) und HMLAN
Experimente sauber auseinanderhalten:

- Ich habe CUL_HM zu 90% mit einem CUL entwickelt.
Mit meinem CUL koennte ich nie verlaesslich die Temperatur der CC-TC setzen,
habs aber auch nie lange versucht. Das ist die "Alte" Version, mit dem man
manche Leute Erfolge hben.

- Martin hat CUL_HM uebernommen, er hatte am Anfang nur ein HMLAN. Er hat
inzwischen auch ein CUL, weiss aber nicht, inwieweit er es auch zum testen
einsetzt.

- Das HM Protokoll ist im HMLAN anders/vollstaendiger implementiert als im culfw:
- resend macht HMLAN alleine, fuer culfw muss es vom CUL_HM uebernommen werden.
- AES macht HMLAN, culfw kann es nicht
- WOR (s.u.) macht HMLAN vermutlich auch, man muss nur die Bits im Befehl
richtig setzten. culfw kann das nicht, koennte aber nachimpementiert
werden, wenn wir Details wissen.

> 1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und

Mwn: falls man einen Fensterkontakt konfiguriert hat, dann ist der CC1101
mit WOR konfiguriert (im HM Kontext wird das wohl faelschlicherweise BURST
genannt). D.h. es wacht haeufiger auf, und prueft auf Funkverkehr. Wenn man
mit dem Ding reden will, dann muss man ein Dauersignal senden. Unbekannt: wie
lange dauert dieser Dauerfunk, ich schaetze es muss in einem einstelligen 100ms
Bereich liegen. D.h. diese Loesung koennte nur in bestimmten Faellen die
Uebertragung um 2 Minuten verkuerzen, und sollte nur als komfort-feature
betrachtet werden, _NICHT_ als DIE Loesung des Kommunikationsproblems.

Mitlauschen ist nichts fuer Anfaenger.

> 2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint
> nicht haltbar zu sein, obwohl ich daran glaube.

Kommt mir komisch vor: da das CUL_HM Modul nach dem Empfang einer Nachricht die
Daten direkt aussenden koennte, ist vermeidbar, dass weitere notify's / etc sich
einmischen, und dabai sollte die 200ms auf einem 500MHz Rechner haltbar sein.
Da innerhalb der Verarbeitung nur hmProtocolEvents ein Trigger
aussendet (na jedenfalls in den Alten Version), sollte das Abschalten von
diesem Attribut reichen, um notify's komplett zu vermeiden. Hier koennte jemand
auch ohne perl Kenntnisse mit etwas experimentieren verwertbare Zahlen liefern.

[kohrti]

Vielen Dank Rudolf für die hilfreichen Infos.

Zu deiner Aussage:

> 2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint
> nicht haltbar zu sein, obwohl ich daran glaube.

Kommt mir komisch vor: da das CUL_HM Modul nach dem Empfang einer Nachricht die
Daten direkt aussenden koennte, ist vermeidbar, dass weitere notify's / etc sich
einmischen, und dabai sollte die 200ms auf einem 500MHz Rechner haltbar sein.
Da innerhalb der Verarbeitung nur hmProtocolEvents ein Trigger
aussendet (na jedenfalls in den Alten Version), sollte das Abschalten von
diesem Attribut reichen, um notify's komplett zu vermeiden. Hier koennte jemand
auch ohne perl Kenntnisse mit etwas experimentieren verwertbare Zahlen liefern.

Ich habe versucht so weit wie möglich mit der Zeitdauer runter zu kommen indem ich alle Logs usw. auch hmProtocolEvents ausgeschaltet habe und bin bei 127ms Verarbeitungszeit gelandet. Da kommt dann eben noch die Laufzeit der Pakete von fhem zum HM-CC-TC dazu, und zwar 2 mal, weil sie hin- und zurück laufen. Es hat trotzdem nicht funktioniert, obwohl ich weit unter der 205ms Grenze war. Daher denke ich, dass die Laufzeit höher als vermutet ist, oder es kein 205ms Problem ist. Dann hätte es allerdings zur Folge, dass an anderer Stelle was nicht stimmt, was aber aufgrund der tatsache, dass es manchmal ja doch geht wohl eher nicht der Fall sein wird.

Wenn mir mal jemand (egal ob mit HMLAN oder CUL,CUNO) mit eingeschalteten hmProtocolEvents ein positives (also wo das sezen funktioniert hat) Log geben würde wäre ich über-glücklich! Ich habe das bisher noch nicht geschafft.

[dou...@gmx.de]

...war jetzt neugierig und hab die Schachtel mit dem HMLAN Adapter mal aus dem Regal gezogen. 

Ganz schönen Boliden haben die da drin verbaut:

Atmel AT91SAM7x256 @18,432MHz

A member of the Atmel SAM7X series of microcontrollers based on the 32-bit ARM7TDMI processor. It operates at a maximum speed of 55 MHz and features 256KB of flash and 64KB of SRAM. The peripheral set includes USB 2.0 full speed device port , Ethernet MAC 10/100 port, CAN 2.0A and 2.0B compliant Controller, two USART, UART, two SPI, SSC, TWI, three 16-bit timers, RTT and 8x10-bit ADC. 

[fhem-hm-knecht]

> 2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint
> nicht haltbar zu sein, obwohl ich daran glaube.

:)

ich hatte folgenden Prüf-messaufbau

1.fhem auf 7390 mit ersten hmlan ip 192.168.2.80
2.ccu
3.fhem auf win7 mit zweiten hmlan ip 192.168.2.81 und wireshark um
direkt am HMlan zu schnüffeln,
damit man die Ergebnisse irgendwie vergleichen kann
Eintreffen der Nachricht vom TC<-->Eintreffen Nachricht (Have Data) =
Zeitdifferenz Luftschnittstelle

CCU ok = 202 - 205 msec
7390 ok = 200 msec
7390 nok = 208 msec
win7 ok = 110 msec

Messungen die noch fehlen sind:
fhem mit cul, (cuno habe ich nicht)
fhem vom letzen Winter
fhem 5.2
fhem 5.3

es interessiert mich noch, da fhem gewachsen ist, fhem.pl , telnet
ausgelagert, https, usw
ob, und welche zeit da(wo) liegen gelassen wird.

Allerdings macht es keinen Spass dieses auf der 7390 zu messen,
da ich jedesmal mein Produktivsystem umbauen muß.
Mal schauen, wann ich die Woche mir mein paar viele Stunden rauseiern
kann

Hary

[kohrti]

Ich hänge auch mal Wireshark rein uns messe mit CUNO (CUL und HMLAN habe  ich nicht). Dabei messe ich auch direkt vor dem CUNO am Netzwerk. Damit sollten die Messverfahren passen und die Ergebnisse vergleichbar sein.
Meine derzeitige Schätzung (siehe Posts weiter oben) gehen aber davon aus, dass es mit CUNO trotz Zeit <205ms nicht geht. Ich prüfe das aber weiterhin und diese Zeitmessung ist ein richtiger Schritt um das zu verifizieren.

[fhem-hm-knecht]

> direkt vor dem CUNO am Netzwerk. Damit
>sollten die Messverfahren passen und die Ergebnisse vergleichbar sein.

Ne, passen nicht, da die Wandelzeit Telnet <--> Luftschnittstelle in
beiden Richtungen , dir fehlt,

Hary

[kohrti]

Ich will ja eigentlich den CUNO bzw. den HMLAN mitmessen (das meinst du doch, oder?). Eine Frage des Standpunkts. Hast du eine andere Idee oder denkst du, dass wir das machen sollten und der Vergleich gewinnbringend ist?

[Martin]

Ziemlich lange diskussion - habe nicht alles gelesen.

Zum TC empfehle ich alle hmProtocolEvents zu loeschen.
Dann global verbose auf '5'

Mitloggen von eine Temp Aenderung - die CUL sollte das auch loggen
=> Trace schicken

set <TC> getConfig
Anlernen druecken am TC ( 'ok' bis es blinkt)
trace schicken.

Mein TC letztin gestreikt - ich habe die Batterie entfernt und eingesetzt - jetzt geht er wieder. Ist einen Versuch wert

[Martin]

Die alte Version (5.2) akzeptiert mindestens 50 % der Kommandos. Die neue Version hat leider 0% Erfolg.

Folgende Fehlermeldungen tauchen bei mir in der Konsole auf:

habe noch keine Erklaerung.  Welche Versin CUL_HM war bei dir in 5.2? Arbeitsr du mit CUL oder HMLAN?

[/opt/share/fhem/FHEM] # Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

kann es sein, dass in deinen Readings ein falscher Wert steht, vor dem Kommando?
Schicke bitte ein 'list <TC>' vor und nach dem Fehler

Use of uninitialized value in substitution (s///) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 3107.

Nach welchem Kommando kommt de Fehler?

[kohrti]

Hallo Martin,

vielen Dank für deine Meldung.

Ich habe hier das 1. trace:

2012-11-01 12:45:15.540 CUL_HM az_Thermostat desired-temp 10.0
2012-11-01 12:45:20.819 CUL_HM az_Thermostat T: 21.9 H: 50
2012-11-01 12:45:20.819 CUL_HM az_Thermostat measured-temp: 21.9
2012-11-01 12:45:20.819 CUL_HM az_Thermostat humidity: 50
2012-11-01 12:45:24.850 CUL_HM az_Thermostat MISSING ACK

MISSING ACK kam hier zufällig sogar sehr schnell.

2. trace:
2012-11-01 12:49:39.974 CUL_HM az_Thermostat RESPONSE TIMEOUT
2012-11-01 12:49:41.595 CUL_HM az_Thermostat RESPONSE TIMEOUT
2012-11-01 12:49:43.101 CUL_HM az_Thermostat RESPONSE TIMEOUT

Ich habe zuerst set <TC> getConfig abgesetzt und dann OK gedrückt. Mehrere Male wiederholt, immer das gleiche Ergebnis.

Grüße,
kohrti

[Martin]

Als trace brauche ich die rohdaten aus dem IO device

attr global verbose 5
attr global mseclog 1

dann die Versuche machen - getConfig,...

anschließend das logfile schicken (nur die relevante Zeit!)

missing ACK kommt immer schneller als der timeout. timeout ist quasi "0.5 layer hoeher angeordnet" - aber egal. Es war offensichtlich noch ein command im commandstack.

[kohrti]

Hallo Martin,

wie komme ich denn an die Rohdaten aus dem IO Device (ebi mir CUNO)?

attr global verbose 5
attr global mseclog 1

und getConfig sind mir klar. Ich hatte für obige traces das EventLog verwendet. Muss ich in ein Logfile des CUNO schauen, evtl aktivieren (loglevel etc.)?

Vielen Dank für die Hilfe,
kohrti

[Martin]

nein- loglevel nicht setzen, besser loeschen.
Wieviele Logs hatst du angelegt? Ich denke sie sollten im eventlog stehen

[kohrti]

Also ich habe insgesamt in meinem Produktiv System 49 FileLogs. Das Testsystem hat nur das Thermostat definiert ohne FileLog. Ich bin jetzt etwas verwirrt, daher poste ich hier mal meine Testconfig file:

Ich hoffe das hilft. Welches eventlog meinst du? Soll ich mich über telnet reinhängen? Den Event Monitor auslesen? Das allgemeine Log? Gibt es vielleicht ein CUNO Log?

[kohrti]

Ich habe jetzt nochmal den allgemeinen Log genommen und hoffe das ist der richtige (sieht zumindest rivhtig aus). Ich habe versucht die wichtigen (aus meiner Sicht) Zeilen Fett zu markieren:


2012.11.02 09:57:59.232 4: Connection closed for FHEMWEB:192.168.2.20:54686
2012.11.02 09:57:59.236 4: Connection accepted from FHEMWEB:192.168.2.20:54688
2012.11.02 09:57:59.236 4: HTTP FHEMWEB:192.168.2.20:54688 GET /fhem?cmd=style%20eventMonitor
2012.11.02 09:57:59.312 4: /fhem?cmd=style%20eventMonitor / RL: 848 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.11.02 09:58:00.356 4: HTTP FHEMWEB:192.168.2.20:54688 GET /fhem?XHR=1&inform=console
2012.11.02 09:58:10.100 5: CUL/RAW: /A0CEC86701D6A4300000000E436FF

2012.11.02 09:58:10.100 5: CUNO: A0CEC86701D6A4300000000E436 -74.5
2012.11.02 09:58:10.104 5: CUNO dispatch A0CEC86701D6A4300000000E436
2012.11.02 09:58:10.116 5: Triggering az_Thermostat (3 changes)
2012.11.02 09:58:10.120 5: az_Thermostat trigger: Checking FileLog_ActionDetector for notify
2012.11.02 09:58:10.124 5: az_Thermostat trigger: Checking FileLog_Aussentemperatur for notify
2012.11.02 09:58:10.124 5: az_Thermostat trigger: Checking FileLog_CUL_HM_dimmer_184110 for notify
2012.11.02 09:58:10.128 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179 for notify
2012.11.02 09:58:10.128 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_1 for notify
2012.11.02 09:58:10.132 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_2 for notify
2012.11.02 09:58:10.136 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_1 for notify
2012.11.02 09:58:10.136 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_2 for notify
2012.11.02 09:58:10.140 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_1A5B7A for notify
2012.11.02 09:58:10.140 5: az_Thermostat trigger: Checking FileLog_IEQ0536117 for notify
2012.11.02 09:58:10.144 5: az_Thermostat trigger: Checking FileLog_Schaltadapter1 for notify
2012.11.02 09:58:10.144 5: az_Thermostat trigger: Checking FileLog_Vorlauftemperatur for notify
2012.11.02 09:58:10.148 5: az_Thermostat trigger: Checking FileLog_az2_PIDPWM for notify
2012.11.02 09:58:10.152 5: az_Thermostat trigger: Checking FileLog_az_PIDPWM for notify
2012.11.02 09:58:10.152 5: az_Thermostat trigger: Checking FileLog_az_Rauchmelder for notify
2012.11.02 09:58:10.156 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe for notify
2012.11.02 09:58:10.156 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe2 for notify
2012.11.02 09:58:10.160 5: az_Thermostat trigger: Checking FileLog_az_Thermostat for notify
2012.11.02 09:58:10.172 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Climate for notify
2012.11.02 09:58:10.176 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Weather for notify
2012.11.02 09:58:10.176 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_WindowRec for notify
2012.11.02 09:58:10.180 5: az_Thermostat trigger: Checking FileLog_ba_PIDPWM for notify
2012.11.02 09:58:10.180 5: az_Thermostat trigger: Checking FileLog_ba_Thermostat for notify
2012.11.02 09:58:10.184 5: az_Thermostat trigger: Checking FileLog_fl_Rauchmelder for notify
2012.11.02 09:58:10.184 5: az_Thermostat trigger: Checking FileLog_gz_PIDPWM for notify
2012.11.02 09:58:10.188 5: az_Thermostat trigger: Checking FileLog_gz_Thermostat for notify
2012.11.02 09:58:10.192 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis1 for notify
2012.11.02 09:58:10.192 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis2 for notify
2012.11.02 09:58:10.196 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis3 for notify
2012.11.02 09:58:10.196 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis4 for notify
2012.11.02 09:58:10.200 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis5 for notify
2012.11.02 09:58:10.200 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis6 for notify
2012.11.02 09:58:10.204 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis7 for notify
2012.11.02 09:58:10.204 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis8 for notify
2012.11.02 09:58:10.208 5: az_Thermostat trigger: Checking FileLog_ku_PIDPWM for notify
2012.11.02 09:58:10.212 5: az_Thermostat trigger: Checking FileLog_ku_Rauchmelder for notify
2012.11.02 09:58:10.212 5: az_Thermostat trigger: Checking FileLog_ku_Thermostat for notify
2012.11.02 09:58:10.216 5: az_Thermostat trigger: Checking FileLog_sz_PIDPWM for notify
2012.11.02 09:58:10.216 5: az_Thermostat trigger: Checking FileLog_sz_Thermostat for notify
2012.11.02 09:58:10.220 5: az_Thermostat trigger: Checking FileLog_wz_PIDPWM for notify
2012.11.02 09:58:10.220 5: az_Thermostat trigger: Checking FileLog_wz_TasterEsstisch for notify
2012.11.02 09:58:10.224 5: az_Thermostat trigger: Checking FileLog_wz_Thermostat for notify
2012.11.02 09:58:10.224 5: az_Thermostat trigger: Checking Logfile for notify
2012.11.02 09:58:10.228 5: az_Thermostat trigger: Checking WEB for notify
2012.11.02 09:58:10.228 5: az_Thermostat trigger: Checking WEBphone for notify
2012.11.02 09:58:10.228 5: az_Thermostat trigger: Checking WEBtablet for notify
2012.11.02 09:58:10.232 5: az_Thermostat trigger: Checking autocreate for notify
2012.11.02 09:58:10.232 5: az_Thermostat trigger: Checking telnetPort for notify
2012.11.02 09:58:10.232 5: az_Thermostat trigger: Checking FHEMWEB:192.168.2.20:54688 for notify
2012.11.02 09:58:10.347 4: Connection accepted from FHEMWEB:192.168.2.20:54689
2012.11.02 09:58:10.347 4: HTTP FHEMWEB:192.168.2.20:54689 GET /fhem?XHR=1&inform=console
2012.11.02 09:58:26.546 4: Connection accepted from FHEMWEB:192.168.2.20:54690
2012.11.02 09:58:26.805 4: HTTP FHEMWEB:192.168.2.20:54690 GET /fhem?room=Office&cmd=set+az_Thermostat+getConfig
2012.11.02 09:58:26.809 5: Cmd: >set az_Thermostat getConfig<
2012.11.02 09:58:26.817 3: CUL_HM set az_Thermostat getConfig
2012.11.02 09:58:26.817 5: Triggering az_Thermostat (1 changes)
2012.11.02 09:58:26.825 5: az_Thermostat trigger: Checking FileLog_ActionDetector for notify
2012.11.02 09:58:26.825 5: az_Thermostat trigger: Checking FileLog_Aussentemperatur for notify
2012.11.02 09:58:26.829 5: az_Thermostat trigger: Checking FileLog_CUL_HM_dimmer_184110 for notify
2012.11.02 09:58:26.829 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179 for notify
2012.11.02 09:58:26.833 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_1 for notify
2012.11.02 09:58:26.833 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_2 for notify
2012.11.02 09:58:26.837 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_1 for notify
2012.11.02 09:58:26.837 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_2 for notify
2012.11.02 09:58:26.841 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_1A5B7A for notify
2012.11.02 09:58:26.841 5: az_Thermostat trigger: Checking FileLog_IEQ0536117 for notify
2012.11.02 09:58:26.845 5: az_Thermostat trigger: Checking FileLog_Schaltadapter1 for notify
2012.11.02 09:58:26.845 5: az_Thermostat trigger: Checking FileLog_Vorlauftemperatur for notify
2012.11.02 09:58:26.849 5: az_Thermostat trigger: Checking FileLog_az2_PIDPWM for notify
2012.11.02 09:58:26.853 5: az_Thermostat trigger: Checking FileLog_az_PIDPWM for notify
2012.11.02 09:58:26.853 5: az_Thermostat trigger: Checking FileLog_az_Rauchmelder for notify
2012.11.02 09:58:26.857 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe for notify
2012.11.02 09:58:26.857 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe2 for notify
2012.11.02 09:58:26.861 5: az_Thermostat trigger: Checking FileLog_az_Thermostat for notify
2012.11.02 09:58:26.865 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Climate for notify
2012.11.02 09:58:26.865 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Weather for notify
2012.11.02 09:58:26.869 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_WindowRec for notify
2012.11.02 09:58:26.873 5: az_Thermostat trigger: Checking FileLog_ba_PIDPWM for notify
2012.11.02 09:58:26.873 5: az_Thermostat trigger: Checking FileLog_ba_Thermostat for notify
2012.11.02 09:58:26.877 5: az_Thermostat trigger: Checking FileLog_fl_Rauchmelder for notify
2012.11.02 09:58:26.877 5: az_Thermostat trigger: Checking FileLog_gz_PIDPWM for notify
2012.11.02 09:58:26.881 5: az_Thermostat trigger: Checking FileLog_gz_Thermostat for notify
2012.11.02 09:58:26.881 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis1 for notify
2012.11.02 09:58:26.885 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis2 for notify
2012.11.02 09:58:26.885 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis3 for notify
2012.11.02 09:58:26.889 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis4 for notify
2012.11.02 09:58:26.889 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis5 for notify
2012.11.02 09:58:26.893 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis6 for notify
2012.11.02 09:58:26.893 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis7 for notify
2012.11.02 09:58:26.896 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis8 for notify
2012.11.02 09:58:26.896 5: az_Thermostat trigger: Checking FileLog_ku_PIDPWM for notify
2012.11.02 09:58:26.900 5: az_Thermostat trigger: Checking FileLog_ku_Rauchmelder for notify
2012.11.02 09:58:26.900 5: az_Thermostat trigger: Checking FileLog_ku_Thermostat for notify
2012.11.02 09:58:26.904 5: az_Thermostat trigger: Checking FileLog_sz_PIDPWM for notify
2012.11.02 09:58:26.904 5: az_Thermostat trigger: Checking FileLog_sz_Thermostat for notify
2012.11.02 09:58:26.908 5: az_Thermostat trigger: Checking FileLog_wz_PIDPWM for notify
2012.11.02 09:58:26.908 5: az_Thermostat trigger: Checking FileLog_wz_TasterEsstisch for notify
2012.11.02 09:58:26.912 5: az_Thermostat trigger: Checking FileLog_wz_Thermostat for notify
2012.11.02 09:58:26.912 5: az_Thermostat trigger: Checking Logfile for notify
2012.11.02 09:58:26.916 5: az_Thermostat trigger: Checking WEB for notify
2012.11.02 09:58:26.916 5: az_Thermostat trigger: Checking WEBphone for notify
2012.11.02 09:58:26.920 5: az_Thermostat trigger: Checking WEBtablet for notify
2012.11.02 09:58:26.920 5: az_Thermostat trigger: Checking autocreate for notify
2012.11.02 09:58:26.920 5: az_Thermostat trigger: Checking telnetPort for notify
2012.11.02 09:58:26.920 5: az_Thermostat trigger: Checking FHEMWEB:192.168.2.20:54689 for notify
2012.11.02 09:58:26.928 4: HTTP FHEMWEB:192.168.2.20:54690 GET /fhem?room=Office
2012.11.02 09:58:27.048 4: /fhem?room=Office / RL: 1985 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2012.11.02 09:58:27.080 4: HTTP FHEMWEB:192.168.2.20:54690 GET /fhem?XHR=1&inform=console
2012.11.02 09:58:27.088 4: Connection accepted from FHEMWEB:192.168.2.20:54691
2012.11.02 09:58:27.112 4: HTTP FHEMWEB:192.168.2.20:54691 GET /fhem?cmd=showlog%20weblink_Desired_az_Thermostat%20FileLog_az_Thermostat%20temp4desired%20az_Thermostat-2012.log&pos=
2012.11.02 09:58:27.155 5: plotcommand: get FileLog_az_Thermostat az_Thermostat-2012.log INT 2012-11-02 2012-11-03 4:desired-temp:0:
2012.11.02 09:58:27.155 5: Cmd: >get FileLog_az_Thermostat az_Thermostat-2012.log INT 2012-11-02 2012-11-03 4:desired-temp:0:<
2012.11.02 09:58:27.446 4: /fhem?cmd=showlog%20weblink_Desired_az_Thermostat%20FileLog_az_Thermostat%20temp4desired%20az_Thermostat-2012.log&pos= / RL: 1833 / image/svg+xml / Content-Encoding: gzip
 /
2012.11.02 09:58:27.450 4: Connection accepted from FHEMWEB:192.168.2.20:54692
2012.11.02 09:58:27.454 4: HTTP FHEMWEB:192.168.2.20:54692 GET /fhem?cmd=showlog%20weblink_az_Thermostat%20FileLog_az_Thermostat%20temp4hum6%20az_Thermostat-2012.log&pos=
2012.11.02 09:58:27.494 5: plotcommand: get FileLog_az_Thermostat az_Thermostat-2012.log INT 2012-11-02 2012-11-03 4:T\x3a:0: 6:H\x3a:0:
2012.11.02 09:58:27.494 5: Cmd: >get FileLog_az_Thermostat az_Thermostat-2012.log INT 2012-11-02 2012-11-03 4:T\x3a:0: 6:H\x3a:0:<
2012.11.02 09:58:28.402 4: /fhem?cmd=showlog%20weblink_az_Thermostat%20FileLog_az_Thermostat%20temp4hum6%20az_Thermostat-2012.log&pos= / RL: 3088 / image/svg+xml / Content-Encoding: gzip
 /
2012.11.02 09:58:28.406 4: Connection accepted from FHEMWEB:192.168.2.20:54693
2012.11.02 09:58:28.410 4: Connection accepted from FHEMWEB:192.168.2.20:54694
2012.11.02 09:58:28.414 4: HTTP FHEMWEB:192.168.2.20:54693 GET /fhem?cmd=showlog%20weblink_ka_Heizkreis6%20FileLog_ka_Heizkreis6%20fs20%20ka_Heizkreis6-2012.log&pos=
2012.11.02 09:58:28.454 5: plotcommand: get FileLog_ka_Heizkreis6 ka_Heizkreis6-2012.log INT 2012-11-02 2012-11-03 3::0:$fld[2]=~"on"?1:0
2012.11.02 09:58:28.458 5: Cmd: >get FileLog_ka_Heizkreis6 ka_Heizkreis6-2012.log INT 2012-11-02 2012-11-03 3::0:$fld[2]=~"on"?1:0<
2012.11.02 09:58:28.992 4: /fhem?cmd=showlog%20weblink_ka_Heizkreis6%20FileLog_ka_Heizkreis6%20fs20%20ka_Heizkreis6-2012.log&pos= / RL: 2033 / image/svg+xml / Content-Encoding: gzip
 /
2012.11.02 09:58:28.996 4: HTTP FHEMWEB:192.168.2.20:54694 GET /fhem?cmd=showlog%20weblink_ka_Heizkreis7%20FileLog_ka_Heizkreis7%20fs20%20ka_Heizkreis7-2012.log&pos=
2012.11.02 09:58:29.036 5: plotcommand: get FileLog_ka_Heizkreis7 ka_Heizkreis7-2012.log INT 2012-11-02 2012-11-03 3::0:$fld[2]=~"on"?1:0
2012.11.02 09:58:29.040 5: Cmd: >get FileLog_ka_Heizkreis7 ka_Heizkreis7-2012.log INT 2012-11-02 2012-11-03 3::0:$fld[2]=~"on"?1:0<
2012.11.02 09:58:29.558 4: /fhem?cmd=showlog%20weblink_ka_Heizkreis7%20FileLog_ka_Heizkreis7%20fs20%20ka_Heizkreis7-2012.log&pos= / RL: 2033 / image/svg+xml / Content-Encoding: gzip
 /
2012.11.02 09:58:36.139 5: CUL/RAW: /A1AED84001D6A430000002100394A4551303139353239365800FFFFF6

2012.11.02 09:58:36.139 5: CUNO: A1AED84001D6A430000002100394A4551303139353239365800FFFF -79
2012.11.02 09:58:36.143 5: CUNO dispatch A1AED84001D6A430000002100394A4551303139353239365800FFFF
2012.11.02 09:58:36.159 3: Device az_Thermostat added to ActionDetector with 000:10 time
2012.11.02 09:58:36.263 5: CUNO sending As104CA001F112341D6A4300040000000000
2012.11.02 09:58:36.263 5: SW: As104CA001F112341D6A4300040000000000
2012.11.02 09:58:36.275 5: Triggering az_Thermostat (0 changes)
2012.11.02 09:58:36.283 5: az_Thermostat trigger: Checking FileLog_ActionDetector for notify
2012.11.02 09:58:36.283 5: az_Thermostat trigger: Checking FileLog_Aussentemperatur for notify
2012.11.02 09:58:36.283 5: az_Thermostat trigger: Checking FileLog_CUL_HM_dimmer_184110 for notify
2012.11.02 09:58:36.286 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179 for notify
2012.11.02 09:58:36.286 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_1 for notify
2012.11.02 09:58:36.286 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_2 for notify
2012.11.02 09:58:36.290 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_1 for notify
2012.11.02 09:58:36.290 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_2 for notify
2012.11.02 09:58:36.290 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_1A5B7A for notify
2012.11.02 09:58:36.294 5: az_Thermostat trigger: Checking FileLog_IEQ0536117 for notify
2012.11.02 09:58:36.294 5: az_Thermostat trigger: Checking FileLog_Schaltadapter1 for notify
2012.11.02 09:58:36.294 5: az_Thermostat trigger: Checking FileLog_Vorlauftemperatur for notify
2012.11.02 09:58:36.298 5: az_Thermostat trigger: Checking FileLog_az2_PIDPWM for notify
2012.11.02 09:58:36.298 5: az_Thermostat trigger: Checking FileLog_az_PIDPWM for notify
2012.11.02 09:58:36.298 5: az_Thermostat trigger: Checking FileLog_az_Rauchmelder for notify
2012.11.02 09:58:36.302 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe for notify
2012.11.02 09:58:36.302 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe2 for notify
2012.11.02 09:58:36.306 5: az_Thermostat trigger: Checking FileLog_az_Thermostat for notify
2012.11.02 09:58:36.306 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Climate for notify
2012.11.02 09:58:36.306 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Weather for notify
2012.11.02 09:58:36.310 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_WindowRec for notify
2012.11.02 09:58:36.310 5: az_Thermostat trigger: Checking FileLog_ba_PIDPWM for notify
2012.11.02 09:58:36.310 5: az_Thermostat trigger: Checking FileLog_ba_Thermostat for notify
2012.11.02 09:58:36.314 5: az_Thermostat trigger: Checking FileLog_fl_Rauchmelder for notify
2012.11.02 09:58:36.314 5: az_Thermostat trigger: Checking FileLog_gz_PIDPWM for notify
2012.11.02 09:58:36.314 5: az_Thermostat trigger: Checking FileLog_gz_Thermostat for notify
2012.11.02 09:58:36.318 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis1 for notify
2012.11.02 09:58:36.318 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis2 for notify
2012.11.02 09:58:36.322 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis3 for notify
2012.11.02 09:58:36.322 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis4 for notify
2012.11.02 09:58:36.322 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis5 for notify
2012.11.02 09:58:36.326 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis6 for notify
2012.11.02 09:58:36.326 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis7 for notify
2012.11.02 09:58:36.326 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis8 for notify
2012.11.02 09:58:36.330 5: az_Thermostat trigger: Checking FileLog_ku_PIDPWM for notify
2012.11.02 09:58:36.330 5: az_Thermostat trigger: Checking FileLog_ku_Rauchmelder for notify
2012.11.02 09:58:36.330 5: az_Thermostat trigger: Checking FileLog_ku_Thermostat for notify
2012.11.02 09:58:36.338 5: az_Thermostat trigger: Checking FileLog_sz_PIDPWM for notify
2012.11.02 09:58:36.338 5: az_Thermostat trigger: Checking FileLog_sz_Thermostat for notify
2012.11.02 09:58:36.342 5: az_Thermostat trigger: Checking FileLog_wz_PIDPWM for notify
2012.11.02 09:58:36.342 5: az_Thermostat trigger: Checking FileLog_wz_TasterEsstisch for notify
2012.11.02 09:58:36.342 5: az_Thermostat trigger: Checking FileLog_wz_Thermostat for notify
2012.11.02 09:58:36.346 5: az_Thermostat trigger: Checking Logfile for notify
2012.11.02 09:58:36.346 5: az_Thermostat trigger: Checking WEB for notify
2012.11.02 09:58:36.346 5: az_Thermostat trigger: Checking WEBphone for notify
2012.11.02 09:58:36.346 5: az_Thermostat trigger: Checking WEBtablet for notify
2012.11.02 09:58:36.350 5: az_Thermostat trigger: Checking autocreate for notify
2012.11.02 09:58:36.350 5: az_Thermostat trigger: Checking telnetPort for notify
2012.11.02 09:58:36.350 5: az_Thermostat trigger: Checking FHEMWEB:192.168.2.20:54690 for notify
2012.11.02 09:58:36.633 5: CUL/RAW: /A1A4C80101D6A43F11234020100020105000AF10B120C340F000000FF

2012.11.02 09:58:36.637 5: CUNO: A1A4C80101D6A43F11234020100020105000AF10B120C340F000000 -74.5
2012.11.02 09:58:36.637 5: CUNO dispatch A1A4C80101D6A43F11234020100020105000AF10B120C340F000000
2012.11.02 09:58:36.757 5: CUNO sending As104DA001F112341D6A4302040000000005
2012.11.02 09:58:36.757 5: SW: As104DA001F112341D6A4302040000000005
2012.11.02 09:58:36.769 5: Triggering az_Thermostat (0 changes)
2012.11.02 09:58:36.777 5: az_Thermostat trigger: Checking FileLog_ActionDetector for notify
2012.11.02 09:58:36.777 5: az_Thermostat trigger: Checking FileLog_Aussentemperatur for notify
2012.11.02 09:58:36.777 5: az_Thermostat trigger: Checking FileLog_CUL_HM_dimmer_184110 for notify
2012.11.02 09:58:36.781 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179 for notify
2012.11.02 09:58:36.781 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_1 for notify
2012.11.02 09:58:36.781 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_2 for notify
2012.11.02 09:58:36.784 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_1 for notify
2012.11.02 09:58:36.784 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_2 for notify
2012.11.02 09:58:36.784 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_1A5B7A for notify
2012.11.02 09:58:36.788 5: az_Thermostat trigger: Checking FileLog_IEQ0536117 for notify
2012.11.02 09:58:36.788 5: az_Thermostat trigger: Checking FileLog_Schaltadapter1 for notify
2012.11.02 09:58:36.788 5: az_Thermostat trigger: Checking FileLog_Vorlauftemperatur for notify
2012.11.02 09:58:36.792 5: az_Thermostat trigger: Checking FileLog_az2_PIDPWM for notify
2012.11.02 09:58:36.792 5: az_Thermostat trigger: Checking FileLog_az_PIDPWM for notify
2012.11.02 09:58:36.792 5: az_Thermostat trigger: Checking FileLog_az_Rauchmelder for notify
2012.11.02 09:58:36.796 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe for notify
2012.11.02 09:58:36.796 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe2 for notify
2012.11.02 09:58:36.800 5: az_Thermostat trigger: Checking FileLog_az_Thermostat for notify
2012.11.02 09:58:36.800 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Climate for notify
2012.11.02 09:58:36.800 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Weather for notify
2012.11.02 09:58:36.804 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_WindowRec for notify
2012.11.02 09:58:36.804 5: az_Thermostat trigger: Checking FileLog_ba_PIDPWM for notify
2012.11.02 09:58:36.804 5: az_Thermostat trigger: Checking FileLog_ba_Thermostat for notify
2012.11.02 09:58:36.808 5: az_Thermostat trigger: Checking FileLog_fl_Rauchmelder for notify
2012.11.02 09:58:36.808 5: az_Thermostat trigger: Checking FileLog_gz_PIDPWM for notify
2012.11.02 09:58:36.808 5: az_Thermostat trigger: Checking FileLog_gz_Thermostat for notify
2012.11.02 09:58:36.812 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis1 for notify
2012.11.02 09:58:36.812 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis2 for notify
2012.11.02 09:58:36.816 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis3 for notify
2012.11.02 09:58:36.816 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis4 for notify
2012.11.02 09:58:36.816 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis5 for notify
2012.11.02 09:58:36.820 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis6 for notify
2012.11.02 09:58:36.820 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis7 for notify
2012.11.02 09:58:36.820 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis8 for notify
2012.11.02 09:58:36.824 5: az_Thermostat trigger: Checking FileLog_ku_PIDPWM for notify
2012.11.02 09:58:36.824 5: az_Thermostat trigger: Checking FileLog_ku_Rauchmelder for notify
2012.11.02 09:58:36.824 5: az_Thermostat trigger: Checking FileLog_ku_Thermostat for notify
2012.11.02 09:58:36.828 5: az_Thermostat trigger: Checking FileLog_sz_PIDPWM for notify
2012.11.02 09:58:36.828 5: az_Thermostat trigger: Checking FileLog_sz_Thermostat for notify
2012.11.02 09:58:36.828 5: az_Thermostat trigger: Checking FileLog_wz_PIDPWM for notify
2012.11.02 09:58:36.832 5: az_Thermostat trigger: Checking FileLog_wz_TasterEsstisch for notify
2012.11.02 09:58:36.832 5: az_Thermostat trigger: Checking FileLog_wz_Thermostat for notify
2012.11.02 09:58:36.832 5: az_Thermostat trigger: Checking Logfile for notify
2012.11.02 09:58:36.836 5: az_Thermostat trigger: Checking WEB for notify
2012.11.02 09:58:36.836 5: az_Thermostat trigger: Checking WEBphone for notify
2012.11.02 09:58:36.836 5: az_Thermostat trigger: Checking WEBtablet for notify
2012.11.02 09:58:36.840 5: az_Thermostat trigger: Checking autocreate for notify
2012.11.02 09:58:36.840 5: az_Thermostat trigger: Checking telnetPort for notify
2012.11.02 09:58:36.840 5: az_Thermostat trigger: Checking FHEMWEB:192.168.2.20:54690 for notify
2012.11.02 09:58:37.131 5: CUL/RAW: /A1A4DA0101D6A43F11234030109292C261828005800002426302C4EF9

2012.11.02 09:58:37.131 5: CUNO: A1A4DA0101D6A43F11234030109292C261828005800002426302C4E -77.5
2012.11.02 09:58:37.135 5: CUNO dispatch A1A4DA0101D6A43F11234030109292C261828005800002426302C4E
2012.11.02 09:58:37.147 5: Triggering az_Thermostat (0 changes)
2012.11.02 09:58:37.155 5: az_Thermostat trigger: Checking FileLog_ActionDetector for notify
2012.11.02 09:58:37.155 5: az_Thermostat trigger: Checking FileLog_Aussentemperatur for notify
2012.11.02 09:58:37.155 5: az_Thermostat trigger: Checking FileLog_CUL_HM_dimmer_184110 for notify
2012.11.02 09:58:37.159 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179 for notify
2012.11.02 09:58:37.159 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_1 for notify
2012.11.02 09:58:37.159 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_2 for notify
2012.11.02 09:58:37.163 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_1 for notify
2012.11.02 09:58:37.163 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_2 for notify
2012.11.02 09:58:37.167 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_1A5B7A for notify
2012.11.02 09:58:37.167 5: az_Thermostat trigger: Checking FileLog_IEQ0536117 for notify
2012.11.02 09:58:37.167 5: az_Thermostat trigger: Checking FileLog_Schaltadapter1 for notify
2012.11.02 09:58:37.171 5: az_Thermostat trigger: Checking FileLog_Vorlauftemperatur for notify
2012.11.02 09:58:37.171 5: az_Thermostat trigger: Checking FileLog_az2_PIDPWM for notify
2012.11.02 09:58:37.171 5: az_Thermostat trigger: Checking FileLog_az_PIDPWM for notify
2012.11.02 09:58:37.175 5: az_Thermostat trigger: Checking FileLog_az_Rauchmelder for notify
2012.11.02 09:58:37.175 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe for notify
2012.11.02 09:58:37.175 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe2 for notify
2012.11.02 09:58:37.179 5: az_Thermostat trigger: Checking FileLog_az_Thermostat for notify
2012.11.02 09:58:37.179 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Climate for notify
2012.11.02 09:58:37.179 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Weather for notify
2012.11.02 09:58:37.183 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_WindowRec for notify
2012.11.02 09:58:37.183 5: az_Thermostat trigger: Checking FileLog_ba_PIDPWM for notify
2012.11.02 09:58:37.187 5: az_Thermostat trigger: Checking FileLog_ba_Thermostat for notify
2012.11.02 09:58:37.187 5: az_Thermostat trigger: Checking FileLog_fl_Rauchmelder for notify
2012.11.02 09:58:37.187 5: az_Thermostat trigger: Checking FileLog_gz_PIDPWM for notify
2012.11.02 09:58:37.191 5: az_Thermostat trigger: Checking FileLog_gz_Thermostat for notify
2012.11.02 09:58:37.191 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis1 for notify
2012.11.02 09:58:37.195 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis2 for notify
2012.11.02 09:58:37.195 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis3 for notify
2012.11.02 09:58:37.195 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis4 for notify
2012.11.02 09:58:37.199 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis5 for notify
2012.11.02 09:58:37.199 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis6 for notify
2012.11.02 09:58:37.199 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis7 for notify
2012.11.02 09:58:37.203 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis8 for notify
2012.11.02 09:58:37.203 5: az_Thermostat trigger: Checking FileLog_ku_PIDPWM for notify
2012.11.02 09:58:37.203 5: az_Thermostat trigger: Checking FileLog_ku_Rauchmelder for notify
2012.11.02 09:58:37.207 5: az_Thermostat trigger: Checking FileLog_ku_Thermostat for notify
2012.11.02 09:58:37.207 5: az_Thermostat trigger: Checking FileLog_sz_PIDPWM for notify
2012.11.02 09:58:37.207 5: az_Thermostat trigger: Checking FileLog_sz_Thermostat for notify
2012.11.02 09:58:37.211 5: az_Thermostat trigger: Checking FileLog_wz_PIDPWM for notify
2012.11.02 09:58:37.211 5: az_Thermostat trigger: Checking FileLog_wz_TasterEsstisch for notify
2012.11.02 09:58:37.211 5: az_Thermostat trigger: Checking FileLog_wz_Thermostat for notify
2012.11.02 09:58:37.215 5: az_Thermostat trigger: Checking Logfile for notify
2012.11.02 09:58:37.215 5: az_Thermostat trigger: Checking WEB for notify
2012.11.02 09:58:37.215 5: az_Thermostat trigger: Checking WEBphone for notify
2012.11.02 09:58:37.219 5: az_Thermostat trigger: Checking WEBtablet for notify
2012.11.02 09:58:37.219 5: az_Thermostat trigger: Checking autocreate for notify
2012.11.02 09:58:37.219 5: az_Thermostat trigger: Checking telnetPort for notify
2012.11.02 09:58:37.223 5: az_Thermostat trigger: Checking FHEMWEB:192.168.2.20:54690 for notify
2012.11.02 09:58:38.255 5: CUNO sending As104EA001F112341D6A4302040000000006
2012.11.02 09:58:38.255 5: SW: As104EA001F112341D6A4302040000000006
2012.11.02 09:58:38.266 5: Triggering az_Thermostat (1 changes)
2012.11.02 09:58:38.270 5: az_Thermostat trigger: Checking FileLog_ActionDetector for notify
2012.11.02 09:58:38.274 5: az_Thermostat trigger: Checking FileLog_Aussentemperatur for notify
2012.11.02 09:58:38.274 5: az_Thermostat trigger: Checking FileLog_CUL_HM_dimmer_184110 for notify
2012.11.02 09:58:38.278 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179 for notify
2012.11.02 09:58:38.278 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_1 for notify
2012.11.02 09:58:38.282 5: az_Thermostat trigger: Checking FileLog_CUL_HM_remote_19C179Btn_2 for notify
2012.11.02 09:58:38.286 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_1 for notify
2012.11.02 09:58:38.286 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_185AA8Sw_2 for notify
2012.11.02 09:58:38.290 5: az_Thermostat trigger: Checking FileLog_CUL_HM_switch_1A5B7A for notify
2012.11.02 09:58:38.290 5: az_Thermostat trigger: Checking FileLog_IEQ0536117 for notify
2012.11.02 09:58:38.294 5: az_Thermostat trigger: Checking FileLog_Schaltadapter1 for notify
2012.11.02 09:58:38.294 5: az_Thermostat trigger: Checking FileLog_Vorlauftemperatur for notify
2012.11.02 09:58:38.298 5: az_Thermostat trigger: Checking FileLog_az2_PIDPWM for notify
2012.11.02 09:58:38.298 5: az_Thermostat trigger: Checking FileLog_az_PIDPWM for notify
2012.11.02 09:58:38.302 5: az_Thermostat trigger: Checking FileLog_az_Rauchmelder for notify
2012.11.02 09:58:38.302 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe for notify
2012.11.02 09:58:38.306 5: az_Thermostat trigger: Checking FileLog_az_Stehlampe2 for notify
2012.11.02 09:58:38.306 5: az_Thermostat trigger: Checking FileLog_az_Thermostat for notify
2012.11.02 09:58:38.314 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Climate for notify
2012.11.02 09:58:38.314 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_Weather for notify
2012.11.02 09:58:38.318 5: az_Thermostat trigger: Checking FileLog_az_Thermostat_WindowRec for notify
2012.11.02 09:58:38.318 5: az_Thermostat trigger: Checking FileLog_ba_PIDPWM for notify
2012.11.02 09:58:38.322 5: az_Thermostat trigger: Checking FileLog_ba_Thermostat for notify
2012.11.02 09:58:38.322 5: az_Thermostat trigger: Checking FileLog_fl_Rauchmelder for notify
2012.11.02 09:58:38.326 5: az_Thermostat trigger: Checking FileLog_gz_PIDPWM for notify
2012.11.02 09:58:38.326 5: az_Thermostat trigger: Checking FileLog_gz_Thermostat for notify
2012.11.02 09:58:38.330 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis1 for notify
2012.11.02 09:58:38.330 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis2 for notify
2012.11.02 09:58:38.338 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis3 for notify
2012.11.02 09:58:38.338 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis4 for notify
2012.11.02 09:58:38.342 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis5 for notify
2012.11.02 09:58:38.346 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis6 for notify
2012.11.02 09:58:38.346 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis7 for notify
2012.11.02 09:58:38.350 5: az_Thermostat trigger: Checking FileLog_ka_Heizkreis8 for notify
2012.11.02 09:58:38.350 5: az_Thermostat trigger: Checking FileLog_ku_PIDPWM for notify
2012.11.02 09:58:38.354 5: az_Thermostat trigger: Checking FileLog_ku_Rauchmelder for notify
2012.11.02 09:58:38.354 5: az_Thermostat trigger: Checking FileLog_ku_Thermostat for notify
2012.11.02 09:58:38.358 5: az_Thermostat trigger: Checking FileLog_sz_PIDPWM for notify
2012.11.02 09:58:38.358 5: az_Thermostat trigger: Checking FileLog_sz_Thermostat for notify
2012.11.02 09:58:38.362 5: az_Thermostat trigger: Checking FileLog_wz_PIDPWM for notify
2012.11.02 09:58:38.362 5: az_Thermostat trigger: Checking FileLog_wz_TasterEsstisch for notify
2012.11.02 09:58:38.366 5: az_Thermostat trigger: Checking FileLog_wz_Thermostat for notify
2012.11.02 09:58:38.366 5: az_Thermostat trigger: Checking Logfile for notify
2012.11.02 09:58:38.370 5: az_Thermostat trigger: Checking WEB for notify
2012.11.02 09:58:38.370 5: az_Thermostat trigger: Checking WEBphone for notify
2012.11.02 09:58:38.370 5: az_Thermostat trigger: Checking WEBtablet for notify
2012.11.02 09:58:38.374 5: az_Thermostat trigger: Checking autocreate for notify
2012.11.02 09:58:38.374 5: az_Thermostat trigger: Checking telnetPort for notify
2012.11.02 09:58:38.374 5: az_Thermostat trigger: Checking FHEMWEB:192.168.2.20:54690 for notify
2012.11.02 09:58:38.486 4: HTTP FHEMWEB:192.168.2.20:54692 GET /fhem?XHR=1&inform=console

[elo]

Ich hänge mich mal hier mit rein, ich habe vor 2 Tagen von 5.2 auf 5.3 geupdated, ca. 1/3 meiner Rollläden (wechselnd) laufen seit dem nicht mehr wie gewohnt.

z.B.

2012-11-02_07:25:00 KuecheRoll oben
2012-11-02_07:25:04 KuecheRoll MISSING ACK

Nutze den HMLAN und kein CUL.

Kann eigentlich bei "MISSING ACK" der Befehl nicht einfach nocheinmal gesendet werden?

[kohrti]

Hallo,
ich denke nicht, dass die Probleme identisch sind, da in diesem Thread der HM-CC-TC mit einem CUL/CUNO verwendet wird.

kannst du bitte einen neuen Thread öffnen? Dabei auch angeben welche Devices verwendet wurden.

Danke.

Gruß
kohrti

[Martin]

Hallo Kohrti

die traces waren die, die ich brauche.

Zu sehen ist, dass es gut beginnt. Dein TC schickt die ersten Daten der List0 vollstaendig. Danach wird List5 von Channel 2 (climate) angefragt.Das ist eine Lange liste, da werden 15 messages empfangen. Es kommt aber nur die erste an.

Das kann ich nicht steuern, die 15 Nachrichten kommen autonom aus dem TC. Wenn ich davon ausgehe, dass dein TC i.O. ist hat die CUL ein Problem, oder die FHEM-CUL sw.

CUL_HM ist also ok (jedenfalls bei diesem Versuch) - ich suche mal wieder weiter unten

Gruss
Martin

[Merhan]

Am Mittwoch, 31. Oktober 2012 23:25:48 UTC+1 schrieb Martin:

Die alte Version (5.2) akzeptiert mindestens 50 % der Kommandos. Die neue Version hat leider 0% Erfolg.

Folgende Fehlermeldungen tauchen bei mir in der Konsole auf:

habe noch keine Erklaerung.  Welche Versin CUL_HM war bei dir in 5.2? Arbeitsr du mit CUL oder HMLAN?

Ich habe HMLAN im Einsatz. CUL_HM Version 1407 2012-04-04 10:54:55Z rudolfkoenig

Sehr seltsam. Ich kann alle sonstigen HomeMatic Geräte mit der aktuellsten Version bedienen. Nur beim HM_CC_TC bekomme ich deterministisch nur MISSING ACKs

[/opt/share/fhem/FHEM] # Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

kann es sein, dass in deinen Readings ein falscher Wert steht, vor dem Kommando?
Schicke bitte ein 'list <TC>' vor und nach dem Fehler 

Use of uninitialized value in substitution (s///) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 3107.

Nach welchem Kommando kommt de Fehler?

Ich habe heute ein Update gemacht. Seitdem tauchen die Fehler nicht mehr auf. 

Ich habe beide Versionen auf meinem NAS und starte sie mit der selben fhem.cfg. Natürlich nicht gleichzeitig.

Mit der alten Version klappen wie gesagt gefühlt 50-70%.

Martin was meinst Du mit falschen Werten in den Readings? Wie kann ich diese zurücksetzen?

Meine Trace befinden sich im anderen Thread (link siehe mein vorheriger Post in diesem Thread)

Danke für die Unterstützung!

Grüße,

Merhan

 

[Martin]

Die alte Version (5.2) akzeptiert mindestens 50 % der Kommandos. Die neue Version hat leider 0% Erfolg.

Folgende Fehlermeldungen tauchen bei mir in der Konsole auf:

habe noch keine Erklaerung.  Welche Versin CUL_HM war bei dir in 5.2? Arbeitsr du mit CUL oder HMLAN?

Ich habe HMLAN im Einsatz. CUL_HM Version 1407 2012-04-04 10:54:55Z rudolfkoenig

Sehr seltsam. Ich kann alle sonstigen HomeMatic Geräte mit der aktuellsten Version bedienen. Nur beim HM_CC_TC bekomme ich deterministisch nur MISSING ACKs

Die meisten andern sind auch nicht so störrisch :-(

Ich habe heute ein Update gemacht. Seitdem tauchen die Fehler nicht mehr auf. 

gut

Ich habe beide Versionen auf meinem NAS und starte sie mit der selben fhem.cfg. Natürlich nicht gleichzeitig.

Mit der alten Version klappen wie gesagt gefühlt 50-70%.

Martin was meinst Du mit falschen Werten in den Readings? Wie kann ich diese zurücksetzen?

In der Alten Version wirden nicht alle Werte komplett geprüft. Da konnte man schon mal einen falschen eingeben. Die neue Prüft alle (also mehr). Readings kann man nicht einfach rücksetzen. Waere aber sinnvoll - da man sonst uralte Werte nicht los bekommt. Ein Verbesserungsvorschlag
 

Meine Trace befinden sich im anderen Thread (link siehe mein vorheriger Post in diesem Thread)

Muss ich noch bearbeiten - heute leider nicht mehr :-(

 

[unimatrix]

Hallo Martin et al,

ich sehe hier gerade dass noch massiv am HM-CC-TC gebastelt wird, das scheint ja auch ein Biest zu sein.

Jedenfalls habe ich hier:

4 x HM-CC-TC
5 x VD
2 Fenster/Türkontakte
1 HMLAN
2 CUl-Sticks (eig. für FS20 und RFR genutzt)

Wenn ich testmäßig was beitragen kann z.B. Mitloggen von Anlernvorgängen usw. dann sagt mir bitte was ich tun soll und ich stelle es hier ein.

Bei mir lässt sich auch die Temperatur nur in gefühlten 50% der Fälle setzen (bei denen im WOR Mode scheint es nicht unbedingt besser zu klappen) und auch das Setzen der Automatik-Temperaturen und -Zeiten ist nicht zuverlässig, soweit ich weiss, wird das auch nicht durch Auslesen verifiziert.

Ich habe die Dinger inzwischen auch mit dem HM-Config-Tool angelernt - also fhem stoppen, HM-Config Tool starten und dann damit anlernen, die HM-ID ist identisch - so habe ich zurzeit die Automatik-WErte konfiguriert weil das zuverlässiger ging. Vll. kann ich auch solche Sachen noch irgendwie loggen, falls sinnvoll.

Falls es noch weiter hilft, in der Schublade ist noch eine CCU mit der gleichen HMID ...da ich die gerade nicht benutze würde ich sie auch jemandem leihen, wenn das der Weiterentwicklung der Bedienung von HM-Komponenten zuträglich ist.

VG!

[Ulrich Maass]

Hi,

Mitschneiden des Anlernvorgangs VD an CC wäre gut, damit ein virtuelles VD gebaut werden kann.

Was da wie aufgezeichnet werden muss - Rudi, Martin?

Gruß Uli

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

[unimatrix]

also einfach hmProtocolEvents auf 5 und dann anlernen mit der Original HMLAN-Vorgangs?

Weil das ist ja eig. kein anlernen. Es wird erst das CC angelernt, dann das VD und dann wird per COnfig-Software eine Verknüpfung zwischen CC und VD hergestellt.

fhem-users+unsubscribe@googlegroups.com

[unimatrix]

sorry ich meinte natürlich mit der Originalsoftware des HM Konfigurationsadapters.

[kohrti]

Hallo Martin,

vielen Dank für die Erklärung. Nun sind wir ja schon einen riesigen Schritt weiter. Es tut mir Leid, dass irgendwie vieles an dir hängen bleibt. Mit der neuen Erkenntnis haben sich die Möglichkeiten aus meiner obigen Zusammenfassung reduziert:

Zusammenfassung:

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man muß nicht warten bis der CC aufwacht. -->Idee von Uwe
--> Aufgrund des Anratens von Rudolf und der Tatsache dass ein höherer Energieverbarauch damit einhergeht sollte das als letzte Möglichkeit betrachtet werden.

2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint nicht haltbar zu sein, obwohl ich daran glaube. Aus obigem Post sieht man aber, dass die Zeitdifferenz von 115ms + Kommunikation CC<->fhem anscheinend länger ist. Wie man End2End messen soll weiß ich nicht. Selbst mit Wireshark würde man nicht die Strecke CUNO-CC mitmessen. Reduktion des Loggings und LogFiles brachte keine Besserung. --> von kohrti
--> Mit den neuen Erkenntnissen von Martin sollte die Timing Geschichte nun klar sein: Es gibt dieses Timing Fenster wirklich, aber es war hier (wahrscheinlich) nicht der Fehler. (Die Zeitmessung nehme ich vor wenn Martin evtl. mehr aus seinem Graben "weiter unten" als in seinem Modul fertig ist.)

3. Anscheinend hatte das setzen von desired-temp in einer älteren fhem Version besser funktioniert. -->von Merhan
-->Soweit ich überblickt habe wird hier noch getestet und weitergearbeitet.

4. Das Beschleunigen des fhem Prozesses brachte keine Abhilfe. --> von kohrti

PS
Wenn es nervt, dass ich ab und zu eine Zusammenfassung mache bitte melden. Ich verliere sonst den Überblick. Es werden hier zwei Probleme diskutiert: 1. HM-CC-TC/VD/fhem und 2.
HM-CC-TC/fhem aber mindestens beide haben eben Problem mit "desired-temp" setzen.

[kohrti]

Hi Hary,

ich warte nochmal die Erkenntnisse von Martin (s.u.) ab und werde anschließend die Messungen vornehmen. Ich hab's nicht vergessen :)

Gruß
kohrti

Am Mittwoch, 31. Oktober 2012 14:01:43 UTC+1 schrieb fhem-hm-knecht:

[kohrti]

Hi Martin,

jetzt muss ich doch nochmal nachfragen wie du das Log File gelesen hast (in meiner unendichen Unwissenheiten und meiner unendlichen Wissbegierigkeit). Also aus meinem Log habe ich die relevanten (fetten) Zeilen hier nochmal ausgeschnitten. Nun versuchte ich vergeblich deine Aussage mit meinem Log zusammen zu bringen und bin irgendwie daraus nicht schlau geworden. Ich habe um ehrlich zu sein keine Ahnung aber vielleicht reichen ja schon wenige Wörter aus um mich auf den richtigen Weg zu bringen:

schnippschnapp

2012.11.02 09:58:10.100 5: CUL/RAW: /A0CEC86701D6A4300000000E436FF
2012.11.02 09:58:10.100 5: CUNO: A0CEC86701D6A4300000000E436 -74.5
2012.11.02 09:58:10.104 5: CUNO dispatch A0CEC86701D6A4300000000E436
2012.11.02 09:58:10.116 5: Triggering az_Thermostat (3 changes)

schnippschnapp

2012.11.02 09:58:26.809 5: Cmd: >set az_Thermostat getConfig<
2012.11.02 09:58:26.817 3: CUL_HM set az_Thermostat getConfig
2012.11.02 09:58:26.817 5: Triggering az_Thermostat (1 changes)

schnippschnapp

2012.11.02 09:58:36.139 5: CUL/RAW: /A1AED84001D6A430000002100394A4551303139353239365800FFFFF6
2012.11.02 09:58:36.139 5: CUNO: A1AED84001D6A430000002100394A4551303139353239365800FFFF -79
2012.11.02 09:58:36.143 5: CUNO dispatch A1AED84001D6A430000002100394A4551303139353239365800FFFF
2012.11.02 09:58:36.159 3: Device az_Thermostat added to ActionDetector with 000:10 time
2012.11.02 09:58:36.263 5: CUNO sending As104CA001F112341D6A4300040000000000
2012.11.02 09:58:36.263 5: SW: As104CA001F112341D6A4300040000000000
2012.11.02 09:58:36.275 5: Triggering az_Thermostat (0 changes)

schnippschnapp

2012.11.02 09:58:36.633 5: CUL/RAW: /A1A4C80101D6A43F11234020100020105000AF10B120C340F000000FF
2012.11.02 09:58:36.637 5: CUNO: A1A4C80101D6A43F11234020100020105000AF10B120C340F000000 -74.5
2012.11.02 09:58:36.637 5: CUNO dispatch A1A4C80101D6A43F11234020100020105000AF10B120C340F000000
2012.11.02 09:58:36.757 5: CUNO sending As104DA001F112341D6A4302040000000005
2012.11.02 09:58:36.757 5: SW: As104DA001F112341D6A4302040000000005
2012.11.02 09:58:36.769 5: Triggering az_Thermostat (0 changes)

schnippschnapp

2012.11.02 09:58:37.131 5: CUL/RAW: /A1A4DA0101D6A43F11234030109292C261828005800002426302C4EF9
2012.11.02 09:58:37.131 5: CUNO: A1A4DA0101D6A43F11234030109292C261828005800002426302C4E -77.5
2012.11.02 09:58:37.135 5: CUNO dispatch A1A4DA0101D6A43F11234030109292C261828005800002426302C4E
2012.11.02 09:58:37.147 5: Triggering az_Thermostat (0 changes)

schnippschnapp

2012.11.02 09:58:38.255 5: CUNO sending As104EA001F112341D6A4302040000000006
2012.11.02 09:58:38.255 5: SW: As104EA001F112341D6A4302040000000006
2012.11.02 09:58:38.266 5: Triggering az_Thermostat (1 changes)

schnippschnapp

Kann ich (ausser versuchen zu verstehen) im Moment noch etwas tun?

Gruß
kohrti

Am Freitag, 2. November 2012 19:02:56 UTC+1 schrieb Martin:

[Martin]

Mehran,

deine Maschine ist zu langsam.
Hast du die hmProtokolEvents aus dem HMLAN gelöscht? Sieht nicht so aus, nach dem Timing!!!

Gruss
Martin

[kohrti]

Kann es sein, dass hier der Hund begraben liegt?

2012.11.02 09:58:37.131 5: CUL/RAW: /A1A4DA0101D6A43F11234030109292C261828005800002426302C4EF9
2012.11.02 09:58:37.131 5: CUNO: A1A4DA0101D6A43F11234030109292C261828005800002426302C4E -77.5
2012.11.02 09:58:37.135 5: CUNO dispatch A1A4DA0101D6A43F11234030109292C261828005800002426302C4E
2012.11.02 09:58:37.147 5: Triggering az_Thermostat (0 changes)

2012.11.02 09:58:38.255 5: CUNO sending As104EA001F112341D6A4302040000000006
2012.11.02 09:58:38.255 5: SW: As104EA001F112341D6A4302040000000006
2012.11.02 09:58:38.266 5: Triggering az_Thermostat (1 changes)

Also, ich habe die Werte 09292C261828005800002426302C4E, die das Register RegL_05 (Climate) darstellt. -77.5 ist das RSSI. Diese Zahlenreihe kann ich nicht zuordnen (evtl. RegL_00?!): A1A4DA0101D6A43F112340301
Da dann im/nach dem letzten Block die Kommunkation abreißt, denke ich ist dieses abreißen der Fehler ?!

[Martin]

Zusammenfassung:

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man muß nicht warten bis der CC aufwacht. -->Idee von Uwe
--> Aufgrund des Anratens von Rudolf und der Tatsache dass ein höherer Energieverbarauch damit einhergeht sollte das als letzte Möglichkeit betrachtet werden.

Verstehe ich nicht ganz. Man kann einen Fensterkontakt an den TC pairen ( TC-channel 3). Habe es noch nicht getestet. Dann muss der TC wach bleiben. FHEM beruecksichtigt das nicht - wir warten sowieso. Es gaebe dann aber voraussichtlich keinen Timeout.
Probieren kannst du es ja - mit einem Taster oder du nimmst einen Virtuellen Taster
set <taste01> devicepair 0 TC_WinRec single set actor

Danach die Anlerntaste druecken - da sollte  mehr Zeit sein.

Danach testen ob das Timing Problem erschlagen ist. Ist evtl ein workaround.

2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint nicht haltbar zu sein, obwohl ich daran glaube. Aus obigem Post sieht man aber, dass die Zeitdifferenz von 115ms + Kommunikation CC<->fhem anscheinend länger ist. Wie man End2End messen soll weiß ich nicht. Selbst mit Wireshark würde man nicht die Strecke CUNO-CC mitmessen. Reduktion des Loggings und LogFiles brachte keine Besserung. --> von kohrti
--> Mit den neuen Erkenntnissen von Martin sollte die Timing Geschichte nun klar sein: Es gibt dieses Timing Fenster wirklich, aber es war hier (wahrscheinlich) nicht der Fehler. (Die Zeitmessung nehme ich vor wenn Martin evtl. mehr aus seinem Graben "weiter unten" als in seinem Modul fertig ist.) 

Das Fenster besteht. Wenn ihr genaues Timing messen wollt koennt ihr euch natuerlich nicht auf FHEM verlassen. Ihr muesst extern messen umsicher zu sein wie lange es dauert bis die message aus dem 'ethernet'  ueberhaupt in FHEM ankommt. Das Device rechnet ab seinem senden, nicht FHEM receive ;-).Ethernetsniffer ist fuer genaue Messungen erforderlich

3. Anscheinend hatte das setzen von desired-temp in einer älteren fhem Version besser funktioniert. -->von Merhan
-->Soweit ich überblickt habe wird hier noch getestet und weitergearbeitet. 

Habe Merhan geantwortet - sein Trace ist 130ms zu langsam - evtl. sind die Traces an.

4. Das Beschleunigen des fhem Prozesses brachte keine Abhilfe. --> von kohrti

Du hast aber eine CUL, richtig? Merhan nicht. Bitteauseinander halten.

PS
Wenn es nervt, dass ich ab und zu eine Zusammenfassung mache bitte melden. Ich verliere sonst den Überblick. Es werden hier zwei Probleme diskutiert: 1. HM-CC-TC/VD/fhem und 2.
HM-CC-TC/fhem aber mindestens beide haben eben Problem mit "desired-temp" setzen.

gerne zusammenfassung. Ich muss auch aufpassen, dass ich nicht die haelfte vergessen!

[Martin]

Das wird wohl die RegL5 sein.
Kann man nicht lesen da es eine Antwort auf einen request ist (getConfig....)
RegList5 hat 256 bytes - das sind die ersten 16. Es fehlen noch einige. RegList5 sieht etwa so aus

2012.11.04 00:39:08.497 1: HMLAN_Send:  SC8A4687F,00,00000000,01,C8A4687F,25A0011743BF172A8502040000000005


2012.11.04 00:39:08.912 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698AF91 d:FF r:FFD5m:25A010172A851743BF03012C1C18221828005800002422482A8A
2012.11.04 00:39:09.011 1: HMLAN_Parse: LANIf1 S:RC8A4687F stat:0001 t:0698AF96 d:FF r:FFD5m:25A010172A851743BF03012C1C18221828005800002422482A8A
2012.11.04 00:39:09.167 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B092 d:FF r:FFD5m:26A010172A851743BF03102A9022902890289028902890289028
2012.11.04 00:39:09.418 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B18F d:FF r:FFD5m:27A010172A851743BF031F902890289028902890289028902890
2012.11.04 00:39:09.673 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B28C d:FF r:FFD5m:28A010172A851743BF032E289028902890289028902890282422
2012.11.04 00:39:09.928 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B388 d:FF r:FFD5m:29A010172A851743BF033D482A8A2A9022902890289028902890
2012.11.04 00:39:10.175 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B485 d:FF r:FFD6m:2AA010172A851743BF034C289028902890289028902890289028
2012.11.04 00:39:10.430 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B582 d:FF r:FFD5m:2BA010172A851743BF035B902890289028902890289028902890
2012.11.04 00:39:10.681 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B67F d:FF r:FFD6m:2CA010172A851743BF036A282422482A8A2A9022902890289028
2012.11.04 00:39:10.936 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B77B d:FF r:FFD6m:2DA010172A851743BF0379902890289028902890289028902890
2012.11.04 00:39:11.186 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B877 d:FF r:FFD6m:2EA010172A851743BF0388289028902890289028902890289028
2012.11.04 00:39:11.441 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698B974 d:FF r:FFD5m:2FA010172A851743BF0397902890282422482A8A2A9022902890
2012.11.04 00:39:11.692 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698BA71 d:FF r:FFD5m:30A010172A851743BF03A6289028902890289028902890289028
2012.11.04 00:39:11.943 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698BB6E d:FF r:FFD5m:31A010172A851743BF03B5902890289028902890289028902890
2012.11.04 00:39:12.198 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698BC6A d:FF r:FFD5m:32A010172A851743BF03C4289028902890282422482A8A2A9022
2012.11.04 00:39:12.449 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698BD67 d:FF r:FFD5m:33A010172A851743BF03D3902890289028902890289028902890
2012.11.04 00:39:12.704 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698BE64 d:FF r:FFD5m:34A010172A851743BF03E2289028902890289028902890289028
2012.11.04 00:39:12.951 1: HMLAN_Parse: LANIf1 S:E172A85 stat:0000 t:0698BF5D d:FF r:FFD5m:35A010172A851743BF03F190289028902890289028


Die Messages kommen wie gesagt aus demTC - die CUL muss sie 'nur' anzeigen. Da sie dies  nicht macht ist es eindeutig dort ein Problem. Unabhaengig vom mode (Fensterkontakt) wird dies dein Arbeiten stoeren.
Meine CUL betreiben ich parallel mit HMLAN - ich habe alle Nachrichten erhalten (ein von ein Versuch)

Gruss
Martin

[kohrti]

s.u.

Am Sonntag, 4. November 2012 00:32:58 UTC+1 schrieb Martin:

Zusammenfassung:

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man muß nicht warten bis der CC aufwacht. -->Idee von Uwe
--> Aufgrund des Anratens von Rudolf und der Tatsache dass ein höherer Energieverbarauch damit einhergeht sollte das als letzte Möglichkeit betrachtet werden.

Verstehe ich nicht ganz. Man kann einen Fensterkontakt an den TC pairen ( TC-channel 3). Habe es noch nicht getestet. Dann muss der TC wach bleiben. FHEM beruecksichtigt das nicht - wir warten sowieso. Es gaebe dann aber voraussichtlich keinen Timeout.
Probieren kannst du es ja - mit einem Taster oder du nimmst einen Virtuellen Taster
set <taste01> devicepair 0 TC_WinRec single set actor

Danach die Anlerntaste druecken - da sollte  mehr Zeit sein.

Danach testen ob das Timing Problem erschlagen ist. Ist evtl ein workaround.

--> Teste ich bis Montag Abend. Hab virtuelle Buttons noch nicht eingesetzt, daher muss ich mich da einlesen.
 

2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint nicht haltbar zu sein, obwohl ich daran glaube. Aus obigem Post sieht man aber, dass die Zeitdifferenz von 115ms + Kommunikation CC<->fhem anscheinend länger ist. Wie man End2End messen soll weiß ich nicht. Selbst mit Wireshark würde man nicht die Strecke CUNO-CC mitmessen. Reduktion des Loggings und LogFiles brachte keine Besserung. --> von kohrti
--> Mit den neuen Erkenntnissen von Martin sollte die Timing Geschichte nun klar sein: Es gibt dieses Timing Fenster wirklich, aber es war hier (wahrscheinlich) nicht der Fehler. (Die Zeitmessung nehme ich vor wenn Martin evtl. mehr aus seinem Graben "weiter unten" als in seinem Modul fertig ist.) 

Das Fenster besteht. Wenn ihr genaues Timing messen wollt koennt ihr euch natuerlich nicht auf FHEM verlassen. Ihr muesst extern messen umsicher zu sein wie lange es dauert bis die message aus dem 'ethernet'  ueberhaupt in FHEM ankommt. Das Device rechnet ab seinem senden, nicht FHEM receive ;-).Ethernetsniffer ist fuer genaue Messungen erforderlich

-->Wir wollen Wireshark nehmen und direkt vor dem CUNO/CUL messen. Das war mal ein Testsetup von fhem-hm-knecht weiter oben im Thread.
 

3. Anscheinend hatte das setzen von desired-temp in einer älteren fhem Version besser funktioniert. -->von Merhan
-->Soweit ich überblickt habe wird hier noch getestet und weitergearbeitet. 

Habe Merhan geantwortet - sein Trace ist 130ms zu langsam - evtl. sind die Traces an.

4. Das Beschleunigen des fhem Prozesses brachte keine Abhilfe. --> von kohrti

Du hast aber eine CUL, richtig? Merhan nicht. Bitteauseinander halten.

-->Ja, ich habe eine CUNO (also gleich mit CUL).
@Merhan
Evtl. sollten wir diesen Thread in einen für CUL/CUNO und einen für HMLAN splitten?! Keine Ahnung ob das sinnvoll ist. Mir würde es helfen.
 

[kohrti]

Vielen vielen Dank. Jetzt hab ich was zum Nachdenken.... :)

[Merhan]

Servus Martin,

war bei mir noch nie drin.

Soe sieht meine HMLAN Definition in fhem.cfg aus:

define HMLAN1 HMLAN 192.168.3.9:1000

attr HMLAN1 hmId 67CA6C

ich habe hmProtokolEvents mal auf 0 gesetzt. Auch das hat nicht zum Erfolg geführt.

Das ganze läuft auf einem QNAP NAS. Das trace war mit mseclog =1  und verbose = 5 kann die Performance daran liegen? Das ist sonst verbose 3 und mseclog nicht definiert.

Ansonsten habe ich viele Log Dateien, die auf einen USB-Stick geschrieben werden. Kann das das Problem sein?

Danke & Grüße,

Merhan

[Christian Kohrt]

Hallo Merhan,

 

reduziere doch mal deine config auf das wesentliche, nämlich dein TC alleine und probiere es aus. Dauert nur 10 Minuten. Es ist schwer zu beurteilen ob Dateizugriffe schuld sein können.

 

Gruß

kohrti

--

To unsubscribe from this group, send email to

fhem-users+...@googlegroups.com

[kohrti]

Übrigens, das setzen der Temperaturprogramms, also zB:

fhem ("set ba_Thermostat tempListMon 04:00 21.0 06:00 23.0 07:00 23.0 12:00 21.0 16:00 21.0 18:00 23.0 24:00 23.0");

funktioniert(Perl Befehl absetzen und OK am TC drücken). Also grundsätzlich sollte die Kommunikation schon passen.

Ich bleib dran...

Am Sonntag, 4. November 2012 00:53:31 UTC+1 schrieb Martin:

[Sefi]

Also vermutlich oute ich mich jetzt als noob, aber das Problem mit dem MISSING ACK hatte ich auch am Anfang.
Problem war, das die Geräte nicht gepaart waren (da kannste suchen wie ein Depp ;)
Irgendwie hatte meine Fritzbox das Kommando set MYCUL hmPairForSec 600 nicht angenommen. Habe es dann direkt im Gerät gesetzt und siehe da - Pairing funktioniert, Temperatursteuerung funktioniert...

Vielleicht löst das Dein Problem?

[kohrti]

Vielen Dank für den Lösungsversuch!

Das Pairing funktioniert bei mir. ich habe etliche Lichtschalter, Aktoren und auch 6 HM-TC-CCs. Alles funktioniert prima, nur das Setzen der "desired-temp" nicht. Evtl. kann jemand berichten, ob man bei seinem CUL/CUNO "desried-temp" setzen kann. Martin hat ja HMLAN und CUL parallel im Einsatz und hat (deshalb?) keine Probleme. Es wäre schön wenn das jemand insbesondere mit einer CUNO testen könnte.

Ich weiß nicht ob Martin noch an der Sache dran ist, wenn nicht, werde ich meinen Workaround einbauen und die Sache selbst nochmal anschauen (mit wenig Hoffnung auf Erfolg, aber immerhin). Martin meinte ja das Problem läge im CUL oder in der FHEM-CUL Software.

Merhan hat ähnliche Probleme mit einer HMLAN, allerdings hat Martin herausgefunden, dass er ein Timing Problem hat (evtl. Logs etc.), ich hingegen habe kein Timing Problem.

Gruß
kohrti

[Uwe]

Hallo Leute, ich habe heute noch mein LOG gepostet - siehe oben.

Ich will mal noch meine Sicht zum gepairten RHS darlegen. Im "Auto" Modus des TC bewirkt er ja das Schließen der VDs bei geöffnetem/gekippten Fenster. Diese Funktion ist ein kleines "Trostpflaster" für meine bessere Hälfte, da ja sonst die FHEM-Ansteuerung leider noch nicht funzt. Bei uns ist es mit "Standarttagesprogrammen" schwierig, weil ich auf Montage bin und somit auch mal in der Woche frei habe und meine Freundin fast jeden Tag anders arbeitet. Deshalb bin ich sehr daran interessiert, dass wir die Ansteuerung des TC mit Fhem noch hin bekommen. Dann könnte ich die Tagesprogramme auch per VPN einspielen. Bis jetzt habe ich deshalb in Bad und Wohnzimmer jeweils Grundzeitintervalle definiert aber alle mit der gleichen Nachttemperatur hinterlegt. Bei Bedarf stellt man am TC die gewünschte Temp. ein und bis zur nächsten hinterlegten Schaltzeit wird diese dann geregelt. Danach gibt dann der TC die Nachttemperatur des folgendes Intervalls wieder vor.
BTW: Vielleicht hat jemand auch noch andere Ansätze für unregelmaßige Arbeits-/Heizzeiten.

Den RHS habe ich bis jetzt in meine Rollladensteuerung integriert, das funzt auch. Wenn dann die TC-Steuerung mal funzt, werde ich dann den RHS und den TC wieder unpairen (wg. Batt.). Bis dahin muss er mir im "Auto"-Modus des TC dienen - leider wird seine Stellung ja auch nicht in der Firmware des TC in allen Betriebsarten berücksichtigt (nur "Auto" und "Party").

Uwe

[littlebilly]

Hallo Uwe,

Am Montag, 5. November 2012 14:13:52 UTC+1 schrieb Uwe:

Hallo Leute, ich habe heute noch mein LOG gepostet - siehe oben.

Diese Funktion ist ein kleines "Trostpflaster" für meine bessere Hälfte, da ja sonst die FHEM-Ansteuerung leider noch nicht funzt.

Bei uns ist es mit "Standarttagesprogrammen" schwierig, weil ich auf Montage bin und somit auch mal in der Woche frei habe und meine Freundin fast jeden Tag anders arbeitet. Deshalb bin ich sehr daran interessiert, dass wir die Ansteuerung des TC mit Fhem noch hin bekommen. Dann könnte ich die Tagesprogramme auch per VPN einspielen.

 Das einfachste wäre doch den CUNO gegen HMLAN zu tauschen? bzw. HMLAN zusätzlich, da läuft alles!

BTW: Vielleicht hat jemand auch noch andere Ansätze für unregelmaßige Arbeits-/Heizzeiten

Unregelmässig lässt sich eigentlich nicht programmieren. Ich würde eine Basis Auto-Konfiguration anlegen und das Unregelmässige über Umschaltung auf  Mode "manual"  mit entsprechender Temperaturvorgabe abdecken.

Gruss Billy

[Uwe]

Hallo Billy, die Basiskonfig. habe ich ja sozusagen schon angelegt. Einen Tausch habe ich noch nicht erwogen, ich weiß nicht, ob für die Zukunft der CUNO die "universellere" Variante ist (z.B. IR). Wenn der TC nicht zu bezwingen sein sollte, dann müssten sich sicher noch ein paar mehr User darüber Gedanken machen.
Naja, vielleicht hilft ja ein Teil meines Logs Martin die Kommunikation TC-RHS zu verfolgen und vielleicht Schlussfolgerungen für die Fhem Ansteuerung zu gewinnen.

Uwe

[dou...@gmx.de]

...ohne zum Problem direkt was beitragen zu können, aber wo ist die Schwierigkeit?

Die HM-CC-TCs und HM-CC-VDs laufen bei mir wunderbar im Paarlauf. Selbst wenn fhem aussteigen würde, würden die ganz normal weiter arbeiten.

Das alles TCs ein Wochenprogramm mit auf den Weg gegeben wurde, setze ich natürlich voraus.

Da ich mit fhem lediglich die Zirkulationspumpe der Heizung weg/zuschalte, hab ich meiner besseren Hälfte den "Handbetrieb" Schalter im Keller gezeigt, mit dem sie die Pumpe manuell in Gang setzte kann, sollte mal etwas schief laufen.

Finde das so eine sehr robuste Lösung - auch ohne desired-temp

VG
Ralf

[Uwe]

@Ralf
An der Heizanlage kann ich nichts machen (Mehrfamilienhaus). Und unsere unregelmäßigen Arbeitszeiten und -tage ermöglichen (bis jetzt) kein sinnvolleres Heizkonzept; wie gesagt, ich will die Heizzeiten dann mit Fhem (z.T. via VPN) vorgeben.

Uwe

[Martin]

Hallo Zusammen,

ich habe gerade festgestellt, das HMLAN in seinem Eigenleben einige ACKs schickt, was die CUL nicht macht.
Da besteht handlungsbedarf - ich muss es mir noch einmal ansehen und dann ein paar aenderungen fuer CUL-user einbauen.

Dauert ein paar Tage - aber ich denke, da ist Licht am Ende des Tunnels.

Fuer alle HMLAN user wird dies nichts aendern.

Gruss
Martin

[kohrti]

Hallo!

Zum Thema Workaround für den TC.  Wir wollten dafür sorgen, dass der TC ständig online ist damit Befehle jederzeit angenommen werden: "desired-temp" setzen.

Ich habe jetzt nochmal versucht mit virtual buttons den HM-TC-CC einen Fensterkontakt anzulernen - ohne Erfolg. Auch mit einem Wandtaster oder einem HM-SCI-3-FM (Schalter Adapter) hat es nicht geklappt. Der TC ist mit fhem gepairt. Geht das überhaupt, einen beliebigen Sensor an den TC anzulernen? Ich sehe kein Window open oder closed im TC.

In der Anleitung steht was von WAKE-ON-RADIO-MODE. Der Sensor sendet also eine Message mit der der TC aufgeweckt wird. Kann es sein dass nur Tür/Fenster Sensoren angelernt werden können?

Gruß
kohrti

[kohrti]

Vielen Dank für die wunderbare Nachricht. Es ist zwar nicht gesagt, dass es (das setzen des "desired-temp" Wertes) danach funktioniert, aber die Hoffnung ist groß.

Ich teste gerne und kann auch implementieren sofern ich ein wenig Hilfe krieg.

Gruß,
kohrti

[Merhan]

Hallo Martin, hallo kohrti,

so nun habe ich fhem.cfg auf einen HM-CC-TC reduziert und die log Dateien vom Stick auf die NAS-Platten umgezogen. Immer noch zu 100% MISSING ACKS.

LOG-Dateien und fhem.cfg befinden sich im Anhang.

Martin, welche Firmware hat Dein HMLAN?

Das QNAP NAS müsste doch eigentlich genug Leistung haben?! Die CPU Auslastung während dessen ist zwischen 5% und 20%. Speicher ist auch genug da.

Grüße,

Merhan

fhem-users+unsubscribe@googlegroups.com

[Christian Kohrt]

Hallo Merhan,

 

ich weiß nicht ob die Idee sinnvoll ist, aber ein Versuch wäre es Wert:

 

Bei mir konnte ich hmProtokolEvents drin lassen zum Testen und mseclog =1  und verbose = 5 drin lassen und bin <205ms geblieben.

 

Die Vermutung war ja das das und deine Logs Prozessorlast verursachen. Ist ja nun gezeigt, dass dem nicht so ist. Daher würde mich interessieren, was du für Zeiten erhältst, wenn du obiges wieder einschaltest und im Log die Zeitdifferenz herausliest (laut fheem-hm-knecht):

 

„ich hatte folgenden Prüf-messaufbau

1.fhem auf 7390 mit ersten hmlan ip 192.168.2.80
2.ccu
3.fhem auf win7 mit zweiten hmlan ip 192.168.2.81 und wireshark um
direkt am HMlan zu schnüffeln,
damit man die Ergebnisse irgendwie vergleichen kann
Eintreffen der Nachricht vom TC<-->Eintreffen Nachricht (Have Data)  = Zeitdifferenz Luftschnittstelle

CCU ok = 202 - 205 msec
7390 ok = 200 msec
7390 nok = 208 msec

win7 ok = 110 msec“

 

Ich hatte das auch gemessen und war auch mit Logging unter 205ms besser <200ms (ich hatte minimale Konfiguration und auch den perl Prozess etwas beschleunigt, weiß aber nicht ob das nötig war).

 

Wenn du da unter 205ms bleibst, ist es kein Timing Problem, und du kannst woanders nach dem Problem suchen.

 

Beispiel von mir (fhem Log):

 

2012.11.06 14:22:56.369 3: CUL_HM set az_Thermostat desired-temp 16.5

2012.11.06 14:22:56.369 5: Triggering az_Thermostat (1 changes)

 

àAlso hier setze ich desired-temp.

 

2012.11.06 14:23:07.914 4: RCV L:0C N:35 F:86 CMD:70 SRC:az_Thermostat DST:broadcast 00D42A (WeatherEvent TEMP:21.2 HUM:42) (,WAKEMEUP,BCAST,RPTEN)

2012.11.06 14:23:07.914 5: Triggering CUNO (1 changes)

 

àJetzt meldet sich der TC.

 

2012.11.06 14:23:08.153 5: CUNO sending As090CA112F112341D6A43

2012.11.06 14:23:08.153 5: SW: As090CA112F112341D6A43

2012.11.06 14:23:08.165 4: SND L:09 N:0C F:A1 CMD:12 SRC:F11234 DST:az_Thermostat  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)

2012.11.06 14:23:08.165 5: Triggering CUNO (1 changes)

 

àSo, hier kommt irgendwann HAVE_DATA.

 

Zeit dt=14:23:08.165 - 14:23:07.914 = 251 ms

 

In diesem Fall also ist dt>205ms à Kann nicht gehenàTiming Problem.

 

Das habe ich gerade mit meiner vollen Konfiguration gemessen (alle devices, alle Logs, hmProtokolEvents=3; mseclog =1  und verbose = 5). Also kein Wunder.

 

Vielleicht auch eine blöde Idee: Messe mal die Ping Laufzeit, vielleicht hast du ja ein Netzwerk Problem.

 

Gruß

kohrti

 

PS

Ich habe eine CUNO. Also nur bedingt vergleichbar mit deiner HMLAN.

fhem-users+...@googlegroups.com

--
To unsubscribe from this group, send email to

fhem-users+...@googlegroups.com

[Merhan]

Hallo kohrti,

Danke für den Tipp. Im Anhang meine Ergebnisse.

Hier ein Auszug: Ich komme auf 198 ms bei eingeschaltetem hmProtocolEvents und trotzdem MISSING ACK.

2012.11.06 17:26:38.346 4: RCV L:0C N:B9 F:86 CMD:70 SRC:KUE_Heizung DST:broadcast 00A837 (WeatherEvent TEMP:0x00A8 HUM:0x37) (,WAKEMEUP,BCAST,RPTEN)

2012.11.06 17:26:38.363 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.383 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.403 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.424 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.443 5: HMLAN_Send:  -1A7A21

2012.11.06 17:26:38.463 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.483 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.503 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.523 5: HMLAN_Send:  +1A7A21,00,00,

2012.11.06 17:26:38.543 5: HMLAN_Send:  SD68B8576,00,00000000,01,D68B8576,01A11267CA6C1A7A21

2012.11.06 17:26:38.544 4: SND L:09 N:01 F:A1 CMD:12 SRC:67CA6C DST:KUE_Heizung  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)

Doofe Frage: Ich setze ein HMLAN ein und habe beide Versionen fhem-5.2 und fhem-5.3 auf dem NAS. Ich beende das eine und starte das andere.

Die TCs sind doch mit dem HMLAN gepaart. Ich muss mit der neuen Version nicht neu paaren, oder? 

Mit der alten habe ich nach wie vor > 50% Erfolg. 

Komplettes Log befindet sich im Anhang. Kann noch mal bitte einer schauen, ob meine Rechnung stimmt.

Danke & Grüße,

Merhan

[Christian Kohrt]

Also ich würde sagen Timing ist nicht Schuld.

 

Ob du bei einer neuen FHEM neu pairen musst weiß ich nicht würde ich aber mal probieren-sozusagen bei NULL anfangen. Ich bin ja auch noch nicht so lange dabei…

 

Hm, jetzt weiß ich auch nicht mehr weiter. Sorry.

 

Von: fhem-...@googlegroups.com [mailto:fhem-...@googlegroups.com] Im Auftrag von Merhan
Gesendet: Dienstag, 6. November 2012 20:29
An: fhem-...@googlegroups.com
Betreff: Re: [FHEM] Re: HM-CC-TC MISSING-ACK bei Einstellen desired-temp

 

Hallo kohrti,

--

[Merhan]

Neu pairen hat nichts verändert.

Anbei noch die Log-Datei. 

@Martin: Woran hastest Du gefolgert, dass mein System zu langsam ist. Wie erkenne ich die Reaktionszeit ohne die hmProtocolEvents?

Grüße,

Merhan

[kohrti]

Moin Merhan,

du könntest noch folgendes probieren:

1. shutdown fhem
2. statefile löschen (backup machen)
3. fhem starten

Dann sind deine readings ALLE weg.

Ich habe auch gesehen, dass dein TC auch noch mit den VDs gepairt ist. Ich würde tatsächlich ein reset des TCs versuchen und dann nur den nochmal testen. Ich weiß noch, dass die "Send/HaveData" irgendwie zusammen gehören müssen, weiß aber nicht wie.

Gruß
kohrti

Am Freitag, 2. November 2012 21:00:45 UTC+1 schrieb Merhan:

Am Mittwoch, 31. Oktober 2012 23:25:48 UTC+1 schrieb Martin:

Die alte Version (5.2) akzeptiert mindestens 50 % der Kommandos. Die neue Version hat leider 0% Erfolg.

Folgende Fehlermeldungen tauchen bei mir in der Konsole auf:

habe noch keine Erklaerung.  Welche Versin CUL_HM war bei dir in 5.2? Arbeitsr du mit CUL oder HMLAN?

Ich habe HMLAN im Einsatz. CUL_HM Version 1407 2012-04-04 10:54:55Z rudolfkoenig

Sehr seltsam. Ich kann alle sonstigen HomeMatic Geräte mit der aktuellsten Version bedienen. Nur beim HM_CC_TC bekomme ich deterministisch nur MISSING ACKs

[/opt/share/fhem/FHEM] # Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

Use of uninitialized value in bitwise or (|) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 1948.

kann es sein, dass in deinen Readings ein falscher Wert steht, vor dem Kommando?
Schicke bitte ein 'list <TC>' vor und nach dem Fehler 

Use of uninitialized value in substitution (s///) at /opt/share/fhem/FHEM/10_CUL_HM.pm line 3107.

Nach welchem Kommando kommt de Fehler?

Ich habe heute ein Update gemacht. Seitdem tauchen die Fehler nicht mehr auf. 

Ich habe beide Versionen auf meinem NAS und starte sie mit der selben fhem.cfg. Natürlich nicht gleichzeitig.

Mit der alten Version klappen wie gesagt gefühlt 50-70%.

Martin was meinst Du mit falschen Werten in den Readings? Wie kann ich diese zurücksetzen?

Meine Trace befinden sich im anderen Thread (link siehe mein vorheriger Post in diesem Thread)

Danke für die Unterstützung!

Grüße,

Merhan

 

[kohrti]

Wo ist denn in deinem alten Log das "Have_DATA" ? Ich kenne mich noch nicht so gut aus, aber mich würde auch interessieren, wie ich sehe warum deine machicne zu langsam ist. Das war doch dein Log aus dem anderen Thread oder?

2012.10.30 22:08:00.575 4: Connection closed for FHEMWEB:192.168.3.10:49894

2012.10.30 22:08:11.837 5: Cmd: >set WZ_Heizung desired-temp 21.0<

2012.10.30 22:08:11.838 3: CUL_HM set WZ_Heizung desired-temp 21.0

2012.10.30 22:08:11.839 5: Triggering WZ_Heizung (1 changes)

2012.10.30 22:08:11.843 5: WZ_Heizung trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:08:12.289 5: HMLAN_Parse: HMLAN1 S:E1938A1 stat:0000 t:F5DB6E0F d:FF r:FFAFm:0586701938A100000000A231

2012.10.30 22:08:12.290 5: HMLAN1 dispatch A0C0586701938A100000000A231

2012.10.30 22:08:12.299 5: Triggering DG_SZ_Heizung (3 changes)

2012.10.30 22:08:12.302 5: DG_SZ_Heizung trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:08:12.926 5: HMLAN_Send:  K

2012.10.30 22:08:12.930 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245123 d:174037 O:67CA6C m:F5DB7097 d2:0004

2012.10.30 22:08:23.760 4: Connection accepted from FHEMWEB:192.168.3.10:49906

2012.10.30 22:08:23.762 4: HTTP FHEMWEB:192.168.3.10:49906 GET /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log

2012.10.30 22:08:24.015 4: /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log / RL: 1316543 / text/html; charset=UTF-8 /  / 

2012.10.30 22:08:24.422 4: Connection accepted from FHEMWEB:192.168.3.10:49907

2012.10.30 22:08:24.424 4: HTTP FHEMWEB:192.168.3.10:49907 GET /fhem/icons/icoEverything

2012.10.30 22:08:24.431 4: /fhem/icons/icoEverything / RL: 344 / image/png /  / Expires: Tue Oct 30 22:23:24 2012 GMT

2012.10.30 22:08:32.289 5: HMLAN_Parse: HMLAN1 S:E1938A1 stat:0000 t:F5DBBC32 d:FF r:FFB0m:05A2581938A1193CA800FF

2012.10.30 22:08:32.289 5: HMLAN1 dispatch A0B05A2581938A1193CA800FF

2012.10.30 22:08:32.298 5: Triggering DG_SZ_HZ_Stellantrieb_1 (1 changes)

2012.10.30 22:08:32.302 5: DG_SZ_HZ_Stellantrieb_1 trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:08:32.342 5: Triggering DG_SZ_Heizung (1 changes)

2012.10.30 22:08:32.348 5: DG_SZ_Heizung trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:08:32.419 5: HMLAN_Parse: HMLAN1 S:E193CA8 stat:0000 t:F5DBBCB7 d:FF r:FFBCm:058202193CA81938A10101C8002E

2012.10.30 22:08:32.434 5: HMLAN_Send:  -193CA8

2012.10.30 22:08:32.454 5: HMLAN_Send:  +193CA8

2012.10.30 22:08:32.455 5: HMLAN1 dispatch A0E058202193CA81938A10101C8002E

2012.10.30 22:08:32.464 5: Triggering DG_SZ_HZ_Stellantrieb_1 (2 changes)

2012.10.30 22:08:32.470 5: DG_SZ_HZ_Stellantrieb_1 trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:08:37.954 5: HMLAN_Send:  K

2012.10.30 22:08:37.958 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245123 d:174037 O:67CA6C m:F5DBD260 d2:0004

2012.10.30 22:08:44.773 5: HMLAN_Parse: HMLAN1 S:E19CA61 stat:0000 t:F5DBECFA d:FF r:FFC1m:56867019CA6100000000C929

2012.10.30 22:08:44.781 5: HMLAN1 dispatch A0C56867019CA6100000000C929

2012.10.30 22:08:44.806 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:44.826 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:44.846 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:44.866 5: HMLAN_Send:  -19CA61

2012.10.30 22:08:44.886 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:44.906 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:44.926 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:44.946 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:44.966 5: HMLAN_Send:  SB381484C,00,00000000,01,B381484C,84A11267CA6C19CA61

2012.10.30 22:08:44.968 5: Triggering WZ_Heizung (3 changes)

2012.10.30 22:08:44.972 5: WZ_Heizung trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:08:45.570 5: HMLAN_Parse: HMLAN1 S:RB381484C stat:0008 t:00000000 d:FF r:7FFFm:84A11267CA6C19CA61

2012.10.30 22:08:45.586 5: HMLAN_Send:  +67CA6C

2012.10.30 22:08:45.587 5: HMLAN1 dispatch A0984A11267CA6C19CA61NACK

2012.10.30 22:08:46.994 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:47.014 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:47.034 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:47.055 5: HMLAN_Send:  -19CA61

2012.10.30 22:08:47.075 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:47.094 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:47.114 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:47.135 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:47.155 5: HMLAN_Send:  SB38150D9,00,00000000,01,B38150D9,84A11267CA6C19CA61

2012.10.30 22:08:47.155 4: CUL_HM_Resend: WZ_Heizung nr 2

2012.10.30 22:08:47.759 5: HMLAN_Parse: HMLAN1 S:RB38150D9 stat:0008 t:00000000 d:FF r:7FFFm:84A11267CA6C19CA61

2012.10.30 22:08:47.774 5: HMLAN_Send:  +67CA6C

2012.10.30 22:08:47.775 5: HMLAN1 dispatch A0984A11267CA6C19CA61NACK

2012.10.30 22:08:48.186 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:48.206 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:48.226 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:48.246 5: HMLAN_Send:  -19CA61

2012.10.30 22:08:48.266 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:48.286 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:48.306 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:48.326 5: HMLAN_Send:  +19CA61,00,00,

2012.10.30 22:08:48.346 5: HMLAN_Send:  SB3815580,00,00000000,01,B3815580,84A11267CA6C19CA61

2012.10.30 22:08:48.346 4: CUL_HM_Resend: WZ_Heizung nr 3

2012.10.30 22:08:48.949 5: HMLAN_Parse: HMLAN1 S:RB3815580 stat:0008 t:00000000 d:FF r:7FFFm:84A11267CA6C19CA61

2012.10.30 22:08:48.966 5: HMLAN_Send:  +67CA6C

2012.10.30 22:08:48.967 5: HMLAN1 dispatch A0984A11267CA6C19CA61NACK

2012.10.30 22:08:49.356 5: Triggering WZ_Heizung (1 changes)

2012.10.30 22:08:49.360 5: WZ_Heizung trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:09:02.994 5: HMLAN_Send:  K

2012.10.30 22:09:02.998 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245123 d:174037 O:67CA6C m:F5DC3434 d2:0004

2012.10.30 22:09:04.772 5: HMLAN_Parse: HMLAN1 S:E19CA61 stat:0000 t:F5DC3B1D d:FF r:FFC0m:56A25819CA611877E7004C

2012.10.30 22:09:04.773 5: HMLAN1 dispatch A0B56A25819CA611877E7004C

2012.10.30 22:09:04.781 5: Triggering WZ_HZ_Stellantrieb_3 (1 changes)

2012.10.30 22:09:04.787 5: WZ_HZ_Stellantrieb_3 trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:09:04.827 5: Triggering WZ_Heizung (1 changes)

2012.10.30 22:09:04.831 5: WZ_Heizung trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:09:04.907 5: HMLAN_Parse: HMLAN1 S:E1877E7 stat:0000 t:F5DC3BA0 d:FF r:FFCDm:5682021877E719CA6101013A0036

2012.10.30 22:09:04.926 5: HMLAN_Send:  -1877E7

2012.10.30 22:09:04.946 5: HMLAN_Send:  +1877E7

2012.10.30 22:09:04.947 5: HMLAN1 dispatch A0E5682021877E719CA6101013A0036

2012.10.30 22:09:04.956 5: Triggering WZ_HZ_Stellantrieb_3 (4 changes)

2012.10.30 22:09:04.960 5: WZ_HZ_Stellantrieb_3 trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:09:05.021 5: CUL/RAW: /E0101F39A6003009B0425

2012.10.30 22:09:05.022 5: CUL1: E0101F39A6003009B04 -55.5

2012.10.30 22:09:05.022 5: CUL1 dispatch E0101F39A6003009B04

2012.10.30 22:09:05.032 5: CUL_EM CUL_EM_1: CNT: 243 CUM: 24730  5MIN: 3  TOP: 1179

2012.10.30 22:09:05.033 4: CUL_EM CUL_EM_1: CNT: 243 CUM: 1203.547  5MIN: 0.480  TOP: 0.407

2012.10.30 22:09:05.035 5: Triggering CUL_EM_1 (10 changes)

2012.10.30 22:09:05.038 5: CUL_EM_1 trigger: Checking AZ_Remote_Bnt2_off for notify

...

2012.10.30 22:09:23.750 4: Connection closed for FHEMWEB:192.168.3.10:49907

2012.10.30 22:09:23.752 4: Connection closed for FHEMWEB:192.168.3.10:49906

2012.10.30 22:09:28.026 5: HMLAN_Send:  K

2012.10.30 22:09:28.030 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245123 d:174037 O:67CA6C m:F5DC9600 d2:0005

2012.10.30 22:09:35.399 4: Connection accepted from FHEMWEB:192.168.3.10:49914

2012.10.30 22:09:35.401 4: HTTP FHEMWEB:192.168.3.10:49914 GET /fhem?cmd=logwrapper%20Logfile%20text%20fhem-2012-10.log

[Merhan]

Hallo kohrti,

Satefile löschen hat leider auch nicht geholfen. Ich habe gerade nur Remotezugriff. Ich werde die Tage mal ein nagelneues TC in Betrieb nehmen.

Ich habe allerdings bereits ein Neues mit der neuen Version in Betrieb genommen. Das hatte auch mehr Readings als die anderen. Trotzdem nur MISSING ACKS.

Ich würde gerne das pairing verstehen. Debuggen läuft in der Regel besser, wenn man den Sachverhalt verstanden hat.

Erfolgt das pairing zwischen dem HM-Aktor und dem LAN-Adapter? Wo wird die Information wer mit wem gepaart ist gespeichert? Im Aktor und im HMLAN, oder im Aktor und irgendwo in fhem?

Danke & Grüße,

Merhan

[Christian Kohrt]

Ich muss raten dass die info im aktor etc und in fhem also zumindest nicht im cul/cuno. Jeder kennt den anderen. Aber wie gesagt nur geraten. 

Von meinem iPhone gesendet

[Martin]

Hi zusammen,

habe eben eine neue Version hochgeladen.
Das Verhalten der ACKs ist geaendert - aus den Erkenntnissen der traces und der Details des HMLAN, die ich bisher nicht gesehen hatte.

CUL funktioniert jetzt mit meinem TC und VD ohne Probleme.

HMLAN hat noch die gleichen Probleme - nicht beim TC aber bei sonstigen laengeren Uebertragungen.

Zusammenfassend: Die CUL ist deutlich schneller - und hat etwas weniger timingprobleme. HMLAN hat noch denNachteil,dass ich das Eigenleben nicht verstanden habe. Manchmal unterbricht sie das Senden.... Ohne beschreibung bedarf es noch einiger experimente um sie wirklich stabil zu bekommen.
CUL hat sich auch manchmal aufgehaengt - dann musste ich neu starten. Kommt aber selten vor.

Viel Erfolg

Martin
PS: die Aenderung betrifft auch HMLAN. Ich habe keinen Unterschied in der Performance festgestellt - muss aber noch beobachtet werden.

[Merhan]

Hi Martin,

bekomme ich diese über das normale update? Ich bekomme die Meldung es gäbe nichts neues und meine CUL_HM ist 

 $Id: 10_CUL_HM.pm 2087 2012-11-05 21:56:00Z martinp876 $

Danke für Deine Mühen!

Merhan

[Merhan]

Hat sich erledigt.

Habe Deinen Beitrag im anderen Thread gesehen. Ich warte dann bis morgen ;-)

Merhan

[dou...@gmx.de]

Moin zusammen,

bin dauerhaft beeindruckt von der Arbeit, die hier geleistet wird. Grosses Kino! Vielen Dank!

Ist es ev. strategisch sinnvoll hier noch mal das HM-OU-LED16 Display zu erwähnen?

Oder soll das in einen anderen Thread? Ich hab immer noch das Problem, das die Kommandos, die vom Display gesendet werden, ein, zwei oder drei mal b ei fhem ankommen. Mal mit ACK mal ohne.

VG
Ralf

[Martin]

In einem Andere Thread bitte - und gleich mit logs waere gut

Ist es ev. strategisch sinnvoll hier noch mal das HM-OU-LED16 Display zu erwähnen?

Oder soll das in einen anderen Thread? Ich hab immer noch das Problem, das die Kommandos, die vom Display gesendet werden, ein, zwei oder drei mal b ei fhem ankommen. Mal mit ACK mal ohne.

In einem Andere Thread bitte - und gleich mit logs waere gut

Gruss
Martin

[Christian Kohrt]

Hallo Martin,

 

Ich habe heute um20 Uhr ein Update gemacht und da waren auch seit gestern einige Dateien dabei, jedoch bekomme ich immer noch MissingAck wenn ich versuche die „desired-temp“ einzustellen.

 

Ich habe ein CUNO. Kann ich davon ausgehen, dass du mit CUL auch CUNO meinst?

 

Vielen Dank für die Arbeit die du hier leistest!

 

Beste Grüße,

kohrti

 

Von: fhem-...@googlegroups.com [mailto:fhem-...@googlegroups.com] Im Auftrag von Martin
Gesendet: Mittwoch, 7. November 2012 20:33
An: fhem-...@googlegroups.com
Betreff: Re: [FHEM] Re: HM-CC-TC MISSING-ACK bei Einstellen desired-temp

 

Hi zusammen,

--

To unsubscribe from this group, send email to

fhem-users+...@googlegroups.com

[Martin]

Ich habe heute um20 Uhr ein Update gemacht und da waren auch seit gestern einige Dateien dabei, jedoch bekomme ich immer noch MissingAck wenn ich versuche die „desired-temp“ einzustellen.

eine CUNO habe ich nicht zum testen - erwarte aber das die im Prinzip wie eine CUL arbeitet - also full-transparent, nicht wie HMLAN.
Aber auch bei der CUL habe ich noch Defizite - wenn man etwas schneller sendet steigt sie komplett aus. Die CUNO koennte also ein anderes Timing haben/brauchen. 
Kannst du noch einmal eine log ziehen?   Einfach nur von Temp setzen.
Kannst du die Temp auch am TC verstellen? Auch loggen

Danke
Martin

[Merhan]

Hallo Martin,

ich habe ebenfalls ein Update gefahren und keinen Erfolg.

Ich habe eine Geräte entfernt, statefile gelöscht, einen TC zurückgesetzt und neu gepairt.

Das log mit verbose 5 und mseclog 1 sowie die aktuelle fhem.cfg findest Du im Anhang. 

Ich habe auch validiert, dass mein HMLAN die neuste Firmware hat. 

Ich danke Dir für Deine Mühen. Gerne kann ich Dir auch Zugriff zu meinem System ermöglichen, wenn Dir das hilft.

Viele Grüße,

Merhan

[Martin]

das geht zu langsam (nicht nur mein debuggen, hier in speziellen das senden deiner messages)

Konkret: meine FB benoetigt zu zum senden der "praeambel" 83ms,  deine HW aber 161 - also doppelt so lange. Ist also ein Performance Problem.

Probier mal die Version im Anhang.
Achtung Mitleser: Wenn es bei euch Funktioniert, dann diese Version NICHT benutzen. Die wird so sicher nicht eigelagert werden!

ggf. noch einmal die gleichen Logs posten

Gruss
Martin

[Christian Kohrt]

OK, mach ich.

 

Martin <marti...@gmail.com> hat am 8. November 2012 um 22:10 geschrieben:

--