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

[Homoran]

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

Ist es leider oft nicht.

Mittlerweile!!
die Info, dass Adapter nur noch bestätigte Werte in fremden Namespaces akzeptierrn ist relativ neu.

[haus-automatisierung]

@homoran Ne, schon immer (zumindest seit ich ioBroker kenne).

• Adapter reagieren immer nur auf unbestätigte Werte und
• in "fremde" Namespaces (außerhalb 0_userdata) schreibt man nie bestätigte Werte

Steht für mich auch noch auf ToDo, die Auswahl der Objekte dahingehend einzuschränken im JavaScript-Adapter. Also dass man im Steuere-Baustein nur Datenpunkte sieht, welche write: true definiert haben (und somit auch jemand darauf hört).

Genauso arbeiten ja viele Adapter nur mit bestätigten Werten, wenn diese weiterverarbeitet werden. Der statistics-Adapter (und viele weitere meiner Adapter) ignorieren z.B. alles, was nicht bestätigt ist. Weil der Wert ja potenziell "falsch" ist.

EDIT: Gerade geschaut. Der statistics-Adapter macht das seit 7+ Jahren so (seit Version 0.0.2: https://github.com/iobroker-community-adapters/ioBroker.statistics/blob/8a72dbf16a0b6e0244cac8f3e939a180c794ac72/main.js#L996-L997)

[Homoran]

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

Ne, schon immer

Auch wenn's OT ist, das sollte man richtigstellen!
Du vermischst da anscheinend noch weitere Informationen.

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

Adapter reagieren immer nur auf unbestätigte Werte

..in den jeweiligen Adapternamespaces!
d'accord!

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

in "fremde" Namespaces (außerhalb 0_userdata) schreibt man nie bestätigte Werte

ähm, zuviel Infos in einem Satz!

• Es gab eine lange Zeit vor 0_userdata.0!! da konnte man überall reinschreiben
  • mache ich heute noch (Messwerte.0 und Systemvariablen.0)
  • natürlich nicht in Adapternamespaces!
• Es wurde nie verboten dort unbestätigt zu schreiben

Es geht aber hier darum, dass Adapter wie z.B. shuttercontrol auch auf States in 0_userdata.0 oder alias.0 zugreift und dort nur noch bestätigte Werte akzeptiert!
DAS ist relativ neu.

Ich kann mich noch an einen Thread erinnern, von dem ich fast nichts verstanden habe, in dem das ziemlich kontrovers diskutiert wurde.

[guitardoc]

@haus-automatisierung Ich bin bei Javascript auf Version 8.7.6 und da ist der Baustein nicht drin, oder übersehe ich den?

[haus-automatisierung]

@homoran sagte in Test Adapter shuttercontrol v1.7.x:

Es geht aber hier darum, dass Adapter wie z.B. shuttercontrol auch auf States in 0_userdata.0 oder alias.0 zugreift und dort nur noch bestätigte Werte akzeptiert!
DAS ist relativ neu.

Ja, habe ich editiert mit einem Beispiel zu statistics, welches 7+ Jahre alt ist.

Wäre ja auch total falsch (aus meiner Sicht), wenn man z.B. ein Relais als Status "offen" loggt (oder die Zeit zählt wie lange das Gerät in Betrieb ist), aber der Befehl nie verarbeitet wurde, weil der Wert nie beim Gerät angekommen ist (unbestätigt wurde).

Oder man zeigt auf einem Geräte wie der LaMetric Time oder der TC001 (mit Awtrix 3) einen Wert an, welcher gar nicht der Realität entspricht, weil z.B. die Hue-Bridge offline war und gar nix geschaltet hat = unbestätigt.

[haus-automatisierung]

@guitardoc sagte in Test Adapter shuttercontrol v1.7.x:

@haus-automatisierung Ich bin bei Javascript auf Version 8.7.6 und da ist der Baustein nicht drin, oder übersehe ich den?

Du übersiehst den. Trigger aufklappen und alles anschauen.

[Homoran]

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

welches 7+ Jahre alt ist.

dann hast du das aber damals eigenmächtig eingeführt, weil du der Meinung warst, dass

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

der Wert ja potenziell "falsch" ist.

du alter Editeur :grin:

Das ist nie (groß) kommuniziert worden

[haus-automatisierung]

@homoran sagte in Test Adapter shuttercontrol v1.7.x:

dann hast du das aber damals eigenmächtig eingeführt

Siehe git blame. Das war foxthefox. Gibt sicherlich noch weitere Beispiel (weil es ja dem Grundkonzept vom ioBroker gerecht wird).

[Homoran]

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

weil es ja dem Grundkonzept vom ioBroker gerecht wird

mag ja sein. Aber das versteht kein normaler User.

Solche massiven "Einschränkungen" müssen sehr deutlich kommuniziert werden.

[haus-automatisierung]

@homoran sagte in Test Adapter shuttercontrol v1.7.x:

Solche massiven "Einschränkungen" müssen sehr deutlich kommuniziert werden.

Steht bei allen diesen Adapter ja in der Doku

[guitardoc]

@haus-automatisierung said in Test Adapter shuttercontrol v1.7.x:

Du übersiehst den. Trigger aufklappen und alles anschauen.

Oh Mann, ich muss wirklich mal zum Augenarzt... Danke für das "MitderNasedraufstupsen" :-)

