Befehle kommen bei HM-CC-TC nur sporadisch an

[Merhan Öztürk]

Nach einigen Stunden habe ich folgendes Ergebnis:

- Stellantrieb mit HM-CC-TC gepaart
- HM-CC-TT mit FHEM gepaart

- Alle Nachrichten von HM-CC-TC kommen bei FHEM an. (z.B. wenn die
SOLL-Temperatur am Gerät manuell verändert wurde sowie die zyklischen
Benachrichtigungen über die IST-Daten)

- die meisten Befehle von FHEM zum HM-CC-TC kommen nur sporadisch an.
Ich habe zwar einige hinbekommen, jedoch mit x-mal ausprobieren

Meist folgt auf einen set desired-temp Befehl ein Missing-Ack.
Manchmal funktioniert es und es kommt ein desired-temp-ack zurück.

Auf der Kommandozeile (nicht in der Telnet-Sitzung) bekomme ich
machmal folgende Meldung:

# Use of uninitialized value in sprintf at /opt/share/fhem/FHEM/
10_CUL_HM.pm line 455.

Ich bin jetzt kein Linux-Kenner - jedoch wundert mich die Ausgabe in
der Shell.

Any Ideas?

Viele Grüße,
Merhan

[itjunky]

Hallo,

vielleicht vorher in der Group mal nach ähnlichen Problemen suchen.

Hier vielleicht :
http://groups.google.com/group/fhem-users/browse_thread/thread/2fe4abe2f299d795/b5f2cebb39c90baa?hl=de&lnk=gst&q=Missing+Ack#b5f2cebb39c90baa

Viele Grüße

Michael

On 24 Apr., 03:13, Merhan Öztürk <merhan.oeztu...@googlemail.com>
wrote:

[Merhan Öztürk]

Danke für den Hinweis. Diesen Thread habe ich bereits studiert und er
hat mir leider nicht geholfen.
Der letzte Eintrag ist vom 21. Dez und da in der Wiki ein Artikel zu
HM_CC_TT vorhanden ist dachte ich, dass der Thread veraltet ist.

Laut diesem Thread ist die Unterstützung für HM_CC_TC noch nicht
vollständing implementiert:
In diesem
http://groups.google.com/group/fhem-users/browse_thread/thread/f48693ad0fd075ef/53dc546320a58adc?hl=de&lnk=gst&q=+HM-CC-TC#53dc546320a58adc

Mein nächstes Projekt war sowieso das Mitlesen einzurichten.
Freue mich über neue Erkenntnisse.

Grüße,
Merhan

On 24 Apr., 08:50, itjunky <michael.schu...@consultpool.de> wrote:
> Hallo,
>
> vielleicht vorher in der Group mal nach ähnlichen Problemen suchen.
>

> Hier vielleicht :http://groups.google.com/group/fhem-users/browse_thread/thread/2fe4ab...

[Merhan Öztürk]

Einträge aus der LOG-Datei mit Verbose 5:
zwei mal den Befehl set desired-temp abgesetzt. Auch wenn es
funktioniert, dauert es recht lange bis ein desired-temp-ack kommt.
Im ersten Beispiel kommt die Message nach ca. 30 Sek.
Der zweite Befehl führte zu einem MISSING-ACK

///////// Befehl: >set WZ_Heizung desired-temp 16<

2012.04.24 12:07:18 5: SW: K
2012.04.24 12:07:18 5: HMLAN/RAW: /HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0D9FDD9E,0004
2012.04.24 12:07:18 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0D9FDD9E,0004
2012.04.24 12:07:18 5: Cmd: >set WZ_Heizung desired-temp 16<
2012.04.24 12:07:18 2: CUL_HM set WZ_Heizung desired-temp 16
2012.04.24 12:07:18 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:07:18 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.

///////// Reaktion nach einer Weile:

2012.04.24 12:07:43 5: SW: K
2012.04.24 12:07:43 5: HMLAN/RAW: /HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0DA03F72,0004

2012.04.24 12:07:43 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0DA03F72,0004
2012.04.24 12:08:03 5: HMLAN/RAW: /
E19CA61,0000,0DA08C6E,FF,FFC3,03867019CA6100000000C62B

