THERMOSTAT_SETPOINT_REPORT wrong number of bytes received

[rudolfkoenig]

Ich habe jetzt eine Version eingecheckt, wo die "Berichtigung" der Paketlaenge direkt vor dem Parsen der KommandoKlassen stattfindet. Ist vermutlich imer noch nicht optimal, aber es geht in die richtige Richtung.

In dem letzten Log sind die zwei Bytes fuer "APPLICATION_COMMAND_HANDLER ID:05" 25-mal 7e00 und einmal dd00. Bei den anderen Nachrichten bin ich unsicher, ob was zusaetzlich angehaengt ist, oder nicht. Es waere toll, wenn wir wuessten, was diese zwei Bytes sind, und wie man sie bestellt bzw. abbestellt.

[krikan]

In dem letzten Log sind die zwei Bytes fuer "APPLICATION_COMMAND_HANDLER ID:05" 25-mal 7e00 und einmal dd00. Bei den anderen Nachrichten bin ich unsicher, ob was zusaetzlich angehaengt ist, oder nicht.

Habe die Nachrichten mit den Nachrichten einer Inklusion an einem SDK 6.5-Stick verglichen: Sehe nur bei "APPLICATION_COMMAND_HANDLER ID" - Nachrichten die angehaengten Bytes.

[Hash99]

Hi,
erst mal an Euch: Ihr seit super! Großes Kompliment! Danke für das Engagement. Und deshalb will ich Euch auch Supporten, soweit ich das mit meine nicht vorhandenen Kenntnissen tun kann. Deshalb zumindest meine Beobachtungen.
- SetpointTemp klappt. Der Fehler ist nicht mehr im Log.
- 3 von 5 Thermostaten schaffen es immer wieder sich mit E5 zu verabschieden. Interessanterweise gehen diese dann auch sporadisch so offline, dass diese dann das Ventil ganz öffnen, was nicht nachvollziehbar ist, da ich eher erwartet hätte, dass die Ventile geschlossen werden.
Aber vielleicht wird dies auch durch einen anderen Befehl ausgelöst.
Testweise habe ich bei zwei von diesen Thermostaten die Parameter multiCommand und noExplorFrames ausprobiert. Beim dritten habe ich ignoreDupMsg gesetzt.
Die beiden unauffälligsten Thermostate haben weder das eine noch das andere.
Bin halt ein Spielkind. Morgen werde ich mal alle zusätzlichen Parameter löschen. Mal sehen was das bringt.
Gruß

[krikan]

Glaube zwar nicht, dass E5 am SDK liegt, da uns das Problem seit Jahren über alle Controller-SDKs verfolgt:
Nach einem Update auf Firmware 5.27 bekomme ich für meinen UZB1 ein Downgrade auf diverse Firmwares und auch auf die SDK 6.5 Firmware 5.7 angeboten.

Am Rande: Beim SDK 6.7 bietet z-way diverse Analyse-Möglichkeiten (Background Noise, Network Statistics usw) für die es neue Controller-Funktionen gibt - > siehe https://github.com/Z-Wave-Me/Z-Way-Manual/raw/3.0/ZWayManual.pdf , Kapitel 8

[krikan]

Es waere toll, wenn wir wuessten, was diese zwei Bytes sind, und wie man sie bestellt bzw. abbestellt.

Das 1. Byte gibt vermutlich Infos zu den Empfangseigenschaften an.
Es bleibt (relativ) gleich, wenn man die Position zwischen Controller und ZWave-Gerät nicht verändert.
Folgende Werte des Bytes ergaben sich beispielsweise, wenn ich die Entfernung zwischen Controller und Gen5-Gerät schrittweise erhöht habe:
0x7e ; 0xA5 ; 0xAE ; 0xC9 ; 0xD5
Bei einem Gen3-Gerät steigen diese Werte schneller; würde zu schlechteren Funkeigenschaften passen.

Das 2. Byte ist in meinen Experimenten bisher immer 0x00.

Wie und ob man diese Infos überhaupt abbestellen kann, habe ich keine Ideen.

Insgesamt bin ich auch nicht sicher, ob die SDK 6.7-Firmwares von zwave.me schon für den normalen Einsatz bestimmt sind oder ob es noch Betas sind. Ich finde keine Infos von zwave.me zu den Firmwareversionen größer als 5.06. Zudem ist der Up- bzw. Downgrade-Pfad merkwürdig. Ich bekomme je nach installierter Firmware verschiedenste Up- und Downgradeangebote. Zudem werden mir teilweise Bridge-Firmware angeboten.

