Sporadisch werden neue endpointChildren erzeugt

[tomspatz]

Moin

das o.g. passiert immer mal zwischendurch.
Auch bei Devices die kein zweites, drittes device haben sollten.
Aktuell ein Danfoss LC-13 der auf einmal ein Kind hat.

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        c9cc092a 4098
   IODev      ZWDongle_0
   NAME       ZWave_Node_16.2
   NR         3046
   STATE      ???
   TYPE       ZWave
   ZWaveSubDevice yes
   endpointParent ThermostatKueche
   homeId     c9cc092a
   nodeIdHex  1002
Attributes:
   IODev      ZWDongle_0
   room       ZWave


Das ist Der "Vater" 

Code Auswählen Erweitern

Internals:
   DEF        c9cc092a 16
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     4905
   NAME       ThermostatKueche
   NR         217
   STATE       19.0 °C
   TYPE       ZWave
   ZWDongle_0_MSGCNT 4905
   ZWDongle_0_RAWMSG 00040010028407
   ZWDongle_0_TIME 2016-10-15 11:48:41
   ZWaveSubDevice no
   endpointChildren ZWave_Node_16.2
   homeId     c9cc092a
   isWakeUp   1
   lastMsgSent 1476524923.34193
   nodeIdHex  10
   Readings:
     2016-02-13 12:40:17   CMD             ZW_APPLICATION_UPDATE
     2016-10-15 11:48:41   battery         72 %
     2016-10-15 11:48:41   ccsOverride     no, unused
     2015-12-28 14:46:54   model           Danfoss Z Thermostat 014G0013
     2015-12-28 14:46:54   modelConfig     danfoss/z.xml
     2015-12-28 14:46:54   modelId         0002-0005-0004
     2016-09-26 17:22:15   neighborList    ZWDongle_0 FunkDose1 LichtWohnzimmerSchrank1A LichtWohnzimmerSchrank2A FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel DimmerWohnzimmer LichtFlur LichtBad DimmerSchlafzimmer
     2016-09-23 07:29:39   neighborUpdate  done
     2016-10-15 11:48:41   setpointTemp    19.00 C heating
     2016-10-15 11:48:43   timeToAck       0.028
     2016-10-15 11:48:43   transmit        OK
     2016-10-15 11:48:41   wakeup          notification
     2016-01-02 22:55:42   wakeupReport    interval 300 target 1
Attributes:
   IODev      ZWDongle_0
   alias      Thermostat Küche
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
   group      Heizung und Temperatur
   icon       hc_wht_regler
   neighborListPos 196.93650717675953,685.8774617168359
   room       Küche,System,ZWave
   stateFormat {sprintf(" %.1f °C",(ReadingsNum("ThermostatKueche","setpointTemp",0)))}

Warum passiert so etwas ?

Habe auch noch andere devices die so ein Quatch anstellen. FGK101, (nicht Temperatur, der ist belegt)

[rudolfkoenig]

Warum passiert so etwas ?

Programmierfehler ?

Wuerde mir sehr helfen, wenn du mit "attr zwdongle verbose 5" die ausloesende Roh-Nachricht hier posten koenntest.
Sonst  muss ich gruebeln, und das habe ich schon einmal hinter mir

[tomspatz]

hmmm
Ich kann das leider gar nicht nachvollziehen. Plötzlich sehe ich im webfrontend das neue device.
So wurde es scheinbar angelegt:

Code Auswählen Erweitern

2016.10.15 04:04:19 3: UNDEFINED ZWave_Node_16.2 ZWave c9cc092a 4098, please define it
2016.10.15 04:04:19 2: autocreate: define ZWave_Node_16.2 ZWave c9cc092a 4098
2016.10.15 04:04:20 2: autocreate: define FileLog_ZWave_Node_16.2 FileLog ./log/ZWave_Node_16.2-%Y.log ZWave_Node_16.2
Wobei der USB zwave Stick ja nicht im inklusionsmodus ist, bzw. war. (und ich zu diesem Zeitpunkt sicher im Bettchen war) Dieser beendet sich doch selbstständig nach einer Inklusion.
Und das Parent davon gibt es schon sein 28.12.2015 also auch nichts neues.
Auch ein Fibaro FGK101 hat sich ein, bzw. noch ein "Kind" geholt.
Aber ich habe leider keinerlei Ansatz zum Zeitpunkt etc.
Gerne helfe ich hierbei aus aber verbose 5 setzten und ein Paar Wochen warten, das bringt es nicht.
LG
Tom

[Klaus.A]

