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
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
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
@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.
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
Damit waere Dein Fall identisch mit dem von 3dmanipulator.
Kannst du bitte auch das homeId Attribut setzen, und pruefen, ob das Problem noch auftaucht?
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...
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.
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
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.
@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
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.