[Hash99]

Hi,
Wie angekündigt habe ich heute alle zusätzlichen Parameter gelöscht. Hat aber nichts gebracht. Wieder zweimal zwei Thermostate auf E5. Aber trotzdem konnten die Readings von diesen Thermostaten empfangen werden. Nur das Absetzen neuer Befehle zu den Thermostaten ging nicht. So als würden sie die Verbindung Kappen. Habe jetzt den WNMI_delay auf 3 gesetzt und die Entfernung zu den Thermostaten auf 5m erhöht. Warte morgen mal ab.
Überlege einen anderen USB-Stick auszuprobieren! Wenn ZWave.me einfach beta releases herausbringt ohne dies zu kennzeichnen finde ich das nicht prickelnd. Immerhin setze ich mein fhem ,,produktiv" zu Hause ein, da will ich kein Beta Tester sein, oder baue mir dazu eine gesonderte Testumgebung auf!
Gruß

[krikan]

Vorsicht: "Schuld" für das häufiger auftretende E5-Problem, mag ich nicht bei zwave.me suchen, sondern neben installationsspezifischen Problemen eher allgemein bei FHEM. Wir wissen zu wenig, wie das E5-Problem richtig gelöst werden kann. Sollte es eine andere Software geben, bei der das Problem nicht auftritt, wäre ein Mitschnitt der Funkkommunikation hilfreich. Oder jemand erklärt, wie man mit dem sensiblen Danfoss-Sprösslingen "reden" muss, damit es nicht auftritt.

Wenn das neue SDK 6.7 einen Einfluß haben sollte, was zu zusätzlichen Problemen in FHEM führen kann, da wir keine Doku zu den SDKs haben, sondern analysieren und teilweise raten müssen, dann gehe doch noch einmal zurück auf das SDK 6.5. Bedeutet: Firmware 5.27 installieren und dann Downgrade auf 5.7. Anschließend noch einmal testen, ob es dann funktioniert.

Meiner Erinnerung nach warnt zwave.me vor Firmwareupdates auch deutlich. Meine dort steht etwas wie: Nur nach Aufforderung durch Support ausführen.

Meine Testversuche und Anmerkungen zum SDK 6.7 gehen zudem nicht in Richtung E5-Lösung, sondern SDK-Untersuchung. Werde zur klareren Trennung zukünftig das Thema SDK 6.7 in einem neuen Thread behandeln.

Gruß, Christian

[Hash99]

Okay,

Du hast Recht. Man darf die Themen nicht vermengen. Somit führe ich meine Tests erst mal weiter.
Ich bleibe vorerst auf 5.27. Heute ist bis zum Nachmittag kein Thermostat ausgefallen. Der Parameter sitzt noch auf 3 s.

Gruss

[volschin]

Das mit experimenteller Firmware kann ich nicht bestätigen. Ich habe Z-Way installiert und da hatte er mir die Firmware 5.22 für ein Update automatisch angeboten ohne Hinweis auf Beta oder experimentell. (siehe der Danalock Thread).

[tomspatz]

Moin
ohne das hier kapern zu wollen
@krikan

"Schuld" für das häufiger auftretende E5-Problem, mag ich nicht bei zwave.me suchen, sondern neben installationsspezifischen Problemen eher allgemein bei FHEM.

Ich habe auch die berühmten LC13 und ich behaupte das das E5 Problem gar keines ist. Auch das periodische Batterie abfragen braucht es nicht.
https://wiki.fhem.de/wiki/Z-Wave#DAN_LC-13_Heizungsthermostat_LC-13_.28014G0013.29

Voraussetzung ist mE, neben einem "schön" vermaschten Netzwerk, ein kurzes wakeupInterwal, bei mir 180.
Noch nie hatte ich einen E5 Fehler.

LG
Tom

[krikan]

Ich habe auch die berühmten LC13 und ich behaupte das das E5 Problem gar keines ist

Gut möglich. Habe kein LC13 oder einen der Abkömmling. Kenne nur die Problemberichte hier und in anderen Foren.

.. ein kurzes wakeupInterwal, bei mir 180.

Sind das 180 Sekunden? Wie viele Batterien braucht man dann im Jahr?

