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

[simatec]

@Tom-Haase
Deine Einstellungen sind noch immer falsch.
Bitte stelle es wie folgt ein

[simatec]

@Tom-Haase
Ich habe deine Konstellation mal simuliert und es funktioniert problemlos.
Bitte halte dich an meinen Screenshot bzw. meine markierten Änderungen

[Tom Haase]

@simatec said in Test Adapter shuttercontrol v1.1.x:

Hi,
das hatte ich ja schon eingestellt und damit fährt das Ding ja auch odentlich rauf und runter. Aber eben der Fensterkontakt mag diese Einstellung nicht und möchte es anscheinend lieber anders rum.

2021-01-12 07:42:14.678 - debug: shuttercontrol.0 (29264) TriggerID changed: zigbee.0.00158d00053f428f.opened Value: true
2021-01-12 07:42:14.682 - debug: shuttercontrol.0 (29264) save trigger height: 100% for device: Buero1 pct
2021-01-12 07:42:14.683 - debug: shuttercontrol.0 (29264) save trigger action: down for device: Buero1 pct
2021-01-12 07:42:18.533 - debug: shuttercontrol.0 (29264) TriggerID changed: zigbee.0.00158d00053f428f.opened Value: false
2021-01-12 07:42:18.540 - debug: shuttercontrol.0 (29264) shutter trigger released Buero1 pct already in place: 100%
2021-01-12 07:42:18.541 - debug: shuttercontrol.0 (29264) save back trigger action: down for device Buero1 pct

Hattest du den Fensterkontakt auch simuliert?

[simatec]

@tom-haase
Den Fensterkontakt hatte ich auch simuliert.
Der Zigbee Kontakt opened ist ein ein state für die Meldung offen.

offen = true
geschlossen = false

shuttercontrol benötigt in der Config den Wert des geschlossenen Zustandes.
Also musst du "false" einstellen.

[Tom Haase]

@simatec said in Test Adapter shuttercontrol v1.1.x:

Also musst du "false" einstellen.

Alles brav gemacht, das Biest macht nix.
:angry:

[FoxRo]

@tom-haase said in Test Adapter shuttercontrol v1.1.x:

@simatec said in Test Adapter shuttercontrol v1.1.x:

Also musst du "false" einstellen.

Alles brav gemacht, das Biest macht nix.
:angry:

habe auch nochmals im Code geschaut.
Die Log-Einträge von Dir oben passen leider auch zu einer Situation, wenn er nicht in den Ast geht, um effektiv zu fahren. Mit anderen Worten, wenn er das "Gefühl" hat, dass der Rollo schon korrekt offen steht, wenn das Fenster geöffnet wird. Dann kommt nämlich kein Fahr-Auftrag.
Kannst Du mal die Objekt-Werte von Shuttercontrol - shutters - autolevel - >Dein Rollo< hier posten, einmal bei Fenster zu und einmal während Du das Fenster offen hast?
zusätzlich wäre es, wie schon mal weiter oben geschrieben, interessant zu wissen, was im autoState drin steht, wenn das Fenster offen und wenn es zu ist. Könnte sein, dass sich hier der Zustand eben doch ändert.
Das gäbe evtl einen Hinweis, wo der Code in Deinem Fall effektiv durchläuft.

[simatec]

@tom-haase
Ich denke du musst in den Extraeinstellungen die Überprüfung deiner Rollläden einschalten. Dein State wird sicher nicht sofort gesetzt.
Mit der Option wird der Status nach einer Minute noch einmal abgefragt

[zolpetol]

Der Adapter steuert zuverlässig zwei neue Rollläden bei uns - vielen Dank!

Allerdings haben wir ein kleines Problem beim lüften am Morgen. Die "späteste Zeit für das hochfahren" ist auf 07:30h eingestellt. Das Fenster wird aber nun z.B. manchmal um 07:20h zum lüften geöffnet und der Rollladen fährt wie konfiguriert auf 50% hoch. 07:35h wird das Fenster wieder geschlossen, der Rollladen fährt wieder runter - bleibt aber zu da 07:30h bereits vorbei ist. Da hilft aktuell nur manuelle Betätigung :confounded:

Konfiguration:

Hat jemand einen Tipp?
Danke!

[FoxRo]

@zolpetol said in Test Adapter shuttercontrol v1.1.x:

Hat jemand einen Tipp?
Danke!

Dazu kannst Du den "Aussperrschutz" verwenden der bei Dir aktuell auf Aus steht.
Die Option "Fahren, nachdem das Fenster geschlossen wurde" ist mit dem Aussperrschutz gekoppelt!
Verwende Aussperrschutz = "Schliessen" wenn der Rollo bei offenem Fenster mit den anderen Rollos Schliessen soll, beim öffnen aber erst fahren darf, wenn das Fenster geschlossen wurde.
Verwende Aussperrschutz = "Öffnen" wenn der Rollo zusammen mit den anderen öffnen soll, aber erst schliessen darf, wenn das Fenster geschlossen wurde.
Verwende Aussperrschutz = "Öffnen/Schliessen" wenn der Rollo bei offenen Fenster zusammen mit den anderen öffnen und schliessen darf/soll.
Viele Grüsse, Roli

