HM-CC-TC Temperatur Anzeige und Vorwahl

[Oskar]

                                                     

On Feb 13, 5:41 pm, JHF wrote:
> ....
>
> > n ganzen Kram auch abkürzen, indem man einmal am Gerät selbst den Modus wechselt, z.b. von auto auf cent und wieder zurück.  Da nämlich alles im selben Byte kondiert ist, kommt das dann alles beim fhem an und man kann das danach im fhem einzeln stellen ohne alle parameter einzugeben.>>> On 12 Feb., 20:45, JHF
>
> guter tip, nützt mir aber nix, da remote.....

Noch so einer.

Ich hab aber jetzt gefunden das der TC im Modus "cent" (also
zentralengeführt) keine desired-temp sendet und wohl deswegen auch die
vorauswahl nicht funktioniert, da diese auf den vom TC gesendeten
Werten basiert (READINGS halt).
Du läßt den nicht etwa im cent-mode laufen?
Und hab damit mein kleines Problem eingekreist, das der die SETPOINT
bzw. desired-temp nicht annimmt.  Das scheint im Auto-Modus einfach
nicht zu funktionieren. Der nimmt es zwar an, schickt aber als
nächstes die Info, das die Auto-Temperatur doch desiredter sei.

Grüße
     Oskar

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

[Guest]

Originally posted by: <email address deleted>

Danke.... nein, ich lasse ihn im auto laufen.... aber ich glaube
mit manuell funktioniert der drehrumbum ganz gut gleich mal testen

On 13 Feb., 20:59, oskar wrote:
> On Feb 13, 5:41 pm, JHF wrote:
>
> > ....
>
> > > n ganzen Kram auch abkürzen, indem man einmal am Gerät selbst den Modus wechselt, z.b. von auto auf cent und wieder zurück.  Da nämlich alles im selben Byte kondiert ist, kommt das dann alles beim fhem an und man kann das danach im fhem einzeln stellen ohne alle parameter einzugeben.>>> On 12 Feb., 20:45, JHF
>
> > guter tip, nützt mir aber nix, da remote.....
>
> Noch so einer.
>
> Ich hab aber jetzt gefunden das der TC im Modus "cent" (also
> zentralengeführt) keine desired-temp sendet und wohl deswegen auch die
> vorauswahl nicht funktioniert, da diese auf den vom TC gesendeten
> Werten basiert (READINGS halt).
> Du läßt den nicht etwa im cent-mode laufen?
> Und hab damit mein kleines Problem eingekreist, das der die SETPOINT
> bzw. desired-temp nicht annimmt.  Das scheint im Auto-Modus einfach
> nicht zu funktionieren. Der nimmt es zwar an, schickt aber als
> nächstes die Info, das die Auto-Temperatur doch desiredter sei.
>
> Grüße
>      Oskar

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

[Guest]

Originally posted by: <email address deleted>

war nur eine wunschvorstellung... drehrumbum geht nicht im manual.....

On 13 Feb., 21:01, JHF wrote:
> Danke.... nein, ich lasse ihn im auto laufen.... aber ich glaube
> mit manuell funktioniert der drehrumbum ganz gut gleich mal testen
>
> On 13 Feb., 20:59, oskar wrote:
>
>
>
>
>
>
>
> > On Feb 13, 5:41 pm, JHF wrote:
>
> > > ....
>
> > > > n ganzen Kram auch abkürzen, indem man einmal am Gerät selbst den Modus wechselt, z.b. von auto auf cent und wieder zurück.  Da nämlich alles im selben Byte kondiert ist, kommt das dann alles beim fhem an und man kann das danach im fhem einzeln stellen ohne alle parameter einzugeben.>>> On 12 Feb., 20:45, JHF
>
> > > guter tip, nützt mir aber nix, da remote.....
>
> > Noch so einer.
>
> > Ich hab aber jetzt gefunden das der TC im Modus "cent" (also
> > zentralengeführt) keine desired-temp sendet und wohl deswegen auch die
> > vorauswahl nicht funktioniert, da diese auf den vom TC gesendeten
> > Werten basiert (READINGS halt).
> > Du läßt den nicht etwa im cent-mode laufen?
> > Und hab damit mein kleines Problem eingekreist, das der die SETPOINT
> > bzw. desired-temp nicht annimmt.  Das scheint im Auto-Modus einfach
> > nicht zu funktionieren. Der nimmt es zwar an, schickt aber als
> > nächstes die Info, das die Auto-Temperatur doch desiredter sei.
>
> > Grüße
> >      Oskar

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

