jjacques68

mouai alors la fonction difftime demande des valeur sous forme de timestamp (heure en nombre de secondes) et non de chaine de caractère sous la forme : pour l'une c'est facile : "date_actuelle", tu remplaces par : os.difftime (date_derniere_pluie, os.time()) pour "date_derniere_pluie", ça se complique. Le plus simple aurait été de stocker dans la VG "time_last_rain" la date sous le format nombre entier et non chaine de caractère. est ce que tu peux afficher le code qui rempli la VG "time_last_rain" ??

pourtant os.difftime fonctionne très bien ! je l'utilise souvent ! tu peux poster le code que tu as essayé ?

tu peux modifier les heures pour tester maintenant

alors j'ai pas l'habitue d'utiliser les scènes par bloc, mais je pense que ce que tu veux faire n'est pas possible dans une seule scène... il en faut une qui allume, et une autre qui éteint. Je ne pense pas que les profiles ont un rôle à jouer pour ça... La scène que tu as créé, semble vouloir dire ça : déclenchement si : il est 7:00 ET que le WallPlug est allumé ET qu'il est 17:00 ET que le wallplug soit éteint c'est pas possible ! tu mets le device (WallPlug) que tu souhaites piloter dans les conditions ! alors que c'est l'action ! ensuite, on peut pas être à 7:00 ET à 19:00 en même temps un exemple comme je le comprends : 1ère scène pour allumer : 2ème scène pour éteindre : Tu as donc 2 scènes séparées, que tu peux enregistrer par exemple avec le nom : "allumer bureau" et la seconde : "éteindre bureau" essaye, ça devrait marcher...

je pense que tu as un problème d'authentification. car tu utilises admin:admin !!! l'erreur que tu as vient du fait, je pense, que tu cherches à afficher une erreur "err" alors que cette valeur est une table et non une chaîne de caractères comme le dit ton message d'erreur. et tu verras que tu auras un truc du genre accès interdit...

c'est laquelle la ligne 12 ?

ah zut ! jamais fais gaffe ! quel âne !!! et bien heureusement que je stocke ça dans une VG ! parce que s'il fallait me retaper tous les script... et bien figures toi que ça je l'avais déjà corrigé car, en effet je faisais un envoi de mail sur le téléphone... et biensûr ça marchait pas... mais pour le push si... bref je modifie ça demain

Tien c'est marrant, chez moi je fais les push vers l'ID du téléphone ! et non vers l'ID du user !

ligne 14 c'est la ligne de la fonction error ?$ essaye avec fibaro:debug("Erreur : "..json.encode(err))

Petit complément au sujet du READ : j'ai rencontré quelques effet de bord avec la fonction TCPSocket:read() en effet, j'utilise comme marqueur de fin, dans l'application qui communique avec la socket, le "CR", caract(13). et la HC3, visiblement interprétait mal ce marqueur de fin. c'est à dire qu'elle trouvait la trame, mais j'avais également un "r" qui était interprété comme une 2ème trame !! du coup avec la fonction TCPSocket:readUntil(delimiter) et en lui précisant bien le marqueur de fin : dans mon exemple : "\r", il n'y a plus de soucis. function QuickApp:waitForResponseFunction() self.sock:readUntil("\r", { success = function(data) self:updateView("LBL_Receive", "text", "RECEIVE : "..data) ... ... fibaro.setTimeout(5, function() self:waitForResponseFunction() end) end, error = function(err) QuickApp:warning("READ ERROR - "..err) self:CloseSocket() fibaro.setTimeout(1000, function() self:OpenSocket() end) end }) end

non non pas du tout !! t'inquiète pas !! ça m'intéresse de comprendre un peu plus en profondeur les choses ! Les avis, connaissances, conseils sont toujours bon à prendre...