[zolpetol]

@foxro Danke für den Hinweis, probiere ich einmal aus!

[Tom Haase]

@foxro said in Test Adapter shuttercontrol v1.1.x:

Kannst Du mal die Objekt-Werte von Shuttercontrol - shutters - autolevel - >Dein Rollo< hier posten, einmal bei Fenster zu und einmal während Du das Fenster offen hast?
zusätzlich wäre es, wie schon mal weiter oben geschrieben, interessant zu wissen, was im autoState drin steht, wenn das Fenster offen und wenn es zu ist.
Rollo oben:

und bei Rollo unten:

Rollo unten und Fensterkontakt auf:

Rollo oben und Kontakt auf:

@simatec
Habe die Option jetzt in den Extraeinstellungen gesetzt.

Die Zeitsteuerung funzt wie gehabt super, Fensterkontakt leider keine Reaktion.

[FoxRo]

@tom-haase said in Test Adapter shuttercontrol v1.1.x:

Rollo oben:

und bei Rollo unten:

Rollo unten und Fensterkontakt auf:

Langsam kommen wir der Sache auf die Spur. Er geht wie vermutet in den falschen "Ast".
Welche Node.JS Version hast Du bei Dir installiert?
Das Problem liegt in dieser Zeile Code
if (typeof state != undefined && state != null && state.val != arrayChangeTrigger[i].triggerDrive && arrayChangeTrigger[i].triggerChange != 'off' && ((state.val < arrayChangeTrigger[i].triggerDrive && convertShutter == false) || (state.val > arrayChangeTrigger[i].triggerDrive && convertShutter == true))) {

Diese checkt, nachdem das Fenster geöffnet wurde, ob der Rollo nicht auf der angeforderten Höhe steht, und der Rollo weiter unten steht als die angeforderte Höhe steht ..

Nun ist es im Java Script so, dass eine Prüfung mit (!=) nicht gleich der Prüfung (!==) ist. Und da ist im JS aus meiner Sicht völlig willkürlich, was man wann genau benutzen muss.
Ich würde behaupten, wenn man den Code so formulieren würde

if (typeof state !== undefined && state !== null && state.val !== arrayChangeTrigger[i].triggerDrive && arrayChangeTrigger[i].triggerChange !== 'off' && ((state.val < arrayChangeTrigger[i].triggerDrive && convertShutter == false) || (state.val > arrayChangeTrigger[i].triggerDrive && convertShutter == true))) {
Dann würde es wohl funktionieren.
Traust Du Dir zu, dies im File "triggerChange.js" testhalber zu ändern?

@simatec : Das ich habe in meinem Fork auch schon ähnliches angepasst, da ich an einer anderen Stelle auch plötzlich solche Probleme bekam. Weiter habe ich da auch noch eine zusätzliche Funktion um das Öffen/Schliessen verzögern zu können eingebaut.
Soll ich dir dies mal auf Dein DEV pushen?
Viele Grüsse, Roli

[Tom Haase]

@foxro said in Test Adapter shuttercontrol v1.1.x:

Welche Node.JS Version hast Du bei Dir installiert?

v12.20.0

[dirkhe]

@foxro das ist nicht willkürlich, wenn man a == false abfragst, würde du zb. True zurückbekommen wenn a
Den Zustand false hat oder null oder undefined oder 0
Wenn du a === false abfragt bekommst du auch wirklich nur beim zustsnd false true zurück

[Tom Haase]

@foxro said in Test Adapter shuttercontrol v1.1.x:

if (typeof state !== undefined && state !== null && state.val !== arrayChangeTrigger[i].triggerDrive && arrayChangeTrigger[i].triggerChange !== 'off' && ((state.val < arrayChangeTrigger[i].triggerDrive && convertShutter == false) || (state.val > arrayChangeTrigger[i].triggerDrive && convertShutter == true))) {
Dann würde es wohl funktionieren.
Traust Du Dir zu, dies im File "triggerChange.js" testhalber zu ändern?

Gesagt, getan (Notepad++)......leider nix

[simatec]

@foxro
Ja pushe ruhig mal.
Arbeite momentan viel an Backitup und komme gerade aus Zeitgründen nicht dazu

[simatec]

@tom-haase
Beobachte mal bitte beim fahren deines Rollladens bitte den State im fhem Adapter.
Ich hab das Gefühl, dass dieser nicht sofort den Wert setzt

[FoxRo]

@simatec said in Test Adapter shuttercontrol v1.1.x:

@foxro
Ja pushe ruhig mal.
Arbeite momentan viel an Backitup und komme gerade aus Zeitgründen nicht dazu

Das war ein "Pfuschversuch" mit dem Vorschlag an @Tom-Haase . :smirk:
Er offenbart auch, dass ich bei @Tom-Haase nun am Ende meines Lateins bin. Ohne Debugger komme ich da nicht mehr weiter.
Es wird wohl, wie Du sagst, mit dem State zu tun haben.
PS. Das mit dem PR halte ich noch ein wenig zurück. Grund: das mit der von mir veränderten Abfrage der Stati bei mir passt mir noch nicht, da ich es noch nicht 100% verstehe, obwohl es funktioniert.
@Tom-Haase : Bitte meinen "Pfusch-Vorschlag" wieder zurück stellen. Das bringt nichts. Sorry, lag da daneben.

Viel Erfolg euch!
Viele Grüsse, Roli

[Tom Haase]

@simatec said in Test Adapter shuttercontrol v1.1.x:

@tom-haase
Beobachte mal bitte beim fahren deines Rollladens bitte den State im fhem Adapter.
Ich hab das Gefühl, dass dieser nicht sofort den Wert setzt

beim runterfahren:

2021.01.17 10:21:07 3 : Testname: SD_Keeloq_AC6000 set down 9
2021-01-17 10:21:07 ROLLO Friedhelm command: pct-100
2021-01-17 10:21:07 ROLLO Friedhelm desired_pct: 100
2021-01-17 10:21:07 ROLLO Friedhelm last_drive: drive-down
2021-01-17 10:21:07 ROLLO Friedhelm drive-down
2021-01-17 10:21:07 ROLLO Friedhelm drive-type: modul
2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 button: down
2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 channel: 9
2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9686
2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 send down
2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: down
2021-01-17 10:21:07 SD_Keeloq SD_Keeloq_AC6000 channel_control: no
2021.01.17 10:21:34 3 : Testname: SD_Keeloq_AC6000 set stop 9
2021-01-17 10:21:34 ROLLO Friedhelm pct: 100
2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 button: stop
2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 channel: 9
2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9687
2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 send stop
2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: stop
2021-01-17 10:21:34 SD_Keeloq SD_Keeloq_AC6000 channel_control: no
2021-01-17 10:21:34 ROLLO Friedhelm closed

beim hochfahren:

2021.01.17 10:22:39 3 : Testname: SD_Keeloq_AC6000 set up 9
2021-01-17 10:22:39 ROLLO Friedhelm command: pct-0
2021-01-17 10:22:39 ROLLO Friedhelm desired_pct: 0
2021-01-17 10:22:39 ROLLO Friedhelm last_drive: drive-up
2021-01-17 10:22:39 ROLLO Friedhelm drive-up
2021-01-17 10:22:39 ROLLO Friedhelm drive-type: modul
2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 button: up
2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 channel: 9
2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9688
2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 send up
2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: up
2021-01-17 10:22:39 SD_Keeloq SD_Keeloq_AC6000 channel_control: no
2021.01.17 10:23:08 3 : Testname: SD_Keeloq_AC6000 set stop 9
2021-01-17 10:23:08 ROLLO Friedhelm pct: 0
2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 button: stop
2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 channel: 9
2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 counter_send: 9689
2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 send stop
2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 LastAction_Channel_09: stop
2021-01-17 10:23:08 SD_Keeloq SD_Keeloq_AC6000 channel_control: no
2021-01-17 10:23:08 ROLLO Friedhelm open

Habe den Fensterkontakt mal im geschlossenen (und auch mal geöffneten) Zustand geöffnet und geschlossen, zeigt aber leider keine Reaktion im FHEM Log

Der shuttercontrol Befehl (openSleep, closeSleep) wird ohne Zeitverzögerung sofort in FHEM angezeigt und auch direkt ausgeführt.

@FoxRo
Danke für das ausprobieren und deine Geduld

[FoxRo]

@dirkhe said in Test Adapter shuttercontrol v1.1.x:

@foxro das ist nicht willkürlich, wenn man a == false abfragst, würde du zb. True zurückbekommen wenn a
Den Zustand false hat oder null oder undefined oder 0
Wenn du a === false abfragt bekommst du auch wirklich nur beim zustsnd false true zurück

Danke für Dein Feedback. Ich bin da noch am lernen und bei den "truthy" Werten bin ich unterdessen bei Dir.
Bei einer Prüfung auf "falsy" bin ich noch echt verwirrt.
Einige einschlägige Foren widersprechen sich, wie man auf 'undefined' und 'null' prüfen soll.
Was ich im IoBroker auch schon erlebt habe ist:
if (typeof state != undefined && state != null => liefert false
if (typeof state !== undefined && state !== null => liefert true
Die Erklärung für dieses Verhalten habe ich bis heute noch nicht gefunden, wenn doch eigentlich beide das gleiche Resultat liefern sollten, ausser dass bei der ersten, wenn möglich, vorab eine allfällige Typ-Konvertierung durchgeführt wird.
.. deshalb ist das für mich aktuell schon ein wenig "willkürlich" um es etwas provokativ auszudrücken.
Vielleicht hast Du dazu eine gute Erklärung die mir etwas "Erleuchtung" bringt? :male-student:
Viele Grüsse, Roli

PS. Sorry, ist eigentlich Off-Topic hier.