Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen

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

[liv-in-sky]

@Mic userdata.0 kam erst nach einigen jahren - hatte mir damals das angelegt

[liv-in-sky]

@Mic wollte mir den umzug von fast 700 eigenen datenpunkten ersparen

[Mic]

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

@Mic userdata.0 kam erst nach einigen jahren - hatte mir damals das angelegt

Verstehe ich gut
Ich nehme es mal auf die Liste, aber nicht mit hoher Prio (weil eben nicht der ioBroker Spezifikation entsprechend), erst sind noch andere Dinge dran

[Homoran]

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

eigene Datenpunkte dürfen nur unter 0_userdata.0 oder javascript.x sein...

Neee

Meine liegen auch unter Messwerte.0 oder Sytemvariablen.0

[liv-in-sky]

@Mic vielleicht könntest du die prio ein wenig höherschrauben es gibt vielleicht mehr von uns "assi-usern"

[Mic]

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

Meine liegen auch unter Messwerte.0 oder Sytemvariablen.0

Verstehe.

@liv-in-sky
Ach Quatsch, alles gut , du und @Homoran und wohl einige weitere haben die wohl halt einfach angelegt, auch weil es geht in den Objekten und aus Übersichtlichkeit.

Ich schau mal. Idealerweise prüfe ich, ob hinter dem Hauptdatenpunkt "Messwerte.0" etc. ein "echter" Adapter ist, wenn ja, dann "ack:true", wenn nicht, dann kann zieht er die Einstellung von

[liv-in-sky]

@Mic

klasse idee

[Homoran]

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

weil es geht in den Objekten

zumindest ging es früher - jetzt nicht mehr (so einfach).

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

und aus Übersichtlichkeit.

Ganz genau!

Natürlich muss man aufpassen, dass später nicht ein Adapter diesen Namespace belegt. Dann muss es Tatsächlich unter 0_userdata.0 - würde aber alles noch eine Ebene tiefer verschachteln.