CUL durch HMLAN ersetzen - bestehendes Pairing und bestehende hmId

kossmann · 14 Januar 2013, 14:32:55

Hallo zusammen,

da ich für KeyMatic ja zwingend ein HMLAN benötige und ein solches nun zu mir unterwegs ist, würde ich in Zukunft gerne alle HM-Geräte per HMLAN ansteuern.

Wie gehe ich am besten vor?

Kann ich das HMLAN einfach mit identischer hmId definieren und muss dann in der Definition der Aktoren nur HMLAN statt CUL nutzen/ändern? Also z.B.

Code Auswählen

define MyCUL CUL /dev/ttyACM0@9600 0000
attr MyCUL hmId 123456
attr MyCUL rfmode HomeMatic

define MyHMLAN HMLAN 192.168.1.2:1000
attr MyHMLAN hmId 123456

Müssen die Aktoren normalerweise nicht erst mit dem HMLAN gepairt werden? Wie funktioniert sonst das Setzen irgendwelcher Parameter in den Aktoren mittels HomeMatic-Software bzw. HMLAN-Webinterface?

Wenn letzteres nötig ist, kann ich die hmId im HMLAN irgendwie fest vorgeben (ich hätte gerne eine ganz bestimmte)?

Samsi · 14 Januar 2013, 15:48:07

Wenn Du das über die Windows Software konfigurieren willst, musst Du es auf jeden Fall auch mit der Windows Software pairen, sonst ist das Gerät dort nicht sichtbar. Du solltest dann in FHEM dieselbe HMID wie in der Windows Software verwenden, damit du nicht jedes mal neu pairen musst, wenn du zwischen Windows und FHEM wechselst.

Du kannst vermutlich auch die HMID in der Windows Software setzen (hab ich allerdings noch nie ausprobiert). Jedenfalls steht diese nach der Installation in C:\ProgramData\Bidcos-Service\ids , allerdings in dezimal. Also erst mit dem Taschenrechner von HEX nach Dezimal umrechnen.

Ob Du unter FHEM mit CUL und HMLAN gleichzeitig die selbe HMID verwenden kannst, weiss ich leider auch nicht, meine Vermutung ist aber das es nicht geht, weil sonst evtl. beide adapter (CUL und HMLAN) versuchen auf einen Funkbefehl zu antworten.

kossmann · 14 Januar 2013, 16:29:42

Werden die Aktoren mit der Windows-Software oder dem HMLAN gepairt? Ich blicke da noch nicht so ganz durch. Wenn es die Windows-Software ist, wäre die Weboberfläche des HMLAN ja ohne Funktion, oder?

Ich möchte eigentlich in Zukunft nur HMLAN statt CUL nutzen und später die KeyMatic anlernen und nutzen. Reicht dafür o.a. vorgehen (ggf. mit Ändern der CUL-Konfiguration zu SlowRF o.ä.)? Wenn ich dann zusätzlich über das Webinterface des HMLAN noch das ein oder andere Einstellen kann, wäre es noch besser.

Samsi · 14 Januar 2013, 17:07:42

Hallo,

beim Pairen mit der Windows Software passiert eigentlich folgendes: die HMID die auch in der Datei ids zu finden ist, wird in den Aktor geschrieben und gleichzeitig wird im HMLAN adapter die HMID gespeichert.
Wenn Du die Windows Software dann ausschaltest, ist das HMLAN immer noch in der Lage empfangen Befehle zu quittieren weil es die HMID noch behält (auch wenn keine Software mehr läuft, die auf irgend etwas reagieren könnte). Das erkennt man daran, das z.B. die Tür Fenster Kontakte die Quittung empfangen und kurz grün leuchten.
Startest Du jetzt FHEM mit einer anderen HMID, dann wird diese andere HMID in das HMLAN Gerät geschrieben, und dann schlägt die Kommunikation zwischen Sender und HMLAN fehl, weil der Sender ja an ein HMLAN Gerät mit einer anderen HMID sendet, sprich dein HMLAN fühlt sich nicht mehr angesprochen. Die Fensterkontakte bekommen dann z.B. keine Quittung mehr und leuchten rot (nachdem sie es mehrmals probiert haben)

Startest Du FHEM hingegen mit der gleichen HMID wie in der Windows Software funktioniert alles weiterhin. Du kannst also ständig zwichen Windows und FHEM wechseln (aber niemals gleichzeitig, also wenn der Windows Manager läuft darf FHEM nicht auf das HMLAN zugreifen und umgekehrt, ich mache das in dem ich das HMLAN define kurz auskommentiere)

Wenn Du den CUL gar nicht mehr benutzen willst, dann würde ich testweise den CUL aus dem define raus nehmen und das HMLAN mit der gleichen HMID definieren, dann sollten alle bisherigen Aktoren schon direkt mit dem HMLAN kommunizieren, wenn ich mich nicht irre.
Wenn nicht, dann definierst Du den CUL wider und nimmst den HMLAN raus, dann ist alles wie vorher (und meine Antwort war falsch :).

Bei neuen Aktoren mache ich immer folgendes: Ich paire den Aktor mit der Windows Software (damit er dort erst mal in der liste steht, wie autocreate bei FHEM) und stelle alles ein wie ich es brauche. Dann paire ich ihn einfach noch mal mit FHEM mit der gleichen HMID, damit er dort auch per autocreate eingetragen wird.

kossmann · 14 Januar 2013, 17:11:14

Dann werde ich hoffentlich auch folgendes machen können:

Software installieren, die umgerechnete hmId in die Datei schreiben und dann erst starten

Ich möchte ja gerne (aus persönlichen Gründen) meine hmId behalten ;-) Ich werde es morgen (oder übermorgen) einfach mal ausprobieren.

Samsi · 14 Januar 2013, 17:20:48

Ja, die HMID zu übernhemen macht auch Sinn, denn so musst Du nicht alle Aktoren erneut in FHEM anlernen.

Aber ich würde trotzdem erst den CUL mal deaktivieren und das HMLAN mit der HMID vom CUL einbinden und schauen ob alles noch funktioniert wie vorher. Wenn ja, hast Du die wichtigste Hürde ja schon genommen. Und dann brauchst Du die Windows Software ja nur wenn Du die Geräte darüber konfigurieren willst, das kann man ja dann nach und nach machen. In der Regel ist eine Konfiguration über die Windows Software nicht nötig, aber manchmal einfacher insbesondere wenn man die Möglichkeiten noch nicht alle kennt, insbesondere im Expertenmodus.

kossmann · 17 Januar 2013, 10:56:27

Das war alles easy - man muss nichts unpairen. Wenn ich nichts vergessen habe oder durch die "/&§%"-Windows-Software einen Schritt übersehen habe, sollte es eigentlich wie folgt gehen:

Grundsätzlich:
- Die Netzwerkkonfiguration des HMLAN unter Windows durchführen ("Hilfsprogramme - HomeMatic-Lan-Interface konfigurieren") (AES deaktivieren, IP-Adresse oder DHCP setzen), Software beenden
- HMLAN in FHEM mit alter hmId definieren, CUL deaktivieren (oder anderen rfmode setzten), FHEM neu starten (hierbei wird die hmId in´s HMLAN geschrieben)

Sollen die Devices auch unter Windows zu konfigurieren sein:
- FHEM beenden (oder HMLAN deaktivieren)
- HMLAN Software starten ("HomeMatic-Komponenten konfigurieren") und HMLAN finden lassen (hier sollte die hmId ausgelesen werden) - hier kann es sein, dass der AES-Schlüssel leer bleiben muss (wurde ja deaktiviert), da bin ich aber nicht sicher, habe es mehrmals probiert
- Anlernen über die Seriennummer, das normale Anlernen hat nicht funktioniert
- Ggf. Einstellungen vornehmen, Software beenden
- FHEM starten (oder HMLAN aktivieren)

