Test Adapter SmartControl 0.3.x-0.6.x Latest
-
@dslraser sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
(dann wird ja auch neu gestartet, oder ?)
Ja genau.
Strange...
Was setzt du denn ein, also- Version node.js
- Version js-controller
- Linux oder Windows
-
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Version node.js
12.irgendwas
Version js-controller
latest (ich glaube 3.16 ich bin gerade unterwegs und nur am Handy)
Linux oder Windows
Docker (buanet image auf Synology, dann wohl Linux)
also eigentlich alles aktuell (latest)
-
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
initial alle Datenpunkte beim (Neu)Start der Adapter-Instanz
erstmal vielen Dank für die Rückmeldung
Wenn du so direkt fragst
ja erwartet hätte ich, das im log eine Warnmeldung erscheint, da es bei grösseren Installationen dann schon recht umfangreich sein kann und man eben in diesem Moment nicht unbedingt an alles denkt, wie/wo/was eingebunden ist.
Änder ich ein Device, wie in dem Fall, denke ich zwar an eventuell damit verbundene Scripte, die ich anpassen muss aber nicht an den Adapter, wobei javascript dann eh eine Warnmeldung ins log schreiben würde, wenn ein script nicht mehr passt, zwecks fehlendem DP
Natürlich könnte man nun hergehen und das ganze mittels Alias ausmerzen, bleibt aber trotzdem das Problem, wenn dann mal ein Alias gelöscht oder umbenannt wird.@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Dass hier trotz "abbrechen" wohl dennoch gespeichert wurde, ist ärgerlich, kann ich aber so leider nicht reproduzieren...
war zum Glück nichts lebensbedrohliches
vielleicht hing es auch mit der Verbindung/Empfang am Handy zusammen -
-
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Dieser Fehler ist interessant, ich kann es leider im Moment nicht reproduzieren.
Hab allerdings jetzt in der Adapter onUnload() Funktion noch eine Abfrage einer Schedule-Variable auf undefined eingebaut, da diese ggf. undefined ist, um Fehler zu vermeiden.
Muss ich mal weiter beobachten.
Kommt das bei dir bei jedem Neustart mit dem "Pfeilkreis"? Kommt das auch beim Stoppen?Ich bin jetzt wieder kurz am Rechner. Ich will meine Variante 1 nochmal probieren.
Ich habe mehrere Änderungen im Adapter gemacht und zwischendurch gespeichert. Dann kommt das im Log.host.iobroker 2020-09-13 14:00:10.877 info Do not restart adapter system.adapter.smartcontrol.0 because desired by instance host.iobroker 2020-09-13 14:00:10.877 error instance system.adapter.smartcontrol.0 terminated by request of the instance itself and will not be restarted, before user restarts it. smartcontrol.0 2020-09-13 14:00:10.343 warn (6509) Got terminate signal. Checking desired PID: 6539 vs own PID 6509 smartcontrol.0 2020-09-13 14:00:10.334 warn (6509) Got terminate signal. Checking desired PID: 0 vs own PID 6509 host.iobroker 2020-09-13 14:00:10.330 info instance system.adapter.smartcontrol.0 started with pid 6539 daswetter.0 2020-09-13 14:00:01.451 info (6524) starting. Version 3.0.1 in /opt/iobroker/node_modules/iobroker.daswetter, node: v12.18.3, js-controller: 3.1.6 host.iobroker 2020-09-13 14:00:00.043 info instance system.adapter.daswetter.0 started with pid 6524 host.iobroker 2020-09-13 13:58:49.965 info Do not restart adapter system.adapter.smartcontrol.0 because desired by instance host.iobroker 2020-09-13 13:58:49.964 error instance system.adapter.smartcontrol.0 terminated by request of the instance itself and will not be restarted, before user restarts it. smartcontrol.0 2020-09-13 13:58:49.427 warn (6494) Got terminate signal. Checking desired PID: 6509 vs own PID 6494 smartcontrol.0 2020-09-13 13:58:49.419 warn (6494) Got terminate signal. Checking desired PID: 0 vs own PID 6494 host.iobroker 2020-09-13 13:58:49.411 info instance system.adapter.smartcontrol.0 started with pid 6509 host.iobroker 2020-09-13 13:57:47.229 info Do not restart adapter system.adapter.smartcontrol.0 because desired by instance host.iobroker 2020-09-13 13:57:47.228 error instance system.adapter.smartcontrol.0 terminated by request of the instance itself and will not be restarted, before user restarts it. smartcontrol.0 2020-09-13 13:57:46.704 warn (6479) Got terminate signal. Checking desired PID: 6494 vs own PID 6479 smartcontrol.0 2020-09-13 13:57:46.694 warn (6479) Got terminate signal. Checking desired PID: 0 vs own PID 6479 host.iobroker 2020-09-13 13:57:46.691 info instance system.adapter.smartcontrol.0 started with pid 6494 host.iobroker 2020-09-13 13:57:38.441 info Do not restart adapter system.adapter.smartcontrol.0 because desired by instance host.iobroker 2020-09-13 13:57:38.440 error instance system.adapter.smartcontrol.0 terminated by request of the instance itself and will not be restarted, before user restarts it. smartcontrol.0 2020-09-13 13:57:37.900 warn (6299) Got terminate signal. Checking desired PID: 6479 vs own PID 6299 smartcontrol.0 2020-09-13 13:57:37.892 warn (6299) Got terminate signal. Checking desired PID: 0 vs own PID 6299 -
@Mic was mir noch aufgefallen ist bzw fragen wollte
da ich in der Vergangenheit, mir schon bestimmte Sachen anlegen wollte ( was technisch aber noch nicht vorhanden ist)
schmeisst mir der Adapter aber dann error wegen falsch konfiguriert, obwohl der Haken deaktiviert ist,
also greift scheinbar dieses nicht, bzw dann wohl nur, wenn alle Pflichtfelder ausgefüllt sind
-
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Also eigentlich nicht mehr, jetzt ab Adapter-Version 0.3.x ist es so:
Sobald jetzt eine Bewegung auslöst (Datenpunkt des BWM auf true), werden ggf. laufende Timer gelöscht und dann die Zielgeräte entsprechend eingeschaltet.
Sobald keine Bewegung mehr (Datenpunkt des BWM geht auf false), bleibt erst mal alles an. Dann wird der Timer gestartet (z.B. 5 Sekunden), und nach diesen 5 Sekunden wird dann ausgeschaltet (es sei denn es gab zwischendurch eine neue Bewegung)Funktioniert doch genau so wie Du es schreibst. Dann hatte ich wohl doch noch irgendwas falsch eingestellt. Getestet mit einer Sekunde Verzögerung.
-
@dslraser sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Version node.js
12.irgendwas
Version js-controller
latest (ich glaube 3.16 ich bin gerade unterwegs und nur am Handy)
Linux oder Windows
Docker (buanet image auf Synology, dann wohl Linux)
also eigentlich alles aktuell (latest)
ok, also ähnlich wie meine Produktivumgebung, ich hab mal in discord gefragt. muss das mal weiter beobachten.
@crunchip sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
@dslraser @Mic diese erwähnte error Meldung hatte ich auch schon das ein oder andere mal
Linux alles im latest und aktuell
nodejs v 12.18.3
js-controller 3.1.6
proxmox vmDanke, also wie bei mir... Hmm...
-
@crunchip sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Wenn du so direkt fragst
ja erwartet hätte ich, das im log eine Warnmeldung erscheint, da es bei grösseren Installationen dann schon recht umfangreich sein kann und man eben in diesem Moment nicht unbedingt an alles denkt, wie/wo/was eingebunden ist.
Änder ich ein Device, wie in dem Fall, denke ich zwar an eventuell damit verbundene Scripte, die ich anpassen muss aber nicht an den Adapter, wobei javascript dann eh eine Warnmeldung ins log schreiben würde, wenn ein script nicht mehr passt, zwecks fehlendem DPAber der Adapter macht eigentlich genau das, es kommt im Log ein Error, wenn z.B. ein Zielgerät angelegt ist, dann der Datenpunkt gelöscht wird, und was danach das Zielgerät auslöst. Grad getestet
smartcontrol.0 2020-09-13 17:53:18.124 error (2972) [asyncSetTargetDevices] – Could not get current state value for '0_userdata.0._TestSC.light.RelaxAreaWall' of device 'test' smartcontrol.0 2020-09-13 17:53:18.123 error (2972) [asyncGetForeignState] – State '0_userdata.0._TestSC.light.RelaxAreaWall' does not exist. -
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
ich hab mal in discord gefragt.
habe ich gesehen.
-
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Danke, also wie bei mir... Hmm...
Ich habe mal verschiedene Adapter über den Pfeilkreis neu gestartet und zum Schluß Deinen. Die Meldungen sehen alle etwas anders aus, aber doch ähnlich. Die Adapter stehen bei mir alle auf
warnDas hier machen alle
(ADAPTER_REQUESTED_TERMINATION)(ausser smartcontrol)host.iobroker 2020-09-13 18:06:27.701 info Do not restart adapter system.adapter.smartcontrol.0 because desired by instance host.iobroker 2020-09-13 18:06:27.701 error instance system.adapter.smartcontrol.0 terminated by request of the instance itself and will not be restarted, before user restarts it. smartcontrol.0 2020-09-13 18:06:27.178 warn (6761) Got terminate signal. Checking desired PID: 7136 vs own PID 6761 smartcontrol.0 2020-09-13 18:06:27.169 warn (6761) Got terminate signal. Checking desired PID: 0 vs own PID 6761 host.iobroker 2020-09-13 18:06:27.167 info instance system.adapter.smartcontrol.0 started with pid 7136 host.iobroker 2020-09-13 18:06:17.839 info instance system.adapter.harmony.0 started with pid 7120 host.iobroker 2020-09-13 18:06:15.259 info instance system.adapter.harmony.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) host.iobroker 2020-09-13 18:06:14.726 info stopInstance system.adapter.harmony.0 send kill signal host.iobroker 2020-09-13 18:06:14.720 info stopInstance system.adapter.harmony.0 (force=false, process=true) host.iobroker 2020-09-13 18:05:44.264 info instance system.adapter.smartgarden.0 started with pid 7104 host.iobroker 2020-09-13 18:05:41.710 info instance system.adapter.smartgarden.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) host.iobroker 2020-09-13 18:05:41.174 info stopInstance system.adapter.smartgarden.0 send kill signal host.iobroker 2020-09-13 18:05:41.172 info stopInstance system.adapter.smartgarden.0 (force=false, process=true) host.iobroker 2020-09-13 18:05:21.550 info instance system.adapter.hue.0 started with pid 7089 host.iobroker 2020-09-13 18:05:19.034 info instance system.adapter.hue.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) host.iobroker 2020-09-13 18:05:18.490 info stopInstance system.adapter.hue.0 send kill signal host.iobroker 2020-09-13 18:05:18.488 info stopInstance system.adapter.hue.0 (force=false, process=true) host.iobroker 2020-09-13 18:04:57.703 info instance system.adapter.iqontrol.0 started with pid 7074 host.iobroker 2020-09-13 18:04:55.175 info instance system.adapter.iqontrol.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) host.iobroker 2020-09-13 18:04:54.635 info stopInstance system.adapter.iqontrol.0 send kill signal -
@crunchip sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
@Mic was mir noch aufgefallen ist bzw fragen wollte
da ich in der Vergangenheit, mir schon bestimmte Sachen anlegen wollte ( was technisch aber noch nicht vorhanden ist)
schmeisst mir der Adapter aber dann error wegen falsch konfiguriert, obwohl der Haken deaktiviert ist,
also greift scheinbar dieses nicht, bzw dann wohl nur, wenn alle Pflichtfelder ausgefüllt sind
Derzeit wird tatsächlich auch geprüft, wenn Zeile nicht aktiviert wird, Grund war die Datenpunkte unter
smartcontrol.0.options- denn hier können einzelne Zeilen z.B. über VIS dann aktiviert werden.
Ich muss da die Beschreibung anpassen.
Alternativ könnte ich auch eine Option einbauen, dass grundsätzlich deaktivierte Zeilen nicht geprüft werden? -
@dslraser sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
Das hier machen alle (ADAPTER_REQUESTED_TERMINATION) (ausser smartcontrol)
Echt seltsam, so sieht es bei mir aus:
smartcontrol.1 2020-09-13 18:20:46.479 info (23536) Subscribing to all target devices and trigger states. 5 trigger schedules activated... smartcontrol.1 2020-09-13 18:20:45.502 info (23536) Adapter admin configuration successfully validated... smartcontrol.1 2020-09-13 18:20:45.043 info (23536) starting. Version 0.3.1 in /opt/iobroker/node_modules/iobroker.smartcontrol, node: v12.16.1, js-controller: 3.1.6 host.ctioBroker 2020-09-13 18:20:43.976 info instance system.adapter.smartcontrol.1 started with pid 23536 host.ctioBroker 2020-09-13 18:20:41.484 info instance system.adapter.smartcontrol.1 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) smartcontrol.1 2020-09-13 18:20:40.680 info (23521) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason smartcontrol.1 2020-09-13 18:20:40.679 info (23521) terminating smartcontrol.1 2020-09-13 18:20:40.678 info (23521) Stopping adapter instance successfully proceeded... smartcontrol.1 2020-09-13 18:20:40.677 info (23521) (6) schedules cleared... smartcontrol.1 2020-09-13 18:20:40.675 info (23521) (0) timers were active and have been cleared... smartcontrol.1 2020-09-13 18:20:40.670 info (23521) Got terminate signal TERMINATE_YOURSELF host.ctioBroker 2020-09-13 18:20:40.666 info stopInstance system.adapter.smartcontrol.1 send kill signal host.ctioBroker 2020-09-13 18:20:40.659 info stopInstance system.adapter.smartcontrol.1 (force=false, process=true)Plattform: linux (Proxmox Debian CT)
Node.js: v12.16.1
js-controller 3.1.6 -
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
dann der Datenpunkt gelöscht wird, und was danach das Zielgerät auslöst.
ok, ich hatte ja keinen DP gelöscht, sondern nur Umbenannt
-
ausgelöst wurde in meinem Fall nicht, daher, Fallbeispiel (ich bastel vormittags an irgendwelchen DP's, welche aber erst zur abendlichen Stunde oder gar erst bei erreichen eines bestimmten Wertes(Temperatur), ausgelöst werden)
den "Fehler" bekomme ich dann aber erst mit, wenn -
A) ich in die Instanz gehe/neu starte( habe ich in den Fall aber nicht, weil ich gar nicht auf die Idee kam) da ich den DP nicht gelöscht, sondern nur umbenannt habe
-
B) das Auslösen eintritt
-
-
Update auf 0.3.2
- (Mic-M) New feature: In the adapter configuration, tab 'Further Options' > 'Input Validation', you can now select if deactivated configuration table rows should be validated as well.
- (Mic-M) Fix adapter-check.iobroker.in error [E144] "common.installedFrom field found in io-package.json. Must be removed."
- (Mic-M) Fix for adapter unload: check schedule variable for undefined.
- (Mic-M) Fixed debug log line
-
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
@crunchip sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
@Mic was mir noch aufgefallen ist bzw fragen wollte
da ich in der Vergangenheit, mir schon bestimmte Sachen anlegen wollte ( was technisch aber noch nicht vorhanden ist)
schmeisst mir der Adapter aber dann error wegen falsch konfiguriert, obwohl der Haken deaktiviert ist,
also greift scheinbar dieses nicht, bzw dann wohl nur, wenn alle Pflichtfelder ausgefüllt sind
Derzeit wird tatsächlich auch geprüft, wenn Zeile nicht aktiviert wird, Grund war die Datenpunkte unter
smartcontrol.0.options- denn hier können einzelne Zeilen z.B. über VIS dann aktiviert werden.
Ich muss da die Beschreibung anpassen.
Alternativ könnte ich auch eine Option einbauen, dass grundsätzlich deaktivierte Zeilen nicht geprüft werden?Mit 0.3.2 nun neue Option (per Default deaktiviert):
-
@crunchip sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
@Mic sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
dann der Datenpunkt gelöscht wird, und was danach das Zielgerät auslöst.
ok, ich hatte ja keinen DP gelöscht, sondern nur Umbenannt
-
ausgelöst wurde in meinem Fall nicht, daher, Fallbeispiel (ich bastel vormittags an irgendwelchen DP's, welche aber erst zur abendlichen Stunde oder gar erst bei erreichen eines bestimmten Wertes(Temperatur), ausgelöst werden)
den "Fehler" bekomme ich dann aber erst mit, wenn -
A) ich in die Instanz gehe/neu starte( habe ich in den Fall aber nicht, weil ich gar nicht auf die Idee kam) da ich den DP nicht gelöscht, sondern nur umbenannt habe
-
B) das Auslösen eintritt
Ob umbenannt oder gelöscht ist hier egal, denn der Quellcode findet so einfach den Datenpunkt nicht mehr. Das wird dir auch im JS-Adapter so passieren usw.
Ich müsste ja ansonsten eine z.B. minütliche Prüfung einbauen, ob alle Datenpunkte noch existieren, aber das ist aus Performance-Sicht nicht zielführend.
Oder was hättest du für einen Vorschlag zur Umsetzung? -
-
@Mic ist mir gleich, wie es der Masse besser passt, hätte das anfangs nur ganz praktisch gefunden, wenn man der Reihe nach seine ganzen DP's schon mal anlegen kann und dann nach und nach aktivieren. Gerade weil es auch mit dem Benennen/Einteilen der Datenpunkte (zur besseren Übersicht) anfangs blöd war
-
@crunchip sagte in Test Adapter SmartControl 0.3.x GitHub (ab 12.09.20):
@Mic ist mir gleich, wie es der Masse besser passt, hätte das anfangs nur ganz praktisch gefunden, wenn man der Reihe nach seine ganzen DP's schon mal anlegen kann und dann nach und nach aktivieren. Gerade weil es auch mit dem Benennen/Einteilen der Datenpunkte (zur besseren Übersicht) anfangs blöd war
Hast Recht, aber ist doch schon umgesetzt
Siehe Version 0.3.2 -
@Mic, ich finde es nahezu unfassbar mit welcher Hingabe und Geschwindigkeit Du hier den Adapter nach vorne bringst. RESPEKT
Bist jetzt konnte ich tatsächlich alles was ich so an Blockly´s hatte in den Adapter migrieren, echt toll.Ich würde mir wünschen, wenn der Adapter so weit fertig ist, das Du Dir dein ein oder anderen Adapter vornimmst, "forkst" und diesen dann ebenfalls so usernah weiterentwickelst
Danke
