jojo Posté(e) le 23 mai 2019 Signaler Posté(e) le 23 mai 2019 Les avantages de la v4 sont : Plus dépendant de la clé usb Les backups contiennent les icônes
Lazer Posté(e) le 23 mai 2019 Signaler Posté(e) le 23 mai 2019 Tu as oublié le support de tous les nouveaux périphériques Z-Wave Plein de nouvelles fonctionnalités LUA/API Etc Depuis la V3 il y a quand même eu pas mal d'évolutions 1
jojo Posté(e) le 23 mai 2019 Signaler Posté(e) le 23 mai 2019 oui biensîr, je te laissait compléter la liste
jojo Posté(e) le 23 mai 2019 Signaler Posté(e) le 23 mai 2019 il y a 47 minutes, Lazer a dit : Tu as oublié le support de tous les nouveaux périphériques Z-Wave tu pense au portier et à la vanne thermo ? lol
Nico Posté(e) le 23 mai 2019 Signaler Posté(e) le 23 mai 2019 Et tu vas devoir faire plusieurs migrations en V4, je ne crois pas que tu puisses faire 3.6 vers V4.5x.
Lazer Posté(e) le 23 mai 2019 Signaler Posté(e) le 23 mai 2019 L'intercom, je l'avais oublié, mais de toute façon il n'est pas Z-Wave non ? Donc il ne compte pas. Je pensais au FGSD (la v3 ne supporte que le FGSS), aux Walli, Roller Shutter v3, tous les nouveaux FGS, Smart Implant, le Button (bon cela dit, ils sont tous en panne), tous les modules Aeotec, le support de la sonde interne des SRT 321, tous les modules Qubino (sans templace, mais ils fonctionnent ce qui était rarement le cas en v3), etc etc etc la liste est très longue @Nico oui il va y avoir une étape intermédiaire, mais c'est bien de celle-ci que je parlais, ça risque d'être laborieux. Une fois en v4, les dernières mises à jour passent comme une une lettre à la poste (impossible) bière dans le gosier.
Nico Posté(e) le 23 mai 2019 Signaler Posté(e) le 23 mai 2019 Yes, faut tenter, par contre plus de retour arrière si 4.5x... Enfin pas sans bidouille.
SebDel Posté(e) le 23 mai 2019 Auteur Signaler Posté(e) le 23 mai 2019 (modifié) Bonsoir à tous, Pour la BD, comme j'ai fait un recovery il y a quelques jours, j'ai peut être une chance qu'elle ne soit pas encore trop énorme. Par contre peut être que la bonne idée serait de faire un nouveau recovery juste avant la mise à jour, comme ca je fait 3.54 -> 3.60 puis 4.07... De toutes les façons, là j'ai tous mes devices qui sont ok sur le réseau. Pour les icons, je ne les ai pas encore défini. Comme ça quitte à tout refaire, je ne garde que les devices matériels et pour le reste je réadapte au fur et à mesure. J'ai : 6 sections, 23 pièces, 150 devices, 8 scenarios, 49 virtuels, 0 plugins et 123 variables. Pour les devices physiques je n'en ai que 28. Ca devrait le faire après un recovery. Modifié le 23 mai 2019 par SebDel
Lazer Posté(e) le 24 mai 2019 Signaler Posté(e) le 24 mai 2019 Cela ne change rien si tu restaures une sauvegarde réalisée juste avant le recovery. En effet, lors de chaque backup, la DB est sauvegardée telle quelle, sans optimisation ou purge particulière. Donc un backup / recovery / restauration remet la HC2 strictement dans le même état que précédemment (sauf les icônes qui étaient perdues en v3 et v4 avant la v4.500) Donc ta DB a toutes les chances d'être assez grosse. Tu peux t'en assurer en allant dans le panneau de consommation, et si tu vois plusieurs années d'historique d'énergie, alors la DB doit être énorme. Après vu les difficultés de migration en v4 pour ceux qui ont trop attendu (il y en a eu pas mal), Fibaro a peut être faire évoluer son script de migration, pour réaliser la purge de la DB AVANT la migration effective en v4.... enfin tu verras bien comment ça se passe !
SebDel Posté(e) le 24 mai 2019 Auteur Signaler Posté(e) le 24 mai 2019 Bonjour Lazer, Effectivement dans ce cas cela ne sert à rien. Par contre pour les historiques de mesures, tous les jours j'ai un script qui purge les données qui ne me sont pas utiles (pour la plupart des devices sauf 1, celui de la conso générale de la maison). Si je purge toutes les consommations et je n'ai aucun événements loggés, je pense que cela devrait réduire la taille de la DB. Après comme tu dis, vu le taf que je vais avoir, je peux toujours tester voir comment cela passe. Dès que j'aurai fini la première MAJ, je reviens ici te dire combien de temps cela aura mis.
Lazer Posté(e) le 24 mai 2019 Signaler Posté(e) le 24 mai 2019 Ah si tu purges déjà les données via un script, c'est top ça ! Tu auras moins de problèmes du coup
SebDel Posté(e) le 24 mai 2019 Auteur Signaler Posté(e) le 24 mai 2019 En fait j'avais remarqué qu'avec le temps la box ralentissait. Comme j'avais plein d'événements dans les logs, j'ai commencé par plus logger par défaut. Ensuite j'ai vu que les infos de conso occupé une grosse partie de la base. Comme je ne les utilise que pour GEA et éventuellement pour une stat instantanée, tous les soirs je les vires sauf pour mon aeotec HEM en tri mais je ne garde que la conso générale. Que je pourrait aussi purger avant de migrer.
jjacques68 Posté(e) le 28 mai 2019 Signaler Posté(e) le 28 mai 2019 euh... question bête : comment on fait pour purger les info du panneau d'événements ou de conso ?
SebDel Posté(e) le 28 mai 2019 Auteur Signaler Posté(e) le 28 mai 2019 Bonjour jjacques68, Pour ma part, j'ai fait un petit module virtuel qui lance un script tous les jours le matin à 3h qui fait cela avec l'API : local HC2=Net.FHttp("192.168.X.X") HC2:setBasicAuthentication("XXXLOGIN","XXXMDP") response ,status, err = HC2:GET("/api/callAction?deviceID=XXNUMDEVICE&name=clearEnergyData") fibaro:sleep(1 * 1000) response ,status, err = HC2:GET("/api/callAction?deviceID=XXNUMDEVICE&name=clearEnergyData") fibaro:sleep(1 * 1000) le 192.168.X.X correspond à l'adresse IP de la BOX, XXLOGIN au login de connexion, XXMDP le mot de passe. Ensuite chaque ligne GET traite un device, avec une seconde d'attente. Le XXNUMDEVICE doit être le numéro du device (ID) à reseter. J'ai mis une seconde de sleep car j'ai remarqué que la box pouvait laguer et rater des reset si on n'attendait pas un peu entre deux requêtes. Une bonne journée à tous. Séb 1
jojo Posté(e) le 28 mai 2019 Signaler Posté(e) le 28 mai 2019 si dans ton code tu utilises local HC2 = Net.FHttp("127.0.0.1",11111) tu ne devras plus d'adapter si ta HC2 change d'IP, ni mettre les credential du user admin
SebDel Posté(e) le 28 mai 2019 Auteur Signaler Posté(e) le 28 mai 2019 (modifié) Comment cela la HC2 change d'IP, normalement il n'y a aucune raison... Après dans l'API on est obligé d'utiliser Basic Authentification, pour l'instant je n'en ai pas d'autres. Je n'ai pas de https sur la HC2 (en tout cas en v3.6). Je n'ai pas testé avec 127.0.0.1. Dans ce cas l'API ne demande pas d'authentification ? (Je viens de voir que le code 127.0.0.1 avec le port 11111 était en direct. C'est valable aussi en v4 ?) Modifié le 28 mai 2019 par SebDel
jojo Posté(e) le 28 mai 2019 Signaler Posté(e) le 28 mai 2019 je n'ai plus de HC2 depuis 2 ans, donc je ne sais pas valider aujourd'hui. Mais ce que je sais, c'est que j'utilisais toujours cela (et tout le monde ici d'ailleurs), et ça permet, entre-autre, de partager les codes sans devoir penser à vier les credentials, etcc.
Lazer Posté(e) le 28 mai 2019 Signaler Posté(e) le 28 mai 2019 Ton HC2 n'a pas changé d'IP. 127.0.0.1 c'est localhost, valable sur toutes les piles IP de tous les appareils du monde. Si tu attaques l'API via l'adresse locale 127.0.0.1 et sur le port 11111, cela permet effectivement de se passer de l'authentification. Cela fait une manipulation en moins, et surtout pas d'identifiant en clair à stocker dans le code de tes scripts Je crois que ça fonctionnait déjà en v3... à tester. En v4, tu pourras encore plus simplifier ton code, en utilisant directement la fonction api.get( ) => voir exemples sur le forum. 1
Steven Posté(e) le 28 mai 2019 Signaler Posté(e) le 28 mai 2019 Il suffit d'utiliser dans le code :api.get(url)Et ne plus faire aucun appel Http.Exemple : api.get("/devices/2")Envoyé de mon SM-G935F en utilisant Tapatalk 2
jjacques68 Posté(e) le 28 mai 2019 Signaler Posté(e) le 28 mai 2019 Et donc c’est 1 device après l’autre pour vider le log...Bon ben on va faire une petite boucle alors !Envoyé de mon iPhone en utilisant Tapatalk Pro
SebDel Posté(e) le 29 mai 2019 Auteur Signaler Posté(e) le 29 mai 2019 Bonjour à tous, @Lazer/@Steven : Pour le 127.0.0.1, en fait initialement je passais par une autre machine qui faisait le taf, après sa mort j'ai repris le code en local. Par contre j'ignorai le port 11111. Je vais changer tout mon code dans ce sens et utiliser api.get en v4 quand je passerai en v4 ce week ou le week end prochain. @jjacques68 : Oui si tous tes devices sont concernés. Pour ma part je le fait pour certains, et garde quelques infos plus longtemps (1 semaine ou 1 mois au plus pour la maison globale).
jjacques68 Posté(e) le 29 mai 2019 Signaler Posté(e) le 29 mai 2019 Et voilà, j'ai désactivé tous les log : local device = api.get("/devices/") local value for k,v in ipairs(device) do if device[k].properties.saveLogs == true then local value=api.get("/devices/"..device[k].id) value.properties.saveLogs = false api.put("/devices/"..device[k].id, value) end end ça a bien pris 15 min pour tout faire... Maintenant faut attendre que ceux à piles se réveillent...
jjacques68 Posté(e) le 29 mai 2019 Signaler Posté(e) le 29 mai 2019 Et pour ceux que ça intéresse, voilà pour vider l'historique de la consommation : print("start") local device = api.get("/devices/") for k,v in ipairs(device) do if device[k].properties.showEnergy == true then local change = api.post("/devices/"..tostring(device[k].id).."/action/clearEnergyData") print(device[k].id.." ----> RAZ Consumption OK") end end print("end") 1
jjacques68 Posté(e) le 29 mai 2019 Signaler Posté(e) le 29 mai 2019 ce qui serait intéressant serait de pouvoir également vider l'historique des température... Mais je trouve pas... encore ...
Lazer Posté(e) le 29 mai 2019 Signaler Posté(e) le 29 mai 2019 Merci, mais tu peux simplifier ton code, et surtout l'accélérer en évitant de récupérer la liste de tous les devices, puis parcourir inutilement une grande boucle. A l'aide des filtres introduis en v4.071. Exemple : local device = api.get("/devices?property=[showEnergy,true]")
Messages recommandés