[Guest]

Originally posted by: <email address deleted>

Bei allem Respekt, ich würde gern verstehen, was das Problem ist, um
die Anzeige des Button (weiß nimmer genaue Bezeichnung) mir der
desired-ack zu verknüpfen. Ich hab so was in der Art mit c# gemacht
(nur mal so zum Gag, als Anfänger). Wie kann ich helfen?

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

[Guest]

Originally posted by: <email address deleted>

Stimmt.

Bei Cent macht der thermostat genau dass. Das kommand wird erst
angenommen, und dan beim nachsten report wird wieder die Cent temp
zuruck geschickt.
Wen man die thermostat umschaltet zwischen Cent und Manu kann mann
auch beobachten dass die thermostat fuer beide modi einen separaten
setpoint im speicher hat.

Ich hab diesen message schon mal irgendwo anders gepost. Im Auto und
Mano Mode funktioniert es jetzt gut. Im Cent modus wie erwarted.

A propos, and beside the subject: ack reliability. Ich sehe das jetzt
das set kommand loss geschickt wird so bald die thermostat sich selber
meldet. (!) Functioniert meistens sehr gut, und vermeidet endlose
wakeup sequenzen !!
Im moment wird das kommand los geschickt wenn der thermostat sich
irgendwie meldet, in alle faelle.
Erfolg haben nur die kommands die folgen auf ein 8670 message vom
HM-TT-TC (also ein broadcast).
Die kommands die abgeschickt werden nach einem thermostat-valve
kommunikation klappen nicht.

Deshalb meine hit and miss erfahrung denke ich.... Kann jemand das mal
bestaetigen?

--Johan



On Mon, Feb 13, 2012 at 8:59 PM, oskar wrote:
>
>
> On Feb 13, 5:41 pm, JHF wrote:
>> ....
>>
>> > n ganzen Kram auch abkürzen, indem man einmal am Gerät selbst den Modus wechselt, z.b. von auto auf cent und wieder zurück.  Da nämlich alles im selben Byte kondiert ist, kommt das dann alles beim fhem an und man kann das danach im fhem einzeln stellen ohne alle parameter einzugeben.>>> On 12 Feb., 20:45, JHF
>>
>> guter tip, nützt mir aber nix, da remote.....
>
> Noch so einer.
>
> Ich hab aber jetzt gefunden das der TC im Modus "cent" (also
> zentralengeführt) keine desired-temp sendet und wohl deswegen auch die
> vorauswahl nicht funktioniert, da diese auf den vom TC gesendeten
> Werten basiert (READINGS halt).
> Du läßt den nicht etwa im cent-mode laufen?
> Und hab damit mein kleines Problem eingekreist, das der die SETPOINT
> bzw. desired-temp nicht annimmt.  Das scheint im Auto-Modus einfach
> nicht zu funktionieren. Der nimmt es zwar an, schickt aber als
> nächstes die Info, das die Auto-Temperatur doch desiredter sei.
>
> Grüße
>     Oskar
>
> --
> 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

[Oskar]

                                                     

On Feb 13, 9:12 pm, JHF wrote:
> Bei allem Respekt, ich würde gern verstehen, was das Problem ist, um
> die Anzeige des Button (weiß nimmer genaue Bezeichnung) mir der
> desired-ack zu verknüpfen. Ich hab so was in der Art mit c# gemacht
> (nur mal so zum Gag, als Anfänger). Wie kann ich helfen?

Der Code dafür steht in webfrontend/pgm2/01_FHEMWEB.pm bzw.
wo auch immer das auf der Fritzbox liegen mag.
in Zeile 913 wird die Funktion FW_select aufgerufen.  Davor könnte man
etwas debugging betreiben, um zu sehen, wieso die aktuelle desired-
temp nicht übergeben wird.

