ZWave_Endpoint_6.0 nach reboot aufgetaucht

Begonnen von 3dmanipulator, 16 Mai 2015, 14:30:26

Vorheriges Thema - Nächstes Thema

3dmanipulator

hallo,

ich bin noch total neu in diesem thema.

ich habe 2 sensoren und eine dimmer an einem razberry angelernt und auch assoziiert; und einen primitiven svg plot generiert.

nachdem ich nun den raspberry neu gebootet habe hat mir fhem drei neue devices eingerichtet:
ZWave_Endpoint_6.0, 5.0 und 7.0.

bei list gibt es folgende info:
Internals:
   DEF        00060600 6
   IODev      razberry
   NAME       ZWave_Endpoint_6.0
   NR         33
   STATE      open
   TYPE       ZWave
   homeId     00060600
   id         06
   Readings:
     2015-05-16 13:54:30   luminance       362 Lux
     2015-05-16 13:58:30   reportedState   open
     2015-05-16 13:58:30   state           open
     2015-05-16 13:55:50   temperature     25.3 C
     2015-05-16 13:58:59   wakeup          notification
Attributes:
   IODev      razberry
   room       ZWave

beim eigentlichen gerät mit list diese:

Internals:
   DEF        c3652eea 6
   IODev      razberry
   NAME       testsensor
   NR         25
   STATE      closed
   TYPE       ZWave
   homeId     c3652eea
   id         06
   Readings:
     2015-05-16 11:27:37   CMD             ZW_APPLICATION_UPDATE
     2015-05-15 09:32:21   UNPARSED        WAKE_UP 028405
     2015-05-16 11:31:18   alarm_type_00   level ff node 06 seconds 0
     2015-05-15 17:14:58   assocGroup_01   Max 05 Nodes
     2015-05-03 16:06:58   assocGroup_03   Max 01 Nodes 01
     2015-05-04 18:31:02   basicReport     00
     2015-05-14 15:45:18   basicSet        ff
     2015-05-15 16:17:16   battery         100 %
     2015-05-15 16:37:18   configIlluminationReportThreshold 5
     2015-05-16 11:55:51   configIlluminationReportsInterval 300
     2015-05-15 16:37:58   configIntervalOfTemperatureMeasuring 60
     2015-05-15 01:04:27   configMaximumTemperatureResultingInRed87 23
     2015-05-05 15:18:22   configMotionSensorSSensitivity 10
     2015-05-15 16:39:20   configTemperatureReportThreshold 1
     2015-05-16 11:58:11   configTemperatureReportsInterval 300
     2015-05-16 13:31:14   luminance       300 Lux
     2015-05-15 00:24:20   model           FIBARO System FGMS001 Motion Sensor
     2015-05-15 00:24:20   modelConfig     fibaro/fgms.xml
     2015-05-15 00:24:20   modelId         010f-0800-1001
     2015-05-16 13:34:32   reportedState   closed
     2015-05-16 13:34:32   state           closed
     2015-05-16 13:30:53   temperature     25.4 C
     2015-05-16 12:00:51   transmit        OK
     2015-05-16 13:34:42   wakeup          notification
     2015-05-16 11:28:48   wakeupReport    interval 20 target 1
   WakeUp:
     1306038502030506
Attributes:
   IODev      razberry
   classes    SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM MARK SENSOR_BINARY SENSOR_MULTILEVEL SENSOR_ALARM
   eventMap   open:51
   room       ZWave
   verbose    3

die werte des sensors kommen jetzt bei ZWave_Endpoint_6.0 an.

irgendwie weiß ich jetzt echt nicht weiter. es fehlt ja eine homeid etc.

..und das svg  bekommt natürlich auch keine infos mehr.

habe ich da was beim grundsätzlichen anlernern der geräte falsch gemacht?

grüße horst


