Probleme mit dem Pairen

Marcel_R · 11 Januar 2014, 12:04:47

Grüezi

Meine FHEM-Version ergab beim Check mit HMinfo -> configCheck viele Unstimmigkeiten. Deshalb habe ich von Grund auf Raspi und FHEM und die HM-Devices neu aufgesetzt (basierend auf dem Busware Image).

Als einzige Komponente habe ich den CUL mit

Code Auswählen

define CUL0 CUL /dev/ttyACM0@9600 2345
attr CUL0 rfmode HomeMatic

selber definiert.

Trotzdem erscheinen sämtliche bisher konfigurierten HM-Devices im HMinfo -> configCheck als

ZitatPairedTo missmatch to IODev
FE1KuecheN paired:0xF12345 IO attr: -
FE1KuecheW paired:0xF12345 IO attr: -
FE_TreppeO paired:0xF12345 IO attr: -
FE_TreppeW paired:0xF12345 IO attr: -
FE_WC_ paired:0xF12345 IO attr: -
FO1BadN paired:0xF12345 IO attr: -
FO1BadW paired:0xF12345 IO attr: -
FO1ElternO paired:0xF12345 IO attr: -
FO1ElternS paired:0xF12345 IO attr: -
FO1Gang_ paired:0xF12345 IO attr: -
FO1NaomiS paired:0xF12345 IO attr: -
FO1NaomiW paired:0xF12345 IO attr: -
FU1RaO paired:0xF12345 IO attr: -
FU1RaW paired:0xF12345 IO attr: -
FU1Sauna_ paired:0xF12345 IO attr: -
FU_EntreeN paired:0xF12345 IO attr: -
FU_EntreeS paired:0xF12345 IO attr: -
SE_WZ paired:0xF12345 IO attr: -

Ich habe in der fhem.cfg kein Device mit HM ID 12345.

Zitat6stellige HM ID (3 Byte hex) die aus dem FHEM log ermittelt werden kann. Die Nummer
ist von Hersteller für jedes Gerät unveränderlich vorgegeben.

Im LOG finde ich ein mal die Zeichenkombination "12345"

Zitat2014.01.11 00:07:16 2: CUL_MAX_SendQueueHandler: Missing ack from 049f71 for 0b010001123456049f710000

Welches ist die richtige HM ID?

Ist diese Installation noch zu retten?

Danke und Gruss

Marcel

fhem.cfg:

Code Auswählen

attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global mseclog 1
attr global sendStatistics manually
attr global statefile ./log/fhem.save
attr global userattr devStateIcon devStateStyle fp_EG fp_OG fp_UG icon sortby webCmd
attr global verbose 3

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB 
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots

# Disable this to avoid looking for new USB devices on startup
# define initialUsbCheck notify global:INITIALIZED usb create


# If the above notify did not helped, then you probably have to enable some of
# the following lines.  Verify first that /dev/xxx ist correct.

#define FHZ FHZ /dev/USB0

define CUL0 CUL /dev/ttyACM0@9600 2345
attr CUL0 rfmode HomeMatic

#define EUL TCM 310 /dev/ttyACM0@57600
#define BscBor TCM 120 /dev/ttyUSB0@9600
#define BscSmartConnect TCM 310 /dev/ttyUSB0@57600

define COC CUL /dev/ttyAMA0@38400 1234
attr COC rfmode MAX

define cm CUL_MAX 345612

define HM HMinfo
attr HM sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
attr HM sumStatus battery,sabotageError,powerError,motor
attr HM webCmd update:protoEvents short:rssi:peerXref:configCheck:models

define EG FLOORPLAN
attr EG fp_arrange 1
attr EG fp_backgroundimg fp_EG.png
attr EG fp_default 1
attr EG fp_noMenu 1
attr EG stylesheet floorplanstyle2.css

define OG FLOORPLAN
attr OG fp_arrange 1
attr OG fp_backgroundimg fp_OG.png
attr OG fp_noMenu 1
attr OG stylesheet floorplanstyle2.css

define UG FLOORPLAN
attr UG fp_arrange 1
attr UG fp_backgroundimg fp_UG.png
attr UG fp_noMenu 1
attr UG stylesheet floorplanstyle2.css

define Umsch_UG dummy
attr Umsch_UG devStateIcon {'<a href="http://192.168.178.22:8083/fhem/floorplan/UG">M</a>'}
attr Umsch_UG fp_EG 118,188,5,
attr Umsch_UG fp_OG 128,198,0,

define Umsch_OG dummy
attr Umsch_OG devStateIcon {'<a href="http://192.168.178.22:8083/fhem/floorplan/OG">M</a>'}
attr Umsch_OG fp_EG 0,188,5,
attr Umsch_OG fp_UG 118,198,0,

define Umsch_EG dummy
attr Umsch_EG devStateIcon {'<a href="http://192.168.178.22:8083/fhem/floorplan/EG">M</a>'}
attr Umsch_EG fp_OG 0,198,5,
attr Umsch_EG fp_UG -10,198,0,

define HKTO_Buero MAX HeatingThermostat 049f71
attr HKTO_Buero room MAX
define FileLog_HKTO_Buero FileLog ./log/HKTO_Buero-%Y.log HKTO_Buero
attr FileLog_HKTO_Buero logtype text
attr FileLog_HKTO_Buero room MAX

define HKTO_Gang MAX HeatingThermostat 05ad75
attr HKTO_Gang room MAX
define FileLog_HKTO_Gang FileLog ./log/HKTO_Gang-%Y.log HKTO_Gang
attr FileLog_HKTO_Gang logtype text
attr FileLog_HKTO_Gang room MAX

define HKTO_Bad MAX HeatingThermostat 049edb
attr HKTO_Bad room MAX
define FileLog_HKTO_Bad FileLog ./log/HKTO_Bad-%Y.log HKTO_Bad
attr FileLog_HKTO_Bad logtype text
attr FileLog_HKTO_Bad room MAX

define HKTO_Naomi MAX HeatingThermostat 05adca
attr HKTO_Naomi room MAX
define FileLog_HKTO_Naomi FileLog ./log/HKTO_Naomi-%Y.log HKTO_Naomi
attr FileLog_HKTO_Naomi logtype text
attr FileLog_HKTO_Naomi room MAX

