"Please report"

PNinBB · 08 November 2015, 20:03:02

In großen und unregelmäßigen Abständen finde ich im Logfile Einträge der folgenden Art:


2015.11.08 10:14:08 1: ZWave: unknown message 00040007075600300300cf3b, please report
2015.11.08 10:14:08 1: ZWave: unknown message 00040007075600300300cf3b, please report
2015.11.08 10:14:08 3: ZWAVE: Unknown code    00040007075600300300cf3b, help me!

Im zeitlichen Umfeld dieser Meldungen gibt es keine Einträge, die irgendwelche Hinweise geben könnten.
Ich experimentiere momentan (wieder einmal) mit einem Danfoss LC13, der aber im Wesentlichen funktioniert.
Einige andere "Kuriositäten" gibt es in den Logfile der Rollladen, beispielsweise:

Code Auswählen


2015-10-06_04:53:32 WZ_RL_TT power: 0.7 W
2015-10-06_06:48:46 WZ_RL_TT luminance: 0 Lux
2015-10-06_06:55:00 WZ_RL_TT off
2015-10-06_06:55:03 WZ_RL_TT power: 99.3 W

Die Helligkeit hat doch dort wohl nichts zu suchen. Im zeitlichen "Umfeld" gab es aber folgende Einträge im Logfile des Fibaro MultiSensors:

Code Auswählen


2015-10-06_00:14:15 WZ_DS_SM temperature: 22.0 C
2015-10-06_00:14:57 WZ_DS_SM UNPARSED: NETWORK_MANAGEMENT_PROXY 0a52013105030a00000391
2015-10-06_00:19:14 WZ_DS_SM temperature: 22.0 C
. . .
2015-10-06_00:49:09 WZ_DS_SM temperature: 21.9 C
2015-10-06_00:54:08 WZ_DS_SM UNPARSED: LOCK 0a76013105012200da8fa9
2015-10-06_00:59:07 WZ_DS_SM temperature: 21.8 C
. . .
2015-10-06_03:53:37 WZ_DS_SM temperature: 21.6 C
2015-10-06_03:58:36 WZ_DS_SM UNPARSED: NETWORK_MANAGEMENT_PRIMARY 0a54013105012200d88feb
2015-10-06_04:03:35 WZ_DS_SM temperature: 21.6 C
. . .
2015-10-06_05:43:17 WZ_DS_SM temperature: 21.5 C
2015-10-06_05:48:02 WZ_DS_SM UNPARSED: DEVICE_RESET_LOCALLY 065a018407c43d
2015-10-06_05:48:16 WZ_DS_SM temperature: 21.5 C
. . .
2015-10-06_07:26:44 WZ_DS_SM basicSet: ff
2015-10-06_07:26:44 WZ_DS_SM UNPARSED: MULTI_CHANNEL 03600d01

Mehr Angabe kann ich momentan nicht machen, bin natürlich gern bereit, weiter mit zu suchen.

krikan · 08 November 2015, 20:16:10

Bitte mit den neuen Modulversionen http://forum.fhem.de/index.php/topic,43735.msg356420.html#msg356420, die Rudi heute eingecheckt hat, noch mal testen und berichten, ob es damit verschwindet.
Danke, Christian

rudolfkoenig · 08 November 2015, 20:59:14

Wen das damit verschwindet, dann habe ich ein Bug eingebaut

00040007075600300300cf3b -> CRC_16_ENCAP (56) eingepackte Meldung (300300) vom nodeId 07 Allerdings versteht FHEM unter CRC nur etwas mit 5601 und nicht mit 5600, und was im Paket ist, ist auch komisch: 300300 kann ich nicht interpretieren. Laenge 30 (statt 3), Klasse 03 (unbekannt).
-> Christian: hast du eine Idee wozu man eine Meldung in CRC einpackt? Oder andersrum: wenn die ZWave Pakete sonst nicht gesichert sind, dann koennen wir das mit report auch lassen, und alles was funktioniert, ist Gluecksfall. Ich muesste mein zwave@CUL Projekt wieder angehen.