Mit diesen "Endpoints" habe ich sonderbare Erlebnisse. Mir ist übrigens auch nicht ganz klar wozu die gut sein sollen (habe auch nichts dazu gefunden).

Hier kurz was passiert ist (oder was nicht passiert ist):

Ich hatte ZWave mit dem Aeon Labs Stick 2 angefangen. Das war "nicht-ZWave+".  Als ich den Fibaro Dimmer 2 (FIBARO System FGD212 Dimmer 2, modelId: 010f-0102-1000) aufgenommen hatte, waren 2 Endpoints vorhanden. Soweit so gut.

Jetzt Umstellung auf Aeon Labs Stick Gen5 (ZWave+). Erst alle alten Devices excludiert, Stick ausgewechselt, neu gestarted, Devices neu Includiert. Hat funktioniert. Nur gibt es jetzt keine dieser Endpoints mehr. Korrekt oder nicht? In den Readings sehe ich als "mcEndpoints" jetzt "total 2, different". Aber sie sind nicht da, und ich kann sie auch nicht erzeugen lassen.

FHEM habe ich laufend aktualisiert, zuletzt heute. Den Dimmer rausnehmen und nochmal aufnehmen - ok, wenn es sein muss ... kann ich machen sobald es die Zeit erlaubt.

Es gibt noch mehr Ungereimtheiten: Jetzt habe ich immer wieder, z.B. nach einem get configALL, aber auch sonst solche Meldungen im Log:

ZWDongle_ProcessSendStack: no ACK, resending message .... (numerischer Wert).

Die kommen haufenweise, obwohl alles funktioniert. Gesehen nach dem Update von heute. Das ist sicher eine andere Baustelle, hier nur als Anmerkung. Wichtiger sind mir diese Endpoints und die Frage wie das denn nach aktuellem Stand das korrekte Systemverhalten wäre.

Gruß, Klaus

[rudolfkoenig]

"Endpoints" werden erzeugt, wenn zu einem bekannten Geraet Nachrichten der Klasse MULTI_CHANNEL empfangen werden, und das angesprochene Kanal (aka Endpoint) nicht bekannt ist.

Ich habe die "please define it" Zeile mit der empfangenen Roh-Nachricht erweitert, update kommt ab morgen. Wenn damit ein Geraet angelegt wird, bitte die Roh-Nachricht hier zeigen.

[tomspatz]

@rudolfkoenig
wird das denn auch in verbose 3 geloggt?

[rudolfkoenig]

Ab dem morgigen update ja.

[tomspatz]

So da habe ich jetzt etwas

Code Auswählen Erweitern

2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
2016.11.12 16:55:25 2: autocreate: define ZWave_Node_14 ZWave c9cc092a 3584
2016.11.12 16:55:25 2: autocreate: define FileLog_ZWave_Node_14 FileLog ./log/ZWave_Node_14-%Y.log ZWave_Node_14

endpointParent davon ist:

Code Auswählen Erweitern

defmod FensterBuero ZWave c9cc092a 14
attr FensterBuero IODev ZWDongle_0
attr FensterBuero alias Fenster Büro
attr FensterBuero classes SENSOR_BINARY SENSOR_ALARM MULTI_CHANNEL ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC
attr FensterBuero devStateIcon open:fts_window_1w_tilt@red .*:fts_window_1w
attr FensterBuero group Fenster und Türen
attr FensterBuero icon fts_window_1w
attr FensterBuero neighborListPos 201.40439360109053,946.8894173875736
attr FensterBuero room Büro,System,ZWave

setstate FensterBuero closed
setstate FensterBuero 2016-11-14 00:55:07 UNPARSED BASIC 0c200d02023105014400000772
setstate FensterBuero 2015-12-26 08:11:10 assocGroups 3
setstate FensterBuero 2015-12-26 08:11:07 basicReport ff
setstate FensterBuero 2016-11-13 19:49:14 basicSet 0
setstate FensterBuero 2016-11-14 11:03:39 battery 74 %
setstate FensterBuero 2016-04-03 22:56:59 configInsensitivenessToTemperature12 0
setstate FensterBuero 2016-10-23 18:20:57 configStatusChangeSignalledByLED LEDTurnedOff
setstate FensterBuero 2016-01-09 15:29:45 config_15 0
setstate FensterBuero 2015-12-26 08:11:06 mcCapability_02 SENSOR_MULTILEVEL
setstate FensterBuero 2015-12-25 08:04:40 model FIBARO System FGK101 Door Opening Sensor
setstate FensterBuero 2015-12-25 08:04:40 modelConfig fibaro/fgk001.xml
setstate FensterBuero 2015-12-25 08:04:40 modelId 010f-0700-1000
setstate FensterBuero 2016-10-22 13:19:13 neighborList ZWDongle_0 FunkDose1 LichtWohnzimmerSchrank2A FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel DimmerWohnzimmer LichtFlur LichtBad DimmerSchlafzimmer LichtSchlafzimmerSchrank1A LichtBueroGabi
setstate FensterBuero 2016-10-22 12:44:28 neighborUpdate done
setstate FensterBuero 2016-11-13 19:49:14 reportedState closed
setstate FensterBuero 2016-11-13 19:49:14 state closed
setstate FensterBuero 2016-07-22 02:26:34 temperature 27.12 C
setstate FensterBuero 2016-11-14 15:44:24 timeToAck 0.052
setstate FensterBuero 2016-11-14 15:44:24 transmit OK
setstate FensterBuero 2016-11-14 15:44:21 wakeup notification
setstate FensterBuero 2016-01-11 08:27:36 wakeupReport interval 4000 target 1


