"Please report"

Begonnen von PNinBB, 08 November 2015, 20:03:02

Vorheriges Thema - Nächstes Thema

PNinBB

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:

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:

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.
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

krikan

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

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

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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

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

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

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:
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:
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

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

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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

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

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

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.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

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

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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

PNinBB

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

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:

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

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

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.

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.

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.
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

rudolfkoenig

Es waere mir lieber, wenn deine Meldungen nicht in diesem Beitrag gelandet waeren, da sie nichts mit dem hier bahandelten Problem zu tun haben. Weiterhin merke: wenn man 2 unterschiedliche Probleme in einem Beitrag meldet, dann ist die Wahrscheinlichkeit halb so hoch, dass man eine Anwort kriegt. Bei 3 Problemen 1/3, usw.

Nun zu den Meldungen:
1. Kein Log, kein Link, keine Details -> keine Hilfe.
2. Ist wohl kein Problem. Mein Danfoss tut nicht.
3. Da die FHEM ZWave.pm Version unbekannt ist, kann ich nicht viel dazu sagen. Rat: Erst update ausfuehren, und nur neue Probleme melden.
3. Das sollte inzwischen nicht mehr kommen.
4. Kling nach ZWdongle Problem oder nach einem Problem mit der ZWDongle Kommunikation. Im 5-er log sehe ich keine Probleme. readingsGroup Warning mit andre (readingsGroup Maintainer) in dem passenden Forumsbereich besprechen. Ich tippe auf ein Problem in der Benutzerkonfiguration.

PNinBB

#16
Danke für die prompte Reaktion und auch für die Hinweise.
Ein paar Antworten:
1. Ich habe seit einiger Zeit den Modul "mailcheck" herausgenommen, aber die Meldungen im Log waren nach dem folgenden Muster und wiederholten sich 5...10 Mal.

2015.10.31 01:36:07 1: PERL WARNING: Trying command when NOT connected! at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 122.
Mail::IMAPClient::LastError(Mail::IMAPClient=HASH(0x33f1810), "NO not connected") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1493
Mail::IMAPClient::_send_line(Mail::IMAPClient=HASH(0x33f1810), "129 SELECT INBOX", 0) called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1320
Mail::IMAPClient::_imap_command_do(Mail::IMAPClient=HASH(0x33f1810), "SELECT INBOX") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1225
Mail::IMAPClient::_imap_command(Mail::IMAPClient=HASH(0x33f1810), "SELECT INBOX") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 845
Mail::IMAPClient::select(Mail::IMAPClient=HASH(0x33f1810), "INBOX") called at ./FHEM/32_mailcheck.pm line 258
main::mailcheck_poll(undef) called at fhem.pl line 2701
main::HandleTimeout() called at fhem.pl line 584
2015.10.31 01:36:07 1: PERL WARNING: Trying command when NOT connected! LastError was: NO not connected at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 122.
Mail::IMAPClient::LastError(Mail::IMAPClient=HASH(0x33f1810), "Error sending '129 SELECT INBOX': NO not connected") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1321
Mail::IMAPClient::_imap_command_do(Mail::IMAPClient=HASH(0x33f1810), "SELECT INBOX") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1225
Mail::IMAPClient::_imap_command(Mail::IMAPClient=HASH(0x33f1810), "SELECT INBOX") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 845
Mail::IMAPClient::select(Mail::IMAPClient=HASH(0x33f1810), "INBOX") called at ./FHEM/32_mailcheck.pm line 258
main::mailcheck_poll(undef) called at fhem.pl line 2701
main::HandleTimeout() called at fhem.pl line 584

Zum Crash kam es dann mit dem folgenden Eintrag:

2015.08.27 15:28:36 1: PERL WARNING: Trying command when NOT connected! LastError was: Error sending '6 IDLE': NO not connected at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 122.
Mail::IMAPClient::LastError(Mail::IMAPClient=HASH(0x1eb1b20), "Error sending '6 IDLE': NO not connected") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1274
Mail::IMAPClient::_imap_command(Mail::IMAPClient=HASH(0x1eb1b20), "IDLE", "+") called at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1118
Mail::IMAPClient::idle(Mail::IMAPClient=HASH(0x1eb1b20)) called at ./FHEM/32_mailcheck.pm line 451
main::mailcheck_Read(HASH(0x1c66410)) called at fhem.pl line 3056
main::CallFn("??????LiveMail", "ReadFn", HASH(0x1c66410)) called at fhem.pl line 651
2015.08.27 15:28:36 3: ????????LiveMail: logged out
2015.08.27 15:28:36 3: ????????LiveMail: Disconnected
2015.08.27 15:28:36 3: ????????LiveMail: connected to imap-mail.outlook.com
2015.08.27 15:28:37 3: ????????LiveMail: logged in to login_name@live.de
Bizarre copy of HASH in list assignment at /usr/share/perl/5.20/Carp.pm line 228.


3. Ich mache fast jeden Tag das Update; die Details für ZWDongle.pm sind:

##############################################
# $Id: 00_ZWDongle.pm 9825 2015-11-08 14:24:48Z rudolfkoenig $

und für ZWave.pm sind:

##############################################
# $Id: 10_ZWave.pm 9840 2015-11-09 18:14:53Z rudolfkoenig $

Die folgende Meldung kommt nach jedem Neustart im Logfile:

2015.11.10 18:35:08 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9


Ich habe momentan mit meiner alten Konfiguration ohne readingsGroup und DOIF einen stabilen Betrieb.
Meine ZWAVE-Firmware habe ich heute von v.2.0.1auf v.2.1.1 aktualisiert.
Auf jeden Fall: vielen Dank.
Peter
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

A.Harrenberg

Hi Rudi,
Zitat von: A.Harrenberg am 09 November 2015, 20:19:15
Hi Rudi,ich schau dann mal in die Sourcen von OZW rein was dort zum Thema CRC_16_ENCAP zu finden ist.
ich habe jetzt mal kurz in die Sourcen von OZW reingeschaut. Auch dort ist nur "01" als Befehl definiert:
enum CRC16EncapCmd
{
CRC16EncapCmd_Encap = 0x01
};

Die Nachricht mit 0x5600 "2015.11.08 10:14:08 1: ZWave: unknown message 00040007075600300300cf3b, please report" von PNinBB muss ich daher auch als "defekte" Nachricht einstufen. Es wäre jetzt natürlich schon irgendwie ironisch wenn ausgerechnet ein Fehler in der Nachricht der CRC Klasse nicht durch die Checksumme erkannt wird...

Die CRC wird ja momentan noch nicht gerechnet... Ich schau mir mal die Berechnung der CRC bei OZW an, sieht nicht so kompliziert aus, ist aber in C++ syntax und mir ist nicht ganz klar ob da nur die Payload reingeht oder noch die gesamte Nachricht.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi Rudi,

ich habe im Netz einen on-line calculator für die CRC gefunden und ein wenig damit rumprobiert.
Das hier:
2015.11.08 10:14:08 1: ZWave: unknown message 00040007075600300300cf3b, please report
ist definitiv eine kaputte Nachricht!

Die CRC_16 der Nachricht ist "cf3b", und passt nicht zu "5600300300" sondern zu "5601300300"! Also doch die bekannte 0x5601 Klasse.

Da die Nachricht ja den CRC_16 Teil noch nicht durchlaufen hat, ist die Länge jetzt 03 und muss der Nachricht vorangestellt werden, dann wäre die Nachricht 03 300300.
Wobei dann die 30 für SENSOR_BINARY steht, 03 für SensorReport und die 00 einen unbekannten Sensortyp meldet, also eine "normale" Nachricht darstellt.

=> Empfangsprobleme...
Und ein gutes Beispiel dafür das die Checksumme alleine nicht (immer) glücklich macht...

Ich habe noch ein paar Codefetzen zur Implementierung gefunden, wahrscheinlich könnte man das wohl auch mit dem cpan DIGEST::CRC modul machen, da diese Nachrichten aber anscheinend so selten sind ist es mMn mit Kanonen auf Spatzen geschossen dafür wieder ein cpan-Modul einzubinden.

Ich werde daher versuchen die gefundenen Codefetzen mal in eine CRC_16 Berechnung ohne das Modul umzusetzen.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi Rudi,

anbei ein kleiner Patch der jetzt bei CRC_16_Encap 0x5601 die CRC berechnet und eine Meldung rausgibt wenn diese nicht stimmt.
Für den hier vorgekommenen Fall 0x5600 hilft das natürlich nicht, dafür ist es ja aber auch nicht gedacht.

Getestet habe ich das nur recht grob mit "Dispatch" und ein paar Nachrichten die ich im Forum gefunden habe, dabei gab es aber keine Auffälligkeiten und Änderungen wurden entsprechend gemeldet.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Habs eingecheckt, aber nicht getestet.

A.Harrenberg

Hi Rudi,
Zitat von: rudolfkoenig am 14 November 2015, 20:06:33
Habs eingecheckt, aber nicht getestet.
Danke, ist ja auch nicht viel zu testen ,-)

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hallo Peter (PNinBB),

da Dein Gerät ja anscheinend diese CRC16 Nachricht unterstützt, könntest du mal darauf achten ob es da zu Fehlermeldungen kommt und die dann evtl. posten?

Die Nachricht die den ganzen Thread hier ausgelöst hat war ja eindeutig ein Empfangsproblem das mit der normalen Checksumme anscheinend nicht erkannt werden konnte. Falls es bei Dir häufiger zu Empfangsproblemen kommt sollten zumindest Fehler in der Payload bzw. der CRC jetzt im Log auftauchen, zumindest solange nicht wieder der CRC-Befehl selbst "kaputt" ankommt, dagegen kann man leider nichts machen.

Hattest Du eigentlich auch schon mal Meldungen wegen falscher Checksumme im Log?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY