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

[Guest]

Originally posted by: <email address deleted>

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

Am Mittwoch, 31. Oktober 2012 10:23:55 UTC+1 schrieb dou...@m1n1.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.
>

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

[Guest]

Originally posted by: <email address deleted>

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

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

[rudolfkoenig]

                                                   

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

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

[Guest]

Originally posted by: <email address deleted>

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.

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

[Guest]

Originally posted by: <email address deleted>

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

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

[LuckyDay]

                                         

> 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

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

[Guest]

Originally posted by: <email address deleted>

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.

Am Mittwoch, 31. Oktober 2012 14:01:43 UTC+1 schrieb 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
>
>

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

[LuckyDay]

                                         

> 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

On 31 Okt., 14:12, kohrti wrote:
> 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.
>
> Am Mittwoch, 31. Oktober 2012 14:01:43 UTC+1 schrieb 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

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

[Guest]

Originally posted by: <email address deleted>

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?

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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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

>
>

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

[Guest]

Originally posted by: <email address deleted>

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 getConfig abgesetzt und dann OK gedrückt. Mehrere
Male wiederholt, immer das gleiche Ergebnis.

Grüße,
kohrti


Am Mittwoch, 31. Oktober 2012 22:52:15 UTC+1 schrieb 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 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
>
>

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

[Guest]

Originally posted by: <email address deleted>

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.




> 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 getConfig abgesetzt und dann OK gedrückt. Mehrere
> Male wiederholt, immer das gleiche Ergebnis.
>
> Grüße,
> kohrti
>
>
> Am Mittwoch, 31. Oktober 2012 22:52:15 UTC+1 schrieb 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 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
>>
>>

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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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

Am Freitag, 2. November 2012 08:22:42 UTC+1 schrieb 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
>

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