Test Adapter Windows-Control v0.1.x GitHub

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

[SBorg]

Vorweg: tut was es soll
Wunschliste: SSL + Auth (IT ler halt ), damit die Sicherheitslücke nicht wie ein Scheunentor wirkt
Hint: auch Linux lässt sich damit steuern...

[Mic]

@SBorg
Danke fürs testen und dein Feedback

Wunschliste: SSL + Auth

Da kenne ich mich leider null mit aus. Kennst du da ein handliches (am besten portable) Tool für Windows, was man nutzen könnte, also welches die Commands vom ioBroker empfangen kann?
Ich bin da offen, das dann in den Adapter einzubauen...

[SBorg]

@Mic Muss ich selbst mal schauen. Ich hatte mir mal ein kleines Tool für Windows geschrieben, aber um von Windows per Knopfdruck andere Rechner/Geräte zu steuern. Aber ev. wäre ja auch Vladimir bereit sein GetAdmin auf zu pimpen...

[Mic]

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

Aber ev. wäre ja auch Vladimir bereit sein GetAdmin auf zu pimpen...

Ich sammle das mal für die Liste an Vladimir

@ Alle
Kurzes Update:

Neue Version 0.1.2

Danke noch mal an alle Tester!

In der Version 0.1.2 - siehe https://github.com/Mic-M/ioBroker.windows-control - wurden nur ein paar Fixes/Verbesserungen unter der Haube durchgeführt, ansonsten hat sich nichts geändert.

Ich bin dabei, den Adapter ins Latest Repository aufnehmen zu lassen. Für die Interessierten hier zum lesen: https://github.com/ioBroker/ioBroker.repositories/pull/678
@apollon77 hat mir sehr hilfreiches Feedback gegeben, das ist nun in der 0.1.2 integriert.

Mic-M created this issue in ioBroker/ioBroker.repositories

closed windows-control added #678

[Mic]

Update-Info:
Der Adapter ist nun im Latest Repository - (merged #678 into master)

[surfer09]

Hallo zusammen,

ich fände es noch gut, wenn man aktive Prozesse damit abfragen könnte. Ich weiß nicht, ob das schon auf der Entwicklungs-Agenda steht?
Ich habe nämlich Systeme am laufen, bei denen bestimmte Programme im Hintergrund aktiv sein müssen. Sind sie das nicht, hätte ich gerne eine Meldung, damit ich reagieren kann.
Ansonsten super Adapter!