Ich kann es nicht nachstellen, da im Auto-Modus bei mir alles schön
ist, will heißen, die Optionsliste zeigt als Vorauswahl die dezeitige
desired-temp an.

Grüße
   Oskar

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

[Oskar]

                                                     

On Feb 13, 11:11 pm, Johan van der Kolk
wrote:
> Erfolg haben nur die kommands die folgen auf ein 8670 message vom
> HM-TT-TC (also ein broadcast).
Ja. Aber auch diejenigen directed messages, welche an die Zentrale
geschickt wurden, können erfolgreich mit einer Parametereinstellung
beantwortet werden.
> Die kommands die abgeschickt werden nach einem thermostat-valve
> kommunikation klappen nicht.

Auch wenn sich bis zum Funkkontakt mehrere Kommandos angesammelt
haben, klappt nur das erste:
2012-02-13 18:16:12 HMLAN HMLAN23 SND L:0B N:47 CMD:A001 SRC:5D24C9
DST:15B50D 0206 (CONFIG_END CHANNEL:02)
2012-02-13 18:16:12 HMLAN HMLAN23 RCV L:0A N:47 CMD:8002 SRC:15B50D
DST:5D24C9 00 (ACK)
2012-02-13 18:16:12 HMLAN HMLAN23 SND L:09 N:48 CMD:A112 SRC:5D24C9
DST:15B50D  (HAVE_DATA)
2012-02-13 18:16:13 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK

oder auch

2012-02-13 18:20:28 HMLAN HMLAN23 SND L:0B N:4E CMD:A001 SRC:5D24C9
DST:15B50D 0206 (CONFIG_END CHANNEL:02)
2012-02-13 18:20:29 HMLAN HMLAN23 RCV L:0A N:4E CMD:8002 SRC:15B50D
DST:5D24C9 00 (ACK)
2012-02-13 18:20:29 HMLAN HMLAN23 SND L:10 N:4F CMD:A001 SRC:5D24C9
DST:15B50D 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000
PEER_CHANNEL:00 PARAM_LIST:05)
2012-02-13 18:20:29 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK

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

[Guest]

Originally posted by: <email address deleted>

@OSCAR: Auf was für einer Hardware läuft dein FHEM?
Bin grad per telnet @fbox

On 14 Feb., 08:30, oskar wrote:
> On Feb 13, 11:11 pm, Johan van der Kolk
> wrote:> Erfolg haben nur die kommands die folgen auf ein 8670 message vom
> > HM-TT-TC (also ein broadcast).
>
> Ja. Aber auch diejenigen directed messages, welche an die Zentrale
> geschickt wurden, können erfolgreich mit einer Parametereinstellung
> beantwortet werden.
>
> > Die kommands die abgeschickt werden nach einem thermostat-valve
> > kommunikation klappen nicht.
>
> Auch wenn sich bis zum Funkkontakt mehrere Kommandos angesammelt
> haben, klappt nur das erste:
> 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:0B N:47 CMD:A001 SRC:5D24C9
> DST:15B50D 0206 (CONFIG_END CHANNEL:02)
> 2012-02-13 18:16:12 HMLAN HMLAN23 RCV L:0A N:47 CMD:8002 SRC:15B50D
> DST:5D24C9 00 (ACK)
> 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:09 N:48 CMD:A112 SRC:5D24C9
> DST:15B50D  (HAVE_DATA)
> 2012-02-13 18:16:13 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK
>
> oder auch
>
> 2012-02-13 18:20:28 HMLAN HMLAN23 SND L:0B N:4E CMD:A001 SRC:5D24C9
> DST:15B50D 0206 (CONFIG_END CHANNEL:02)
> 2012-02-13 18:20:29 HMLAN HMLAN23 RCV L:0A N:4E CMD:8002 SRC:15B50D
> DST:5D24C9 00 (ACK)
> 2012-02-13 18:20:29 HMLAN HMLAN23 SND L:10 N:4F CMD:A001 SRC:5D24C9
> DST:15B50D 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000
> PEER_CHANNEL:00 PARAM_LIST:05)
> 2012-02-13 18:20:29 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK

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

[Guest]

Originally posted by: <email address deleted>