2012.04.24 12:08:03 5: HMLAN_Parse: HMLAN1
E19CA61,0000,0DA08C6E,FF,FFC3,03867019CA6100000000C62B
2012.04.24 12:08:03 5: HMLAN1 dispatch A0C03867019CA6100000000C62B
2012.04.24 12:08:03 4: RCV L:0C N:03 CMD:8670
(TYPE=112,WAKEMEUP,BCAST,RPTEN) SRC:19CA61 DST:000000 00C62B
2012.04.24 12:08:03 5: SW: SE3D27A2D,00,00000000,01,E3D27A2D,
10A11267CA6C19CA61
2012.04.24 12:08:03 4: SND L:09 N:10 CMD:A112
(TYPE=18,WAKEUP,BIDI,RPTEN) SRC:67CA6C DST:19CA61 (HAVE_DATA)
2012.04.24 12:08:03 5: Triggering WZ_Heizung (0 changes)
2012.04.24 12:08:03 5: WZ_Heizung trigger: Checking Aufstehen for
notify



////////// hier ein Beispiel für ein Missing-Ack
////////// Befehl: >set WZ_Heizung desired-temp 15<

2012.04.24 12:18:20 5: HMLAN/RAW: /
E1877E7,0000,0DA9F96B,FF,FFC9,0782021877E719CA610101000031

2012.04.24 12:18:20 5: HMLAN_Parse: HMLAN1
E1877E7,0000,0DA9F96B,FF,FFC9,0782021877E719CA610101000031
2012.04.24 12:18:20 5: HMLAN1 dispatch A0E0782021877E719CA610101000031
2012.04.24 12:18:20 4: RCV L:0E N:07 CMD:8202 (TYPE=2,WAKEMEUP,RPTEN)
SRC:1877E7 DST:19CA61 0101000031
2012.04.24 12:18:22 5: Cmd: >set WZ_Heizung desired-temp 15<
2012.04.24 12:18:22 2: CUL_HM set WZ_Heizung desired-temp 15
2012.04.24 12:18:22 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:18:22 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.

/////////// Reaktion MISSING_ACK:

2012.04.24 12:20:10 5: HMLAN/RAW: /
E19CA61,0000,0DABA3BC,FF,FFC3,08867019CA6100000000C62A

2012.04.24 12:20:10 5: HMLAN_Parse: HMLAN1
E19CA61,0000,0DABA3BC,FF,FFC3,08867019CA6100000000C62A
2012.04.24 12:20:10 5: HMLAN1 dispatch A0C08867019CA6100000000C62A
2012.04.24 12:20:10 4: RCV L:0C N:08 CMD:8670
(TYPE=112,WAKEMEUP,BCAST,RPTEN) SRC:19CA61 DST:000000 00C62A
2012.04.24 12:20:10 5: SW:
SE3DD9205,00,00000000,01,E3DD9205,17A11267CA6C19CA61
2012.04.24 12:20:10 4: SND L:09 N:17 CMD:A112
(TYPE=18,WAKEUP,BIDI,RPTEN) SRC:67CA6C DST:19CA61 (HAVE_DATA)
2012.04.24 12:20:10 5: Triggering WZ_Heizung (0 changes)
2012.04.24 12:18:22 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.
2012.04.24 12:20:10 5: HMLAN/RAW: /RE3DD909D,0002,00000000,FF,7FFF,
16800267CA6C161D290101FE00

2012.04.24 12:20:10 5: HMLAN_Parse: HMLAN1 RE3DD909D,0002,00000000,FF,
7FFF,16800267CA6C161D290101FE00
2012.04.24 12:20:10 5: HMLAN1 dispatch A0D16800267CA6C161D290101FE00
2012.04.24 12:20:10 4: RCV L:0D N:16 CMD:8002 (TYPE=2,RPTEN) SRC:
67CA6C DST:161D29 0101FE00 (ACK_STATUS CHANNEL:01 STATUS:FE)
2012.04.24 12:20:10 5: HMLAN/RAW: /RE3DD9205,0008,00000000,FF,7FFF,
17A11267CA6C19CA61

2012.04.24 12:20:10 5: HMLAN_Parse: HMLAN1 RE3DD9205,0008,00000000,FF,
7FFF,17A11267CA6C19CA61
2012.04.24 12:20:10 5: HMLAN1 dispatch A0917A11267CA6C19CA61NACK
2012.04.24 12:20:10 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:20:10 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.