Comme tu dis, j'ai 1 QA qui envoi les données en base. Et plusieurs autres (enfin 2) qui utilisent justement CE QA. ça fonctionne bien ! (de ce que je constate) Ensuite faut pas oublier que je passe par une variable de type tableau qui me sert de tampon... Mes 2 QA ne font que remplir cette variable tableau. LE QA de gestion de la socket s'occupe juste d'envoyer le contenu de ce tableau ! Je sais pas, y a rien qui me choque ! ça devrait ?? Maintenant côté performance, capabilité de la box, je m'y connais pas assez pour de dire si c'est bon ou pas... A mon niveau, ça à l'air d'allé... pour info : j'ai franchi un autre cap avec les socket, où j'utilise maintenant le READ (toujours dans le même QA de gestion de la socket). en effet depuis mon soft IHM, au lieu d'envoyer les ordres par requête HTTP à la HC3 pour actionner les device, je transmet l'ordre au QA via la socket. Et c'est lui qui fait les actions sur les device. Je sais pas si je me suis fait comprendre... Et bien je trouve que je gagne en réactivité par rapport aux requêtes HTTP. Donc CE QA fait l'envoi et la lecture simultanément, comme des thread... il a l'air d'encaisser Honnêtement c'était pour le fun... Et ça marche super c'est bien. c'est nickel pour comprendre pourquoi tel ou tel truc c'est mal passé. J'ai déjà plus que divisé par 2 les informations stockées en filtrant à la source (sur la HC3).

et bien c'est nickel !!! juste dommage que les caméras ne peuvent pas bouger plus vite... suis déjà au max avec la vitesse... Mais niveau réactivité de la BOX (déclenchement d'une scène par les PIR, envoi de la requete HTTP pour faire bouger la caméra (à travers un QA) ...) , y a rien a dire !!

ça marche nickel ce code !!! merci encore !!!

Je sais pas faudra que j'essaye... après concernant les "Lignes", faut dire aussi, que je récupère par exemple toute les 3 secondes les infos d'un ECO-DEVICE et la nuit quand l'alarme tourne c'est une trame par seconde que je récupère... Sans parlé de l'échange que j'ai entre l'IHM perso et la box.... Tout ça, sont des "lignes" qui ne sont pas de la communication Z-Wave... Pour le moment je ne constate pas latence dans les device Z-Wave... Au contraire, elle est plutôt réactive ! Mais justement, je fais tester en créant un "mode poursuite" avec les caméra. j'avais essayé sur la HC2, ça marchait, mais alors le temps que tu passes d'un PIR à un autre, la camera avait pas encore bougée on verra...

alors avec le status des device, je dépasse les 100 000 lignes en 24 heures !!! c'est dingue comme ça travaille dans cette petite boite ! J'ai mis des filtres en place, sinon j'explose la base. Surtout que certaines infos n'étaient absolument pas utiles... Par contre en analysant les données, y a des trucs étranges... je sais pas si ça vient de ma programmation (sans doute), faut que je regarde de plus près. Par exemple : - des méthodes lancées sans raisons ???? en moyenne toutes les 30 minutes (j'ai aucun souvenir d'avoir programmé ça !!) - lors de l'allumage/extinction d'une lumières (et que les lumières) j'ai une double saisie dans l'historique (mais ce n'est pas visible dans la page "History", que dans l'API). Et j'ai bien 2 ID différent dans l'API pour ce doublon d'informations (ça vient pas de mon système...)

j'y suis parvenu avec panels/event...

