Befehle kommen bei HM-CC-TC nur sporadisch an

[Guest]

Originally posted by: <email address deleted>

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

--Johan


On Tue, Apr 24, 2012 at 9:06 PM, Rudolf Koenig wrote:

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

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

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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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

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

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.

Am Sonntag, 29. April 2012 10:18:16 UTC+2 schrieb 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
>>
>>
>>

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

[Guest]

Originally posted by: <email address deleted>

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?

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

[rudolfkoenig]

                                                   

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

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

[Guest]

Originally posted by: <email address deleted>

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

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

[rudolfkoenig]

                                                   

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

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

[Guest]

Originally posted by: <email address deleted>

@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

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

[LuckyDay]

                                         

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

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

[Guest]

Originally posted by: <email address deleted>

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

On 6 Mai, 19:13, Rudolf Koenig wrote:
> > 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.

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

[rudolfkoenig]

                                                   

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

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

[Guest]

Originally posted by: <email address deleted>

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
 

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

[Guest]

Originally posted by: <email address deleted>

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

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