FHEM Forum

guten abend,

wie genau ist denn das vorgehen wenn ich zusätzlich zum cul ein hmlan einsetzten möchte um die reichweite zu erhöhen?

müssen beide eine unterschiedliche hmid bekommen? wenn ja bedeutet das das ich die aktoren die näher am hmlan sind dann neu pairen muß?

gruss
  andre

hi
wenns nur um die reichweite geht könntest du ev einen zwischenstecker mit internem repeater nutzen. Denke die sind dafür gedacht alles einfach weiterzuleiten. Nicht getestet, nur mein verständnis der produktbeschreibung.
Lg martin

Hallo Andre,

Eine klare vorgaben habe ich nicht. Bedacht werden muss senden und empfangen.

Empfangen: FHEM filtert im Prinzip keinen Nachrichten. CUL und HMLAN werden empfangen - jedenfalls im Übergangsbereich. FHEM sollte aber duplicate Nachrichten verwerfen. Das musste soewit eigentich funktionieren - unabhaengig von der FHEM ID der CUL/HMLAN

Senden: Du solltest bei den Devices einstellen, welches IO device benutzt wird. Damit du die ein statisches und reproduzierbares Ergebnist bekommst. Siehe Attribut IODev

Remotes: tragbare Fernbedienungen sind eine Herausforderung - da kannst du nicht einfach etwas einstellen...

Automatisches Antworten eines HMLAN: HMLAN schickt gerne ACKs selbstaendig. Bei CUL ist dies alles "manuell". Das koennte ein Problem geben, wenn du die gleiche HMID fuer CUL und HMLAN benutzt.

=> Prinzipiell kannst du es mit einer HMID fuer CUL und HMLAN probieren. Grosse Probleme erwarte ich nicht.
Aber der Weg 2 IDs zu vergeben sollte auch funktionieren. Und bei sauberen Aufsetzen des pairings und des IODev je device muesste es problemlos laufen.
IODev und pairing pbrauchst du natürlich nur für 'devices' - channel senden immer über das Device, brauchen also keine Einstellungen

danke.

ich werde probieren und berichten.

gruss
  andre

noch zwei fragen...

ist das prinzipielle vorgehen mit gleicher hmid bei einer erweiterung per cuno statt hmlan identisch?

wäre eine erweiterung auch per cul/coc und rasberry pi und möglich? dann per fhem2fhem oder gibt es einen direkteren weg den entfernten cul anzusprechen ohne zweite fhem installation?

gruss
  andre

Andre,

Ich habe es nicht probiert - aber ich habe etwas code - speziell in der CUL gesehen, der 'multi-CUL-Betrieb' unterstützt. Nicht Speziell fuer HM, sondern generell.

Prinzipiell ist es bei einer CUL einfacher als bei HMLAN. Eine CUL sendet nur, was CUL_HM beauftragt. HMLAN sendet ACKs und wiederholt selbstaendig (ist ein feature... das man bei Multibetrieb kontrollieren muss)

Also alle 'IOs' melden ihren Empfang nach CUL_HM und dort wird geparst.
Mein senden ist es (etwas) einfacher - nur der Beauftragte IO sendet.

Ich denke 2 FHEM Installationen brauchst du nur, wenn du deine IOs nicht von einem host aus betreiben kannst/willst

Also kurz: es sollte alles mit einer FHEM-installation gehen - selbst mit getrennter HMID je device

Gruss
Martin

hallo martin,

mit dem 'etwas code' meinst du vermutlich die sendpool konfiguration.

das mit dem gleichen host scheidet leider aus da es zwei stockwerke weiter unten ist.

wenn ich es richtig sehe gibt es prinzipiell mehrere möglichkeiten der ios:

1. lokales i/o
  1a per usb (cul)
  1b per netzwerk (cuno/hmlan)

2. remote i/o
  2a zweite fhem instanz mit fhem2fehm

d.h. out of the box geht lokales i/o über größere entfernung nur mit hmlan oder cuno.

als weitere möglichkeit fällt mir noch ein einen entfernen cul per netcat, network character device oder usb redirector als lokales i/o zu nutzen. sozusagen 1c. scheinbar hat das aber noch niemand probiert.

ich glaube das mir 1c am besten gefallen würde. vielleicht ist es aber auch nur irrational nicht einfach einen hmlan zu kaufen. zumindest wäre das die günstigste lösung sogar mit ziemlichem vorsprung sobald nicht nur einer sondern zwei nötig sind.

gruss
  andre

Hallo,

jetzt muss ich trotzdem nochmal nachfragen, wieso ihr meinen Vorschlag komplett ignoriert habt, was spricht denn gegen den repeater? Der ist eindeutig die günstigste Lösun und tut doch auf den Punkt genau was hier benötigt wird?
http://www.elv.at/homematic-selektiver-funk-zwischenstecker-repeater-hm-sys-srp-pl-fertiggeraet.html (//www.elv.at/homematic-selektiver-funk-zwischenstecker-repeater-hm-sys-srp-pl-fertiggeraet.html)

Was spricht gegen diese Lösung? Die ist Netzwerk unabhängig und benötigt außer Strom auch sonst keine zusätzlichen Geräte.
lG
Martin

Sorry Martin.

aus meiner Sicht nichts.
Ich muss gestehen, den habe ich noch nicht angesehen. Ich bin davon ausgegangen, dass das Geraet schon vorhanden ist (kann falsch sein...)

Reden wir über den Repeater:
Wird aktuell nicht von FHEM unterstützt ( als funktioniert schon - aber man kann ihn  nicht konfigurieren...)
Der Repeater wiederholt selektiv messages.
 a) je nach Ablauf kann (oder auch nicht) die Zentrale messages doppelt erhalten. Das kann sie ab, kein Problem.
 b) die Selektivitaet muss offensichtlich eingestellt werden. Man kann bis zu 36 devices in den Repeater eintragen. Die Register sind bisher nicht dekodiert, man kann natürlich raw programmieren - das geht immer.


Besteht interesse, die den Repeater zu Programmieren? Also die Register?

Gruss
Martin

Hi Martin,

bei mir momentan nicht ;-)
Aber wenn ich an meine Grenzen der Reichweite stoßen würde, fände ich das eine elegante Lösung!

cheers
Martin

Hallo Martin(s),

interessante Möglichkeit. Die Frage ist ob sie entscheidende Nachteile gegenüber einem 2. HMLAN besitzt?

Höherer Funkverkehr etc. pp. ? (Bin kein Fachmann)

Interessiert mich, da ich vermutlich mit meinem KFM100 und der Verbindung zum einzigen HMLAN
dann an die Grenze komme wenn ich ihn in der Zisterne einbaue.

Gruss Billy

die idee mit dem repeater habe ich nicht absichtlich ignoriert. das war eher verdrängt. sorry.

eventuell waere der repeater in bestimten konfigurationen auch eine möglichkeit. ich glaube aber das es durchaus probleme geben kann weil die nachrichten ja wiederholt werden. d.h. sie sind mindestens doppelt so lange in der luft plus verzögerung.

die fenstergriffe senden z.b. beim drehen in den kipp zustand auch eine nachricht wenn sie zwischendurch bei offen vorbei kommen. und das macht mir jetzt schon probleme wenn ich direkt bei offen den rolladen los fahren lasse. dann ist das rolladen runter kommando gerade in der luft wenn der fenstergriff den zweiten status sendet. und es gibt öfter ein missing ack. ich kann mir nicht vorstellen das es mit repeater nicht noch problematischer wird.

