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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

Mehran,

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

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

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: *A1A4DA0101D6A43F112340301**
09292C261828005800002426302C4E* -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 ?!*
*

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

[Guest]

Originally posted by: <email address deleted>

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

>
>

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

[Guest]

Originally posted by: <email address deleted>

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

Am Sonntag, 4. November 2012 00:23:20 UTC+1 schrieb 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: *A1A4DA0101D6A43F112340301**
> 09292C261828005800002426302C4E* -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 ?!*
> *

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

[Guest]

Originally posted by: <email address deleted>

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

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

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

[Guest]

Originally posted by: <email address deleted>

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

Am Sonntag, 4. November 2012 00:53:31 UTC+1 schrieb 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
>
> Am Sonntag, 4. November 2012 00:23:20 UTC+1 schrieb 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: *A1A4DA0101D6A43F112340301**
>> 09292C261828005800002426302C4E* -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 ?!*
>> *
>
>

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

[Guest]

Originally posted by: <email address deleted>

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



Am Sonntag, 4. November 2012 00:15:56 UTC+1 schrieb 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
>
>

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

[Guest]

Originally posted by: <email address deleted>

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

 

Von: fhem-users@googlegroups.com [mailto:fhem-users@googlegroups.com (fhem-users@googlegroups.com)] Im
Auftrag von Merhan
Gesendet: Sonntag, 4. November 2012 17:53
An: fhem-users@googlegroups.com
Betreff: [FHEM] Re: HM-CC-TC MISSING-ACK bei Einstellen desired-temp

 

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

 

 


Am Sonntag, 4. November 2012 00:15:56 UTC+1 schrieb 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

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

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

[Guest]

Originally posted by: <email address deleted>

Ü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:
>
> 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
>
> Am Sonntag, 4. November 2012 00:23:20 UTC+1 schrieb 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: *A1A4DA0101D6A43F112340301**
>> 09292C261828005800002426302C4E* -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 ?!*
>> *
>
>

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

[Guest]

Originally posted by: <email address deleted>

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?

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

[Guest]

Originally posted by: <email address deleted>

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

Am Montag, 5. November 2012 10:11:59 UTC+1 schrieb 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?
>

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

[locodriver]

                                                         

Habe das Log mal gezipped. Hoffe, dass ich es jetzt hoch geladen bekomme.
Uwe

Am Samstag, 3. November 2012 21:31:35 UTC+1 schrieb Uwe:
>
> Leider bekomme ich das Log-File nicht hochgeladen (Server Fehler 340). ich
> versuche, es direkt an Martin zu schicken.
>
>
> Am Samstag, 3. November 2012 20:35:36 UTC+1 schrieb Uwe:
>>
>> Hallo Miteinander,
>>
>> heute will ich mich - wie angekündigt - wieder melden und mein Log-File
>> zur Auswertung zur Verfügung stellen.
>>
>> Erstmal zur Korrektur: wenn ich weiter oben vom CC geschrieben habe, so
>> meinte ich natürlich den TC (war nicht zu Hause und habe das aus dem Kopf
>> geschrieben).
>>
>> Nun zu meinem LOG:
>> Erstmal ein paar Erklärungen. Hk0 und Hk1 sind zwei vom TC WZ_Regler
>> geregelte Heizkörper, WZ_Balkon ist ein gepairter RHS (Three State
>> Fensterkontakt).
>> Die VDs und den RHS habe ich erst mit dem TC gepaired und dann alles mit
>> Fhem. Ich habe noch Version 5.2 mit neuer Struktur.
>> Aus dem Log habe ich offensichtlich nicht erforderliche Geräte gelöscht
>> und das Log mit verbose 5 laufen lassen.
>> Ab ca. 19:18 habe ich den RHS von zu nach offen und dann gekippt betätigt
>> und dann wieder zurück. Das Fenstersymbol im TC erscheint auch nach kurzer
>> Verzögerung.
>> Ab ca. 19:19:34 habe ich mit Fhem die Disired-temp auf 24°C gesetzt -
>> nach einiger Zeit kam das Missing-Ack zurück. Danach habe ich noch am TC
>> manuell 24°C eingestellt - das hat er akzeptiert und Fhem hat es dann auch
>> auf der Weboberfläche zurückgegeben.
>>
>> Ich hoffe es hilft weiter. Das Log hat allerdings noch rund 800 Zeilen
>> (ich wollte nichts wichtiges löschen).
>>
>> Uwe
>>
>> Am Freitag, 2. November 2012 19:02:56 UTC+1 schrieb 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
>>>
>>

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

[locodriver]

                                                         

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





Am Montag, 5. November 2012 10:21:15 UTC+1 schrieb 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
>
> Am Montag, 5. November 2012 10:11:59 UTC+1 schrieb 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?
>>
>

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

[Billy]

                                                         

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

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