Test Adapter Windows-Control v0.1.x GitHub

[Mic]

@liv-in-sky sagte in Test Adapter Windows-Control v0.0.x GitHub:

klasse idee - werd morgen testen

Danke
Läuft bei mir sowohl auf einem Windows-Rechner (Testsytem) als auch produktiv unter Debian soweit gut...

[liv-in-sky]

@Mic

war neugierig - also noch schnell erster test
installation (linux) klappt - befehle werden ausgeführt

super umgesetzt

[Mic]

@liv-in-sky sagte in Test Adapter Windows-Control v0.0.x GitHub:

war neugierig - also noch schnell erster test
installation (linux) klappt - befehle werden ausgeführt

super umgesetzt

Cool, danke, freut mich

[liv-in-sky]

@Mic unter windows-iobroker funktioniert es auch ohne fehler

noch eine frage - man kann auch z.b. "http://192.168.178.36:8585/?chk=chrome" aufrufen und überprüfen, ob dieses programm läuft

das ist nicht integriert ?

[sigi234]

@Mic sagte in Test Adapter Windows-Control v0.0.x GitHub:

GetAdmin-Tool.

Da bekomme ich eine Viruswarnung

[liv-in-sky]

@sigi234 hatte ich auch - musst du im scanner als erlauben kennzeichnen

wird sogar bei einigen scanner in quarantäne geschickt - dann wieder herstellen lassen

[Mic]

@liv-in-sky
Danke für dein positives Feedback zu Windows.

noch eine frage - man kann auch z.b. "http://192.168.178.36:8585/?chk=chrome" aufrufen und überprüfen, ob dieses programm läuft
das ist nicht integriert ?

Folgt bald, steht schon auf meiner "Liste"

[Mic]

