HM-CC-TC Thermostat setpoints

[Guest]

Originally posted by: <email address deleted>

Apologies for using the wrong Title in my previous msg. Please delete

--Johan




Hello,

I''m new to FHEM, new to Home Automation...and not native German speaking

I have started using the Homematic system, and particularly the HM-CC-TC.

I noticed that setpoints are now logged, but also noticed that not all
setpoint changes are registered.

Learning Perl is probably the next step, but until I have mastered the
basics, I would like to share some information regarding the logging
of desired-temps.

For what its worth, I logged some received commands from a HM-CC-TC on
a BidCos PC. I am using a HM Lan adapter, which is separate from the
actual system (other PC, not paired with anything), and only receives
information sent by the thermostat.

I hope someone can do more with this information than I am currently
capable of.

Feel free to respond in German, I have no problem speaking or reading.

Johan

Here's the log capture:



change temp on thermostat in manu mode

Thermostat broadcasts the information, without request:

RX for HEQ0132796: @288678974 RSSI=-46dB 0x1375C2 -> 0x0EFFDA
INFO_ACTUATOR_STATUS [IEQ0245464]:
 CNT=77,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
 CHANNEL = 2
 STATUS = 39
 STATE = 0
 CLOCK = 0
 LOWBAT = 0
 DUTY_CYCLE = 0
 RSSI = 0

Event: HEQ0132796:2.SETPOINT=19.500000

Recorded in LogFile as desired-temp, Status in WebInterface updated

---------------------------------------------------------------
Change Temp from FHEM, thermostat in Manu mode

RX for HEQ0132796: @289093408 RSSI=-48dB 0x1375C2 -> 0x0EFFDA
ACK_STATUS [IEQ0245464]:
 CNT=14,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x02
 CHANNEL = 2
 STATUS = 26
 STATE = 0
 CLOCK = 0
 LOWBAT = 0
 DUTY_CYCLE = 0
 RSSI = 57

Event: HEQ0132796:2.SETPOINT=13.000000

Command appears in logfile when set (desired-temp), but actual
confirmation (above) from thermostat does not. This confirmation came
about a minute later, when the thermostat changed also its displayed
set temperature.
WebInterface is not updated

-----------------------------------------------------------------------

Change temp from thermostat while in Cent Mode

RX for HEQ0132796: @289599772 RSSI=-46dB 0x1375C2 -> 0x0EFFDA
INFO_ACTUATOR_STATUS [IEQ0245464]:
 CNT=83,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
 CHANNEL = 2
 STATUS = 30
 STATE = 0
 CLOCK = 0
 LOWBAT = 0
 DUTY_CYCLE = 0
 RSSI = 0

Event: HEQ0132796:2.SETPOINT=15.000000

Broadcasting desired temp, goes in logfile, no status update on WebInterface

Just a bit later, thermostat falls back to earlier setpoint, and
broadcasts this as well
RX for HEQ0132796: @289701528 RSSI=-52dB 0x1375C2 -> 0x0EFFDA
INFO_ACTUATOR_STATUS [IEQ0245464]:
 CNT=84,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
 CHANNEL = 2
 STATUS = 26
 STATE = 0
 CLOCK = 0
 LOWBAT = 0
 DUTY_CYCLE = 0
 RSSI = 0

Event: HEQ0132796:2.SETPOINT=13.000000

Event is not logged in FHEM

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

[Oskar]

                                                     

Thank you for this information, I'll try to figure out how to figure out what happens here.  
Maybe Rudi can make sense out of it sooner, but nevertheless thanks.
Keep on making sense of it all

Cheers
   Oskar
Am 24.01.2012 um 21:13 schrieb Johan van der Kolk:

