FHEM Forum

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
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:
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

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:
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   ;D


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

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


lieber

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

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.

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.

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.

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.

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

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

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

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

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.

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
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:
# 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 (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:
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

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)

Hallo,

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

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

Und speziell bei HM-Lan http://www.fhemwiki.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter (http://www.fhemwiki.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter)
findet sich die Passage im Wikitext:
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  8)

Grüße

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:
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

ZitatWenn 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.

ich will gar nichts DURCHSETZEN.  Ich mache nur Vorschläge. Und zwar insbesondere solche, wie man Anfängern den Einstieg erleichtern kann. Dabei geht es in der Regel nur um Kleinigektien in der Benennung. Ich habe mich vor ca. 2 Jahren dafür eingesetzt,  den begriff "Hauscode" nur noch auf FS20 anzuwenden, weil die Verwendung dieses Begriffes für die verschiedensten Sachen (insbesonder die FHT-ID) bei Anfängern für viel Verwirrung gesorgt hat.  Das ist heute besser und in der Tat haben wir da kaum noch Nachfragen. Ich hatte gehofft, wir könnten so was noch mal wiederholen, also durch reine Namesverwendung Verwirrung minimieren.

Ich verstehe deine prinzipiellen Anmerkungen, die vor allem aus Entwicklersicht  bzw technisch sicher stichhaltig sind. Der Anfänger kapiert das aber oft nicht oder erst nach den ersten Verzweiflungen.

Zitat

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.

Natürlich! Ich weiss das. Das ist aber eine reich technische Argumentation. Für den Anfänger ist
1. der CUL und der HMLAN im Verhalten quasi gleich, der Rest wird schon gar nicht druchdrungen
2. und prinzipiell andere Geräte als alle anderen Komponenten.

Die Frage ist eben was den einfacheren Zugang ergibt: Versuchen das alles zu erklären oder... eben einfach die Adresse in einem Fall anders zu nennen. (und dann auf Wunsch später erklären, wenn der Anfänger die ersten Erfolge hatte)

Zitat

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

nein.

Die Kernaussage aus der Sicht des Anweders - und zwar insbesondere wenn er mit anderen Systeme schon Erfahrung gesammelt hat ist:
- Die Adressen der Geräte kannst du nicht setzen (anders als bei FS20 oder IT oder FHT)
- Die Adresse des IODevices MUSST du selber setzen (anders als bei FS20 oder IT)

Kombiniert kommt dabei also raus: "die HM-ID kannst du nicht setzen aber muss du selber setzen."

Hm.

Das ist einfacher zu verstehen (und NUR darum gehts mir) wenn man nicht den selben Begriff verwendet.

Deine Ergänzungen zum Einsteigerdok sind sicher gut und reichen vielleicht auch. Ich persönlich würde es trotzdem besser finden, bei der HM-ID der Geräte z.b. von HM-Adresse zu reden.

Aber DURCHSETZEN? Nope.

@Puschel76

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.

ZitatIch wüsste jetzt nicht was dort unverständlich beschrieben ist

Bestens. Der Artikel ist in der Grundanlage von mir, diese Formulierung ist von mir.
Ich kann also Erklären  :-)


Was ich hier in diesem Thread anmerke ist, das diesen klaren Worten nur die leider ebenso klaren Worte aus der Einsteigerdoku

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.

exakt entgegen stehen!

Nur darum geht es hier!

Und man kann das nun versuchen zu erklären warum beides stimmt obwohl es echt nicht so klingt (Martins Favorisierter Weg), oder man kann einfach in einem der beiden Fälle eine anderes Wort verwenden, z.b. für die Geräte "HM-Adresse" (das ware dann analog zu dem bereits seit langem verwendeten Namen bei FHT).

Das ist schon alles.


Zuletzt:Viele die CUL oder CUNO für HM verwenden sehen den von dir zitierten Artikel nicht, da er über den HM-LAN Konfigurator geht. Ich habe auch schon drüber nachgedacht, da was im CUL Artikel zu ergänzen.

