NEWS
Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen
-
@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 -
@Mic
Werde ich testen. Danke. Die Entwicklung läuft ja rasant. -
@MartyBr
Das hier sollten wir uns noch ansehen:
Hast du Latitude/Longitude in deinen Admin-Einstellungen drin?
Sonst noch was auffälliges im Log?
-
@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 -
@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.
-
@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.
-
@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...
-
@Mic
Das klingt gut, dann kann man den Fehler umgehen. Ich möchte ungern umziehen, fühle mich hier sehr wohl -
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...
-
@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 -
@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:
-
@Mic hatte ich auch umgestellt - selbe meldung
-
@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. -
@Mic meine datenpunkte liegen unter controll-own.0 - ist ein eigener ordner - könnte man da noch einbauen, dass man selber welche definieren kann
-
@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...
-
@Mic userdata.0 kam erst nach einigen jahren - hatte mir damals das angelegt
-
@Mic wollte mir den umzug von fast 700 eigenen datenpunkten ersparen
-
@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 -
@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
-
@Mic vielleicht könntest du die prio ein wenig höherschrauben es gibt vielleicht mehr von uns "assi-usern"