die griffe haben zwar noch einen parameter send delay. ich bin mir aber noch nicht sicher was der genau macht. wenn sich damit das erste event unterdrücken lässt wenn schnell genug das zweite hinterher kommt waere das sicher hilfreich. muss ich mal probieren. oder fhem nach der ersten nachricht etwas warten lassen ob noch eine zweite kommt.

wobei das sofort reagieren des rolladens ohne jede verzögerung natürlich eigentlich sehr schön ist.

gruss
  andre

hallo martin,

ich habe gerade einen hmlan zusätzlich zum cul in betrieb genommen. um nicht alles neu zu pairen erst mal mit der gleichen hmid.

abgesehen von diversen problemen bis das ding endlich im fhem war sind mir direkt ein paar dinge aufgefallen:

- der empfang scheint deutlich schlechter zu sein als mit meinem cul und der 15cm antenne. rssi von einem meiner fenstergriffe zum hmlan ist -92 und zum cul -96. der hmlan steht aber im prinzip im gleichen zimmer 2 meter weit weg, der cul zwei stockwerke mit fb heizung und 3 zimmerwände schräg angeschnitten weit weg. gibt es noch einen trick den hmlan auszurichten oder ist der wirklich so schlecht?

- ich sehe zwar jeweils die rssi werte aber beim eigentlichen reading steht immer das die nachricht zum cul ging. wird der empfänger anhand der hmid bestimmt oder ist es das wirkliche iodev dessen nachricht benutzt wurde?

- das LASTIODev steht auch immer auf cul. da es aus dem dispatch gefüllt wird scheint es als ob die nachrichten wirklich nur die cul nachricht ausgewertet wird.

- wo sehe ich über welches iodev die acks wirklich raus gegangen sind?

so viel zu den nach meinem geschmack erst mal recht enttäuschenden ersten ergebnissen.

gruss
  andre

Hallo Andre,

mit der Reichweite habe ich keine Erfahrung, muss jemand anders ran

Beim Empfangen der Nachrichten wird die erste ausgewertet. Also CUL_HM wird von HMLAN und CUL 'gespeist' (egal wie viele du hast:-))
CUL_HM verwirft doppelte Nachrichten. Da also einer der beiden schneller sein wird - ich habe ein kleine CUL und ein HMLAN - da gibt es massive unterscheide da das ein USB ist, das andere LAN....  - wird wohl meist der gleiche zum Zug kommen. Da die Nachrichten identisch sind kann getrost eine verworfen werden, was auch passiert.
Du kannst den ablaug beobachten indem du die Logs von HMLAN und CUL einschaltest. Das verwerfen logge ich nicht, passiert in CUL_HM, wo beide zusammenkommen.
HMLAN sollte auch dispatchen!
Vorteil: Sollte einer nicht empfangen (reichweite,...) klappt alles immer noch problemlos (also die empfangsseite!). Hier haben wir mehr als hot-standby, das ist voll-paralleler Betrieb der IOs.

das mit den acks ist jetzt eines meiner groesseren Problem in diesem Aufbau.
erst einmal das Senden ansich: gesender werden sollte nicht parallel, immer nur zu einem. Das kann man ueber IODev festlegen. Tut man dies nicht wird es automatisch festgelegt - muss ich mir einmal ansehen. Hatte bei mir nicht sinnvoll funktioniert. Es hing von der Reihenfolge der Eintraege in fhem.cfg ab.

jetzt die acks:
HMLAN sendet seine acks meist selbst - und ohne nachzufragen. CUL macht nichts selbst, man muss jedes ACK manuell schicken. CUL_HM sendet daher immer ACKs. HMLAN verwirft die unnoetigen, CUL sendet sie.
Ferner wird HMLAN nachrichten automatisch wiederholen, wenn das Device nicht antwortet.
Und da liegt eines der Probleme, das ganze wasserdicht zu machen.

Es gibt Einstellungen in HMLAN und ich bin mir sicher, dass man das Verhalten bezueglich ACKs und anderes steuern kann. Leider kenne ich nur einen Bruchteil der Befehle und habe auch diese nicht komplett ausgetestet.

Einen sauberen Betrieb kannst du sicher erreichen, wenn du 2 "netzwerte" aufbaust, also mit 2 HMIDs. Das ist dann aber keine Redundanz (obwohl - beim Empfangen schon, nur beim Senden nicht).

So gut erst einmal - fragen oder anregungen?

Gruss
Martin

hallo martin,

vielen dank für deine wie immer mühevolle erklärung.

zu den acks: ich sehe das problem wenn beide die nachricht empfangen, fhem die cul nachricht verwendet und acks sendet und hmlan auch noch automaitsch acks sendet. meinst du das? vielleicht wuerde es hier helfen die acks nur zu senden wenn die verwendete nachricht auch auf dem gleichen iodev empfangen wurde das auch zum senden eingetragen ist. damit würde zumindest das obige problem nicht auftreten. damit wäre zumindest einer der fälle für mögliche mehrfache acks beseitigt. ich weiss aber natürlich nicht was das für seiteneffekte hätte.

ich glaube wenn mein rasbbery pi so weit ist werde ich probeweise mal meinen fs20 cul mal daran mit homematic probieren. die reichweite sollte sehr viel besser sein und das scheint mir konzeptionell weniger probleme mit acks zu machen.

gruss
  andre

Zitatvielleicht wuerde es hier helfen die acks nur zu senden wenn die verwendete nachricht auch auf dem gleichen iodev empfangen wurde das auch zum senden eingetragen ist.

gute Idee. Eigentich ist das kein Problem, wenn du nur CULs verwendest.
 a) FHEM wird nur eine Nachricht parsen, alle anderen verwerfen (von CUL oder HMLAN, egal)
 b) FHEM wird daher auch nur 1 (in worten ein) ack senden. Über welches device ist eine andere Frage, egal

damit ist soweit alles ok... aber... HMLAN sendet eben ACK selbstaendig. Noch habe ich keinen Weg, dies zu unterbinden (gibt sicher einen - ich kenne ihn aber nicht) . mit HMLAN meine ich nicht das fhem-modul sondern die eq3 HW/FW HMLAN.

==> ich kann es (noch) nicht verhindern. Falls das ACK über CUL gesendet wird hat HMLAN schon längst selbständig auch eins geschickt.

Wenn ich einmal Zeit habe werden ich probieren HMLAN in einen "no-auto-ack" mode zu setzen - und das deviceabhaengig. Ich bin zuversichtlich dass dies geht - eq3 baut somit sicher eigenen Netzwerke mit mehreren HMLAN auf.... wir kennen nur die Kommandos nicht


p.s. an ein paar acks zuviel geht nicht gleich die ganze kommunikation flöten - aber es kann im Einzelfall zu Problemen kommen
Gruss
Martin

hallo martin,

vielleicht mache ich mir viel zu viele gedanken :) ich habe halt immer die fenster griff sensoren im auge und die senden unter umständen sehr kurz hintereinander zwei nachrichten. und wenn der empfang nicht besonders gut ist kommt es hier immer wieder zu problemen. ich habe die acks im verdacht weil sie eben den funkkanal belegen. da ich dann auch direkt eine meldung bezüglich mehrfacher ignorierter acks im log gesehen habe hab ich einfach mal meine theorie bestätigt gesehen :) aber du bist sicher sehr viel qualifizierter das zu beurteilen.

ansonsten noch ein paar dinge die mir aufgefallen sind:
- es reicht nicht mehr den cul in den pairing modus zu versetzen. der hmlan muss auf jeden fall dabei sein. ob es nur mit ihm geht weiss hab ich noch nicht probiert.
- ich habe den 4fach hutschienen aktor in betrieb genommen und als das pairen dann ging hab ich bemerk das wenn ich die tasten schnell nacheinander drücke erscheinen sie jeweils reih um als vom cul und hmlan empfangen. das scheint mir positiv und ich habe das gefühl das es nur mit dem cul nicht ganz so schnell möglich war. das wäre also positiv.