FW_pO "".
             FW_hidden("arg.$d", "desired-temp") .
             FW_hidden("dev.$d", $d) .
             FW_select("val.$d", \@tv, ReadingsVal($d, "desired-temp",
$txt)) .
             "".
             FW_submit("cmd.$d", "set").
             "";

So, dann sag mal an!

On 14 Feb., 18:33, JHF wrote:
> @OSCAR: Auf was für einer Hardware läuft dein FHEM?
> Bin grad per telnet @fbox
>
> On 14 Feb., 08:30, oskar wrote:
>
>
>
>
>
>
>
> > On Feb 13, 11:11 pm, Johan van der Kolk
> > wrote:> Erfolg haben nur die kommands die folgen auf ein 8670 message vom
> > > HM-TT-TC (also ein broadcast).
>
> > Ja. Aber auch diejenigen directed messages, welche an die Zentrale
> > geschickt wurden, können erfolgreich mit einer Parametereinstellung
> > beantwortet werden.
>
> > > Die kommands die abgeschickt werden nach einem thermostat-valve
> > > kommunikation klappen nicht.
>
> > Auch wenn sich bis zum Funkkontakt mehrere Kommandos angesammelt
> > haben, klappt nur das erste:
> > 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:0B N:47 CMD:A001 SRC:5D24C9
> > DST:15B50D 0206 (CONFIG_END CHANNEL:02)
> > 2012-02-13 18:16:12 HMLAN HMLAN23 RCV L:0A N:47 CMD:8002 SRC:15B50D
> > DST:5D24C9 00 (ACK)
> > 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:09 N:48 CMD:A112 SRC:5D24C9
> > DST:15B50D  (HAVE_DATA)
> > 2012-02-13 18:16:13 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK
>
> > oder auch
>
> > 2012-02-13 18:20:28 HMLAN HMLAN23 SND L:0B N:4E CMD:A001 SRC:5D24C9
> > DST:15B50D 0206 (CONFIG_END CHANNEL:02)
> > 2012-02-13 18:20:29 HMLAN HMLAN23 RCV L:0A N:4E CMD:8002 SRC:15B50D
> > DST:5D24C9 00 (ACK)
> > 2012-02-13 18:20:29 HMLAN HMLAN23 SND L:10 N:4F CMD:A001 SRC:5D24C9
> > DST:15B50D 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000
> > PEER_CHANNEL:00 PARAM_LIST:05)
> > 2012-02-13 18:20:29 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK

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

[Guest]

Originally posted by: <email address deleted>

Vielleicht kann mal jemand hier drüber gucken.... ob alles ok ist

DEF    18DC35

LAN_MSGCNT   1148
LAN_RAWMSG   E18DC35,0000,192C1AE5,FF,FFE1,84867018DC35000000009626
LAN_RSSI   -31
LAN_TIME   2012-02-14 18:49:56
LASTIODev   LAN
MSGCNT   1148
NAME   STEUERUNG
NR   17
STATE   T: 15 H: 38
TYPE   CUL_HM
lastMsg   0C84867018DC35000000009626


 Readings CommandAccepted   yes   2012-02-13 21:04:18
actuator   10 %                  2012-02-14 18:47:52
controlMode   auto   2012-02-13 21:06:05
decalcDay   mon   2012-02-13 19:00:28
desired-temp   15   2012-02-14 00:00:04
desired-temp-ack   14.5   2012-02-13 21:04:18
displayTemp   setpoint   2012-02-13 19:00:28
displayTempUnit   celsius   2012-02-13 19:00:28
humidity   38   2012-02-14 18:49:56
measured-temp   15   2012-02-14 18:49:56
state   T: 15 H: 38   2012-02-14 18:49:56
tempListMon    24:00 14.0   2012-02-13 19:46:51
tempListTue    24:00 15.0   2012-02-13 19:43:43
temperature   15   2012-02-14 18:49:56
unknownMsg   (A03F)    2012-02-14 00:01:36

 STEUERUNG   devInfo   00FFFF   deleteattr
firmware   2.0   deleteattr
hmClass   unknown   deleteattr
model   HM-CC-TC   deleteattr
room   CUL_HM   deleteattr
serialNr   IEQ0516197   deleteattr
subType   unknown   deleteattr