Nur: ich habe keinen CUL in frMode HM und will keine Sachen sagen, die ich nicht selber überprüfen kann.

sorry - ich komme nicht mit

HMId ist an vielen stellen exakt so verwendet wie ich es verstehe.
dass sie im IO veränderbar ist kann man erwähnen.

Um etwas zu vereinheitlichem muss man es bei den Entwicklern einkippen. Wenn keiner mitmacht passiert es nicht. Durchsetzen oder nicht, egal wie du es nennst.

Der User darf NIE den eindruck bekommen, die Adresse des IO device ist etwas grundlegend anderes als die eines device. Das ist ein-und-das-selbe. Alle reden mit einander und nutzen diese Adresse.
Nur die von der Zentrale - und die der virtuellen devices - und die,welche von panstamp programmiert werden ...
werden vom User vorgegeben - und müssen mit denen von HM-devices abgeglichen werden. Das solle man auch so beschreiben

Gruss Martin

Okay, ich geb auf.

Du verstehts ganz offensichtlich nicht, was ich meine.

Macht nix, ist nicht mein Problem, nur das der Anfänger.

Grüezi Puschel74,

Vielen Dank für die Antwort.

Zitat von: Puschel74 am 12 Januar 2014, 09:11:59
Und speziell bei HM-Lan http://www.fhemwiki.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter (http://www.fhemwiki.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter)
findet sich die Passage im Wikitext:

Code Auswählen Erweitern

define HMLAN1 HMLAN <IP Adresse>:1000
attr HMLAN1 hmId 123ABC
Ich wüsste jetzt nicht was dort unverständlich beschrieben ist

Wie ich geschrieben habe, hat es eine 'unendliche Menge an Dokumentation'. Der von Dir zitierte Text ist auch für mich verständlich.

Da ich einen CUL habe, war für mich als Anfänger nicht ersichtlich, dass dieser wiki-Text wesentliche Elemente für dessen Einbindung aufzeigt. Sorry!

Schönen Abend
Marcel

Hallo Martin,

Zitat von: martinp876 am 12 Januar 2014, 16:00:45
HMId ist an vielen stellen exakt so verwendet wie ich es verstehe.

Ja, wie du es verstehst. Im HM-Code, in der commandref, aber nicht von den Wiki-Schreibern und sonstigen Foren-Helfern.

Und Bitte: Diese und meine nachfolgenden Äußerungen sind nicht negativ gemeint! Ich schätze deine Leistungen mehr als du glaubst.

ZitatDer User darf NIE den eindruck bekommen, die Adresse des IO device ist etwas grundlegend anderes als die eines device. Das ist ein-und-das-selbe.

Ja, aus (nochmals der Hinweis) technischer Sicht. Die HM-Zentrale, egal ob CUL, HM-LAN, HM-USB ist aus Anwender-Sicht etwas anderes, als die Devices. Und deshalb werde ich dabei bleiben, dass diese eine (veränderbare und festzulegende) HM-ID hat und die Devices eine (festgelegte bzw. unveränderbare) ID haben.

ZitatAlle reden mit einander und nutzen diese Adresse.

Nein, nur einer regiert! Und das ist die Zentrale (hier: Fhem i.V.m. CUL/HM-LAN/HM-USB). Diese genießt eine Sonderstellung (auch aus technischer Sicht), warum dann nicht auch in der Benamung ihrer ID als HM-ID?

Wie erklärt es sich dem Anwender, dass er die HM-ID der Zentrale konfigurieren muss, die HM-ID der Devices aber vorgegeben und unveränderbar ist?
Zudem ist bei Devices mit Channels die ID nur beim Device 6-stellig, bei den Channels aber 8-stellig. Wenn bereits die Benamung (in den Erläuterungen, ich rede nicht vom Code!) unterschiedlich ist, ist dies mM viel einfacher rüberzubringen bzw. zu erklären.

Und Martin... es gibt wirklich eine andere Betrachtungsweise als die technische, nämlich die des Anwenders, der seine Sachen "einfach nur" ans Laufen bringen möchte.