[Rudolf Koenig]

> Im ersten Beispiel kommt die Message nach ca. 30 Sek.

Das HM-CC-TC ist die meiste Zeit am Schlafen, sendet nur alle fn(x) Sekunden
eine Nachricht an die Ventile, die wahrscheinlich auch synchron zum HM-CC-TC
schlafen. Die Funktion fn(x) ist mir unbekannt.

Wenn fhem an das HM-CC-TC was zu sagen hat (z.Bsp desired-temp), dann sendet es
die Nachricht nach dem Empfang der "Ventil"-Nachricht erst los.

Parallel dazu sendet fhem an dem HMLAN ein Keepalive (K) alle 25 Sekunden, da
nach 30Sek ohne keepalive das HMLAN die Verbindung selbst zuklappt.

[unimatrix]

Dass die Ventile mit HM-CC-TC synchron sind steht sogar in der Doku, damit gibts auch mal Probleme was dann zum schnellen Batterieverbrauch führt.

Die Funktion fn(x) kenn ich auch noch nciht.

Ich hab das Thema Heizung zur Seite gelegt um mich in Ruhe im Sommer damit zu beschäftigen wenn die Dinger nicht in Benutzung sind.

VG

[Merhan Öztürk]

> Wenn fhem an das HM-CC-TC was zu sagen hat (z.Bsp desired-temp), dann sendet es
> die Nachricht nach dem Empfang der "Ventil"-Nachricht erst los.

Ok ich verstehe die Verzögerung.
Was ich nicht verstehe wie es ziemlich zeitnah nach einem Befehl FEHM -
> HM-CC-TC zu einem MISSING-ACK kommen kann:

Hier der Auszug aus der Log-Datei zu einem set desired-temp mit einem
unmittelbaren MISSING-ACK in der Telnet Konsole:

//////////////////////////////////


2012.04.24 12:59:10 5: HMLAN/RAW: /
E19CA61,0000,0DCF5BB7,FF,FFC3,17A25819CA611877E70000

2012.04.24 12:59:10 5: HMLAN_Parse: HMLAN1
E19CA61,0000,0DCF5BB7,FF,FFC3,17A25819CA611877E70000
2012.04.24 12:59:10 5: HMLAN1 dispatch A0B17A25819CA611877E70000
2012.04.24 12:59:10 4: RCV L:0B N:17 CMD:A258
(TYPE=88,WAKEMEUP,BIDI,RPTEN) SRC:19CA61 DST:1877E7 0000
2012.04.24 12:59:10 5: SW:
SE40147E4,00,00000000,01,E40147E4,23A11267CA6C19CA61
2012.04.24 12:59:10 4: SND L:09 N:23 CMD:A112

(TYPE=18,WAKEUP,BIDI,RPTEN) SRC:67CA6C DST:19CA61 (HAVE_DATA)

2012.04.24 12:59:10 5: Triggering WZ_Heizung (0 changes)
2012.04.24 12:59:10 5: WZ_Heizung trigger: Checking Aufstehen for
notify

2012.04.24 12:59:10 5: HMLAN/RAW: /
E1877E7,0000,0DCF5C3A,FF,FFC9,1782021877E719CA610101000031

2012.04.24 12:59:10 5: HMLAN_Parse: HMLAN1
E1877E7,0000,0DCF5C3A,FF,FFC9,1782021877E719CA610101000031
2012.04.24 12:59:10 5: HMLAN1 dispatch A0E1782021877E719CA610101000031
2012.04.24 12:59:10 4: RCV L:0E N:17 CMD:8202 (TYPE=2,WAKEMEUP,RPTEN)

SRC:1877E7 DST:19CA61 0101000031

2012.04.24 12:59:11 5: HMLAN/RAW: /RE40147E4,0008,00000000,FF,7FFF,
23A11267CA6C19CA61

2012.04.24 12:59:11 5: HMLAN_Parse: HMLAN1 RE40147E4,0008,00000000,FF,
7FFF,23A11267CA6C19CA61
2012.04.24 12:59:11 5: HMLAN1 dispatch A0923A11267CA6C19CA61NACK
2012.04.24 12:59:11 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:59:11 5: WZ_Heizung trigger: Checking Aufstehen for
notify