Hello ! j'étais intéressé de pouvoir récupérer l'historique de ce qu'il se passe avec nos device. Ce que l'on peut voir dans la page "history". L'objectif final est de sauvegarder tout ça dans une base de données externe à la HC3... bref. donc voici dans un QA la méthode que j'utilise pour récupérer les données de l'API : Le principe est que je cherche toutes les X minutes le contenu. (pour le moment le déclenchement est manuel, il faut que je réfléchisse à l'interval de bouclage...) J'utilise une variable au QA "TimeStart" qui contient le TimeStamp de fin de la dernière recherche. Par précaution, je vérifie que l'interval de recherche ne soit pas supérieur (pour le moment) à 1 h. Si c'est le cas, je force donc à 1 heure max. --------------------------------------------------------------------------------------- -- CHERCHE LES DONNEES --------------------------------------------------------------------------------------- function QuickApp:CheckLogs() local TimeStart = tonumber(self:getVariable("TimeStart")) local TimeEnd = os.time() local http = net.HTTPClient({timeout=3000}) --Pour ne pas récupérer plus de x temps de log (cas d'un plantage, arrêt, autre...) if os.difftime(TimeEnd, TimeStart) > 3600 then TimeStart = TimeEnd - 3600 end print("<<<<<<<<<<<< start : "..os.date("%d/%m/%Y %H:%M:%S", TimeStart).." - end : "..os.date("%d/%m/%Y %H:%M:%S", TimeEnd).." >>>>>>>>>>>>") http:request("http://127.0.0.1:11111/api/panels/event?type=time&from="..TimeStart.."&to="..TimeEnd, { options = { method = "GET" }, success = function(res) Display(res.data) end, error = function(error) print(json.encode(error)) end }) --mémorise l'heure de fin pour qu'elle soit la procaine heure de début self:setVariable("TimeStart", tostring(TimeEnd)) end et voici comment je sors les données avec la fonction Display() : --------------------------------------------------------------------------------------- -- TRAITEMENT DU RESULTAT --------------------------------------------------------------------------------------- local function Display(alldata) --formate le tableau json alldata = json.decode(alldata) --pour chaque élément du tableau for k,v in pairs(alldata) do --chope le nom du device local NameDevice = api.get("/devices/"..v.deviceID).name --créé la trame local Message = v.type.." - "..os.date("%d/%m/%Y %H:%M:%S", v.timestamp).." - "..v.deviceID.." - "..NameDevice.." - "..tostring(v.event.data.newValue) print(Message) end end Pour le moment je ne fait que un print du résultat, mais celui-ci sera envoyé en base de donnée... (pas voulu en parler dans ce sujet). le résultat dans le debug donne ça : on obtient donc, le type d’événement (DEVICE_EVENT), son Timecode, l'ID du device, son nom et pour finir sa valeur. d'autres information son dispo dans l'API, mais pour le moment, celles-ci me suffisent... Je lance actuellement le process manuellement pas un bouton, mais je vais mettre un bouclage par setTimeout en place, afin de le faire boucler régulièrement.

hello tout le monde ! est ce quelqu’un sait comment éteindre le chauffage ? j’ai beau mettre la zone sur "off" elle continue sa programmation !!

nan mais je peux enventuellement mettre des filtres... A voir dans le temps... prochaine étape, l'historique des device....

en fait l'historique est très faible, si on souhaite voir si y a eu des erreurs il y a quelques heures, c'est mort !!! on les retrouve plus !!

alors j'ai fini par y arriver ! mais je comprends pas pourquoi cela ne marche pas : res = api.delete(string.format("/devices/action/%d/%d",timestamp,id)) print(json.encode(res)) ----> réponse : nil mais ça c'est ok : local http = net.HTTPClient({ timeout = 20000 }) http:request(string.format("http://127.0.0.1:11111/api/devices/action/%d/%d",timestamp,id), { options = { method = "DELETE", }, success = function(status) print(status.status) end, error = function(error) print(status.status) end }) -----> réponse : 200 (ou 404 si inexistant) comme décrit dans l'API ???????

si tu fais allusion a l’histoire de la redondance dans le debug, c’est pas ce self:debug qui en est à l’origine... C’est que pour afficher ce qui viendrait éventuellement du serveur.

car cette socket est utilisée par d’autre QA également non, mais le simple fait d’appeler une méthode, ajoute systématiquement une ligne (pour tous les QA d’ailleurs) Et comme l’argument que je passe n’est ni plus ni point que le debug lui-même, ça fait de la redondance... Je sais pas si je me fais comprendre...

ouah !! plus de 20 000 enregistrements en 7 heures !! hé bé... ça travaille sévère la dedans...