Gruß
Thomas

@Marcel: Dir braucht wirklich nichts leid zu tun. Dieser, dein, Thread hätte von "uns" nicht "zweckentfremdet" werden dürfen.
Sorry dafür.

Hallo Thomas

ZitatDie HM-Zentrale, egal ob CUL, HM-LAN, HM-USB ist aus Anwender-Sicht etwas anderes
darf es aber nicht.

Ind warum glaubt ihr, der User sei dumm? Esr könnte es nicht verstehen?
Auch in Wiki (da stehen keine Artikel von mir) wird es in gleicher weise verwendet. Offensichtlich gibt es auch hier nicht nur deine Sicht der Dinge. Wiki ist an vielen Stellen nicht konsistent.
Der User MUSS aufpassen, das diese Adresse korrekt zu vergeben - da beisst die Maus keinen Faden ab und da kann es auch nichts zu diskutieren geben. Das kann ich auch nicht ändern.
###Und deshalb werde ich dabei bleiben, dass diese eine (veränderbare und festzulegende) HM-ID hat und die Devices eine (festgelegte bzw. unveränderbare) ID haben.
korrekt, hatte ich nie wiedersprochen - und weiter?

ZitatNein, nur einer regiert! Und das ist die Zentrale

falsch. Alle können miteinander reden, so die gepeert sind - sorry, das ist systemphilosophie von HM, auch nicht von mir.

ZitatWie erklärt es sich dem Anwender, dass er die HM-ID der Zentrale konfigurieren muss, die HM-ID der Devices aber vorgegeben und unveränderbar ist?

sags ihm einfach - der User ist nicht dumm.

ZitatZudem ist bei Devices mit Channels die ID nur beim Device 6-stellig, bei den Channels aber 8-stellig.

habe ich alles sauber dargelegt im Dokument. Der User muss sowieso wissen, was ein Device ist und was ein Channel. Und die Adresse ist NUR im Device.

ZitatUnd Martin... es gibt wirklich eine andere Betrachtungsweise als die technische, nämlich die des Anwenders, der seine Sachen "einfach nur" ans Laufen bringen möchte.

schon klar. Ich erwarte nicht, dass der Anwender sich um die Adresse im Detail kümmert, muss er ja auch nicht. Aber die meisten werden es verstehen - tun sie schon jetzt soweit nötig.
Klar, dass der Anwender nur eine geringe Fehlerquote hat 16mio Möglichkeiten....

Deine Sichtweise ist, dem Anwender für das gleich verschiedene Namen einzureden, nur weil das eine Einstellbar ist, das andere (systembedingt) fix gegeben ist. Ich sehe leider überhaupt nicht, dass dies für den User irgendwie einfacher sein sollte und warum man darüber nicht offen reden kann. Schlussendlich bleibt es doch, was es ist, eine Adresse, die stimmen muss.

Ein Grund, warum ich Wiki nur bedingt gut finde ist, dass die Grundlagen nicht erklärt werden - in einer Art Tutorial.

Sorry, wenn ich hier eine feste Meinung habe und nicht berücksichtige, wer schon was in Wiki geschrieben hat und nicht ändern will. Ich habe mir alle Euere Argumente genau angehört! , aber leider hat mich keines überzeugt.
Defacto habe ich es im Einsteigerdoc durchgängig so genutzt und meine Begriffe definiert, das werde ich so beibehalten. Es hat einen Leven für User, die tiefer einsteigen wollen (sicher sind fehler in doc... sorry for that). Im Code hat sich nichts geändert...

Ich sehe auch keine Verwirrung bei den Usern - es gab ein Problem in einer Darstellung, noch nicht einmal operationell. Auf meine Frage, wo die Verständnnissprobleme sind habe ich keine Antwort erhalten - und im homematic-threat habe ich viele Probleme gesehen, dieses gehört nicht wirklich dazu.
Die Definition im Einsteigerdoc wird erweitert - und evtl werde ich ein Kapitel zu IO devices einfügen. Evtl gibt es dazu schon etwas in Wiki?

