Bug suite MàJ Plugin Shelly

‹ Il pourrait › c’est pllud que du subjonctif, c’est il y a
L’existence du démon nodejs venait palier a une limite de caractères qui rendait les actions Shelly inutilisable via l’API jeedom, URL trop longue.
Depuis leur changement sur la gestion des actions, la limite du ily a est bien supérieure, ils arrivent même a garder jusqu’à 5 URL en parrallele (c’est d’ailleurs la prochaine mise a jour du plugin pouvoir setter directement de jeedom les actions des Shelly, y compris URL directe si c’est un Shelly)

Mais enlever 5 caractères au début ne change rien.

C’est la sauvegarde de l’équipement qui fait tout.
Sur update du plugin il doit le faire sur tous, mais dans les vieilles versions jeedom j’ai pas vraiment confia ce.
Et quand je vois fds URL encore vide sans l’adresse en 8122 CZ veut dire que ça n’a jamais marcher le retour d’État sur ce Shelly, rien a voir avec la mise a jour.

Et pour l’histoire que ça fonctionne uniquement sans restriction c’est quoi le problème du coup ?

Pour info je suis en 4.0.61 et j’ai des shelly 1 et plug s et j’avais bien l’adresse en 8122 avant.

3 messages ont été scindés en un nouveau sujet : Mise à jour Shelly et jeelink

Bon bah je pense qu’on aura jamais notre réponse sur les login/pass. Quand le développeur vient ici c’est pour mettre des cartouches à des personne qui veulent juste aider comme @AntFleu ou d’autre. C’est dommage et ça va à l’opposer du principe de cette communauté.

Je viens juste tempérer les propos.

Je pense que Lunarok a étudié les API Shelly et leur changement. Donc vu son niveau je pense qu’il sait de quoi il parle sinon on aurait pas de plugin du tout.

Maintenant, il a poussé une version de son plugin qui tient compte des dernières modifs de shelly.
Peut-on lui reprocher, à mon humble avis non !

Doit-on sur ce post tenir compte des personnes qui viennent faire +1, moi aussi etc. sans log, je ne suis pas sur car sans log sans véritables informations techniques, on ne peut rien faire

Est-ce que ces personnes qui ont des soucis on tenté de mettre en place ce qui a déjà été dit et que j’ai résumé dans un post on ne sait pas !

Bref, même si Lunarok n’est pas le meilleur communiquant, c’est n’est pas no plus un manche en développement !

Est-ce que les gens qui se plaignent donnent des infos, il suffit de lire les posts de ce forum pour s’apercevoir qu’en majorité on ne sait pas quel version de jeedom ils ont, ni la version de linux, ni la version du plugin, ni si ils ont tenté les solutions mises en avant, ni de log ni rien…

Après modifier une url sans connaitre et avoir étudié l’API ok, mais on peut se poser la question de la pérénité de la solution…

Bref ca ne fait pas avancer la chose, mais ce n’est pas non plus en ayant des +1 et des moi aussi que l’on donne du grain à moudre pour peut être mettre en avant un souci qui à ce jour n’est pas avéré.

Le but est de prouver via log et autre qu’il y a une intéraction entre la config de chacun, la nouvelle API et le plugin.

Il y a tellement de parametres en jeux que seule une analyse détaillée et technique permettra de trouver la root cause.

Et ce n’est pas en s’écharpant sur un forum communautaire ou le developpeur est même pas censé intervenir que l’on aboutira à quelque chose.

Quand on voit le nombre de gens qui achete un module sans en lire sa doc pour connaitre ses capacités, ces spécificités…
exemple Shelly 1 fonctionnement ca laisse réveur.

Je suis en accord avec quasi l’ensemble de ton message.

Mais nous sommes plusieurs ici à avoir donné des pistes, ou s’être porté volontaire pour tester. Pas de réponse.
A la simple question pour la restriction qui fonctionnait avant avant mais plus maintenant, et surtout que devons nous faire : attendre une MAJ du plugin ? attendre une MAJ du firmware ? Peu importe la réponse du moment que nous en avons une.
« ’Ce n’est pas non plus un manche en développement », j’en doute pas une seconde, donc justement c’est aux dev de nous aiguiller, plutôt que de se faire renvoyer dans ses 22 (sur ce poste ou d’autre …).

