Les plugins qui viennent de l’exterieur, comme alexa, app mobile, jeemate etc ils fonctionnent ? si tu demande qql chose à alexa, ouvre l’app sur ton mobile, etc ? Pas de log d’erreur au moment où tu le fais ?
Je suis repassé en 4.1.28 et tout à l’air de fonctionner normalement (ca obéit et pas d’erreur). C’était lorsque j’étais passé en 4.2 que j’avais eu mes logs d’erreurs… (et des tests fait sur les plugins tout fonctionnait aussi ; le fait ensuite de désactiver tous les plugins n’a pas évité les logs d’erreur).
Donc tu ne sais pas d’où sa vient et tu aura le même problème dès que tu voudra updater 
Bonjour,
Je confirme: depuis la mise a jour en 4.2.7 sur mes scenarios IFTTT , impossible de faire des webhooks depuis IFTTT.
Voici le message que je reçois:
2022-02-02 11:20:43 jeeEvent → Vous n’êtes pas autorisé à effectuer cette action, IP : 92.148.214.99
idem ici et pourtant j’utilise bien la clef api du plugin iftt et non celle du core…
ça marchait bien avant la mise à jour et subitement plus rien ne passe
je me réponds à moi même, ça peut servir aux autres: utiliser la bonne clé ne suffit pas: après la clé il faut utiliser
&plugin=ifttt&type=event&id=
je viens de reprendre une bonne dizaine de requêtes et je ne suis pas très heureux de découvrir ça comme ça sans avertissement préalable à la mise à jour. Surtout que certaines sont liées à mon alarme!!!
Est on certain au moins que les autres interactions iftt ne passant pas par du webhook vont continuer à bien fonctionner?
Bonjour,
Dans le changelog :
En api http vous pouviez indiquer un nom de plugin en type, ce n’est plus possible. Le type correspondant au type de la demande (scenario, eqLogic, cmd, etc.) doit correspondre au plugin. Par exemple pour le plugin virtuel vous aviez type=virtual dans l’url il faut maintenant remplacer par plugin=virtual&type=event
Dans le blog :
1 « J'aime »
Oui c’est bien ça, heureusement que le forum est là pour nous mettre sur la voie.
Car pour être honnête qui lit tous les change logs avant les maj et surtout qui pense aux implications sur tous les différents plugins?
Du coup c’est pas sans « avertissement préalable » en toute objectivité.
Pour ma part je lis les changelogs mais j’ai des réflexes de vieux sûrement 
après il est vrai qu’il faut comprendre leur portée ce qui, et je m’inclus dedans, est parfois loin d’être évident. Mais on ne peut nier que Jeedom a cette fois essayé de vulgariser les changements majeurs.
Autant pour moi → c’est vrai il faut lire les changelogs et en plus il faut les comprendre, ce qui n’était pas mon cas.
Maintenant c’est OK pour moi.
MERCI à tout le monde
Bonjour @ericc , heureux de voir que tu as pu résoudre ton soucis. Perso j’ai fait une restauration car je n’arrivais pas à savoir techniquement ce qu’il faut faire (l’article sur le blog est trop évasif/théorique pour moi qui suis newbie) : idéalement un lien vers un post/article décrivant pas à pas les étapes à suivre pour migrer sans error-logs. D’avance grand merci pour vos conseils ! H
Bonjour,
J’ai essaye la manip proposee: plugin=ifttt&type=event, API ifttt… je n’ai plus le message erreur jeevent, en revanche les requetes ifttt ne marchent plus.
est ce qu’il y a une autre manip a faire?
et de plus, j’ai recree des nouveaux equipements ifttt, dans l’exemple de url a utiliser que Jeedom indique automatiquement:
https://------jeedom.link/core/api/jeeApi.php?api=--------&type=ifttt&id=#ID_CMD#&value=#VALEUR#
donc la correction ifttt&type=event n’a pas ete faite meme dans le plugin. Donc les anciens equipements ainsi que les nouveaux sont incorrects.
pas terrible la release4.2 !!! qu’il faille faire des modifs, ca peut s’entendre mais que les plugins ne donnent plus les bonnes info, ni la doc, ca craint.
Bonjour,
Je pense qu’il ne faut pas être trop critique envers JEEDOM.
D’abord la version 4.2 est très bien et apporte de vrais changements.
Ensuite ils ont vraiment essayer de nous expliquer les différents changements qui allaient intervenir, et ce à quoi il fallait faire attention.
Je suis comme beaucoup je n’ai pas trop fait attention et j’ai eu quelques soucis.
Mais en fin de compte ça fonctionne bien. IL SUFFISAIT DE BIEN LIRE LES CHANGELOGS.
MERCI à toute l’équipe jeedom
1 « J'aime »
Bonjour à tous,
J’ai la même erreur JeeEvent qui dans mon cas renvoie vers l’IP de mon RPI (celui qui héberge Jeedom).
Mais je n’arrive pas à identifier quelle commande génère cette erreur.
Il y’a t il un moyen de le faire ?
Merci,
Cyril
Pareil que toi, j’utilise ces plugins :
Agenda
Alarme
AndroidTV
AsusWRT
AutoLogin
BLA
Boîte à lettres
Caméra
Détection de téléphone (BT)
Enedis
Gestion Humidité
Google Cast
GSH
Harmony Hub
HTML Display
iCalendar
IFTTT (fonctionne bien ça vient pas de là)
Jeedom Connect
Jeeloc
JeeXplorer
jMQTT
Ewejee
Mail
mode
monitoring
Network
onduleur (nut)
OpenVPN
openwrt
Philips Hue
Phone Market
PiHole
Script
Simulation présence
SmartThings
SSH Commander
Suivre un colis
Switchbot
Thermostat
Virtuel
Weather
WiFilight V2
Xiaomi Home
Zigbee
Et j’ai régulièrement des « jeeEvent Vous n’êtes pas autorisé à effectuer cette action, IP : 192.168.1.XXX » (adresse du RPI qui héberge Jeedom), sans actions spécifiques de ma part ni (a priori) de scénario qui s’exécute
Bonjour @Drakal et @cyrstr ! Je viens de rebasculer en 472 et maintenant j’ai maintenant seulement 4 logs errors toutes les 5 minutes (alors qu’avant j’en avais 5). J’ai l’impression que la seule différence entre mon premier upgrade et le second est la mise à jour du plugin « virtual ».
Ce qu’il y a d’étrange c’est que j’ai l’impression que tout fonctionne correctement… sans dégradation aucune.
…et vous vous avez combien de logs errors et tous les combien de temps ?
Moi c’est assez aléatoire j’ai l’impression
Bonjour @ericc ,
Désolé si je lance de l’huile sur le feu, ca n’est pas mon intention. Mais je voudrais juste faire un peu de prévention.
Une gestion d’alarme via la domotique est une chose à mettre en place en connaissance de cause. Le mieux dans le cas contraire étant de bien séparer les 2, et de ne pas rendre l’un dépendant de l’autre.
Par contre, coupler les 2 via un service internet comme IFTT n’est PAS une bonne idée du tout.
Le jour ou IFTT change d’aPI, que votre alarme n’est plus compatible, ou simplement le jour ou internet tombe, vous n’avez plus d’alarme a la maison? Sérieusement?
Car pour être honnête qui lit tous les change logs avant les maj
Celui qui utilise jeedom pour la gestion de la sécurité de sa maison (ou simplement la gestion des ouvertures) ?
Blague à part, on ne peux pas d’un coté gérer la sécurité de sa maison et de l’autre faire les mises à jours sans attendre au moins un peu, et sans lire le changelog, non? Ca me semble être un raisonnement manquant un peu de bon sens… Mais ca n’est que mon avis.
Surtout que pour le coup, le change log (et l’article de blog) était clir : les URL changent. Et ca n’est pas jeedom qui a décidé d’utiliser ces URL dans un service tiers comme IFTT, non?
Perso, quand j’ai lu le changelog, je savais exactement ou ca allait ne plus fonctionner chez moi. Et du coup, j’ai fait la MAJ un jour ou j’avais le temps de tester ces appels d’url externes, et avec une solution pour revenir en arriere.
Bref, désolé pour le coup de gueule, mais je ne pense pas qu’il soit très productif (ni sympa ) de taper sur l’équipe jeedom …
Amicalement,
3 « J'aime »
Certe mais tout le monde n’est pas expert pour déterminer ce qu’il va lui arriver rien qu’en lisant le change log.
Donc, il y a t il une façon de savoir quel est la commande à l’origine du message d’erreur ?
Merci
1 « J'aime »