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

[MartyBr]

@Mic Ich bekomme immer Fehler:

bei

[liv-in-sky]

@MartyBr

den fehler habe ich auch

[MartyBr]

@liv-in-sky
Auf den Adapter habe ich auch lange gewartet. Aktuell laufen meine Bewegungsmelder über Script in der Homematic. Ich hatte vor einiger Zeit das Script von @Mic im Einsatz. Hier fehlte aber die Funktion, vor dem Einschalten der Lampen durch den Bewegungsmelder zu prüfen, ob die Lampe schon brennt. Dadurch wurden die Lampen dann ausgeschaltet. War schon blöd....

[liv-in-sky]

@MartyBr

werde meine scripte mit den bewegungsmeldern wahrscheinlich auch nicht in diesem adapter nutzen können - ich habe einen mode, indem ich - wenn allein - die scripte bzw iobroker - immer weiß, wo ich bin und einiges mehr, wie ein licht eingeschaltet wird - aber mal sehen, ob ich da was umstellen kann - ist bei mir daheim wie mit google - iobroker weiß immer wo ich bin

finde aber so eine schaltzentrale eine gute idee - meine javascript sammlung ist zu groß und unübersichtlich geworden - vielleicht kann ich mit dem adapter etwas aufräumen

ich glaube, ich muss langsam mit den aliasen richtig anfangen, sonst muss man darin auch noch ändern, wenn geräte getauscht werden

[MartyBr]

@liv-in-sky Das geht mir genauso. Ich emigriere auch so langsam meine Script von der Homematic zum ioBroker. Der größte Brocken waren die Rollläden inkl. Beschattung. Die laufen jetzt in Shuttercontrol. Bisher erfüllt der Adapter ca. 90% der Funktionen meiner Script. Der riesige Vorteil der Adapter ist die "zentrale" Steuerung der Einstellungen. Ich hatte ca. 40 Scripte für die Rollos laufen inkl. Beschattungssteuerung mit Temp./Differenztemp, Auswertung der Innen- wie auch Außentemperatur, etc.....
Das war doch schon immer ein Problem bei jedem Change Prozess. Das macht der Adapter schon einfacher.
Jetzt muss ich überlegen, wo läuft denn mein Script? Auf der Homematic oder schon auf dem ioBroker. Ich werde dann umsteigen, wenn mehr als 80% der Funktionen erfüllt sind.

[Mic]

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

@Mic Ich bekomme immer Fehler:

Ich habe nun die Anforderung rausgenommen, dass Datenpunkte nur einmal pro Tabelle vorkommen dürfen.
Gelöst in 0.1.0-alpha.6

[MartyBr]

@Mic
Werde ich testen. Danke. Die Entwicklung läuft ja rasant.

[Mic]

@MartyBr
Das hier sollten wir uns noch ansehen:

Hast du Latitude/Longitude in deinen Admin-Einstellungen drin?
Sonst noch was auffälliges im Log?

[MartyBr]

@Mic
Die Meldungen kommen im Sommer bei <night> und <nightend>. Die Zeiten liegen hier in Deutschland wohl außerhalb des Scopes. Ich habe das seit Anfang an in jedem Script, wo Astro Zeiten berechnet werden. Dazu gibt es einige Foreneinträge.

Habe jetzt die neue Version installiert. Im Test System einige Errors:

War dann mutig und habe es auf dem Produktiv System installiert. Hier lief es einwandfrei durch bis auf den Zeitfehler.

Konnte aber beide Systeme noch nicht testen.

Update 18:40
Habe die beiden "Anderen Auslöser" aktiv geschaltet, läuft wieder.
Danke

[Mic]

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

Update 18:40
Habe die beiden "Anderen Auslöser" aktiv geschaltet, läuft wieder.

Danke fürs Testen. Was meinst du mit "läuft wieder"? D.h. auch Astro für night/nightEnd geht?

Denn das sollte dennoch gehen, auch wenn night/nightEnd nach Mitternacht sind.

[MartyBr]

@Mic
Sorry, der Text war nicht deutlich. ich hatte die beiden "Anderen Auslöser" deaktiviert und den Adapter laufen lassen. Nun habe ich nach dem Update die beiden Trigger wieder aktiv geschaltet und es kamen keine Fehlermeldungen.