raspberry pi, razberry, fibaro sensor, fibaro dimmer,  nodon fb, tkb dual dimmer Switch, milight e27 + stripe, hmlan, hm-TC, hm-RT

scooty

#1
Passiert bei mir auch, allerdings nicht nur nach einem "shutdown restart", sondern auch manchmal nach set oder get auf ein ZWave Device.
Aber nur, wenn autocreate eingeschaltet ist.
Ohne autocreate gibt's den Spuk natürlich nicht.

Habe inzwischen 11 ZWave Devices im Einsatz, die durch autocreate in wirklich willkürlicher Folge und Anzahl als "ZWave_Endpoint_xx.0" immer 'mal wieder neu angelegt werden. Allerdings sind diese nicht funktional, die "wirklichen" Devices funktionieren weiterhin.

Im Log steht dann z.B.:
2015.05.16 17:27:08 2: ZWave get ZWave_SWITCH_MULTILEVEL_23 configRGBColor
2015.05.16 2015.05.16 17:27:35 3: UNDEFINED ZWave_Endpoint_11.0 ZWave 000b0320 11, please define it
2015.05.16 17:27:35 2: autocreate: define ZWave_Endpoint_11.0 ZWave 000b0320 11
2015.05.16 17:27:35 2: autocreate: define FileLog_ZWave_Endpoint_11.0 FileLog /opt/fhem/log/ZWave_Endpoint_11.0-%Y-%m.log ZWave_Endpoint_11.0
2015.05.16 17:27:49 2: ZWave get ZWave_SWITCH_MULTILEVEL_23 ccCapabilityGet
2015.05.16 17:27:58 2: ZWave get ZWave_SWITCH_MULTILEVEL_23 ccStatus
2015.05.16 17:28:26 2: ZWave get ZWave_SWITCH_MULTILEVEL_23 zwavePlusInfo
2015.05.16 17:29:51 2: ZWave set ZWave_SWITCH_MULTILEVEL_23 off
2015.05.16 17:30:21 3: UNDEFINED ZWave_Endpoint_20.0 ZWave 000b0320 20, please define it
2015.05.16 17:30:21 2: autocreate: define ZWave_Endpoint_20.0 ZWave 000b0320 20
2015.05.16 17:30:21 2: autocreate: define FileLog_ZWave_Endpoint_20.0 FileLog /opt/fhem/log/ZWave_Endpoint_20.0-%Y-%m.log ZWave_Endpoint_20.0
2015.05.16 17:31:04 2: ZWave get ZWave_SWITCH_MULTILEVEL_23 swmStatus
2015.05.16 17:32:01 3: UNDEFINED ZWave_Endpoint_9.0 ZWave 000b0320 9, please define it
2015.05.16 17:32:01 2: autocreate: define ZWave_Endpoint_9.0 ZWave 000b0320 9
2015.05.16 17:32:01 2: autocreate: define FileLog_ZWave_Endpoint_9.0 FileLog /opt/fhem/log/ZWave_Endpoint_9.0-%Y-%m.log ZWave_Endpoint_9.0

obwohl die Nodes 11, 20 und 9 in FHEM schon vorhanden sind.
Kann es mit der Menge und zeitlichen Nähe von sets und gets zusammenhängen (passieren bei einem "shutdown restart" ähnliche Mengen an set/gets ?)

Liefere gerne weitere, detaillierte Infos wenn gewünscht (bitte Angabe, was und wie genau, bin in ZWave nicht so fit), kann das Verhalten ja quasi provozieren.

Viele Grüße,
Andreas

PS:Mein bisheriger Workaround nach Auftreten der doppelten Nodes (VORSICHT: Nur anwenden, wenn die anderen ZWave-Devices schon umbenannt wurden, also nicht mehr die Standardnamen haben, die durch autocreate vergeben werden, sonst sind ALLE ZWave-Devices gelöscht!!!):
delete ZWave_Endpoint_.*
delete FileLog_ZWave_Endpoint_.*

