Mehrere HM-CFG-LAN Konfig Adapter

[Guest]

Originally posted by: <email address deleted>

Hallo Zusammen,

ich habe aktuell 2 HM-CFG-LAN an einer fhem-Installation angemeldet :

define HMLAN1 HMLAN 192.168.1.1:1000
attr HMLAN1 hmId 123ABC

define HMLAN2 HMLAN 192.168.1.2:1000
attr HMLAN2 hmId 456DEF

HMLAN1 ist mit einem Wandthermostat und einem Zwischenstecker-Schaltaktor
gepaired.
HMLAN2 ist mit einem Außenfühler gepaired.

Das Pairing ist jeweils passend zum Empfangsbereich der LAN-Adapter.

Alle HM-Komponenten erscheinen unterhalb von CUL_HM.

Leider habe ich keine Beschreibung ähnlicher Konfigurationen gefunden.
Es sieht für mich so aus, als würde der Betrieb auch funktionieren.

Meine Frage : Ist das tatsächlich so dauerhaft nutzbar bzw. vorgesehen ?

Um eine flächendeckende Funkversorgung zu erhalten plane ich evtl. einen
dritten LAN-Adapter zu installieren.
Daher vorbeugend die Frage, ob ich hier das Design breche. Oder sollte ich
besser die HM-Repeater in der Zwischenstecker-Bauform einsetzen ?
Es sollen 8-10 Wandthermostate folgen + Diverse Schaltaktoren.

Viele Grüße,
Sven


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

[Guest]

Originally posted by: <email address deleted>

Hallo Sven,
ich habe es sogar noch weiter auf die Spitze getrieben und bisher keinen Nebeneffekt festgestellt.
Bei mir arbeiten beide hm-lan mit der gleichen hmid.
Ich habe allerdings in einigen Geräten dann das attr iodev auf den räumlich am nächsten liegenden hmlan gesetzt.
Etliche Geräte haben aber auch kein attr iodev und nutzen dann meines Wissens nach den hmlan, welcher in der fhem.cfg davor geladen wurde.
Wenn der HM Martin hier reinschaut, dann hat er evtl. ja noch nen Tipp.

VG


Am Dienstag, 4. Dezember 2012 19:48:56 UTC+1 schrieb Sven:
> Hallo Zusammen,
>
>
> ich habe aktuell 2 HM-CFG-LAN an einer fhem-Installation angemeldet :
>
>
>
> define HMLAN1 HMLAN 192.168.1.1:1000
> attr HMLAN1 hmId 123ABC
>
>
> define HMLAN2 HMLAN 192.168.1.2:1000
> attr HMLAN2 hmId 456DEF
>
>
> HMLAN1 ist mit einem Wandthermostat und einem Zwischenstecker-Schaltaktor gepaired.
> HMLAN2 ist mit einem Außenfühler gepaired.
>
>
> Das Pairing ist jeweils passend zum Empfangsbereich der LAN-Adapter.
>
>
> Alle HM-Komponenten erscheinen unterhalb von CUL_HM.
>
>
> Leider habe ich keine Beschreibung ähnlicher Konfigurationen gefunden.
> Es sieht für mich so aus, als würde der Betrieb auch funktionieren.
>
>
> Meine Frage : Ist das tatsächlich so dauerhaft nutzbar bzw. vorgesehen ?
>
>
> Um eine flächendeckende Funkversorgung zu erhalten plane ich evtl. einen dritten LAN-Adapter zu installieren.
> Daher vorbeugend die Frage, ob ich hier das Design breche. Oder sollte ich besser die HM-Repeater in der Zwischenstecker-Bauform einsetzen ?
> Es sollen 8-10 Wandthermostate folgen + Diverse Schaltaktoren.
>
>
> Viele Grüße,
> Sven

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

[Guest]

Originally posted by: <email address deleted>

Hi!

