Retour Kanal gemäss 1.16

Hardware digitalSTROM
1

Der Samichlaus hinterliess mir angehängtes Skript. Damit liesse sich perfekt ein periodischen Retour Kanal erstellen mit vermutlich hoher Frequenz Möglichkeit.

@paresy Ich hoffe, dieses Skript überzeugt Dich, dies in Angriff zu nehmen. Ansonsten zeig mir eine Möglichkeit, wie ich feststelle, ob eine bestimmte DSUID im Configurator bereits erzeugt wurde. Wenn erzeugt dann welche IP-Symcon ID. Wie überschreibe ich dann den Wert dieser ID, da dieser bekanntlich „gesperrt“ ist. Ebenso sollte die DS_MakeRequest Funktion erweitert werden, weil jetzt „api/v1/“ anstatt „json/“ steht. Token-Abfrage ist sehr langsam.


$Server = "192.168.1.50"; 
$AppToken = "506aa41219d946d918cf7421ced104154e067c2e0c378cda8e50d6fcb1a12345";       //64-Stelligen Applikation Token
$tcpPort = "8080";
$dsuid="303505d7f8000000000000400002271a00";



$Call1 = "/api/v1/apartment?includeALL=true";
$Call2 = "/api/v1/apartment/status?includeAll=true";

$arrContextOptions=array(
    "ssl"=>array(
        "verify_peer"=>false,
        "verify_peer_name"=>false,
    ),
);


 

$sessionToken = fdSLogin();


//fdSGetJson($Call1, $sessionToken);

$ist2=fdSGetJson($Call2, $sessionToken);
$ist2=json_decode($ist2,true);
$ist2=$ist2['data']['included']['dsDevices'];

foreach ($ist2 as $value)
	{
        if ($value["id"]==$dsuid){
            $wert=$value['attributes']['functionBlocks']['0']['outputs']['0']['value'];
            $level=$value['attributes']['functionBlocks']['0']['outputs']['0']['level'];
            print_r($wert);
            print_r($level);}
//;
    }

/************************************************* Funktionen definieren  **********************************/
 
/* digitalSTROM Login Prozedure Function */
function fdSLogin(){
    global $Server;
    global $tcpPort;
    global $AppToken;
    global $arrContextOptions;
 
    if($sessionToken = file_get_contents("https://" . $Server . ":" . $tcpPort . "/json/system/loginApplication?loginToken=" . $AppToken, false, stream_context_create($arrContextOptions))){
        $sessionToken = json_decode($sessionToken);
        return $sessionToken->result->token;
    }
    else{
        return "<font color='red'><b>ERROR:</b> unable to get loginToken from digitalSTROM Server</font><br>";
    }
}
 
/* digitalSTROM get JSON content Function */
function fdSGetJson($call, $sessionToken){
    global $Server;
    global $tcpPort;
    global $arrContextOptions;
    $sHelp;
    global $debug;
 
    $sHelp = "https://" . $Server . ":" . $tcpPort . $call . "&token=" . $sessionToken;
 
    if($jsonOutput = file_get_contents($sHelp , false, stream_context_create($arrContextOptions))){
        return $jsonOutput; // plain output
    }
    else{
        return "<font color='red'><b>ERROR:</b> unable to get JSON Content from digitalSTROM Server</font><br>";
    }
}
2

Damit kennt man den output nicht nur der gelben Klemmen sondern auch der grauen Klemmen. Ebenso sieht man die Stellung der SW-UMR200.

Genauso würde man den Zuständ der Bereiche auch ablesen können (bräuchte man zwar gar nicht mehr). Ebenso die Benutzerdefinierten Zustände. (Die Benutzerdefinierten zustände sind bekanntlich schon in der alten API enthalten gewesen mit

DS_MakeRequest($Expert_id, "apartment/getDevices", "");

Die Temperatur und Luftfeuchtigkeit könnte man zwar nicht mehr ablesen. Hier hilft bekanntlich auch

DS_MakeRequest($Expert_id, "apartment/getDevices", "");

(Mit dem etwas schnelleren Befehl

$ist=DS_MakeRequest($Expert_id, "apartment/getSensorValues", "");

hat man jedoch ein Problem, wenn in einem Raum zwei Sensoren verbaut sind. Dann kann man diese in der Abfrage nicht unterscheiden.)

3

Wie bereits in dem anderen Thema angesprochen kann ich leider erst was planen/umsetzen, wenn wir was offizielles von dS bekommen. Zumindest einen Draft von einer Beschreibung oder ähnlichem :frowning:

paresy

4

Ich vermute, dass in 2021 dS keine Doku veröffentlicht. Der Samichlaus hat mir gesagt, dass die momentane Firmenpolitik kein solches Dokument heraus gibt. Eigentlich bin ich schon froh, dass wir überhaupt den Code bekommen haben.

Leider können wir diesen nicht verarbeiten.

Klar, wir könnten von Hand eine Funktion F(dsuid) zu IP-Symcon_ID erstellen. Mit dem Befehl


SetValue( F(dsuid), json_output);

können wir aber auch nicht hantieren, weil die Variable F(dsuid) schreibgeschützt ist. Wir müssten für jede Klemme eigene Variablen von Hand erzeugen. Nach getaner Arbeit kommt dann die Publikation von dS, IP-Symcon setzt es um und die ganze Arbeit müssen wir wieder zurück bauen.

  1. So gross wird der Aufwand nicht sein, um in der Funktion DS_MakeRequest den „json/“ Teil zu entfernen. Dann könnten wir zumindest die neue API schon einmal bequem verwenden ohne die Token Abfrage.
  2. Verrat uns, wir wir die Original erzeugten Variablen überschreiben können
5

Falls du da Kontakte hast, frage ich doch noch mal. Bekommen wir die Änderungen z.B. auch über den /event/get Rückkanal? Falls es dort integriert wäre, kann ich mir vorstellen, dass wir es mit minimalem Aufwand als experimentelles Features einbinden könnten. Worauf muss ich mich dann bei event/subscribe registrieren?

paresy