cul und hmlan

[justme1968]

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

[Martin Thomas Schrott]

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

[martinp876]

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

[justme1968]

danke.

ich werde probieren und berichten.

gruss
  andre

[justme1968]

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

[martinp876]

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

[justme1968]

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

[Martin Thomas Schrott]

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

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

[martinp876]

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

[Martin Thomas Schrott]

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

[Billy]

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

[justme1968]

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

[justme1968]

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

[martinp876]

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

[justme1968]

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