Gruß, Christian

[tomspatz]

Sind das 180 Sekunden? Wie viele Batterien braucht man dann im Jahr?

Das ist das meist benutzte weil am Balkon.
Batterien eingesetzt 03.Feb.2017 jetzt noch 45 %
Sehe ich eigentlich ganz passabel.

Code Auswählen Erweitern

defmod ThermostatWohnzimmer ZWave c9cc092a 9
attr ThermostatWohnzimmer IODev ZWDongle_0
attr ThermostatWohnzimmer WNMI_delay 1.0
attr ThermostatWohnzimmer alias Thermostat WZ
attr ThermostatWohnzimmer classes BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
attr ThermostatWohnzimmer group Heizung & Temperatur
attr ThermostatWohnzimmer icon hc_wht_regler
attr ThermostatWohnzimmer ignoreDupMsg 1
attr ThermostatWohnzimmer neighborListPos 762.8774360789704,1424.4775301930767
attr ThermostatWohnzimmer room System,Wohnzimmer,ZWave
attr ThermostatWohnzimmer stateFormat {sprintf(" %.1f °C",(ReadingsNum("ThermostatWohnzimmer","setpointTemp",0)))}
attr ThermostatWohnzimmer useMultiCmd 1

setstate ThermostatWohnzimmer  21.5 °C
setstate ThermostatWohnzimmer 2016-11-21 08:26:36 CMD ZW_APPLICATION_UPDATE
setstate ThermostatWohnzimmer 2017-11-21 10:05:36 battery 45 %
setstate ThermostatWohnzimmer 2017-11-21 10:05:36 ccsOverride no, unused
setstate ThermostatWohnzimmer 2015-12-22 15:18:38 model Danfoss Z Thermostat 014G0013
setstate ThermostatWohnzimmer 2015-12-22 15:18:38 modelConfig danfoss/z.xml
setstate ThermostatWohnzimmer 2015-12-22 15:18:38 modelId 0002-0005-0004
setstate ThermostatWohnzimmer 2017-10-27 22:10:49 neighborList ZWDongle_0 LichtWohnzimmerSchrank1A LichtWohnzimmerSchrank2A FunkDose2 LichtBuero1A LichtKueche LichtFlurSpiegel DimmerWohnzimmer LichtFlur LichtBad DimmerSchlafzimmer LichtSchlafzimmerSchrank1A LichtWC
setstate ThermostatWohnzimmer 2016-11-11 14:02:59 neighborUpdate done
setstate ThermostatWohnzimmer 2017-11-21 10:05:36 setpointTemp 21.50 C heating
setstate ThermostatWohnzimmer 2017-11-21 07:33:40 state thermostatSetpointSet 21.5 °C
setstate ThermostatWohnzimmer 2017-11-21 10:05:37 timeToAck 0.027
setstate ThermostatWohnzimmer 2017-11-21 10:05:37 transmit OK
setstate ThermostatWohnzimmer 2017-11-21 10:05:36 wakeup notification
setstate ThermostatWohnzimmer 2016-12-28 11:43:15 wakeupReport interval 180 target 1



LG
Tom

[Hash99]

Hi zusammen,
hier mein Update: Zur Zeit laufen alle Thermostate ohne Probleme. Ich habe keine Änderungen mehr vorgenommen. Die Parameter sitzen noch bei einigen Thermostaten.
Der Aussage, dass E5 kein Problem darstellt kann ich nicht zustimmen. Denn wenn die Thermostate ein E5 liefern werden auch keine Commands, die von FHEM gesteuert werden, mehr verarbeitet. Erst wenn die Thermostate wieder durch Exclusion und Inklusive oder durch Verbindungsupdate wieder ein Lebenszeichen von sich geben, werden die pending commands auch verarbeitet. Dabei kann es trotzdem sein, dass einige Readings regelmäßig updated werden.
Zur Zeit bin ich mir nicht sicher, ob die alles entscheidende Frage die Frage nach dem Standort Sticks und die direkte Umgebung ist. Fast habe ich den Eindruck, dass Einflussfaktoren in der unmittelbaren Umgebung des Sticks, wie Stahl oder Stahlbeton die Empfangsbereitschaft weitaus mehr beeinflussen, als erhöhte Abstände der Wzave-Geräte und Übertragungsverluste durch Decken und Wände.
Gruss