Das ganze scheint nur über hmId und Seriennummer zu funktionieren, daher ist ein erneutes Pairing nicht notwendig, solange alle Beteiligten die selbe hmId verwenden

Samsi · 17 Januar 2013, 23:44:07

Zitat von: kossmann schrieb am Do, 17 Januar 2013 10:56- HMLAN Software starten ("HomeMatic-Komponenten konfigurieren") und HMLAN finden lassen (hier sollte die hmId ausgelesen werden) - hier kann es sein, dass der AES-Schlüssel leer bleiben muss (wurde ja deaktiviert), da bin ich aber nicht sicher, habe es mehrmals probiert

Wenn die AES verschlüsselte Verbindung deaktiviert ist, muss AES in der Software definitiv Leer bleiben, sonst geht es nicht.

Zitat von: kossmann schrieb am Do, 17 Januar 2013 10:56- Anlernen über die Seriennummer, das normale Anlernen hat nicht funktioniert

Interessant, damit hatte ich noch nie Probleme. Bei mir funktionieren beide Methoden.

Zitat von: kossmann schrieb am Do, 17 Januar 2013 10:56Das ganze scheint nur über hmId und Seriennummer zu funktionieren, daher ist ein erneutes Pairing nicht notwendig, solange alle Beteiligten die selbe hmId verwenden

Und wie bekommst Du dann Deine Geräte-Einträge in FHEM wenn das Gerät noch nie mit FHEM gepaart war? Also ich muss die immer noch mal mit FHEM pairen, damit die neuen Geräte mit Autocreate erstellt werden. Wäre mir auch lieber wenn das ohne erneute pairen gehen würde, vielleicht kannst Du mir erklären wie Du das bei neuen Geräten machst. Ich nehme nicht an das Du sie mühsam mit der Hand manuell anlegst ;)

Und noch ein Tipp: In dem Bidcos Ordner liegen auch XML Dateien mit allen angelernten Geräten. Die würde ich ab und zu sichern, wenn Du mal Dein Windows neu installierst müsstest Du damit alle Geräte wieder in die Konfigurationssoftware bekommen ohne das Du sie alle erneut anlernen musst.

kossmann · 18 Januar 2013, 08:59:02

Die Aktoren waren vorher in FHEM angelernt (über CUL, welches ja durch HMLAN ersetzt werden sollte) und in eigenen Konfigurationsdateien definiert, welche per inculde eingebunden werden. Daher kannte FHEM die Aktoren weiterhin ohne neues Pairing. Ob dies auch der Grund war, dass ein automatisches Pairing an HMLAN nicht funktioniert hat, kann ich nicht beurteilen (der Aktor kannte die hmId ja schon / ist das automatische Pairing vielleicht ein "Hallo, ich bin die Zentrale mit der hmId x und wer möchte alles zu mir?" und das über die Seriennummer ein "Hallo Gerät y, zu gehörst ab sofort zu mir!").

Wie ich in Zukunft neue Geräte aufnehme, weiß ich auch noch nicht. Wahrscheinlich erst mal ein autocreate in FHEM und anschließend (bei angehaltenem FHEM-Dienst) wieder über die Seriennummer in die Windows-Software.

Der devices-Ordner mit den Geräten ist natürlich schon gesichert ;-)

martinp876 · 18 Januar 2013, 09:36:24

habe den Thread nicht verfolgt. Einfach einmal ein tip, hoffentlich nicht komplett daneben

wenn ich zwischen HMLAN und CUL hin und her schalte funktioniert dies ohne Probleme. Zu beachten ist:
- das IO device im fhem-config MUSS VOR den Actoren stehen
- ich verwende nur eine HMID fuer CUL und HMLAN (ausser in spezialfaellen)
- im Parallel-betrieb ist mit doppelten messages zu rechnen und das sende-device sollte definiert werden

Gruss,
Martin

Samsi · 18 Januar 2013, 10:38:51