> Apologies for using the wrong Title in my previous msg. Please delete
>
> --Johan
>
>
>
>
> Hello,
>
> I''m new to FHEM, new to Home Automation...and not native German speaking
>
> I have started using the Homematic system, and particularly the HM-CC-TC.
>
> I noticed that setpoints are now logged, but also noticed that not all
> setpoint changes are registered.
>
> Learning Perl is probably the next step, but until I have mastered the
> basics, I would like to share some information regarding the logging
> of desired-temps.
>
> For what its worth, I logged some received commands from a HM-CC-TC on
> a BidCos PC. I am using a HM Lan adapter, which is separate from the
> actual system (other PC, not paired with anything), and only receives
> information sent by the thermostat.
>
> I hope someone can do more with this information than I am currently
> capable of.
>
> Feel free to respond in German, I have no problem speaking or reading.
>
> Johan
>
> Here's the log capture:
>
>
>
> change temp on thermostat in manu mode
>
> Thermostat broadcasts the information, without request:
>
> RX for HEQ0132796: @288678974 RSSI=-46dB 0x1375C2 -> 0x0EFFDA
> INFO_ACTUATOR_STATUS [IEQ0245464]:
>  CNT=77,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
>  CHANNEL = 2
>  STATUS = 39
>  STATE = 0
>  CLOCK = 0
>  LOWBAT = 0
>  DUTY_CYCLE = 0
>  RSSI = 0
>
> Event: HEQ0132796:2.SETPOINT=19.500000
>
> Recorded in LogFile as desired-temp, Status in WebInterface updated
>
> ---------------------------------------------------------------
> Change Temp from FHEM, thermostat in Manu mode
>
> RX for HEQ0132796: @289093408 RSSI=-48dB 0x1375C2 -> 0x0EFFDA
> ACK_STATUS [IEQ0245464]:
>  CNT=14,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x02
>  CHANNEL = 2
>  STATUS = 26
>  STATE = 0
>  CLOCK = 0
>  LOWBAT = 0
>  DUTY_CYCLE = 0
>  RSSI = 57
>
> Event: HEQ0132796:2.SETPOINT=13.000000
>
> Command appears in logfile when set (desired-temp), but actual
> confirmation (above) from thermostat does not. This confirmation came
> about a minute later, when the thermostat changed also its displayed
> set temperature.
> WebInterface is not updated
>
> -----------------------------------------------------------------------
>
> Change temp from thermostat while in Cent Mode
>
> RX for HEQ0132796: @289599772 RSSI=-46dB 0x1375C2 -> 0x0EFFDA
> INFO_ACTUATOR_STATUS [IEQ0245464]:
>  CNT=83,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
>  CHANNEL = 2
>  STATUS = 30
>  STATE = 0
>  CLOCK = 0
>  LOWBAT = 0
>  DUTY_CYCLE = 0
>  RSSI = 0
>
> Event: HEQ0132796:2.SETPOINT=15.000000
>
> Broadcasting desired temp, goes in logfile, no status update on WebInterface
>
> Just a bit later, thermostat falls back to earlier setpoint, and
> broadcasts this as well
> RX for HEQ0132796: @289701528 RSSI=-52dB 0x1375C2 -> 0x0EFFDA
> INFO_ACTUATOR_STATUS [IEQ0245464]:
>  CNT=84,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=1,TYPE=0x10
>  CHANNEL = 2
>  STATUS = 26
>  STATE = 0
>  CLOCK = 0
>  LOWBAT = 0
>  DUTY_CYCLE = 0
>  RSSI = 0
>
> Event: HEQ0132796:2.SETPOINT=13.000000
>
> Event is not logged in FHEM
>
> --
> 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]

                                                   

> I hope someone can do more with this information than I am currently
> capable of.

I would be more keen on seeing the messages in the "hmProtocolEvents" format,
as I still dont know the mapping between the RPTEN,RPTED,BIDI,BURST,etc flags
and the bytes in fhem. Of course I would be very grateful if you could
establish this mapping, especially when you could tell us what these flags
mean.  This would most certainly result in cleanups in the CUL_HM module.


