Originally posted by: <email address deleted>
Hallo zusammen,
jetzt verstehe ich gar nichts mehr. Nachdem ich einige erfolglose
Versuche zum obigen Gerät unternommen hatte (s. alter Beitrag:
http://groups.google.com/group/fhem-users/browse_thread/thread/accaa584b4efbeb4?hl=de#),
kann ich jetzt folgendes kurioses Verhalten reproduzieren:
Das Gerät meldet derzeit noch stoisch ein NACK. Auch die
Schaltversuche (an/aus) via Fhem funktionieren nicht:
2012-03-04 16:33:12 HMLAN HMOG SND L:0E N:D4 CMD:A011
(TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201C80000 (SET CHANNEL:01
VALUE:C8 RAMPTIME:00 ONTIME:00)
2012-03-04 16:33:12 CUL_HM CUL_HM_switch_178E6F on
2012-03-04 16:33:13 CUL_HM CUL_HM_switch_178E6F MISSING ACK
2012-03-04 16:33:13 FHT fht.keller.wasch actuator: 49%
2012-03-04 16:33:13 HMLAN HMOG SND L:0E N:D5 CMD:A011
(TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201000000 (SET CHANNEL:01
VALUE:00 RAMPTIME:00 ONTIME:00)
2012-03-04 16:33:13 CUL_HM CUL_HM_switch_178E6F off
2012-03-04 16:33:14 CUL_HM CUL_HM_switch_178E6F MISSING ACK
Wenn ich jedoch das Gerät über den Taster auf der Platine kurz
hintereinander an- und ausschalte, funktioniert danach das An- und
Ausschalten via Fhem und HMLAN-Adapter. Das Schalten funktioniert aber
nur solange per Fhem, bis man zu große Pausen zwischen den Fhem-
Schaltbefehlen macht. Hier das Protokoll aus dem telnet dazu:
012-03-04 16:32:05 HMLAN HMOG SND L:0E N:CC CMD:A011
(TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201C80000 (SET CHANNEL:01
VALUE:C8 RAMPTIME:00 ONTIME:00)
2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F on
2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F deviceMsg: on (to
254BB2)
2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F on
2012-03-04 16:32:07 HMLAN HMOG SND L:0E N:CD CMD:A011
(TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201000000 (SET CHANNEL:01
VALUE:00 RAMPTIME:00 ONTIME:00)
2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F off
2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F deviceMsg: off (to
254BB2)
2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F off
Was ist die Logik dahinter? Wie kann ich weiter testen?
Für jede Hilfe dankbar, Jan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Laut diesem Thread hier:
http://www.fhz-forum.de/viewtopic.php?f=27&t=7284&sid=f56d5ff33037770f9babc87b40eca254
geht es einfach nicht und das Problem hat mit FHEM nix zu tun, so zeigt
z.B. auch die CCU die 65 Kanäle an.
Es ist wohl die Firmware von diesem Teil noch "etwas unausgereift"
Am Sonntag, 4. März 2012 18:51:00 UTC+1 schrieb Jan:
>
> Hallo zusammen,
>
> jetzt verstehe ich gar nichts mehr. Nachdem ich einige erfolglose
> Versuche zum obigen Gerät unternommen hatte (s. alter Beitrag:
>
> http://groups.google.com/group/fhem-users/browse_thread/thread/accaa584b4efbeb4?hl=de#),
>
> kann ich jetzt folgendes kurioses Verhalten reproduzieren:
>
> Das Gerät meldet derzeit noch stoisch ein NACK. Auch die
> Schaltversuche (an/aus) via Fhem funktionieren nicht:
>
> 2012-03-04 16:33:12 HMLAN HMOG SND L:0E N:D4 CMD:A011
> (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201C80000 (SET CHANNEL:01
> VALUE:C8 RAMPTIME:00 ONTIME:00)
> 2012-03-04 16:33:12 CUL_HM CUL_HM_switch_178E6F on
> 2012-03-04 16:33:13 CUL_HM CUL_HM_switch_178E6F MISSING ACK
> 2012-03-04 16:33:13 FHT fht.keller.wasch actuator: 49%
> 2012-03-04 16:33:13 HMLAN HMOG SND L:0E N:D5 CMD:A011
> (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201000000 (SET CHANNEL:01
> VALUE:00 RAMPTIME:00 ONTIME:00)
> 2012-03-04 16:33:13 CUL_HM CUL_HM_switch_178E6F off
> 2012-03-04 16:33:14 CUL_HM CUL_HM_switch_178E6F MISSING ACK
>
> Wenn ich jedoch das Gerät über den Taster auf der Platine kurz
> hintereinander an- und ausschalte, funktioniert danach das An- und
> Ausschalten via Fhem und HMLAN-Adapter. Das Schalten funktioniert aber
> nur solange per Fhem, bis man zu große Pausen zwischen den Fhem-
> Schaltbefehlen macht. Hier das Protokoll aus dem telnet dazu:
>
> 012-03-04 16:32:05 HMLAN HMOG SND L:0E N:CC CMD:A011
> (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201C80000 (SET CHANNEL:01
> VALUE:C8 RAMPTIME:00 ONTIME:00)
> 2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F on
> 2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F deviceMsg: on (to
> 254BB2)
> 2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F on
> 2012-03-04 16:32:07 HMLAN HMOG SND L:0E N:CD CMD:A011
> (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201000000 (SET CHANNEL:01
> VALUE:00 RAMPTIME:00 ONTIME:00)
> 2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F off
> 2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F deviceMsg: off (to
> 254BB2)
> 2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F off
>
> Was ist die Logik dahinter? Wie kann ich weiter testen?
>
> Für jede Hilfe dankbar, Jan
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo zusammen,
bis auf zig, unnötige Shadowdevices beim Pairen, funzt alles
einwandfrei (das Gerät hat nur einen Kanal).
Alles ist heute Nacht noch im Trunk eingecheck worden. Der Burstmodus
muss in den HeaderBytes gesetzt sein.
Ich denke hier muss in FHEM dem Protokoll bzw. dem Feld CMD eine
erweiterte Bedeutung beigemessen werden. Bei CMD handelt es sich
meiner Ansicht nach um zwei separate Felder mit getrennter Bedeutung:
HeaderByte und Nachrichtenart/Frame
Falsch ist dem zu Folge:
SND (...) CMD:A011
Richtig ist:
SND (...) CMD:FF11
Alles Andere sollte, wie du bereits im alten Beitrag schreibst,
adäquat zum HM-LC-Sw4-PCB sein.
Beschrieben steht das in der entsprechenden Firmware-XML und in der
Dokumentation des CC1100 von Texas Instruments.
Gruß, MartiMcFly
On Mar 4, 9:26 pm, unimatrix
wrote:
> Laut diesem Thread hier:http://www.fhz-forum.de/viewtopic.php?f=27&t=7284&sid=f56d5ff33037770...
>
> geht es einfach nicht und das Problem hat mit FHEM nix zu tun, so zeigt
> z.B. auch die CCU die 65 Kanäle an.
>
> Es ist wohl die Firmware von diesem Teil noch "etwas unausgereift"
>
> Am Sonntag, 4. März 2012 18:51:00 UTC+1 schrieb Jan:
>
>
>
>
>
>
>
>
>
> > Hallo zusammen,
>
> > jetzt verstehe ich gar nichts mehr. Nachdem ich einige erfolglose
> > Versuche zum obigen Gerät unternommen hatte (s. alter Beitrag:
>
> >http://groups.google.com/group/fhem-users/browse_thread/thread/accaa5...),
>
> > kann ich jetzt folgendes kurioses Verhalten reproduzieren:
>
> > Das Gerät meldet derzeit noch stoisch ein NACK. Auch die
> > Schaltversuche (an/aus) via Fhem funktionieren nicht:
>
> > 2012-03-04 16:33:12 HMLAN HMOG SND L:0E N:D4 CMD:A011
> > (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201C80000 (SET CHANNEL:01
> > VALUE:C8 RAMPTIME:00 ONTIME:00)
> > 2012-03-04 16:33:12 CUL_HM CUL_HM_switch_178E6F on
> > 2012-03-04 16:33:13 CUL_HM CUL_HM_switch_178E6F MISSING ACK
> > 2012-03-04 16:33:13 FHT fht.keller.wasch actuator: 49%
> > 2012-03-04 16:33:13 HMLAN HMOG SND L:0E N:D5 CMD:A011
> > (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201000000 (SET CHANNEL:01
> > VALUE:00 RAMPTIME:00 ONTIME:00)
> > 2012-03-04 16:33:13 CUL_HM CUL_HM_switch_178E6F off
> > 2012-03-04 16:33:14 CUL_HM CUL_HM_switch_178E6F MISSING ACK
>
> > Wenn ich jedoch das Gerät über den Taster auf der Platine kurz
> > hintereinander an- und ausschalte, funktioniert danach das An- und
> > Ausschalten via Fhem und HMLAN-Adapter. Das Schalten funktioniert aber
> > nur solange per Fhem, bis man zu große Pausen zwischen den Fhem-
> > Schaltbefehlen macht. Hier das Protokoll aus dem telnet dazu:
>
> > 012-03-04 16:32:05 HMLAN HMOG SND L:0E N:CC CMD:A011
> > (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201C80000 (SET CHANNEL:01
> > VALUE:C8 RAMPTIME:00 ONTIME:00)
> > 2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F on
> > 2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F deviceMsg: on (to
> > 254BB2)
> > 2012-03-04 16:32:06 CUL_HM CUL_HM_switch_178E6F on
> > 2012-03-04 16:32:07 HMLAN HMOG SND L:0E N:CD CMD:A011
> > (TYPE=17,BIDI,RPTEN) SRC:254BB2 DST:178E6F 0201000000 (SET CHANNEL:01
> > VALUE:00 RAMPTIME:00 ONTIME:00)
> > 2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F off
> > 2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F deviceMsg: off (to
> > 254BB2)
> > 2012-03-04 16:32:07 CUL_HM CUL_HM_switch_178E6F off
>
> > Was ist die Logik dahinter? Wie kann ich weiter testen?
>
> > Für jede Hilfe dankbar, Jan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> bis auf zig, unnötige Shadowdevices beim Pairen, funzt alles
> einwandfrei (das Gerät hat nur einen Kanal).
Also ist meine Theorie, dass bei einem DEVICE_INFO Paket eines switch oder
threeState Geraetes die PEER_CHANNEL_A/PEER_CHANNEL_B Werte die Von-/Bis-
Kanalnummer beinhalten falsch, bzw. nicht ueberall richtig. Bessere Theorie?
> Bei CMD handelt es sich meiner Ansicht nach um zwei separate Felder mit
> getrennter Bedeutung: HeaderByte und Nachrichtenart/Frame
Klingt auch fuer mich zunehmend plausibel, bin nur nicht ganz sicher, ob
"HeaderByte" und Nachrichtenart separat behandelt werden kann.
> Beschrieben steht das in der entsprechenden Firmware-XML und in der
> Dokumentation des CC1100 von Texas Instruments.
Wo genau? Bitte.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Mann kann die header und nachricht separat bewerten. Aber die combination
von beide bestimmt was zuruck geschickt werden muss.
ZB bit 5 im header is true: brauch ein Ack
send back 8002, generic Ack fuer die meiste berichte
send back 803F für timesync request und ein total andere Berichtinhalt.
--Johan
On Tue, Apr 17, 2012 at 2:31 PM, Rudolf Koenig wrote:
> > bis auf zig, unnötige Shadowdevices beim Pairen, funzt alles
> > einwandfrei (das Gerät hat nur einen Kanal).
>
> Also ist meine Theorie, dass bei einem DEVICE_INFO Paket eines switch oder
> threeState Geraetes die PEER_CHANNEL_A/PEER_CHANNEL_B Werte die Von-/Bis-
> Kanalnummer beinhalten falsch, bzw. nicht ueberall richtig. Bessere
> Theorie?
>
>
> > Bei CMD handelt es sich meiner Ansicht nach um zwei separate Felder mit
> > getrennter Bedeutung: HeaderByte und Nachrichtenart/Frame
>
> Klingt auch fuer mich zunehmend plausibel, bin nur nicht ganz sicher, ob
> "HeaderByte" und Nachrichtenart separat behandelt werden kann.
>
>
> > Beschrieben steht das in der entsprechenden Firmware-XML und in der
> > Dokumentation des CC1100 von Texas Instruments.
>
> Wo genau? Bitte.
>
> --
> 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>
Hej Rudi,
verzeiht mir bitte die knappe Antwort. Ich diese Woche etwas kurz
angebunden.
Ein Teil der Nachricht scheint mir durch den Mikrochip von
Texasinstrument fest vorgegeben zu sein. Ähnlich dem OSI-
Schichtenmodel in dem jede Schicht ihren Teil anhängt.
Zum Beispiel ist bereits in der Dokumentation die Rede von Length/
Counter/HeaderByte etc.
http://www.ti.com/lit/ds/symlink/cc1100.pdf
Der BurstModus steht auf Seite 27, in der zweiten Spalte mittig
beschrieben. Daher habe ich das FF.
In der Firmware-XML (rf_s_ba.xml) ist immer der rx_modus im ersten XML-
Tag beschrieben.
Eine kurze Frage würde ich aber gerne noch kurz los werden. Woher
kommen die %culHmDevProps?
Sie scheinen sich für mich nicht zu decken. Der CO2-Sensor ist zum
Beispiel kein THSensor. Und in den XML-Dateien finde ich keinen
Hinweis darauf.
@Johan: Kannst Du bitte die beiden SND CMDs zu den send backs posten?
Danke.
Ich hoffe am Wochenende mehr haurausfinden zu können.
Gruß, MartiMcFly
On 17 Apr., 20:52, Johan van der Kolk
wrote:
> Mann kann die header und nachricht separat bewerten. Aber die combination
> von beide bestimmt was zuruck geschickt werden muss.
> ZB bit 5 im header is true: brauch ein Ack
>
> send back 8002, generic Ack fuer die meiste berichte
> send back 803F für timesync request und ein total andere Berichtinhalt.
>
> --Johan
>
>
>
>
>
>
>
> On Tue, Apr 17, 2012 at 2:31 PM, Rudolf Koenig wrote:
> > > bis auf zig, unnötige Shadowdevices beim Pairen, funzt alles
> > > einwandfrei (das Gerät hat nur einen Kanal).
>
> > Also ist meine Theorie, dass bei einem DEVICE_INFO Paket eines switch oder
> > threeState Geraetes die PEER_CHANNEL_A/PEER_CHANNEL_B Werte die Von-/Bis-
> > Kanalnummer beinhalten falsch, bzw. nicht ueberall richtig. Bessere
> > Theorie?
>
> > > Bei CMD handelt es sich meiner Ansicht nach um zwei separate Felder mit
> > > getrennter Bedeutung: HeaderByte und Nachrichtenart/Frame
>
> > Klingt auch fuer mich zunehmend plausibel, bin nur nicht ganz sicher, ob
> > "HeaderByte" und Nachrichtenart separat behandelt werden kann.
>
> > > Beschrieben steht das in der entsprechenden Firmware-XML und in der
> > > Dokumentation des CC1100 von Texas Instruments.
>
> > Wo genau? Bitte.
>
> > --
> > 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>
Hej Rudi,
verzeiht mir bitte die knappe Antwort. Ich bin diese Woche etwas kurz
angebunden.
Ein Teil der Nachricht scheint mir durch den Mikrochip von
Texasinstrument fest vorgegeben zu sein. Ähnlich dem OSI-
Schichtenmodel in dem jede Schicht ihren Teil anhängt.
Zum Beispiel ist bereits in der Dokumentation die Rede von Length/
Counter/HeaderByte etc.
http://www.ti.com/lit/ds/symlink/cc1100.pdf
Ein Teil des BurstModus steht auf Seite 27, in der zweiten Spalte
mittig
beschrieben. Daher habe ich das FF.
In der Firmware-XML (rf_s_ba.xml) ist immer der rx_modus im ersten
XML-
Tag beschrieben.
Eine kurze Frage würde ich aber gerne noch los werden. Woher
kommen die %culHmDevProps?
Sie scheinen sich für mich nicht zu decken. Der CO2-Sensor ist zum
Beispiel kein THSensor. Und in den XML-Dateien finde ich keinen
Hinweis darauf.
@Johan: Kannst Du bitte die beiden SND CMDs zu den send backs posten?
Danke.
Ich hoffe am Wochenende mehr haurausfinden zu können.
Gruß, MartiMcFly
On 17 Apr., 20:52, Johan van der Kolk
wrote:
> Mann kann die header und nachricht separat bewerten. Aber die combination
> von beide bestimmt was zuruck geschickt werden muss.
> ZB bit 5 im header is true: brauch ein Ack
>
> send back 8002, generic Ack fuer die meiste berichte
> send back 803F für timesync request und ein total andere Berichtinhalt.
>
> --Johan
>
>
>
>
>
>
>
> On Tue, Apr 17, 2012 at 2:31 PM, Rudolf Koenig wrote:
> > > bis auf zig, unnötige Shadowdevices beim Pairen, funzt alles
> > > einwandfrei (das Gerät hat nur einen Kanal).
>
> > Also ist meine Theorie, dass bei einem DEVICE_INFO Paket eines switch oder
> > threeState Geraetes die PEER_CHANNEL_A/PEER_CHANNEL_B Werte die Von-/Bis-
> > Kanalnummer beinhalten falsch, bzw. nicht ueberall richtig. Bessere
> > Theorie?
>
> > > Bei CMD handelt es sich meiner Ansicht nach um zwei separate Felder mit
> > > getrennter Bedeutung: HeaderByte und Nachrichtenart/Frame
>
> > Klingt auch fuer mich zunehmend plausibel, bin nur nicht ganz sicher, ob
> > "HeaderByte" und Nachrichtenart separat behandelt werden kann.
>
> > > Beschrieben steht das in der entsprechenden Firmware-XML und in der
> > > Dokumentation des CC1100 von Texas Instruments.
>
> > Wo genau? Bitte.
>
> > --
> > 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
> Zum Beispiel ist bereits in der Dokumentation die Rede von Length/
> Counter/HeaderByte etc.
Ich gehe von Seite 32 der CC1101.pdf (15.2 Packet Format) bzw. von
culfw/clib/rf_asksin.c aus :) Laut diesen ist nur die Laenge der Nachricht
(Byte 1 des BidCos Paketes) CC1101 "Kompatibel".
> Ein Teil des BurstModus steht auf Seite 27, in der zweiten Spalte mittig
> beschrieben. Daher habe ich das FF.
"The burst bit is used to determine if the FIFO access is a single byte access
or a burst access."
Hier geht es darum, wie z.Bsp culfw aus dem CC1101-Puffer die angekommenen
Pakete rauslesen kann. Hat mit dem HM Protocol "BURST" Bit nichts am Hut.
>
Ich weiss es ja dass diesen Bit gibt, ich weiss nur nicht so recht wozu, und
welche Konsequenzen es hat.
> Der CO2-Sensor ist zum Beispiel kein THSensor. Und in den XML-Dateien finde
> ich keinen Hinweis darauf.
Die Namen sind mehr oder weniger selbst erfunden. Der Schluessel (70) kommt vom
DEVICE_INFO Paket des Geraetes. sensor gibts schon, THsensor muss dann in was
anderes umbenannt werden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Dienstag, 17. April 2012 14:15:34 UTC+2 schrieb MartiMcFly:
>
> Alles ist heute Nacht noch im Trunk eingecheck worden.
Mensch Mensch, im alkoholisierten Zustand SVN beschicken - wenn das mal gut
geht ;-)
=8-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Seite 58:
"32.4 Data Burst Transmissions
The high maximum data rate of CC1100 opens
up for burst transmissions. A low average data
rate link (e.g. 10 kBaud), can be realized using
a higher over-the-air data rate. Buffering the
data and transmitting in bursts at high data
rate (e.g. 500 kBaud) will reduce the time in
active mode, and hence also reduce the
average current consumption significantly.
Reducing the time in active mode will reduce
the likelihood of collisions with other systems
in the same frequency range."
Das HMLAN wird in einem ganz anderen SendeModus operieren müssen um
die Daten zu übermitteln. Dafür werden die Bits sicherlich gesetzt
sein müssen.
Das würde auch erklären warum der HM-LC-SW1-BA-PCB bei mehrfachem
+schnellen Absetzen einer Nachricht manchmal reagiert hat. Das konnte
ich bei mir nachstellen.
Allerdings hat es mir nichts genutzt die Bits entsprechend dem
@culHmCmdBits zu setzen.
Kannst du mir bitte sagen wo ich das DEVICE_INFO Paket finde?
@UliM: Sicher datt das gut geht. Habe das bei mir im Einsatz.
Aber in der Tat gibt es noch ein Problem beim Pairen. Unabhängig von
meiner Änderung stürzt FHEM beim Paaren ab. Nach der letzten Meldung
ist FHEM weg vom Fenster. Lässt sich aber anstandslos neustarten.
Das per autocreate erstellte (erste) Gerät lässt sich benutzen. Kann
ich Perl irgendwie aus der Ferne Step-by-Step debuggen?
fhem> set CUL_HM_switch_ZZZZZZ pair
2012-04-17 23:42:32 HMLAN HMLAN1 SND L:15 N:0B CMD:A001 SRC:XXXXXX DST:
000000 010A49455131323334353637 (PAIR_SERIAL SERIALNO:IEQ1234567)
2012-04-17 23:42:32 CUL_HM CUL_HM_switch_ZZZZZZ pair
2012-04-17 23:42:32 HMLAN HMLAN1 RCV L:1A N:0B CMD:8000 SRC:ZZZZZZ
DST:XXXXXX 12006C4945513132333435363710410100 (DEVICE_INFO FIRMWARE:12
TYPE:006C SERIALNO:IEQ0405172 CLASS:10 PEER_CHANNEL_A:41
PEER_CHANNEL_B:01 UNKNOWN:00)
2012-04-17 23:42:32 HMLAN HMLAN1 SND L:10 N:0C CMD:A001 SRC:XXXXXX
DST:ZZZZZZ 00050000000000 (CONFIG_START CHANNEL:00 PEER_ADDRESS:000000
PEER_CHANNEL:00 PARAM_LIST:00)
2012-04-17 23:42:33 HMLAN HMLAN1 RCV L:11 N:0C CMD:A002 SRC:ZZZZZZ
DST:XXXXXX 048EC9434B3F8000 (Request AES DATA:048EC9434B3F8000)
2012-04-17 23:42:33 HMLAN HMLAN1 SND L:0A N:0D CMD:8002 SRC:XXXXXX
DST:ZZZZZZ 00 (ACK)
2012-04-17 23:42:33 HMLAN HMLAN1 SND L:13 N:0E CMD:A001 SRC:XXXXXX
DST:ZZZZZZ 000802010A650BE90C60 (CONFIG_WRITE_INDEX CHANNEL:00 DATA:
02:01 0A:65 0B:E9 0C:60)
2012-04-17 23:42:33 HMLAN HMLAN1 RCV L:0E N:0C CMD:8002 SRC:ZZZZZZ
DST:XXXXXX 00027F6666 (ACK)
2012-04-17 23:42:33 HMLAN HMLAN1 RCV L:0A N:0D CMD:8002 SRC:XXXXXX
DST:ZZZZZZ 00 (ACK)
2012-04-17 23:42:34 HMLAN HMLAN1 RCV L:11 N:0E CMD:A002 SRC:ZZZZZZ
DST:XXXXXX 04B4EC0DFBBF2800 (Request AES DATA:04B4EC0DFBBF2800)
2012-04-17 23:42:34 HMLAN HMLAN1 SND L:0A N:0F CMD:8002 SRC:XXXXXX
DST:ZZZZZZ 00 (ACK)
2012-04-17 23:42:34 HMLAN HMLAN1 SND L:0B N:10 CMD:A001 SRC:XXXXXX
DST:ZZZZZZ 0006 (CONFIG_END CHANNEL:00)
2012-04-17 23:42:34 HMLAN HMLAN1 RCV L:0E N:0E CMD:8002 SRC:ZZZZZZ
DST:XXXXXX 001DFBC0BE (ACK)
2012-04-17 23:42:34 CUL_HM CUL_HM_switch_ZZZZZZ_CHN_29 deviceMsg:
125.5 %
2012-04-17 23:42:34 CUL_HM CUL_HM_switch_ZZZZZZ_CHN_29 125.5 %
2012-04-17 23:42:34 HMLAN HMLAN1 RCV L:0A N:0F CMD:8002 SRC:XXXXXX
DST:ZZZZZZ 00 (ACK)
2012-04-17 23:42:34 HMLAN HMLAN1 RCV L:11 N:0F CMD:A002 SRC:ZZZZZZ
DST:XXXXXX 044D5639E2ED6700 (Request AES DATA:044D5639E2ED6700)
2012-04-17 23:42:34 HMLAN HMLAN1 RCV L:11 N:10 CMD:A002 SRC:ZZZZZZ
DST:XXXXXX 04B741F0FB89F500 (Request AES DATA:04B741F0FB89F500)
2012-04-17 23:42:35 HMLAN HMLAN1 RCV L:0E N:10 CMD:8002 SRC:ZZZZZZ
DST:XXXXXX 00DBCAE8ED (ACK)
@Rudi: Ist es normal, dass ich ein Pair nicht über die Weboberfläche,
sondern nur über Terminal, ausführen kann?
Gruß, MartiMcFly
On 18 Apr., 12:08, Rudolf Koenig wrote:
> > Zum Beispiel ist bereits in der Dokumentation die Rede von Length/
> > Counter/HeaderByte etc.
>
> Ich gehe von Seite 32 der CC1101.pdf (15.2 Packet Format) bzw. von
> culfw/clib/rf_asksin.c aus :) Laut diesen ist nur die Laenge der Nachricht
> (Byte 1 des BidCos Paketes) CC1101 "Kompatibel".
>
> > Ein Teil des BurstModus steht auf Seite 27, in der zweiten Spalte mittig
> > beschrieben. Daher habe ich das FF.
>
> "The burst bit is used to determine if the FIFO access is a single byte access
> or a burst access."
>
> Hier geht es darum, wie z.Bsp culfw aus dem CC1101-Puffer die angekommenen
> Pakete rauslesen kann. Hat mit dem HM Protocol "BURST" Bit nichts am Hut.
>
> >
>
> Ich weiss es ja dass diesen Bit gibt, ich weiss nur nicht so recht wozu, und
> welche Konsequenzen es hat.
>
> > Der CO2-Sensor ist zum Beispiel kein THSensor. Und in den XML-Dateien finde
> > ich keinen Hinweis darauf.
>
> Die Namen sind mehr oder weniger selbst erfunden. Der Schluessel (70) kommt vom
> DEVICE_INFO Paket des Geraetes. sensor gibts schon, THsensor muss dann in was
> anderes umbenannt werden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> "32.4 Data Burst Transmissions
...
Alles schoen und gut, hat aber mit dem HM burst bit nichts zu tun (behaupte
ich). Das CC1101 muss auf eine Frequenz/Modulation/Datenrate eingestellt sein,
und das ist beim HM fix. Klar werden die Daten erst ins FIFO gepackt, und dann
"in Burst" gesendet, das ist beim Paketmodus der CC1101 normal.
> Das HMLAN wird in einem ganz anderen SendeModus operieren müssen um
> die Daten zu übermitteln. Dafür werden die Bits sicherlich gesetzt
> sein müssen.
Kann mir nicht vorstellen, dass HM beim gesetzten BURST Bit ein CUL_RFR
aehnlichen Modus verwendet (ping auf slowrf, dann umschalten auf highspeed).
Dazu braeuchte ich mehr Beweise, bzw. dafuer funktioniert im CUL (der im HM
sicher nicht umschaltet) zu viel.
> Kann ich Perl irgendwie aus der Ferne Step-by-Step debuggen?
Ich mag keine Debugger / verwende print bzw. Log. Single-Stepping ist bei
zeitkritischen Problemen wie hier mAn eh unbrauchbar.
> 2012-04-17 23:42:32 HMLAN HMLAN1 RCV L:1A N:0B CMD:8000 SRC:ZZZZZZ
> DST:XXXXXX 12006C4945513132333435363710410100 (DEVICE_INFO FIRMWARE:12
> TYPE:006C SERIALNO:IEQ0405172 CLASS:10 PEER_CHANNEL_A:41
> PEER_CHANNEL_B:01 UNKNOWN:00)
Das ist ein Device_info Paket, mit Class 10 (culHmDevProps -> switch)
> @Rudi: Ist es normal, dass ich ein Pair nicht über die Weboberfläche,
> sondern nur über Terminal, ausführen kann?
Eigentlich nicht, aber ich teste hauptsaechlich ueber telnet.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Geht z.B. hiermit
http://www.epic-ide.org/guide/ch06.php oder mit Komodo (ActiveState, keine
Freeware)
>
> Das per autocreate erstellte (erste) Gerät lässt sich benutzen. Kann
> ich Perl irgendwie aus der Ferne Step-by-Step debuggen?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudi,
endlich habe ich mal wieder etwas Zeit.
Nach einem kurzen Test scheint es nicht notwendig zu sein 0xFF in den
Headerbytes zu übergeben. Ganz im Gegenteil, Du scheinst sogar Recht zu
haben. Mit den Headerbytes 0x30 reagiert der Schalter bereits. (BIDI, plus
noch eine Option die ich gerade nicht zur Hand habe)
Gruß, Martina
Am Mittwoch, 18. April 2012 16:39:50 UTC+2 schrieb Rudolf Koenig:
>
> > "32.4 Data Burst Transmissions
> ...
> Alles schoen und gut, hat aber mit dem HM burst bit nichts zu tun (behaupte
> ich). Das CC1101 muss auf eine Frequenz/Modulation/Datenrate eingestellt
> sein,
> und das ist beim HM fix. Klar werden die Daten erst ins FIFO gepackt, und
> dann
> "in Burst" gesendet, das ist beim Paketmodus der CC1101 normal.
>
>
> > Das HMLAN wird in einem ganz anderen SendeModus operieren m�ssen um
> > die Daten zu �bermitteln. Daf�r werden die Bits sicherlich gesetzt
> > sein m�ssen.
>
> Kann mir nicht vorstellen, dass HM beim gesetzten BURST Bit ein CUL_RFR
> aehnlichen Modus verwendet (ping auf slowrf, dann umschalten auf
> highspeed).
> Dazu braeuchte ich mehr Beweise, bzw. dafuer funktioniert im CUL (der im HM
> sicher nicht umschaltet) zu viel.
>
>
> > Kann ich Perl irgendwie aus der Ferne Step-by-Step debuggen?
>
> Ich mag keine Debugger / verwende print bzw. Log. Single-Stepping ist bei
> zeitkritischen Problemen wie hier mAn eh unbrauchbar.
>
>
> > 2012-04-17 23:42:32 HMLAN HMLAN1 RCV L:1A N:0B CMD:8000 SRC:ZZZZZZ
> > DST:XXXXXX 12006C4945513132333435363710410100 (DEVICE_INFO FIRMWARE:12
> > TYPE:006C SERIALNO:IEQ0405172 CLASS:10 PEER_CHANNEL_A:41
> > PEER_CHANNEL_B:01 UNKNOWN:00)
>
> Das ist ein Device_info Paket, mit Class 10 (culHmDevProps -> switch)
>
>
> > @Rudi: Ist es normal, dass ich ein Pair nicht �ber die Weboberfl�che,
> > sondern nur �ber Terminal, ausf�hren kann?
>
> Eigentlich nicht, aber ich teste hauptsaechlich ueber telnet.
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com