Wie gesagt, sich verstehe die Aufregung eigentlich nicht.
Wo in Wiki sind die Beispiele, in dem HMID eine Ausschliesslichkeit auf IOs darlegt und wo werden die im Protokoll referenzierten Adressen der Devices beschrieben? Wo wird die Vergaberegel der HMId für IO devices festgelegt/ausgezeigt? Nur dass ich mir ein Bild machen kann - etwas wirklich missverständliches habe ich nicht gefunden

Nicht für ungut, die Diskussion finde ich ok - ich hoffe auch für euch, selbst wenn wir an Ende nicht einig werden würden (was ich nicht hoffe)

Gruss Martin

Hi,

Zitat von: martinp876 am 13 Januar 2014, 14:04:28... Sorry, wenn ich hier eine feste Meinung habe und nicht berücksichtige, wer schon was in Wiki geschrieben hat und nicht ändern will.

Hmmm... ok, ich nehme für mich mit, dass es aussichtslos ist, da du das Geschriebene in deinem Sinne fehlinterpretierst. Und da die Resonanz gering ist, andere Developer auch nichts dazu sagen (ein Thread im Developer-Teil ist den Nicht-Developern übrigens nur zum Lesen freigegeben!) sowie ich - so lese ich es wenigstens aus deinen Antworten (möglicherweise auch eine Fehlinterpretation) - deiner Ansicht nicht die nötige Weitsicht habe, erübrigt sich weiteres.

ZitatIch habe mir alle Euere Argumente genau angehört! , aber leider hat mich keines überzeugt.

Ne, schon klar, gleicher Kontext, aber egal. Ich mache für mich dann hier auch Schluss und bin raus aus dieser "Diskussion".

Gruß
Thomas

Zitatich nehme für mich mit, dass es aussichtslos ist, da du das Geschriebene in deinem Sinne fehlinterpretierst.

die Einstellung von dir finde ich schade.
Ich sehe schon, dass es (mehr als) 2 Meinungen gibt. Du könntest mich nicht von deiner überzeugen, ich dich nicht von meiner. Ein Fehler ist dies von keinem, m.M. auch keine Fehlinterpretation. 

Der Code und die gesamte web-oberfläche ist nicht mit diesen Begriffen belastet (ausser die HMId im IO-Device - da willst du es sowieso).

Mein Dokument, in dem ich zumindest versuche Hintergründe zu vermitteln, ist hoffentlich weitgehend in sich schlüssig. Da komme ich nicht umhin es offen zu legen.
In Wiki kannst du (und wer auch immer) es beschreiben wie du willst. Da schreiben ich nichts. Wie gesagt, auch dort gibt es einträge die exakt meine sichtweise wiederspiegeln.
Leider hast du mir nicht gezeigt, wo die Widersprüche sind und wo die User mit den Problem-threats, die Wiki-einträge,....

Dass andere Developer nicht reagieren wundert mich nicht - daher sehe ich auch keine chance auf Vereinheitlichung solcher Kleinigkeiten. Außerdem ist es wirklich nur ein geringes Detail - da gibt es m.E. erheblich grössere Dinge, die man in Angriff nehmen könnte

Gruss Martin

Hi,

hmmm... evtl. wäre keine Antwort die bessere Antwort gewesen, aber ...

Zitat von: martinp876 am 13 Januar 2014, 19:19:53die Einstellung von dir finde ich schade.

Hattest du mal einen Rhetorik-Kurs? Du glaubst gar nicht, was ich von deiner manifestierten Ansicht halte

Zitat...(ausser die HMId im IO-Device - da willst du es sowieso).

Wo schrieb ich, das ich was "will"?

ZitatMein Dokument, in dem ich zumindest versuche Hintergründe zu vermitteln, ist hoffentlich weitgehend in sich schlüssig.