A.Harrenberg · 08 November 2015, 21:16:00

Hi Rudi,

Zitat von: rudolfkoenig am 08 November 2015, 20:59:14
-> Christian: hast du eine Idee wozu man eine Meldung in CRC einpackt?

ich geb' mal meinen Senf dazu... (Stammt soweit ich mich erinnern kann aus dem Pätz)

Die Checksumme am Ende der Nachricht ist sehr "schwach" und kann Fehler nicht immer erkennen. Daher hat sich die ZWave-Alliance wohl die Klasse CRC_16_Encap ausgedacht um Fehler besser erkennen zu können.
Doku davon habe ich aber keine, man könnte höchsten mal wieder bei OZW schauen was die unterstützen.

Ich weiß allerdings nicht worauf Du hiermit raus willst?

Zitat von: rudolfkoenig am 08 November 2015, 20:59:14
Oder andersrum: wenn die ZWave Pakete sonst nicht gesichert sind, dann koennen wir das mit report auch lassen, und alles was funktioniert, ist Gluecksfall. Ich muesste mein zwave@CUL Projekt wieder angehen.

Gruß,
Andreas.

krikan · 08 November 2015, 21:24:38

Andreas hat Recht; stammt aus Paetz.

ZitatWen das damit verschwindet, dann habe ich ein Bug eingebaut

Habe ich nicht behauptet

Mich wundern nur immer wieder die seltsamen UNPARSED-Telegramme, die Ähnlichkeit mit anderen Telegrammen haben und die Nachrichten, die augenscheinlich falschen Nodes zugeordnet werden (siehe ausführlich http://forum.fhem.de/index.php/topic,43489.msg355445.html#msg355445) . Spekuliere, ob das mit Überforderung des Dongles durch zu viele offene Kommunikationen zusammenhängen könnte, die die "alten" Modulfasssungen verursachten.

krikan · 08 November 2015, 21:33:29

Wenn die merkwürdigen Nachrichten durch die schwache Prüfsumme nicht als Fehler erkannt werden, dann sollte man überlegen, ob UNPARSED und report rausfliegen, um nicht alle zu verwirren. Gefallen würde es mir nicht wirklich, da evtl. Infos verloren gehen.

A.Harrenberg · 08 November 2015, 21:56:37

Hi Krikan,

Zitat von: krikan am 08 November 2015, 21:33:29
Wenn die merkwürdigen Nachrichten durch die schwache Prüfsumme nicht als Fehler erkannt werden, dann sollte man überlegen, ob UNPARSED und report rausfliegen, um nicht alle zu verwirren. Gefallen würde es mir nicht wirklich, da evtl. Infos verloren gehen.

man könnte aber zumindest mal den Loglevel für die Meldungen raufsetzen... ,-)
Die Meldungen kommen ja bereits mit Loglevel 1 bzw. 3.

Man müsste sich die betreffenden Nachrichten jetzt noch mal genauer ansehen und mal die Checksummen für "naheliegende" oder "mögliche" richtige Antworten ausrechnen. Evtl. trifft man ja einen Fall wo die vermeintlich richtige und die angekommene Nachricht die gleiche Checksumme hätten. Das dürfte aber ziemlich mühselig sein.

In einem anderen Thread hat jemand bei "maxNodes" irgendwas von 66051 stehen:

Code Auswählen

Readings:
     2015-11-08 21:06:13   assocGroup_1    Max 14 Nodes 66051

Hier dürfte das Problem eher darin liegen das die Nachricht "zu lang" war:

Code Auswählen