Hast du einen Tipp für mich für die Meldungen für night/nightend? Die Geo-Koordinaten sind eingetragen.

[Mic]

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

Hast du einen Tipp für mich für die Meldungen für night/nightend? Die Geo-Koordinaten sind eingetragen.

Habe mich grad zum Testen weit in den Norden versetzt:

Da erkennt er dann auch keine Zeiten:

Was ich machen kann: Option anbieten, die bei night/nightEnd Fehler einfach eine vorzugebende Uhrzeit setzt, damit zumindest die Funktionalität soweit gegeben ist. Könnte man auch einfach in Abhängigkeit vom Sonnenaufgang grob kalkulieren lassen für den Sommer, also sunrise - x Minuten...

[MartyBr]

@Mic
Das klingt gut, dann kann man den Fehler umgehen. Ich möchte ungern umziehen, fühle mich hier sehr wohl

[liv-in-sky]

@Mic

was bedeutet das :

smartcontrol.0	2020-07-11 19:10:16.420	debug	(24857) Subscribed state 'controll-own.0.mount.CPUTemp' change: ack 'false' is not meeting conditions per isAckPassing()
smartcontrol.0	2020-07-11 19:10:16.420	debug	(24857) Subscribed state 'controll-own.0.mount.CPUTemp' changed, new value: [38] (ack: false)
smartcontrol.0	2020-07-11 19:10:01.402	debug	(24857) Subscribed state 'controll-own.0.mount.CPUTemp' change: ack 'false' is not meeting conditions per isAckPassing()
smartcontrol.0	2020-07-11 19:10:01.402	debug	(24857) Subscribed state 'controll-own.0.mount.CPUTemp' changed, new value: [47] (ack: false)
smartcontrol.0	2020-07-11 19:09:46.386	debug	(24857) Subscribed state 'controll-own.0.mount.CPUTemp' change: ack 'false' is not meeting conditions per isAckPassing()
smartcontrol.0	2020-07-11 19:09:46.386	debug	(24857) Subscribed state 'controll-own.0.mount.CPUTemp' changed, new value: [39] (ack: false)
smartcontrol.0	2020-07-11 19:09:41.354	info	(24857) 0 trigger schedules activated...

[Mic]

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

Ich möchte ungern umziehen, fühle mich hier sehr wohl

Schade, dann könnte ich mir das ersparen

Ich schau mal. Du könntest parallel hier mal schauen http://suncalc.net/ welche Formel bzw. Anzahl Minuten sinnvoll wäre. Also Basis z.B. Sonnenaufgang (sunrise).
Dann für
night = sunrise - x Minuten
nightEnd = sunrise - y Minuten

[Mic]

@liv-in-sky
Wegen "ack":

Siehe hier: https://forum.iobroker.net/topic/34019/frage-zu-subscribeforeignstates-ack/9

Insbesondere Kommentar von AlCalzone:
@AlCalzone sagte in Frage zu subscribeForeignStates() -> ack:

Bei anderen Adaptern solltest du davon ausgehen, dass die States erst "gültig" bzw. bestätigt sind, wenn ack: true.

States mit ack: false zu setzen, ist eine Aufforderung an den dazugehörigen Adapter (oder Skript), diese Änderung zu verarbeiten.

Daher werden Datenpunkt-Änderungen bei anderen Adaptern ignoriert, falls nicht bestätigt (ack: false).

Als Ausnahme habe ich für Datenpunktänderungen für 0_userdata.0 und javascript.x folgende Optionen eingebaut:

[liv-in-sky]

@Mic hatte ich auch umgestellt - selbe meldung

[Mic]

@liv-in-sky
Klar, die Einstellung betrifft auch nur:

Du hast da aber einen Adapter. Bestätigt dieser Adapter "control-own" denn nicht sauber den Datenpunkt mit ack:true? Denn das wäre gemäß https://forum.iobroker.net/post/448606 dann ein Fehler/Optimierungsbedarf dieses "control-own" Adapters.

[liv-in-sky]

@Mic meine datenpunkte liegen unter controll-own.0 - ist ein eigener ordner - könnte man da noch einbauen, dass man selber welche definieren kann

[Mic]

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

meine datenpunkte liegen unter controll-own.0

Hmm, das entspricht aber nicht den ioBroker-Regeln, also eigene Datenpunkte dürfen nur unter 0_userdata.0 oder javascript.x sein...