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

[Mic]

@EdgarM
Sorry, aber ich verstehe nicht ganz und da sind auch Lücken im Text.
Bitte noch mal besser beschreiben, gerne zur Unterstützung mit Logauszug sowie deinen Konfigeinstellungen und/oder Screenshots.

@EdgarM sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

Möchtest du eigentlich lieber ein Issue in github statt hier, nur hier oder beides?

Jetzt am Anfang (Alpha-Phase) gerne auch hier, sonst lieber Github.

Danke für dein Testen und Feedback.

[Mic]

@ Alle

Welches Info-Logging wünscht ihr euch denn?

Gibt ja in Adaptern die Log-Level "debug", "info", "warn", "error.
Zusätzlich habe ich in den Optionen noch:

Was soll...

1. ... im Info-Log angezeigt werden (z.B. jedes mal, wenn ein Bewegungsmelder auslöst, eine Meldung?, oder nur wenn geschalten wird, weil alle Bedingungen zutreffen, oder?)
2. ... raus aus Info-Log und nur angezeigt werden, wenn "Mehr Info-Log-Ausgaben" aktiviert ist?

Nur ein Beispiel:

info: smartcontrol.0 (8256) Trigger 'Motion Bathroom' activated, but it is not matching a current schedule, so no execution.

[EdgarM]

Hi Mic,

mein text war auch etwas wirr :), Bilder sagen mehr als Worte

Es ist nur 1 BWM, der zu unterschiedlichen Zeiten leicht verschiedene Ziele hat.

Leider sind die beiden Ausführungen abend und nachts nicht mehr möglich, da bei der Überprüfung des ersten Auslösers anscheinend bereits einen "ausgeführt" Wert setzt.

grüße

	2020-07-18 21:32:50.521	info	(4541) Trigger [BWM Esszimmer nacht] was already activated 0 seconds ago, so we ignore. Must be at least 3 seconds.
smartcontrol.0	2020-07-18 21:32:50.521	debug	(4541) No brightness defined for motion sensor 'BWM Esszimmer nacht', so continue and do not use bri as an additional criterion.
smartcontrol.0	2020-07-18 21:32:50.521	debug	(4541) [TriggerConfigParam (cP)] : {"triggerName":"BWM Esszimmer nacht","triggerStatePath":"deconz.0.Sensors.2.presence","triggerStateVal":true,"triggerIsMotion":true,"triggerIsToggle":false,"targetO
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) 1 rows in Execution table for trigger 'BWM Esszimmer nacht' successfully found.
smartcontrol.0	2020-07-18 21:32:50.520	info	(4541) Trigger [BWM Esszimmer abend] was already activated 0 seconds ago, so we ignore. Must be at least 3 seconds.
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) No brightness defined for motion sensor 'BWM Esszimmer abend', so continue and do not use bri as an additional criterion.
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) [TriggerConfigParam (cP)] : {"triggerName":"BWM Esszimmer abend","triggerStatePath":"deconz.0.Sensors.2.presence","triggerStateVal":true,"triggerIsMotion":true,"triggerIsToggle":false,"targetO
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) 1 rows in Execution table for trigger 'BWM Esszimmer abend' successfully found.
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) Trigger is not matching a schedule, so no further action at this point.
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) Execution table row for zone 'Esszimmer Tag' is NOT meeting conditions
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) Current time '21:33' is *not* within schedule times (start: '05:04', end: '20:39) of 'Esszimmer Tag'.
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) Trigger BWM Esszimmer Tag is associated with following Execution table row: {"active":true,"name":"Esszimmer Tag","start":"sunrise-30","end":"sunset-30","mon":true,"tue":true,"wed":true,"thu":
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) No brightness defined for motion sensor 'BWM Esszimmer Tag', so continue and do not use bri as an additional criterion.
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) [TriggerConfigParam (cP)] : {"triggerName":"BWM Esszimmer Tag","triggerStatePath":"deconz.0.Sensors.2.presence","triggerStateVal":true,"triggerIsMotion":true,"triggerIsToggle":false,"targetOff
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) 1 rows in Execution table for trigger 'BWM Esszimmer Tag' successfully found.
smartcontrol.0	2020-07-18 21:32:50.520	debug	(4541) State 'deconz.0.Sensors.2.presence' change --> execute asyncTriggerActivated()
smartcontrol.0	2020-07-18 21:32:50.518	debug	(4541) Subscribed state 'deconz.0.Sensors.2.presence' changed, new value: [true] (ack: true)

