Sporadisch werden neue endpointChildren erzeugt

[A.Harrenberg]

Hi,

Sehe ich anders: alles was der Benutzer absetzt, wenn ein Geraet "schlaeft", sammelt sich da. Auch wenn notifies auf WUN reagieren, landen die Befehle auf dem Stack. Ob eine Zusammenfassung viel bringt, kann ich pauschal nicht beurteilen, und haengt vmtl. auch vom Geraet ab.

natürlich landet das alles auf dem Stack, aber wer alle 15 Minuten alle Werte von allen Sensoren abfragt macht da vielleicht auch was falsch... WENN das natürlich jemand so macht, dann loht sich die Zusammenfassung sicherlich.

CRC16 sehe ich kritisch: da das CRC nicht auf der unteren Ebene geprueft wird, muss eine Wiederholung (wenn ueberhaupt) auf der oberen Ebene zusaetzlich implementiert werden, und hier gibt es keine Moeglichkeit einer Wiederholungs- oder "Kam falsch an"-Erkennung. Man kann also die Nachricht nur wegschmeissen, dafuer ist der Nutzwert mAn nicht besonders hoch.

Hmm, das ist unschön, da müsste man also schon low-level prüfen, was ja so nicht vorgesehen ist.

Fuer CRC und MULTI_CMD gilt: wie "motiviere" ich die Gegenseite, diese Klassen fuer die gesendeten Nachrichten zu verwenden?

Einfach hinschicken... 

Code Auswählen Erweitern

Devices supporting CRC-16 Encapsulation Command Class
A device that supports the CRC-16 Encapsulation Command Class MAY receive a combination of encapsulated and normal non-encapsulated requests and the response MUST be as follows:
a) If the request is sent encapsulated, the response MUST be returned encapsulated.
b) If the request is sent non-encapsulated, the response MUST be sent non-encapsulated.

Code Auswählen Erweitern

A device that supports the Multi Command Command Class MAY receive a combination of encapsulated and normal non-encapsulated requests over time. The response MUST be as follows:
a) If the request is sent encapsulated, the response MUST be returned encapsulated.
b) If the request is sent non-encapsulated, the response MUST also be sent non-encapsulated.

Gruß,
Andreas.

[krikan]

CRC16 sehe ich kritisch: da das CRC nicht auf der unteren Ebene geprueft wird, muss eine Wiederholung (wenn ueberhaupt) auf der oberen Ebene zusaetzlich implementiert werden, und hier gibt es keine Moeglichkeit einer Wiederholungs- oder "Kam falsch an"-Erkennung. Man kann also die Nachricht nur wegschmeissen, dafuer ist der Nutzwert mAn nicht besonders hoch.

CRC16 fände ich recht nützlich:
Wenn die "kaputten" Nachrichten aussortiert, geloggt und nicht verarbeitet würden, dann gäbe es u.a. keine merkwürdigen Events und Readings sowie keine unnötige Device-Anlage durch autocreate. Damit auch keine negative Beeinflußung im Frontend und Verwirrung beim User. Zudem kann man "kaputte" Nachrichten eindeutig identifizieren und braucht nicht mehr nur vermuten, wie hier im Thread. Eine Möglichkeit der Wiederholung finde ich nicht so wichtig. Das wäre erst der zweite Schritt.

Einfach hinschicken... 

Wenn das mal so einfach ist: Was passiert bei den spontanen Nachrichten der Geräte; wann werden die CRC16 geschützt?
Beim Fibaro FGMS mit der alten Firmware war meine Beobachtung beim ZWCul-Test:
HC empfängt spontane Nachrichten, die CRC16 geschützt waren.
FHEM empfängt gleiche spontane Nachricht ohne CRC16 Schutz.
Habe es nicht intensiv betrachtet, da meine Zielrichtung damals eine andere war, aber:
Ist das ein Zufall, Geräte-Besonderheit, habe ich falsch analysiert oder gibt es ein unbekanntes System, das ich nicht kenne? In zwapi finde ich nichts dazu.

[tomspatz]

Auch wenn das hier leider mein Wissens Level überschreitet....
Meine Erfahrung, und jetzt bleibe ich bei dem "leidigen" Gerät, sagt auch mit 3-4 Meter Sichtweite vom UZB zum LC-13 gibt es immer wieder

Code Auswählen Erweitern

ZWDongle_0 transmit NO_ACK for CB 08, target ThermostatWohnzimmer
Das Ganze läuft hier jetzt fast ein Jahr, eigentlich stabil. Die anderen LC-13 die durch mehrere Wände teils erst zu erreichen sind, genauso. Mal mehr mal weniger.
Eine Lokale umsetztung des Controllers in ca. 2 Meter höhe über einen Zeitraum von gut 4 Wochen im Sommer hat nicht besser funktioniert. Was das angeht.
Die Thermostate werden alle 30 Minuten nach Batterie abgefragt. Ob das wirklich so muss sei dahingestellt. Allerdings werden NUR so wirklich regelmäßig die Battery Readings  aktualisiert.
Mit 300 Sekunden wakupInterwal gibt es "etwas" weniger NO_ACK's, im Moment probiere ich mich an die untere Grenze des wakupInterwals zu tasten, einfach nur so.
Batterie Spielt jetzt keine Rolle. Bei 60 Sekunden läuft der Log voll damit, bei 150 Momentan ist es deutlich weniger. Aber ganz ohne NIE.
Die Fibaro Jungs lassen die z.T. mit 60 Sekunden laufen, es gibt so in dem UI des HC2 immer wieder "rote" Fehlermeldungen zu dem Thermostaten, leider weiss ich den Wortlaut nich mehr.
Das stört die aber gar nicht.
Anderseits wenn ich  immer mehrerer Befehle zugleich absetzten soll frage ich wie das dann funktionieren soll.
Beispiel der Batt Abfrage liegt doch auf dem Sendstack, wass soll da noch mit rein wenn nur das gewollt wird.