define HKTO_Eltern MAX HeatingThermostat 049f10
attr HKTO_Eltern room MAX
define FileLog_HKTO_Eltern FileLog ./log/HKTO_Eltern-%Y.log HKTO_Eltern
attr FileLog_HKTO_Eltern logtype text
attr FileLog_HKTO_Eltern room MAX

define HKTE_WZN MAX HeatingThermostat 049f58
attr HKTE_WZN room MAX
define FileLog_HKTE_WZN FileLog ./log/HKTE_WZN-%Y.log HKTE_WZN
attr FileLog_HKTE_WZN logtype text
attr FileLog_HKTE_WZN room MAX

define HKTU_Ra MAX HeatingThermostat 05adb4
attr HKTU_Ra room MAX
define FileLog_HKTU_Ra FileLog ./log/HKTU_Ra-%Y.log HKTU_Ra
attr FileLog_HKTU_Ra logtype text
attr FileLog_HKTU_Ra room MAX

define HKTE_WZO MAX HeatingThermostat 049f68
attr HKTE_WZO room MAX
define FileLog_HKTE_WZO FileLog ./log/HKTE_WZO-%Y.log HKTE_WZO
attr FileLog_HKTE_WZO logtype text
attr FileLog_HKTE_WZO room MAX

define HKTE_Kueche MAX HeatingThermostat 05adc3
attr HKTE_Kueche room MAX
define FileLog_HKTE_Kueche FileLog ./log/HKTE_Kueche-%Y.log HKTE_Kueche
attr FileLog_HKTE_Kueche logtype text
attr FileLog_HKTE_Kueche room MAX

define HKTU_Sauna MAX HeatingThermostat 05adba
attr HKTU_Sauna room MAX
define FileLog_HKTU_Sauna FileLog ./log/HKTU_Sauna-%Y.log HKTU_Sauna
attr FileLog_HKTU_Sauna logtype text
attr FileLog_HKTU_Sauna room MAX

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*

define FO1Gang_ CUL_HM 1F136F
attr FO1Gang_ .devInfo 910101
attr FO1Gang_ .stc 80
attr FO1Gang_ IODev CUL0
attr FO1Gang_ actCycle 028:00
attr FO1Gang_ actStatus alive
attr FO1Gang_ autoReadReg 4_reqStatus
attr FO1Gang_ expert 2_full
attr FO1Gang_ firmware 2.0
attr FO1Gang_ model HM-SEC-RHS
attr FO1Gang_ peerIDs 00000000,
attr FO1Gang_ room CUL_HM
attr FO1Gang_ serialNr KEQ0018780
attr FO1Gang_ subType threeStateSensor
define FileLog_FO1Gang_ FileLog ./log/FO1Gang_-%Y.log FO1Gang_
attr FileLog_FO1Gang_ logtype text
attr FileLog_FO1Gang_ room CUL_HM

define FE_TreppeW CUL_HM 1F1347
attr FE_TreppeW .devInfo 910101
attr FE_TreppeW .stc 80
attr FE_TreppeW IODev CUL0
attr FE_TreppeW actCycle 028:00
attr FE_TreppeW actStatus alive
attr FE_TreppeW autoReadReg 4_reqStatus
attr FE_TreppeW expert 2_full
attr FE_TreppeW firmware 2.0
attr FE_TreppeW model HM-SEC-RHS
attr FE_TreppeW peerIDs 00000000,
attr FE_TreppeW room CUL_HM
attr FE_TreppeW serialNr KEQ0018820
attr FE_TreppeW subType threeStateSensor
define FileLog_FE_TreppeW FileLog ./log/FE_TreppeW-%Y.log FE_TreppeW
attr FileLog_FE_TreppeW logtype text
attr FileLog_FE_TreppeW room CUL_HM

define FO1BadN CUL_HM 1F1370
attr FO1BadN .devInfo 910101
attr FO1BadN .stc 80
attr FO1BadN IODev CUL0
attr FO1BadN actCycle 028:00
attr FO1BadN actStatus alive
attr FO1BadN autoReadReg 4_reqStatus
attr FO1BadN expert 2_full
attr FO1BadN firmware 2.0
attr FO1BadN model HM-SEC-RHS
attr FO1BadN peerIDs 00000000,
attr FO1BadN room CUL_HM
attr FO1BadN serialNr KEQ0018779
attr FO1BadN subType threeStateSensor
define FileLog_FO1BadN FileLog ./log/FO1BadN-%Y.log FO1BadN
attr FileLog_FO1BadN logtype text
attr FileLog_FO1BadN room CUL_HM

define FO1BadW CUL_HM 1C814D
attr FO1BadW .devInfo 910101
attr FO1BadW .stc 80
attr FO1BadW IODev CUL0
attr FO1BadW actCycle 028:00
attr FO1BadW actStatus alive
attr FO1BadW autoReadReg 4_reqStatus
attr FO1BadW expert 2_full
attr FO1BadW firmware 2.0
attr FO1BadW model HM-SEC-RHS
attr FO1BadW peerIDs 00000000,
attr FO1BadW room CUL_HM
attr FO1BadW serialNr JEQ0260922
attr FO1BadW subType threeStateSensor
define FileLog_FO1BadW FileLog ./log/FO1BadW-%Y.log FO1BadW
attr FileLog_FO1BadW logtype text
attr FileLog_FO1BadW room CUL_HM

define FE_TreppeO CUL_HM 1F1B57
attr FE_TreppeO .devInfo 910101
attr FE_TreppeO .stc 80
attr FE_TreppeO IODev CUL0
attr FE_TreppeO actCycle 028:00
attr FE_TreppeO actStatus alive
attr FE_TreppeO autoReadReg 4_reqStatus
attr FE_TreppeO expert 2_full
attr FE_TreppeO firmware 2.0
attr FE_TreppeO model HM-SEC-RHS
attr FE_TreppeO peerIDs 00000000,
attr FE_TreppeO room CUL_HM
attr FE_TreppeO serialNr KEQ0016804
attr FE_TreppeO subType threeStateSensor
define FileLog_FE_TreppeO FileLog ./log/FE_TreppeO-%Y.log FE_TreppeO
attr FileLog_FE_TreppeO logtype text
attr FileLog_FE_TreppeO room CUL_HM