gruss
  andre

Zitateine meldung bezüglich mehrfacher ignorierter acks im log

welche meldung genau?

Zitatich habe die acks im verdacht weil sie eben den funkkanal belegen

im Prinzip bin ich bei dir: Fehlerhafte ACKs erzeugen Wiederholungen -und das alles zusammen addiert sich zu unnötiger Funklast.

Zitat- es reicht nicht mehr den cul in den pairing modus zu versetzen. der hmlan muss auf jeden fall dabei sein. ob es nur mit ihm geht weiss hab ich noch nicht probiert.

kann ich so nicht glauben ;-) - aber vielleicht kann ich etwas lernen. Kannst du ein log schicken - die messages wenn es nicht klappt? Natürlich CUL UND HMLAN

Zitatdie tasten schnell nacheinander drücke erscheinen sie jeweils reih um als vom cul und hmlan empfangen

- du schaust in CUL_HM nach oder einen level tiefer im IO device?
- es geht nur im das empfangen, kein senden? Wenn ja wo?
- was geht schneller? Bei nur Empfangen arbeitet FHEM die events nacheinander ab - aber in der Luft wird nichts gebremst!

Gruss
Martin

also das hier ist zum pairen:
gerade ein HM-OU-LED16 nach set cul2 hmPairForSec 600 angelernt. es wird das gerät und nach und nach alle leds angelegt. wenn ich aber danach ein get config mache gibt es nur ein NACK. wenn ich auf dem device einen button auslöse steht im event log ein 'to broadcast'. wenn ich zusätzlich ein hmlan hmPairForSec 600 mache und noch mal paire wird natürlich nichts neu angelegt aber ein getConfig gibt kein NACK mehr und wenn ich am gerät einen button auslöse steht ein 'to cul2'. ich habe leider vergessen den log level hoch zu drehen. das einzige was im log steht ist 2013.02.13 19:29:18 3: CUL_HM Unknown device CUL_HM_outputUnit_1D4B0B, please define it                  
2013.02.13 19:29:18 2: autocreate: define CUL_HM_outputUnit_1D4B0B CUL_HM 1D4B0B A1A0084001D4B0B00000011006D4A455130323139323736121000002013.02.13 19:29:18 3: CUL_HM pair: CUL_HM_outputUnit_1D4B0B outputUnit, model HM-OU-LED16 serialNr JEQ0219276
2013.02.13 19:29:18 3: hmlan pairing (hmPairForSec) not enabled                                      
2013.02.13 19:29:19 2: autocreate: define CUL_HM_outputUnit_1D4B0B_Led_01 CUL_HM 1D4B0B01                
2013.02.13 19:29:20 2: autocreate: define CUL_HM_outputUnit_1D4B0B_Led_02 CUL_HM 1D4B0B02                
... und beim zweiten mal pairen dann nur noch das: 2013.02.13 19:30:25 3: CUL_HM pair: CUL_HM_outputUnit_1D4B0B outputUnit, model HM-OU-LED16 serialNr JEQ0219276


zu den acks: ja. in der Luft wird nichts gebremst. aber könnte es sein das der cul gerade seine acks sendet und nicht empfangen könnte. der hmlan aber schon?

gruss
  andre

Ich sehe nur, wie kommandos empfangen werden.
kannst du einmal die messages aufzeichnen?

attr global mseclog 1
attr global verbose 1
attr <CUL> hmProtocolEvents 1
attr <CUL> loglevel 1

und dann pairing probieren....
Evtl ein getConfig
oder ein setzen des "pairCentral" registers - das ist identisch dem pairen

dann einmal sehen, was zurück kommt
Gruss
Martin

Hallo Martin,

Du hast ja den Support schon iplementiert (setRepeat) :-) Dazu hätte ich einn paar Fragen:

1) Sind je Gerätepaar jeweils zwei Settings über Kreuz notwendig ? Also z.B.

set Repeater_Kueche setRepeat 1 F14321 1859C7 no
set Repeater_Kueche setRepeat 2 1859C7 F14321 yes[/font]

(F14321 ist mein HM CUNO und 1859C7 ein Schaltaktor).

2) Gibt es eine Möglichkeit die aktuellen Settings auch paarweise wieder auszulesen
   (die PeerList zeigt ja "nur" die Gesamtliste der Peers) ?

3) Kann man dem Repeater ein bisschen mehr Debug im Logfile entlocken ? Interessant wäre zu
   sehen, welche Messages er konkret weiterleitet.

Bei der Auflösung der hmId anhand des Namens macht der CUNO übrigens noch Probleme:

set Repeater_Kueche setRepeat 1 CUNO1 1859C7 no
sender ID unknown:cuno1:2323 4321[/font]

Dies tritt auch dann auf, wenn die hmId für den CUNO zusätzlich als Attribute gesetzt wurde.
Aber man kann ja direkt mit der hmId des CUNOs arbeiten.

Toll, dass der Repeater jetzt unterstützt wird !

Gruss, Marc

Hi Marc,

zu 1)
ja, so muss es wohl funktionieren. Testen konnte ich es nicht, habe ja keinen.

zu 2)
du hast get myrepeater reg all schon probiert?

zu 3)
kannst du mir einmal ein Log schicken, wenn der repeater repeated?

zur CUNO
die Namensaufloesung der IO devices ist nicht komplett (eigentlich fast garnicht) vorhanden. Diese sind keine CUL_HM entities. Mal sehen, ob ich die irgendwie sammeln kann...

Gruss
Martin

Hallo Martin,

so richtig viel gibt das Log des Repeaters leider nicht her:

2013-02-17_15:13:22 Repeater_Kueche RESPONSE TIMEOUT:RegisterRead
2013-02-17_15:13:23 Repeater_Kueche noReceiver: src:1C37C4 (A410) 060100003A
2013-02-17_15:21:08 Repeater_Kueche RESPONSE TIMEOUT:RegisterRead
2013-02-17_15:21:43 Repeater_Kueche RESPONSE TIMEOUT:RegisterRead
2013-02-17_15:31:01 Repeater_Kueche powerOn: -
2013-02-17_15:55:24 Repeater_Kueche noReceiver: src:1C37C4 (A410) 060100003E
2013-02-17_19:22:42 Repeater_Kueche RESPONSE TIMEOUT:RegisterRead
2013-02-17_19:26:31 Repeater_Kueche RESPONSE TIMEOUT:RegisterRead
2013-02-17_20:18:38 Repeater_Kueche RESPONSE TIMEOUT:RegisterRead
2013-02-17_20:18:51 Repeater_Kueche noReceiver: src:1C37C4 (A410) 060100003D

Es ist also nicht ersichtlich, ob er wirklich Meldungen weiterleitet.

Der Status sieht wie folgt aus:

fhem> list Repeater_Kueche
Internals:
   CUNO1_MSGCNT 29
   CUNO1_RAWMSG A0ECCA4101C37C4F14321060100003D18
   CUNO1_RSSI -62
   CUNO1_TIME 2013-02-17 20:18:51
   DEF        1C37C4
   IODev      CUNO1
   LASTIODev  CUNO1
   MSGCNT     29
   NAME       Repeater_Kueche
   NR         253
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:CC - t:10 s:1C37C4 d:F14321 060100003D
   protCmdDel 1
   protLastRcv 2013-02-17 20:18:51
   protResnd  6 last_at:2013-02-17 20:18:33
   protResndFail 1 last_at:2013-02-17 20:18:38
   protSnd    6 last_at:2013-02-17 20:18:51
   protState  CMDs_done
   Readings:
     2013-02-17 20:17:59   PairedTo        0xF14321
     2013-02-17 20:17:22   R-pairCentral   0xF14321
     2013-02-17 20:18:51   noReceiver      src:1C37C4 (A410) 060100003D
     2013-02-17 20:18:39   peerList        Licht_Gehege,Licht_Weg,Luefter_Gehege_chn:01,F14321_chn:00,
     2013-02-17 20:18:38   state           RESPONSE TIMEOUT:RegisterRead
   Fhem:
   Helper:
     mId        0076
     rxType     1
     Shadowreg:
Attributes:
   firmware   1.1
   model      HM-Sys-sRP-Pl
   peerIDs    00000000,1859C701,185A3801,1C6FBD01,F1432100,
   room       Kueche
   serialNr   JEQ0467388
   subType    repeater

Das Auslesen der Register ist nicht wirklich ergiebig:

fhem> get Repeater_Kueche reg all
Repeater_Kueche type:repeater -
list:peer   register         :value
   0:         intKeyVisib      :invisib
   0:         pairCentral      :0xF14321

Gruß, Marc

Hallo Marc,

Zitatso richtig viel gibt das Log des Repeaters leider nicht her:

Interessiert bin ich an logs des Protokols - raw. Damit ich ein sample haben kann - dann kann ich nachdenken ob und wie man erkennen kann was vom receiver kommt. Evtl kann man etwas mit RSSI machen... da bastle ich gerade ein bisschen.

Also erst raw logs "einstellen"
attr global verbose 1
attr global mseglog 1
attr <hmlan oder IO> loglevel 1
attr <hmlan oder IO> hmProtocolEvents 0

dann ein paar Aktionen aufzeichnen mit einem Aktor der ueber den Repeater betrieben wird....

Die Unbekannten messages werden abgefangen...  dann gibt es auch eine "state"

ZitatDas Auslesen der Register ist nicht wirklich ergiebig:

kannst du ein 'getConfig' mit obigen attribute loggen?

Gruss
Martin

Hallo Martin,

anbei die gewünschten Logs. Es sieht so aus, als würde der Repeater für drei konfigurierten Aktoren wirklich "repeaten":

[Devices mit Repeater]

set Licht_Gehege statusRequest
2013.02.19 22:23:43 1: SW: As0B04A001F143211859C7010E
2013.02.19 22:23:43 1: CUNO1: A0B04E001F143211859C7010E -62.5
2013.02.19 22:23:43 1: CUNO1: A0E04A4101859C7F143210601000054 -88
2013.02.19 22:23:44 1: CUNO1: A0E04E4101859C7F143210601000054 -59.5

set Licht_Gehege on
2013.02.19 21:36:38 1: SW: As0E0AA011F143211859C70201C80000
2013.02.19 21:36:38 1: CUNO1: A0E0AE011F143211859C70201C80000 -60
2013.02.19 21:36:38 1: CUNO1: A0E0A80021859C7F143210101C80059 -86
2013.02.19 21:36:38 1: CUNO1: A0E0AC0021859C7F143210101C80059 -60.5

set Licht_Gehege off
2013.02.19 22:25:12 1: SW: As0E12A011F143211859C70201000000
2013.02.19 22:25:12 1: CUNO1: A0E12E011F143211859C70201000000 -59.5
2013.02.19 22:25:12 1: CUNO1: A0E1280021859C7F143210101000052 -84.5
2013.02.19 22:25:12 1: CUNO1: A0E12C0021859C7F143210101000052 -61.5

Licht Gehege an (am Schalter)
2013.02.19 21:40:00 1: CUNO1: A0D0684101859C70000000601C800 -85
2013.02.19 21:40:01 1: CUNO1: A0D06C4101859C70000000601C800 -62

Licht Gehege aus (am Schalter)
2013.02.19 21:41:02 1: CUNO1: A0D0CC4101859C700000006010000 -60

Lüfter Gehege an (am Schalter)
2013.02.19 21:41:38 1: CUNO1: A0D0A84101C6FBD0000000601C800 -86
2013.02.19 21:41:38 1: CUNO1: A0D0AC4101C6FBD0000000601C800 -60.5

Lüfter Gehege aus (am Schalter)
2013.02.19 21:42:10 1: CUNO1: A0D0C84101C6FBD00000006010000 -81.5
2013.02.19 21:42:11 1: CUNO1: A0D0CC4101C6FBD00000006010000 -60

Licht Weg an (am Schalter)
2013.02.19 21:43:51 1: CUNO1: A0DF08410185A380000000601C800 -69
2013.02.19 21:43:51 1: CUNO1: A0DF0C410185A380000000601C800 -60

Licht Weg aus (am Schalter)
2013.02.19 21:44:33 1: CUNO1: A0DF28410185A3800000006010000 -67.5
2013.02.19 21:44:33 1: CUNO1: A0DF2C410185A3800000006010000 -60.5


[Devices ohne Repeater]

set Licht_KU_Fenster off
2013.02.19 22:20:39 1: SW: As0E0BA011F143211A5C900201000000
2013.02.19 22:20:39 1: CUNO1: A0E0B80021A5C90F14321010100003D -67

set Licht_KU_Fenster on
2013.02.19 22:21:11 1: SW: As0E0CA011F143211A5C900201C80000
2013.02.19 22:21:11 1: CUNO1: A0E0C80021A5C90F143210101C80041 -62.5

Licht Kueche aus (am Schalter)
2013.02.19 22:15:42 1: CUNO1: A0DDB84101A5C9000000006010000 -77

Licht Kueche an (am Schalter)
2013.02.19 22:16:44 1: CUNO1: A0DDD84101A5C900000000601C800 -64.5

[getConfig]

set Repeater_Kueche getConfig
2013.02.19 22:31:17 1: SW: As100DA001F143211C37C400040000000000
2013.02.19 22:31:17 1: CUNO1: A140DA0101C37C4F143210202010AF10B430C21CDA9 -61.5
2013.02.19 22:31:17 1: SW: As0A0D8002F143211C37C400
2013.02.19 22:31:17 1: CUNO1: A0C0EA0101C37C4F14321030000 -61.5
2013.02.19 22:31:17 1: SW: As0A0E8002F143211C37C400
2013.02.19 22:31:17 1: SW: As0B0FA001F143211C37C40103
2013.02.19 22:31:18 1: CUNO1: A1A0FA0101C37C4F1432101F14321001859C701F14321001C6FBD01 -62
2013.02.19 22:31:18 1: SW: As0A0F8002F143211C37C400
2013.02.19 22:31:18 1: CUNO1: A1610A0101C37C4F1432101F1432100185A380100000000 -62
2013.02.19 22:31:18 1: SW: As0A108002F143211C37C400
2013.02.19 22:31:18 1: CUNO1: A1610A0101C37C4F1432101F1432100185A380100000000 -61
2013.02.19 22:31:18 1: SW: As1011A001F143211C37C401040000000002
2013.02.19 22:31:19 1: CUNO1: A0C11A0101C37C4F14321030800 -61.5
2013.02.19 22:31:19 1: SW: As0A118002F143211C37C400
2013.02.19 22:31:19 1: CUNO1: A0C12A0101C37C4F14321030018 -62
2013.02.19 22:31:19 1: SW: As0A128002F143211C37C400

Gruß, Marc

Hallo Marc,

die Traces sind hilfreich. Ich habe verstanden, man repeatede messages unterscheiden kann.
==> werde ich in die RSSI Auswertung einbauen an der ich bastle.

