Originally posted by: <email address deleted>
Hallo FHEM Gemeinde,
möchte Umsetzung Grafikanzeige für Heizungssteuerung HM-CC-TC für alle zur
Verfügung stellen.
Es wird gemessene Temperatur und Ventilstellung angezeigt. Mit dem
fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.
Leider erfolgt keine Ausgabe der "desired-temp" im Log, sonst könnte man
diese auch anzeigen.
############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define
FileLog /var/log/fhem/actuator_name-%Y.log
:(measured-temp|actuator).*
set terminal png transparent size crop
set output '.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title ''
set grid xtics y2tics
set y2label "Temperatur in C"
set ylabel "Ventil (%)"
#FileLog 4:measured:10:
#FileLog 4:actuator:50:
plot \
"< egrep 'temperature' "\
using 1:4 axes x1y2 title 'Temperaturm in C' with lines,\
"< egrep 'actuator' "\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Wiki -> done
On 4 Feb., 13:32, Lipo
wrote:
> Hallo FHEM Gemeinde,
> möchte Umsetzung Grafikanzeige für Heizungssteuerung HM-CC-TC für alle zur
> Verfügung stellen.
> Es wird gemessene Temperatur und Ventilstellung angezeigt. Mit dem
> fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.
> Leider erfolgt keine Ausgabe der "desired-temp" im Log, sonst könnte man
> diese auch anzeigen.
>
> ############################
> # Display the measured temp and the actuator.
> # Corresponding FileLog definition:
> # define FileLog /var/log/fhem/actuator_name-%Y.log
> :(measured-temp|actuator).*
>
> set terminal png transparent size crop
> set output '.png'
> set xdata time
> set timefmt "%Y-%m-%d_%H:%M:%S"
> set xlabel " "
> set ytics nomirror
> set y2tics
> #set ytics
> set title ''
> set grid xtics y2tics
>
> set y2label "Temperatur in C"
> set ylabel "Ventil (%)"
>
> #FileLog 4:measured:10:
> #FileLog 4:actuator:50:
>
> plot \
> "< egrep 'temperature' "\
> using 1:4 axes x1y2 title 'Temperaturm in C' with lines,\
> "< egrep 'actuator' "\
> using 1:4 axes x1y1 title 'Ventil (%)' with lines\
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ähm, tja, das kommt davon, wenn man wartet. Aber eigentlich hatten wir das Thema auch schon mal und keiner hats ins wiki gedingst.
Naja, im Wiki gibts jetzt noch eine andere Variante. Mit desired-temp und Feuchte.
Und ja, nur im Wiki ;-)
Grüße
Oskar
Am 04.02.2012 um 14:25 schrieb Zrrronggg!:
> Wiki -> done
>
> On 4 Feb., 13:32, Lipo
wrote:
>> Hallo FHEM Gemeinde,
>> möchte Umsetzung Grafikanzeige für Heizungssteuerung HM-CC-TC für alle zur
>> Verfügung stellen.
>> Es wird gemessene Temperatur und Ventilstellung angezeigt. Mit dem
>> fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.
>> Leider erfolgt keine Ausgabe der "desired-temp" im Log, sonst könnte man
>> diese auch anzeigen.
>>
>> ############################
>> # Display the measured temp and the actuator.
>> # Corresponding FileLog definition:
>> # define FileLog /var/log/fhem/actuator_name-%Y.log
>> :(measured-temp|actuator).*
>>
>> set terminal png transparent size crop
>> set output '.png'
>> set xdata time
>> set timefmt "%Y-%m-%d_%H:%M:%S"
>> set xlabel " "
>> set ytics nomirror
>> set y2tics
>> #set ytics
>> set title ''
>> set grid xtics y2tics
>>
>> set y2label "Temperatur in C"
>> set ylabel "Ventil (%)"
>>
>> #FileLog 4:measured:10:
>> #FileLog 4:actuator:50:
>>
>> plot \
>> "< egrep 'temperature' "\
>> using 1:4 axes x1y2 title 'Temperaturm in C' with lines,\
>> "< egrep 'actuator' "\
>> using 1:4 axes x1y1 title 'Ventil (%)' with lines\
>
> --
> 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
Originally posted by: <email address deleted>
Der bestehende Wiki- Eintrag bezieht sich auf einen FHT80b
Bei diesem steht wohl dann auch "desirend-temp" im Log.
Bei mir kommt nur:
actuator: 5 %
T: 20.1 H: 44
measured-temp: 20.1
temperature: 20.1
humidity: 44
mesured-temp und temperature geben wohl den gleichen Wert an.
Leider wird keine "derired-temp" ausgegeben.
Kann das jemand ändern?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 04.02.2012 um 17:08 schrieb Lipo:
> Der bestehende Wiki- Eintrag bezieht sich auf einen FHT80b
Nun ja, wie man es nimmt, es ist die Definition des Plots meines HM_CC_TC.
> Bei diesem steht wohl dann auch "desirend-temp" im Log.
> Bei mir kommt nur:
> actuator: 5 %
> T: 20.1 H: 44
> measured-temp: 20.1
> temperature: 20.1
> humidity: 44
>
> mesured-temp und temperature geben wohl den gleichen Wert an.
> Leider wird keine "derired-temp" ausgegeben.
>
> Kann das jemand ändern?
Du selber kannst es, die File-Log Definition sollte keinen Filter enthalten, siehe aktualisierten wiki-Eintrag: http://fhemwiki.de/wiki/HM-CC-TC
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Du selber kannst es, die File-Log Definition sollte keinen Filter
enthalten, siehe aktualisierten wiki-Eintrag:
http://fhemwiki.de/wiki/HM-CC-TC
Ich habe auch ein FileLog ohne Filter:
define HZ_TReg_1_FLog_text FileLog ./log/HZ_TReg_1-text_%Y-%m-%d.log *
HZ_TReg_1*
attr HZ_TReg_1_FLog_text logtype text
Bei mir tauchen allerdings keine Eintraege "desired-temp" auf.
2012-02-05_09:57:11 HZ_TReg_1 measured-temp: 19.9
2012-02-05_09:57:11 HZ_TReg_1 temperature: 19.9
2012-02-05_09:57:11 HZ_TReg_1 humidity: 42
2012-02-05_09:57:31 HZ_TReg_1 actuator: 91 %
2012-02-05_09:59:34 HZ_TReg_1 T: 19.9 H: 42
Wie sieht das bei Dir aus?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 05.02.2012 um 10:07 schrieb Lipo:
> > Du selber kannst es, die File-Log Definition sollte keinen Filter enthalten, siehe aktualisierten wiki-Eintrag: http://fhemwiki.de/wiki/HM-CC-TC
>
> Ich habe auch ein FileLog ohne Filter:
> define HZ_TReg_1_FLog_text FileLog ./log/HZ_TReg_1-text_%Y-%m-%d.log HZ_TReg_1
> attr HZ_TReg_1_FLog_text logtype text
define FileLog_CUL_HM_HM_CC_TC FileLog /var/log/fhem/CUL_HM_HM_CC_TC-%Y.log CUL_HM_HM_CC_TC
attr FileLog_CUL_HM_HM_CC_TC logtype hmcc:Temp/Act,text
> Bei mir tauchen allerdings keine Eintraege "desired-temp" auf.
>
> 2012-02-05_09:57:11 HZ_TReg_1 measured-temp: 19.9
> 2012-02-05_09:57:11 HZ_TReg_1 temperature: 19.9
> 2012-02-05_09:57:11 HZ_TReg_1 humidity: 42
> 2012-02-05_09:57:31 HZ_TReg_1 actuator: 91 %
> 2012-02-05_09:59:34 HZ_TReg_1 T: 19.9 H: 42
>
> Wie sieht das bei Dir aus?
>
2012-02-04_17:09:25 CUL_HM_HM_CC_TC T: 17 H: 33
2012-02-04_17:09:25 CUL_HM_HM_CC_TC measured-temp: 17
2012-02-04_17:09:25 CUL_HM_HM_CC_TC temperature: 17
2012-02-04_17:09:25 CUL_HM_HM_CC_TC humidity: 33
2012-02-04_17:09:45 CUL_HM_HM_CC_TC actuator: 0 %
2012-02-04_17:10:22 CUL_HM_HM_CC_TC desired-temp: 15.5
2012-02-04_17:11:58 CUL_HM_HM_CC_TC T: 17 H: 33
2012-02-04_17:11:58 CUL_HM_HM_CC_TC measured-temp: 17
2012-02-04_17:11:58 CUL_HM_HM_CC_TC temperature: 17
2012-02-04_17:11:58 CUL_HM_HM_CC_TC humidity: 33
2012-02-04_17:12:18 CUL_HM_HM_CC_TC actuator: 0 %
2012-02-04_17:14:17 CUL_HM_HM_CC_TC T: 17 H: 33
2012-02-04_17:14:17 CUL_HM_HM_CC_TC measured-temp: 17
2012-02-04_17:14:17 CUL_HM_HM_CC_TC temperature: 17
2012-02-04_17:14:17 CUL_HM_HM_CC_TC humidity: 33
2012-02-04_17:14:37 CUL_HM_HM_CC_TC actuator: 0 %
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 05.02.2012 um 10:07 schrieb Lipo:
> > Du selber kannst es, die File-Log Definition sollte keinen Filter enthalten, siehe aktualisierten wiki-Eintrag: http://fhemwiki.de/wiki/HM-CC-TC
>
> Ich habe auch ein FileLog ohne Filter:
> define HZ_TReg_1_FLog_text FileLog ./log/HZ_TReg_1-text_%Y-%m-%d.log HZ_TReg_1
> attr HZ_TReg_1_FLog_text logtype text
>
> Bei mir tauchen allerdings keine Eintraege "desired-temp" auf.
Im übrigen wird desired-temp nur bei einer Änderung übertragen, sonst _nie_.
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich setzte "desired-temp" nicht selbst, sondern arbeite mit:
set HZ_TReg_1 tempListMon .... usw., auch fuer die anderen Tage
D.h. dann wohl, dass der HM-CC-TC "seine" desired-temp nicht rausschickt?
Kann man das ändern? Ich wollte eigentlich nicht 20* at Kommandos
verwalten, oder wie machst Du das?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hej,
Am 05.02.2012 um 10:34 schrieb Lipo:
> Ich setzte "desired-temp" nicht selbst, sondern arbeite mit:
> set HZ_TReg_1 tempListMon .... usw., auch fuer die anderen Tage
Ich auch.
> D.h. dann wohl, dass der HM-CC-TC "seine" desired-temp nicht rausschickt?
Doch, das tut es. Wenn Du in Deiner Tagesliste um 15:00 Uhr eine Temperaturänderung einprogrammiert hast, schickt der auch um 15:00 Uhr seine "neue" desired-temp raus. Jedenfalls bei mir...
> Kann man das ändern? Ich wollte eigentlich nicht 20* at Kommandos verwalten, oder wie machst Du das?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Die thermostat schickt in minimal drei fallen etwas zuruck
1. Als resultat von einem am thermostat selber gemachte einstellung
2. Als resultat von das ausfuehren von einem program auf der thermostat
3. Als bestaetugung von eine aenderung gemacht von FHEM z.b weboberflaeche.
Dir dritte wird nicht gelogged, aber wen mann die Zeile:
if($cmd eq "8002" && $p =~ m/^0102(..)(....)/) {
push @event, "desired-temp:" .hex($1)/2;
}
zufuegt im CUL_HM wird es richtig im weboberflache angezeigt. Wie es
in die logs rein gehen soll weiss ich nicht.
Im moment wirden in die log zwei verschiedene sachen mit den gleichen
benennung (desired-temp) gelogd:
1. Die unter 1 und 2 genannten berichte, und
2. Das command das von FHEM einen neuen soll-temperatur is abgeschickt
zum thermostat, diese sollte eigentlich unbenant werden zu
"desired-setpoint" (Die andere sind alle bestaetugungen oder berichte
vom thermostat das eine desired-temperatur aendering auf der
thermostat gemacht IST).
--Johan
On Sun, Feb 5, 2012 at 2:54 PM, Jan-Hinrich Fessel
wrote:
> Hej,
> Am 05.02.2012 um 10:34 schrieb Lipo:
>
>> Ich setzte "desired-temp" nicht selbst, sondern arbeite mit:
>> set HZ_TReg_1 tempListMon .... usw., auch fuer die anderen Tage
>
> Ich auch.
>
>> D.h. dann wohl, dass der HM-CC-TC "seine" desired-temp nicht rausschickt?
>
> Doch, das tut es. Wenn Du in Deiner Tagesliste um 15:00 Uhr eine Temperaturänderung einprogrammiert hast, schickt der auch um 15:00 Uhr seine "neue" desired-temp raus. Jedenfalls bei mir...
>
>> Kann man das ändern? Ich wollte eigentlich nicht 20* at Kommandos verwalten, oder wie machst Du das?
>
> --
> 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
Originally posted by: <email address deleted>
I'm not getting too much response (Jan Hinrich Fessel/Oskar excluded)
on my messages about the HM protocol status bits (information
requested by Rudolph) or on this message. Either the information is
not considered useful, or my German is not understandable. In either
case I would not mind getting some feedback.
I surely hope no one is expecting me to rewrite the module, I am still
struggling with Perl itself, and trying to understand the structure
and relationships between the modules.
--Johan
On Mon, Feb 6, 2012 at 6:26 PM, Johan van der Kolk
wrote:
> Die thermostat schickt in minimal drei fallen etwas zuruck
>
> 1. Als resultat von einem am thermostat selber gemachte einstellung
> 2. Als resultat von das ausfuehren von einem program auf der thermostat
> 3. Als bestaetugung von eine aenderung gemacht von FHEM z.b weboberflaeche.
>
> Dir dritte wird nicht gelogged, aber wen mann die Zeile:
>
> if($cmd eq "8002" && $p =~ m/^0102(..)(....)/) {
> push @event, "desired-temp:" .hex($1)/2;
> }
>
> zufuegt im CUL_HM wird es richtig im weboberflache angezeigt. Wie es
> in die logs rein gehen soll weiss ich nicht.
>
> Im moment wirden in die log zwei verschiedene sachen mit den gleichen
> benennung (desired-temp) gelogd:
> 1. Die unter 1 und 2 genannten berichte, und
> 2. Das command das von FHEM einen neuen soll-temperatur is abgeschickt
> zum thermostat, diese sollte eigentlich unbenant werden zu
> "desired-setpoint" (Die andere sind alle bestaetugungen oder berichte
> vom thermostat das eine desired-temperatur aendering auf der
> thermostat gemacht IST).
>
>
>
> --Johan
>
>
>
> On Sun, Feb 5, 2012 at 2:54 PM, Jan-Hinrich Fessel
> wrote:
>> Hej,
>> Am 05.02.2012 um 10:34 schrieb Lipo:
>>
>>> Ich setzte "desired-temp" nicht selbst, sondern arbeite mit:
>>> set HZ_TReg_1 tempListMon .... usw., auch fuer die anderen Tage
>>
>> Ich auch.
>>
>>> D.h. dann wohl, dass der HM-CC-TC "seine" desired-temp nicht rausschickt?
>>
>> Doch, das tut es. Wenn Du in Deiner Tagesliste um 15:00 Uhr eine Temperaturänderung einprogrammiert hast, schickt der auch um 15:00 Uhr seine "neue" desired-temp raus. Jedenfalls bei mir...
>>
>>> Kann man das ändern? Ich wollte eigentlich nicht 20* at Kommandos verwalten, oder wie machst Du das?
>>
>> --
>> 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
On Tue, Feb 07, 2012 at 07:24:03PM +0100, Johan van der Kolk wrote:
> I'm not getting too much response (Jan Hinrich Fessel/Oskar excluded)
Sorry, it has nothing to do with your german, but I tend to push back more
complex questions / tasks. And earning money tends to be more time consuming
for me lately, so I do not have so much spare time for fhem.
I just checked in the patches from Oskar, which includes the desired-temp-ack
for HM-CC-TC, although for me it looks too generic to be only the ack for the
desired-temp.
I still would stick to the name desired-temp: for one it temp is less technical
and easier to understand then setpoint, on the other hand at least the FHEMWEB
frontend knows about "desired-temp" and offers a dropdown.
And I am a little bit lazy on including the bit decoding, as right now I don't
know the meaning behind the names so it won't really help. On the other side it
doubles (well sort of) the length of the hmProtocolEvents message, making it
even more unreadable.
Regards,
Rudi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hello Rudolph and Oskar
the actual message that is "captured" with this line of code is the following:
0E 0B 80 02 1375C2 0EFFDA 0102 1C 0044 (I'm ignoring what I believe is
the RSSI value here)
In this message the thermostat basically confirms that it has changed
the desired temperature. This answer only comes if the desired
temperature is changed from FHEM.
If the desired temperature is changed on the thermostat, using the
wheel or while it runs in Auto mode then a different message is sent,
which was already captured correctly by the code.
So both of these actually reflect the status of the thermostat.
At the time a command is sent from FHEM, a log entry appears also
stating "desired temperature" which is also kind of true, however it
does not represent the same parameter as in the two messages above.
this parameter and probably also the specific variable in the web
interface remains at the last "FHEM sent" desired temperature, also
when a manual or programmatic change (in auto mode) has occured on the
thermostat. Hence my suggestion to change the name. desired setpoint,
as in "this is what we want the thermostat to take as setpoint".
Using these two as distinct variables would allow to detect if there
is a difference between what FHEM "thinks" the desired temp is, and
what the actual status is. (in case someone played with the
thermostat)
But it may have larger implications, as I see that the same "notation"
is used throughout the whole program. Not my area of expertise (but
neither are thermostats :) )
Now for the naming of the bits
RPTEN and RPTED... I still do not know, and they are in my
configuration static, The radio datasheets don't mention them as such.
BIDI : BiDirectional, an answer is expected. From what I saw in the
BidCos logs, the messagenumber of the response should be the same as
the messagenumber of the received message. (can this be confirmed?)
BROADCAST : no explanation required, msg sent without destination address.
WAKEUP: as the thermostats are normally sleeping setting this bit
should wake up the thermostat, The fact that they are sleeping is
recognized by not getting a confirnation from a command (see for
example 8002 message above) May not be successfull 1st time and needs
to be repeated until the thermostat sends a message back with WAKEMEUP
at 0. Following that the real command can be kicked out again. Since
the wakeups are sent repetetive, the counter on the sender side goes
up. Responses cannot be expected until the thermostat is awake. I
believe that the thermostat finally responds with a message with the
last sent message number and the bit WAKEMEUP at "0". Unfortunatelly
this is not logged very well in the Homematic software, but I would
not be surprised if this bit is set in combination with BIDI.
WAKEMEUP: normal status "1" for the thermostat. Just means I'm
currently asleep, wake me up if you want to talk to me. Is set to 0
when sending a response to a WAKEUP message
BURST: is mentioned in the datasheet from the radio chip, but I'm not
clear on its meaning. According to the radio datasheet this is also
some kind of "wakeup", but based on an other activity pattern.
You are right about the length of the HMprotocolEvents message.
Terminal width of 150 works well :) perhaps move these bits to another
log level, or only mention the active ones.
regards,
--Johan
On Wed, Feb 8, 2012 at 9:12 AM, Rudolf Koenig wrote:
> On Tue, Feb 07, 2012 at 07:24:03PM +0100, Johan van der Kolk wrote:
>> I'm not getting too much response (Jan Hinrich Fessel/Oskar excluded)
>
> Sorry, it has nothing to do with your german, but I tend to push back more
> complex questions / tasks. And earning money tends to be more time consuming
> for me lately, so I do not have so much spare time for fhem.
>
> I just checked in the patches from Oskar, which includes the desired-temp-ack
> for HM-CC-TC, although for me it looks too generic to be only the ack for the
> desired-temp.
>
> I still would stick to the name desired-temp: for one it temp is less technical
> and easier to understand then setpoint, on the other hand at least the FHEMWEB
> frontend knows about "desired-temp" and offers a dropdown.
>
> And I am a little bit lazy on including the bit decoding, as right now I don't
> know the meaning behind the names so it won't really help. On the other side it
> doubles (well sort of) the length of the hmProtocolEvents message, making it
> even more unreadable.
>
> Regards,
> 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
> 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
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
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
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