ich bin zwar ein absoluter Neuling auf diesem Gebiet, aber soweit ich
das aus diversen Dokus und Postings gelesen habe arbeitet der HM LAN
doch als Repeater --> somit brauchst du doch nur einen mit FHEM
verknüpfen und alle weiteren bei dir im Haus verteilen und ihren Job
machen lassen? Die sollten doch alles was sie empfangen auch
weiterleiten?...
Wie gesagt so hab ich es aus dieversen Quellen verstanden, der richtige
Martin bessere meine Gedanken natürlich sofort aus, wenn das Schwachsinn
war.

lG
Martin


Am 04.12.2012 20:27, schrieb thotti70@gmx.net:
> Hallo Sven,
> ich habe es sogar noch weiter auf die Spitze getrieben und bisher keinen Nebeneffekt festgestellt.
> Bei mir arbeiten beide hm-lan mit der gleichen hmid.
> Ich habe allerdings in einigen Geräten dann das attr iodev auf den räumlich am nächsten liegenden hmlan gesetzt.
> Etliche Geräte haben aber auch kein attr iodev und nutzen dann meines Wissens nach den hmlan, welcher in der fhem.cfg davor geladen wurde.
> Wenn der HM Martin hier reinschaut, dann hat er evtl. ja noch nen Tipp.
>
> VG
>
>
> Am Dienstag, 4. Dezember 2012 19:48:56 UTC+1 schrieb Sven:
>> Hallo Zusammen,
>>
>>
>> ich habe aktuell 2 HM-CFG-LAN an einer fhem-Installation angemeldet :
>>
>>
>>
>> define HMLAN1 HMLAN 192.168.1.1:1000
>> attr HMLAN1 hmId 123ABC
>>
>>
>> define HMLAN2 HMLAN 192.168.1.2:1000
>> attr HMLAN2 hmId 456DEF
>>
>>
>> HMLAN1 ist mit einem Wandthermostat und einem Zwischenstecker-Schaltaktor gepaired.
>> HMLAN2 ist mit einem Außenfühler gepaired.
>>
>>
>> Das Pairing ist jeweils passend zum Empfangsbereich der LAN-Adapter.
>>
>>
>> Alle HM-Komponenten erscheinen unterhalb von CUL_HM.
>>
>>
>> Leider habe ich keine Beschreibung ähnlicher Konfigurationen gefunden.
>> Es sieht für mich so aus, als würde der Betrieb auch funktionieren.
>>
>>
>> Meine Frage : Ist das tatsächlich so dauerhaft nutzbar bzw. vorgesehen ?
>>
>>
>> Um eine flächendeckende Funkversorgung zu erhalten plane ich evtl. einen dritten LAN-Adapter zu installieren.
>> Daher vorbeugend die Frage, ob ich hier das Design breche. Oder sollte ich besser die HM-Repeater in der Zwischenstecker-Bauform einsetzen ?
>> Es sollen 8-10 Wandthermostate folgen + Diverse Schaltaktoren.
>>
>>
>> Viele Grüße,
>> Sven

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

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

meines Wissens nach funktionieren die hmlans nur in Verbindung mit der Zentrale ccu 1 als Repeater  und du brauchst 2Stück davon.
Repeater hat auch den Nachteil, dass Funktelegramme doppelt gesendet werden, inkl. Bestätigungen usw.

VG


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

[Guest]

Originally posted by: <email address deleted>

Also ich habe keine 2 Adapter. Mir ist nicht klar ob die sich 'absprechen'.