parse => { "..8503(..)(..)..(.*)" =>
          'sprintf("assocGroup_%d:Max %d Nodes %d", hex($1), hex($2), hex($3))',

Der letzte Parameter nimmt auch mehr als ein Byte falls mehr da ist... In dem Fall müssen es sogar 3 Byte gewesen sein!

Ich finde es allerdings insgesamt merkwürdig das diese unerklärlichen Nachrichten irgendwie gehäuft auftreten.

Gruß,
Andreas.

krikan · 08 November 2015, 22:16:29

Zitat von: A.Harrenberg am 08 November 2015, 21:56:37
In einem anderen Thread hat jemand bei "maxNodes" irgendwas von 66051 stehen:

Da tippe ich eher auf eine verbesserungsbedürftige parse-Funktion: 66051 dez = 10203 hex -> Nodes 01 02 03

Zitatman könnte aber zumindest mal den Loglevel für die Meldungen raufsetzen... ,-)
Die Meldungen kommen ja bereits mit Loglevel 1 bzw. 3.

Würde zumindest zu weniger Meldungen im Forum führen. Aber die Frage ist, ob es nicht doch sinnvolle Infos sein könnten!?

A.Harrenberg · 09 November 2015, 07:51:44

Hi Krikan,

Zitat von: krikan am 08 November 2015, 22:16:29
Da tippe ich eher auf eine verbesserungsbedürftige parse-Funktion: 66051 dez = 10203 hex -> Nodes 01 02 03
Würde zumindest zu weniger Meldungen im Forum führen. Aber die Frage ist, ob es nicht doch sinnvolle Infos sein könnten!?

gut aufgepasst!

Ich hatte mir die Klasse nicht angeschaut und war davon ausgegangen das hier die ANZAHL der Nodes gemeldet wird und nicht eine "Liste" der Nodes.

Ich habe eigentlich auch nichts gegen die RM im Forum. Momentan sind da noch ein paar Probleme offen, und meistens werden durch die RM ja auch Fehler/Probleme oder auch neue Eigenheiten von Devices erkannt. Von daher halte ich die Meldungen ja auch für sinnvoll, allerdings kommt da gerade eine ganze Menge...

Gruß,
Andreas.

krikan · 09 November 2015, 08:05:04

Zitat von: A.Harrenberg am 09 November 2015, 07:51:44
gut aufgepasst!

Na ja, ich habe mit meiner Drängelei zur hex/dez-Umstellung den optischen Mangel wohl verursacht.

ZitatIch habe eigentlich auch nichts gegen die RM im Forum. Momentan sind da noch ein paar Probleme offen, und meistens werden durch die RM ja auch Fehler/Probleme oder auch neue Eigenheiten von Devices erkannt. Von daher halte ich die Meldungen ja auch für sinnvoll, allerdings kommt da gerade eine ganze Menge...

Ja, die Frage ist nur woran das liegt und mich würde interessieren, ob das mit den geänderten Modulversionen geringer wird. Obwohl selbst bei abnehmender Meldungszahl kein Beweis vorliegt. Letztlich bin ich hin- und hergerissen und Rudi darf/muss entscheiden.

rudolfkoenig · 09 November 2015, 15:55:52

Hab das loglevel auf 4 geaendert, und "please report" entfernt.
Wir sollten das im Hinterkopf behalten, aber es hilft nicht immer wieder Leute aufzuscheuchen, um dann doch nichts zu unternehmen.

A.Harrenberg · 09 November 2015, 16:56:03

Hallo Rudi,

Zitat von: rudolfkoenig am 09 November 2015, 15:55:52
Hab das loglevel auf 4 geaendert, und "please report" entfernt.
Wir sollten das im Hinterkopf behalten, aber es hilft nicht immer wieder Leute aufzuscheuchen, um dann doch nichts zu unternehmen.

ok, aber bzgl. "dann doch nichts zu unternehmen"... Hast Du eine Liste mit "offenen" Punkten für ZWave in der Du solche Sachen wie jetzt z.B. die CRC_16_encap mit "5600" oder die Sachen mit den MaxNodes für die AssociationGroup (66501 -> 0x010203) einträgst?

Einige von den Kleinigkeiten könnte ich Dir sicherlich abnehmen, das sollte nur irgendwie abgesprochen sein damit da keine Arbeit doppelt gemacht wird.

Gruß,
Andreas.