So, es geht weiter. Hatte ein paar Schwierigkeiten mit git (falls es interessiert: https://forum.iobroker.net/topic/31511/)

Wir sind jetzt bei Version 0.0.3, Änderungen:

0.0.3

• (Mic-M) Fix io-package.json (removed one redundand comma, not sure why node.js is not able to autocorrect such minor issue)

0.0.2

• (Mic-M) Fixed sendkey issue
• (Mic-M) State _sendKey: provide all supported keys as dropdown and no longer as open text field.
• (Mic-M) Renamed states: sendKey -> _sendKey, connected -> _connection

Alle verfügbaren Keys sind also nun per Dropdown im State verfügbar:

[Mic]

@liv-in-sky sagte in Test Adapter Windows-Control v0.0.x GitHub:

noch eine frage - man kann auch z.b. "http://192.168.178.36:8585/?chk=chrome" aufrufen und überprüfen, ob dieses programm läuft

Ich überlege gerade, was eine gute Umsetzung wäre.
Also angenommen es gibt einen Datenpunkt windows-control.0.Gästezimmer-PC.checkAppStatus als Textfeld.
Nun trägt man da z.B. chrome ein. Was soll dann geschehen mit der Rückmeldung (true/false)?
Reicht es, wenn dann in denselben Datenpunkt z.B. chrome:true/ chrome:false mit ack:true gesetzt wird? Oder was ist der Use Case?
Man könnte natürlich auch die Apps gescheduled prüfen, also Datenpunkte für jedes in der Adapter-Konfig gesetztes zu prüfendes Programm generieren mit Status true/false. Die Frage ist, ob man das braucht....

[liv-in-sky]

@Mic ich würde zum 2ten tendieren - so wie du das mit den commands machst - ein antwortfeld für alle process antworten und im setting definiert man den prozessnamen, der eine datenpunkt bekommt - evtl eine antwort als json format - also antwort und frage in einem json {chrome:true}
ein datenpunbkt für anfrage und antwort geht zwar aber man muss beim trigger aufpassen - bei iobroker unüblich

[Mic]

@liv-in-sky
Wie wäre es stattdessen, wenn regelmäßig geprüft wird, z.B. analog zum Polling auf "_connection".
Also: in den Adapter-Settings steht "Zu prüfende Prozesse": chrome, firefox, xyz.
Dann erzeugt daraus der Adapter Datenpunkte:

1. windows-control.0.Gästezimmer-PC.processStatus.chrome - true
2. windows-control.0.Gästezimmer-PC.processStatus.firefox - false
3. windows-control.0.Gästezimmer-PC.processStatus.xyz - true

Die Aktualisierung erfolgt lt. in Admin-Settings eingestellter Sekunden, z.B. alle 2 Minuten.
Zusätzlich einen State (als Button) updateAll, falls man den Status sofort braucht (in einem Script).

So sinnvoller? Damit wäre der Status auch in VIS einfach darstellbar.

[liv-in-sky]

@Mic hört sich gut an - hauptsache man kann dieses update sofort machen

würde mir gefallen

[CruziX]

Freue mich darauf das morgen auch mal zu testen.
Benötige eig nur Herunterfahren und hab das bisher über PAW2, tasker und Unified Remote gelöst, ist aber sehr unschön und funktioniert nicht immer korrekt.

[Mic]

@liv-in-sky sagte in Test Adapter Windows-Control v0.0.x GitHub:

noch eine frage - man kann auch z.b. "http://192.168.178.36:8585/?chk=chrome" aufrufen und überprüfen, ob dieses programm läuft

Neue Adapter-Version 0.1.0

Gibt jetzt 2 neue Datenpunkte _processGetStatus und _processGetStatusResult pro Windows-Gerät.

Um im JavaScript-Adapter den Status eines Prozesses abzufragen, kann man das Script hier nehmen:

Spoiler

const pcName = 'Gästezimmer-PC'; // Name des PCs (in Adapter Windows Control)
const checkProcess = 'chrome' // Welcher Prozess soll geprüft werden? Ohne .exe eingeben. Prüfen ob Chrome-Browser läuft: chrome

const windowsControlAdapterInstance = 0; // Kann man so lassen, wenn nur eine Instanz läuft.

/**
 * Ruft die eigentliche function getWindowsProcessStatus() auf. Im Callback kann dann darauf reagiert werden.
 */
getWindowsProcessStatus(0, pcName, checkProcess, function(status, device, process) {

    switch (status) {
        case null:
            log('Windows-Gerät [' + device + '] ist nicht konfiguriert, nicht erreichbar, oder Prozess-Name ist leer. Prozess-Name: [' + checkProcess + ']');
            break;
        case true:
            log('Windows-Gerät ' + device + ': Der Prozess [' + process + '] läuft.');
            break;
        case false:
            log('Windows-Gerät ' + device + ': Der Prozess [' + process + '] läuft nicht.');
            break;
        default:
            log('Windows-Gerät ' + device + ': Unbekannter Status: [' + status + ']');
    }

});


/**
 * Check if process is running
 * For adapter: https://github.com/Mic-M/ioBroker.windows-control
 * Change History: 
 *   Mic-M - 0.0.1 - Initial release
 * 
 * @param {number} inst     Instance of adapter windows-control
 * @param {string} device   Windows device to check
 * @param {string} process  Windows Process to check if running or not (like: "chrome")
 * @param {object} callback
 */
function getWindowsProcessStatus(inst, device, process, callback) {
    
    if (!existsState('windows-control.' + inst + '.' + device + '._processGetStatus')) {
        return callback(null, device, process); // State, and so the device, not existing
    } else {
        setState('windows-control.' + inst + '.' + device + '._processGetStatus', process, function(test) {
            setTimeout(function(){
                let result = JSON.parse(getState('windows-control.' + inst + '.' + device + '._processGetStatusResult').val);
                for (let lpEntry of result) {
                    //({process: whichProcess, status: status, ts: Date.now()});
                    if(lpEntry.process == process) {
                        if( parseInt(lpEntry.ts)+1000 > Date.now()) { // Check if entry within last 1000ms
                            if (lpEntry.status == 'true') {
                                return callback(true, device, process);
                            } else {
                                return callback(false, device, process);
                            }
                        }
                    }
                }
                return callback(null, device, process); // we did not have a hit, so return null;
            }, 300)
        });
    }
}

Gefällt mir aber noch nicht so gut, da sehr umständlich. Aber zumindest kann man es damit abfragen.

[liv-in-sky]

@Mic ist ja doch die json lösung geworden

getestet - funktioniert - danke

falls jmd interesse: für die abfrage und zum triggern ein beispiel in js und blockly, wie man da ran kommt

log((JSON.parse(getState("windows-control.0.NUC2._processGetStatusResult").val))[0].status)

[Mic]

@liv-in-sky sagte in Test Adapter Windows-Control v0.1.x GitHub:

ist ja doch die json lösung geworden
getestet - funktioniert - danke

Danke fürs testen und dein Script

Ja, ich habe mich dann doch für json entschieden, da wohl kaum wer ständig sehen muss (z.B. in VIS), welche Apps auf einem Windows-PC laufen. Das geht am Ziel des Adapters vorbei... Daher nur die Status-Abfrage bei Bedarf.

[Bostil]

Vielen Dank für den schönen Adapter! @Mic

Habe es an meinem Stick-PC nun eingerichtet, aber m_hibernate und m_sleep kommen zwar beim GetAdmin an, aber leider tut sich nichts. Andere Befehle funktionieren. Hat jemand eine Idee, ob hier eine Windows-Einstellung am Rechnung die Ausführung verhindern könnte.

Danke euch.

[Mic]

@Bostil
Danke fürs Testen und dein Feedback

Poste bitte am besten mal einen Screenshot von deinem GetAdmin. Wo läuft dieser denn, auf einem PC/Notebook oder einem anderen Endgerät? Welche Windows-Version?

[Bostil]

@Mic Danke für deine Rückmeldung @Mic Habe es wirklich so eingestellt, wie auf den von dir gezeigten Screenshorts, die bei der Einrichtung sowieso sehr hilfreich waren. Ist ja eigentlich idiotensicher. Andere Befehle, wie "poweroff" oder "logoff" funktionieren tadellos.

Es scheint eine Einstellung in meinem Windows 10 (aktuelle Version) zu sein. Ist ein "günstiger" Stick-Computer aus China, der nicht viel Power hat, aber gerade so eignet, um den Webbrowser mit der VIS per HDMI auf einem Touchscreen darzustellen.

Ich teste mal weiter. Aber Danke dir schonmal.

By the way hat der Ursprungsautor des Tools auf deinen Kommentar hin angemerkt, dass er das Tool auch um weitere Ideen / Features erweitern könnte top !

[Mic]

@Bostil
Danke für die Rückinfo.
Müsstest tatsächlich mal googlen, welche Befehle da sonst noch gehen. Sobald das über die Kommandozeile (also cmd.exe) geht, sollte das auch in den GetAdmin überführbar sein.

@Bostil sagte in Test Adapter Windows-Control v0.1.x GitHub:

By the way hat der Ursprungsautor des Tools auf deinen Kommentar hin angemerkt, dass er das Tool auch um weitere Ideen / Features erweitern könnte top !

Das ist super Wir können ja mal sehen, ob noch was zusammen kommt. Das Kontextmenü im Systray z.B. zeigt bei mir nur ????? an, weil ich wohl kyrillisch nicht drauf hab, da wäre wohl auch Englisch besser.