Was ich erwarte ist
1) Empfangen von Nachrichten
- beide LAN-adapter werden die Nachricht empfangen und weiterleiten. FHEM
wird duplicate messages loeschen - somit parsen wir jeden Nachricht nur
einmal -> sollte also kein Problem sind
2) Nachrichten senden
ein device sendet ueber einen LAN adapter. Ich denke es ist immer der
selbe, habe noch keine Dynamik gesehen. Dies sollte man natuerlich nicht
dem Zufall ueberlassen. Mir ist aber nicht bekannt, dass es eine
automatische Einstellung auf Basis der Empfangsstärke gibt, noch dass der
User es einstellen kann.
==> hier brauch man demnach noch etwas code, sonst bringt es beim senden
zufallsergebnisse
3) Nachrichten an die HM-ID
Nachrichten, die an fhem gesendet werden, also an die HMid den/der lan
adaper werden ggf vom LAN adapter quittiert - sprich der LAN adapter sendet
ACKs.  Es sollte nach Moeglichkeit nur ein Adapter quittieren. Ich habe es
noch nicht getestet, aber ich vermute es wird jeder adapter quittieren, der
schon einmal (seit seinem letzten restart) an das device gesendet hat. Dies
hat mit den Protokoll zwischen FHEM und HMLAN zu tun.
==> dies sollte also auch funktionieren, vorausgesetzt man sendet immer
ueber den gleichen Adapter.

Also - zusammenfassung zur realisierung aus meiner sicht
a) im Augenblick funktioniert es nicht richtig, da man das sende-HMLAN
nicht festlegen kann
b) um dies steuerbar zu machen muesste ein Attribut oder ein kommando
generiert werden - ich denke in attribut ist schon vorgesehen, aber noch
nicht funktionell
c) im ersten Ansatz muss der User die Zuordnung von hand machen. ein
Automatismus ist komplexer

Falls es jemand im Einsatz hat - wie hat er die Details oben geloest?


 Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Vielen Dank für das Feedback an Alle !


Nach ein paar Stunden Beobachtung habe ich festgestellt, daß die
Schaltaktoren auf state "MISSING ACK" gehen, vermutlich mangels Pairing mit
dem zweiten LAN-Adapter auf der zweiten ID. Die LAN-Adapter liegen nicht
weit genug auseinander, um einen zufällig überschneidenden Empfang
auszuschließen.

Nach Eurem Feedback habe ich die Reihenfolge der Initialisierung in der cfg
geändert.
Vorher hatte ich zunächst beide LAN-Adapter, dann die Geräte. Nun jeweils
den Adapter gefolgt von den Geräten, die auf angelernt sind.
Die hmid habe ich unterschiedlich auf beiden LAN-Adaptern belassen.
Zusätzlich habe ich den Geräten noch ein "attr IODev" für HMLAN1 bzw.
HMLAN2 gegeben.

Da ich zunächst nur eine statische Zuordnung benötige, sieht das für mich
nach einem guten ersten Ansatz aus.
Interessant wird es, wenn mobile Handsender dazu kommen. Hier wäre eine
Funktion über alle Adapter natürlich besser.
Aber so weit bin ich in meinem Aufbau noch nicht.

Eine Verständnisfrage noch :
Solange ich die Geräte per IODev festlege und unterschiedliche hmids auf
den HMLANs nutze, ist die Zuordnung fest und es sollte nicht zu
überkreuzenden ACKs der LAN-Adapter kommen, richtig ?

Vielen Dank nochmal und Gruss,
Sven

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

[Guest]

Originally posted by: <email address deleted>

Am Mittwoch, 5. Dezember 2012 07:57:51 UTC+1 schrieb Sven:
>
> Vielen Dank für das Feedback an Alle !
>
>
> Nach ein paar Stunden Beobachtung habe ich festgestellt, daß die
> Schaltaktoren auf state "MISSING ACK" gehen, vermutlich mangels Pairing mit
> dem zweiten LAN-Adapter auf der zweiten ID.
>
Die LAN-Adapter liegen nicht weit genug auseinander, um einen zufällig
> überschneidenden Empfang auszuschließen.
>
> Nach Eurem Feedback habe ich die Reihenfolge der Initialisierung in der
> cfg geändert.
> Vorher hatte ich zunächst beide LAN-Adapter, dann die Geräte. Nun jeweils
> den Adapter gefolgt von den Geräten, die auf angelernt sind.
>
das kann etwas bringen - aber wenn, dann nur beim Senden.  Kannst du testen
indem du die Zaehler des LAN interface pruefst - oder einfach einen der
HMLAN abziehst. Ein automatisches Umschalten sollte nicht erfolgen.