kannst du einmal ein

set <repeater> raw ++A001F143211C37C400040000000002

aufzeichnen? Offensichtlich muss ich einen andern Kanal eingeben...

Gruss
Martin

Hallo Martin,

here you go:

set Repeater_Kueche raw ++A001F143211C37C400040000000002
2013.02.20 18:29:02 1: SW: As10EFA001F143211C37C400040000000002
2013.02.20 18:29:07 1: SW: As10EFA001F143211C37C400040000000002
2013.02.20 18:29:12 1: SW: As10EFA001F143211C37C400040000000002
2013.02.20 18:29:12 1: CUNO1: A0CC086701AC26A000000002451 -66
2013.02.20 18:29:16 1: SW: As10EFA001F143211C37C400040000000002
2013.02.20 18:29:20 1: SW: As10EFA001F143211C37C400040000000002
2013.02.20 18:29:25 1: SW: As10EFA001F143211C37C400040000000002
2013.02.20 18:29:31 1: SW: As10EFA001F143211C37C400040000000002

Gruß, Marc

Hi Marc,

hm - auch nichts. Scheint man nicht direkt ruecklesen zu koennen.

Was ich gesehen habe ist die Liste der peerIDs. Diese kommt in einem besonderen Format - vielleicht kann man daraus etwas basteln.
Aktuell sind 3 devices und die Zentrale eingetragen. Um es sicher auszulesen muesste man ein paar versuche durchfuehren , damit wir ein Verstaendniss bekommen.
a) hast du noch alle kommandos, die du zu setzen benutzt hast? Welche waren dass? Bitte immer mit referenz zur HMID

b) tests = bitte mitloggen
kannst du einfach an stuck laufen lassen

set Repeater_Kueche getdevicepair    #kontrolle...
set Repeater_Kueche setRepeat 10 A14321 9959C7 no
set Repeater_Kueche getdevicepair
set Repeater_Kueche setRepeat 11 9959C7 A14321 no
set Repeater_Kueche getdevicepair
set Repeater_Kueche setRepeat 10 000000 000000 no
set Repeater_Kueche getdevicepair
set Repeater_Kueche setRepeat 12 B14321 C14321 no
set Repeater_Kueche getdevicepair
set Repeater_Kueche setRepeat 12 B14321 D14321 no
set Repeater_Kueche getdevicepair
set Repeater_Kueche setRepeat 11 000000 000000 no
set Repeater_Kueche setRepeat 12 000000 000000 no
set Repeater_Kueche getdevicepair
set Repeater_Kueche setRepeat 12 B14321 D14321 yes
set Repeater_Kueche getConfig
set Repeater_Kueche setRepeat 12 000000 000000 yes
set Repeater_Kueche getConfig
set Repeater_Kueche setRepeat 12 000000 000000 no
set Repeater_Kueche getConfig

mal sehen

Gruss
Martin

Hallo Martin

hier die Infos:

a)
# CUNO1 - Schalter_Gegege_1
set Repeater_Kueche setRepeat 1 F14321 1859C7 no
set Repeater_Kueche setRepeat 2 1859C7 F14321 yes

# CUNO1 - Luefter_Gegege
set Repeater_Kueche setRepeat 3 F14321 1C6FBD no
set Repeater_Kueche setRepeat 4 1C6FBD F14321 yes

# CUNO1 - Schalter_Gegege_2
set Repeater_Kueche setRepeat 5 F14321 185A38 no
set Repeater_Kueche setRepeat 6 185A38 F14321 yes