Zitat von: kossmann schrieb am Fr, 18 Januar 2013 08:59Die Aktoren waren vorher in FHEM angelernt (über CUL, welches ja durch HMLAN ersetzt werden sollte) und in eigenen Konfigurationsdateien definiert, welche per inculde eingebunden werden. Daher kannte FHEM die Aktoren weiterhin ohne neues Pairing. Ob dies auch der Grund war, dass ein automatisches Pairing an HMLAN nicht funktioniert hat, kann ich nicht beurteilen (der Aktor kannte die hmId ja schon / ist das automatische Pairing vielleicht ein "Hallo, ich bin die Zentrale mit der hmId x und wer möchte alles zu mir?" und das über die Seriennummer ein "Hallo Gerät y, zu gehörst ab sofort zu mir!").

Wie ich in Zukunft neue Geräte aufnehme, weiß ich auch noch nicht. Wahrscheinlich erst mal ein autocreate in FHEM und anschließend (bei angehaltenem FHEM-Dienst) wieder über die Seriennummer in die Windows-Software.

Der devices-Ordner mit den Geräten ist natürlich schon gesichert ;-)

#kossman:
Ich hab auch schon Geräte automatisch gepaart die schon mal in FHEM angemeldet waren, daran sollte es nicht liegen.

#martin876
Das ist in Ordnung. Ist im Prinzip eine korrekte Zusammenfassung was wir hier besprochen haben.
Die frage ist nur noch, kann man irgendwie die Aktoren (welche man in der Wiindows Software schon geppaart hat) in FHEM automatisch erstellen lassen (autocreate) oder muss man neue Aktoren immer erst 2x pairen, einmal mit der Windows Software und einmal mit FHEM.

kossmann · 18 Januar 2013, 11:33:56

Zitat von: Samsi schrieb am Fr, 18 Januar 2013 10:38Die frage ist nur noch, kann man irgendwie die Aktoren (welche man in der Wiindows Software schon geppaart hat) in FHEM automatisch erstellen lassen (autocreate) oder muss man neue Aktoren immer erst 2x pairen, einmal mit der Windows Software und einmal mit FHEM.

Wenn ich mir ein BidCos-Device-XML ansehe, könnte man aus der ersten Zeile einen FEHM-define-Block bauen. Da müsste man nur eine BidCos-Import-Funktion bauen, die das macht.

Code Auswählen

<device serial="JEQ01166xx" type="HM-LC-Bl1PBU-FM" address="0x1BCD08" aes_key_index="0" firmware_version="2.1" bidcos_interface="JEQ01858yy" sysinfo="0080001BCD0820331721006A4A45513031313636353730010100">

wird zu

Code Auswählen

define <Name> CUL_HM 1BCD08
attr <Name> devInfo 010100
attr <Name> firmware 2.1
attr <Name> hmClass receiver
attr <Name> model HM-LC-Bl1PBU-FM
attr <Name> serialNr JEQ01166xx
attr <Name> subType blindActuator

Die fehlenden Daten (devInfo, hmClass, subType) werden wahrscheinlich sowieso von FHEM selbst gesetzt, oder?

martinp876 · 18 Januar 2013, 12:34:38

nun - ist das nicht schon drin?

Gut ist, wenn man die HMIDs der devices hat (kann man evtl mitlesen). Dann:
define <name> CUL_HM <HMID>
>Anlernen druecken ==> fertig
==> es werden alle notwengiden Attribute gesetzt
==> es werden alle Kanaele angelegt

dann erst einmal ein "save" (wenn alle drin sind).

Nun wuerde ich die Device Konfiguration sichern. Dazu kann man
- manuell ein getConfig auf alle devices machen (kanaele sind nicht notwendig)
oder (so mache ich es bei non-config devices)
- automatik einstellen - so dass bei jedem FHEM restart die Konfigurationsdaten ausgelesen werden. Hierzu muss das Attribut autoReadReg auf '1' gesetzt werden (sinnvoll nur in den devices).
Nach einem fhem restart werden - zeitlich gestaffelt- alle devices gelesen.

Und dann erst einmal speichern - und zwar die HM-devicedaten mit get <name> saveConfig