@A.Harrenberg

natürlich landet das alles auf dem Stack, aber wer alle 15 Minuten alle Werte von allen Sensoren abfragt macht da vielleicht auch was falsch...

Sorry aber das finde ich Quatsch, allerdings ohne des hintergrundwissens zu fhem.
Die Meisten Sensoren senden ihre Werte doch selbstätig. Darf mann da nicht noch eine Abfrage dazu starten?

[krikan]

Code Auswählen Erweitern

ZWDongle_0 transmit NO_ACK for CB 08, target ThermostatWohnzimmer
Ist Dir bekannt, auf welche Nachricht von FHEM die LC-13 die NO_ACK liefern?
Wenn es die "WakeupNoMoreInformation"-Nachricht (=Gehe schlafen LC-13) ist, dann experimentiere mal mit einer Verkürzung der Wachzeit mit dem Attribut WNMI_delay. Oder hast Du das schon gemacht?
Die Batterieabfrage ist vielleicht nicht notwendig, wenn WNMI_delay kurz genug ist:
Es gibt Sensoren, die sich ohne Nachricht von FHEM nach einem Wakeup und vor Versand der WNMI durch FHEM nach 2 Sekunden schon wieder schlafen gelegt haben. Die WNMI-Nachricht von FHEM endet dann zwangsläufig mit NO_ACK.
Erhalten diese Sensoren aber nach dem Wakeup unverzüglich eine Nachricht (hier battery-Abfrage) verlängert sich deren Wachzeit deutlich und die WNMI-Nachricht von FHEM kommt zumeist vor dem automatischen "Schlafen gehen" an.

Den Einfluss einer Verkürzung des wakeUpIntervals auf NO_ACK erkenne ich nicht. Ausschließen kann ich es aber auch nicht.

Code Auswählen Erweitern

Anderseits wenn ich  immer mehrerer Befehle zugleich absetzten soll frage ich wie das dann funktionieren soll.
Beispiel der Batt Abfrage liegt doch auf dem Sendstack, wass soll da noch mit rein wenn nur das gewollt wird.
Gleichzeitig mit der Batterieabfrage kann man in einer Nachricht mit MULTI_CMD noch den WNMI-Befehl verschicken = kurzestmögliche Wachzeit. Entfernt ähnlicher Effekt wie Verkürzung WNMI_delay.

[A.Harrenberg]

Hi,

Meine Erfahrung, und jetzt bleibe ich bei dem "leidigen" Gerät, sagt auch mit 3-4 Meter Sichtweite vom UZB zum LC-13 gibt es immer wieder

Code Auswählen Erweitern

ZWDongle_0 transmit NO_ACK for CB 08, target ThermostatWohnzimmer

irgendwie scheinen einige Geräte empfindlicher gegen Störungen zu sein als andere, und der LC-13 scheint ein solcher Kandidat zu sein, der verhält sich ja schon im Normalzustand merkwürdig.

Die Thermostate werden alle 30 Minuten nach Batterie abgefragt. Ob das wirklich so muss sei dahingestellt. Allerdings werden NUR so wirklich regelmäßig die Battery Readings  aktualisiert.
Mit 300 Sekunden wakupInterwal gibt es "etwas" weniger NO_ACK's, im Moment probiere ich mich an die untere Grenze des wakupInterwals zu tasten, einfach nur so.
Batterie Spielt jetzt keine Rolle. Bei 60 Sekunden läuft der Log voll damit, bei 150 Momentan ist es deutlich weniger. Aber ganz ohne NIE.
Die Fibaro Jungs lassen die z.T. mit 60 Sekunden laufen, es gibt so in dem UI des HC2 immer wieder "rote" Fehlermeldungen zu dem Thermostaten, leider weiss ich den Wortlaut nich mehr.
Das stört die aber gar nicht.
Anderseits wenn ich  immer mehrerer Befehle zugleich absetzten soll frage ich wie das dann funktionieren soll.
Beispiel der Batt Abfrage liegt doch auf dem Sendstack, wass soll da noch mit rein wenn nur das gewollt wird.

@A.HarrenbergSorry aber das finde ich Quatsch, allerdings ohne des hintergrundwissens zu fhem.
Die Meisten Sensoren senden ihre Werte doch selbstätig. Darf mann da nicht noch eine Abfrage dazu starten?

Was ich damit nur sagen wollte:
Die meisten Leute "übertreiben" es mit Ihren Logs/Abfragen an Sensoren. Wenn Du alle 30 Minuten die Batterie abfragst ist das eigentlich völlig übertrieben und auch kontraproduktiv, da dies ja den Batterieverbrauch in die Höhe treibt. Wenn das beim LC-13 in diesem kurzen Abstand sein muss damit er intern nicht abstürzt, dann hat das in diesem Fall zwar einen wichtigen Grund, sollte aber eigentlich nicht so sein wenn das dumme Ding richtig funktionieren würde. Eine Abfrage der Batterie einmal pro Tag oder vielleicht sogar nur einmal pro Woche sollte dann ja eigentlich reichen, die geben ja nicht urplötzlich auf.