define FE1KuecheN CUL_HM 1E90B5
attr FE1KuecheN .devInfo 910101
attr FE1KuecheN .stc 80
attr FE1KuecheN IODev CUL0
attr FE1KuecheN actCycle 028:00
attr FE1KuecheN actStatus alive
attr FE1KuecheN autoReadReg 4_reqStatus
attr FE1KuecheN expert 2_full
attr FE1KuecheN firmware 2.0
attr FE1KuecheN model HM-SEC-RHS
attr FE1KuecheN peerIDs 00000000,
attr FE1KuecheN room CUL_HM
attr FE1KuecheN serialNr JEQ0711450
attr FE1KuecheN subType threeStateSensor
define FileLog_FE1KuecheN FileLog ./log/FE1KuecheN-%Y.log FE1KuecheN
attr FileLog_FE1KuecheN logtype text
attr FileLog_FE1KuecheN room CUL_HM

define FE1KuecheW CUL_HM 1E8E02
attr FE1KuecheW .devInfo 910101
attr FE1KuecheW .stc 80
attr FE1KuecheW IODev CUL0
attr FE1KuecheW actCycle 028:00
attr FE1KuecheW actStatus alive
attr FE1KuecheW autoReadReg 4_reqStatus
attr FE1KuecheW expert 2_full
attr FE1KuecheW firmware 2.0
attr FE1KuecheW model HM-SEC-RHS
attr FE1KuecheW peerIDs 00000000,
attr FE1KuecheW room CUL_HM
attr FE1KuecheW serialNr JEQ0711709
attr FE1KuecheW subType threeStateSensor
define FileLog_FE1KuecheW FileLog ./log/FE1KuecheW-%Y.log FE1KuecheW
attr FileLog_FE1KuecheW logtype text
attr FileLog_FE1KuecheW room CUL_HM

define FE_WC_ CUL_HM 1F14EA
attr FE_WC_ .devInfo 910101
attr FE_WC_ .stc 80
attr FE_WC_ IODev CUL0
attr FE_WC_ actCycle 028:00
attr FE_WC_ actStatus alive
attr FE_WC_ autoReadReg 4_reqStatus
attr FE_WC_ expert 2_full
attr FE_WC_ firmware 2.0
attr FE_WC_ model HM-SEC-RHS
attr FE_WC_ peerIDs 00000000,
attr FE_WC_ room CUL_HM
attr FE_WC_ serialNr KEQ0018409
attr FE_WC_ subType threeStateSensor
define FileLog_FE_WC_ FileLog ./log/FE_WC_-%Y.log FE_WC_
attr FileLog_FE_WC_ logtype text
attr FileLog_FE_WC_ room CUL_HM

define FU1Sauna_ CUL_HM 1F1500
attr FU1Sauna_ .devInfo 910101
attr FU1Sauna_ .stc 80
attr FU1Sauna_ IODev CUL0
attr FU1Sauna_ actCycle 028:00
attr FU1Sauna_ actStatus alive
attr FU1Sauna_ autoReadReg 4_reqStatus
attr FU1Sauna_ expert 2_full
attr FU1Sauna_ firmware 2.0
attr FU1Sauna_ model HM-SEC-RHS
attr FU1Sauna_ peerIDs 00000000,
attr FU1Sauna_ room CUL_HM
attr FU1Sauna_ serialNr KEQ0018413
attr FU1Sauna_ subType threeStateSensor
define FileLog_FU1Sauna_ FileLog ./log/FU1Sauna_-%Y.log FU1Sauna_
attr FileLog_FU1Sauna_ logtype text
attr FileLog_FU1Sauna_ room CUL_HM

define FU_EntreeN CUL_HM 1E90E6
attr FU_EntreeN .devInfo 910101
attr FU_EntreeN .stc 80
attr FU_EntreeN IODev CUL0
attr FU_EntreeN actCycle 028:00
attr FU_EntreeN actStatus alive
attr FU_EntreeN autoReadReg 4_reqStatus
attr FU_EntreeN expert 2_full
attr FU_EntreeN firmware 2.0
attr FU_EntreeN model HM-SEC-RHS
attr FU_EntreeN peerIDs 00000000,
attr FU_EntreeN room CUL_HM
attr FU_EntreeN serialNr JEQ0711392
attr FU_EntreeN subType threeStateSensor
define FileLog_FU_EntreeN FileLog ./log/FU_EntreeN-%Y.log FU_EntreeN
attr FileLog_FU_EntreeN logtype text
attr FileLog_FU_EntreeN room CUL_HM

define FU_EntreeS CUL_HM 1E90E4
attr FU_EntreeS .devInfo 910101
attr FU_EntreeS .stc 80
attr FU_EntreeS IODev CUL0
attr FU_EntreeS actCycle 028:00
attr FU_EntreeS actStatus alive
attr FU_EntreeS autoReadReg 4_reqStatus
attr FU_EntreeS expert 2_full
attr FU_EntreeS firmware 2.0
attr FU_EntreeS model HM-SEC-RHS
attr FU_EntreeS peerIDs 00000000,
attr FU_EntreeS room CUL_HM
attr FU_EntreeS serialNr JEQ0711394
attr FU_EntreeS subType threeStateSensor
define FileLog_FU_EntreeS FileLog ./log/FU_EntreeS-%Y.log FU_EntreeS
attr FileLog_FU_EntreeS logtype text
attr FileLog_FU_EntreeS room CUL_HM

define FU1RaO CUL_HM 1F19FA
attr FU1RaO .devInfo 910101
attr FU1RaO .stc 80
attr FU1RaO IODev CUL0
attr FU1RaO actCycle 028:00
attr FU1RaO actStatus alive
attr FU1RaO autoReadReg 4_reqStatus
attr FU1RaO expert 2_full
attr FU1RaO firmware 2.0
attr FU1RaO model HM-SEC-RHS
attr FU1RaO peerIDs 00000000,
attr FU1RaO room CUL_HM
attr FU1RaO serialNr KEQ0017205
attr FU1RaO subType threeStateSensor
define FileLog_FU1RaO FileLog ./log/FU1RaO-%Y.log FU1RaO
attr FileLog_FU1RaO logtype text
attr FileLog_FU1RaO room CUL_HM

