Aller au contenu

HC2 devenu folle


SebDel

Messages recommandés

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.

Lien vers le commentaire
Partager sur d’autres sites

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é par SebDel
Lien vers le commentaire
Partager sur d’autres sites

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 !

Lien vers le commentaire
Partager sur d’autres sites

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.:13:

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

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é par SebDel
Lien vers le commentaire
Partager sur d’autres sites

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.

 

Lien vers le commentaire
Partager sur d’autres sites

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.
 

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

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).

 

Lien vers le commentaire
Partager sur d’autres sites

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...

Lien vers le commentaire
Partager sur d’autres sites

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")

 

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

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]")

 

Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...