b)
2013.02.21 21:57:41 1: SW: As0B3CA001F143211C37C40103
2013.02.21 21:57:42 1: CUNO1: A1A3CA0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:57:42 1: SW: As0A3C8002F143211C37C400
2013.02.21 21:57:42 1: CUNO1: A1A3CA0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:57:42 1: CUNO1: A1A3DA0101C37C4F1432101F1432100185A3801A14321009959C700 -62
2013.02.21 21:57:42 1: SW: As0A3D8002F143211C37C400
2013.02.21 21:57:42 1: CUNO1: A1A3DA0101C37C4F1432101F1432100185A3801A14321009959C700 -60
2013.02.21 21:57:42 1: CUNO1: A0E3EA0101C37C4F143210100000000 -62
2013.02.21 21:57:42 1: SW: As0A3E8002F143211C37C400
2013.02.21 21:57:43 1: SW: As103FA001F143211C37C401050000000002
2013.02.21 21:57:43 1: CUNO1: A0A3F80021C37C4F1432100 -62
2013.02.21 21:57:43 1: SW: As1940A001F143211C37C4010840A1414342214399445945C74600
2013.02.21 21:57:43 1: CUNO1: A0A4080021C37C4F1432100 -60.5
2013.02.21 21:57:43 1: SW: As0B41A001F143211C37C40106
2013.02.21 21:57:43 1: CUNO1: A0A4180021C37C4F1432100 -62
2013.02.21 21:57:43 1: SW: As0B42A001F143211C37C40103
2013.02.21 21:57:48 1: SW: As0B42A001F143211C37C40103
2013.02.21 21:57:48 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:57:48 1: SW: As0A428002F143211C37C400
2013.02.21 21:57:49 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -64
2013.02.21 21:57:49 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61.5
2013.02.21 21:57:49 1: SW: As0B42A001F143211C37C40103
2013.02.21 21:57:49 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:57:50 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60
2013.02.21 21:57:55 1: SW: As0B42A001F143211C37C40103
2013.02.21 21:57:56 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61.5
2013.02.21 21:57:56 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63.5
2013.02.21 21:57:56 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61
2013.02.21 21:57:57 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60
2013.02.21 21:57:57 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63.5
2013.02.21 21:57:57 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:57:59 1: SW: As0B42A001F143211C37C40103
2013.02.21 21:58:00 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60
2013.02.21 21:58:00 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:58:01 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63.5
2013.02.21 21:58:01 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:58:01 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61
2013.02.21 21:58:02 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63.5
2013.02.21 21:58:04 1: SW: As0B42A001F143211C37C40103
2013.02.21 21:58:04 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61.5
2013.02.21 21:58:05 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -62
2013.02.21 21:58:07 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63
2013.02.21 21:58:10 1: SW: As0B42A001F143211C37C40103
2013.02.21 21:58:10 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -65
2013.02.21 21:58:11 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -65
2013.02.21 21:58:11 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61.5
2013.02.21 21:58:12 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61.5
2013.02.21 21:58:12 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -65
2013.02.21 21:58:12 1: CUNO1: A1A42A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -62
2013.02.21 21:58:16 1: SW: As1043A001F143211C37C401050000000002
2013.02.21 21:58:16 1: CUNO1: A0A4380021C37C4F1432100 -62
2013.02.21 21:58:16 1: SW: As1944A001F143211C37C401084799485949C74AA14B434C214D00
2013.02.21 21:58:17 1: CUNO1: A0A4480021C37C4F1432100 -60.5
2013.02.21 21:58:17 1: SW: As0B45A001F143211C37C40106
2013.02.21 21:58:17 1: CUNO1: A0A4580021C37C4F1432100 -62
2013.02.21 21:58:17 1: SW: As0B46A001F143211C37C40103
2013.02.21 21:58:21 1: SW: As0B46A001F143211C37C40103
2013.02.21 21:58:22 1: CUNO1: A1A46A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63
2013.02.21 21:58:22 1: SW: As0A468002F143211C37C400
2013.02.21 21:58:22 1: CUNO1: A1A47A0101C37C4F1432101F1432100185A3801A14321009959C700 -61
2013.02.21 21:58:22 1: SW: As0A478002F143211C37C400
2013.02.21 21:58:22 1: CUNO1: A1A47A0101C37C4F1432101F1432100185A3801A14321009959C700 -63.5
2013.02.21 21:58:22 1: CUNO1: A0E48A0101C37C4F143210100000000 -60.5
2013.02.21 21:58:22 1: SW: As0A488002F143211C37C400
2013.02.21 21:58:23 1: SW: As1049A001F143211C37C401050000000002
2013.02.21 21:58:23 1: CUNO1: A0A4980021C37C4F1432100 -60
2013.02.21 21:58:23 1: SW: As194AA001F143211C37C401084000410042004300440045004600
2013.02.21 21:58:23 1: CUNO1: A0A4A80021C37C4F1432100 -60
2013.02.21 21:58:23 1: SW: As0B4BA001F143211C37C40106
2013.02.21 21:58:23 1: CUNO1: A0A4B80021C37C4F1432100 -60
2013.02.21 21:58:23 1: SW: As0B4CA001F143211C37C40103
2013.02.21 21:58:29 1: SW: As0B4CA001F143211C37C40103
2013.02.21 21:58:29 1: CUNO1: A1A4CA0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63
2013.02.21 21:58:29 1: SW: As0A4C8002F143211C37C400
2013.02.21 21:58:29 1: CUNO1: A1A4DA0101C37C4F1432101F1432100185A38019959C70000000000 -65.5
2013.02.21 21:58:30 1: SW: As0A4D8002F143211C37C400
2013.02.21 21:58:30 1: CUNO1: A1A4DA0101C37C4F1432101F1432100185A38019959C70000000000 -64
2013.02.21 21:58:30 1: SW: As104EA001F143211C37C401050000000002
2013.02.21 21:58:30 1: CUNO1: A0A4E80021C37C4F1432100 -62.5
2013.02.21 21:58:30 1: SW: As194FA001F143211C37C401084EB14F43502151C1524353215400
2013.02.21 21:58:30 1: CUNO1: A0A4F80021C37C4F1432100 -68
2013.02.21 21:58:30 1: SW: As0B50A001F143211C37C40106
2013.02.21 21:58:30 1: CUNO1: A0A5080021C37C4F1432100 -69
2013.02.21 21:58:31 1: SW: As0B51A001F143211C37C40103
2013.02.21 21:58:36 1: SW: As0B51A001F143211C37C40103
2013.02.21 21:58:36 1: CUNO1: A1A51A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -64.5
2013.02.21 21:58:37 1: SW: As0A518002F143211C37C400
2013.02.21 21:58:37 1: CUNO1: A1A52A0101C37C4F1432101F1432100185A38019959C700B1432100 -64.5
2013.02.21 21:58:37 1: SW: As0A528002F143211C37C400
2013.02.21 21:58:37 1: CUNO1: A1A52A0101C37C4F1432101F1432100185A38019959C700B1432100 -65
2013.02.21 21:58:37 1: CUNO1: A0E53A0101C37C4F143210100000000 -65.5
2013.02.21 21:58:37 1: SW: As0A538002F143211C37C400
2013.02.21 21:58:37 1: SW: As1054A001F143211C37C401050000000002
2013.02.21 21:58:38 1: CUNO1: A0A5480021C37C4F1432100 -65
2013.02.21 21:58:38 1: SW: As1955A001F143211C37C401084EB14F43502151D1524353215400
2013.02.21 21:58:38 1: CUNO1: A0A5580021C37C4F1432100 -66
2013.02.21 21:58:38 1: SW: As0B56A001F143211C37C40106
2013.02.21 21:58:38 1: CUNO1: A0A5680021C37C4F1432100 -67
2013.02.21 21:58:38 1: SW: As0B57A001F143211C37C40103
2013.02.21 21:58:44 1: SW: As0B57A001F143211C37C40103
2013.02.21 21:58:44 1: CUNO1: A1A57A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61
2013.02.21 21:58:44 1: SW: As0A578002F143211C37C400
2013.02.21 21:58:44 1: CUNO1: A1A58A0101C37C4F1432101F1432100185A38019959C700B1432100 -61
2013.02.21 21:58:45 1: SW: As0A588002F143211C37C400
2013.02.21 21:58:45 1: CUNO1: A1A58A0101C37C4F1432101F1432100185A38019959C700B1432100 -60
2013.02.21 21:58:45 1: CUNO1: A0E59A0101C37C4F143210100000000 -61.5
2013.02.21 21:58:45 1: SW: As0A598002F143211C37C400
2013.02.21 21:58:45 1: SW: As105AA001F143211C37C401050000000002
2013.02.21 21:58:45 1: CUNO1: A0A5A80021C37C4F1432100 -64
2013.02.21 21:58:45 1: SW: As195BA001F143211C37C401084700480049004A004B004C004D00
2013.02.21 21:58:45 1: CUNO1: A0A5B80021C37C4F1432100 -60.5
2013.02.21 21:58:46 1: SW: As0B5CA001F143211C37C40106
2013.02.21 21:58:46 1: CUNO1: A0A5C80021C37C4F1432100 -60.5
2013.02.21 21:58:46 1: SW: As105DA001F143211C37C401050000000002
2013.02.21 21:58:48 1: SW: As105DA001F143211C37C401050000000002
2013.02.21 21:58:48 1: CUNO1: A0A5D80021C37C4F1432100 -61
2013.02.21 21:58:48 1: SW: As195EA001F143211C37C401084E004F0050005100520053005400
2013.02.21 21:58:48 1: CUNO1: A0A5E80021C37C4F1432100 -60
2013.02.21 21:58:49 1: SW: As0B5FA001F143211C37C40106
2013.02.21 21:58:49 1: CUNO1: A0A5F80021C37C4F1432100 -62
2013.02.21 21:58:49 1: SW: As0B60A001F143211C37C40103
2013.02.21 21:58:53 1: SW: As0B60A001F143211C37C40103
2013.02.21 21:58:53 1: CUNO1: A0C4C86701AC26A000000001C50 -65
2013.02.21 21:58:53 1: CUNO1: A1A60A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -60.5
2013.02.21 21:58:53 1: SW: As0A608002F143211C37C400
2013.02.21 21:58:54 1: CUNO1: A1661A0101C37C4F1432101F1432100185A380100000000 -59.5
2013.02.21 21:58:54 1: SW: As0A618002F143211C37C400
2013.02.21 21:58:54 1: CUNO1: A1661A0101C37C4F1432101F1432100185A380100000000 -60
2013.02.21 21:58:54 1: SW: As1062A001F143211C37C401050000000002
2013.02.21 21:58:54 1: CUNO1: A0A6280021C37C4F1432100 -60
2013.02.21 21:58:54 1: SW: As1963A001F143211C37C401084EB14F43502151D1524353215401
2013.02.21 21:58:54 1: CUNO1: A0A6380021C37C4F1432100 -60.5
2013.02.21 21:58:55 1: SW: As0B64A001F143211C37C40106
2013.02.21 21:58:55 1: CUNO1: A0A6480021C37C4F1432100 -59.5
2013.02.21 21:58:55 1: SW: As1065A001F143211C37C400040000000000
2013.02.21 21:59:01 1: SW: As1065A001F143211C37C400040000000000
2013.02.21 21:59:01 1: CUNO1: A1465A0101C37C4F143210202010AF10B430C215A36 -62
2013.02.21 21:59:01 1: SW: As0A658002F143211C37C400
2013.02.21 21:59:01 1: CUNO1: A0C66A0101C37C4F14321030000 -62
2013.02.21 21:59:01 1: SW: As0A668002F143211C37C400
2013.02.21 21:59:01 1: SW: As0B67A001F143211C37C40103
2013.02.21 21:59:01 1: CUNO1: A1A67A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -63.5
2013.02.21 21:59:02 1: SW: As0A678002F143211C37C400
2013.02.21 21:59:02 1: CUNO1: A1A68A0101C37C4F1432101F1432100185A3801B143210100000000 -62.5
2013.02.21 21:59:02 1: SW: As0A688002F143211C37C400
2013.02.21 21:59:02 1: CUNO1: A1A68A0101C37C4F1432101F1432100185A3801B143210100000000 -61.5
2013.02.21 21:59:02 1: SW: As1069A001F143211C37C401040000000002
2013.02.21 21:59:02 1: CUNO1: A0C69A0101C37C4F14321030800 -60.5
2013.02.21 21:59:03 1: SW: As0A698002F143211C37C400
2013.02.21 21:59:03 1: CUNO1: A0C6AA0101C37C4F14321030000 -62.5
2013.02.21 21:59:03 1: SW: As0A6A8002F143211C37C400
2013.02.21 21:59:03 1: CUNO1: A0C6AA0101C37C4F14321030000 -60.5
2013.02.21 21:59:03 1: SW: As106BA001F143211C37C401050000000002
2013.02.21 21:59:03 1: CUNO1: A0A6B80021C37C4F1432100 -60
2013.02.21 21:59:04 1: SW: As196CA001F143211C37C401084E004F0050005100520053005401
2013.02.21 21:59:04 1: CUNO1: A0A6C80021C37C4F1432100 -60.5
2013.02.21 21:59:04 1: SW: As0B6DA001F143211C37C40106
2013.02.21 21:59:04 1: CUNO1: A0A6D80021C37C4F1432100 -59.5
2013.02.21 21:59:04 1: SW: As106EA001F143211C37C400040000000000
2013.02.21 21:59:06 1: CUNO1: A0D3184101B8F07F1432106012600 -55.5
2013.02.21 21:59:07 1: SW: As0D318002F143211B8F0701012600
2013.02.21 21:59:08 1: CUNO1: A0D74A41019723EF1432106010000 -58
2013.02.21 21:59:08 1: SW: As0A748002F1432119723E00
2013.02.21 21:59:09 1: SW: As106EA001F143211C37C400040000000000
2013.02.21 21:59:09 1: CUNO1: A146EA0101C37C4F143210202010AF10B430C21922D -60.5
2013.02.21 21:59:10 1: SW: As0A6E8002F143211C37C400
2013.02.21 21:59:10 1: CUNO1: A0C6FA0101C37C4F14321030000 -59.5
2013.02.21 21:59:10 1: SW: As0A6F8002F143211C37C400
2013.02.21 21:59:10 1: SW: As0B70A001F143211C37C40103
2013.02.21 21:59:10 1: CUNO1: A1A70A0101C37C4F1432101F14321001859C701F14321001C6FBD01 -61.5
2013.02.21 21:59:10 1: SW: As0A708002F143211C37C400
2013.02.21 21:59:11 1: CUNO1: A1671A0101C37C4F1432101F1432100185A380100000000 -62
2013.02.21 21:59:11 1: SW: As0A718002F143211C37C400
2013.02.21 21:59:11 1: CUNO1: A1671A0101C37C4F1432101F1432100185A380100000000 -61.5
2013.02.21 21:59:11 1: SW: As1072A001F143211C37C401040000000002
2013.02.21 21:59:11 1: CUNO1: A0C72A0101C37C4F14321030800 -60
2013.02.21 21:59:11 1: SW: As0A728002F143211C37C400
2013.02.21 21:59:11 1: CUNO1: A0C73A0101C37C4F14321030000 -61
2013.02.21 21:59:12 1: SW: As0A738002F143211C37C400
2013.02.21 21:59:12 1: SW: As1074A001F143211C37C401050000000002
2013.02.21 21:59:12 1: CUNO1: A0A7480021C37C4F1432100 -60
2013.02.21 21:59:12 1: SW: As1975A001F143211C37C401084E004F0050005100520053005400
2013.02.21 21:59:12 1: CUNO1: A0A7580021C37C4F1432100 -64.5
2013.02.21 21:59:12 1: SW: As0B76A001F143211C37C40106
2013.02.21 21:59:12 1: CUNO1: A0A7680021C37C4F1432100 -61