und noch einen

Code Auswählen Erweitern

2016.11.14 03:54:14 3: UNDEFINED ZWave_Node_6.2 ZWave c9cc092a 1538, please define it. Triggered by 000410060c600d02023905014400000746.
2016.11.14 03:54:14 2: autocreate: define ZWave_Node_6.2 ZWave c9cc092a 1538
2016.11.14 03:54:14 2: autocreate: define FileLog_ZWave_Node_6.2 FileLog ./log/ZWave_Node_6.2-%Y.log ZWave_Node_6.2

endpointParent davon ist:

Code Auswählen Erweitern

defmod FunkDose1 ZWave c9cc092a 6
attr FunkDose1 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 room_map structexclude
attr FunkDose1 IODev ZWDongle_0
attr FunkDose1 alias Tannenbaum Büro
attr FunkDose1 classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD MARK SWITCH_BINARY METER SENSOR_MULTILEVEL
attr FunkDose1 devStateIcon on:ios-on-green off:ios-off
attr FunkDose1 group Steckdosen & Funksteckdosen
attr FunkDose1 icon message_socket
attr FunkDose1 neighborListPos 689.6143230671229,1001.2561315978934
attr FunkDose1 room Büro,System,ZWave
attr FunkDose1 webCmd :

setstate FunkDose1 off
setstate FunkDose1 2016-11-05 22:11:37 UNPARSED SENSOR_MULTILEVEL 06310704220000
setstate FunkDose1 2016-07-05 22:15:04 alarm_type_04 level 22
setstate FunkDose1 2015-12-19 16:48:16 assocGroup_1 Max 5 Nodes ZWDongle_0
setstate FunkDose1 2015-12-19 16:48:16 assocGroup_2 Max 5 Nodes
setstate FunkDose1 2015-12-19 16:48:16 assocGroup_3 Max 1 Nodes ZWDongle_0
setstate FunkDose1 2015-12-19 16:48:16 assocGroups 3
setstate FunkDose1 2015-12-19 16:48:52 configActionInCaseOfExceedingDefined52 and3Combined
setstate FunkDose1 2015-12-19 16:48:52 configAlarmDuration 600
setstate FunkDose1 2015-12-19 16:48:52 configAlwaysOnFunction functionInactive
setstate FunkDose1 2015-12-19 16:48:53 configDOWNValue 300
setstate FunkDose1 2015-12-19 16:48:53 configImmediatePowerReport 80
setstate FunkDose1 2015-12-19 16:48:53 configLEDRingIlluminationColourAtTheZ63 LEDRingFlashesRedBlueWhite
setstate FunkDose1 2016-10-17 17:05:36 configLEDRingIlluminationColourWhen61 illuminationTurnedOffCompletely
setstate FunkDose1 2015-12-19 16:48:53 configLEDRingIlluminationColourWhen62 illuminationTurnedOffCompletely
setstate FunkDose1 2015-12-19 16:48:53 configMeteringEnergyConsumedByTheWall49 functionInactive
setstate FunkDose1 2015-12-19 16:48:53 configOveloadSafetySwitch 65535
setstate FunkDose1 2015-12-19 16:48:53 configPowerLoadWhichWhenExceededMakes60 25000
setstate FunkDose1 2015-12-19 16:48:53 configPowerReportingFrequency 30
setstate FunkDose1 2015-12-19 16:48:53 configReactionToAlarms ALARMALL
setstate FunkDose1 2015-12-19 16:48:53 configRememberDeviceStatusAfterPower16 WallPlugMemorizesItsStateAfterA1
setstate FunkDose1 2015-12-19 16:48:53 configReportingChangesInEnergyConsumed45 10
setstate FunkDose1 2015-12-19 16:48:53 configStandardPowerLoadReporting 15
setstate FunkDose1 2015-12-19 16:48:53 configTimePeriodBetweenReportsOnPower47 3600
setstate FunkDose1 2015-12-19 16:48:53 configUPValue 500
setstate FunkDose1 2015-12-19 16:48:53 configWallPlugSResponseToAlarmFrames NoReaction
setstate FunkDose1 2016-09-05 11:13:48 distance 0.0 m
setstate FunkDose1 2016-11-14 16:11:20 energy  3.55 kWh
setstate FunkDose1 2016-09-02 08:13:48 formaldehydeLevel 0.3 mol/m3
setstate FunkDose1 2015-12-19 16:44:15 model FIBARO System FGWPE Wall Plug
setstate FunkDose1 2015-12-19 16:44:15 modelConfig fibaro/fgwpe.xml
setstate FunkDose1 2015-12-19 16:44:15 modelId 010f-0600-1000
setstate FunkDose1 2016-10-22 13:19:13 neighborList ZWDongle_0 ThermostatBuero ThermostatSchlafzimmer ThermostatWohnzimmer LichtWohnzimmerSchrank2A FensterBuero UNKNOWN_15 ThermostatKueche FunkDose2 FensterSchlafzimmerLinks LichtBuero1A LichtKueche LichtFlurSpiegel FensterKueche FensterSchlafzimmerRechts FensterBad DimmerWohnzimmer LichtFlur LichtBad BalkontuerWohnzimmer TuerKammer DimmerSchlafzimmer LichtSchlafzimmerSchrank1A LichtBueroGabi SchalterGabi ThermostatBad Multisensor_02
setstate FunkDose1 2016-10-22 12:59:08 neighborUpdate done
setstate FunkDose1 2016-11-14 16:11:19 power 0.0 W
setstate FunkDose1 2016-03-14 09:03:24 powerlvl current 0 remain 0
setstate FunkDose1 2016-10-18 09:12:17 reportedState on
setstate FunkDose1 2016-10-22 12:59:37 state off
setstate FunkDose1 2016-10-22 12:59:37 timeToAck 0.042
setstate FunkDose1 2016-10-22 12:59:37 transmit OK
setstate FunkDose1 2016-09-04 05:40:39 velocity 0.0 m/s