Die hmid habe ich unterschiedlich auf beiden LAN-Adaptern belassen.
> Zusätzlich habe ich den Geräten noch ein "attr IODev" für HMLAN1 bzw.
> HMLAN2 gegeben.
>
aendert sich da etwas? Ich denke nicht, dass hier code hinterlegt ist.

>
> Da ich zunächst nur eine statische Zuordnung benötige, sieht das für mich
> nach einem guten ersten Ansatz aus.
> Interessant wird es, wenn mobile Handsender dazu kommen. Hier wäre eine
> Funktion über alle Adapter natürlich besser.
> Aber so weit bin ich in meinem Aufbau noch nicht.
>
Bei Handsendern kann man es etwas gelassener sehen. Wie beschrieben wird
von allen gleichzeitig empfangen - also sollte die Zentrale den Befehl
mitbekommen.
Auf der anderen Seite muss man selten etwas an den Handsender schicken
(Ausnahme RC19 mit dem Display).  Bei ACKs kommt es auf das peering an.
Wenn du mit dem schalter peers ist der Adapter nur monitor. Somit reduziert
sich das Problem auf das peering mit der Zentrale und dem virtuellen
devices.
Hier ist es von vorteil wenn du beide LAN adapter mit der gleichen ID
laufen laesst. Dann sollte das ack automatisch  aus dem Adapter kommen....
evtl muss man in der Config noch etwas aendern.

>
> Eine Verständnisfrage noch :
> Solange ich die Geräte per IODev festlege und unterschiedliche hmids auf
> den HMLANs nutze, ist die Zuordnung fest und es sollte nicht zu
> überkreuzenden ACKs der LAN-Adapter kommen, richtig ?
>
1) ich denke nicht, dass das "Attribut" IODev Auswirkungen hat. es gibt
einen Parameter IOdev der dem hash zugeordnet ist und den hash den IODev
beinhaltet. Der ist wichtig. Du solltest mit "list" nachsehen koennen,
welcher hash eingetragen ist - jedenfalls ob es die selben oder
unterschiedliche nummern sind.
wenn du kein Attribut IODev hast solltest du den parameter mit "get
param IODev" lesen koennen. Ausgegeben wird der erste treffer
aus attribut, readings, hash-> oder helper.
==> ich denke hier sollte noch etwas nachkodiert werden um die Auswahl des
Sendedevice einstellen zu koennen
2) einfache ACKs kommen von LAN adapter autonom. Dies wird nach Empfang
einer Nachricht automatisch freigeschaltet. Evtl kannst du die Acks des
ersten mit dem 2. Adapter sehen.

Evtl einfach einmal aufzeichnen (nur HMLAN messages) und beschreiben, was
passiert ist. Liste der HMIDs beifuegen.

Gruss
Martin

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

[rudolfkoenig]

                                                   

> 1) ich denke nicht, dass das "Attribut" IODev Auswirkungen hat.

Doch.

Bei der Definition von sog. logischen Geraeten (FS20/HM/etc) wird AssignIoPort
aufgerufen. Dieser sucht nach dem zuletzt definierten Geraet, der als
Ausgabegeraet fungieren kann, und setzt diesen als IODev (hash Eintrag, fuer
den Endanwender nicht sichtbar).

Der Benutzer kann diesen mit dem Attribut IODev bestaetigen oder aendern, beim
setzen dieses Attributes wird der unsichtbare hash Eintrag gesetzt.

Im Modul sollte man sinnvollerweise IOWrite() verwenden, um Daten an das
logische Geraet zu senden, diese Funktion gibt die Daten an dem per IODev
zugeordneten Geraet (CUL/HMLAN/etc) weiter.

Im HM Kontext waere sinnvoll fuer Fernbedienungen das IODev dynamisch auf das
letzte Empfaenger zu setzen, evtl. unter Beachtung der RSSI. Hoert sich
einfacher an, als es ist.

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

[Guest]

Originally posted by: <email address deleted>