> Thermostat broadcasts the information, without request:
...
Dont understand your problem with this message.


> Command appears in logfile when set (desired-temp), but actual
> confirmation (above) from thermostat does not.

Since message content is device-type dependent and fhem does not know about the
type of the source, i.e. the CC-VD, as it has seen no learning message from it,
the message will be ignored.


> Broadcasting desired temp, goes in logfile, no status update on WebInterface

Only certain types are put into the status field.

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

[Guest]

Originally posted by: <email address deleted>

Home Matic Rawmsg analysis
A1 0 58 A4 10 1375C2 0EFFDA 0602 2C    00000000

A is extension of the Pre-amble (10101010)
That reduces the syncword from 2 to 1 bytes

So messages starting with A1 or A0 have either 1 or 0 as the syncword.

The next byte could be the length but I believe it may already be
payload, have not figured out what it is
The next two bytes (4&5) contain the message counter
Bytes 6 & 7 contain the RPTEN etc stuff in bit mapped format

I believe it's like this:
RPTEN(bit7),RPTED(bit6),BIDI(bit5),BURST(bit4),WAKEUP(bit3),BCAST(bit2),WAKEMEUP(bit1),
()bit 0. where bit 7 is MSB.

Bytes 8&9 contain the messagecounter
Bytes 10-16 the HM address
Bytes 17-22 contain the ACK.
the next 4 I don't know yet (maybe contains the channel number)
I have not figured out why the zero's are there.

msg length is variable, so I assume there must be a mechanism to
identify that, but it could also be defined by E3q as part of the
messagetype (0x02 is 20 long, 0x70 is 10 long, etc). Suggestions?


The message that is sent by the thermostat and not being picked up by
FHEM is the following:
"Sends ack and new setpoint in one msg"

A0 E 0B 80 02 1375C2 0EFFDA 0102 1C 0044
RX for HEQ0132796: @369444264 RSSI=-48dB 0x1375C2 -> 0x0EFFDA
ACK_STATUS [IEQ0245464]:
  CNT=11,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x02
  CHANNEL = 2
  STATUS = 28
  STATE = 0
  CLOCK = 0
  LOWBAT = 0
  DUTY_CYCLE = 0
  RSSI = 68

Event: HEQ0132796:2.SETPOINT=14.000000


The first asksin message in my previous mail was correct indeed, I
just mentioned it as an example. The one above is not processed
correctly.

So I'm not sure if I added something useful, but given this is my
first try I hope I'm not adding confusion

--Johan



On Wed, Jan 25, 2012 at 7:59 AM, Rudolf Koenig wrote:
>> I hope someone can do more with this information than I am currently
>> capable of.
>
> I would be more keen on seeing the messages in the "hmProtocolEvents" format,
> as I still dont know the mapping between the RPTEN,RPTED,BIDI,BURST,etc flags
> and the bytes in fhem. Of course I would be very grateful if you could
> establish this mapping, especially when you could tell us what these flags
> mean.  This would most certainly result in cleanups in the CUL_HM module.
>
>
>> Thermostat broadcasts the information, without request:
> ...
> Dont understand your problem with this message.
>
>
>> Command appears in logfile when set (desired-temp), but actual
>> confirmation (above) from thermostat does not.
>
> Since message content is device-type dependent and fhem does not know about the
> type of the source, i.e. the CC-VD, as it has seen no learning message from it,
> the message will be ignored.
>
>
>> Broadcasting desired temp, goes in logfile, no status update on WebInterface
>
> Only certain types are put into the status field.
>
> --
> 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>

Slight correction due to a typo. Bytes 8&9 contain the message type.

--Johan