rudolfkoenig · 09 November 2015, 19:36:04

Ich habe nur eine TODO Liste, aber da trage ich manches wie das CRC Problem gar nicht rein, du darfst es gerne zusammen mit dem "please report" gerne haben

Das associationGroup-Problem habe ich gerade gefixt.

A.Harrenberg · 09 November 2015, 20:19:15

Hi Rudi,

Zitat von: rudolfkoenig am 09 November 2015, 19:36:04
Ich habe nur eine TODO Liste, aber da trage ich manches wie das CRC Problem gar nicht rein, du darfst es gerne zusammen mit dem "please report" gerne haben

ich schau dann mal in die Sourcen von OZW rein was dort zum Thema CRC_16_ENCAP zu finden ist.
Das "please report" ist mir dann aber doch zu unkonkret

Zitat von: rudolfkoenig am 09 November 2015, 19:36:04
Das associationGroup-Problem habe ich gerade gefixt.

Schön, falls Du es noch nicht getan hast werde ich in dem Thread darauf aufmerksam machen.

Gruß,
Andreas.

PNinBB · 10 November 2015, 13:23:35

Momentan geht bei mir garnichts !!
Was habe ich gemacht ?
1. Seit längerer Zeit steigt fhem nach der nächtlichen Neuzuteilung der IP-Adresse aus. Ich habe einen cron-Job, der danach prüft, ob und wenn ja fhem neu startet. M.E. steht das irgendwie in Verbindung mit dem mailcheck-Module. Ich habe in dem Thread auch darüber berichtet. Aber das war momentan nicht die wichtigste "Baustelle".
2. Die Thermostatsteuerung mit dem neuen Danfoss LC13 funktionierte, obwohl es da oft zu großen Verzögerungen beim Setpoint-Kommando kommt. Die Verbindung scheint mir aber stabil zu sein, auch da der Danfoss direkt neben einem netzgespeisten Dual relay (PAN06-1A) liegt.
3. Die Rollladensteuerung (3x) funktionierte seit fast einem Jahr recht verlässlich. Probleme gab es, seit ich alles mit DOIF programmiert habe. Das Ereignis triggerte, aber die Aktion blieb aus. Im Log sah das etwa so aus:

Code Auswählen


2015.10.05 06:55:00 2: ZWave set WZ_RL_FS off
2015.10.05 06:55:00 2: ZWave set WZ_RL_FT off
2015.10.05 06:55:00 2: ZWave set WZ_RL_TT off
2015.10.05 06:55:01 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001303032501002503e4
2015.10.05 06:55:02 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001304032501002504e4
2015.10.05 06:55:03 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900130602840825064e
2015.10.05 06:55:10 2: ZWAVE transmit NO_ACK for 06
2015.10.05 06:55:10 2: ZWAVE transmit NO_ACK for 06
2015.10.05 06:55:10 2: ZWave: No ACK from WZ_RL_FS after 10s for sent:1302032501002502

3. Vor einigen Tagen tauchte - nicht zum ersten Mal - der folgende Eintrag im fhem-Log auf:

Code Auswählen


2015.10.04 13:11:33 3: UNDEFINED ZWave_Node_134 ZWave ed70b42b 134, please define it
2015.10.04 13:11:33 2: autocreate: define ZWave_Node_134 ZWave ed70b42b 134
2015.10.04 13:11:33 2: autocreate: define FileLog_ZWave_Node_134 FileLog ./log/ZWave_Node_134-%Y.log ZWave_Node_134

4. Heute habe ich gegen 10:10 Uhr ein update gemacht und seitdem läuft fhem jeweils nur noch 2...3 Minuten und steigt aus; und das sehr "stabil", soll heißen reproduzierbar. Im fhem-Log ist bei verbose=3 nichts auffälliges; bis auf ein "ZWDongle_ProcessSendStack: no ACK".

Code Auswählen