PPS: Ohne autocreate erscheint im Log zumindest
2015.05.16 18:35:49 3: UNDEFINED ZWave_Endpoint_12.0 ZWave 000b0320 12, please define it
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

scooty

Und hier noch das fhem.log mit verbose 5 (aufgetreten nach ein paar sets):
2015.05.16 18:43:06 5: ZWDongle/RAW: /01080004001402840766
2015.05.16 18:43:06 5: SW: 06
2015.05.16 18:43:06 5: ZWDongle_Read ZW_Dongle: 00040014028407
2015.05.16 18:43:06 5: ZW_Dongle dispatch 00040014028407
2015.05.16 18:43:06 4: ZW_Dongle CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:028407
2015.05.16 18:43:06 3: UNDEFINED ZWave_Endpoint_20.0 ZWave 000b0320 20, please define it
2015.05.16 18:43:06 5: Triggering global (1 changes)
2015.05.16 18:43:06 5: Notify loop for global UNDEFINED ZWave_Endpoint_20.0 ZWave 000b0320 20
2015.05.16 18:43:06 5: battStatus: not on any display, ignoring notify
2015.05.16 18:43:06 5: ZWDongle/RAW: /0109000400140380036402
2015.05.16 18:43:06 5: SW: 06
2015.05.16 18:43:06 5: ZWDongle_Read ZW_Dongle: 0004001403800364
2015.05.16 18:43:06 5: ZW_Dongle dispatch 0004001403800364
2015.05.16 18:43:06 4: ZW_Dongle CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:03800364
2015.05.16 18:43:06 3: UNDEFINED ZWave_Endpoint_20.0 ZWave 000b0320 20, please define it
2015.05.16 18:43:06 5: Triggering global (1 changes)
2015.05.16 18:43:06 5: Notify loop for global UNDEFINED ZWave_Endpoint_20.0 ZWave 000b0320 20
2015.05.16 18:43:06 5: battStatus: not on any display, ignoring notify


Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

rudolfkoenig

@3dmanipulator: bei dir faellt auf, dass das IODev des angelegten Geraetes nicht dem der "Richtigen" entspricht. Ich vermute, dass dein ZWdongle die Macke hat, manchmal eine falsche homeId zu melden.
Kannst du bitte das homeId ZWdongle Attribut auf das richtige homeId setzen, und beobachten, ob das Problem wieder auftritt?

@scooty: kannst du bitte zeigen, was dein ZWDongle-homeId ist?
Das Problem koennte bei dir das Gleiche sein, wenn du zwischendurch ein "get ZWDongle homeId" durchgefuehrt hast.

scooty

Hallo Rudolf,

