nigao

Coucou la communauté, J'ai récemment eu des soucis de rats et j'ai eu besoin de détecter leur lieu exact de passage afin d'optimiser la pose de piège. J'ai chercher un moment comment faire à moindre cout pour optimiser la psoe du piège et j'ai eu l'idée d'utiliser le FGMS pour le transformer en détecteur de mouvement mais au niveau du sol ou sous un meuble de la cave par exemple. J'ai modéliser en 3D un support que j'ai grandement évider pour économiser de la matière. Résultat : 3 FGMS pour quadriller une pièce m'ont permis de déterminer le lieu de passage préféré Maintenant j'en ai un qui reste à demeure dans un piège avec tapette + appat olfactif qui m'alerte si j'en chope un... et qu'il faut aller enlever le cadavre Je le propose à la communauté en libre accès si ça peut servir à certains Fichier STL : https://www.dropbox.com/s/zyyzl9n57kkrt8e/porte_fgms.stl?dl=0

je dois en avoir 7 qui dorment dans un placard... mon pire investissement fibaro

Le deuxième compte marche bien comme solution ^^ Sinon pour ceux qui ont la double authentification, il faut partir dans https://myaccount.google.com/security Et de choisir "mot de passe d'application"... Ca vous permet de créer un mot de passe spécifique (sans double authentification) ; (attention ne fonctionnera pas si on n'est pas sur une connexion sécurisée). From google :

la commande api.post transmet les requests headers ? Habitant sous les tropiques j'ai pas du tout ce genre de matériel dans ma box ^^ donc je fais que passer par là. ---- Sinon j'utilise souvent postman pour tester mes requêtes HTTP avant de me lancer dans du code, histoire de savoir si tout se passe bien ou pas. https://www.getpostman.com/product/api-client

local selfhttp = net.HTTPClient({timeout=2000}) local tkn = "xxxxxxx" local usr = "yyyyyyy" local msg = fibaro:getGlobalValue("pushoverBody") local requestBody = 'token=' .. tkn .. '&user=' ..usr .. msg; print(requestBody); selfhttp:request('https://api.pushover.net/1/messages.json', { options = { headers = selfhttp.controlHeaders, data = requestBody, method ='POST', timeout =5000 }, success = function(status) local result = json.decode(status.data); print("status"); if result.status == 1 then print("successful"); print("Request: " .. result.request); else print("failed"); print(status.data); end end, error = function(error) print"ERROR" print(error) end }) Mon code pour pushover

Personnellement j'interroge 3 fois de suite le wallplug, et la HC2 le pose en dead si elle reçoit pas les infos à la 3eme fois.

https://www.igen.fr/domotique/2019/05/google-le-nest-hub-en-france-et-le-nest-hub-max-aux-etats-unis-107754 Pour aller dans le sens de Lazer, j'ai regardé la retramsmission live du google I/O mardi soir qui le présentait, je reste toujours avec ma HC2 ou je peux faire ce que je veux ^^ Car ce que j'adore avec la HC2, c'est le côté ' notre seul frein c'est notre imagination'. On a des capteurs en input que veux t'on en output sans être figé dans ce qui a été décidé comme usage ?

Coucou, effectivement les wallplug passent en dead device et c'est donc détectable via scene/vd. J'utilise cet attribut dans un autre VD pour détecter les zones où un fusible disjoncte chez moi VS coupure totale de courant. (avec une icone de compteur electrique vert / orange / rouge en fonction de état du courant) Sauf rare exception, on conserve internet malgré la coupure électrique, ma HC2 étant ondulée, elle me notifie quand même ; sans besoin d'une carte SIM pour les notifs. J'ai deux fusible assez capricieux pour lesquels je ne parviens pas à isoler la source qui fait sauter le courant de façon aléatoire. Chaque secteur de la maison, a au moins 1 wallplug et j'envoie régulièrement les statuts sur un googlesheet qui me fait un pseudo zoning. Ainsi quand je suis en déplacement et que le courant saute (un WallPlug est dead), je peux juger de l'importance de rentrer réarmer ou pas (zone avec congélo ou zone sans importance directe). Si toute la maison est rouge, alors de forte chance que ce soit une coupure électrique générale et pas un seul de mes fusibles capricieux Ps : nos posts se sont croisés avec jojo, effectivement moi j'ai un temps de latence de 3mn pour détecter un wallplug mort. (je pourrais réduire ce temps, mais j'ai pas envie de saturer mon réseau zwave a poll non stop les wallplug) Ps2 : pour détecter les fusibles liés aux lumières et pas aux prises électriques, je fais également des polls des ampoules zwave. mais les tests peuvent être faussés si un invité switch off un interrupteur de lumière par non habitude de la domotique) Ps3 : a l'époque j'avais commandé une pince ampèremétrique zwave pour la poser directement sur le compteur pour détecter la coupure générale, mais on m'a livré du triphasé ... et vu la galère de se faire livrer par chez moi, j'ai abandonné l'idée aux profits de wallplug qui sont plus polyvalent avec de l'imagination (test onduleurs, test fusible, compteur photo etc etc... je love les wallplug). J'espère que les prises zwave de la nouvelle gamme Walli seront aussi polyvalentes, pour que l'intégration soit encore plus invisible et waf.

Heureux que dans cette confusion de genre, tu y trouves tout de même une réponse ^^