define FU1RaW CUL_HM 1C812E
attr FU1RaW .devInfo 910101
attr FU1RaW .stc 80
attr FU1RaW IODev CUL0
attr FU1RaW actCycle 028:00
attr FU1RaW actStatus alive
attr FU1RaW autoReadReg 4_reqStatus
attr FU1RaW expert 2_full
attr FU1RaW firmware 2.0
attr FU1RaW model HM-SEC-RHS
attr FU1RaW peerIDs 00000000,
attr FU1RaW room CUL_HM
attr FU1RaW serialNr JEQ0260891
attr FU1RaW subType threeStateSensor
define FileLog_FU1RaW FileLog ./log/FU1RaW-%Y.log FU1RaW
attr FileLog_FU1RaW logtype text
attr FileLog_FU1RaW room CUL_HM

define FO1ElternO CUL_HM 1F1354
attr FO1ElternO .devInfo 910101
attr FO1ElternO .stc 80
attr FO1ElternO IODev CUL0
attr FO1ElternO actCycle 028:00
attr FO1ElternO actStatus alive
attr FO1ElternO autoReadReg 4_reqStatus
attr FO1ElternO expert 2_full
attr FO1ElternO firmware 2.0
attr FO1ElternO model HM-SEC-RHS
attr FO1ElternO peerIDs 00000000,
attr FO1ElternO room CUL_HM
attr FO1ElternO serialNr KEQ0018807
attr FO1ElternO subType threeStateSensor
define FileLog_FO1ElternO FileLog ./log/FO1ElternO-%Y.log FO1ElternO
attr FileLog_FO1ElternO logtype text
attr FileLog_FO1ElternO room CUL_HM

define FO1ElternS CUL_HM 1C825A
attr FO1ElternS .devInfo 910101
attr FO1ElternS .stc 80
attr FO1ElternS IODev CUL0
attr FO1ElternS actCycle 028:00
attr FO1ElternS actStatus alive
attr FO1ElternS autoReadReg 4_reqStatus
attr FO1ElternS expert 2_full
attr FO1ElternS firmware 2.0
attr FO1ElternS model HM-SEC-RHS
attr FO1ElternS peerIDs 00000000,
attr FO1ElternS room CUL_HM
attr FO1ElternS serialNr JEQ0261193
attr FO1ElternS subType threeStateSensor
define FileLog_FO1ElternS FileLog ./log/FO1ElternS-%Y.log FO1ElternS
attr FileLog_FO1ElternS logtype text
attr FileLog_FO1ElternS room CUL_HM

define FO1NaomiS CUL_HM 1F1B53
attr FO1NaomiS .devInfo 910101
attr FO1NaomiS .stc 80
attr FO1NaomiS IODev CUL0
attr FO1NaomiS actCycle 028:00
attr FO1NaomiS actStatus alive
attr FO1NaomiS autoReadReg 4_reqStatus
attr FO1NaomiS expert 2_full
attr FO1NaomiS firmware 2.0
attr FO1NaomiS model HM-SEC-RHS
attr FO1NaomiS peerIDs 00000000,
attr FO1NaomiS room CUL_HM
attr FO1NaomiS serialNr KEQ0016807
attr FO1NaomiS subType threeStateSensor
define FileLog_FO1NaomiS FileLog ./log/FO1NaomiS-%Y.log FO1NaomiS
attr FileLog_FO1NaomiS logtype text
attr FileLog_FO1NaomiS room CUL_HM

define FO1NaomiW CUL_HM 1F1B5D
attr FO1NaomiW .devInfo 910101
attr FO1NaomiW .stc 80
attr FO1NaomiW IODev CUL0
attr FO1NaomiW actCycle 028:00
attr FO1NaomiW actStatus alive
attr FO1NaomiW autoReadReg 4_reqStatus
attr FO1NaomiW expert 2_full
attr FO1NaomiW firmware 2.0
attr FO1NaomiW model HM-SEC-RHS
attr FO1NaomiW peerIDs 00000000,
attr FO1NaomiW room CUL_HM
attr FO1NaomiW serialNr KEQ0016798
attr FO1NaomiW subType threeStateSensor
define FileLog_FO1NaomiW FileLog ./log/FO1NaomiW-%Y.log FO1NaomiW
attr FileLog_FO1NaomiW logtype text
attr FileLog_FO1NaomiW room CUL_HM

define SE_WZ CUL_HM 1FD1F6
attr SE_WZ .devInfo 020100
attr SE_WZ .stc 10
attr SE_WZ IODev CUL0
attr SE_WZ autoReadReg 4_reqStatus
attr SE_WZ expert 2_full
attr SE_WZ firmware 1.12
attr SE_WZ model HM-LC-SW2-FM
attr SE_WZ peerIDs 
attr SE_WZ room CUL_HM
attr SE_WZ serialNr KEQ0254447
attr SE_WZ subType switch
attr SE_WZ webCmd toggle:on:off:statusRequest
define FileLog_SE_WZ FileLog ./log/SE_WZ-%Y.log SE_WZ
attr FileLog_SE_WZ logtype text
attr FileLog_SE_WZ room CUL_HM

define CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_01 CUL_HM 1FD1F601
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_01 expert 
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_01 model HM-LC-SW2-FM
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_01 peerIDs 00000000,
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_01 webCmd toggle:on:off:statusRequest

define CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_02 CUL_HM 1FD1F602
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_02 expert 
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_02 model HM-LC-SW2-FM
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_02 peerIDs 00000000,
attr CUL_HM_HM_LC_SW2_FM_1FD1F6_Sw_02 webCmd toggle:on:off:statusRequest

Zrrronggg! · 11 Januar 2014, 17:47:17

Zitatdefine CUL0 CUL /dev/ttyACM0@9600 2345
attr CUL0 rfmode HomeMatic

ZitatSE_WZ paired:0xF12345 IO attr: -
Ich habe in der fhem.cfg kein Device mit HM ID 12345.

Must genauer lesen

1.

ZitatSE_WZ paired:0xF12345

sagt, dass es um ein Device/HM-Zentrale mit der HM-ID F12345 geht, *nicht* um eines mit "12345"

2. klar hast du das Device/HM-Zentrale.
Normalerweise muss man die HM-ID ja setzen, mit dem attribute hmId, z.b. so:

Code Auswählen

attr CUL hmId 123ABC
Das hast du aber vergessen.

Und dann versucht Fhem eine HM-ID sich selbst auszudenken. Dazu verwendet es die im HM-rfMode an sich überflüssige FHT ID und packt "F1" davor (steht so in der commandref). Und tatsächlich: die FHT-ID hast du bei deiner CUL-Definition angegeben, die ist nämlich...

Zitatdefine CUL0 CUL /dev/ttyACM0@9600 2345