2015.11.10 02:05:49 1: usb create end
2015.11.10 02:05:49 0: Featurelevel: 5.6
2015.11.10 02:05:49 0: Server started with 124 defined entities (version $Id: fhem.pl 9755 2015-11-02 19:34:14Z rudolfkoenig $, os linux, user fhem, pid 5983)
2015.11.10 02:05:49 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9

2015.11.10 07:28:51 1: usb create end
2015.11.10 07:28:51 0: Featurelevel: 5.6
2015.11.10 07:28:51 0: Server started with 124 defined entities (version $Id: fhem.pl 9755 2015-11-02 19:34:14Z rudolfkoenig $, os linux, user fhem, pid 13065)
2015.11.10 07:28:51 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9

2015.11.10 07:29:06 3: ZWave reading config for fibaro/fgrm222.xml
2015.11.10 07:29:11 2: ZWave set WZ_RL_FS off
2015.11.10 07:29:11 2: ZWave set WZ_RL_FT off
2015.11.10 07:29:11 2: ZWave set WZ_RL_TT off
2015.11.10 07:29:13 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001302032501002502e4
2015.11.10 07:29:14 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001303032501002503e4
2015.11.10 07:29:15 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a001304032501002504e4
2015.11.10 07:29:16 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900130a028408250a4e

2015.11.10 10:11:02 0: Featurelevel: 5.6
2015.11.10 10:11:02 0: Server started with 124 defined entities (version $Id: fhem.pl 9809 2015-11-07 18:39:08Z rudolfkoenig $, os linux, user fhem, pid 18324)
2015.11.10 10:11:02 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9

2015.11.10 10:22:20 0: Featurelevel: 5.6
2015.11.10 10:22:20 0: Server started with 124 defined entities (version $Id: fhem.pl 9809 2015-11-07 18:39:08Z rudolfkoenig $, os linux, user fhem, pid 18609)
2015.11.10 10:22:20 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9

2015.11.10 11:06:46 0: Featurelevel: 5.6
2015.11.10 11:06:46 0: Server started with 124 defined entities (version $Id: fhem.pl 9809 2015-11-07 18:39:08Z rudolfkoenig $, os linux, user fhem, pid 3208)
2015.11.10 11:06:46 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9

Auch ein Versuch mit verbose = 5 brachte natürlich eine Menge Einträge, aber nichts auffälliges, zumindest nicht für mich !.

Code Auswählen