[Rudolf Koenig]

> Hier der Auszug aus der Log-Datei zu einem set desired-temp mit einem
> unmittelbaren MISSING-ACK in der Telnet Konsole:

Stell mal verbose auf 4 (sonst wird es fuer diesen Zweck unleserlich), und
mseclog auf 1. Was bleibt:


> RCV L:0B N:17 CMD:A258 SRC:19CA61 DST:1877E7 0000
CC-TC an CC-VD, sollte von fhem als "actuator:0 %" gemeldet werden.

> SND L:09 N:23 CMD:A112 SRC:67CA6C DST:19CA61 (HAVE_DATA)
FHEM an CC-TC (hab was zu sagen, schick mir ein ACK)


> RCV L:0E N:17 CMD:8202 SRC:1877E7 DST:19CA61 0101000031
CC-VD an CC-TC: "actuator:0 %, motor:ok, battery:ok"


Das HMLAN ist (zu?) klug, und sendet schon mal ohne fhem-Auftrag ACKs, bzw.
beantwortet die AES Anfragen. Evtl. haengt das Problem damit zusammen. Oder
fhem haette erst nach dem CC-VD Antwort mit seinem HAVE_DATA melden sollen.

Ich habe solche Logs selber schon laenger untersucht, und nicht wesentlich mehr
rausgefunden, als bisher in 10_CUL_HM.pm implementiert ist. Evtl. muss man
unterschiedliche Theorien ausprobieren, das ueberlasse ich aber gerne anderen
:)

[Johan van der Kolk]

Nachdem Mann ein NACK (0008) bekommen hat, sollte man gleich ein "+123456,02,00," schicken.
Wobei 123456 die alte Zieladdresse ist

Beim nächsten HM-TT-TC aufwachen schickt der HMLAN dann ein bericht zum FHEM aber diesmal mit status 0081. (wakemeup ist jetzt 0)
Das heisst, ich bin wach, schick mir neue auftrage (also ganz neu, auch neue message nummer und timestamps)
Alle offene commands koennen jetzt geschickt werden (warten auf Ack, dann die nächste, usw)

--Johan

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

[Willi]

Ich hatte mir auch ein HM-CFG-LAN sowie HM-CC-TC und HM-CC-VD vor einiger Zeit gekauft und hatte beim Testsetup bzgl. desired-temp das gleiche Problem. Ich hatte auch das Gefühl, dass das Setzen des desired-temp nur funktioniert, wenn HM-CC-TC vorher aufgewacht war. Direkt nach dem Pairing war das deshalb kein Problem.

Ich hatte danach wegen anderer Projekte die Geräte beiseite gelegt und war davon ausgegangen, das das Problem zwischen meinen Ohren lag.

Zur Klärung: 

- Gibt es das Problem des Setzens von desired-temp nur mit HM-CFG-LAN oder auch mit CUL?

- Gibt es jemanden der das Problem nicht hat, also bei dem das Setzen von desired-temp immer funktioniert?

[Jan-Hinrich Fessel]

Am 24.04.2012 um 18:33 schrieb Willi:

> Ich hatte mir auch ein HM-CFG-LAN sowie HM-CC-TC und HM-CC-VD vor einiger Zeit gekauft und hatte beim Testsetup bzgl. desired-temp das gleiche Problem. Ich hatte auch das Gefühl, dass das Setzen des desired-temp nur funktioniert, wenn HM-CC-TC vorher aufgewacht war. Direkt nach dem Pairing war das deshalb kein Problem.

> Zur Klärung:

>
> - Gibt es das Problem des Setzens von desired-temp nur mit HM-CFG-LAN oder auch mit CUL?

Meine oberflächliche Auswertung der Posting hier ergibt, das sich nur HM-CFG-LAN Benutzer über das Problem beschweren. Als ich noch das CUL hatte, ging es bei mir auch. Jetzt nur selten. Und zwar niemals, wenn das Setzen nach Funkverkehr zwischen HM-CC-TC und -VD stattfinden sollte. Also praktisch immer.

> - Gibt es jemanden der das Problem nicht hat, also bei dem das Setzen von desired-temp immer funktioniert?

