HomeMatic Heizungssteuerung HM-CC-TC Grafig

[Guest]

Originally posted by: <email address deleted>

Broadcast and 000000 have so far always coincided here. Not that that
is a guarantee though. I also wondered why this is double, but one
could assume that receivers would interpret a dst of 000000 without
broadcast bit as a faulty message. The radiochip is not exclusively
used for Homematic, so there are probably variations that we would
never see. (like the dst is now a network address)
Possibly this one can be looked up in the datasheet for the radio, so
i'll investigate tonight.

On the wake up I have a trace. It involves making a setting on the
thermostat (going from C to F if I remember correctly). That would not
require waking up a valve.
I'll forward that trace tonight when I'm back home.

kind regards,

--Johan



On Wed, Feb 8, 2012 at 2:33 PM, Rudolf Koenig wrote:
>> BROADCAST : no explanation required, msg sent without destination address.
>
> Little bit strange, as there is also the broadcast address of 000000.
> What should we do if they (bit and address) do not match?
>
>
>> WAKEUP: as the thermostats are normally sleeping setting this bit
>> should wake up the thermostat
>
> This makes little sense to me, since I thought that the thermostat is sending a
> command to the valve on wakeup, and this is the signal for the CCU/fhem to
> start sending. Do you have some evidence, that the CC-TC is awake more often?
>
>
>> WAKEMEUP: normal status "1" for the thermostat. Just means I'm
>> currently asleep
>
> Another strange bit. Normally you are not talking when you are sleeping, I hope
> the CC-TC is no exception. Anyway I'll add the bits, just in order to be able
> to analyze them.
>
> --
> 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

[rudolfkoenig]

                                                   

Hi Johan,

I've added your interpretation of the command bits to the hmProtocoleEvents
decoding (see the SVN). Could you please check, if it is done correctly?

Thanks,
  Rudi

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

[Guest]

Originally posted by: <email address deleted>

Rudolph.

You are running the evaluation here:
1624         my @culHmCmdBits = ( "", "WAKEMEUP", "BCAST", "WAKEUP",
"BURST", "BIDI", "RPTED", "RPTEN");

1639    my $cmdInt = hex($cmd)>>8;
1640    my $cmdBits="TYPE=".(hex($cmd)&0xff);
1641    for(my $i = 0; $i < @culHmCmdBits; $i++) {
1642    $cmdBits .= ",$culHmCmdBits[$i]" if($cmdInt & (1<<$i));

So I assume you are evaluating from LSBit to MSBit
In that order line 1624 should look like this:

1624         my @culHmCmdBits = ( "WAKEUP", "WAKEMEUP", "BCAST", "",
"BURST", "BIDI", "RPTED", "RPTEN");

where you also may replace BURST with "", because bits 3 and 4 are
never active on my setup (so unconfirmed).
Moving the WAKEUP to the first bit is a modification I sent in a later message.

Note that the bits shown here will not be in line with the message in
hmProtocolEvents since this replacement is still here:

1645    $cmd = "0A$1" if($cmd =~ m/0B(..)/);
1646    $cmd = "A4$1" if($cmd =~ m/84(..)/);
1647    $cmd = "8000" if(($cmd =~ m/A40./ || $cmd eq "0400") && $len eq "1A");
1648    $cmd = "A0$1" if($cmd =~ m/A4(..)/);


and thanks to you and the team for all the other improvements put in
the CUL_HM module. Nice surprise after updatefhem started working
again.

--Johan



On Sat, Feb 11, 2012 at 4:03 PM, Rudolf Koenig wrote:
> Hi Johan,
>
> I've added your interpretation of the command bits to the hmProtocoleEvents
> decoding (see the SVN). Could you please check, if it is done correctly?
>
> Thanks,
>  Rudi
>
> --
> 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