jjacques68

nan chez moi la ram semble OK, moyenne a 35 %. Je viens de me rendre compte qu’une scène avec dans l’entête %%killOtherInstances faisait monter la charge CPU !!! (qui était appelée par moment avec des répétitions très très soutenues) Je viens de remettre le bon vieux if fibaro:countScenes() > 1 then fibaro:abort() et depuis j’ai l’impression que ça va mieux. à suivre...

Hello tout le monde !! vous avez déjà eut ce genre de cas ?

alors moi je viens de la faire... etrange... bloquée sur start service, comme ont n’a pu l’entendre sur le topic. je l’ai éteinte puis rallumer. Au redémarrage, tous les volets se sont fermés et les lumières allumées. son réglage de l’heure était au 01/01/2010 à 01:00 ! j’ai modifié en sélectionnant mise à jour de l’heure par le net. Elle a redémarré et puis ça semble ok. j’avais jamais eut de problème jusqu’à cette mise à jour... je viens de faire un backup local. Suis entrain d’en faire un sur le cloud. Après je récupère la sauvegarde local, dans un rep de mon NAS.. a suivre...

Re-bonjours à tous ! Je reviens avec mon histoire de socket pour transmettre des infos... Rapide descriptif du sujet : ça fonctionne très bien, mais le problème maintenant est que la scène appelée à diverse endroit (et y en a beaucoup) peut être appelée très très souvent voir quasi simultanément. Alors j'ai mis le nombre d'instance de cette scène au max (10). Je n'ai pas encore eut de message d'erreur du style "to many instances"... Mais je me rends compte que j'ai des loupés, voir des doublons d'info, quand la scène est appelée plusieurs fois simultanément. J'ai bien essayé de temporiser la scène en fonction du nombre d'instances avec ça : Nb_Instance = fibaro:countScenes() if Nb_Instance > 1 then fibaro:sleep(Nb_Instance*250) end En espérant que chaque nouvel envoi serait retardé pour laisser le précédent se terminer, mais cela ne change absolument rien. J'ai l'impression aussi que les arguments ne sont pas toujours pris en compte, dans des appels simultanés... Comme si le nouvel appel de la scène écrasait les arguments de l'appel précédent... Vous avez déjà connu ce cas ? une idée pour faire cela propre ? Merciiiiii !

tu fais bien : local IdPhone = fibaro:getGlobal("Ma_Variable") ... fibaro:call(tonumber(IdPhone), "sendPush", "bla bla bla") moi j’ai ça partout et j’ai aucun soucis...

Bonjour à tous, J'utilise depuis quelques jours un VD qui m'envoie des infos sur une socket vers un soft réalisé sous Windev... le code dans le VD est ultra simple : local udpSocket = Net.FUdpSocket() udpSocket:write("blablabla",ip,port) Mais à mon grand étonnement, comme pour les requettes HTTP, tous les caractères spéciaux sont encodé en "chinois"... On avait le même soucis avec le google home, on avait fait une super fonction qui convertit les caractère spéciaux comme il se devait, function ReplaceChar(s) local Char = { -- 3 caractères à détecter {" ' ", "'"}, -- 2 caractères à détecter {"é", "é"}, {"à©", "é"}, {"è", "è"}, {"à¨","è"}, {"î", "î"}, {"ô", "ô"}, {"û", "û"}, {"ù", "ù"}, {"ê", "ê"}, {"â","â"}, --1 caractère à détecter {"Ã", "à"}, } for i,v in pairs(Char) do s = string.gsub(s, v[1], v[2]) end return s end Mais là cette fonction n'est pas utilisable car on dirait que les caractères sont codés différemment... exemple : à = à° =  é = é Y aurait pas une solution pour ne plus avoir ce genre de soucis ??? c'est franchement pénible !

ça c'est cool !!! merci !

Nan chez moi c’est tout ok maintenant ! Envoyé de mon iPhone en utilisant Tapatalk Pro

Ma scène reçoit des arguments... du coup j’envoie ces arguments dans un label de mon VD pour les envoyer sur la socket... C’est un peu lourd comme procédé... Je pourrai directement envoyer les arguments dans le VD au lieu de passer par la scène, mais j’avais conçu le système comme ça avant... Et j’ai pas envie de me taper tous les scripts un par un pour corriger cela... Envoyé de mon iPhone en utilisant Tapatalk Pro

Hello tout le monde !!! Petite question qui est dans le titre, est ce qu'on peut écrire sur une socket depuis une scène ?? Depuis un VD avec Net.FUdpSocket() c'est ok ! mais depuis une scène ??????? Merci à vous !

Ah ouiiiii !! Bien joué !!! Ça a fonctionné !! Envoyé de mon iPhone en utilisant Tapatalk Pro

j’espere qu’ils vont corriger ça vite fait !!!!

super, idem pour moi

oui je confirme aussi ce que dit @Nico, je dois attendre le réveil des têtes pour que la consigne de la centrale prenne effet. (réglé à 10 min).

Ha cette fameuse couche... elle nous en fait voir... Envoyé de mon iPhone en utilisant Tapatalk Pro

autre question, lors de la création des règles dans le parefeu du routeur, faut-il toujours ajouter 2 routes ? dans les 2 sens ? pour les même équipements ? Hôplà, maintenant au dôdô encore merci !

@Lazer, @Dgille, @Nico, @minos (j'espère ne pas avoir oublié qqun) : MERCI !!! Maintenant j'ai plus qu'a faire mes règles de routage inter VLAN car la c'est open bar Et faire le tour des PC pour débloquer le parefeu de l'antivirus. Mais 2 questions encore : - pourquoi dois je obligatoirement mettre le VLAN 3 comme vlan par défaut sur le port 3 ? (sinon je reçois même pas d'IP) Normalement les paramètres définit dans le vlan (association des ports) devrait suffir nan ? et @Lazer, sur le switch (qui ne semble pas poser problème), dois je Tagger le port 27 pour le VLAN 1 ? Encore merci les gars !!!

yes 1 NAS est OK

attend y a encore les NAS qui veulent pas... j'en redémarre un pour vooir

Mais ce que je ne comprends pas c'est que si je mets pas le bon vlan par défaut sur le port 3, le pc de test n'obtient meme plus d'adresse IP ! alors que je ne touchait jamais à ce paramètre avant ! Et si je veux faire passer plusieurs VLAN sur le ce même port ?

yes le reboot de la HC2 fait que je peux aussi la pinger

alors je pense que ça vienne de windows , je viens de faire ça dans l'antivirus : Any incoming ICMP était interdit, je l'ai mis sur autorisé. et ça marche. C'est grave docteur ? d'avoir fait ça ?

punaise je trouve pas où c'est

minute je pige pas. pas sû que ce soit QUE l'antivirus. parce que si j'active le pare feu windows sur les réseau public, ça bloque aussi !

c'est kapsersky le fautif !!!