Ein WakeUp-Interval von 300 Sekunden ist auch sehr kurz, bei den üblichen Trägheiten einer Heizung sollten z.B. auch 15 Minuten reichen, solange man den normalen Temperaturverlauf "autark" im Thermostaten laufen lässt. Meine Thermostate sind von Homematic, die können mit einem Funk-Burst aufgeweckt werden, das ist für so eine Anwendung natürlich ideal. Bei ZWave könnte man das mit sogenannten FLIRS (Frequent Listening) machen, das gibt es wohl schon bei Rauchmeldern, bei Thermostaten habe ich das aber bisher noch nicht gesehen.

Das dies beim LC-13 nicht alles umzusetzen ist weil das Ding einfach "speziell" ist, stellt sicherlich einen Sonderfall dar. Natürlich darfst man auch noch Abfragen wie z.B. Batterie machen, mein "falsch machen" bezog sich darauf die meisten Leute dazu tendieren zu häufig und zu viele Werte abzufragen. Ich habe hier so einen AEOTEC 6 Multisensor, der kann z.B. Luminance und ultraviolet Werte senden. Nur für sehr wenig Leute ist das WIRKLICH wichtig, also nicht abfragen und so konfigurieren das es gar nicht erst gesendet wird. Wenn man den Bewegungsmelder abhängig von der aktuellen Helligkeit z.B. zur Steuerung einer Gehweglampe nutzen möchte, dann benötigt man den Wert natürlich.

Gruß,
Andreas.

[tomspatz]

@krikan

Ist Dir bekannt, auf welche Nachricht von FHEM die LC-13 die NO_ACK liefern?

Wie finde ich das raus?

[krikan]

Wie finde ich das raus?

Setze das Attribut verbose beim ZWDongle-Device auf 5 und warte bis NO_ACK kommt. Dann im Log die zugehörige Stelle bzw. die abgesetzte Nachricht suchen. Oder den betreffenden Logauszug am Besten mit mehreren NO_ACK-Vorkommnissen hier in einem Post anhängen. Normalerweise hilft schon jemand.

[tomspatz]

Moin, habe nun etwas gesammelt, bitte auf "ThermostatBuero" achten.
Das ist einer von fünfen der vorhandenen LC-13.

Code Auswählen Erweitern