On Wed, Jan 25, 2012 at 10:05 PM, Johan van der Kolk
wrote:
> Home Matic Rawmsg analysis
> A1 0 58 A4 10 1375C2 0EFFDA 0602 2C    00000000
>
> A is extension of the Pre-amble (10101010)
> That reduces the syncword from 2 to 1 bytes
>
> So messages starting with A1 or A0 have either 1 or 0 as the syncword.
>
> The next byte could be the length but I believe it may already be
> payload, have not figured out what it is
> The next two bytes (4&5) contain the message counter
> Bytes 6 & 7 contain the RPTEN etc stuff in bit mapped format
>
> I believe it's like this:
> RPTEN(bit7),RPTED(bit6),BIDI(bit5),BURST(bit4),WAKEUP(bit3),BCAST(bit2),WAKEMEUP(bit1),
> ()bit 0. where bit 7 is MSB.
>
> Bytes 8&9 contain the messagetype
> Bytes 10-16 the HM address
> Bytes 17-22 contain the ACK.
> the next 4 I don't know yet (maybe contains the channel number)
> I have not figured out why the zero's are there.
>
> msg length is variable, so I assume there must be a mechanism to
> identify that, but it could also be defined by E3q as part of the
> messagetype (0x02 is 20 long, 0x70 is 10 long, etc). Suggestions?
>
>
> The message that is sent by the thermostat and not being picked up by
> FHEM is the following:
> "Sends ack and new setpoint in one msg"
>
> A0 E 0B 80 02 1375C2 0EFFDA 0102 1C 0044
> RX for HEQ0132796: @369444264 RSSI=-48dB 0x1375C2 -> 0x0EFFDA
> ACK_STATUS [IEQ0245464]:
>  CNT=11,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x02
>  CHANNEL = 2
>  STATUS = 28
>  STATE = 0
>  CLOCK = 0
>  LOWBAT = 0
>  DUTY_CYCLE = 0
>  RSSI = 68
>
> Event: HEQ0132796:2.SETPOINT=14.000000
>
>
> The first asksin message in my previous mail was correct indeed, I
> just mentioned it as an example. The one above is not processed
> correctly.
>
> So I'm not sure if I added something useful, but given this is my
> first try I hope I'm not adding confusion
>
> --Johan
>
>
>
> On Wed, Jan 25, 2012 at 7:59 AM, Rudolf Koenig wrote:
>>> I hope someone can do more with this information than I am currently
>>> capable of.
>>
>> I would be more keen on seeing the messages in the "hmProtocolEvents" format,
>> as I still dont know the mapping between the RPTEN,RPTED,BIDI,BURST,etc flags
>> and the bytes in fhem. Of course I would be very grateful if you could
>> establish this mapping, especially when you could tell us what these flags
>> mean.  This would most certainly result in cleanups in the CUL_HM module.
>>
>>
>>> Thermostat broadcasts the information, without request:
>> ...
>> Dont understand your problem with this message.
>>
>>
>>> Command appears in logfile when set (desired-temp), but actual
>>> confirmation (above) from thermostat does not.
>>
>> Since message content is device-type dependent and fhem does not know about the
>> type of the source, i.e. the CC-VD, as it has seen no learning message from it,
>> the message will be ignored.
>>
>>
>>> Broadcasting desired temp, goes in logfile, no status update on WebInterface
>>
>> Only certain types are put into the status field.
>>
>> --
>> 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]

                                                   

> > I believe it's like this:
> > RPTEN(bit7),RPTED(bit6),BIDI(bit5),BURST(bit4),WAKEUP(bit3),BCAST(bit2),WAKEMEUP(bit1),
> > ()bit 0. where bit 7 is MSB.

Thanks for the info. Now it would be nice to know the meaning of those bits,
giving them a name is only the start


> > Bytes 8&9 contain the messagetype
...
Note that by enabling hmProtocolEvents you will see how fhem splits the
message. I think it has no problem with the Length/Counter/Src and Dest fields.
The Payload (the data following the destination) is device dependent.

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

[Guest]

Originally posted by: <email address deleted>