ohne die vorgeschlagenen Tests von Martin schon ausgeführt zu haben, kann
ich bestätigen, daß sich zumindest in den LOGs ein Unterschied zeigt.

Ein Schalter einer an einer E-Heizung der mittels HCS per Wandthermostat
gesteuert wird meldete sich vor Installation des zweiten HMLAN mit :

2012-12-03_10:55:21 CUL_HM_switch_1A5F34 set_on-for-timer 130
2012-12-03_10:55:22 CUL_HM_switch_1A5F34 CommandAccepted: yes
2012-12-03_10:55:22 CUL_HM_switch_1A5F34 deviceMsg: on (to HMLAN1)
2012-12-03_10:55:22 CUL_HM_switch_1A5F34 on

Nachdem beide HMLAN direkt hintereinander initialisiert wurden, ohne
gesetztes IODev :

2012-12-05_07:24:33 CUL_HM_switch_1A5F34 MISSING ACK
2012-12-05_07:25:29 CUL_HM_switch_1A5F34 set_on-for-timer 130
2012-12-05_07:25:35 CUL_HM_switch_1A5F34 MISSING ACK
2012-12-05_07:26:30 CUL_HM_switch_1A5F34 set_on-for-timer 130

Mit gesetztem IODev und Initialisierung nach
LAN-Adapter,Devices,LAN-Adapter, Devices :
2012-12-05_08:26:57 CUL_HM_switch_1A5F34 set_on-for-timer 130
2012-12-05_08:26:57 CUL_HM_switch_1A5F34 CommandAccepted: yes
2012-12-05_08:26:57 CUL_HM_switch_1A5F34 deviceMsg: on (to A8DB6D)
2012-12-05_08:26:57 CUL_HM_switch_1A5F34 on
2012-12-05_08:27:57 CUL_HM_switch_1A5F34 set_on-for-timer 130
2012-12-05_08:27:58 CUL_HM_switch_1A5F34 CommandAccepted: yes
2012-12-05_08:27:58 CUL_HM_switch_1A5F34 deviceMsg: on (to A8DB6D)
2012-12-05_08:27:58 CUL_HM_switch_1A5F34 on

die deviceMsg lösen nun die hmid auf, anstelle des HMLAN.
sieht soweit ganz gut aus.

btw: HCS war zwar eigentlich anders gedacht, ist aber perfekt für die
Steuerung von Elektroheizkörpern auch pro Raum (wenn man die per ignore
jeweils nur das lokale Wandthermostat referenziert). Vielen Dank dafür. Das
ersetzt das alte FS20-Set aus Wandthermostat + Zwischenstecker.

VG,
Sven

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

[Guest]

Originally posted by: <email address deleted>

Rudi hat sicher recht bei dem Mechanismus.

es bei Fernbedienungen an den zuerst empfangenen zu koppeln ist einfach -
sagt aber nichts ueber die Empfangsleistung aus - und ist daher reiner
Zufall. Und wieder hat Rudi recht,  die Empfansleistung auszuwerten ist
etwas komplexer, da  hier erst ein Senderpool aufgemacht werden muesste, es
muesste auf evtl eintreffende Nachrichten des 2. HMLAN gewartet werden...



> ohne die vorgeschlagenen Tests von Martin schon ausgeführt zu haben, kann
> ich bestätigen, daß sich zumindest in den LOGs ein Unterschied zeigt.
>
>
> die deviceMsg lösen nun die hmid auf, anstelle des HMLAN.
> sieht soweit ganz gut aus.
>
Die devicemessage loest immer die HMID auf und ersetzt es mit dem Namen.  
Die Namensaufloesung funktioniert nicht komplett bei mehreren IO-devices,
das geht nur bedingt. Ich durchsuche nicht alle IO-devices nach deren
Namen, nur das aktuell eingetragene.
Dies hier betrifft die ACK-status und reflektiert quasi das sendedevice.
Bei Aktoren sollte noch eine INFO_STATUS an die Zentrale kommen. Hier musst
du aufpassen, welchen du pairst.  - dieser schickt die ACKs. Das kann so
nicht sauber funktionieren - und sehen kannst du es auf diesem Level kaum,
da musst du tiefer schauen.

