UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[AlCalzone]

@Harry94 Joar... Der Befehl geht auch durch, nur interessiert das das Thermostat nicht.

Befehl gesendet

14:34:18.851 DRIVER » [Node 046] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      216
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      0
                        │ destination: 1
                        └─[ThermostatSetpointCCSet]
                            setpoint type: Heating
                            value:         25 °C

danach folgt die Bestätigung dass der Befehl angekommen ist.

Die Abfrage zur Kontrolle:

14:34:18.881 DRIVER » [Node 046] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      217
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      0
                        │ destination: 1
                        └─[ThermostatSetpointCCGet]
                            setpoint type: Heating
...
14:34:18.927 DRIVER « [Node 046] [REQ] [ApplicationCommand]
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      1
                        │ destination: 0
                        └─[ThermostatSetpointCCReport]
                            setpoint type: Heating
                            value:         19 °C

antwortet aber mit 19°.

Bei einem Blick in die Anleitung habe ich das Gefühl, dass das Thermostat da auch gepflegt drauf sch*t:
http://manuals-backend.z-wave.info/make.php?lang=DE&sku=HEAE5430599&cert=ZC10-20036889
Da gibts Konfigurationsparameter für Sollwerte 🙄

Allerdings hab ich noch keine Konfigurationsdatei für das Thermostat, daher siehst du auch keine Parameter im ioBroker. Das ist zwar eins von den neueren Geräten, was automatische Erkennung der Parameter unterstützt, behauptet da aber auch gepflegt, dass es keine kennt 🙄

Du könntest für mich aber mal was testen. Ein Javascript erstellen mit folgendem Inhalt:

sendTo(
	"zwave2.0",
	"sendCommand",
	{
		nodeId: 46,
		endpoint: 0,
		commandClass: "Configuration",
		command: "getProperties",
		args: [1]
	},
	({ error, result }) => {
		if (error) {
			log(error, "error");
		} else {
			log(JSON.stringify(result));
		}
	},
);

und die Log-Ausgabe posten. Das gleiche bitte nochmal mit

sendTo(
	"zwave2.0",
	"sendCommand",
	{
		nodeId: 46,
		endpoint: 1,
		commandClass: "Configuration",
		command: "getProperties",
		args: [0]
	},
	({ error, result }) => {
		if (error) {
			log(error, "error");
		} else {
			log(JSON.stringify(result));
		}
	},
);

[AlCalzone]

Äh ja, das Gerät hat nen Bug
https://github.com/OpenZWave/open-zwave/issues/2435

[Harry94]

@AlCalzone
Gut das jemand in den Adapter die Möglichkeit eingebaut hat ne FW zu flashen ;) . Gibt da wohl schon ne korrigierte Version. Werde das heute Abend mal ausprobieren und Rückmelden.
Die Skripte geben im iobroker Log nix zurückt. Anbei nochmal die aktuellen Z-Wave logs:

201112 Z-TRM3 Node 046.rar

[AlCalzone]

@Harry94 sagte in Test Adapter Z-Wave 2 (v1.7.x):

Gibt da wohl schon ne korrigierte Version

Wirklich? Haste nen Link? Würde das gerne mal lesen. Dann kann ich mir sparen da ein Compat-Flag für einzubauen.

@Harry94 sagte in Test Adapter Z-Wave 2 (v1.7.x):

Die Skripte geben im iobroker Log nix zurück

Sieht aus als hätten sie auch nix gemacht. Du hast sie schon gestartet oder? 😅

[Harry94]

@AlCalzone
Ja hab ich. xD

also im Iobroker log war auch das zu sehen dass sie gestartet wurden.

Eventuell kannst du aus dem OZW-fork was ableiten, da scheint das problem schon angegangen worden zu sein

Spoiler

They sent me a document containing an alternative firmware, instructions to patch and most importantly a document detailing what they concluded is wrong and how to read the spec according to them.

@kpine sorry I thought I inferred from that thread that OpenHAB used OZW as well; which means whenever we figure out what is wrong that still leaves other stacks to be fixed.

About that screenshot: I was linked the Z-wave specification before which is the same document Heat-It seemed to use but it differs from yours: the capabilities report apparently defines the format which is needed for the setpoint command, so while there is some freedom at the setpoint format, demanding a specific number of bytes or precision is also possible.
See: Test of thermostat Setpoint Command Class.pdf

In my fork I now implemented this, where the capability report is parsed to retain the number of bytes and precision and applied at the setpoint command. The thermostat is actually reacting to these payloads, but unfortunately its setting the setpoint to wildly different values so something is still wrong.
Edit: link to my fork: https://github.com/Cyberwizzard/open-zwave

Auf det HeatIT homepage selbst gibt es eine
"alternative and unoffical firmware" ... find ich schon lustig XD

link