I modified CUL_HM to show the received bits by name in the level 4
logs with hmProtocolEvents.
For me the bits still make sense and match the debug log from a second
LAN adapter, in the way I described them.

For sure some report/set the radio status to support the WOR capabilty
of the CC1100 chip.
Unfortunately I can't debug any further. I can't get the homeputer
stuff to run at all so no comparison possible.
Currently I only see the incoming data from one TH appearing on that
LAN adapter, (why not from all 6, I don't know)
The bits I can confirm are RPTED, BCAST, BIDI and WAKEMEUP. The other
bits are never activated in my setup

Johan





On Thu, Jan 26, 2012 at 8:42 AM, Rudolf Koenig wrote:
>> > I believe it's like this:
>> > RPTEN(bit7),RPTED(bit6),BIDI(bit5),BURST(bit4),WAKEUP(bit3),BCAST(bit2),WAKEMEUP(bit1),
>> > ()bit 0. where bit 7 is MSB.
>
> Thanks for the info. Now it would be nice to know the meaning of those bits,
> giving them a name is only the start
>
>

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

[Guest]

Originally posted by: <email address deleted>

Ich antworte michselber mahl.

Protokol fuer HomeMatic (brauche bestaetigung hier !)

1. Kommando zu thermostat von HM-Lan mit BIDI bit gesetzt (I need Ack)
2. Kein antwort wenn die TC schlaft, versuch es noch einmal, wenn
wieder kein antwort wecken mit A1 im bitmap und ein type 12 bericht,
und kein daten.(A1 meint RPTEN, BIDI(will ein Ack) und wakeup/burst
    3.(a) Die A1 wuerde bedeuten das bit 1 von dieses bitmapped wort
burst oder wakeup ist.
4. Das A1-12 bericht wird widerholt bis die TC antwortet mit einem ACK
bericht in dem  das Wakemeup bit 0 ist.
5. Dan wird das erste kommando noch mahl abgeschickt.
komt ein Ack zurick mit dem gleihen message counter ist die sache
geschaft, sonst versuchen wir is erneut

Also ein BIDI bericht erwartet ein ACK mit die gleiche counter.

Beim homematic configurator sieht man waehrend diese sequenz
"Konfigurationsdaten stehen zur Ãœbertragung an" Die gewunschte aber
nicht gelungene konfigurations aenderung wird auch gespeicherd bis es
gelungen ist, (nach program neustart fangt die konfigurator wieder an
mit neuversuche um die daten weg zu schrieben zum TC)

Das A112 bericht wurde bei mir hex33 mahl wiederholt bevor ein antwort
kam, jedes mahl mit ein neuen counter wert.  Leider werden diese
berichte nicht im Bidcos log gezeigt. Aber zwichen das erste kommando
and den Ack gab es eine counterwert luecke von 33 (hex).


--Johan
--Johan



On Fri, Jan 27, 2012 at 7:43 PM, Johan van der Kolk
wrote:
> I modified CUL_HM to show the received bits by name in the level 4
> logs with hmProtocolEvents.
> For me the bits still make sense and match the debug log from a second
> LAN adapter, in the way I described them.
>
> For sure some report/set the radio status to support the WOR capabilty
> of the CC1100 chip.
> Unfortunately I can't debug any further. I can't get the homeputer
> stuff to run at all so no comparison possible.
> Currently I only see the incoming data from one TH appearing on that
> LAN adapter, (why not from all 6, I don't know)
> The bits I can confirm are RPTED, BCAST, BIDI and WAKEMEUP. The other
> bits are never activated in my setup
>
> Johan
>
>
>
>
>
> On Thu, Jan 26, 2012 at 8:42 AM, Rudolf Koenig wrote:
>>> > I believe it's like this:
>>> > RPTEN(bit7),RPTED(bit6),BIDI(bit5),BURST(bit4),WAKEUP(bit3),BCAST(bit2),WAKEMEUP(bit1),
>>> > ()bit 0. where bit 7 is MSB.
>>
>> Thanks for the info. Now it would be nice to know the meaning of those bits,
>> giving them a name is only the start
>>
>>

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

[Guest]

Originally posted by: <email address deleted>

Ich hab den neuen Datei nicht mit geschickt, weil er nur den
evaluation macht am empfangseite, die weitere Befehle nicht anruehrt
und damit alles bricht im moment.
Ausserdem bin ich nur sicher von 3 bits, und schon fast sicher das ein
status von dem ich dachte das auf bit 1 lag falsch ist.

Ich habe ubrichens ein anderes topic gestarted, Diesen topic title is
nicht richtig mehr.
Antwort habe Ich bis jetzt nicht auf meine erste Frage, aber ich
glaube jetzt das die code einige teile vom message (statusbytes)
aendert bevor diese im log zu schreiben. Es waehre besser die code zu
optimalisieren und keine replace mehr zu machen.

Ich meine dieses stuckchen code:

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

aber, seit Ich kein Perl verstehe, bin Ich moeglicherweise total falsch

Leider kann ich nicht programmieren, Perl ist total unbekannt fuer
mich, und meine letzte programmier versuche sind schon ueber 25 jahre
her. Koente dir die modifizierte Datei uber ein PM zuschicken.


--Johan



On Sun, Jan 29, 2012 at 11:01 AM, Jan-Hinrich Fessel
wrote:
>
> Am 27.01.2012 um 19:43 schrieb Johan van der Kolk:
>
>> I modified CUL_HM to show the received bits by name in the level 4
>> logs with hmProtocolEvents.
>
> Do you want to share this modification?
>
> Cheers
>        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]

                                                     

Am 29.01.2012 um 17:36 schrieb Johan van der Kolk:

> Ich hab den neuen Datei nicht mit geschickt, weil er nur den
> evaluation macht am empfangseite, die weitere Befehle nicht anruehrt
> und damit alles bricht im moment.
> Ausserdem bin ich nur sicher von 3 bits, und schon fast sicher das ein
> status von dem ich dachte das auf bit 1 lag falsch ist.

Auch fein

> Ich habe ubrichens ein anderes topic gestarted, Diesen topic title is
> nicht richtig mehr.

Hab ich schon gesehen.  Jetzt hier auch mit neuem Titel.

> Antwort habe Ich bis jetzt nicht auf meine erste Frage, aber ich
> glaube jetzt das die code einige teile vom message (statusbytes)
> aendert bevor diese im log zu schreiben. Es waehre besser die code zu
> optimalisieren und keine replace mehr zu machen.

Das ist mir auch schon unangenehm aufgefallen.  Ich habe aber nicht genug Zeit gefunden, das warum zu verstehen um das Problem eventuell zu beheben.

> Ich meine dieses stuckchen code:
>
> $cmd = "0A$1" if($cmd =~ m/0B(..)/);
>  $cmd = "A4$1" if($cmd =~ m/84(..)/);
>  $cmd = "8000" if(($cmd =~ m/A40./ || $cmd eq "0400") && $len eq "1A");
>  $cmd = "A0$1" if($cmd =~ m/A4(..)/);
>
> aber, seit Ich kein Perl verstehe, bin Ich moeglicherweise total falsch

Nein, das hat Du schon richtig erkannt.  Ich dachte bislang, das hier doppelte dekodierung eingespart werden sollte und gleichzeitig schon die "richtigen" codes für das ACK bzw. die Antwort generiert werden.
Weswegen ich mich auch nicht getraut habe, das anzufassen.

Grüße
   Oskar

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

[Oskar]

                                                     

Am 27.01.2012 um 19:43 schrieb Johan van der Kolk:

> I modified CUL_HM to show the received bits by name in the level 4
> logs with hmProtocolEvents.

Do you want to share this modification?

Cheers
   Oskar

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