Gruss
Martin

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

[Zrrronggg!]

                                                     

So richtig schlau werde ich aus den Antworten nicht nicht.

Ich wollte irgendwann mal einen 2ten HMLAN einsetzen, aber nicht wegen
Reichweite, sondern wegen dem Signing-Request.

Ich betreibe meinen HMLAN ohne Signing-Request ("AES-Encryption"),
wollte aber irgendwann mal (HM)Keymatic einsetzen und die erfordert ja
wohl das einschalten der "AES-Encryption".

Ich plante dazu einfach einen 2. HM LAN Adapter mit anderer ID
einzubinden und dann per IOdev den sendenden Adapter festzulegen, der
natürlich der ist, an den das jeweilige Gerät gepairt ist.

Ich muss zugeben, ich habe noch nicht verstanden, ob das nun gehen
würde oder nicht.




On 5 Dez., 16:10, Martin wrote:
> Rudi hat sicher recht bei dem Mechanismus.
>
> es bei Fernbedienungen an den zuerst empfangenen zu koppeln ist einfach -
> sagt aber nichts ueber die Empfangsleistung aus - und ist daher reiner
> Zufall. Und wieder hat Rudi recht,  die Empfansleistung auszuwerten ist
> etwas komplexer, da  hier erst ein Senderpool aufgemacht werden muesste, es
> muesste auf evtl eintreffende Nachrichten des 2. HMLAN gewartet werden...
>
> > ohne die vorgeschlagenen Tests von Martin schon ausgeführt zu haben, kann
> > ich bestätigen, daß sich zumindest in den LOGs ein Unterschied zeigt.
>
> > die deviceMsg lösen nun die hmid auf, anstelle des HMLAN.
> > sieht soweit ganz gut aus.
>
> Die devicemessage loest immer die HMID auf und ersetzt es mit dem Namen.
> Die Namensaufloesung funktioniert nicht komplett bei mehreren IO-devices,
> das geht nur bedingt. Ich durchsuche nicht alle IO-devices nach deren
> Namen, nur das aktuell eingetragene.
> Dies hier betrifft die ACK-status und reflektiert quasi das sendedevice.
> Bei Aktoren sollte noch eine INFO_STATUS an die Zentrale kommen. Hier musst
> du aufpassen, welchen du pairst.  - dieser schickt die ACKs. Das kann so
> nicht sauber funktionieren - und sehen kannst du es auf diesem Level kaum,
> da musst du tiefer schauen.
>
> Gruss
> Martin

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

[Guest]

Originally posted by: <email address deleted>

deine Aussage jetzt wrift ein anderes Licht  auf deinen Anwendung. Im
ersten Ansatz hab ich verstanden, dass du es fuer die rechweite brauchst
und dass du  mit deiner Fernbedienung ueber beide HMLAN bedient werden
willst.

Der jetzige Ansatz sieht (oder sollte sehen) eine strikte Trennung zwischen
den beiden Funkwelten vor. Jedes device wird einem HMLAN zugewiesen und
diese beiden haben dann auch andere IDs - so habe ich es jetzt verstanden.
Einer vn beiden soll AES unterstuetzen.

Das macht die Sache relativ einfach - wenn das mit den IO-devices
funktioniert wie von Rudi beschrieben (und er hat sicher recht) sollte es
mit den Protokoll auch klappen. Es gibt verschiedene codeteile in denen die
"Zentrale" behandelt wird. Du hast dann je device eine von 2 Zentrale...
sollte auch funktionieren. Du musst aber alle peers und pairings korrekt
einstellen - besser nicht mischen in einem Device!

Anmerkung zu AES (habe ich noch nicht probiert...) aberevtl hast du ein den
peering inforamtionen der Sender gesehen, dass je peer eingestellt werden
kann, ob der peer AES benoetigt. Ist in den Registern List4 der Sender
einzuschalten - falls du peer2peer schalten willst.

Gruss
Martin

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