Pas de soucis, si c’est voulu que ça scroll 
Là il ne manque qu’une partie du bouton About donc ça me semblait pas désiré de ta part. Idem sur la charge il ne manque que le bas des boutons.
Pour l’effet tableau de bord, ça ne me semblait pas souhaitable de scroller pour si peu, autant réduire les cadres de qq millimètres qui ne pénaliseront pas la lecture.
Mais c’est peut-être facile à dire et compliqué à faire, je ne suis pas doué en balises et autres 
Rapporte nous aussi du soleil
Bonne fête de fin d’année et bonnes vacances
Oui je peux tester si tu renvoies le lien googledrive de cette modif
Salut a tous,
Je souhaite publier la nouvelle version du plugin OpenEVSE qui gere la nouvelle API WIFI mais je bloque ici:
https://community.jeedom.com/t/cacher-masquer-une-commande-si-option-selectionnee/98173/2
Si un developpeur peut me donner conseil ce serait sympa 
Sebastien
Bonsoir,
Contacte Xav-74 il me semble qu’il avait fait ce genre de chose pour le plugin mybmw.
Cordialement
Salut a tous!
Le plugin OpenEVSE est mis a jour et integre la nouvelle API WIFI.
Merci encore @KipK, @rennais35000, @tomitomas, @Phpvarious et @Mips pour votre aide!
Sebastien
Du coup on peut fermer ce fil?
rappel sur community 1 sujet = 1 question => 1 solution
117 messages c’est complétement inutilisable
Effectivement le fil est parti dans tous les sens …
Pour ma partie c’est ok mais @rennais35000 et @KipK echangent encore sur autre chose … a eux de juger.
Sebastien
Bonjour et meilleurs vœux,
Pas de souci pour moi, vous pouvez le fermer. Kipk saura bien me trouver si besoin à son retour de vacances
Cordialement
on pourra aussi en profiter pour changer la solution du 2nd post (fermé donc je ne peux pas rebondir dessus!) :
https://community.jeedom.com/t/cacher-masquer-une-commande-si-option-selectionnee/98173/2?u=tomitomas
la solution au problème initial « comment faire » est le msg #2, et non pas le dernier qui corrige un autre soucis
Bonjour à tous,
Je continue sur ce post…
La commande Set Disable met la borne en pause soit l’état 254.
Ma Zoé est sacrément capricieuse et il ne faut pas que je loupe les préliminaires si je veux arriver au bout avec elle …!!
Donc mon rituel :
Voilà, je valide ça cette nuit, mais la commande $FD permettant de passer en 255 est essentiel.
Manu
Salut !
C’est ce que je disais, le passage en 255 est essentiel!
Hors avec l’API WIFI ça ne passe pas en 255 mais uniquement en 254.
Je pense avoir tout essayé, Pause Status en enabled et disabled … rien n’y fait.
Bon, moi avec la Tesla ça ne dérange pas mais comme le dit Mamundk il semble que sa Zoe a besoin du passage en 255.
Sébastien
Ah, lors de mes essais, je n’avais pas rebooté OpenEvse.
Mais je crains que cette fonction ne me permette plus de détecter le branchement de la prise. Donc quand je vais brancher ma Zoé, le déclenchement automatique de la charge durant 30 secondes risque de ne pas se faire, la voiture ne devrait pas se réveiller au passage de HC.
Extrait du Github
tested running a short charge before putting the EVSE to sleep and the Zoe did not start charging at the start time. $FD/$FE started the charge.
Je ferai le test quand la Zoé sera rentrée.
Sinon, pourquoi la commande $FD n’est pas accessible par l’API ?
Effectivement, si l’openevse en 255, pas de détection du branchement.
Il faut donc que je mette en Ready en appuyant sur le bouton pour la charge commence durant 30 secondes, suivant le protocole expliqué plus haut.
Le passage en Disable 255 entraine un clignotement bleu / rouge de la Zoe, je ne suis pas sûr qu’elle soit fonctionnelle à 2h. Il me semble que ça la passe en chargeur défectueux.
Résultat demain matin.
Bonjour!
@KipK , oulala pas mal a revoir je vois
Alors d’apres tes recommandations, j’ai modifie la fonction SetSliderSetpoint comme ceci:
curl_setopt_array($ch, [
//CURLOPT_URL => 'http://'.$OpenEVSE_IP.'/config',
CURLOPT_URL => 'http://'.$OpenEVSE_IP.'/claims/client',
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 10,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => 'POST',
//CURLOPT_POSTFIELDS => '{max_current_soft:'.$valueSlider.'}',
CURLOPT_POSTFIELDS => '{charge_current:'.$valueSlider.'}',
CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
]);
$response = curl_exec($ch);
$err = curl_error($ch);
curl_close($ch);
if ($err) {
log::add('OpenEVSE', 'debug','Fonction SetSliderSetPoint : Erreur CURL (WIFI API) -> ').$err;
} else {
log::add('OpenEVSE', 'debug','Fonction SetSliderSetPoint : Changement référence intensité à '.$valueSlider.' ampères (WIFI API) -> ' .$response);
return $valueSlider;
}
Et pour recuperer la valeur du setpoint de charge je fais comme ceci deouis la fonction GetData:
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "GET");
// Get OpenEVSE Amperes Set Point
curl_setopt($ch, CURLOPT_URL, 'http://'.$OpenEVSE_IP.'/claims/client');
$data = curl_exec($ch);
if (curl_errno($ch)) {
log::add('OpenEVSE', 'debug','Fonction GetData : State - Erreur CURL (WIFI API) -> '.curl_error($ch));
return;
}
$json = json_decode($data, true);
$setPointEVSE = $json['charge_current'];
$cmd = $this->getCmd(null, 'EVSE_AmpSetPointReadBack');
$setPointCMD = $cmd->execCmd();
if ($setPointEVSE != $setPointCMD) {
// Set AmpSetPointReadBack value
$this->checkAndUpdateCmd('EVSE_AmpSetPointReadBack', $setPointEVSE);
//Refresh position of the slider
$cmdAmpSetPointSlider = $this->getCmd(null, 'EVSE_AmpSetPointSlider');
$options = array('slider'=>round($arr[2],0));
$cmdAmpSetPointSlider->execCmd($options, $cache=0);
log::add('OpenEVSE', 'debug','Fonction GetData : Amperes Set Point (WIFI API) -> Rafraîchissement valeur set point intensité à '.$setPointEVSE. ' ampères');
} else {
log::add('OpenEVSE', 'debug','Fonction GetData : Amperes Set Point (WIFI API) -> Check valeur set point EVSE vs Plugin OK ('.$setPointEVSE.' ampères)');
}
Je n’utilise donc plus ‹ config › mais ‹ claims › …
Mais ce que je remqraue c’est que l’interface web ‹ officielle › ne montre pas ce changement d’intensite:
La valeur de MAX CURRENT sur l’interface web reste toujours pareil donc si je comprends bien je dois la configuer en fonction de l’intensite MAX qui est donne dans mon plugin et c’est ensuite CHARGE_CURRENT qui s’occupe de varier cette intensite, correcte? (j’ai pas la voiture sous la main pour verifier la … c’est madame qui l’a )
Avant avec RAPI on changeait bien MAX CURRENT, donc ca ecrivait aussi toujours dans l’eeprom, vrai?
Pas tres simple tout cela… mais avec tes conseils on va bien avancer!
Je corrige point apres point en fonction de tes retours.
Merci beaucoup pour ton aide!
Sebastien
Negatif, si je change CHARGE_CURRENTdepuis un CLAIM alors PILOT reste a l’ancienne valeur dans STATUS ! (je crois d’ailleur que c’est bien pour cela que je n’ai pas fait comme ca…
Du coup pour confirmer le feedback je lis en retour egalement le CHARGE_CURRENT du claim …
Alors qu’avant cette derniere modification, lorsque je changeais le MAX_CURRENT_SOFT dans CONFIG, la PILOT changeait avec la bonne valeur.
C’est un beug de la V4.1.7 peut-etre?
Je sais plus trop quoi faire la …
Sebastien
Expliquer à Renault que leur Zoe a un bug et que la solution est dispo sur un forum, c’est pas gagné 
J’ai déclaré forfait, sans une recommandation du TechnoCentre, ils ne font rien. !!!
Je suis satisfait de la parade que j’ai réussi à mettre en place, je ne vais pas perdre mon temps avec un chef d’atelier qui ne comprend pas grand chose à tout ça !!!
Je resterai figé à cette version qui me permet de gérer le $FD.
Merci
Salut,
@KipK , quand tu dis ‹ firmware › tu parles bien du firmware wifi et rien d’autre, vrai?
J’ai le dernier firmware v4.1.7 de ce git:
https://github.com/OpenEVSE/ESP32_WiFi_V4.x/releases
J’ai essaye de modifier le code de mon plugin pour utiliser l’endpoint /override comme ceci mais rien de change dans /status ‹ pilot › :
curl_setopt_array($ch, [
//CURLOPT_URL => 'http://'.$OpenEVSE_IP.'/config',
CURLOPT_URL => 'http://'.$OpenEVSE_IP.'/override',
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 10,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => 'POST',
//CURLOPT_POSTFIELDS => '{max_current_soft:'.$valueSlider.'}',
CURLOPT_POSTFIELDS => '{charge_current:'.$valueSlider.'}',
CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
]);
$response = curl_exec($ch);
$err = curl_error($ch);
curl_close($ch);
if ($err) {
log::add('OpenEVSE', 'debug','Fonction SetSliderSetPoint : Erreur CURL (WIFI API) -> ').$err;
} else {
log::add('OpenEVSE', 'debug','Fonction SetSliderSetPoint : Changement référence intensité à '.$valueSlider.' ampères (WIFI API) -> ' .$response);
return $valueSlider;
}
Soit j’ai loupe un truc ou alors il y a un bug dans ce firmware…
Et pourquoi ils ont rendu le truc aussi complex/vague? Avant avec RAPI on utilisait des commandes simple et la il y a tellement de possibilites que ca devient incromprehensible.
Je suis un peu perdu.
@Manumdk , oui moi aussi je continue d’utiliser RAPI (appels de type $FD) depuis mon plugin jursqu’a ce que la nouvelle API WIFI soit totalement au point.
Sebastien
Sebastien
Salut @KipK ,
Je ne crois pas que ce soit un problème avec CURL sinon les autres requêtes ne passeraient non plus.
De plus j’ai pris les examples exactement qui sont donnés sur les pages de l’API.
Je vais installer ton firmware pour voir.
Sebastien