Scheinbar ja.

Grüße
Oskar

[eppi]

Hallo

> - Gibt es das Problem des Setzens von desired-temp nur mit HM-CFG-LAN oder auch mit CUL?</div>

> - Gibt es jemanden der das Problem nicht hat, also bei dem das Setzen von desired-temp immer funktioniert?

Ich habe 5 Stück HM-CC-TC gekoopelt mit je einem HM-CC-VD. Ich verwende einen CUL im rfmode homematic mit version 1.39. Ich kann problemlos die desired-temp ändern.

Gruss Dani

[Willi]

Am Dienstag, 24. April 2012 18:46:19 UTC+2 schrieb eppi:

Ich habe 5 Stück HM-CC-TC gekoopelt mit je einem HM-CC-VD. Ich verwende einen CUL im rfmode homematic mit version 1.39. Ich kann problemlos die desired-temp ändern.

Das ist ja seltsam. Ich hatte vermutet, dass es daran liegt, dass das Timing noch nicht stimmt und  HM-CC-TC erst die Befehle im Wachmodus annimmt. Dann hätte es auch bei CUL Probleme geben müssen.

@Rudi: Wird HM-CC-TC in der CUL-Firmware oder in den CUL-Routinen für FHEM irgendwie anders behandelt? So wie es eine FHT-Spezialbehandlung und Warteschlange in der CUL Firmware gibt und hier erst gesendet wird, wenn sicher ist, dass der FHT80b wach ist.

Oder liegt es daran, dass die HMLAN-Nutzer zumeist AES verwenden und hier das Timing sowie der Ablauf unterschiedlich ist? 

Seltsam.......

[Merhan Öztürk]

>
> Oder liegt es daran, dass die HMLAN-Nutzer zumeist AES verwenden und hier
> das Timing sowie der Ablauf unterschiedlich ist?
>
> Seltsam.......

Ich habe kein AES aktiviert und die Probleme. Zufällig ist heute mein
CUL- Modul gekommen. Ich wollte es für FS20 & Co verwenden jedoch
spricht nichts gegen einen Test.

Kann Ich relativ einfach meine vorhandene Konfig beibehalten und den
HM-Lan durch den CUL- Stick ersetzen?

[Rudolf Koenig]

> @Rudi: Wird HM-CC-TC in der CUL-Firmware oder in den CUL-Routinen f�r FHEM
> irgendwie anders behandelt?

Nein. AskSin (==BidCos) in culfw ist sehr duenn...

> Oder liegt es daran, dass die HMLAN-Nutzer zumeist AES verwenden und hier
> das Timing sowie der Ablauf unterschiedlich ist?

Ich meine das HM-CC-TC verwendet kein AES. Ich tippe darauf, dass das HMLAN
(zu) klug ist, und manches anders macht, als ich denke. Ganz genau blicke ich
die HMLAN Kommandos eh noch nicht: z.Bsp folgendes in HMLAN_Write kann nur
Unfug sein:
===
if(!$lhash{$dst} && $dst ne "000000") { # Don't think I grok the logic
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "-$dst");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
$lhash{$dst} = 1;
}
===
aber das HMLAN-Config macht es auch so, und wenn ich die Wiederholungen
wegoptimiere, dann tut es auch nicht :/

[Johan van der Kolk]

I programmed it in basic, the way I described. 100% success rate.

--Johan

On Tue, Apr 24, 2012 at 9:06 PM, Rudolf Koenig <inf...@koeniglich.de> wrote:

> @Rudi: Wird HM-CC-TC in der CUL-Firmware oder in den CUL-Routinen für FHEM
> irgendwie anders behandelt?

[Willi]

Am Mittwoch, 25. April 2012 00:19:25 UTC+2 schrieb Johank:

I programmed it in basic, the way I described. 100% success rate.

--Johan

Hello Johan,

this sound very good! 

Would you supply us with the pogramm code and also put it into FHEMs SVN?

Regards

Willi 

[unimatrix]

das hilft jetzt vll nur noch begrenzt aber ich kann bestätigen dass ich meine 4 Thermostate mit dem CUL problemlos bedienen kann und mit dem HMLAN die o.b. Probleme habe.

VG

[Johan van der Kolk]

Sequence as follows:

send a command....
receive a NACK (0008)
send +123456,02,00,
on the next tem/hum report from device 123456 (not a valve set command !!) the HMLAN adapter will come back with delayed NACK,
(0081).
Then recreate the old command (pull it from the stack), pack it up again with new msgnr, timestamps etc and send it out again.

That's all.

Hope someone can Perlifise this.


--Johan

2012/4/29 unimatrix <sebastian...@googlemail.com>

das hilft jetzt vll nur noch begrenzt aber ich kann bestätigen dass ich meine 4 Thermostate mit dem CUL problemlos bedienen kann und mit dem HMLAN die o.b. Probleme habe.

VG

[Merhan]

ich habe nun endlich mein CUL am laufen und kann dies auch bestätigen.

Mit dem CUL gibt es keine Probleme. Alle Befehle werden deterministisch angenommen.

Mit HMLAN bekommt man auf oft MISSING ACK auf Befehle seitens FHEM.

[Willi]

Am Sonntag, 6. Mai 2012 15:33:30 UTC+2 schrieb Merhan:

ich habe nun endlich mein CUL am laufen und kann dies auch bestätigen.

Mit dem CUL gibt es keine Probleme. Alle Befehle werden deterministisch angenommen.

Wenn ich Johan richtig verstehe, müssten wir um HMLAN mit  HM-CC-TC richtig zu unterstützen die Befehle zwischenspeichern und in der beschriebenen Weise nach NACK neu senden. Dazu braucht man wohl eine Queue der noch nicht bestätigten Befehle.

Solch eine Queue gibt es ja auch für CUL und FHT80b, jedoch in der Firmware der CUL (also quasi als separater Prozess) und nicht in FHEM.

@Rudi:  An Dich als Author von 00_HMLAN.pm und als FHEM-Versteher: Reicht Deiner Meinung nach eine einfache Queue der nicht bestätigten Befehle in 00_HMLAN.pm oder braucht man eher einen separaten Prozess der zwischen HMLAN und FHEM läuft und dies realisiert? 

Schleierhaft ist für mich, warum es mit CUL ohne diese Logik funktioniert, aber HMLAN dies benötigt.............

-- Willi

 

[Johan van der Kolk]

Ack's werden beim HMLAN ueber diese + und - zeilen gesteuert. Nach zb einem -123456 (geraete Adresse) gibt das HMLAN keinen eigenen Acks mehr. Genau wie das funktioniert mit die beide kommands(+123456,00,00, +123456,02,00,) hab Ich dass auch noch nicht, aber ich bekomme nur selten retransmits (nur beim timesync).
+123456 scheint das gleiche zu machen als +123456,00,00.

 
--Johan

2012/5/6 Willi <willi....@googlemail.com>

[fhem-hm-knecht]

Der Hmlan darf nur bei Der Broadcastmeldung von Temperatur und
Humidity
das Disired-temp setzten,

da der hmlan es auch bei der Meldung zum actuator versucht,
gibt es die Nacks

Johann hat es ja bereits beschrieben.
Hary

[Willi]

Am Sonntag, 6. Mai 2012 17:36:57 UTC+2 schrieb fhem-hm-knecht:

Der Hmlan darf nur bei Der Broadcastmeldung von Temperatur und
Humidity
das Disired-temp setzten,

da der hmlan es auch bei der Meldung zum actuator versucht,
gibt es die Nacks

Johann hat es ja bereits beschrieben.

Hmm. Jetzt verstehe ich nichts mehr.

Johan hatte geschrieben:

>Sequence as follows:
>
>send a command....
>receive a NACK (0008)
>send +123456,02,00,
>on the next tem/hum report from device 123456 (not a valve set command !!) the HMLAN adapter will come back with delayed NACK, 
>(0081).

>Then recreate the old command (pull it from the stack), pack it up again with new msgnr, timestamps etc and send it out again.

@Hary:

Ich dachte man muss dies implementieren und dafür eine Warteschlange der abzusetzenden Befehle implementieren.  Diese kann man dann erst senden, wenn das nächste Mal der tem/hum report kommt.

Bisher gibt es diese Warteschlange m.E. nicht. Daher hatte ich Rudi gefragt, ob man das in 00_HMLAN.pm hin bekommt ohne dazwischengeschalteten Prozess.