Ich hoffe, dass bei b) nicht dazwischengefunkt wurde ...

Gruß, Marc

Hi Marc,

teilerfolg.
a) direktes ruecklesen scheint nicht moeglich
b) in der peerliste tauchen alle IDs der "source" auf, die receiver aber nicht.
c) die Angezogene channel-number in der peerList ist falsch interpretiert - das funktioniert beim repeater nicht so

==> ich werde eine Auswertung in readings erstellen, die eine Liste aller Sourcen und den broadcasts enthaelt

So nun die offenen Punkte:
Ich kann nicht sehen welcher receiver eingetragen ist. Auch die Nummer des Eintrags kann ich nicht sehen. Sehen kann ich, wenn eine sourceID mehrfach vorkommt.

Die Auswertung wird also so in der Art aussehen

Entries:
1 Schalter_Gegege_1 Brdcast
1 Schalter_Gegege_2 Brdcast
1 Luefter_Gegege Brdcast
3 zentrale noBrdcast

Mal sehen was ich beim repeater mit der peerList mache... evtl kann man hier die Info reinpacken - ist dann aber unformatiert...
Gruss
Marnti

Hallo Martin,

so,heute habe ich den neuen Repeater endlich malzusammen gelötet und mit ihm
gleich mal was interessantes ausprobiert. Ich hatte mir die Tage einen
HM-LC-SW1-BA-PCB gekauft und zusammengesetzt. Pairen ging zwar, mehr aber auch
nicht, da ich keinen HMLAN sondern nur CULs/CUNOs habe. Daher habe ich den
Schalter mal in die PeerList der Repeaters aufgenommen. Was soll ich sagen,
jetzt kann ich ihn schalten. Der Repeater scheint also Burst zu unterstützen.
Kann das jemand bestetigen ? Damit wäre der Reapter ja ggf. eine alternative
um Burst Sensoren/Aktoren über einen CUL anzusteuern :-)

Gruß,Marc

Hallo Marc,

so du es so sagst ist es logisch.
Wenn der Aktor ausserhalb der Reichreite des HMLAN liegt muss der repeater alle signale "nachbauen".
Der repeater ist kein Verstärker, er wiederholt das signal zeitversetzt. Also baut er es wieder zusammen - obendrein markiert er es noch als "repeated", veraendert es also.
Er könnte jetzt sniffen, dass eine "burst" sequenz zu beginn vorhanden war. Oder er macht es wie ein HMLAN, er erkennt an der message dass es eines burst bedarf und schickt einen. Die FW ist schon im HMLAN realisiert und sicher auch in anderen Zentralen.

Somit wird die message, auch wenn sie von einer CUL kommt korrekt verarbeitet und der Burst generiert.

daran gedacht haette ich nicht, aber wie gesagt, logisch und konsequent.
Das gibt CUL betreibern eine weitere Option

Gruss, Martin

Moin !

Bei Interesse, im Log sieht da wie folgt aus:

2013.03.24 13:54:52 5: Cmd: >set Tuerklingel on<
2013.03.24 13:54:52 5: Triggering Tuerklingel (1 changes)
2013.03.24 13:54:53 2: CUL_HM set Tuerklingel on rxt:2
2013.03.24 13:54:53 5: CUNO1 sending As0EF3B011F143211EFF0D0201C80000
2013.03.24 13:54:53 5: SW: As0EF3B011F143211EFF0D0201C80000
2013.03.24 13:54:53 5: CUL/RAW: /A0EF3B011F143211EFF0D0201C8000013