2345.

Ergbniss: deine HM-ID wurde automatisch auf F1 2345 gesetzt. Voila.

Zitat
Zitat6stellige HM ID (3 Byte hex) die aus dem FHEM log ermittelt werden kann. Die Nummer
ist von Hersteller für jedes Gerät unveränderlich vorgegeben.

Wo kommt das Zitat her? Wenn damit tatsächlich die HM-ID gemeint ist, ist die Aussage FALSCH. Die HM-ID kann und muss man selber setzen, siehe oben. Es gibt hier sicher eine Menge Leute die das nicht gemacht haben, aber - in Unkenntniss - ihrem CUL/CUNO eine FHT-ID mitgegeben haben, obwohl die für ein CUL/CUNO im rfmode HomeMatic natürlich sinnlos ist. Zum Glück bastelt FHEM fehlertolerant daraus dann eine gültige HM-ID, wie oben beschrieben. Ich wette, dass daher bei vielem HM Nutzern die Installtion geht und sie eigentlich gar nicht genau wissen warum

Allerdings ist die SERIENNUMMER und die Adresse eine HM Gerätes im Gegensatz zu anderen Funksystem (FHT, FS20, IT) fest vergeben. Möglicherweise hat der Verfasser des Textes den Begriff HM-ID hier nur missverständlicherweise auf die HM-Adresse des HM Gerätes angewendet.

ZitatIst diese Installation noch zu retten?

Kann gar keine Fehler entdecken. Es wäre im Sinne des Diskutierten sicher besser, anstatt
des

Code Auswählen

define CUL0 CUL /dev/ttyACM0@9600 2345
attr CUL0 rfmode HomeMatic

lieber

Code Auswählen

define CUL0 CUL /dev/ttyACM0@9600
attr CUL0 rfmode HomeMatic
attr CUL0 hmId F12345

zu schreiben, aber das ist letztlich nur eine Schönheitsthema.

(oder beliebige andere HM-IDs anstatt F12345, dann müsste aber neu gepairt werden)

nachlesen kann man das hier:
http://www.fhem.de/commandref.html#hmId

und sinngemäss auch hier:
http://www.fhemwiki.de/wiki/HMLAN_Konfigurator#Einbindung_in_FHEM

Marcel_R · 11 Januar 2014, 18:12:21

Zrrronggg!

Danke für diese ausführliche Erklärung - ich bin nun ein ganzes Stück gescheiter.

ZitatWo kommt das Zitat her? Wenn damit tatsächlich die HM-ID gemeint ist die Aussage FALSCH.

Das Zitat kommt von Seite 6 aus "EinsteigerHMAnhangV6-2-1.pdf" von martinp876. Vermutlich habe ich diese Aussage aus dem Kontext gerissen - gemeint sind vermutlich alle anderen als die IO-Devices.

Danke
Marcel

Nachtrag:
Habe "hmId F12345" als attr gesetzt. Jetzt ergibt configCheck eine blütenweisse Weste!!!

P.S. ohne Angabe der FHT ID hat es mir das System aber nicht akzeptiert.

Zrrronggg! · 11 Januar 2014, 18:45:25

ZitatP.S. ohne Angabe der FHT ID hat es mir das System aber nicht akzeptiert.

Spannend.

Kannst du mal für meinen Wissensgewinn sagen, was "hat nicht akzeptiert" genau heisst?

Fehlermeldung im Log? Wie sah die aus?
Denkbar ist, das als Rudiment aus Zeiten als CUL eigentlich nur SlowRF konnte, noch eine Check übrig ist, der verlangt, das die FHT-ID in jedem fall gesetzt wird, auch wenn danach durch rfMode HomeMatic diese an sich überflüssig wird.

Commandref sagt:

define <name> CUL <device> <FHTID>

Okay, das bedeutet die FHT ID ist tatsächlich obligatorisch, auch wenn eine FHT Kommunikation in rfMode HomeMatic gar nicht möglich ist.

Das sichert zwar einerseits die Funktion mit HM auch wenn man (so wie du) vergisst die HM-ID zu setzen, verwirrt aber andererseits.

Naja, Problem ist natürlich, dass das Attribute rfmode optional ist und später gesetzt wird, da kann man das wohl anders nicht einfach machen.

martinp876 · 11 Januar 2014, 18:57:46

die HMId ist die Adresse jedes Devices - und ist unveränderlich. Ausser eben für HMLAN, CUL und virtuelle Aktoren. Da muss es immer noch eindeutig sein, aber der User kann/muss es vergeben.
Bei CUL wird es, wenn nicht vom User gesetzt, automatisch generiert. Ein Service, den ich bei der Wichtigkeit des Parameters so nicht für sinnvoll halte.
Die HMId/Adresse wird in jeder message benötigt. Die des IO device ist auch die, mit dem das Gerät gepairt wird.

p.s.: es funktioniert alles weiterhin bei CUL auch ohne gesetztes Attribut HMId - wie bisher eben. Der HMInfo configCheck wird aber einen Fehler/warnung ausspucken. Es testet ob die HMId des IO devices auch der des "gepairten maters" entspricht. Hier wird auf das Attribut geprüft.

Zrrronggg! · 11 Januar 2014, 19:07:13

Zitatdie HMId ist die Adresse jedes Devices - und ist unveränderlich

Dann müssten wir aber dringend was an der Benennung ändern. Sowohl die commandref, also auch darauf aufsetzende Wikiartikel meinem mit HM-ID die der Zentrale. (CUL, LANKondigurator etc). Zu sagen diese sei unveränderlich ist dann mindestens verwirrend.

ZitatDa muss es immer noch eindeutig sein, aber der User kann/muss es vergeben.

HM: Auch das ist eine eventuell schwierige Aussage. Es gibt auch hier im Forum Leute, die mit Erfolg mehrere LAN Configuratoren mit der SELBEN HM-ID betreiben und dann Devices mit IOdev nach RSSI zuteilen. Die HM-ID der Zentralen aka IO-Devices muss also nicht immer eindeutig sein. Daraus ergibt sich eigentlich auch, das die HM-ID der Zentralen nicht ganz das Selbe ist wie die Adressen der normalen Devices, oder? Wäre es da nicht doch sinnvoll da nicht den selben Begriff zu verwenden?

ZitatEin Service, den ich bei der Wichtigkeit des Parameters so nicht für sinnvoll halte.