hoffe das man damit etwas anfangen kann

LG
Tom

[krikan]

Die erste Anlage eines Endpoint-Devices aus der Nachricht

Code Auswählen Erweitern

2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
ist mMn ein Schönheitsfehler von FHEM. Die Nachricht müsste, da sie vom Endpoint 0 kommt, dem endpointParent-Device FensterBuero zugeordnet werden und es dürfte kein neues Device angelegt werden.
Auf der anderen Seite verstehe ich aber nicht, warum der Sensor so eine MultiChannel-Nachricht (Endpoint 0 an Endpoint 0=Hauptdevice an Hauptdevice) verschickt. Das ist nach meiner Lesart der zwapi nicht wirklich zwapi-konform.

Die zweite Anlage eines Endpoint-Devices aus der Nachricht

Code Auswählen Erweitern

2016.11.14 03:54:14 3: UNDEFINED ZWave_Node_6.2 ZWave c9cc092a 1538, please define it. Triggered by 000410060c600d02023905014400000746.
ist ok. Der Aktor schickt von Endpoint 2 eine Nachricht an den Endpoint 2 und es gibt bisher kein entsprechendes Device.
Entweder handelt es sich um eine kaputte Nachricht (mein Tipp) oder man/Du musst herausfinden, warum der Aktor diese Nachricht verschickt.

[rudolfkoenig]

Ich habe das Zuordnen der Nachricht fuer EndPoint 00 geaendert aus das Hauptgeraet, kann aber immer noch nicht einchecken.

Eingecheckt.

[tomspatz]

Entweder handelt es sich um eine kaputte Nachricht (mein Tipp) oder man/Du musst herausfinden, warum der Aktor diese Nachricht verschickt.

Für mich sehen die beiden Nachrichten identisch aus. Aber der Aktor  hat ja gar kein zweiten Kanal.
Wahrscheinlich Müll

LG
Tom

[krikan]

Ehrlicherweise vermute ich auch bei der ersten Endpoint-Device-Anlage eine kaputte Nachricht, die aber zufaelligerweise halbwegs Sinn macht. Anhand der Readings der Devices sehe ich, dass kaputte Nachrichten in Deinem Netz kein Einzelfall sind. Ursache=?

