jjacques68

j'espère que la prochaine mise à jour va nettoyer tout ce bazard !

alors dans mon cas c'est simple : aux vu des fichiers .fbi qui augmentent de 1 Mo par jour (qui du coup fond planté le backup automtique, car trop long visiblement), j'ai fait un "REPAIR" depuis le Recovery (sur les conseils du supports) et la c'est la dégringolade... le "REPAIR" à visiblement pas fonctionné du tout. La box a redémarrer 3 fois de suite sans résultat. Elle est entrée en mode "repair auto" elle m'a retrogradé en 5.037 (avec le Sytem B ) J'ai donc perdu toutes mes modifications d'optimisation de script en 5.040 J'ai essayé de restaurer la 5.040 sans succès (depuis l'interface web) --> echec. Plus de reboot plossible. J'ai forcer le mode recovery depuis les boutons sur la box, et voulu utiliser un des fichiers générés par le backup du Syno. Marche pas car pas la bonne extension J'ai compressé le fichier .fbi en .7z. La restauration à fonctionné. J'ai rebooté, et ça a planté anouveau. Du coup reset usine. Depuis l'interface WEB, j'ai restaurer le dernier backup du Syno (depuis l'interface WEB, il accepte les fichier .fbi) Là ça à l'aire OK. Je viens de faire un backup, et je suis à 14 Mo !!!!

tu as vu les messages que tu as déplacé, le compressé en .7z semble fonctionné malgré l'erreur d'image corrompue... c'est vraiment louche ce truc...

recovery OK après reset usine... On va voir combien de temps ça tient, et surtout la taille des backup...

bon allé, trop n'importe quoi cette version, Comme a dit @mprinfo vien de faire un reset usine... je vais restaurer un backup en 5.040 pour voir... un dernier coup. Sinon je reviens en 5.037.

bon ben je confirme, le fait de simplement compresser le fichier .fbi en .7z fonctionne. ça vient de me sauver la vie ! EDIT : sauf que : ????

hmmm mon histoire se complique dangereusement... visiblement si on veut utiliser les fichier de backup sauvegarder en local, l'extention ne doit pas être .fbi mais .7z ! alors suffit-il de le compresser avec 7-Zip ? - pas trouver de réponses null part... Pour le moment je suis dans une grosse galère avec leur connerie de "repair". Box plantée...

tu alimentes le mini click ? tu ne prends pas le GND du FGBS ?

Réponse du support : faire une tentative de réparation(option Repair du mode recovery) selon la doc : Repairing system This feature allows you to restore the operating system to the latest version or version from a file without deleting any user data. Only the system will be refreshed. Depending on how you have entered the Recovery Mode, different system will be available for repairing: inactive when entered via configuration interface or active when entered using button. Switch system to repair the other one. Enter the Recovery Mode. Click Repair System A/B. Choose if you want to restore Latest version or use Local file. Confirm. Je me demande si c'est une bonne idée...

je dirais ok pour l'alimentation. a confirmer... @Did ?

ben c'est bon à mon avis..., de tout façon ce qui nous intéresse c'est le contact sec, donc pas de soucis... tu confirmes @Did ?

chose faite. J'ai reçu un lien sur Fibaro Customer Care, auquel j'ai du m'inscrire. Ma demande a visiblement automatiquement ouvert un ticket. à suivre...

bon, je contacte le support technique, en 2 jours, la backup est monté de 5 Mo ! J'ai quand même pas tapé pour 5 Mo de ligne de code !

Yes, a table of functions, I think I will finish to create it Thanks, I didn't remember me anymore how to write syntax...

I understand, but I can't wait 2 even 1 second to switch ON a light, it must be instantly... when the sensor up to true... example of filters I use : if e.type == 'DevicePropertyUpdatedEvent' and e.data.property ~= 'quickAppVariables' then ... elseif e.type == "NotificationCreatedEvent" then ...