Autre question plus général : qu’elle est le canal « officiel » pour contacter un dev sur un plugin payant ?

Effectivement je me renseigne avant d’acheter.

Bon j’avais télécharger le PDF mais j’ai pas lu car je pensais que c’était des infos si on utilisais une appli Shelly!!!

Ouvrire un ticket sauf que quand tu activé les bêta, plus de sav

1 « J'aime »

si je répond pas c’est que y a aucune info ou raison.
Credentials activés, le plugin fonctionne.

Et quand je lis que ca serait que le retour d’état qui ne marche pas en ayant les credentials activés, désolé mais encore une fois ca marche et c’est improbable que ca soit autrement (que les actions ou le cron marche mais pas le settings des webhooks)

Je viens de rester à l’instant.

Sans restriction j’ai le retour d’état de mon volet (Shelly 2.5).
Avec restriction je n’ai plus le retour d’état.

J’ai que ça comme log :
Sans :

[2020-11-12 16:11:19][DEBUG] : Call : http://192.168.15.125/status
[2020-11-12 16:11:19][DEBUG] : Call : http://192.168.15.125/meter/0
[2020-11-12 16:11:19][DEBUG] : Call : http://192.168.15.125/meter/1
[2020-11-12 16:11:36][DEBUG] : Call : http://192.168.15.125/status
[2020-11-12 16:11:36][DEBUG] : Call : http://192.168.15.125/meter/0
[2020-11-12 16:11:36][DEBUG] : Call : http://192.168.15.125/meter/1
[2020-11-12 16:11:41][DEBUG] : Call : http://192.168.15.125/roller/0?go=close
[2020-11-12 16:11:41][DEBUG] : Call : http://192.168.15.125/status
[2020-11-12 16:11:41][DEBUG] : Call : http://192.168.15.125/meter/0
[2020-11-12 16:11:41][DEBUG] : Call : http://192.168.15.125/meter/1
[2020-11-12 16:11:42][DEBUG] : Call : http://192.168.15.125/roller/0?go=stop
[2020-11-12 16:11:42][DEBUG] : Call : http://192.168.15.125/status
[2020-11-12 16:11:43][DEBUG] : Call : http://192.168.15.125/meter/0
[2020-11-12 16:11:43][DEBUG] : Call : http://192.168.15.125/meter/1

Avec

[2020-11-12 16:12:41][DEBUG] : Loading cmd for type : shelly2-roller on Ecran projection
[2020-11-12 16:12:41][DEBUG] : Call : http://192.168.15.125/status
[2020-11-12 16:12:51][DEBUG] : Call : http://192.168.15.125/status
[2020-11-12 16:12:53][DEBUG] : Call : http://192.168.15.125/roller/0?go=close
[2020-11-12 16:12:53][DEBUG] : Call : http://192.168.15.125/status
[2020-11-12 16:12:55][DEBUG] : Call : http://192.168.15.125/roller/0?go=stop
[2020-11-12 16:12:55][DEBUG] : Call : http://192.168.15.125/status

Les URL créées dans des Shelly i3 ou 1, sont via un port 8122. Ce port est fermé sur mon Jeedom.

root@xxxxxxx:~# netstat -anp | grep 8122
root@xxxxxxx:~#

En complément, une capture réseau :

Sans restriction : je vois bien la position du volet quand je clique sur refresh dans Jeedom

Avec restriction : il n’y a pas la présence du login/pass dans le get status (je ne sais pas si c’est normal)

Du coup le retour est en erreur 401

1 « J'aime »

Après analyse, j’ai fini par comprendre et trouver le problème sur le retour d’état lors d’un refresh quand y a les restrictions.

L’ajout des restrictions active l’envoi de l’header dans la requête curl.
Sauf que dans le retour, le header sera présent également et c’est là que ça pose problème pour le json_decode ensuite.

