jjacques68

au hasard, si tu fais un : self:debug(response.data.state.any_on) dans le success de ta requete ça donne quoi ? en fait il faudrait que tu postes le debug complet de "response.data", pour voir... PS : utilise l'éditeur du code du fofo (bouton </>) pour poster des lignes de codes, c'est plus lisible

hmm j'ai pas de HUE, je peux pas t'aider sur ce cas... Mais pour envoyer des requête http depuis un QA : https://manuals.fibaro.com/home-center-3-quick-apps/ Tu trouveras ton bonheur ici, mais faut fouiller...

si ça peut aider :

ok j'ai compris. vais mettre cette sécurité dans mes QA. merci !!

petite question : on a souvent une fonction pour créer les child dans le parent. Comment peut-on faire, si on re-exécuté cette fonction, pour ne pas qu'il recrée les child déjà créé ? il faut checker les child existant et comparer le nom ? ou y a un autre moyen ?

oh punaise ça c'est la top classe (sans jeux de mots) ce petit tuto. Faudrait pas le perdre ! merci !

complètement d'accord.

ma première version était par requête http, pour le pilotage et le retour d'état. Y avait pas encore la notion de Parent/Child à ce moment là. Je rencontrais des problèmes étranges lors ce que je pilotais plusieurs sorties simultanément avec la commande fibaro:call({id1, id2, id3}, "turnOn") une fois sur deux, j'avais id2 qui n'était pas pris en compte. je devais séparer en 3 appels, intercallant une tempo( setTimeout) pour que les 3 s'allument. Je sais pas pourquoi, c'est comme si l'IPX, n'arrivait pas à traiter plusieurs requêtes simultanément. Bref ça m'a saoulé, les Parents/Child sont arrivés, j'ai l'habitude des socket, et voilà. Je ne regrette pas du tout. Le code dans le parent, qui décrypte la trame reçue à chaque changement d'une entrée/sortie/compteur, est peu lourd, surtout que j'ai fais un petit IHM dans le parent pour avoir une visu sur l'état de l'IPX : Mais ça tourne nickel, et plus de soucis. Je peux partager le code avec plaisir, mais pas sur ce topic, je te laisse en ouvrir un... Après ça pas du code grand public

@Lazer, merci pour ces explications plus qu'intéressantes ! Avec ce que tu dis, je pense avoir pas trop mal fait mon QA IPX , du moins la partie Child... Quoique je me rends compte que j'ai pas de child pour le seul compteur que j'utilise... j'envoi la valeur directement dans un autre QA dédié (gestion de l'eau). Après je l'ai réalisé d'une manière, j'ai l'impression, peu commune... mais qui fonctionne à merveille. Le parent discute à 100% en TCP avec l'IPX. L'IPX ne met pas à jour les Child directement par requete push, c'est le parent qui fait ce boulo selon ce qu'il reçoit sur la socket. Et biensur j'utilise les Child partout dans les scènes et autres... désolé @MAM78, je ferme la parenthèse.

là tu parles bien du cas spécifique de @MAM78 ? parce que pour des child "actif", typiquement les child affectés aux sorties d'un IPX par exemple, sont de type "bianrySwitch", donc possèdent bien 2 méthodes "action" ! J'ai un doute, à quoi ressemblerait la requête sans utiliser curl ?

ben oui, tu appelles la méthode "turnOn" de ton Child ! tu as donc une fonction turnOn dans la class du Child ! Il y a quoi dans cette fonction ? ou j'ai pas compris la question... EDIT : Je pense que j'avais pas compris. Du coup je penche vers un soucis de droits d'accès. La commande semble être OK... (ou alors c'est pas la commande turnOn ??) L'équipement qui commande ton Child doit avoir le droit d'accès sur la HC3... RE EDIT : En fait je pense pas que le turnOn fonctionne ... Il apparaît pas dans les actions d'un MotionSensor dans l'API. Si j'étais à ta place, je créerai la méthode trunOn dans la class avec un self:updateProperty("value", true) désolé j'ai pas de quoi tester sous la main...

dans la class donc dans les child, il me semble avec un simple self.id self.name self.type

mouai ça sent un problème de rafraîchissement du navigateur, vidange du cache, un truc dans le genre...

et hop un nokia 6 avec android 7 pour 60 € sur ebay

il reste une possibilité pour automatiser à 100 % le truc, coller une étiquette RFID sur chaque produit mais on commence à être dans la science fiction

mon stocke de module domotique se limite à... 1 wallplug oui mais le faire soi-même c'est toujours mieux pour les DLUO, je vois pas comment les frigos peuvent faire ça, il n'y a rien qui permette de lire ces dates sur les produits ! a moins de les saisir à la main ! A moins de prendre la date d'achat et d'y ajouter la DLUO pompé sur le net pour ce produit. Mais si, comme ça arrive souvent, la date est déjà bien avancé, ça collerait jamais ?!