Ja, das dachte ich auch schon. Ich stelle mir auch vor, dass es besser wäre, wenn man sich des Themas bewusst wäre und ohne das Setzen der HM-ID eine Fehlermeldung kommt.
Ich will nicht wissen, wieviel Leute mit F12345 oder sehr ähnlichem fahren.

Rohan · 11 Januar 2014, 19:50:08

Hi,

Zitat von: Zrrronggg! am 11 Januar 2014, 19:07:13
Dann müssten wir aber dringend was an der Benennung ändern. Sowohl die commandref, also auch darauf aufsetzende Wikiartikel meinem mit HM-ID die der Zentrale. (CUL, LANKondigurator etc). Zu sagen diese sei unveränderlich ist dann mindestens verwirrend. ...

Full ACK.

Auch ich betrachte die HM-ID als die ID des HMLAN. Das andere sind für mich die IDs bzw. Device-IDs. Und so würde ich es auch gerne beibehalten wollen.

Edith muss noch ergänzen: Diese Benamung half/hilft mir ungemein bei der Verinnerlichung des Pairings/Peerens.

Just my 2 EUR-Cents.

Gruß
Thomas

martinp876 · 11 Januar 2014, 19:57:43

nun - das ist mir alles klar.... reden wir drüber

es gibt nur Adressen. Die können wir HMId nennen oder nicht. Die Adresse wird bei Devices in der definition genutzt (betrifft alle CUL_HM entities - channels erweitern die Adresse um 1 Byte, senden aber eh nie selbst)

Eine Zentrale hat mindestens eine, evtl. auch mehrere Adressen. Die Zentrale nutzt -meist- eine Adresse je IO-device - kann aber auch mehrere nutzen. Eine CUL weiss eh nichts von ihrer eigenen Adresse (HMLAN/USB schon). Die Zentrale muss jeden IO eine Adresse geben - das kann die selbe sein, oder unterschiedliche. Im Prinzip werden bei mehreren Adressen mehrere Zentralen (HM entities) definiert welche implizit in FHEM zusammengeworfen werden.
Nutzen der gleichen HMId in mehreren IOs hat ein paar Eigenheiten... da ein HMLAN gerne ACKs sendet, wenn ihm einer etwas zuschickt. Das ist nur unkritisch solange der User das IO-device nicht on-the-fly ändert... passiert wohl selten. Da wäre noch etwas Code notwendig, es wirklich sauber zu machen.

Aber zurück zum Thema
Ich sehe keinen Unterschied zwischen Adresse und HMId. Wir können es nennen wie wir wollen. Eindeutig muss es je Entity sein, das ist auch Fakt. Ein IO-device ist keine CUL_HM entity sondern ein eigentlich ein "draht", ein IO eben. Die Zentrale eigentlich schon... die ist implizit vorhanden - aber nicht sichtbar oder provisionierbar. Das Setzen der Zentralen-Adresse im IO-Device ist daher nach objektorientierung nicht korrekt, aber eben pragmatisch. Man sollte es in der Zentrale definieren und dem IO-device übergeben. Aber da die Zentrale als objekt garnicht sichtbar/existent ist....

Ich kann mit dem Begriff HMId als device-adresse leben - und auch mit der Implementierung.

Gruss Martin

Rohan · 11 Januar 2014, 20:11:24

Hallo Martin,

ich sehe deine Sicht, aber es ist wie so oft: Es gibt mindestens 2 Betrachtungs-/Herangehensweisen, nämlich die des Anwenders (die ich hier als Indviduum einnehme - es kann also auch durchaus andere Meinungen dazu geben) und die des Technikers/Programmierers. Und da es - wie du selbst sagst - programmtechnisch kein Problem ist, die (veränderliche) ID des HM-LAN "HM-ID" und die der Devices anders (z.B. als (unveränderliche) "Device-ID") zu benennen, wäre es aus *meiner* Sicht sinnvoll, diese Unterscheidung bereits im Namen der ID auszudrücken.

Wie gesagt, es kann/wird durchaus auch andere Anwendermeinungen geben. Ggfls passe ich mich an (werde ich dann wohl müssen). Vlt. rührt meine Auffassung/Meinung auch zu einem großen Teil der "Gewohnheit" bzw. einem daraus sich ergebenden Beharrungsvermögen

Ich bitte um rege Beteiligung bei diesem Meinungsbildungprozess.

Gruß
Thomas

martinp876 · 11 Januar 2014, 20:25:43

Hi Thomas,

Also im coding sehe ich keinen Änderungebedarf - ist ja kein schul-code.
In der doku sehe ich dies auch nicht.
Jede ansprechbare Einheit hat eine Identifikation (ID) die für HomeMatic genutzt wird (HMID eben). Das ist eben die Adresse.

Die ID der "externen devices" kann (aus guten Grund) nicht geändert werden -ist genauso fix wie die Seriennummer.
Für die Zentrale vergibt dies HM auch automatisch so man deren Code (PC-SW )nutzt.

Der User muss sich um die HMId der Device nicht kümmern, geht alles automatich. Die ID steht in "DEF" (was ich von der Namensgebung nicht verstehe - ist eben so).

Im Einsteigerdoc (schon lange nicht mehr hineingesehen) habe ich anfänglich Details und rohmessages beschrieben - in den späteren Versionen hat dies nachgelassen da schon mehr high-level ging. Ich denke, die Beschreibung ist schon ok.

Was ist jetzt eigentlich der Knackpunkt? Dass im Einsteigerdoc die Konfiguration eines IO device beschrieben wird (ist komplett aussen vor)? Und die dortige Möglichkeit der Nutzung doppelter Adressen und das daraus folgende verhalten?
dass die Adresse auch die Adresse ist kann ich dem User nicht vorenthalten - so er auf diesen Level runter geht.

Gruss Martin

Zrrronggg! · 11 Januar 2014, 20:48:03

Der Knackpunkt ist, das Einsteiger und Anfänger falsche Schlüsse ziehen, so auch der Threadowner hier.
Er ist ja nicht der Erste, der dieses oder eine sehr ähnliches Problem hat.

Ich denke, wir machen es den Anfängern einfacher, wenn wir
1. Diese Dinge analog in den diversen Funkfamilien nennen
2. Dinge die sich unterschiedlich verhalten unterschiedlich bennenen