2015.11.10 10:34:02 4: ZWDongle_Read ZWAVE: sending ACK, processing 000400060656018407cc39
2015.11.10 10:34:02 5: SW: 06
2015.11.10 10:34:02 5: ZWAVE dispatch 000400060656018407cc39
2015.11.10 10:34:02 4: ZWAVE CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:0656018407cc39
2015.11.10 10:34:02 4: ZWDongle_Read ZWAVE: sending ACK, processing 000400060656018407cc39
2015.11.10 10:34:02 5: SW: 06
2015.11.10 10:34:02 5: ZWAVE dispatch 000400060656018407cc39
2015.11.10 10:34:02 4: ZWAVE CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:0656018407cc39
2015.11.10 10:34:02 4: ZWDongle_Read ZWAVE: sending ACK, processing 000400060656018407cc39
2015.11.10 10:34:02 5: SW: 06
2015.11.10 10:34:02 5: ZWAVE dispatch 000400060656018407cc39
2015.11.10 10:34:02 4: ZWAVE CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:0656018407cc39
2015.11.10 10:34:04 5: ZWDongle_Write 00 13060284082506
2015.11.10 10:34:04 5: SW: 010900130602840825064e
2015.11.10 10:34:04 5: ACK received, WaitForAck=>2 for 010900130602840825064e
2015.11.10 10:34:04 4: ZWDongle_Read ZWAVE: sending ACK, processing 011301
2015.11.10 10:34:04 5: SW: 06
2015.11.10 10:34:04 5: ZWAVE dispatch 011301
2015.11.10 10:34:04 4: ZWDongle_Read ZWAVE: sending ACK, processing 001306000006
2015.11.10 10:34:04 5: SW: 06
2015.11.10 10:34:04 5: device ack reveived, removing 010900130602840825064e from dongle sendstack
2015.11.10 10:34:04 5: ZWAVE dispatch 001306000006
2015.11.10 10:34:04 4: ZWAVE CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.11.10 10:34:04 4: ZWAVE transmit OK for 06
2015.11.10 10:34:16 4: ZWDongle_Read ZWAVE: sending ACK, processing 000400060a56013105012200dddf4e
2015.11.10 10:34:16 5: SW: 06
2015.11.10 10:34:16 5: ZWAVE dispatch 000400060a56013105012200dddf4e
2015.11.10 10:34:16 4: ZWAVE CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:0a56013105012200dddf4e
2015.11.10 10:34:16 5: Triggering WZ_DS_SM (1 changes)
2015.11.10 10:34:16 5: Notify loop for WZ_DS_SM temperature: 22.1 C
2015.11.10 10:34:16 5: Triggering no_WZ_Temp
2015.11.10 10:34:16 4: no_WZ_Temp exec {
my $temp = ReadingsVal("WZ_DS_SM","temperature",99);;fhem("set WZ_Temperatur $temp")
}
2015.11.10 10:34:16 5: Cmd: >{
my $temp = ReadingsVal("WZ_DS_SM","temperature",99);fhem("set WZ_Temperatur $temp")
}<
2015.11.10 10:34:16 5: Cmd: >set WZ_Temperatur 22.1 C<
2015.11.10 10:34:16 4: dummy set WZ_Temperatur 22.1 C
2015.11.10 10:34:16 5: Triggering WZ_Temperatur (1 changes)
2015.11.10 10:34:16 5: Notify loop for WZ_Temperatur 22.1 C
2015.11.10 10:34:16 5: rg_Batterie: not on any display, ignoring notify
2015.11.10 10:34:16 4: ZWDongle_Read ZWAVE: sending ACK, processing 000400060a56013105012200dddf4e
2015.11.10 10:34:16 5: SW: 06
2015.11.10 10:34:16 5: ZWAVE dispatch 000400060a56013105012200dddf4e
2015.11.10 10:34:16 4: ZWAVE CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:0a56013105012200dddf4e
2015.11.10 10:34:16 5: Triggering WZ_DS_SM (1 changes)
2015.11.10 10:34:16 5: Notify loop for WZ_DS_SM temperature: 22.1 C
2015.11.10 10:34:16 5: Triggering no_WZ_Temp
2015.11.10 10:34:16 4: no_WZ_Temp exec {
my $temp = ReadingsVal("WZ_DS_SM","temperature",99);;fhem("set WZ_Temperatur $temp")
}
2015.11.10 10:34:16 5: Cmd: >{
my $temp = ReadingsVal("WZ_DS_SM","temperature",99);fhem("set WZ_Temperatur $temp")
}<
2015.11.10 10:34:16 5: Cmd: >set WZ_Temperatur 22.1 C<
2015.11.10 10:34:16 4: dummy set WZ_Temperatur 22.1 C
2015.11.10 10:34:16 5: Triggering WZ_Temperatur (1 changes)
2015.11.10 10:34:16 5: Notify loop for WZ_Temperatur 22.1 C
2015.11.10 10:34:16 5: rg_Batterie: not on any display, ignoring notify
2015.11.10 10:34:16 4: ZWDongle_Read ZWAVE: sending ACK, processing 000400060a56013105012200dddf4e
2015.11.10 10:34:16 5: SW: 06
2015.11.10 10:34:16 5: ZWAVE dispatch 000400060a56013105012200dddf4e
2015.11.10 10:34:16 4: ZWAVE CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:0a56013105012200dddf4e
2015.11.10 10:34:16 5: Triggering WZ_DS_SM (1 changes)
2015.11.10 10:34:16 5: Notify loop for WZ_DS_SM temperature: 22.1 C
2015.11.10 10:34:16 5: Triggering no_WZ_Temp
2015.11.10 10:34:16 4: no_WZ_Temp exec {
my $temp = ReadingsVal("WZ_DS_SM","temperature",99);;fhem("set WZ_Temperatur $temp")
}
2015.11.10 10:34:16 5: Cmd: >{
my $temp = ReadingsVal("WZ_DS_SM","temperature",99);fhem("set WZ_Temperatur $temp")
}<
2015.11.10 10:34:16 5: Cmd: >set WZ_Temperatur 22.1 C<
2015.11.10 10:34:16 4: dummy set WZ_Temperatur 22.1 C
2015.11.10 10:34:16 5: Triggering WZ_Temperatur (1 changes)
2015.11.10 10:34:16 5: Notify loop for WZ_Temperatur 22.1 C
2015.11.10 10:34:16 5: rg_Batterie: not on any display, ignoring notify
2015.11.10 10:34:39 4: ZWDongle_Read ZWAVE: sending ACK, processing 0004000a03800355
2015.11.10 10:34:39 5: SW: 06
2015.11.10 10:34:39 5: ZWAVE dispatch 0004000a03800355
2015.11.10 10:34:39 4: ZWAVE CMD:APPLICATION_COMMAND_HANDLER ID:0a ARG:03800355
2015.11.10 10:34:39 5: Triggering WZ_HZ_T1 (1 changes)
2015.11.10 10:34:39 5: Notify loop for WZ_HZ_T1 battery: 85 %
2015.11.10 10:34:39 5: Triggering no_WZ_HZ_T1
2015.11.10 10:34:39 4: no_WZ_HZ_T1 exec {myHeizungUtils_HZ_TH_Mode("WZ_HZ_T1",$EVENT)}
2015.11.10 10:34:39 5: Cmd: >{myHeizungUtils_HZ_TH_Mode("WZ_HZ_T1",$EVENT)}<
. . .

