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

[arteck]

@jrgsch LOG erzeugen... schon mal drüber nachgedacht

[AlCalzone]

@jrgsch Bitte die folgenden Infos liefern:
https://github.com/AlCalzone/ioBroker.zwave2/blob/master/docs/de/bei-problemen.md#notwendige-informationen-für-ein-issue

[wykat]

@AlCalzone : Danke diesen link hab ich gesucht

Das plugin (verwende noch 1.7.5) funktioniert richtig gut mit die meiste meine z-wave modulen

Nur 1 (von 8 ) Fibaro FGK-101 Tur/Fenster sensoren gibt leider nicht alle daten. Es funktionieren die tur erkennung und tamper, nur gibt er nicht alle weitere info's (wie zum beispiel batterie). Die andere 7 funktionieren einwandfrei.

Im log steht:
08:55:54.023 CNTRLR [Node 036] Beginning interview - last completed stage: None
08:55:54.024 CNTRLR [Node 036] new node, doing a full interview...
08:55:54.024 CNTRLR » [Node 036] querying protocol info...
08:55:54.033 SERIAL » 0x01040041249e (6 bytes)
08:55:54.035 DRIVER » [REQ] [GetNodeProtocolInfo]
payload: 0x24
08:55:54.042 SERIAL « [ACK] (0x06)
08:55:54.044 SERIAL « 0x01090141539c010407017a (11 bytes)
08:55:54.044 SERIAL » [ACK] (0x06)
08:55:54.046 DRIVER « [RES] [GetNodeProtocolInfo]
payload: 0x539c01040701
08:55:54.051 CNTRLR « [Node 036] received response for protocol info:
basic device class: Static Controller
generic device class: Notification Sensor
specific device class: Notification Sensor
is a listening device: false
is frequent listening: false
is a routing device: true
is a secure device: unknown
is a beaming device: true
maximum baud rate: 40000 kbps
version: 4
08:55:54.052 CNTRLR [Node 036] The node is now awake.
08:55:54.057 CNTRLR [Node 036] Interview stage completed: ProtocolInfo
08:55:54.061 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!
08:55:54.065 CNTRLR [Node 036] did not respond after 1/3 attempts. Scheduling next try in 500 ms.
08:55:54.066 CNTRLR » [Node 036] pinging the node...
08:55:54.568 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!
08:55:54.570 CNTRLR [Node 036] did not respond after 2/3 attempts. Scheduling next try in 500 ms.
08:55:55.073 DRIVER Unexpected error during SerialAPI command: ZWaveError: Security CC requires a
nonce to be sent!]
08:55:55.098 SERIAL » 0x01080013240100255fbb (10 bytes)
08:55:55.099 DRIVER » [Node 036] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 95
└─[NoOperationCC]
08:55:55.099 CNTRLR [Node 036] The node is not included securely. Continuing interview non-securel
y.
08:55:55.100 CNTRLR [Node 036] WakeUpCC: doing a complete interview...
08:55:55.100 CNTRLR » [Node 036] retrieving wakeup interval from the device...
08:55:55.103 SERIAL « [ACK] (0x06)
08:55:55.106 SERIAL « 0x0104011301e8 (6 bytes)
08:55:55.107 SERIAL » [ACK] (0x06)
08:55:55.108 DRIVER « [RES] [SendData]
was sent: true
08:56:01.922 SERIAL « 0x010700135f0102aa1d (9 bytes)
08:56:01.923 SERIAL » [ACK] (0x06)
08:56:01.925 DRIVER « [REQ] [SendData]
callback id: 95
transmit status: NoAck
08:56:01.938 SERIAL » 0x01090013240272042560f0 (11 bytes)
08:56:01.939 DRIVER » [Node 036] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 96
└─[ManufacturerSpecificCCGet]
08:56:01.940 CNTRLR [Node 036] The node did not respond after 1 attempts.
It is probably asleep, moving its messages to the wakeup queue.
08:56:01.941 CNTRLR [Node 036] The node is now asleep.
08:56:01.944 CNTRLR [Node 036] ping failed: Failed to send the command after 1 attempts (Status No
Ack)
08:56:01.945 CNTRLR » [Node 036] querying node info...
08:56:01.955 SERIAL « [ACK] (0x06)
08:56:01.958 SERIAL « 0x0104011301e8 (6 bytes)
08:56:01.959 SERIAL » [ACK] (0x06)
08:56:01.961 DRIVER « [RES] [SendData]
was sent: true
08:56:08.672 SERIAL « 0x01070013600102a028 (9 bytes)
08:56:08.672 SERIAL » [ACK] (0x06)
08:56:08.673 DRIVER « [REQ] [SendData]
callback id: 96
transmit status: NoAck