alors en fait ça marche super bien avec windev... bon pour le moment en tapant les EAN à la main... mais l'api google Custom Search fonctionne à merveille ! je filtre les résultats, sors les infos dont j'ai besoin, et c'est nickel et rapide moins d'une seconde pour avoir le nom du produit et l'image. J'ai dans l'idée de mettre en base de donnée tous les produits alimentaires et non alimentaires des mes armoires, et de gérer le stock. Suis une grosse feignasse, je fais mes courses via les drive. (pas les produits frais évidemment, ceux là viennent d'un producteur local - ça va être une autre histoire ça - surtout qu'il y a pas d'EAN sur les produits frais) donc je fais ça depuis ma tablette, dans le canapé, les doigts de pied en éventail Quand je fais mon panier, ça me fait franchement chi... de lever mes fesses pour aller voir s'il me reste des cotons tiges Avec mon système, un un click j'aurai ce qu'il manque biensûr cela va m'obliger à scanner chaque produit que je rentre et biensûr chaque produit que je sors ! D'où la nécessité d'avoir un système de douchage (sous android, pour pouvoir le programmer avec Windev). Le coup du téléphone me plaît bien, faut que je trouve lequel encore, @Lazer m'a mis sur une piste, qu'il faut que j'explore ... l'idée c'est d'en placer 2 ou 3 aux endroits stratégiques de la maison... après le top du top serait de valider mon panier automatiquement, toujours via les API, mais ça, je crois que je peux rêver... quoique il me semble bien que Amazon le permet... Voilà, je vous vois venir, ... oui, concrètement, ça sert à rien. Non, je trouve pas encore l'intérêt de le relier à notre domotique, les idées viendront peut-être... Mais je me fait juste plaisir. Et ça me permet de me lancer dans la programmation Android, c'est toujours bon à prendre... Peut être même utile professionnellement ...

ben justement, je vais pouvoir tester les perf de Windev Mobile. je vais regarder du côté de nokia... merci !!

mouvais justement, je pense au téléphone. Android pour pouvoir développer avec Windev. tu as une idée de téléphone androïde ? j'ai aucune connaissance, je tourne avec la pomme ... ... ... j'arrive à récupérer les infos via une Api de google. Pas faite pour ça, mais je m'en sortirai.

Maintenant, il me faudrait un terminal pour scanner les produits sous androïde. Les terminal Zébra/Datalogic coûte une blinde, une idée sur des téléphones qui pourraient faire l'affaire ? (dans lesquels je ne mettrerai pas de SIM biensûr) merci d'avance !

Il semble que je pourrais m'en sortir avec l'API Google "Custom Search API". C'est compliqué, mais j'ai essayé et ça semble me retourner les résultats. Au lieu d'avoir juste l'info nécéssaire, j'ai le retour JSON comme si je faisais une recherche classique, à moi de mettre en place des filtres et d'exporter le JSON à ma sauce. Je vais voir...

On parle bien d'un IPX V3 ? pas la version 4 !

c'est gentil merci, si jamais je te dirai... Je suis sûr que ça va fonctionner mais c'est le tarif qui me gêne... c'est un peu "luxueux" pour ce que je souhaiterai faire

je confirme que c'est le couple user:password qui doit être encodé en base64. Concernant le port, j'ai un doute là, je ne l'ai pas précisé, peut-être bien qu'il faut le rajouter derrière l'IP, du style @ip:port... suis désolé pour ce doute. Faut essayer... la variable IpxOutNumber prend juste la valeur de la sortie que tu veux : 1 ou 2 ou ... 8. j'avoue ne pas savoir ce dont tu parles avec la clé API, je ne trouve pas ce paramètre chez moi !? concernant ta dernière question, je rebondis sur le fait que depuis la création ce petit tuto, j'ai complètement changé ma manière de gérer l'IPX. En effet je le pilote maintenant entièrement par socket et non par http. En utilisant la solution des QA Parent/Child. Et le top c'est de justement récupérer automatiquement l'ensemble des valeurs de l'IPX (état des sorties + compteur + entrées) à chaque changement d'état, grâce à la fonction "send data on status change" de l'onglet M2M. c'est un peu plus compliqué à coder, mais fonctionne à la perfection. Il me semble que qqun sur le forum avait poster qqch sur les QA Parent/Child avec l'IPX, mais il me semble que c'était en version 4. PS : j'ai mis à jour mon IPX, je suis en version 3.05.74.

mouai... chez GS1 c'est 89€ l'année et il faut être une entreprise pour adhérer. bien dommage car c'est le genre de truc que je cherche... j'en trouve d'autres, mais pareil, tous payant ! je cherche côté api de google, mais étrangement je trouve rien.