zu 1.
Bei FHT heisst heisst die Adresse des I/O Adapters "FHT-ID", die der FHT80 jedoch "FHT-Adresse"
Daher wäre es eventuell gut, wenn man das bei anderen Protokollen ähnlich halten würde. Das erleichtert das Verständnis aus Anwendersicht, weil Analogien gezogen werden können.

zu 2.
Die Adresse des I/O Adapter verhält sich anders als die der sonstigen Devices
Sie kann und muss vom Anwender gesetzte werden, sie ist also nicht im Gerät fest verdrahtet. Nebenher: sie muss nichtmal eindeutig sein (darauf basieren ja vorgeschlagenen Exploits).

Speziell die Kernaussagen zur HM Adresse sind bei den beiden Anwendungsfälle (Gerät vs IO Device) exakt gegenteilig, und solange man das nicht im Namen auseinanderhalten kann sind alle Sätze entweder umfangreich und mit "ausser" geformt, oder missverständlich.

Und genau das ist ja hier passiert und genau das hat den Threadowner in die Irre geleitet (gut, kombinert mit dem Umstand das die HM-ID ohne setzen aus der FHT-ID gebildet wird.)

ICH weiss ja Bescheid und kann daher damit leben wie auch Rohan. Aber als Anfänger - speziell wenn man von z.b. IT oder FS20 kommt ist ja gerade das , was man begreifen muss: - die Adresse kann man nicht selber bestimmten was die Geräte betrifft, aber der "Zentrale" muss man eine Adresse zuteilen.

Das sind ja beides Konzepte die man erstmal verinnerlichen muss.

Didaktisch ist es da einfach schwierig, wenn man so Sätze bringen muss wie:

"Also die HM-ID kann und muss man selber setzen, bzw. kann man NICHT selber setzen, kommt drauf an."

Egal wie man das genau formuliert, das hilft Anfängern wenig.

Es geht also nicht um Technik oder technische Definitionen oder Coding, es geht nur um Namensschilder. Und die sollten für etwas was sich konträr verhält unterschiedlich sein.

MEINE Meinung. Aber wie Rohan: Mir ist's für mich egal. Ich kenne die Situation, und suche nur nach wegen Anfängern schneller zu helfen.

ZitatIch denke, die Beschreibung ist schon ok.

Für dich und mich und Rohan, ja. Für Anfänger ganz deutlich erkennbar eben genau nicht.

Marcel_R · 12 Januar 2014, 02:11:12

Es tut mir ja leid, dass ich eine solche Diskussion losgetreten habe....

Was mich als Anfänger verwirrt ist 'everything goes' - mindestens am Anfang - und dann kommt plötzlich der Hammer und irgendwo hakt es mit einer myriade von möglichen Fehlerquellen.

Erschwerend ist die unendliche Menge an Dokumentation von relevant bis banal bunt gemischt; durchsetzt mit Abkürzungen von Fachausdrücken, meist so kurz, dass sie in einer Suchmaschine keine sinnvolle Antwort liefert.

Gerade heute habe ich meiner Frau gesagt, dass ich mich mit FHEM in die gute alte Zeit zurück versetzt fühle, als es 1 bis 2 Arbeitstage brauchte, um einen neuen Druckertyp an einem Computer (oder einen bekannten Drucker an ein neues Computer-Modell) anzupassen.

Auch wenn ich nicht ein grosser Microsoft-Fan bin - eines muss ich ihnen neidlos zugestehen, die Anbindukng der Peripheriegeräte haben sie standardisiert. Ich bin der Meinung, dass auch die Schnittstellen in der Hausautomation normiert werden müssen.

Am Beispiel HM ID:
Meine ersten Devices waren MAX Heizkörper-Thermostate.

aus http://www.fhemwiki.de/wiki/MAX

Code Auswählen

CUL_MAX
Minimale Konfiguration:

define CUL0 CUL /dev/ttyACM0@9600 0000
 attr CUL0 rfmode MAX
 define cm CUL_MAX 123456

Anlernen
Dazu muss der "pairmode" auf MAXLAN/CUL_MAX per
    set cm/ml pairmode

Eine vergleichbare Hilfe habe ich für HM-Devices nicht gefunden. Dafür stehen im fhem.cfg des busware-image folgende Anmerkungen:

Code Auswählen

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create


# If the above notify did not helped, then you probably have to enable some of
# the following lines.  Verify first that /dev/xxx ist correct.

#define FHZ FHZ /dev/USB0
#define CUL CUL /dev/ttyACM0@9600 1234
#attr CUL rfmode HomeMatic

Zrrronggg! hat in seiner Anwort richtig bemerkt:

ZitatMust genauer lesen
Zitat
SE_WZ paired:0xF12345
sagt, dass es um ein Device/HM-Zentrale mit der HM-ID F12345 geht, *nicht* um eines mit "12345"

Nur, wenn ich nach "Anleitung" vorgehe; in der Folge FHEM in der Blackbox einen Wert bildet ohne mir diesen Vorgang zu kommunizieren, dann finde ich dies nicht optimal.

In der Folge habe ich ja herausfinden müssen, was genau der angegebene Fehler aussagt, dann musste ich auf Spurensuche gehen, um mich an die Ursache meines Problems heranzupirschen. In der Folge wurde ich aufgrund der Informationen zu HM ID

Zitat6stellige HM ID (3 Byte hex) die aus dem FHEM log ermittelt werden kann. Die Nummer
ist von Hersteller für jedes Gerät unveränderlich vorgegeben.

effektiv auf eine falsche Fährte geführt, denn :
- weder wird die Nummer vom Hersteller vergeben
- noch ist sie unveränderlich,
- noch erscheint sie im log
- noch ist sie nach aussen "sichtbar" 6 stellig.

Nur bin ich der Meinung, wir sollten die Kirche im Dorf lassen und lobenswert anerkennen:
1. Martin hat ein äusserst umfangreiches Werk geschrieben, das tief Einblick in die Funktionsabläufe von HM gibt - sowie mit HMinfo ein Kontrollinstrument geschaffen
2. ist Martin intensiv im Forum und hilft fürsorglich
3. sieht die Welt aus "seiner" Fritz!Box-Sicht nicht unbedingt wie aus CUL-Optik aus

Wichtiger als die Frage über den "richtigen" Namen würde mir scheinen, dass das scheinbar zwingend erforderliche Attribut vom System auch in die fhem.cfg hineingeschrieben wird (sodass der Begriff bei Problemfällen bekannt ist und mit ihm Fehler gefunden werden können).