Suggestion bête, ne sachant pas exactement ce que tu veux remonter comme info ; tu mets un WallPlug avant ton onduleur, au moins tu connais - sa consommation en temps normal - tu peux détecter les phases de coupure de courant - tu peux detecter la consommation en recharge après coupure de courant -------- J'ai pseudo bricoler un truc equivalent pour un autre besoin (pas parfait mais ça fait le job) Je voulais avoir un compteur de déclenchement de photos au studio (le tout connecté à un compteur live sur mon site web). J'avais y a longtemps de cela pensé à un FGMS pour capter les variations d'intensité lumineuse mais le module étant à pile + pas assez sensible pour des flash répétés ; j'ai décidé de me baser sur la consommation électrique des flash. Ce qui donne WallPlug -> Onduleur -> Torche Flash - je détecte les phases où l'onduleur est sous tension mais flash éteints (env. 8watts) - je détecte les phases où les flash sont allumés mais pas déclenchés (env. 22 watts) - je détecte les déclenchements photos (variation entre 200w et 800w) - je détecte les coupure de courant (WallPlug n'est plus joignable) - je détecte la reprise de courant où la conso est farfelue (genre 120w constant pendant 1h >>> onduleur en recharge après coupure) - j'ai également les relevés de consommation totale dans la HC2 - en bonus je tamise les lumières quand un shooting photo commence (>200w) et je restaure l'ambiance lumineuse si ca fait plus de 60s qu'on est <200w -- Edit et accessoirement encore j'utilise ce système pour des tests onduleurs mensuels. Meme principe mais cette fois dans le bureau Wall Plug -> Onduleur -> Ordis Une fois par mois -- je ping un des appareils derrière onduleur pour voir s'il est en ligne (un lametric qui est tjrs allumé comparé à ordi ; mais ça marche aussi avec le NAS) ---- Si appareil en ligne, notification PUSH qu'un test onduleur aura lieu dans 30mn (histoire de pas être pris au dépourvu) 30mn après la notification, ultime vérification que le ping est toujours ok (appareil bien en ligne donc) Puis je passe le wallplug à OFF pendant 10mn pour forcer le passage de l'onduleur sur batterie Et à partir de la; à intervalle régulier je ping le même appareil pour tester s'il demeure en ligne ------ Si appareil ne répond plus aux ping durant le test Annulation du test, retour du wallplug sur ON, envoi d'une notification que l'onduleur à pas tenu 10minutes ------ Si appareil répond aux ping pendant 10mn retour du wallplug sur ON et envoi d'une notification test concluant J'ai mis ça au point car comme pour les backups, c'est bien beau d'en avoir mais si on sait pas les restaurer c'est inutile. Avant j'avais un onduleur, je faisais jamais de test, et c'est lorsqu'il s'est mis à ne plus tenir la charge après une coupure que je me suis rendu compte qu'il était déjà trop tard. Ps : certains onduleur ont le paramètre dans l'appli qui va bien pour faire des tests mensuels sans tout ce process, sauf quand tu as des Mac et que l'appli n'existe que sous Windows, faut trouver des alternatives ^^)

Alors je préfère citer directement ce message de tcheri qui a eu 4 ans d'avance sur moi ^^ On a fait quasiment la meme chose (jusqu'au choix du nom de la VG ^^) La différence c'est que j'ai enlever le print dans le debug (je n'utilise plus pour faire des copier/coller) et j'ai aussi désactivé les commentaires (ID généres le // usage) dans la variable result afin de ne pas les encoder en json. Tcheri a rajouter une variable 'resultVar' qu'il JSON.encode par la suite pour ne pas altérer le code principal. Je vous envoi donc vers sa version qui elle converse le print et la notice d'usage, qui est plus user friendly donc.

Fredric je pense qu'on trouvera aucun terrain d'entente ayant chacun un parti pris ^^ Le système semble te (vous) convenir ; je peux l'admettre ^^ mais je reste navré que en dehors de toute sémantique c'est total pourri comparé à un push android ou le Yes / No est clairement visible sans manipulation... '?' ou pas, sur iOS, si tu as foiré ton clic, c'est foutu

Personnelement, je trouve pas ça très user friendly pour différencier un push classique (celui du haut) d'un push interactif (celui du bas) .... on peut discuter sémantique, point d'interrogation, tournure de phrase à l'interrogatif, mais pour moi ça n'enlève rien au fait que le côté UX de la chose sur iOS cest pas waf. Sachant que si je me loupe, et que je fais un appui simple sur le push interactif... ca ouvre l'appli fibaro et il ne se passe rien... et la notification disparait je peux donc plus revenir en arrière répondre oui/non (cf video : https://www.dropbox.com/s/cu9ahkdpt9ezybp/ScreenRecording_03-09-2019 16-28-23.MP4?dl=0

Ca y est j'ai fais ma modif ^^ je pense qu'a long terme c'est le truc qui me fera encore plus apprécier cet IDgenerator qui est déjà indispensable. Toutes les 24h il autoupdate la variable globale now Et je réalise en remontant les vieilles pages que c'est une demande de epoque et qu'elle avait déjà était réalisée par tcheri* Au moins ca remontera le sujet hihihi

Je réactive ce sujet car ce script me sauve souvent la vie pour gérer les ID (merci merci steven). Par contre avec le temps je réalise que c'est galère quand tu l'a utilisé dans tous tes scripts/VD de maintenir à jour les array. Pensez-vous qu'il serait possible (judicieux) de faire un Json encode du tableau et de le stocker dans une variable globale qui s'autoupdate a intervalle régulier ? Ainsi >>> json decode la variable globale >> et on a tous les VD device qui ont les ID à jour Bon dans mon cas ca fait un paquet de script à update mais je me dis que sur le long terme j'aurais plus à rien revenir