2013.03.24 13:54:53 5: CUL1: A0EF3B011F143211EFF0D0201C80000 -64.5
2013.03.24 13:54:53 5: CUL1 dispatch A0EF3B011F143211EFF0D0201C80000::-64.5:CUL1
2013.03.24 13:54:53 5: CUL/RAW: /A0EF3F011F143211EFF0D0201C8000006

2013.03.24 13:54:53 5: CUL1: A0EF3F011F143211EFF0D0201C80000 -71
2013.03.24 13:54:53 5: CUL1 dispatch A0EF3F011F143211EFF0D0201C80000::-71:CUL1
2013.03.24 13:54:53 5: CUL/RAW: /A0EF3F011F143211EFF0D0201C8000026

2013.03.24 13:54:53 5: CUNO1: A0EF3F011F143211EFF0D0201C80000 -55
2013.03.24 13:54:53 5: CUNO1 dispatch A0EF3F011F143211EFF0D0201C80000::-55:CUNO1
2013.03.24 13:54:53 5: CUL/RAW: /A0EF380021EFF0DF143210101C88035EF

2013.03.24 13:54:53 5: CUL1: A0EF380021EFF0DF143210101C88035 -82.5
2013.03.24 13:54:53 5: CUL1 dispatch A0EF380021EFF0DF143210101C88035::-82.5:CUL1
2013.03.24 13:54:53 5: Triggering Tuerklingel (3 changes)
2013.03.24 13:54:54 5: CUL/RAW: /A0EF380021EFF0DF143210101C880352C
A0EF3C0021EFF0DF143210101C8803526

2013.03.24 13:54:54 5: CUNO1: A0EF380021EFF0DF143210101C88035 -52
2013.03.24 13:54:54 5: CUNO1 dispatch A0EF380021EFF0DF143210101C88035::-52:CUNO1
2013.03.24 13:54:54 4: CUL_HM Tuerklingel dup mesg
2013.03.24 13:54:54 4: CUL_HM Tuerklingel dup mesg - ignore
2013.03.24 13:54:54 5: CUNO1: A0EF3C0021EFF0DF143210101C88035 -55
2013.03.24 13:54:54 5: CUNO1 dispatch A0EF3C0021EFF0DF143210101C88035::-55:CUNO1
2013.03.24 13:54:54 4: CUL_HM Tuerklingel dup mesg
2013.03.24 13:54:54 4: CUL_HM Tuerklingel dup mesg - ignore
2013.03.24 13:54:54 5: CUL/RAW: /A0EF3C0021EFF0DF143210101C8803509

2013.03.24 13:54:54 5: CUL1: A0EF3C0021EFF0DF143210101C88035 -69.5
2013.03.24 13:54:54 5: CUL1 dispatch A0EF3C0021EFF0DF143210101C88035::-69.5:CUL1
2013.03.24 13:54:54 4: CUL_HM Tuerklingel dup mesg
2013.03.24 13:54:54 4: CUL_HM Tuerklingel dup mesg - ignore
2013.03.24 13:54:57 5: Cmd: >set Tuerklingel off<
2013.03.24 13:54:57 5: Triggering Tuerklingel (1 changes)
2013.03.24 13:54:57 2: CUL_HM set Tuerklingel off rxt:2
2013.03.24 13:54:57 5: CUNO1 sending As0EF4B011F143211EFF0D0201000000
2013.03.24 13:54:57 5: SW: As0EF4B011F143211EFF0D0201000000
2013.03.24 13:54:57 5: CUL/RAW: /A0EF4B011F143211EFF0D020100000013

2013.03.24 13:54:57 5: CUL1: A0EF4B011F143211EFF0D0201000000 -64.5
2013.03.24 13:54:57 5: CUL1 dispatch A0EF4B011F143211EFF0D0201000000::-64.5:CUL1
2013.03.24 13:54:57 5: CUL/RAW: /A0EF4F011F143211EFF0D020100000007

2013.03.24 13:54:57 5: CUL1: A0EF4F011F143211EFF0D0201000000 -70.5
2013.03.24 13:54:57 5: CUL1 dispatch A0EF4F011F143211EFF0D0201000000::-70.5:CUL1
2013.03.24 13:54:57 5: CUL/RAW: /A0EF480021EFF0DF143210101000035EE

2013.03.24 13:54:57 5: CUL1: A0EF480021EFF0DF143210101000035 -83
2013.03.24 13:54:57 5: CUL1 dispatch A0EF480021EFF0DF143210101000035::-83:CUL1
2013.03.24 13:54:57 5: Triggering Tuerklingel (3 changes)

2013.03.24 13:54:58 5: CUL/RAW: /A0EF4F011F143211EFF0D020100000026
A0EF480021EFF0DF1432101010000352C
A0EF4C0021EFF0DF14321010100003527

2013.03.24 13:54:58 5: CUNO1: A0EF4F011F143211EFF0D0201000000 -55
2013.03.24 13:54:58 5: CUNO1 dispatch A0EF4F011F143211EFF0D0201000000::-55:CUNO1
2013.03.24 13:54:58 5: CUNO1: A0EF480021EFF0DF143210101000035 -52
2013.03.24 13:54:58 5: CUNO1 dispatch A0EF480021EFF0DF143210101000035::-52:CUNO1
2013.03.24 13:54:58 4: CUL_HM Tuerklingel dup mesg
2013.03.24 13:54:58 4: CUL_HM Tuerklingel dup mesg - ignore
2013.03.24 13:54:58 5: CUNO1: A0EF4C0021EFF0DF143210101000035 -54.5
2013.03.24 13:54:58 5: CUNO1 dispatch A0EF4C0021EFF0DF143210101000035::-54.5:CUNO1
2013.03.24 13:54:58 4: CUL_HM Tuerklingel dup mesg
2013.03.24 13:54:58 4: CUL_HM Tuerklingel dup mesg - ignore
2013.03.24 13:54:58 5: CUL/RAW: /A0EF4C0021EFF0DF14321010100003507

2013.03.24 13:54:58 5: CUL1: A0EF4C0021EFF0DF143210101000035 -70.5
2013.03.24 13:54:58 5: CUL1 dispatch A0EF4C0021EFF0DF143210101000035::-70.5:CUL1
2013.03.24 13:54:58 4: CUL_HM Tuerklingel dup mesg
2013.03.24 13:54:58 4: CUL_HM Tuerklingel dup mesg - ignore
Gruß,Marc

Hi nach Durchfliegen des Threads bin ich mir jetzt unsicher ob der HM-Sys-sRP-Pl unterstützt wird oder nicht...
Kann ich den nun mit Fhem und einem CUL zusammen einsetzen?

nicht ganz klar, wo die Zweifel herkommen.
der repeater wiederholt messages wie programmiert - egal ob die Quelle CUL oder HMLAN ist.
der Repeater laesst sich komplett aus FHEM heraus programmieren (jedenfalls kenne ich keine Lücken)
Der Repeater laesst sich fast komplett auslesen - mir ist nicht bekannt, dass es eine HM SW besser kann.
FHEM wertet RSSI getrennt nach IOdev und repeater aus (ausser auf der Device seite, da ist es nicht möglich)

==> da es ein selektiver repeater ist muss man sich im klaren sein, was man wiederholen lassen will

Ich kann keine Probleme sehen

Danke, das wollt ich wissen.
Gruss