[haus-automatisierung]

@guitardoc Ich gebe mir wirklich alle Mühe, diese ganzen Themen und Features als Video festzuhalten und alles möglichst aktuell zu dokumentieren. Einfach mal reinschauen

[guitardoc]

@haus-automatisierung

Das mache ich. Danke für den Hinweis!

[guitardoc]

@homoran Noch mal bitte zur Klarstellung für mich:

• Schreiben in 0_userdata.0 mit Bestätigung (in Blockly: aktualisieren) -> das hab ich jetzt verstanden.
• Schreiben in alias.0 mit oder ohne Bestätigung (in Blockly: aktualisieren oder steuern)? Weil du geschrieben hattest:

@homoran said in Test Adapter shuttercontrol v1.7.x:

...auch auf States in 0_userdata.0 oder alias.0 zugreift und dort nur noch bestätigte Werte akzeptiert!

[Homoran]

@guitardoc

@simatec sagte in Test Adapter shuttercontrol v1.7.x:

Ack sollte immer gesetzt werden

@haus-automatisierung sagte in Test Adapter shuttercontrol v1.7.x:

Adapter) ignorieren z.B. alles, was nicht bestätigt ist. Weil der Wert ja potenziell "falsch" ist.

reicht das?

[guitardoc]

@homoran Ich frag ja nur. Zum einen hieß es, nur in 0_userdata.0 mit Bestätigung schreiben, zum anderen schreiben Adapter wie mqtt selbst auch ohne Bestätigung wenn man einen Alias drauf setzt.

[simatec]

@guitardoc Die Diskussion passt hier aber nicht wirklich mehr zum Thread. Bitte eröffnet da für einen separaten Thread

[guitardoc]

@simatec Ich denke, ich habe das Problem gefunden. Und eigentlich ist es ganz einfach. Schau dir mal diese Ausgabe genau an:

shuttercontrol.2
2024-09-02 21:26:06.624 debug TriggerID changed: 0_userdata.0.Fenster.Wohnzimmer.Tür_zur_Terrasse.Kombination_der_Kontaktsensoren | Value: true 
shuttercontrol.2
2024-09-02 21:26:06.622 debug TriggerID changed: 0_userdata.0.Fenster.Wohnzimmer.Tür_zur_Terrasse.Kombination_der_Kontaktsensoren | Value: false

Und ich vermute, dass es sowohl an SC als auch am Skript liegt.

Zuerst mein Skript - dieses sendet zweimal unmittelbar hintereinander, dass der Kontaktsensor geschlossen ist.

Jetzt SC - dieses schaut vermutlich nicht, welchen Wert der Sensor tatsächlich hat wenn dieser ausgelöst ist, sondern wechselt bei der Sensorauslösung als FlipFlop hin und her. Damit arbeitet SC beim ersten Ändern des Kontaktsensors mit geschlossen, beim zweiten dann mit offen (obwohl zweimal geschlossen gesendet wurde).
Das kann bei einem "richtigen" Sensor natürlich nicht passieren, da geht es nur hin und her. Aber wenn ein Skript dazwischen ist, dann stimmt das eben nicht, wenn das Skript nicht auch immer abwechselnd die Werte schickt.

Kannst du bestätigen, dass du den tatsächlichen Wert nicht ausliest, sondern nur darauf reagierst, dass der Kontaktsensor ausgelöst wurde? Dann baue ich das Skript so um, dass der Kontaktsensor nur einmal auf geschlossen gesetzt wird und dann müsste das passen. Das ist aber etwas mehr Aufwand, daher vorher erst mal die Frage ob ich es richtig erkannt hab.

[da_Woody]

@guitardoc raketenwissenschaft? wie oft muss dir @simatec noch erklären, daß wenn du mit scripts reinpfuscht, probleme bekommst!? du schreibst ja selbst:
Zuerst mein Skript - dieses sendet zweimal unmittelbar hintereinander, dass der Kontaktsensor geschlossen ist.
ergo ist dein script das problem, nicht SC.
sorry, hab mich bis jetzt rausgehalten, aber langsam wirds fad.
diese diskussion müllt einfach nur den tread zu...

[simatec]

@guitardoc Nein ... es ist dein Script der da dieses Wirrwarr verursacht... Shuttercontrol verarbeitet nur den State... Das was der State bei Änderung für einen Wert hat, ist für Shuttercontrol entscheidend... Wenn dein Script da doppelt sendet und einmal false und einmal true, dann solltest du den Script prüfen... Aber nochmal... Solange bei dir Scripts in die Arbeit von Shuttercontrol reinhauen, kann ich dir keinen Support geben, da ich nicht in die Glaskugel schauen kann, was deine Scripts da zu veranstalten