Auch einen Neustart der Rasberry Pi änderte nichts.
In einer der kurzen Laufzeiten habe noch noch einmal ein "update" versucht.

Code Auswählen


Im Log
2015.11.10 12:23:14 0: Featurelevel: 5.6
2015.11.10 12:23:14 0: Server started with 123 defined entities (version $Id: fhem.pl 9809 2015-11-07 18:39:08Z rudolfkoenig $, os linux, user fhem, pid 5425)
2015.11.10 12:23:14 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2015.11.10 12:23:33 3: telnetForBlockingFn: port 41228 opened
2015.11.10 12:23:38 1: UPD FHEM/10_MYSENSORS_DEVICE.pm
2015.11.10 12:23:39 1: Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015.11.10 12:23:40 1: nothing to do...
2015.11.10 12:24:22 1: nothing to do...
2015.11.10 12:24:23 1: nothing to do...

Beim letzten Versuch tauchte noch diese Warnung auf, die aber wohl nicht die Ursache sein kann.

Code Auswählen


2015.11.10 13:02:45 0: Featurelevel: 5.6
2015.11.10 13:02:45 0: Server started with 123 defined entities (version $Id: fhem.pl 9809 2015-11-07 18:39:08Z rudolfkoenig $, os linux, user fhem, pid 6604)
2015.11.10 13:02:45 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2015.11.10 13:04:11 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at ./FHEM/33_readingsGroup.pm line 970.
2015.11.10 13:04:11 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at ./FHEM/33_readingsGroup.pm line 975.
2015.11.10 13:04:26 3: ZWave reading config for fibaro/fgrm222.xml

Ich habe auch mit einer extrem "zusammengeschnittenen" cfg-Datei mein Glück versucht; alles ohne Erfolg.

Ergänzung: eine sehr kurze, nur mit den Gerätedefinitionen versehene cfg-Datei läuft seit 10 Minuten; ich werde nun sukzessive die weiteren Einträge einbauen und eventuell so den Verursacher finden !

In den Jessy Logfiles habe ich auch nichts auffälliges gefunden.
Also momentan geht garnichts !! Folglich ist jeder Tipp sehr willkommen.