[CKMartens]

@Mic das Licht schaltet jetzt perfekt auch nach Mitternacht. Danke für das Update

[Ein ehemaliger Benutzer]

@Mic
Hi, ich würde für Version 2 deiner Logausgaben plädieren.. Info nur, wenn Adapter startet, endet, etc.. wenn mehr Infos fürs Testen gewünscht sind, dann "erweiterte Log-Ausgaben" aktivieren.

Bei mir sind wegen recht vielen Adaptern die meisten auf "warn" gestellt, nur welche, die ich im Auge behalten möchte, auf Info oder gar debug. Aber da ist schnell das Log sehr unübersichtlich..

[BoehserWolf]

@Mic Bzgl. der Log-Ausgaben ist es nach meiner Meinung doch relativ typisch, dass nur das Nötigste auf Info läuft. Dazu gehört bei dir vlt. sowas wie Neustart auf Grund von Konfigurationsänderungen, Anpassungen wichtiger Konfigurationsparameter, etc. Auf Debug laufen dann alle weiteren Meldungen.
Bei ioBroker fehlt mir hier noch Trace zum erweiterten Debuggen. Das könntest du bspw. mit der Option "Erweiterte Log-Ausgaben" auf Log-Level Debug abbilden. Dazu würde ich dann noch einen Hinweis geben, dass der Adapter selbst dazu auf Debug gestellt werden muss.
Ich bin der Meinung zu viel Log im Normalfall verwässert alles unnötig. Wer mehr Ausgaben benötigt, hat jedoch über den Level Debug die Möglichkeit an alle Infos zu kommen.

[Mic]

@frostnatt sagte in Planung neuer Adapter: Smart Control:

Der Aqara Sensor aktualisiert Lux-Wert nur wenn eine Bewegung erkannt wird. Mein Problem ist, dass das Script (in meinem Fall) nicht mit dem aktuellen Helligkeitswert arbeitet. Es wartet ja nicht, bis dieser aktualisiert wird, sondern prüft einfach nur. Wenn der Lux-Datenpunkt aber erst nach dieser Prüfung mit dem aktuellen Wert beschrieben wird (ist bei mir so, denn ich benutzte ein eigenes Script zum Beschreiben der Datenpunkte, die Werte werden aus einem Json Objekt geparst, welches ich über mqtt empfange. Dieses Objekt ist so aufgebaut, dass Lux-Wert als letztes Element vorkommt) Die Zeitverzögerung zwischen Beschreiben von Occupancy und Lux habe ich nicht gemessen, bin mir aber ziemlich sicher, dass das aquara-motion-control Script die Prüfung schneller ausführt...

Ich hoffe, ich habe mein Problem ausführlich beschrieben.

Ich könnte meinen Parser auch so abändern, dass der Lux-Datenpunkt vor dem Occupancy beschrieben wird, finde aber dass eine Timestamp Prüfung hier sinnvoll ist. Es wird bestimmt noch Leute mit ähnlichen Timing Problemen geben...