Reduzieren könnte man es vielleicht, indem man nach Telegrammkollisionen sucht und diese vermeidet. Eventuell würde auch der Einbau der Command Class CRC16 etwas helfen. Bei direkt abgefragten Werten könnte man mit Sicherheit fehlerhafte Nachrichten besser erkennen. Bei den spontanen Nachrichten bin ich mir unsicher, da ich nicht herausgefunden habe, wie man einen Aktor/Sensor dazu bewegt, spontane Nachrichten mit CRC16 zu schicken. Die Haeufigkeit von spontanen Nachrichten würde ich als haeufiger als abgefragte Werte einschaetzen; außer Du arbeitest sehr viel mit get/set.

[tomspatz]

kaputte Nachrichten in Deinem Netz kein Einzelfall sind.

Woran kann man das du das erkennen.
Das Z-Wave Netzwerk ist hier auf knapp 90 m² schon sehr eng vermascht. Die einzigen Kameraden die mEn "Müll" produzieren sind die LC-13.
Diese liefern des Öfteren "transmit NO_ACK" bzw steht es ja im Log seitens des Dongles.
Damit experimentiere ich im Moment noch was das wakeupInterwal angeht. Diese "Fehler" werden immer öfters umso kürzer das Interwal ist.
Da probiere ich ein Optimum raus zu holen, aber ob das hierhin gehört.
Interessanter wäre es deine etwaige Vermutung nachzuvollziehen.

Reduzieren könnte man es vielleicht, indem man nach Telegrammkollisionen sucht und diese vermeidet.

Gerne, wie?

außer Du arbeitest sehr viel mit get/set.

Jeder Aktor wird doch so angesteuert.
Zum LC-13 fällt mir noch ein das es in der Doku steht:

Obwohl living connect® Z auf einzelne Befehle reagiert, müssen immer mehrfache Befehle verwendet werden, um die zweijährige Batterielebensdauer zu gewährleisten.

Was soll das denn bedeuten? Die Befehle gehen doch alle seriell raus, nacheinander.
Ich schweife aber sehr ab.

[krikan]

Woran kann man das du das erkennen.

Vermute ich aus:

Code Auswählen Erweitern

2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
2016.11.12 16:55:25 3: UNDEFINED ZWave_Node_14 ZWave c9cc092a 3584, please define it. Triggered by 0004000e0c600d0000310501440000084d.
FensterBuero 2016-11-14 00:55:07 UNPARSED BASIC 0c200d02023105014400000772
FunkDose1 2016-11-05 22:11:37 UNPARSED SENSOR_MULTILEVEL 06310704220000
FunkDose1 2016-09-05 11:13:48 distance 0.0 m
FunkDose1 2016-09-02 08:13:48 formaldehydeLevel 0.3 mol/m3
FunkDose1 2016-09-04 05:40:39 velocity 0.0 m/s
Halte diese Nachrichten alle für "merkwürdig";  und das ist alles relativ aktuell.

Gerne, wie?

Experimentieren und Suchen :
CANs, TRANSMIT_NO_ACK, resend suchen, auf den Grund gehen und abstellen.
-> Gibt es notify/DOIF, die auf Funknachrichten triggern und neue Funknachrichten absetzen, die regelmäßig Probleme machen?
Nur benötigte Assoziationen zum Controller setzen (sind bspw. bei FunkDose1 Assoziationen des Controllers mit Asso 1 und 3 wirklich notwendig?)
...

Jeder Aktor wird doch so angesteuert.

Ja, aber man kann sich auch Probleme schaffen, indem man bspw. zuviel pollt und damit Kollisionen auslöst. Oder an falschen Zeitpunkten Nachrichten absetzt.

[A.Harrenberg]

Hi,

Obwohl living connect® Z auf einzelne Befehle reagiert, müssen immer mehrfache Befehle verwendet werden, um die zweijährige Batterielebensdauer zu gewährleisten.

Was soll das denn bedeuten? Die Befehle gehen doch alle seriell raus, nacheinander.
Ich schweife aber sehr ab.

das ist eine sehr schlechte Übersetzung von jemandem der keine Ahnung von der Technik dahinter hat...
Hiermit ist die Klasse MULTI_COMMAND gemeint. Die kann mehrere Befehle in EINE Nachricht packen und "spart" damit Sendezeit und dadurch Batterien. Die Beschreibung "mehrfache Befehle" ist hier einfach sau-blöd...

Gruß,
Andreas.