anbei ein list meines ZW_Dongle:
Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyACM0@115200
   DeviceName /dev/ttyACM0@115200
   FD         26
   NAME       ZW_Dongle
   NR         311
   PARTIAL
   RAWMSG     0004000b028407
   ReadTime   1431863240.7515
   STATE      Initialized
   TYPE       ZWDongle
   ZW_Dongle_MSGCNT 805
   ZW_Dongle_TIME 2015-05-17 13:47:20
   homeId     d79c8805
   nrNAck     0
   Matchlist:
     1:ZWave    .*
   Readings:
     2015-04-15 13:45:41   ctrlCaps        PRIMARY
     2015-05-17 08:09:54   homeId          HomeId:d79c8805 CtrlNodeId:01
     2015-04-22 14:28:38   neighborList_1  8,12,13,14,15
     2015-05-16 18:39:14   neighborList_10 0
     2015-04-22 14:23:04   neighborList_11 8,12,13,14,15
     2015-04-22 14:24:39   neighborList_12 8,13,14,15
     2015-04-22 14:26:19   neighborList_13 8,12,15
     2015-04-22 14:27:01   neighborList_14 8,12,15
     2015-04-22 14:27:50   neighborList_15 8,12,13,14
     2015-04-23 20:52:20   neighborList_20 8,12,13,15
     2015-05-16 17:41:59   neighborList_23 8,12,13,14,15
     2015-05-16 17:42:06   neighborList_24 8,12,13,15
     2015-04-22 14:18:31   neighborList_8  12,13,14,15
     2015-04-22 14:22:28   neighborList_9  8
     2015-04-16 22:23:54   nodeInfo_1      STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
     2015-04-16 22:23:38   nodeInfo_10     CONTROLLER GENERIC_CONTROLLER sleeping frequentListening:0 beaming:16 40kBaud Vers:3 Security:0
     2015-04-16 22:23:40   nodeInfo_11     ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-04-16 22:23:47   nodeInfo_12     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-04-16 22:23:49   nodeInfo_13     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-04-16 22:23:51   nodeInfo_14     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-04-16 22:23:57   nodeInfo_15     ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-04-23 20:52:10   nodeInfo_20     ROUTING_SLAVE SWITCH_REMOTE sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-05-16 17:39:46   nodeInfo_23     ROUTING_SLAVE SWITCH_MULTILEVEL listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-05-16 17:39:54   nodeInfo_24     ROUTING_SLAVE SWITCH_MULTILEVEL listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-04-16 22:23:33   nodeInfo_8      ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-04-16 22:23:35   nodeInfo_9      ROUTING_SLAVE THERMOSTAT sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-05-16 17:38:58   nodeList        1,8,9,10,11,12,13,14,15,20,23,24
     2015-05-17 08:09:53   state           opened
     2015-03-04 12:34:20   version         Z-Wave 3.99 STATIC_CONTROLLER
   SendStack:
Attributes:
   group      IO_Devs
   icon       cul_usb
   room       Global,ZWave


Home-ID müsste also die d79c8805 sein.

Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

rudolfkoenig

Damit waere Dein Fall identisch mit dem von 3dmanipulator.
Kannst du bitte auch das homeId Attribut setzen, und pruefen, ob das Problem noch auftaucht?

det.

Gleiches tritt bei mir auch auf und das homeID Attribut ist gesetzt (daran liegt das also offenbar nicht). Das Attribut allerdings funktioniert prima und verhindert seither falsche homeID nach shutdown restart.
Die list des Dongle sieht bei mir wie bei scooty aus - bis auf eine andere ID...

LG
det.

rudolfkoenig

Meinst du mit "Gleiches", dass das homeId des automatisch angelegtes Geraetes falsch ist? Wenn ja, dann muss das homeId des meldenden Geraetes (== ZWDongle) auch falsch sein, da ZWave_Parse es als erstes von diesem holt.

scooty

#8
Danke für den Tip mit dem homeID Attribut, bei mehrfachen shutdown restart oder komplettem Reboot des Pi sind bisher keine weiteren doppelten Nodes erstellt bzw. keine Meldungen "UNDEFINED ZWave_Endpoint_23.0 ZWave d79c8805 23, please define it" aufgetaucht.

Allerdings erscheinen nun die Meldungen
2015.05.17 15:36:14 3: UNDEFINED ZWave_Endpoint_23.0 ZWave d79c8805 23, please define it
für meine Zipato RGBW Bulbs (habe zwei im Einsatz) bei jeglichem Versuch, mit "get" Informationen aus ihnen auszulesen. Ich bin mir nicht sicher, ob das jetzt auch zu diesem Thema gehört (mache auch gerne ein neues Thema auf)?
Hier sind weitere Infos zu dem Phänomen:

List der Zipato RGBW Bulbs (ZWave_SWITCH_MULTILEVEL_23 / ZWave_SWITCH_MULTILEVEL_24):
Internals:
   DEF        000b0320 23
   IODev      ZW_Dongle
   NAME       ZWave_SWITCH_MULTILEVEL_23
   NR         403
   STATE      off
   TYPE       ZWave
   homeId     000b0320
   id         17
   Readings:
     2015-05-16 17:01:28   assocGroup_01   Max 01 Nodes 01
     2015-05-16 17:20:40   basicReport     63
     2015-05-16 18:32:56   configRGBColor  99
     2015-05-16 17:02:15   configShockSensor 16
     2015-05-16 17:01:35   model           Zipato RGBW LED Bulb
     2015-05-16 17:01:35   modelConfig     zipato/RGBBulb.xml
     2015-05-16 17:01:35   modelId         0131-0002-0002
     2015-05-16 17:33:19   reportedState   dim 99
     2015-05-17 15:14:35   state           off
     2015-05-16 18:41:42   transmit        OK
     2015-05-16 17:13:56   version         Lib 3 Prot 3.92 App 1.7
     2015-05-16 17:29:24   zwavePlusInfo   version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0600 userIcon:0600
Attributes:
   IODev      ZW_Dongle
   classes    ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY ASSOCIATION ASSOCIATION_GRP_INFO POWERLEVEL FIRMWARE_UPDATE_MD COLOR_CONTROL SWITCH_MULTILEVEL CONFIGURATION
   room       ZWave


Internals:
   DEF        000b0320 24
   IODev      ZW_Dongle
   NAME       ZWave_SWITCH_MULTILEVEL_24
   NR         405
   STATE      off
   TYPE       ZWave
   homeId     000b0320
   id         18
   Readings:
     2015-05-16 17:06:32   assocGroup_01   Max 01 Nodes 01
     2015-05-16 17:20:51   basicReport     00
     2015-05-16 18:32:56   configRGBColor  99
     2015-05-16 17:06:47   configShockSensor 16
     2015-05-16 17:05:48   model           Zipato RGBW LED Bulb
     2015-05-16 17:05:48   modelConfig     zipato/RGBBulb.xml
     2015-05-16 17:05:48   modelId         0131-0002-0002
     2015-05-16 17:33:22   reportedState   dim 50
     2015-05-17 15:14:35   state           off
     2015-05-16 18:41:42   transmit        OK
     2015-05-16 17:14:25   version         Lib 3 Prot 3.92 App 1.6
     2015-05-16 17:28:26   zwavePlusInfo   version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0600 userIcon:0600
Attributes:
   IODev      ZW_Dongle
   classes    ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY ASSOCIATION ASSOCIATION_GRP_INFO POWERLEVEL FIRMWARE_UPDATE_MD COLOR_CONTROL SWITCH_MULTILEVEL CONFIGURATION
   room       ZWave


Die unterschiedliche "version" (Node 23: App 1.7 / Node 24: App 1.6) machen mich schon etwas stutzig, ergeben aber keinen Unterschied im Verhalten.