Gruss
Marcel

P.S. 1) Nicht zu vergessen ist, hätte HMinfo mich nicht darauf aufmerksam gemacht, hätte ich diesen "Schönheitsfehler" gar nicht bemerkt. Dass ich so pointiert suche hat mit einem anderen Fehler zu tun, bei dem ein notify sämtliche Thermostate auf windowOpen setzt. Für dieses Thema hoffe ich auf die Spezialisten in der MAX-Gruppe (siehe http://forum.fhem.de/index.php/topic,18420.msg122528.html#msg122528

P.S. 2) Antwort für Zrrronggg!

Zitatwas "hat nicht akzeptiert" genau heisst?
Fehlermeldung im Log? Wie sah die aus?

Nicht im Log, sondern abgefangen beim Speichern:

Code Auswählen

ERROR:
wrong syntax: define CUL {none | devicename[@baudrate] | devicename@directio | hostname:port} Please define CUL0 first Please define CUL0 first FO1Gang_: unknown IODev specified FE_TreppeW: unknown IODev specified FO1BadN: unknown IODev specified FO1BadW: unknown IODev specified FE1KuecheN: unknown IODev specified FE1KuecheW: unknown IODev specified FE_WC_: unknown IODev specified FU1Sauna_: unknown IODev specified FU_EntreeN: unknown IODev specified FU_EntreeS: unknown IODev specified FU1RaO: unknown IODev specified FU1RaW: unknown IODev specified FO1ElternO: unknown IODev specified FO1ElternS: unknown IODev specified FO1NaomiS: unknown IODev specified FO1NaomiW: unknown IODev specified SE_WZ: unknown IODev specified FE_TreppeO: unknown IODev specified Please define CUL0 first Please define CUL0 first

Zrrronggg! · 12 Januar 2014, 02:29:49

Muss dir nicht leid tun, bist ja nicht der erste. Und Kritik an Martins Leistung ist das sowieso nicht.

Ansonten: Ja, beschäftigen muss man sich damit leider schon, Klicki-Bunti ist das nicht (ich selber nutze sonst nur OS X - also Macs)

Puschel74 · 12 Januar 2014, 09:11:59

Hallo,

ich komme ja ursprünglich auch aus der FS20-Welt

Meine ersten Schritte (und auch meine weiteren) habe ich mit dem Wiki gemacht: http://www.fhemwiki.de/wiki/Kategorie:HomeMatic_Components

Und speziell bei HM-Lan http://www.fhemwiki.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter
findet sich die Passage im Wikitext:

Code Auswählen

define HMLAN1 HMLAN <IP Adresse>:1000 
attr HMLAN1 hmId 123ABC

Zitatwichtig ist vor allem, für den HMLAN eine Adresse festzulegen, die HM-ID. Diese muss hexadezimal und 6 stellig sein. 000000 und FFFFFF sind nicht gültig. Jedes Wechseln dieser Adresse erfordert neues pairen aller HM Geräte!

Ich wüsste jetzt nicht was dort unverständlich beschrieben ist - aber ok, ich bin zum Glück ja auch nicht das Maß aller Dinge

Grüße

martinp876 · 12 Januar 2014, 10:55:57

Hi,

@Marcel,
mir sind einige deiner Aussagen nicht klar.
a) das "Problem" von HMInfo ist kein Problem sondern ein Schönheitsfehler
b) "everything goes" würde mir sage, dass es tausende stellräder gibt. Man kann es einfacher machen - geht nicht viel aber einfach. FHEM legt viel offen
c)1-2 Tage ein device einzubinden - finde ich schade. Ist das so? Ich gehe davon aus, dass
- einfaches licht schalten sollte schneller gehen
- komplexere Dinge muss man erlernen - das ist wohl immer so
- wenn man eine Basis hat sollte man deutlich schneller vorankommen
- Möglichkeiten die man hat sind unbegrenzt - das braucht auch unbegrenzt zeit diese zu entdecken
d) klares Lesen und Fehler machen ist menschlich. Wenn man 0xF12345 als 12346 liest kann das vorkommen - ist aber kein Problem von FHEM

=> wenn du vorschläge hast oder Fehler gefunden hast in der Doku/Code melde dies. Wenn es in meinen Bereich fällt werde ich es beheben.

Mir ist klar, dass CUL_HM quasi eine Programmier-oberfläche bietet -aber keine simple-user oberfläche. Üblicher weise werden auf den komfortablen oberflächen etliche optionen versteckt/verboten,... erst dann kann man easy-use erstellen. Das wäre ein layer operhalb. CUL_HM bildet nur HM-möglichkeiten ab.

@Zrrronggg!

Wenn du ein einheitliches Konzept zur Adressenvergaben über mehrere Familien durchsetzen willst, werde ich mich daran halten (falls möglich). Wende dich hierzu an das Development forum. Hier macht diese Diskussion keinen Sinn.

ZitatDie Adresse des I/O Adapter verhält sich anders als die der sonstigen Devices

ja, ist ja auch kein Protokoll-endpunkt. Der reicht nur durch - draht eben (HMLAN = inteligenter Draht)
Aus sicht den Endpukts sieht es wieder anders aus.

ZitatSpeziell die Kernaussagen zur HM Adresse sind bei den beiden Anwendungsfälle (Gerät vs IO Device) exakt gegenteilig

nein. Die Adresse MUSS für JEDEN Empfänger eindeutig sein. Im Fall von IOs sind das keine Endpunkte. Der User sollte wissen, dass er dem FHEM nicht eine Adresse eines Device geben darf (die Chancen stehen schlecht bei 1:16mio). Alles andere ist
Ich kann dies im Einsteigerdoc klar legen. Bisher habe ich das Kapitel komplett IOs ausgespart.
Mehr sehe ich aktuell nicht zu tun.

Im Einsteigerdoc werde ich zufügen:

Code Auswählen

Die HMID der Zentrale wird vom User festgelegt. Die Zentrale kann mehrere HMIds nutzen. Sie werden über das Attribut HMId im jeweiligen IO device festgelegt.

mit HMInfo configCheck und update habe ich begonnen, dem User einen check an die Hand zu geben, was alles fraglich ist. Das will ich noch ausbauen - es gibt hier noch ein paar mehr kommandos, die den User helfen sollen, einen Überblick zu bekommen.

Gruss Martin