Siehst Du das anders? Wenn ja:

Was ist Deiner Meinung nach jetzt die Lösung? Hast Du einen Fix?

[Rudolf Koenig]

> Dazu braucht man wohl eine Queue der noch nicht best�tigten Befehle.

Das gibt es schon, und wird extensiv genutzt (siehe CUL_HM_PushCmdStack & co)
bloss bei einem NACK wird alles weggeworfen. Das koennte man aendern, wenn man
weiss wie, macht bloss das jetzt schon komplexe CUL_HM.pm nicht wirklich
verstaendlicher.


> Solch eine Queue gibt es ja auch f�r CUL und FHT80b, jedoch in der Firmware

> der CUL (also quasi als separater Prozess) und nicht in FHEM.

Da ist es noch kompilzierter: es gibt eigentlich auch in fhem ein Puffer (attr
FHZ softbuffer), war aber beim CUL kontraproduktiv, ist also nur beim FHZ
aktiv. Das FHZ vergisst nach 'ne Weile FHT Befehle, da musste jemand die
merken...


> Schleierhaft ist f�r mich, warum es mit CUL ohne diese Logik funktioniert,
> aber HMLAN dies ben�tigt.............

Weil ich den HMLAN nicht wirklich kapiere, es wundert mich eh, dass soviel
damit funktioniert :) Wenn jemand sich einarbeiten will, kann ich gerne
assistieren.

[Willi]

Ok. Dann nehme ich bzgl. Warteschlange, etc. alles zurück.

Dann fehlt "nur" noch die neue Logic, die beim NACK nichts wegschmeisst, sondern die Befehle des entsprechenden HM-CC-TC neu sendet (natürlich nur bei temp/hum) und löscht wenn das ACK kommt.

;-)

Was mich wundert: Gibt es diese Probleme nur mit HM-CC-TC oder auch mit anderen Geräten? Wenn nur mit HM-CC-TC, bräuchte man einen eigenen Stack für HM-CC-TC.

Aber vermutlich ist es einfacher, ist stelle mein HMLAN in eine Ecke und nutze CUL...............

[Rudolf Koenig]

> Der Hmlan darf nur bei Der Broadcastmeldung von Temperatur und Humidity das
> Disired-temp setzten, da der hmlan es auch bei der Meldung zum actuator
> versucht, gibt es die Nacks

Ist nur komisch, dass beim CUL das trotzdem klappt. Die HM-CC-TC Daten nicht
nach dem Ventil-Meldung zu schicken waere einfach, erst auf NACK zu warten und
fuer die HMLAN/TC-CC Kombination exrawurst zu drehen, ist komplizierter, bzw.
macht CUL_HM.pm noch unuebersichtlicher.

Koennt Ihr bitte noch pruefen, ob die "einfache" Methode reicht?

[Johan van der Kolk]

@Rudi,
 Es koente es auch klappen mit nur beim tem/hum (also die "70"/112 message) das Kommando zu schicken. Fuer HMLAN wird es nicht schlechter sein, weil die andere (beim "58"/88) sowieso nie klappen.

Willi, der HM-CC-TC schläft ein (jedenfalls auf das Kanal auf dem mit der Adapter kommuniziert wird). Das gleiche problem koente es geben bei andere teile die auch einschlafen.


--Johan

2012/5/6 Willi <willi....@googlemail.com>

--

[fhem-hm-knecht]

ich bin in Perl miserabel bis sau schlecht aber loggen kann ich :)
mein fix ist bisher HM-CC-TC=IODev CUL2, Rest =IODev hmlan1

disered-temp wird nur vom HM-CC-TC angenommen nach einer Temp/Hum
Meldung (Fakt) sprich,
(HM-CC-TC= SRC:135B35)
das es besser lesbar ist kürze ich die Meldungen ein!

CUL CUL2 RCV L:0C N:62 CMD:8670 DST:000000 00B243
CUL CUL2 SND L:09 N:21 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
CUL CUL2 RCV L:0A N:21 CMD:8002 SRC:135B35 DST:F12222 00
CUL CUL2 SND L:0C N:22 CMD:A011 SRC:F12222 DST:135B35 02021E
CUL CUL2 RCV L:0E N:22 CMD:8002 SRC:135B35 DST:F12222 01021E0059
CUL_HM eg_Halle_Hz1 desired-temp: 15.0