Ein
get ZWave_SWITCH_MULTILEVEL_23 configRGBColor
erzeugt folgende Einträge im Log (verbose 5):
2015.05.17 15:38:15 4: HTTP FHEMWEB:::ffff:192.168.0.101:56288 GET /fhem&cmd=get+ZWave_SWITCH_MULTILEVEL_23+configRGBColor
2015.05.17 15:38:15 5: Cmd: >get ZWave_SWITCH_MULTILEVEL_23 configRGBColor<
2015.05.17 15:38:15 2: ZWave get ZWave_SWITCH_MULTILEVEL_23 configRGBColor
2015.05.17 15:38:15 5: SW: 0109001317037005010580
2015.05.17 15:38:15 5: ZWDongle/RAW: /06
2015.05.17 15:38:15 5: ZWDongle/RAW: /0104011301e8
2015.05.17 15:38:15 5: SW: 06
2015.05.17 15:38:15 5: ZWDongle_Read ZW_Dongle: 011301
2015.05.17 15:38:15 5: ZW_Dongle dispatch 011301
2015.05.17 15:38:15 5: ZWDongle/RAW: /010700131800
2015.05.17 15:38:15 5: ZWDongle/RAW: 010700131800/0002f1
2015.05.17 15:38:15 5: SW: 06
2015.05.17 15:38:15 5: ZWDongle_Read ZW_Dongle: 001318000002
2015.05.17 15:38:15 5: ZW_Dongle dispatch 001318000002
2015.05.17 15:38:15 4: ZW_Dongle CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.05.17 15:38:15 4: ZW_Dongle transmit OK for 18
2015.05.17 15:38:16 5: ZWDongle/RAW: /010b00040017057006010163f7
2015.05.17 15:38:16 5: SW: 06
2015.05.17 15:38:16 5: ZWDongle_Read ZW_Dongle: 00040017057006010163
2015.05.17 15:38:16 4: ZW_Dongle CMD:APPLICATION_COMMAND_HANDLER ID:17 ARG:057006010163
2015.05.17 15:38:16 3: UNDEFINED ZWave_Endpoint_23.0 ZWave d79c8805 23, please define it
2015.05.17 15:38:16 5: Triggering global (1 changes)
2015.05.17 15:38:16 5: Notify loop for global UNDEFINED ZWave_Endpoint_23.0 ZWave d79c8805 23


Wie man an den Readings der Bulbs sehen kann, funktionierten die gets zumindest gestern auch noch.
Die 10_ZWave.pm ist
# $Id: 10_ZWave.pm 8581 2015-05-14 19:21:06Z rudolfkoenig $

Die entprechenden "set .. configRGBColor" werden ohne Probleme angenommen.

Ich hoffe, mir kann jemand weiterhelfen.

Vielen Dank,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

det.

Zitat von: rudolfkoenig am 17 Mai 2015, 15:38:40
Meinst du mit "Gleiches", dass das homeId des automatisch angelegtes Geraetes falsch ist? Wenn ja, dann muss das homeId des meldenden Geraetes (== ZWDongle) auch falsch sein, da ZWave_Parse es als erstes von diesem holt.
Ja, genau so ist es. Der Dongel meldet irgendwie Murks und bekommt erst über das Attribut nachträglich die richtige ID zugewiesen. Vor Eurem Patch mußte ich nach jedem Neustart die ID prüfen (war fast immer falsch) und mit manuell angestoßenem  get ZWDongle_1 homeId die Id korrigieren.
LG
det.

3dmanipulator

@rudolfkoenig,
Erst mal danke für den Tipp, ich habe das Attribut gesetzt und werde die Sache beobachten und testen.

Bei mir hatten ja sowohl die devices als auch der razberry nach dem reboot eine völlig irre, aber gemeinsame homeid. Über die haben sie dann auch kommuniziert.
Mit gethomeid habe ich dann wieder die richtige Id bekommen, und ab da lief die Kommunikation wieder mit den richtigen devices. ( die falschen hab ich dann einfach gelöscht).

Vielleicht ein Problem bei der bootreihenfolge??

Grüße Horst
raspberry pi, razberry, fibaro sensor, fibaro dimmer,  nodon fb, tkb dual dimmer Switch, milight e27 + stripe, hmlan, hm-TC, hm-RT

rudolfkoenig

Eine weitere Ursache fuer die gleichen Meldungen/Aktionen ist, wenn ein Geraet sich meldet, der im ZWDongle bekannt ist, aber in FHEM nicht.
Ich habe deswegen den Namen leicht umgebaut in ZWave_Node_X. Nachkommastelle gibts nur, wenn es ein MULTI_CHANNEL Nachricht ist, mit Kanalnummer >= 1.
Fuer solche neuentdeckten Geraet sollte man trotzdem die Klassen zuweisen, z.Bsp. indem man auf dem Geraet selbst Inclusion durch Knopf-Druecken "bestellt". addNode im ZWdongle ist dafuer nicht notwendig.