Ich hab mir das jetzt mal näher angesehen. Ich setze die Aqara-Sensoren sowohl im mihome- als auch im Zigbee-Adapter ein. In beiden Adaptern wird immer zuerst Helligkeit gesetzt, dann erst (paar ms später) die Bewegung. Meines Erachtens sollte das also auch der Adapter (oder Script was man verwendet) so regeln, und nicht der smartcontrol-Adapter.
Du schreibst ja auch selbst, dass du das in deinem Parser auch abändern kannst.
Ich stelle daher das jetzt erst mal zurück.
Sollten sich mehr User melden, also es tatsächlich hier ein Problem geben sollte, dann schaue ich mir das gerne noch mal an.

[Mic]

@Christoph1337 sagte in Planung neuer Adapter: Smart Control:

ich hätte noch eine feature Idee. Wenn man schon so einen Adapter hat, wäre es cool wenn dieser automatisch eine HTML Tabelle generiert wo alle Schalter mit Zuordnung enthalten sind. Das wäre gerade für den Start für viele einfacher da man sich nicht in vis großartig einarbeiten muss. Am besten sogar responsive für verschiedene Auflösungen

Bitte Github Issue aufmachen und dort genau beschreiben, am besten mit Beispiel-Tabelle.

[Mic]

@looxer01 sagte in Planung neuer Adapter: Smart Control:

Moeglichkeit der Umrechnung des neu abzuspeichernden Wertes aus der Aktion (Damit kann z.B. ein Zähler realisiert werden. Wenn der neue Wert <+> <-> </> <:> enthält dann wird der folgende Zielwert berechnet beispiel. Alter wert = 2 Neuer Wert = <+>1 ergibt 3 im Zielwert. - also ein Zähler

Noch mal danke für deine Ideen.

Aufgenommen: https://github.com/Mic-M/ioBroker.smartcontrol/issues/10

Möglichkeit der Simulation, damit für die Umstellung eine Zeitlang parallel gearbeitet werden kann bis zur endgültigen Umstellung. Meldungen müssen natürlich ausgegeben werden aber der eigentliche Update des Wertes bleibt aus. Das erleichtet das Einstellen und testen enorm

Der Adapter bietet Test-Datenpunkte, damit kann alles simuliert werden.

Message Ausgabe (konfigurierbar)

https://github.com/Mic-M/ioBroker.smartcontrol/issues/11

Log als CSV Datei. sieht dann z.B. so bei mir aus:

Datum;Uhrzeit;TriggerKey;ActionKey;Ziel-ID;Neuer Wert;Message

22.06.2020 ;07:00:00 ;RolladeKind2Auf;RolladeKind2Auf;hm-rpc.0.LEQ0276xxx.1.LEVEL;100;Rollade Kind2 hochgefahren

22.06.2020 ;07:00:00 ;RolladeKind1Auf;RolladeKind1Auf;hm-rpc.0.JEQ0112xxx.1.LEVEL;100;Rollade Kind1 hochgefahren

22.06.2020 ;07:00:00 ;RolladeKuecheAuf;RolladeKuecheAuf;hm-rpc.0.JEQ0111xxx.1.LEVEL;100;Rollade Kueche hochgefahren

Wozu braucht es denn eine csv-Datei? Wäre nicht als Log und dann als JSON sinnvoller? Der Logparser-Adapter macht dann eh den Rest im Bedarf (JSON-Umwandlung, etc.).

[Mic]

@EdgarM sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

Hi Mic,

mein text war auch etwas wirr :), Bilder sagen mehr als Worte

Es ist nur 1 BWM, der zu unterschiedlichen Zeiten leicht verschiedene Ziele hat.

Leider sind die beiden Ausführungen abend und nachts nicht mehr möglich, da bei der Überprüfung des ersten Auslösers anscheinend bereits einen "ausgeführt" Wert setzt.

So ist es viel besser
Ist behoben, kommt mit dem nächsten Update (heute oder morgen)

[Mic]

Hier geht es nun weiter:

Teste Adapter SmartControl 0.1.1-beta.x

---

Bitte hier nicht mehr posten, sondern nur noch in dem neuen Thread.