Exemple sans restriction (donc sans header), le json reçu par curl est bien « déchiffré » dans le json_decode :

Exemple avec restriction (donc rajout des header nécessaires), vu qu’il y a le header avant le json reçu par curl, ce dernier ne sera pas « déchiffré » dans le json_decode : :

Dans /var/www/html/plugins/shelly/core/class/shelly.class.php, j’ai fais la modification suivante pour retirer la partie header de la réponse :
Avant

Après :

La commande rajoutée dans le if créé : $data = substr($data, curl_getinfo($ch, CURLINFO_HEADER_SIZE));

Le retour est à présent correct, sans header, et bien « déchiffré » dans le json_decode :

Attention pour ceux qui souhait modifier si vous n’êtes pas sûr de ce que vous faites.

NOTA : Ce refresh pour le retour d’état est fait via un cron toutes les minutes, ce n’est donc pas de l’instantané. Pour ça il faut modifier manuellement la partie action dans les shelly.

5 « J'aime »

Merci, là y a bien un bug sauf qu’il est là depuis le début du plugin Shelly.
Surtout c’est pas juste le refresh qu’il bloque mais aussi le setting du wbehook.

Ce qui veut dire que ceux qui ont des URL avec 8122 de visible mais un user password, ce user password a été ajouté post création dans jeedom. Le load des webhook utilisant le contenu de status, avec authentification il était vide.
Donc ca marchait avant la cette mise à jour pour ceux qui avait créer l’équipement sans mot de passe mais pas via le cron. Du coup certaines infos ne devaient jamais remontées (toutes ne sont pas en webhook)

1 « J'aime »

Sans rancune :slight_smile:

Les webhook sont bien chargé de mon côté maintenant que le GET status est ok via ta fonction loadWebhook. Tout est redevenue dans l’ordre (pour mon i3, Shelly 1 et mes deux 2.5 en mode volet).

(Petite suggestion sur les 2.5 en mode volet, dans la partie action pour OPEN, STOP and CLOSE, le plugin ne met rien, mais sur ces trois, j’ai manuellement ajouté la requête API (de Jeedom, pas de Shelly) qui reprend simplement la commande « refresh » du module, comme ça si j’actionne l’interrupteur physique ou via l’appli Shelly, ça renverra la position sans attendre le cron)

1 « J'aime »

Avec la nouveauté en beta que t’as vu, je me doute qu’on va me demander plus de retour. C’est vrai que le refresh est assez générique.
Par contre à confirmer, mais j’ai l’impression que les shelly ont par contre un peu de mal à suivre l’enchainement d’ordres de jeedom lors de la conf. Les uni et i3 par exemple qui prend 15 appels de webhook de suite, souvent il ne répond plus au bout de X.

Pour le i3 c’est effectivement assez long, mais ça a marché au bout de deux enregistrement pour bien tout avoir. La lenteur est bien au niveau du Shelly, pas du plugin.

Depuis la mise à jour, le retour d’état ne se fait pas immédiatement sur mes shelly, il ne se fait que toutes les minutes via le cron.

Les urls dans les actions shelly ne sont pas renseignées automatiquement, ni à la mise à jour du plugin ni à la sauvegarde des équipements.

Ci-dessous le log après une sauvegarde d’un équipement :