Wurde ein upgrade auf 1.7.8 helfen? Ich hab auch noch ein Fibaro rauchmelder die sich ahnlich verhalt, da muss ich mir das log noch mal anschauen. Ein 2e rauchmelder bleibt immer wach (und damit mit batterie nutzlos)

Danke fur die sehr gute arbeit!

[wykat]

@AlCalzone : Beim versuch mit der Rauchmelder hat's dann auf einmal funktioniert (paar mal tamper taste gedruckt) und der ist dann angefangen seine konfiguration zu senden Hab das noch ein mal mit der tur sensor getan (hatte das vorher ohne erfolg versucht) und sehe da auf einmal funktioniert er

Hab jetzt aber das probleem das 2 rauchmelder immer awake bleiben. Hab die geraten auch schon auf factory default gereset aber das bringt leider nichts. Kann dein adapter da helfen oder liegt das einfach an die geraten?

[wykat]

@AlCalzone:

Es sind alle Fibaro FGSS001 Rauchmelder, sind laut Manufacturing information gleich, aber unterscheiden sich:
Ein funktionierende FGSS001:

Bemerke ControllerNodeId beim Wakeup (1)

Der erste FGSS001 die bleibt alive:

Hier steht ControllerNodeId auf 255 ! obwohl manufacturing specific und version gleich sind. Ich kann diesen wert auch nicht andern

Der 3e FGSS001 gibt uberhaupt keine Wakeup informationen (vielleicht weil der batterie schnell lehr ist)

Ich habe mal das log file vom node 038 dran gehangt und ein paar batterie punkten rot markiert. Vielleicht gibt's da eine losung?

Fibaro FGSS001.odt

[wykat]

@wykat : Hier der anhang als PDF....

Fibaro FGSS001.pdf

[AlCalzone]

@wykat Puh, das ist eine chaotische Meldung.

Bitte:

• Update auf 1.7.10 um auszuschließen, dass wir Geister jagen
• Logs bitte nicht im Post einfügen, sondern als vollständige Textdateien anhängen ohne Formatierung
• Geräte, bei denen ready auf true steht, aber trotzdem irgendwas mit den Datenpunkten nicht stimmt, über die Adapter-Konfiguration gezielt einzeln neu interviewen.
• Dann bitte nochmal zusammenfassen, was jetzt nicht geht, bestenfalls von den erneuten Interviews ein Log anhängen.

[wykat]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

@wykat Puh, das ist eine chaotische Meldung.

Bitte:

• Update auf 1.7.10 um auszuschließen, dass wir Geister jagen

Gemacht, aber leider keine verbesserung

• Logs bitte nicht im Post einfügen, sondern als vollständige Textdateien anhängen ohne Formatierung

Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?

• Geräte, bei denen ready auf true steht, aber trotzdem irgendwas mit den Datenpunkten nicht stimmt, über die Adapter-Konfiguration gezielt einzeln neu interviewen.

