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
Ca dépend car c’est un petit bordel entre la nouvelle api full json et les anciens endpoints dont on a besoin encore dont certains sont des http form, d’autre en urlencoding, etc… J’ai bien galéré à chaque fois à devoir verifiéer dans le code du fw comment c’était implementé.
Tu as un git avec la source de ton plugin ?
edit: ca y est les builds test avec l’ui2 sont générés automatiquement coté git openevse quand je pousse de nouvelles modifs sur l’ui : Release V2 GUI pre-release · OpenEVSE/openevse_esp32_firmware · GitHub
Hello, oui c’est ici:
Donc la V2 va officellement sortir d’ici quelques jours, bien!
Regardes mon p’tit code et dis moi si tu trouves des choses pas bien …
Merci tout plein!
Sebastien
Salut @Sattaz, je viens de tester ta modif ( /override max_current ) et ca marche très bien. Je ne sais pas ce qu’il s’est passé quand tu as testé, mais ca fonctionne 
J’ai bien les bonnes donnees publiées, le pilot se met à jours, et le slider aussi coté client ( new ui ):
edit: je zieute vite fait ton code:
sauf erreur de ma part tu ne lis pas la réponse serveur sur tes publications. Un post /override doit te répondre {msg: « OK »} si le claim est bien passé. Ca peut valoir le coup de vérifier.
J’ai pas regardé encore comment tu récupères la valeur du slider pour la mettre à jours coté interface jeedom.
Chose à laquelle je me suis retrouvé confronté qui peux t’interesser en fonctiin de ce que tu veux faire: Si tu ne lis que la valeur charge_current du endpoint /override, tu es sûr de n’afficher que la commande manuelle qui a été émise soit par ton plugin, ou ailleurs en /override par ex depuis l’UI2.
Mais si un service autre a envoyé un claim avec une priorité supérieure ou juste qu’il n’y a pas d’override et un claim d’un autre service ( Divert par ex ), tu ne le verras pas depuis /override
Et si tu lis directement le endpoint /claims c’est un peu chiant à parser pour chopper celui qui est actif.
Tu as un endpoint non documenté qui s’appelle /claims/target
Il permet de savoir rapidement quel service controle quelle propriété. ex:
{
"properties": {
"state": "disabled",
"charge_current": 17,
"max_current": 28,
"auto_release": false
},
"claims": {
"state": 65540,
"charge_current": 65537,
"max_current": 65548
}
}
tu vois ici tout de suite ici que c’est le client 65548 ( Shaper) , qui controle « max_current », et le client 65537 ( Manual override) qui controle « charge_current »
Je récupère ces données pour afficher le petit tooltip sous le slider avec l’identifiant qui le controle.
@Manumdk , j’ai ouvert uine issue pour ton soucis, histoire d’exposer ces settings 254/255 à travers l’api.
@KipK , j’avais pas le temps ces derniers jours de travailler sur le plugin mais je vais m’y mettre.
Deja c’est tres etrange que ma borne ne reagisse pas comme chez toi …
Je vais essayer de mettre ton dernier firmware pour voir si c’est mieux. Dois-je prendre la V2 GUI Pre-Release depuis le site d’openEVSE?
Si oui, quel fichier? (gui-v2 ou wifi_gui) ?
Merci,
Sebastien
gui-v2 ,l,'autre c’est l’ancienne UI
OK, j’ai mis le dernier firmware. Belle ton interface au passage
Mais la j’ai un soucis:
Je continue mes tests.
Edit:
Selon ta deuxieme remarque, tu dis que je ne lis pas si le claim/override est bien passe … en fait je recupere la reponse dans le log du plugin Jeedom, je vois bien un {msg: Created}
Mais que faire avec cela? si j’ai une erreur de communication alors err de CURL me le dit et je le log aussi.
Puis le refresh du slider en lisant pilot indique si la la valeur est bien passee.
C’est suffiant non?
Pour ta troisieme remarque, c’est la valeur de l’endoint /status pilot qui est recupere puis compare a la valeur du slider de Jeedom, si pas pareil alors le slider se met a la position de la valeur de pilot.
Bon ou pas ?
quatrieme point, j’ai pas bein compris le truc du /claims/target
A voir pour la suite …
dernier point qui m’interesse beaucoup c’est d’utiliser un websocket pour recuperer les valeurs en temps reel … mais je ne sais trop ou commencer avec ca.
Tu aurais un petit exemple php sous la main? (pas de dependance necessaire j’espere?)
Milles merci pour tout!
Sebastien
Sebastien
pour RAPI y a pas de raisons, dans la partie /configuration/developpeur de l’ui tu peux envoyer les commandes rapi ?
sinon le endpoint est bien toujours fonctionnel je viens de tester:
/r?json=1&rapi=$G0
J’ai edite mon precedent post … tu veux bien relire?
Merci
mes remarques étaient plutot à titre informatif , j’ai pas eu le temps de bien regarder le plugin.
pour la 3eme oui tu peux faire comme ça, dans 90% des cas ca sear suffisant.
Sur la nouvelle UI j’ai utilisé justement le /claims/target , ce qui me permet d’afficher sous le slider quel service controle cette valeur et de pouvoir même supprimer certains ordres externes ( par ex un ordre depuis mqtt sur le charge_current , j’affiche une vignette mqtt sous le slider pour mentionner que c’"est lui qui definit le charge_current à l’instant t. Si je le supprime depuis l’ui, alors une nouvelle vignette apparait avec manual, qui correspond à l’ordre que j’aurais donné depuis l’UI avant celle de MQTT ( c’est juste un ex )
pour le dernier point, tu as l’exemple en javascript sur la nouvelle ui , pour du php, je sais pas trop, mais ca doit etre bien documenté.
ok je vais voir pour le websocket …
Encore un truc:
Si je change la valeur du ‹ charge rate › depuis l’interface ou depuis l’endpoint /override charge_current, parfois sur l’interface la valeur de ‹ setpoint › change et parfois pas … idem quand je recupere l’endoint /status pilot
un bug ?
Sebastien
fais voir ce que donne justement /claims/target voir ce qu’il affiche quand ca bug ?
Sinon pas normal non jamais eu ce bug encore ca m’étonne.
Voilq ce que donne claims/target:
{"properties":{"state":"active","charge_current":14,"auto_release":false},"claims":{"charge_current":65537}}
bizarre tout est normal , on dirait que ton pilot est à la traine, aucune erreur dans la console du navigateur ?
Non aucune erreur surle navigateur du PC.
Depuis mon iphone c’est pareil.
J’avais remarque ceci lors de mes premiers tests, j’ai fait un restart du firmware wifi et ca fonctionnait alors.
Puis c’est encore arrive par la suite. Je viens de redemarrer encore une fois et la ca fonctionne a nouveau.
hum hum …
Sebastien
T’es sur que c’est pas la connection wifi qui saute ? Regarde si les logs marchent correctement depuis l’ui ( /config/developpeur ), si le module esp decroche du wifi la console devrait freeze.
Edit: en rafraichissant l’interface, le pilot reste toujours sur l’ancienne valeur ?
OK je visn de trouver ce qui provoaue le probleme:
Depuis mon plugin Jeedom en utilisant RAPI, si je fais ceci :
curl_setopt_array($ch, [
CURLOPT_URL => 'http://'.$OpenEVSE_IP.'/r?rapi=$SC%20'.$valueSlider,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 10,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => 'GET',
]);
$data = curl_exec($ch);
curl_close($ch);
alors le courant max se met apparement a la valeur du slider mais rien ne l’indique sur l’interface web.
rien non plus dans l’endoint /status pilot, tout rest pareil.
Donc si je regle a 10 amperes depuis cette commande RAPI je ne vois rien depuis l’interface mais aussi je ne peux plus depasser 10 amperes en essant d’ajuster depuis l’interface:
c’est normal ca?
ah c’est normal oui, c’est justement pour ça qu’il faut éviter rapi.
L’api a été créee justement pour résoudre les soucis d’ordres venant de multiples sources différentes. Rapi ne peut etre utilisé que si un seul service controle l’evse en fait. Et maintenant c’est le module Wifi qui se charge de communiquer en RAPI avec le module, et normalement rien d’autre ne devrait s’en servir ( sauf pour debug )
ok, alors il faudra que je retire RAPI du plugin et obiliger les utilisateurs de passer sur la nouvelle interface/firmware.