[2020-11-16 13:11:49][DEBUG] : Loading cmd for type : shelly1 on Lumière salon
[2020-11-16 13:11:49][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/status
[2020-11-16 13:11:49][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/relay/0?out_on_url=http%3A%2F%2F192.168.1.[IP_de_Jeedom]%2Fplugins%2Fshelly%2Fcore%2Fapi%2FjeeShelly.php%3Fapikey%3D[ma_cle_API]%26id%3D87%26relay%3D0%26value%3Dout_on_url
[2020-11-16 13:11:49][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/relay/0?out_off_url=http%3A%2F%2F192.168.1.[IP_de_Jeedom]%2Fplugins%2Fshelly%2Fcore%2Fapi%2FjeeShelly.php%3Fapikey%3D[ma_cle_API]%26id%3D87%26relay%3D0%26value%3Dout_off_url
[2020-11-16 13:11:49][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/relay/0
[2020-11-16 13:11:49][DEBUG] : Button : Array (     [name] =>      [ison] =>      [has_timer] =>      [default_state] => off     [btn_type] => momentary     [btn_reverse] => 1     [auto_on] => 0     [auto_off] => 0     [power] => 0     [btn_on_url] => http://192.168.1.[IP_de_Jeedom]/plugins/shelly/core/api/jeeShelly.php?apikey=[ma_cle_API]&id=87&input=0&value=1     [btn_off_url] => http://192.168.1.[IP_de_Jeedom]/plugins/shelly/core/api/jeeShelly.php?apikey=[ma_cle_API]&id=87&input=0&value=0     [out_on_url] => http://192.168.1.[IP_de_Jeedom]/plugins/shelly/core/api/jeeShelly.php?apikey=[ma_cle_API]&id=87&relay=0&value=out_on_url     [out_off_url] => http://192.168.1.[IP_de_Jeedom]/plugins/shelly/core/api/jeeShelly.php?apikey=[ma_cle_API]&id=87&relay=0&value=out_off_url     [longpush_url] => http://192.168.1.[IP_de_Jeedom]/plugins/shelly/core/api/jeeShelly.php?apikey=[ma_cle_API]&id=87&relay=0&value=longpush_url     [shortpush_url] => http://192.168.1.[IP_de_Jeedom]/plugins/shelly/core/api/jeeShelly.php?apikey=[ma_cle_API]&id=87&relay=0&value=shortpush_url     [schedule] =>      [schedule_rules] => Array         (         )  )
[2020-11-16 13:11:49][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/relay/0?longpush_url=http%3A%2F%2F192.168.1.[IP_de_Jeedom]%2Fplugins%2Fshelly%2Fcore%2Fapi%2FjeeShelly.php%3Fapikey%3D[ma_cle_API]%26id%3D87%26relay%3D0%26value%3Dlongpush_url
[2020-11-16 13:11:49][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/relay/0?shortpush_url=http%3A%2F%2F192.168.1.[IP_de_Jeedom]%2Fplugins%2Fshelly%2Fcore%2Fapi%2FjeeShelly.php%3Fapikey%3D[ma_cle_API]%26id%3D87%26relay%3D0%26value%3Dshortpush_url
[2020-11-16 13:11:49][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/input/0
[2020-11-16 13:11:50][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/input/0?btn_on_url=http%3A%2F%2F192.168.1.[IP_de_Jeedom]%2Fplugins%2Fshelly%2Fcore%2Fapi%2FjeeShelly.php%3Fapikey%3D[ma_cle_API]%26id%3D87%26input%3D0%26value%3D1
[2020-11-16 13:11:50][DEBUG] : Call : http://192.168.1.[IP_du_Shelly]/settings/input/0?btn_off_url=http%3A%2F%2F192.168.1.[IP_de_Jeedom]%2Fplugins%2Fshelly%2Fcore%2Fapi%2FjeeShelly.php%3Fapikey%3D[ma_cle_API]%26id%3D87%26input%3D0%26value%3D0

Et la partie réseau de mon jeedom, les ip et url sont bonnes :

Le firmware des shelly est à jour, ce sont des Shelly 1 :

Current version: 20200827-065344/v1.8.3@4a8bc427
You have latest version of your device! 

Ainsi que le plugin Shelly :

2020-10-09 01:01:33

Dites moi si il y a besoin de plus d’info.

J’ai réussi à faire marcher mes shelly malgré tout en prenant les url dans le log, en les décodant avec https://www.urldecoder.org/ et en les copiant manuellement dans les actions des shelly, mais j’aimerai bien trouver la raison quand même pour les prochains shelly que j’ajouterai.

C est moi le retour d’état à toujour mie plus ou moins 1 minutes, je pensais que c’était normal.

Non, car quand tu contrôles une lumière avec le shelly par exemple tu ne peux pas avoir une minute de délai entre l’appui sur l’interrupteur et l’allumage de la lumière.