Nun... die Fhem-Einsteiger-Doku habe ich mir anfangs "gegeben". Und - jetzt spreche ich nur für mich! - den HomeMatic-Teil habe ich kurz nach Beginn nur noch überflogen und mir gesagt: "Zu technisch und theoretisch, sowas brauchst du (also ich) nicht." Ich lerne mehr an Beispielen statt an irgendwelchen Schaubildern. Aber(!): Meine "Ansprüche" an Hausautomation sind - im Vergleich zu manch anderen Szenarien hier - sehr "niedrig". Mir fehlt vor allem einfach die Zeit. Da lerne ich mehr und schneller durch das Wiki und die Problemschilderungen und die Verfolgung dieser Threads hier im Forum und die dort stehen Code-Beispiele.

Und warum fehlt dir im Wiki eine Pendant zu deiner Einsteiger-Doku? Entweder reicht deine Doku oder nicht. Warum dann noch etwas weiteres, das auch noch ständig gepflegt bzw. im Einklang mit der fortschreitenden Entwicklung im Bereich HomeMatic gehalten werden muss?

ZitatDa komme ich nicht umhin es offen zu legen.

Wie war das doch noch gleich mit der Rhetorik (war "es" vorher versteckt?)?

ZitatIn Wiki kannst du (und wer auch immer) es beschreiben wie du willst.

Na, na... deinen Segen brauche ich nicht, aber dennoch Danke.

ZitatDa schreiben ich nichts.

Hmmm... mW machen das nur einige Entwickler, wenn ich das richtig mitbekomme, also kein Alleinstellungsmerkmal. Starte doch mal eine Umfrage hier im Forum, woher die Anwender das Wissen zur Bewältigung/Umsetzung ihrer Anwendungsszenarien überwiegend beziehen. Aus der commandref? Aus der Einsteigerdoku? Aus dem Wiki? Aus dem (Mit-)Lesen/Suchen von Threads im Forum?

ZitatWie gesagt, auch dort gibt es einträge die exakt meine sichtweise wiederspiegeln.

"Exakt"? Mir drängt sich die Frage nach Fundstellen/Beispielen auf, aber lassen "wir" es besser?

ZitatLeider hast du mir nicht gezeigt, wo die Widersprüche sind und wo die User mit den Problem-threats, die Wiki-einträge,....

Hmmm... ich habe schon "gezeigt", aber es kam/kommt nicht rüber... kann man so oder so sehen.

ZitatDass andere Developer nicht reagieren wundert mich nicht - daher sehe ich auch keine chance auf Vereinheitlichung solcher Kleinigkeiten. Außerdem ist es wirklich nur ein geringes Detail - da gibt es m.E. erheblich grössere Dinge, die man in Angriff nehmen könnte

Also Peanuts?

Warum engagierst du dich dann so?

Für mich bleibt festzuhalten: Deine Position ist fest. Dann ist es eben so. Kein Problem! Darauf habe ich schon anfangs hingewiesen. Manchmal führen die Wege eben nicht zueinander.

Gruß
Thomas

Leutz,

Martins Verdienste im Bereich HM sind sicher absolut unstrittig.
Ich bin der Sache klar Rohans Ansicht, ich glaube da hat Martin nicht recht und ich glaube er versteht uns auch nicht. Woran das liegt weiss ich nicht, vielleicht bringen wir unser Anliegen nicht richtig rüber.


Damit ist das Thema für mich erledigt, ich glaube nicht, das weiteres insistieren und pingongartiges vortragen nur leicht abgewandelter Argumente in immer gereizterem Ton etwas bringt

Ich glaube eher , das die Diskussion vom Stil her gerade richtig aus dem Ruder läuft.  Es ist es sicher nicht wert, das wir uns ernsthaft "zanken", wir sind eben nicht einer Meinung, Martin hat quasi die Machtpostition inne UND wegen seiner geleisteten Arbeit ist das auch nicht gerade ungerecht oder so. Wir konnten ihn nicht überzeugen, fertich.

Ich schlage vor, wir hören jetzt genau hier auf, bevor wir uns hinterher noch ärgern.