Im Ernstsfall kann man nun alle settings wieder zurueckspielen.

Anmerkung: Devices die nur auf 'config' reagieren sollte man manuell auslesen, nicht mit der automatic.

Gruss
Martin

Rohan · 18 Januar 2013, 23:19:32

Hi,

Zitat von: martinp876 schrieb am Fr, 18 Januar 2013 12:34... Dazu kann man
- manuell ein getConfig auf alle devices machen...

Rückgabe:

Code Auswählen

Unknown command getconfig, try help

Das mit dem Attribut setzen funktioniert, nur eben das getConfig auf dasselbe HM-Device eben nicht.

Wie lautet die komplette Syntax bzw. ab welcher Version ist dies vorhanden oder wo liegt sonst mein Fehler?

Danke und Gruß
Thomas

Fennek · 19 Januar 2013, 00:10:48

Moin Thomas,

wenn Du den Automodus ( autoReadReg ) auf 1 gesetzt hast werden beim nächsten
Start oder restart von fhem die Devices ausgelesen wo Du es eingestellt hast.

hier ein Stück von meinem Log, dadurch siehst Du das getConfig schon ausgeführt wurde.

2013.01.18 21:54:56 2: CUL_HM set WZ_Thermostat getConfig rxt:12
2013.01.18 21:54:56 2: CUL_HM set WZ_Thermostat statusRequest rxt:12
2013.01.18 21:55:11 2: CUL_HM set WZ_HZ_Antrieb getConfig rxt:12
2013.01.18 21:55:12 2: CUL_HM set WZ_HZ_Antrieb statusRequest rxt:12
2013.01.18 21:55:27 2: CUL_HM set WZ_Tuersensor getConfig rxt:12
2013.01.18 21:55:27 2: CUL_HM set WZ_Tuersensor statusRequest rxt:12
2013.01.18 21:55:42 2: CUL_HM set WZ_Dim_a getConfig rxt:1
2013.01.18 21:55:42 2: CUL_HM set WZ_Dim_a statusRequest rxt:1
2013.01.18 21:55:57 2: CUL_HM set KUE_Thermostat getConfig rxt:12
2013.01.18 21:55:57 2: CUL_HM set KUE_Thermostat statusRequest rxt:12
2013.01.18 21:56:12 2: CUL_HM set KUE_Antrieb getConfig rxt:12
2013.01.18 21:56:12 2: CUL_HM set KUE_Antrieb statusRequest rxt:12

manuell geht das mit set <Device Name> getConfig
um zu speichern get <name> saveConfig <FileName> in der Komandozeile von fhem eingeben und <ENTER>
z.Bsp get KUE_Thermostat saveConfig KUE_TH
der File wird dann im modpath abgelegt.
Was noch zu beachten ist, nicht ungeduldig werden die TC's brauchen bis zu 4min für getConfig.

Rohan · 19 Januar 2013, 14:46:58

Hallo Andreas,

herzlichen Dank für deine Antwort!

(bitte sehe es mir nach, dass ich nicht auf +1 klicke, aber ich mach bei dem offenkundigen Blödsinn nicht mit).

Dank deiner Hinweise habe ich von mir ins Wiki eingetragene Fehler korrigieren können, nicht aber die Fehler in meinem System, denn ich erhalte von allen 6 HM-CC-TCs mit eingestelltem autoReadReg 1 nur TimeOuts und auf set <HM-CC-TC> getConfig nur "MISSING ACK"s. update development gerade erst gefahren mit anschließendem shutdown restart.

Aber ich will diesen Thread nicht highjacken, deshalb werde zu gegebener Zeit (wenn ich durch suchen und lesen nicht zu einer Lösung komme) hier einen eigenen Thread dazu eröffnen.

Deshalb nur eine Frage dazu: Wie stehen bei deinen HM-CC-TCs "verbose" und "loglevel" und nutzt du CUL oder HMLAN-Konfigurator (ja, ich weiß, sind 3 Fragen ;) )?

Gruß
Thomas