Hatte zuerst dasselbe Ergebnis (NULL). Nach Durchsicht der opsi-client-agent, opsi-script und opsi-utils Changelogs (
https://changelog.opsi.org) hatte ich den Verdacht/die Hoffnung, dass neuere Versionen auf dem Client und Server einen anderen Wert liefern werden. Deshalb opsi-utils auf dem server aktualisiert (4.3.19.3-1 -> 4.3.20.2-1 - aus dem experimental release)
p-xx-00000-0001 (opsi-client-agent und opsi-script auf dem Client aktualisiert)
opsi-client-agent_4.3.15.2-1
opsi-script_4.12.18.8-7
p-xx-00000-0003 (opsi-client-agent und opsi-script auf dem Client NICHT aktualisiert)
opsi-client-agent_4.3.13.7-2
opsi-script_4.12.18.7-7
Jetzt liefert der Befehl endlich ein Ergebnis - s. Screenshot:

- opsi-cli_uptime_Abfrage.png (43.06 KiB) 276 mal betrachtet
Laut dem opsi JSON-RPC-API Handbuch liefert der Befehl hostControlSafe_uptime die Uptime der Clients in Sekunden.
Wir benutzen diese uptime Abfrage nicht, aber nur so als Hinweis:
Mich hat die Ausgabe beim Client p-xx-00000-0001 (alias PC 001) stutzig gemacht. Deshalb hier die Betriebssystemzeit laut Windows beider Clients:

- pc_001_uptime_laut_windows.png (69.66 KiB) 274 mal betrachtet

- pc_003_uptime_laut_windows.png (67.12 KiB) 274 mal betrachtet
PC 001 liefert seltsamerweise somit beim opsi-cli Aufruf (in der Kombi an opsi-client-agent/script Version und nach einem Update der Pakete auf dem Client) ein anderes Ergebnis als Windows: 266 seconds +/- ca. 1h zwischen den Screenshots von Windows und opsi-cli != 3 Tage 18 h. PC 003 hat die korrekte Uptime via opsi-cli geliefert. Da es aber eh nur ein Testsystem ist ignoriere ich diesen Unterschied, da es diverse Ursachen dafür geben kann. Hauptsache es liefert mir keinen NULL Wert mehr.