Bonjour,
Je viens d’acheter un frigo Liebherr connecté en wifi via une « smartdevice box » intégrée.
j’imagine qu’il n’y a aucun moyen de récuperer les infos dans jeedom, je ne crois pas que Liebherr publie son API ?
Bonjour,
Je viens d’acheter un frigo Liebherr connecté en wifi via une « smartdevice box » intégrée.
j’imagine qu’il n’y a aucun moyen de récuperer les infos dans jeedom, je ne crois pas que Liebherr publie son API ?
Salut Doryphore, je sus super intéressé aussi ! si ta des infos je suis preneur .
Bonjour,
Désolé, aucune info depuis…
Rien de neuf depuis?
Je suis également intéressé 
Idem, suis également intéressé
+1 je suis intéréssé
apparement les API viennent de sortir , j’ai la possibilité sur mon appli Liebherr desormais .
Bonjour,
J’ai survolé l’API. Pour le moment, c’est léger (plus que l’app
).
La seule info qui me parait utile sur mon congel, c’est sa température.
On peut aussi déclencher Superfrost et le mode party.
Pas d’info de porte ouverte comme ce que peut remonter l’app.
Ci-dessous le bloc code de scénario utilisé. Il faut renseigner la clé API.
$apiKey = "Clé API récupérable sur l'app";
$url = "https://home-api.smartdevice.liebherr.com/v1/devices";
$header = array("accept: */*", "api-key: $apiKey");
$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_URL => $url, CURLOPT_HTTPHEADER => $header,
CURLOPT_SSL_VERIFYPEER => false, CURLOPT_RETURNTRANSFER => true));
$response = curl_exec($curl);
$http_code = curl_getinfo($curl, CURLINFO_HTTP_CODE);
if($http_code == 200) {
// log::add(__CLASS__, 'debug', " ----- CURL OK ".__FUNCTION__ ." $url");
curl_close($curl); unset($curl);
$scenario->setLog($response);
$devices = json_decode($response,true);
if($devices === null) {
$scenario->setLog("Json_decode error : " .json_last_error_msg() ." " .substr($resource,0,50));
return;
}
else {
foreach($devices as $device) {
if(isset($device['deviceId'])) {
$deviceId = $device['deviceId'];
$scenario->setLog("DeviceID: $deviceId");
$scenario->setLog(" Name: [{$device['nickname']}]");
$scenario->setLog(" Image: [{$device['imageUrl']}]");
$scenario->setLog(" Type: [{$device['deviceType']}]");
$scenario->setLog(" Model: [{$device['deviceName']}]");
$urlDev = $url ."/$deviceId/controls";
$scenario->setLog(" URL device: $urlDev");
$header = array("api-key: $apiKey");
$curl = curl_init();
curl_setopt_array($curl, array(CURLOPT_URL => $urlDev, CURLOPT_HTTPHEADER => $header,
CURLOPT_SSL_VERIFYPEER => false, CURLOPT_RETURNTRANSFER => true));
$response = curl_exec($curl);
$scenario->setLog(" $deviceId features:" .$response);
$features = json_decode($response,true);
if($features === null) {
$scenario->setLog("Json_decode error : " .json_last_error_msg() ." " .substr($resource,0,50));
}
else {
foreach($features as $feature) {
$scenario->setLog(" Feature:" .json_encode($feature));
}
}
}
else {
$scenario->setLog(" DeviceID not set in " .$response);
}
}
}
} else {
$scenario->setLog(" Curl error. Code: $http_code");
curl_close($curl); unset($curl);
}
Après la création d’un virtuel avec des commandes, l’ajout de quelques tags dans le code ci-dessus et les events pour renseigner les commandes :