2016.12.01 07:15:42 5: device ack reveived, removing 010900130702840825256c from dongle sendstack
2016.12.01 07:15:42 5: ZWDongle_0 dispatch 001325000006
2016.12.01 07:15:42 4: CMD:ZW_SEND_DATA ID:00 ARG:0006 CB:25
2016.12.01 07:15:42 4: ZWDongle_0 transmit OK for CB 25, target ThermostatBuero
2016.12.01 07:15:52 4: ZWDongle_Read ZWDongle_0: rcvd 00040021063105012200b7 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:52 5: SW: 06
2016.12.01 07:15:52 5: ZWDongle_0 dispatch 00040021063105012200b7
2016.12.01 07:15:52 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:063105012200b7 CB:00
2016.12.01 07:15:53 4: ZWDongle_Read ZWDongle_0: rcvd 0004002105310505013c (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:53 5: SW: 06
2016.12.01 07:15:53 5: ZWDongle_0 dispatch 0004002105310505013c
2016.12.01 07:15:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:05310505013c CB:00
2016.12.01 07:15:54 4: ZWDongle_Read ZWDongle_0: rcvd 0004002103800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:54 5: SW: 06
2016.12.01 07:15:54 5: ZWDongle_0 dispatch 0004002103800364
2016.12.01 07:15:54 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:03800364 CB:00
2016.12.01 07:15:58 4: ZWDongle_Read ZWDongle_0: rcvd 00040021063105030a0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:58 5: SW: 06
2016.12.01 07:15:58 5: ZWDongle_0 dispatch 00040021063105030a0000
2016.12.01 07:15:58 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:063105030a0000 CB:00
2016.12.01 07:15:58 4: ZWDongle_Read ZWDongle_0: rcvd 00040021028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:15:58 5: SW: 06
2016.12.01 07:15:58 5: ZWDongle_0 dispatch 00040021028407
2016.12.01 07:15:58 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:028407 CB:00
2016.12.01 07:16:00 5: ZWDongle_Write 0013210284082526 (c9cc092a)
2016.12.01 07:16:00 5: SW: 0109001321028408252649
2016.12.01 07:16:00 5: ACK received, WaitForAck=>2 for 0109001321028408252649
2016.12.01 07:16:00 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:16:00 5: SW: 06
2016.12.01 07:16:00 5: ZWDongle_0 dispatch 011301
2016.12.01 07:16:00 4: ZWDongle_Read ZWDongle_0: rcvd 001326000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:16:00 5: SW: 06
2016.12.01 07:16:00 5: device ack reveived, removing 0109001321028408252649 from dongle sendstack
2016.12.01 07:16:00 5: ZWDongle_0 dispatch 001326000002
2016.12.01 07:16:00 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:26
2016.12.01 07:16:00 4: ZWDongle_0 transmit OK for CB 26, target Multisensor_01
2016.12.01 07:16:14 4: ZWDongle_Read ZWDongle_0: rcvd 0004002d0e3202216400000780007800000780 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:14 5: SW: 06
2016.12.01 07:16:14 5: ZWDongle_0 dispatch 0004002d0e3202216400000780007800000780
2016.12.01 07:16:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:2d ARG:0e3202216400000780007800000780 CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 000400100380033c (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 000400100380033c
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0380033c CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 000400100643030142079e (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 000400100643030142079e
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:0643030142079e CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 00040010044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 00040010044608007f
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:044608007f CB:00
2016.12.01 07:16:28 4: ZWDongle_Read ZWDongle_0: rcvd 00040010028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:28 5: SW: 06
2016.12.01 07:16:28 5: ZWDongle_0 dispatch 00040010028407
2016.12.01 07:16:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:028407 CB:00
2016.12.01 07:16:30 5: ZWDongle_Write 0013100284082527 (c9cc092a)
2016.12.01 07:16:30 5: SW: 0109001310028408252779
2016.12.01 07:16:30 5: ACK received, WaitForAck=>2 for 0109001310028408252779
2016.12.01 07:16:30 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:16:30 5: SW: 06
2016.12.01 07:16:30 5: ZWDongle_0 dispatch 011301
2016.12.01 07:16:30 4: ZWDongle_Read ZWDongle_0: rcvd 001327000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:16:30 5: SW: 06
2016.12.01 07:16:30 5: device ack reveived, removing 0109001310028408252779 from dongle sendstack
2016.12.01 07:16:30 5: ZWDongle_0 dispatch 001327000002
2016.12.01 07:16:30 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:27
2016.12.01 07:16:30 4: ZWDongle_0 transmit OK for CB 27, target ThermostatKueche
2016.12.01 07:16:41 4: ZWDongle_Read ZWDongle_0: rcvd 0004001f0c600d020231050144000007b7 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:41 5: SW: 06
2016.12.01 07:16:41 5: ZWDongle_0 dispatch 0004001f0c600d020231050144000007b7
2016.12.01 07:16:41 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:0c600d020231050144000007b7 CB:00
2016.12.01 07:16:57 4: ZWDongle_Read ZWDongle_0: rcvd 0004000e0c600d020231050144000007d6 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:16:57 5: SW: 06
2016.12.01 07:16:57 5: ZWDongle_0 dispatch 0004000e0c600d020231050144000007d6
2016.12.01 07:16:57 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:0c600d020231050144000007d6 CB:00
2016.12.01 07:17:03 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0c600d02023105014400000a15 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:03 5: SW: 06
2016.12.01 07:17:03 5: ZWDongle_0 dispatch 0004001a0c600d02023105014400000a15
2016.12.01 07:17:03 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0c600d02023105014400000a15 CB:00
2016.12.01 07:17:18 4: ZWDongle_Read ZWDongle_0: rcvd 000400190c600d0202310501440000070e (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:18 5: SW: 06
2016.12.01 07:17:18 5: ZWDongle_0 dispatch 000400190c600d0202310501440000070e
2016.12.01 07:17:19 4: CMD:APPLICATION_COMMAND_HANDLER ID:19 ARG:0c600d0202310501440000070e CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 0004000903800333 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 0004000903800333
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:03800333 CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 0004000906430301420834 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 0004000906430301420834
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:06430301420834 CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 00040009044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 00040009044608007f
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:044608007f CB:00
2016.12.01 07:17:22 4: ZWDongle_Read ZWDongle_0: rcvd 00040009028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:22 5: SW: 06
2016.12.01 07:17:22 5: ZWDongle_0 dispatch 00040009028407
2016.12.01 07:17:22 4: CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407 CB:00
2016.12.01 07:17:24 5: ZWDongle_Write 0013090284082528 (c9cc092a)
2016.12.01 07:17:25 5: SW: 010900130902840825286f
2016.12.01 07:17:25 5: ACK received, WaitForAck=>2 for 010900130902840825286f
2016.12.01 07:17:25 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:17:25 5: SW: 06
2016.12.01 07:17:25 5: ZWDongle_0 dispatch 011301
2016.12.01 07:17:25 4: ZWDongle_Read ZWDongle_0: rcvd 001328000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:17:25 5: SW: 06
2016.12.01 07:17:25 5: device ack reveived, removing 010900130902840825286f from dongle sendstack
2016.12.01 07:17:25 5: ZWDongle_0 dispatch 001328000002
2016.12.01 07:17:25 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:28
2016.12.01 07:17:25 4: ZWDongle_0 transmit OK for CB 28, target ThermostatWohnzimmer
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 0004000803800336 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 0004000803800336
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:03800336 CB:00
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 0004000806430301420708 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 0004000806430301420708
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:06430301420708 CB:00
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040008044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 00040008044608007f
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:044608007f CB:00
2016.12.01 07:17:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040008028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:37 5: SW: 06
2016.12.01 07:17:37 5: ZWDongle_0 dispatch 00040008028407
2016.12.01 07:17:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:028407 CB:00
2016.12.01 07:17:38 4: ZWDongle_Read ZWDongle_0: rcvd 00040029063105012200cf (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:38 5: SW: 06
2016.12.01 07:17:38 5: ZWDongle_0 dispatch 00040029063105012200cf
2016.12.01 07:17:38 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:063105012200cf CB:00
2016.12.01 07:17:39 5: ZWDongle_Write 0013080284082529 (c9cc092a)
2016.12.01 07:17:39 5: SW: 010900130802840825296f
2016.12.01 07:17:39 5: ACK received, WaitForAck=>2 for 010900130802840825296f
2016.12.01 07:17:39 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:17:39 5: SW: 06
2016.12.01 07:17:39 5: ZWDongle_0 dispatch 011301
2016.12.01 07:17:39 4: ZWDongle_Read ZWDongle_0: rcvd 001329000008 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:17:39 5: SW: 06
2016.12.01 07:17:39 5: device ack reveived, removing 010900130802840825296f from dongle sendstack
2016.12.01 07:17:39 5: ZWDongle_0 dispatch 001329000008
2016.12.01 07:17:39 4: CMD:ZW_SEND_DATA ID:00 ARG:0008 CB:29
2016.12.01 07:17:39 4: ZWDongle_0 transmit OK for CB 29, target ThermostatSchlafzimmer
2016.12.01 07:17:39 4: ZWDongle_Read ZWDongle_0: rcvd 00040029053105050132 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:39 5: SW: 06
2016.12.01 07:17:39 5: ZWDongle_0 dispatch 00040029053105050132
2016.12.01 07:17:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:053105050132 CB:00
2016.12.01 07:17:41 4: ZWDongle_Read ZWDongle_0: rcvd 0004002903800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:41 5: SW: 06
2016.12.01 07:17:41 5: ZWDongle_0 dispatch 0004002903800364
2016.12.01 07:17:41 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:03800364 CB:00
2016.12.01 07:17:45 4: ZWDongle_Read ZWDongle_0: rcvd 00040029063105030a0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:45 5: SW: 06
2016.12.01 07:17:45 5: ZWDongle_0 dispatch 00040029063105030a0000
2016.12.01 07:17:45 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:063105030a0000 CB:00
2016.12.01 07:17:45 4: ZWDongle_Read ZWDongle_0: rcvd 00040029028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:17:45 5: SW: 06
2016.12.01 07:17:45 5: ZWDongle_0 dispatch 00040029028407
2016.12.01 07:17:45 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:028407 CB:00
2016.12.01 07:17:47 5: ZWDongle_Write 001329028408252a (c9cc092a)
2016.12.01 07:17:47 5: SW: 0109001329028408252a4d
2016.12.01 07:17:47 5: ACK received, WaitForAck=>2 for 0109001329028408252a4d
2016.12.01 07:17:47 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:17:47 5: SW: 06
2016.12.01 07:17:47 5: ZWDongle_0 dispatch 011301
2016.12.01 07:17:47 4: ZWDongle_Read ZWDongle_0: rcvd 00132a00000f (request ZW_SEND_DATA), sending ACK
2016.12.01 07:17:47 5: SW: 06
2016.12.01 07:17:47 5: device ack reveived, removing 0109001329028408252a4d from dongle sendstack
2016.12.01 07:17:47 5: ZWDongle_0 dispatch 00132a00000f
2016.12.01 07:17:47 4: CMD:ZW_SEND_DATA ID:00 ARG:000f CB:2a
2016.12.01 07:17:47 4: ZWDongle_0 transmit OK for CB 2a, target Multisensor_02
2016.12.01 07:18:11 4: ZWDongle_Read ZWDongle_0: rcvd 0004002e03250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:11 5: SW: 06
2016.12.01 07:18:11 5: ZWDongle_0 dispatch 0004002e03250300
2016.12.01 07:18:11 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:03250300 CB:00
2016.12.01 07:18:14 4: ZWDongle_Read ZWDongle_0: rcvd 0004002d0e3202216400000780007800000780 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:14 5: SW: 06
2016.12.01 07:18:14 5: ZWDongle_0 dispatch 0004002d0e3202216400000780007800000780
2016.12.01 07:18:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:2d ARG:0e3202216400000780007800000780 CB:00
2016.12.01 07:18:15 4: ZWDongle_Read ZWDongle_0: rcvd 000400210a7105000000ff07000000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:15 5: SW: 06
2016.12.01 07:18:15 5: ZWDongle_0 dispatch 000400210a7105000000ff07000000
2016.12.01 07:18:15 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:0a7105000000ff07000000 CB:00
2016.12.01 07:18:16 4: ZWDongle_Read ZWDongle_0: rcvd 00040032097105000000ff070800 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:16 5: SW: 06
2016.12.01 07:18:16 5: ZWDongle_0 dispatch 00040032097105000000ff070800
2016.12.01 07:18:16 4: CMD:APPLICATION_COMMAND_HANDLER ID:32 ARG:097105000000ff070800 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004002803800336 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 0004002803800336
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800336 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004002806430301420866 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 0004002806430301420866
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:06430301420866 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 00040028044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 00040028044608007f
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:044608007f CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 00040028028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 00040028028407
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:028407 CB:00
2016.12.01 07:18:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004002103200100 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:17 5: SW: 06
2016.12.01 07:18:17 5: ZWDongle_0 dispatch 0004002103200100
2016.12.01 07:18:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:21 ARG:03200100 CB:00
2016.12.01 07:18:19 5: ZWDongle_Write 001328028408252b (c9cc092a)
2016.12.01 07:18:19 5: SW: 0109001328028408252b4d
2016.12.01 07:18:19 5: ACK received, WaitForAck=>2 for 0109001328028408252b4d
2016.12.01 07:18:19 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:18:19 5: SW: 06
2016.12.01 07:18:19 5: ZWDongle_0 dispatch 011301
2016.12.01 07:18:19 4: ZWDongle_Read ZWDongle_0: rcvd 00132b000002 (request ZW_SEND_DATA), sending ACK
2016.12.01 07:18:19 5: SW: 06
2016.12.01 07:18:19 5: device ack reveived, removing 0109001328028408252b4d from dongle sendstack
2016.12.01 07:18:19 5: ZWDongle_0 dispatch 00132b000002
2016.12.01 07:18:19 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:2b
2016.12.01 07:18:19 4: ZWDongle_0 transmit OK for CB 2b, target ThermostatBad
2016.12.01 07:18:25 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e032503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:25 5: SW: 06
2016.12.01 07:18:25 5: ZWDongle_0 dispatch 0004001e032503ff
2016.12.01 07:18:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:032503ff CB:00
2016.12.01 07:18:36 4: ZWDongle_Read ZWDongle_0: rcvd 0004000703800334 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:36 5: SW: 06
2016.12.01 07:18:36 5: ZWDongle_0 dispatch 0004000703800334
2016.12.01 07:18:36 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:03800334 CB:00
2016.12.01 07:18:37 4: ZWDongle_Read ZWDongle_0: rcvd 0004000706430301420802 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:37 5: SW: 06
2016.12.01 07:18:37 5: ZWDongle_0 dispatch 0004000706430301420802
2016.12.01 07:18:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:06430301420802 CB:00
2016.12.01 07:18:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040007044608007f (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:37 5: SW: 06
2016.12.01 07:18:37 5: ZWDongle_0 dispatch 00040007044608007f
2016.12.01 07:18:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:044608007f CB:00
2016.12.01 07:18:37 4: ZWDongle_Read ZWDongle_0: rcvd 00040007028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:37 5: SW: 06
2016.12.01 07:18:37 5: ZWDongle_0 dispatch 00040007028407
2016.12.01 07:18:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:028407 CB:00
2016.12.01 07:18:39 5: ZWDongle_Write 001307028408252c (c9cc092a)
2016.12.01 07:18:39 5: SW: 0109001307028408252c65
2016.12.01 07:18:39 5: ACK received, WaitForAck=>2 for 0109001307028408252c65
2016.12.01 07:18:39 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.12.01 07:18:39 5: SW: 06
2016.12.01 07:18:39 5: ZWDongle_0 dispatch 011301
2016.12.01 07:18:41 4: no response from device, removing 0109001307028408252c65 from dongle sendstack
2016.12.01 07:18:46 4: ZWDongle_Read ZWDongle_0: rcvd 00132c0102ac (request ZW_SEND_DATA), sending ACK
2016.12.01 07:18:46 5: SW: 06
2016.12.01 07:18:46 5: ZWDongle_0 dispatch 00132c0102ac
2016.12.01 07:18:46 4: CMD:ZW_SEND_DATA ID:01 ARG:02ac CB:2c
2016.12.01 07:18:46 2: ZWDongle_0 transmit NO_ACK for CB 2c, target ThermostatBuero
2016.12.01 07:18:46 4: ZWDongle_Read ZWDongle_0: rcvd 000400110a32022144000001050000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:46 5: SW: 06
2016.12.01 07:18:46 5: ZWDongle_0 dispatch 000400110a32022144000001050000
2016.12.01 07:18:46 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:0a32022144000001050000 CB:00
2016.12.01 07:18:46 4: ZWDongle_Read ZWDongle_0: rcvd 000400320a7105000000ff07000108 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:46 5: SW: 06
2016.12.01 07:18:46 5: ZWDongle_0 dispatch 000400320a7105000000ff07000108
2016.12.01 07:18:46 4: CMD:APPLICATION_COMMAND_HANDLER ID:32 ARG:0a7105000000ff07000108 CB:00
2016.12.01 07:18:53 4: ZWDongle_Read ZWDongle_0: rcvd 000400120c600d020231050144000001c2 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:53 5: SW: 06
2016.12.01 07:18:53 5: ZWDongle_0 dispatch 000400120c600d020231050144000001c2
2016.12.01 07:18:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0c600d020231050144000001c2 CB:00
2016.12.01 07:18:56 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e03250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:18:56 5: SW: 06
2016.12.01 07:18:56 5: ZWDongle_0 dispatch 0004001e03250300
2016.12.01 07:18:56 4: CMD:APPLICATION_COMMAND_HANDLER ID:1e ARG:03250300 CB:00
2016.12.01 07:19:01 4: ZWDongle_Read ZWDongle_0: rcvd 00040032097105000000ff070800 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.01 07:19:01 5: SW: 06
2016.12.01 07:19:01 5: ZWDongle_0 dispatch 00040032097105000000ff070800
2016.12.01 07:19:01 4: CMD:APPLICATION_COMMAND_HANDLER ID:32 ARG:097105000000ff070800 CB:00

[krikan]

Dort ist einmal NO_ACK auf die verschickte "WakeupNoMoreInformation"-Nachricht enthalten.
Wenn NO_ACK nur selten vorkommt, könnten das Funktelegrammverluste oder ander Besonderheiten sein.
Wenn das regelmäßig vorkommt würde ich, wie in #33 geschrieben:

Wenn es die "WakeupNoMoreInformation"-Nachricht (=Gehe schlafen LC-13) ist, dann experimentiere mal mit einer Verkürzung der Wachzeit mit dem Attribut WNMI_delay.

Würde nach Deinem Log passen, da 2 Sek. nach WakeupNotification die WakeupNorMoreInformation-Nachricht mit NO_ACK-Antwort verschickt wird und sonst keine Kommunikation mit dem Gerät stattfindet. Also WNMI_delay bspw. auf 1 Sekunde setzen, beobachten und bitte berichten.

Wenn Verkürzung des WMNI_delay bei den LC-13 hilft, dann ist des allgemein interessant.

[tomspatz]

Ja moin
du bist ja fix 
Vielen dank dafür erstmal.
Ich werde testen und berichten.
Grundsätzlich kommen die NO_ACK Nachrichten hier quer Beet alle Weile, doch fast ausschlieslich von Wakeup-Geräten.
Da möchte ich nicht unbedingt die LC-13 extrem schlecht tun. Die laufen wirklich gut mitlerweile.

Scheinbar auch ohne:

Das Danfoss Heizungsthermostat LC-13 muss derzeit zur korrekten Funktion mit FHEM regelmäßig mit folgendem at abgefragt werden (Beitrag):
define Atdanfoss at +*00:30 get <name> battery

Dafür habe ich jetzt allerdings ohne des at's weniger von den NO_ACK's.

Da ja Funkinformationen immer MAL verloren gehen könne sehe ich das nicht so sehr wenn sie sporadisch kommen, die devices allerdings funktionieren.
Doch kann man da ja sicherlich optimieren.
LG
Tom

[tomspatz]

Das lässt mir alles keine Ruhe.
Bin mit WNMI_delay am testen mit 1 bzw. jetzt mit 0.2 aber das sieht alles nicht viel anders aus.
Ist es evtl. möglich das die Nachrichten die hin und her gesendet werden irgendwie "andere" Wege nehmen?
Habe massig die NO_ACK oft mehrfach nacheinander dann wieder stundenlang gar nicht, trotzdem läuft das alles.
Teils auch :

Code Auswählen Erweitern

ERROR: cannot SEND_DATA to ThermostatSchlafzimmer: transmit queue overflow
trotzdem läuft es ja. Das zeitgesteuerte setzten der jeweiligen Temperaturen checken die LC-13 fix, nachdem sie wach sin.
SORRY das nervt irgendwie komme ich nicht weiter.
LG
Tom

[krikan]

Ist es evtl. möglich das die Nachrichten die hin und her gesendet werden irgendwie "andere" Wege nehmen?

Grunsaetzlich möglich. Jedoch mMn nicht der Standardfall.

Habe massig die NO_ACK oft mehrfach nacheinander dann wieder stundenlang gar nicht, trotzdem läuft das alles.
Teils auch :

Code Auswählen Erweitern

ERROR: cannot SEND_DATA to ThermostatSchlafzimmer: transmit queue overflow
trotzdem läuft es ja. Das zeitgesteuerte setzten der jeweiligen Temperaturen checken die LC-13 fix, nachdem sie wach sin.
SORRY das nervt irgendwie komme ich nicht weiter.

Du musst ein System der NO_ACK und ERROR suchen und finden. Erst dann kann man tatsaechlich Rückschlüsse ziehen und vielleicht Abhilfe schaffen. Wenn es keine Regelmaeßigkeit gibt, dann wird es sehr schwierig.
Wenn es laeuft, kann man es auch ignorieren. Dennoch interessiert mich aus reiner Neugierde die Ursache.

[tomspatz]

Guck mal bitte in diesen Abschnitt:

Code Auswählen Erweitern

2016.12.05 16:31:39 2: ZWDongle_0 transmit NO_ACK for CB 8c, target ThermostatBuero
2016.12.05 17:46:20 3: ZWave set LichtFlurSpiegel on
2016.12.05 17:46:50 3: ZWave set LichtKueche on
2016.12.05 17:48:16 2: ZWDongle_0 transmit NO_ACK for CB 24, target ThermostatBuero
2016.12.05 17:48:35 3: ZWave set LichtBad_30.02 on
2016.12.05 17:48:40 3: ZWave set LichtBad_30.02 off
2016.12.05 17:54:09 2: ZWDongle_0 transmit NO_ACK for CB 30, target ThermostatBuero
2016.12.05 17:59:48 2: ROOMMATE set rr_Tom absent
2016.12.05 18:00:39 2: ROOMMATE set rr_Tom home
2016.12.05 18:02:57 2: ZWDongle_0 transmit NO_ACK for CB 41, target ThermostatBuero
2016.12.05 18:11:09 3: ZWave set LichtBad_30.02 on
2016.12.05 18:11:14 3: ZWave set LichtBad_30.02 off
2016.12.05 18:23:49 3: ZWave set LichtBad_30.02 on
2016.12.05 18:23:54 3: ZWave set LichtBad_30.02 off
2016.12.05 18:24:09 3: ZWave set LichtSchlafzimmerSchrank1A on
2016.12.05 18:26:28 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900130702840825743d
2016.12.05 18:26:35 2: ZWDongle_0 transmit NO_ACK for CB 75, target ThermostatBuero
2016.12.05 18:47:12 2: ZWDongle_0 transmit NO_ACK for CB 9d, target ThermostatBuero
2016.12.05 18:54:41 2: ZWDongle_0 transmit NO_ACK for CB ac, target FensterBuero
2016.12.05 19:01:56 2: ZWDongle_0 transmit NO_ACK for CB ba, target ThermostatBuero
2016.12.05 19:08:06 3: ZWave set ThermostatWohnzimmer thermostatSetpointSet 12.00
2016.12.05 19:08:06 3: set ThermostatWohnzimmer thermostatSetpointSet 12.00 : Scheduled for sending after WAKEUP
2016.12.05 19:08:06 3: HeizungReglerNotifyWohnzimmer return value: Scheduled for sending after WAKEUP
2016.12.05 19:08:25 3: ZWave set ThermostatWohnzimmer thermostatSetpointSet 22.50
2016.12.05 19:08:25 3: set ThermostatWohnzimmer thermostatSetpointSet 22.50 : Scheduled for sending after WAKEUP
2016.12.05 19:08:25 3: HeizungReglerNotifyWohnzimmer return value: Scheduled for sending after WAKEUP
2016.12.05 19:10:40 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900130702840825cb82
2016.12.05 19:10:47 2: ZWDongle_0 transmit NO_ACK for CB cc, target ThermostatBuero
2016.12.05 19:11:20 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900132802840825cdab
2016.12.05 19:11:21 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900132802840825cdab
2016.12.05 19:22:32 2: ZWDongle_0 transmit NO_ACK for CB e3, target ThermostatBuero
2016.12.05 19:57:53 2: ZWDongle_0 transmit NO_ACK for CB 28, target ThermostatBuero
2016.12.05 19:58:20 2: ZWDongle_0 transmit NO_ACK for CB 2a, target ThermostatKueche
2016.12.05 20:00:49 2: ZWDongle_0 transmit NO_ACK for CB 2f, target ThermostatBuero
2016.12.05 20:03:46 2: ZWDongle_0 transmit NO_ACK for CB 35, target ThermostatBuero
2016.12.05 20:21:26 2: ZWDongle_0 transmit NO_ACK for CB 57, target ThermostatBuero
2016.12.05 20:38:51 3: ZWave set LichtBueroGabi off
2016.12.05 20:39:16 3: ZWave set LichtBuero1A off
2016.12.05 20:39:18 3: ZWave set FunkDose1 off

ist willkürlich raus kopiert, da kannste mal gucken wie das so aussieht 

Aber dazu noch ne Frage, hier angefangen:

Code Auswählen Erweitern

2016.12.05 19:08:06 3: set ThermostatWohnzimmer thermostatSetpointSet 12.00 : Scheduled for sending after WAKEUP
werden nacheinander zwei verschiedene Befehle in den WAKEUP SendStack gelegt.
Dann wird das ThermostatWohnzimmer ja irgendwann wach, haben die resending message etwas damit zu tun?
Wenn könnte man so etwas nicht vermeiden?
Was ich meine, es werden ja ggf. viele, viele Nachrichten auf einmal dann abgefeuert?
Ist das dann halt so, oder immer jede einzeln nach jedem aufwachen?

[krikan]

ist willkürlich raus kopiert, da kannste mal gucken wie das so aussieht 

Schlecht. Kenne ich so nicht. Problem: mangels verbose 5 Log kann ich über tatsaechlichen Ablauf nur Vermutungen anstellen. Wenn WNMI_delay auf 0.2 stand, dann bitte wieder hochsetzen und nicht unter 0.5 gehen.

Aber dazu noch ne Frage, hier angefangen:

Code Auswählen Erweitern

2016.12.05 19:08:06 3: set ThermostatWohnzimmer thermostatSetpointSet 12.00 : Scheduled for sending after WAKEUP
werden nacheinander zwei verschiedene Befehle in den WAKEUP SendStack gelegt.

Warum wird denn der gleiche Befehl mit so total unterschiedlichen Werten (12 versus 22.5)  überhaupt abgesetzt? Kann das überhaupt funktionieren?

Dann wird das ThermostatWohnzimmer ja irgendwann wach, haben die resending message etwas damit zu tun?

Vermutlich.

Wenn könnte man so etwas nicht vermeiden?

Doppeltes Absetzen des gleichen Befehls zwischen zwei Wakeups vermeiden (es sei denn Du überzeugst mich von der Notwendigkeit). Da mir nicht bekannt ist, wie und warum das gemacht wird, kann ich Dir keine Alternative liefern.

Was ich meine, es werden ja ggf. viele, viele Nachrichten auf einmal dann abgefeuert?
Ist das dann halt so, oder immer jede einzeln nach jedem aufwachen?

Die Nachrichten werden pro Geraet einzeln und nacheinander abgesetzt. Es kann aber dennoch zu Funkkollisionen kommen, die durch Antworten des Geraetes selbst oder anderer Geraete entstehen. Die gilt es zu minimieren, indem unnötige Befehle vermieden werden.

[tomspatz]

Warum wird denn der gleiche Befehl mit so total unterschiedlichen Werten (12 versus 22.5)  überhaupt abgesetzt? Kann das überhaupt funktionieren?

hmm das gehört zur Lüftung, Fenster auf Erkennung Heizung runter, Fenster zu Heizung wieder rauf. Grundsätzlich funktioniert das, im Frontend, wobei es ggf. ja auch irgendwelche Schreinerei machen könnte die sich evtl. später auswirkt.
Wenn du Spaß dran hast poste ich gerne hier eine Gesamte Konfiguration dieser Geschichte für ein Fenster, vielleicht hast du da noch eine Idee dazu.

Verbose 5 möchte ich erstmals nachts setzen, da gibt es keinerlei andere Sachen die stören könnten.
Lässt sich ein attr auch per at setzen?