Ja das hab ich schon mehrmals gemacht (man sieht im log was alles ausgetauscht wird zwischen zWave stick und die rauchmelder

• Dann bitte nochmal zusammenfassen, was jetzt nicht geht, bestenfalls von den erneuten Interviews ein Log anhängen.

Ich hab 3 Fibaro FGSS001 rauchmelder die alle 3 behaupten identisch zu sein (gleiche firmware, library, etc.):
Node4: Funktioniert einwandfrei
Node29: Bleibt immer 'alive', sowohl im zWave2 instance als im objects. Hab kein eintrag im log gefunden das Node29 'asleep' gegangen ist. Beim Node29 fehlt immer noch die option Wake_up (ist bei Nodes 4 und 38 da).


Node38: Bleibt immer 'awake' im objects, im instance aber als asleep angezeigt. Log zeigt das diese node38 asleep ist. Hab jetzt mal eine neue batterie installiert aber denke der wird auch wieder schnell lehr sein.

[AlCalzone]

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

Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?

Jup, einfach hier im Forum hochladen.

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

Node38: Bleibt immer 'awake' im objects, im instance aber als asleep angezeigt. Log zeigt das diese node38 asleep ist.

Das könnte ein Anzeigefehler im Admin sein. Bei den anderen ist definitiv was faul.

[wykat]

@AlCalzone said in Test Adapter Z-Wave 2 (v1.7.x):

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

Kann nur "upload file" machen, das neue log file nach update und node refresh habe ich. Ist das ok?

Jup, einfach hier im Forum hochladen.

Anbei, danke!
zwave-12345.log

[gelberlemmy]

@AlCalzone ich habe da auch noch ein kleines Anliegen bezüglich eine Aeon Lab Keyfob. Die Fernbedienung habe ich angelernt. Nur scheinen dort auch noch Datenpunkte zu fehlen. habe bereits das Gerät neu interviewt. Anbei einmal ein Screenshot welche Datenpunkte dort angelegt sind. Auch mit der Betätigung von Tasten, kommen keine neuen Datenpunkten. Logs schicke ich Dir per Mail. Es geht da um Note 071

Gruß und Danke André

[AlCalzone]

@all - Hab euch nicht vergessen, nur viel zu tun und bin seit ein paar Tagen auf Bug-Jagd

[AlCalzone]

@gelberlemmy

Das war ein Fall von "Anleitung lesen" Dein Gerät ist im Group-Modus, d.h. es kommuniziert direkt mit den Geräten, die du verknüpft hast!

Your Key Fob is in Use (Group) Mode.
In order to program each button of your Key Fob, please refer to the ‘Selecting which devices to control’ section of this guide.

Your Key Fob is in Use (Scene) Mode.
In this mode your Key Fob communicates directly with your Z-Wave network’s primary controller, generally a gateway or hub. By pressing each scene button, your Key Fob will send out a scene ID telling the primary controller to activate customized scenes that need to be setup via your controller’s interface.

Stell den Konfigurationsparameter auf Scene Mode und alles sollte gut sein.

[gelberlemmy]

@AlCalzone ja hab ich auch gesehen. Aber im Szenen Modus ist es nicht anders. Da schicke ich einmal den Log. Hatte beides versucht.

[Harry94]

Hallöchen,

ich hätte da mal wieder ein Log

Und zwar habe ich mir ein HeatIT Z-TRM3 beigeschafft, lässt sich auch (ohne Verschlüsselung) problemlos inkludieren.
Die Werte des Sensors kommen an, und stimmen auch mit denen auf dem lokalen Display überein.
Auch die anderen Datenpunkte wie Stauts (an/aus) oder ob grade geheizt wird sowie der aktuelle Setpoint kommt durch.
Wenn ich jetzt über iobroker einen Befehl senden will kommt nichts an. im Iobroker selbst wird der wert aber als bestätigt angegeben.
In den Objekten wird auch keine Bezeichnung außer NODE 046 angegeben.

201112 HeatIT Z-TRM3 NODE 046.rar

Anbei noch die Datenpunkte die Vorhanden sind.

hoffe das Hilft weiter.

Lg

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