EDIT.. Das Betrifft das Vorgängermodell, sorry.

Weiterhin wurde das Problem auch schon im Openhab Forum diskutiert:

hier

ging für mich auf die schnelle nicht hervor ob das OTA update nur für die Openhab-Bindings speziell ist.

[Harry94]

@AlCalzone
Die neue FW habe ich über deinen Adapter Aufgespielt. Das Problem scheint behoben.
Das log vom flashen sowie die von mir Verwendete FW hängt an. Hoffentlich hilft es auch noch dem ein oder anderen weiter.
201112 HeaIT Z-TRM neue FW NODE 046.rar

Therm3_slave_enhanced_232_OTA_ZW050x_EU_SETPOINT_MOD_UNOFFICIAL.otz

[gelberlemmy]

@AlCalzone so jetzt funktioniert es. Hatte leider mit dieser Anleitung gearbeitet. http://manuals-backend.z-wave.info/make.php?lang=de&sku=ZW088-A&cert=ZC10-14120003. Dort ist nicht alles beschrieben. Hatte gedacht ich kann den Datenpunkt "Use Mode setting" auf "Scene Mode" stellen und das Gerät aufwecken. Sah auch ganz gut aus. Klappt aber nicht. Man muss dies hardwaretechnisch an dem KeyFob tätigen. Hab dann mal die originale Anleitung genommen.... Danke für den neuen Denkanstoss.

Gruß André

[AlCalzone]

@Harry94 sagte in Test Adapter Z-Wave 2 (v1.7.x):

"alternative and unoffical firmware" ... find ich schon lustig XD

Ich glaube die Begründung war, dass das Gerät mit den Bug zertifiziert wurde und das Verhalten nicht offiziell geändert werden kann, ohne die Zertifizierung zu verlieren. 🙄

@Harry94 sagte in Test Adapter Z-Wave 2 (v1.7.x):

Eventuell kannst du aus dem OZW-fork was ableiten

Ich weiß was das Problem ist und was man tun muss. Da es definitiv ein Bug im Gerät ist, wollte ich nicht unnötig Arbeit verschwenden, wenn es eine Firmware gibt, die das behebt.

[jrgsch]

@arteck
ja, habe ich. Da ich den Fehler aber erstmal bei mir gesucht habe eben nicht sofort losgelegt und nach einem Tipp gefragt.

@AlCalzone
ich habe die Logs zusammengestellt. Node_005, Node_007 und Node_009 sind baugleich (Coolcam Motion Sensor PD03Z). Node_005 bekommt beim Inkludieren alle (soweit überschaubar) Objekte, Node_007/009 nicht.

Ca. 10:48 habe ich ein erneutes Interview für Node_007 angestoßen und unmittelbar darauf den Motion Sensor aufgeweckt, er quittiert das auch mit einem roten Blinken so wie es gemäß Handbuch sein soll. Im Handbuch steht dann bzgl. Wake Up noch
"Command Classes
This Sensor(Motion Detector) supports Command Classes as Below:
....

• COMMAND_CLASS_WAKE_UP (V2)
  ...."

Wenn ich in das Log schaue, kann ich keinen Hinweis auf das Wakup finden (ich bin da aber kein Experte). Ich habe daraufhin bei Node_005 einen Parameter umkonfiguriert, bin dann zum Gerät, habe es aufgeweckt und erwartet, dass der Parameter im Objekt von rot auf grün geht (also übernommen wurde). Das hat auch nicht funktioniert. Ich bilde mir ein, dass das schon mal ging. Im Screenshot sieht man anhand des letzten Änderungsdatums des Status, dass das Gerät zuvor mal aufgeweckt sein muss (sonst hätte es ja keine Änderung gegeben).

Prinzipiell funktioniert die Kommunikation zu den Modulen, sie melden ihre Zustände.

Danke für die deine Unterstützung

20201113 1050 zwave-4388.log
20201113 1055 Objekte.PNG
c395e71a.json
c395e71a.metadata.jsonl
c395e71a.values.jsonl

[AlCalzone]

@jrgsch Das erneute Interview ist in deinem Fall eigentlich nicht nötig. Der Adapter versucht das selbst, sobald das Gerät aufwacht - was im Log tatsächlich nicht zu erkennen ist, weder für 5, noch für 7, noch für 9. Auch nicht beim manuellen Versuch.

Erschwerend kommt noch ein Bug im Umgang mit schlafenden Nodes hinzu, der erst vor kurzem durch die zahlreichen anderen Verbesserungen ans Tageslicht getreten ist.
Wenn ich den für die nächste Version drin hab, geht es hoffentlich mit deinen Geräten etwas flüssiger.

[AlCalzone]

Hier geht's weiter: https://forum.iobroker.net/topic/38642/test-adapter-z-wave-2-v1-8-x