Bonjour,
J’ajoute la documentation de l’API qui est simple d’utilisation :
https://developer.liebherr.com/apis/smartdevice-homeapi/swagger-ui/
Dans l’app « Smart Device Liebherr » sur Smartphone, menu paramètre en haut à gauche, puis, devenir beta testeur, puis activer l’interphase HomeAPI pour obtenir votre clé API
Actuellement possibilité de récupérer 2 JSON avec les références de l’appareil puis un autre avec la température et le mode SuperFrost.
Possibilité également de faire des POST pour activer/désactiver le mode SuperFrost ainsi que la consigne de température.
Exemple :
curl -X POST ‹ https://home-api.smartdevice.liebherr.com/v1/devices/xxxx/controls/superfrost › -H ‹ accept: / › -H ‹ api-key: xxxxxxxx › -H ‹ Content-Type: application/json › -d ‹ {« zoneId »: 0,« value »: true} ›
Je n’ai pas trouvé d’information concernant l’état de la porte et/ou l’alarme lorsque que la porte du congélateur est restée ouverte ![]()
pour partage Liebherr vient de blacklister mon IP car à raison de 1 requete toutes les 5 minutes ils jugent que c’est trop important …
dans leur documentation :
- We suggest polling the controls every 5 sec. You can use the GET request on /v1/devices/{deviceId}/controls to get all states with one poll
- For security reasons, there can be a restriction of the number of possible polls, if we receive too many API calls
La réponse à leur problème est de fournir des APIs locales.
Il faut faire une pression importante en tant que consommateur pour que ce type de groupe assez peu à l’aise avec les nouvelles technologies basculent sur des standards ouverts (Matter, MQTT) et cessent d’imposer des connexions cloud pour des informations qui n’ont pas besoin de remonter dans leur serveur.
Evidemment … ca ne va pas régler ton problème !
Bonjour à tous,
Le sujet date un peu, mais c’est le premier qui ressort quand on cherche « Liebherr » et « Jeedom », alors autant y mettre la suite.
Comme l’avaient repéré @romaingi et @jpty, Liebherr a fini par ouvrir une API : la HomeAPI SmartDevice, toujours en bêta. La clé se génère dans l’application mobile, dans Paramètres > Devenir bêta testeur > Activer l’interface HomeAPI. Attention, elle ne peut être copiée qu’une seule fois.
J’ai fait une passerelle entre cette API et MQTT, au format MQTT Discovery : le plugin MQTT Discovery crée l’équipement et ses commandes tout seul, il n’y a rien à déclarer à la main.
Précision tout de suite pour éviter la confusion : c’est un conteneur Docker, pas un plugin Jeedom.
(elle est aussi dans les Community Applications d’Unraid pour ceux que ça concerne, en cherchant liebherr2mqtt)
Sur mon IRBci 5151, ça remonte la température, la consigne (réglable depuis Jeedom), SuperCool, le Mode Party, le Mode Nuit et un témoin de liaison. Le code gère aussi SuperFrost, la machine à glaçons, HydroBreeze, BioFresh-Plus, l’éclairage de présentation et la porte automatique — la liste des commandes est construite à partir de ce que l’appareil déclare lui-même, donc ça devrait s’adapter à vos modèles sans rien changer.
Deux choses qui m’ont pris du temps et qui vous en feront peut-être gagner :
@Jezz s’était fait blacklister son IP à raison d’une requête toutes les 5 minutes. Il existe en fait un endpoint SSE (/v1/sse/devices/{id}/controls) qui pousse les changements en temps réel. La passerelle ne fait donc aucun polling : elle ouvre le flux et attend. Une relecture complète toutes les 15 minutes sert juste de filet de sécurité.
Dans le plugin MQTT Discovery, il faut que liebherr figure dans les « topics de données ». Le plus simple est de laisser le plugin le proposer : démarrez le démon, attendez une minute, rafraîchissez sa page de configuration, la racine découverte apparaît avec un bouton +. C’est documenté : le plugin n’active pas d’office ce qu’il trouve, pour ne pas créer des équipements que personne n’a demandés.
Deux limites, par contre. Toujours pas d’état de porte ni d’alarme : ce n’est pas dans la HomeAPI, l’application mobile passe par une autre API interne. Et pour répondre à @guipom sur les API locales : la LocalAPI existe bien dans la SmartDeviceBox, mais Liebherr la désactive à distance sur les appareils grand public, elle n’est ouverte que sur les gammes pro.
Le pont s’appuie sur pyliebherrhomeapi, la bibliothèque de l’intégration officielle Home Assistant, plutôt que sur du code maison — comme ça il suivra les évolutions de l’API.
J’ai choisi le conteneur parce que c’est ce qui me demande le moins d’entretien chez moi, et que ça sert aussi à ceux qui sont sous Home Assistant ou autre chose. Mais si ça intéresse du monde, je peux en sortir une version plugin Jeedom — dites-le moi ici, je verrai en fonction de la demande.
Bonne journée à tous.
Richard