LAN_MSGCNT   564
LAN_RAWMSG   E19162F,0000,192E666B,FF,FFD5,85820219162F18DC350101100029
LAN_RSSI   -43
LAN_TIME   2012-02-14 18:52:27
LASTIODev   LAN
MSGCNT   564
NAME   STELLER
NR   21
STATE   10 %
TYPE   CUL_HM
lastMsg   0E85820219162F18DC350101100029


 Readings STATE   10 %   2012-02-14 18:52:27
actuator   8 %   2012-02-14 18:52:27


 STELLER   devInfo   010100   deleteattr
firmware   1.9   deleteattr
hmClass   unknown   deleteattr
model   HM-CC-VD   deleteattr
room   CUL_HM   deleteattr
serialNr   IEQ0516702   deleteattr
subType   1   deleteattr

DEF    192.168.178.21

DeviceName   192.168.178.21:1000
FD   11
HM_CMDNR   19
LAN_MSGCNT   1720
LAN_TIME   2012-02-14 18:52:27
NAME   LAN
NR   15
PARTIAL
RAWMSG   E19162F,0000,192E666B,FF,FFD5,85820219162F18DC350101100029
RSSI   -43
STATE   opened
TYPE   HMLAN
firmware   0.961
owner   356147
serialNr   HEQ0400502
uptime   004 117:22:53.584


 LAN   hmId   356147   deleteattr
hmProtocolEvents   logs   deleteattr

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

[Guest]

Originally posted by: <email address deleted>

--Johan



On Tue, Feb 14, 2012 at 8:30 AM, oskar wrote:
>
>
> On Feb 13, 11:11 pm, Johan van der Kolk
> wrote:
>> Erfolg haben nur die kommands die folgen auf ein 8670 message vom
>> HM-TT-TC (also ein broadcast).
> Ja. Aber auch diejenigen directed messages, welche an die Zentrale
> geschickt wurden, können erfolgreich mit einer Parametereinstellung
> beantwortet werden.
>> Die kommands die abgeschickt werden nach einem thermostat-valve
>> kommunikation klappen nicht.
>
> Auch wenn sich bis zum Funkkontakt mehrere Kommandos angesammelt
> haben, klappt nur das erste:
> 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:0B N:47 CMD:A001 SRC:5D24C9
> DST:15B50D 0206 (CONFIG_END CHANNEL:02)
> 2012-02-13 18:16:12 HMLAN HMLAN23 RCV L:0A N:47 CMD:8002 SRC:15B50D
> DST:5D24C9 00 (ACK)
> 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:09 N:48 CMD:A112 SRC:5D24C9
> DST:15B50D  (HAVE_DATA)
> 2012-02-13 18:16:13 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK
>
Leider sieht das genau so aus beim Bidcos logs
Diese handshakes, die ich mal Layer2 protokol nennen wird (WakeUp- I'm
Awake) und das "layer 2bis" protokol (Bidi-Ack handshake) ist
anscheinend nicht 100% wasserdicht. Wo Bidi-Ack perfect funktioniert
beim ersten kommand, reagiert der thermostat nach das erste Bidi-Ack
nicht mehr, ach wenn er/sie meldet das wakemeup "0" ist.


Es kann etwas mit timing sein, (Und dass wiederspricht das prinzip vom
(async acknowledged bidirectional communication) protokol. Gibt es
einem timeout, der definiert wie lange FHEM auf dem ack wartet?

Ich hab ein log wobei ein ganze sekuenz klappt. Set temp nach fahrenheit zb,
Hab auch bidcos logs wobei die thermostat nach dem letzten "I'm Awake"
bericht nicht mehr reagiert, bis er/sie wider neu aufgewacht ist.
Muss sehen ob die fehlerfreie kommunikation reproduzierbar ist (oder nur zufall)

Vieleicht deshalb die retry's bei die Homeputer software. Layer 2bis part 2

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

[rudolfkoenig]

                                                   

> Gibt es einem timeout, der definiert wie lange FHEM auf dem ack wartet?

Beim HMLAN wird resend/retry vom HMLAN Firmware gemacht, und dieser sendet nur
eine Nachricht an fhem beim "MISSING-ACK". Beim CUL macht das 10_CUL_HM.pm,
deswegen sieht man alle Wiederholungen. Den Timeout habe ich dafuer auf 2*0.5
Sek gesetzt.

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

[LuckyDay]

                                         

ich habe einmal 3 Komandos auf einen TC abgesetzt mit Cul
und der nimmt es


CUL_HM eg_Halle_Hz1 desired-temp 18.0
CUL_HM eg_Halle_Hz1 desired-temp 20.0
CUL_HM eg_Halle_Hz1 statusRequest

CUL CUL2 RCV L:0C N:75 CMD:8670 (TYPE=112,WAKEMEUP,BCAST,RPTEN) SRC:
135B35 DST:000000 008B3B
CUL CUL2 SND L:09 N:77 CMD:A112 (TYPE=18,,BIDI,RPTEN) SRC:F12222 DST:
135B35  (HAVE_DATA)
CUL CUL2 RCV L:0A N:77 CMD:8002 (TYPE=2,RPTEN) SRC:135B35 DST:F12222
00 (ACK)
CUL CUL2 SND L:0C N:78 CMD:A011 (TYPE=17,BIDI,RPTEN) SRC:F12222 DST:
135B35 020224 (SET CHANNEL:02 VALUE:24)
CUL CUL2 RCV L:0E N:78 CMD:8002 (TYPE=2,RPTEN) SRC:135B35 DST:F12222
010224004A (ACK_STATUS CHANNEL:02 STATUS:24 RSSI:4A)
CUL CUL2 SND L:09 N:79 CMD:A112 (TYPE=18,,BIDI,RPTEN) SRC:F12222 DST:
135B35  (HAVE_DATA)
CUL_HM eg_Halle_Hz1 desired-temp-ack: 18
CUL CUL2 RCV L:0A N:79 CMD:8002 (TYPE=2,RPTEN) SRC:135B35 DST:F12222
00 (ACK)
CUL CUL2 SND L:0C N:7A CMD:A011 (TYPE=17,BIDI,RPTEN) SRC:F12222 DST:
135B35 020228 (SET CHANNEL:02 VALUE:28)
CUL CUL2 RCV L:0E N:7A CMD:8002 (TYPE=2,RPTEN) SRC:135B35 DST:F12222
010228004B (ACK_STATUS CHANNEL:02 STATUS:28 RSSI:4B)
CUL CUL2 SND L:0B N:7B CMD:A001 (TYPE=1,BIDI,RPTEN) SRC:F12222 DST:
135B35 010E (CONFIG_STATUS_REQUEST CHANNEL:01)
CUL_HM eg_Halle_Hz1 desired-temp-ack: 20
CUL CUL2 RCV L:0E N:7B CMD:8002 (TYPE=2,RPTEN) SRC:135B35 DST:F12222
010228004B (ACK_STATUS CHANNEL:02 STATUS:28 RSSI:4B)
CUL_HM eg_Halle_Hz1 desired-temp-ack: 20

On 14 Feb., 19:23, Johan van der Kolk
wrote:
> --Johan
>
>
>
>
>
>
>
>
>
> On Tue, Feb 14, 2012 at 8:30 AM, oskar wrote:
>
> > On Feb 13, 11:11 pm, Johan van der Kolk
> > wrote:
> >> Erfolg haben nur die kommands die folgen auf ein 8670 message vom
> >> HM-TT-TC (also ein broadcast).
> > Ja. Aber auch diejenigen directed messages, welche an die Zentrale
> > geschickt wurden, können erfolgreich mit einer Parametereinstellung
> > beantwortet werden.
> >> Die kommands die abgeschickt werden nach einem thermostat-valve
> >> kommunikation klappen nicht.
>
> > Auch wenn sich bis zum Funkkontakt mehrere Kommandos angesammelt
> > haben, klappt nur das erste:
> > 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:0B N:47 CMD:A001 SRC:5D24C9
> > DST:15B50D 0206 (CONFIG_END CHANNEL:02)
> > 2012-02-13 18:16:12 HMLAN HMLAN23 RCV L:0A N:47 CMD:8002 SRC:15B50D
> > DST:5D24C9 00 (ACK)
> > 2012-02-13 18:16:12 HMLAN HMLAN23 SND L:09 N:48 CMD:A112 SRC:5D24C9
> > DST:15B50D  (HAVE_DATA)
> > 2012-02-13 18:16:13 CUL_HM CUL_HM_HM_CC_TC_15B50D MISSING ACK
>
> Leider sieht das genau so aus beim Bidcos logs
> Diese handshakes, die ich mal Layer2 protokol nennen wird (WakeUp- I'm
> Awake) und das "layer 2bis" protokol (Bidi-Ack handshake) ist
> anscheinend nicht 100% wasserdicht. Wo Bidi-Ack perfect funktioniert
> beim ersten kommand, reagiert der thermostat nach das erste Bidi-Ack
> nicht mehr, ach wenn er/sie meldet das wakemeup "0" ist.
>
> Es kann etwas mit timing sein, (Und dass wiederspricht das prinzip vom
> (async acknowledged bidirectional communication) protokol. Gibt es
> einem timeout, der definiert wie lange FHEM auf dem ack wartet?
>
> Ich hab ein log wobei ein ganze sekuenz klappt. Set temp nach fahrenheit zb,
> Hab auch bidcos logs wobei die thermostat nach dem letzten "I'm Awake"
> bericht nicht mehr reagiert, bis er/sie wider neu aufgewacht ist.
> Muss sehen ob die fehlerfreie kommunikation reproduzierbar ist (oder nur zufall)
>
> Vieleicht deshalb die retry's bei die Homeputer software. Layer 2bis part 2

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

[Guest]

Originally posted by: <email address deleted>

--Johan

Mann koentte mal ein vergleich machen.
Oskars kommands, die nicht bei HM-LAN klappen, auch auf dem CUL laufen lassen.

Die HM-Lan timeout gibt sich selber wenig zeit wenn die timestamps
millisekunden sind.

TX:  @1578280656 0x174286 -> 0x178A9C CONFIG_PARAM_REQ [IEQ0245464]:
  CNT=15,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01
  CONFIG_CHANNEL = 2
  CONFIG_PEER_ADDRESS = 0x000000
  CONFIG_PEER_CHANNEL = 0
  CONFIG_PARAM_LIST = 5

SendFrame failed 1 times:  @1578280656 0x174286 -> 0x178A9C
CONFIG_PARAM_REQ [IEQ0245464]:
  CNT=15,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01
  CONFIG_CHANNEL = 2
  CONFIG_PEER_ADDRESS = 0x000000
  CONFIG_PEER_CHANNEL = 0
  CONFIG_PARAM_LIST = 5

TX:  @1578281312 0x174286 -> 0x178A9C CONFIG_PARAM_REQ [IEQ0245464]:
  CNT=16,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01
  CONFIG_CHANNEL = 2
  CONFIG_PEER_ADDRESS = 0x000000
  CONFIG_PEER_CHANNEL = 0
  CONFIG_PARAM_LIST = 5

SendFrame failed 2 times:  @1578281312 0x174286 -> 0x178A9C
CONFIG_PARAM_REQ [IEQ0245464]:
  CNT=16,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01
  CONFIG_CHANNEL = 2
  CONFIG_PEER_ADDRESS = 0x000000
  CONFIG_PEER_CHANNEL = 0
  CONFIG_PARAM_LIST = 5




On Tue, Feb 14, 2012 at 7:42 PM, fhem-hm-knecht wrote:
> ich habe einmal 3 Komandos auf einen TC abgesetzt mit Cul
> und der nimmt es
>
>
> CUL_HM eg_Halle_Hz1 desired-temp 18.0
> CUL_HM eg_Halle_Hz1 desired-temp 20.0
> CUL_HM eg_Halle_Hz1 statusRequest
>

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

[Guest]

Originally posted by: <email address deleted>

habe nach rereadcfg und shutdown restart endlich wieder rechts ne
sinnvolle anzeige......

... dir temp am rechten (drehrumbum) rad entspricht der ist-temp...
ist da nicht einfach was falsch programmiert/vertauscht

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