I must poll it quickly ! I need to intercept the change of state of PIR sensor for switch ON/OFF lights... and to update an IHM... It must be reactive... My code looks like yours : I have 2 setTimeout, one for main loop, and one for each treatment... is it correct ? Function Main() local res = self.http:request("http://127.0.0.1:11111/api/refreshStates?last=" .. self.lastRefresh,{ success=function(res) for _,e in ipairs(res.data.states.events or {}) do fibaro.setTimeout(0, function() if ...Filter1... then ... fibaro.call(QA1, "Function", ...) end if ...Filter2... then ... fibaro.call(QA2, "Function", ...) end if ...Filter3... then ... fibaro.call(QA3, "Function", ...) end ... end) end setTimeout(Main(), 50) end, error = function(res) ... setTimeout(Main(), 50) end, )} end

@jang yes, a lot of questions about... I have some problems with a function which modify the Notifications properties of device in API /deviceNotifications/V1. The box crashes when the script modifies the API while a device is changing his state. Since the latest update... So I juste change my code and now I use my QA which check the RefreshState every 50 ms. And case of certains criteria, I notify or not... It works fine. But this script begins to do a lot of thing !! It allows me to (with another specifics QA of course, all is not in the same QA ) : send debug data in database through a socket send events of devices in a soft for an IHM through a another socket switch ON/OFF the lights with PIR sensor send Events from notifications panel by mail and now, notify me by Push, TTS, mail or Prowl of states of devices This script is very big and it works fine ! I have in, a big variable table with all devices and informations to make what I need. But I ask me some questions above performances... I ask me if I should not create a new QA for notifications, but always with API RefreshState... And why not for the Lights with PIR... but 2 or 3 script which question the same API every 50 ms !! It's not too ?? I don't know what doing... what is the best method... This QA replaces the multi instances of scenes...

compare les 2, si ça se trouve, ils sont compatibles !

@Lazer : : pour en revenir à l’optimisation des fonctions, ce principe est toujours correct ? - bouclage de la fonction principale - selon les cas, appel de la sous fonction x function Principale() if ... then setTimeout(0, MaSousFonction1()) end if ... then setTimeout(0, MaSousFonction2()) end setTimeout(50, Principale()) end function MaSousFonction1() ... end function MaSousFonction2() ... end

ah peut être ! oui voilà, le Mini-click de chez hunter, c'est celui-là que j'ai aussi.... suis bête c'est marqué dans ma signature idem, branché sur un smar implant, alimenté par panneau solaire.

ben voilà chez moi il vient de déclencher avec une grosse pluie ! 10 min de temps de réaction...

il réagit avec du retard par rapport à la condition réelle. s'il commence à pleuvoir au moment de l'arrosage, ça arrosera quand même. et s'il vient d'arrêter de pleuvoir, ça n'arrosera pas. le principe est qu'il y a quelques disques de lièges (je pense), et ceux-ci vont gonfler avec les gouttes d'eau, pour finir par déclencher le contact. d'où le retard décalage par rapport à la réalité. Par contre s'il pleut trois gouttes, tu vas attendre longtemps avant qu'il déclenche, voir il déclenche pas. sous une averse d'orage, il déclenche en 5-10 min quand même. après il revient en mode normal suivant la vitesse à laquelle les disques sèchent et se rétractent pour libérer le contact. Donc en été il sèche très vite par rapport au printemps et automne. On peut régler plus ou moins la durée avant le déclenchement du contact en jouant avec la bague de réglage. Je suis satisfait du principe.

nan j'en ai pas pour le sol... par contre j'ai un capteur de pluie de ce type, qui me coupe l'arrosage si il est enclenché.

si vraiment ça te bloque, je me suis fait QA qui permet de contourner la chose... Faudra juste qu'on le mette à ta sauce

Tu utilises plusieurs zones ? Tu n'as pas de soucis, quand tu coches "lundi" de ne plus avoir la possibilité de le cocher pour les autres zones ?