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

[CKMartens]

@Mic
Ich habe heute mal versucht mein Flurlicht nicht per Script sondern per Smartcontrol zu schalten. Ziel ist es das das Flurlicht nur nachts bei Bewegung geschaltet wird.
Dazu habe ich natürlich das Zielgerät, den Auslöser, die Zone und die Ausführung definiert. Bei der Ausführung habe ich für Start "sunset-30" und Ende "sunrise+30" eingetragen.

Gestern Abend hat die Lampe auch brav geschaltet. Allerdings weigert sich Smartcontrol die Lampe nach Mitternacht zu schalten:

smartcontrol.0	2020-07-16 03:32:07.903	debug	(26560) Trigger is not matching a schedule, so no further action at this point.
smartcontrol.0	2020-07-16 03:32:07.903	debug	(26560) Execution table row for zone 'Flur' is NOT meeting conditions
smartcontrol.0	2020-07-16 03:32:07.903	debug	(26560) Current time is *not* within schedule times (start: 'sunset-30', end: 'sunrise+30) of 'Flur'.
smartcontrol.0	2020-07-16 03:32:07.903	debug	(26560) Start time > End time, but option 'Exceed Midnight' activated, so we add 24h to the end time. New end time: 'sunrise+30'='2020-7-17 5:55:00 AM'
smartcontrol.0	2020-07-16 03:32:07.902	debug	(26560) Start: 'sunset-30'='2020-7-16 8:51:00 PM', end: 'sunrise+30'='2020-7-16 5:55:00 AM'. To check if in between: '2020-7-16 3:32:07 AM'
smartcontrol.0	2020-07-16 03:32:07.900	debug	(26560) Trigger Bewegung Flur is associated with following Execution table row: {"active":true,"name":"Flur","start":"sunset-30","end":"sunrise+30","mon":true,"tue":true,"wed":true,"thu":true,"fri":tr
smartcontrol.0	2020-07-16 03:32:07.899	debug	(26560) [asyncSwitchTargetDevices] Config Parameters cP = {"triggerType":"statePath","triggerStatePath":"hm-rpc.1.0014DA49924E5C.3.MOTION","targetOff":false,"triggerStateValSet":true,"scheduleRows":[{
smartcontrol.0	2020-07-16 03:32:07.899	debug	(26560) Trigger [Bewegung Flur] Brightness of 0 is < threshold of 5, so we continue.
smartcontrol.0	2020-07-16 03:32:07.853	debug	(26560) [cP] : {"triggerType":"statePath","triggerStatePath":"hm-rpc.1.0014DA49924E5C.3.MOTION","targetOff":false,"triggerStateValSet":true,"scheduleRows":[{"active":true,"name":"Flur","start":"sunset
smartcontrol.0	2020-07-16 03:32:07.852	debug	(26560) Execution rows for 'Bewegung Flur' successfully found.
smartcontrol.0	2020-07-16 03:32:07.851	debug	(26560) State 'hm-rpc.1.0014DA49924E5C.3.MOTION' change --> execute asyncTriggerActivated()
smartcontrol.0	2020-07-16 03:32:07.844	debug	(26560) Subscribed state 'hm-rpc.1.0014DA49924E5C.3.MOTION' changed, new value: [true] (ack: true)

Das Probvlem ist das er für sunset den heutigen Tag (16.07.) nimmt. Und der ist logischerweise noch nicht erreicht, da ja eigentlich die Nacht von 15. auf 16. ist und da sunset für den 15.07. genommen werden müsste. Hab ich mich jetzt eigentlich verständlich ausgedrückt?

[Michael Sauer]

@Mic
Habe noch mal ein bisschen mit den Zeiten gespielt.
Dabei ist mir aufgefallen das deine Funktion "Über Mitternacht hinaus" nicht greift.

Nachdem ich die zeiten innerhalb eines Tages definiert habe schaltet er so wie es soll. Sobald ich eine Zeit zwischen 22-6 Uhr definiere schaltet er diesen den ganzen Tag.

Ich denke das sollte das Problem klären.

Danke.

[OstfrieseUnterwegs]

Low-Prio:arrow_down:

Warnung/Fehlermeldung nicht ganz konsistent.

Wenn der Adapter auf Info steht, dass meldet er

Adapter admin configuration successfully validated...

Kurz darauf:

2 error(s) occurred while processing state generation of options.

Tatsächlich (im Debug Mode wird es gemeldet) liegt es daran, dass ich zum Test einen Trigger und eine Zone jeweils Namen mit nur zwei Zeichen gegeben habe. Das sollte entweder im Help stehen, oder besser noch beim Abspeichern abgefangen werden.

[Mic]

Bug in "Über Mitternacht hinaus" und Schaltzeiten

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

Allerdings weigert sich Smartcontrol die Lampe nach Mitternacht zu schalten:

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

Dabei ist mir aufgefallen das deine Funktion "Über Mitternacht hinaus" nicht greift.

Danke für eure Rückmeldungen.
War ein Bug. Sollte behoben sein mit 0.1.0-alpha.11 - ich hatte da kompliziert mittels Zeitstempel verglichen, aber jetzt einfacher umgesetzt im Code und damit gelöst.
Mit 0.1.0-alpha.11 habe ich auch die Option "Über Mitternacht hinaus" entfernt und sie greift jetzt immer, auch weil es wohl keine Konstellation gibt, in der man das nicht bräuchte... ;-)

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

@Mic kam falsch rüber, die Lampe wird/ kann mit dem Broadlink geschaltet werden.
Jedoch wurde sie nicht geschaltet, siehe Log...not turned on....

Ok, danke, ist aufgenommen

• (Yetiberg) & (crunship) - 2020-07-15 - Zielgerät schalten per Button ohne Überprüfung ob bereits an/aus. Siehe Forum

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

Kleine Sache im Log, nur wenn man die Ziel-aus benutzt:

 ... not turned off (as already off): ...

Im diesem Fall wäre das Log nicht richtig, es werden doch die angegebenen Zielgeräte off wenn die on sind.

Danke, ist aufgenommen:

• (OstfrieseUnterwegs) - 2020-16-07 - Warnung/Fehlermeldung nicht ganz konsistent. Siehe Forum

[EdgarM]

Hi,

ich habe das Gefühl , dass smartcontrol falsch zählt.

Ich habe für mein Esszimmer 3 verschiedene schedules: Tag, Abend, Nacht.

Seit Version scheint aber getrackt zu werden, ob ein schedult innerhalb der letzten 3 Sekunden bereits ausgelöst wurde.

soweit so gut :)

Aber offenbar wird das Tracking auf dem BWM zu sein, statt auf den schedules, er testet den "Tag" und merkt sich ein Aufruf.
Wenn es aber nicht Tag ist, dann geht er weiter und testet Abend. Dort merkt er aber das der Timer noch nicht abgelaufen ist und sagt das geht erst in 3 Sekunden wieder.

ich hoffe, ich habe es verständlich ausgedrückt.

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

grüße
E

[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

[A Former User]

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