das war der Idealfall :)

der unidealfall mit cul ist folgender und geht trotzdem
CUL_HM eg_Halle_Hz1 desired-temp 12.0
CUL CUL2 RCV L:0B N:61 CMD:A258 SRC:135B35 DST:179CDE 0000
CUL CUL2 SND L:09 N:1F CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA))
CUL CUL2 RCV L:0E N:61 CMD:8202 SRC:179CDE DST:135B35 0101000037
CUL_HM EG_KU actuator: 0 %

Regler kommt und dazwischen
--> Have Data weg :(

CUL CUL2 RCV L:0C N:62 CMD:8670 SRC:135B35 DST:000000 00B243
(TYPE=112,WAKEMEUP,BCAST,RPTEN)
CUL CUL2 SND L:0C N:20 CMD:A011 SRC:F12222 DST:135B35 020218 (SET
CHANNEL:02 VALUE:18) (TYPE=17,BIDI,RPTEN)
CUL CUL2 RCV L:0E N:20 CMD:8002 SRC:135B35 DST:F12222 0102180058
(ACK_STATUS CHANNEL:02 STATUS:18 RSSI:58) (TYPE=2,RPTEN)
CUL_HM eg_Halle_Hz1 desired-temp-ack: 12.0
CUL_HM eg_Halle_Hz1 desired-temp: 12.0

HM-CC-TC ist nicht auf das (Have data) pingelich und nimmt das das
neue disired temp trotzdem an :)

jetzt der HM_lan

CUL_HM eg_Halle_Hz1 desired-temp 11.0
jetzt die Meldung vom regler
CUL CUL2 RCV L:0B N:76 CMD:A258 SRC:135B35 DST:179CDE 0000
HMLAN hmlan1 SND L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
CUL CUL2 RCV L:0E N:76 CMD:8202 SRC:179CDE DST:135B35 0101000037
CUL_HM EG_KU actuator: 0 %
CUL_HM EG_KU motor: ok
CUL_HM EG_KU battery: ok
und noch drei Wiederholungen
CUL CUL2 RCV L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
(TYPE=18,WAKEUP,BIDI,RPTEN)
CUL CUL2 RCV L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
(TYPE=18,WAKEUP,BIDI,RPTEN)
CUL CUL2 RCV L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
(TYPE=18,WAKEUP,BIDI,RPTEN)
CUL_HM eg_Halle_Hz1 MISSING ACK
und jetzt Beleidigt

Cul und Hmlan machen es beide nicht richtig,
der Hmlan ist allerdings gleich beleidigt, der Cul nicht und wartet
auf die nächste Meldung ohne Have data, weil schon gesendet, und der
Hm-cc-tc ist da nicht so pingelich :)


vielleicht hilfts es dem Rudi :)))))))))))))

Hary

[itjunky]

Hallo,

ich würde mich gerne in das Thema einarbeiten, da ich momentan Zeit
habe.
Mir fehlt aber zum einen der ÜBerblick über fhem (Wie funktioniert das
System überhaupt ??).
Zweitens wären auch Infos wichtig und notwendig, die den HMLAN und das
Protokoll betreffen.
Wenn ich da entsprechende Infos bekommen könnte, dann könnte ich mir
vorstellen, daß ich mich um das Thema mal kümmern könnte.

Viele Grüße

Michael

[Rudolf Koenig]

> Zweitens w�ren auch Infos wichtig und notwendig, die den HMLAN und das
> Protokoll betreffen.

Wenn man das HMLAN nicht verschluesselt betreibt, dann gibt es die (meisten!?)
empfangenen Daten in hex zurueck mit weiteren mir mehr oder weniger unbekannten
Daten. Senden funktioniert auch so aehnlich, deswegen habe ich das HMLAN mit
relativ wenig Aufwand CUL-Kompatibel gemacht.

Man kann ueber contrib/tcptee.pl das Windows HMLAN Konfig-Programm
protokollieren, was die Befehle konkret bewirken, muss man aber selbst
zusammenreimen. Das was ich verstanden habe, habe ich in 99_HMLAN.pm
implementiert. Weitere Dokumentation ist mir nicht bekannt.