Aller au contenu

Sunrisehour, Sunsethour, Os.date Et Variable Jour_Nuit

mprinfo

Par mprinfo
dans Tutoriels

 Partager

Messages recommandés

cybersquat Newbie

cybersquat

Posté(e)
Posté(e)

re les boys,

 

mdr serait bien de poster un code tout prêt lol, moi je fais que des conneries avec tout ca  :2:

 

en tout cas merci de votre super taf !

  • Réponses 100
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

mprinfo
mprinfo

Sunrisehour, Sunsethour, Os.date Et Variable Jour_Nuit V1.00     Une version plus élaborée ce trouve ici :  http://www.domotique-fibaro.fr/scene-lua-jour-nuit-avec-decalge-possible-et-o

Steven
Steven

Allez, soyons fou :   Il y a trois type d'optimisation .. la mémoire, le temps processeur .. le temps du développeur.   Une bonne application prend en compte ces 3 critères en essayant de faire un bon

JossAlf
JossAlf

Merci pour cette réponse. J'avais même pas rêvé de toi cette nuit ...   Ton code fonctionne et je comprends ton intention avec le test if(NbreScene == 1) mais je trouve le procédé alambiqué. En plu

Images postées

pepite Newbie

pepite

Posté(e)
Posté(e)

yeah, toujours aussi super  ;-)

 

On apprend toujours et encore des anciens ;-)

 

Alors optimisons un max ;-)

 

Profitons profitons..;-)

 

PS : on pourrait faire aussi créer la VG si elle n'existe pas ;-)

 

à mprinfo : si tu mettais le code optimisé dans le 1er post ;-)

supermenteur Newbie

supermenteur

Posté(e)
Posté(e)

[DEBUG] 10:43:37: Lever Soleil : nil - Coucher Soleil : nil

 

Voilà  ce que j'ai dans le debug. Je suis en 4.042.

mais les variables locales lever et coucher sont bonnes. C'est la fonction string qui ne marche pas/plus.

cybersquat Newbie

cybersquat

Posté(e)
Posté(e)

question ? :D

 

le problème sur le truc, est que si on créer une scène par exemple en lui disant la nuit, éteint tel truc, il va se caler sur le coucher du soleil non ?

 

sera pas en fonction d'un timing genre 23h quoi ?

 

ou je sort ?

supermenteur Newbie

supermenteur

Posté(e)
Posté(e)

Non, la variable est bonne. Un fibaro:debug(lever) juste avant l'appel me donne la bonne valeur. C'est le String et %s qui ne marche pas.

 

Update: J'ai trouvé. La variable pour le %S est "Lever" et pas "lever" mame chose pour coucher.

Steven Newbie

Steven

Posté(e)
Posté(e)

Je vais même te faire rigoler :

 

Ma configuration de GEA ne tourne plus depuis 2 jours et je n'arrive pas trouver quel est la ligne en erreur.

 

Je pense que je fatigue  :D

  • Upvote 2
Steven Newbie

Steven

Posté(e)
Posté(e)

P@#*@ ... chercher l'erreur :

 

fibaro:setGlobal("Pushingbox")
fibaro:call(290, "pressButton", 1)
 
Dodo pépé ... dodo.
  • Upvote 1
Steven Newbie

Steven

Posté(e)
Posté(e)

@mprinfo

Heuu, non ... NomVG est déclaré en tant que variable Globale au script, tout en haut du code. Elle est donc visible de partout dans le script. 

 

L'erreur que je vois dans mon code est 

 

function traitement(lever, coucher, heure)

   local valeur = "Nuit"

   -- test si on est le jour ou la nuit

   if (heure >= lever) and (heure < coucher) then

     valeur = "Jour"

   end

   UpdateVG(nuit) -- mise a jour de la VG Jour_Nuit

end

 

nuit n'existe pas, c'est valeur qu'il faut mettre.

 

Bien évidement, il peux y avoir d'autres erreurs.

 

 

Ca vous ira ?????

Moi je verrais bien un hystérésis  :60:

cybersquat Newbie

cybersquat

Posté(e)
Posté(e)

2ieme demande  :D

 

ca fait 2, je continu ? mdr

 

Oui intéressant car il peut faire encore jour ou nuit, pour le déclenchement de certaines scènes, c'est top !

Steven Newbie

Steven

Posté(e)
Posté(e)

Pour vous faire patientez en attendant que sa fille le laisse se reposer un peu :)

 

C'est un complément à  ceci : Précis Sur Les Variables Locales/globales

 

 

Pour la variable avec une portée globale et les passages de paramètres, voici une explication et un petit script pour bien comprendre son fonctionnement.

 

Notion de base sur le passage de paramètre :

Les paramètres d'une fonction peuvent être de 2 manières différentes (par référence ou par valeur) : 

- référence : la fonction reçoit l'adresse mémoire du paramètre. Un changement de valeur affectera TOUT le script

- valeur : on reçoit la valeur du paramètre Ce dernier est copié dans une nouvelle référence propre à  la fonction. Un changement de valeur n'affectera que la fonction.

 

en LUA, chaque passage de paramètre ce fait en "valeur" SAUF pour les tables (c'est comme en français, il y a toujours une exception).

 

Donc si je fais

 

function maFonction(var)

   print(var)

end

maFonction("Coucou")

 

j'envoi à  ma fonction la valeur, soit une copie de "Coucou". Si a l'intérieur de maFonction je modifie la valeur, cela n'aura un impact QU'AU sein de maFonction.

maFonction va donc créer une nouvelle variable "var" dans laquelle il va copier la valeur "Coucou"

 

Si je fais

 

local coucou = "Coucou"

function maFonction()

   print(coucou)

end

 

et que dans maFonction je modifie coucou, alors coucou va être modifié pour tout le script puisque la modification aura eu lieu sur sa référence.

 

En bref, si on est au sein d'un script ou d'une fonction, nous travaillons sur les références. Si nous passons les informations en tant que paramètre, nous travaillons sur une valeur.

 

local coucou = "Coucou"

function maFonction(variable)

   print(coucou)

   print(variable)

end

maFonction("Coucou")

 

Plus compliqué car la référence coucou est envoyée en paramètre et devient donc une copie de valeur.

local coucou = "Coucou"

function maFonction(variable1, variable2)

   print(variable1)

   print(variable2)

end

maFonction("Coucou", coucou)

 
 
Allez un bon script vaut mieux qu'un long discours :
 
function scope1()
  -- la variable var n'existe pas
  print(var)  --- nil (variable inexistante)
end

function scope2(var)
  -- la variable est passée en paramètres donc visible
  -- bien que déclarée après
  -- En sortant de cette méthode, var aura repris ça valeur
  -- initial car elle a été passée en paramètre soit par
  -- valeur
  print(var .. " dans scope2()") -- ______
  var = "Scope2"
  print(var) -- Scope2
end

local var = "-=init=-"

function scope3()
  -- la variable est connue car déclarée avant. Elle est assignable
  -- par contre, si on déclare une variable du même nom au sein
  -- de cette même function, en sortant la variable aura repris sa valeur "Scope3"
  print(var .. " dans scope3()")
  var = "Scope3"
  print(var)
  local var = "Byebye"
  print(var)
end

function exception(unTableau) 
  -- Les tableaux sont toujours traité comme une référence
  unTableau[1] = "Et voilà "
end

print(var .. " avant tout")
scope1()
print(var .. " après scope1()")
scope2(var)
print(var .. " après scope2()")
scope3()
print(var .. " après scope3()")

-- Exception avec les table qui sont toujours envoyé en tant que référence.
local table = {[1]="Humm"}
print(table[1])
exception(table)
print(table[1])

Debug :

[DEBUG] 11:39:22: -=init=- avant tout
[DEBUG] 11:39:22: nil
[DEBUG] 11:39:22: --init=- après scope1()
[DEBUG] 11:39:22: --init=- dans scope2()
[DEBUG] 11:39:22: Scope2
[DEBUG] 11:39:22: -=init=- après scope2()
[DEBUG] 11:39:22: -=init=- dans scope3()
[DEBUG] 11:39:22: Scope3
[DEBUG] 11:39:22: Byebye
[DEBUG] 11:39:22: Scope3 après scope3()
[DEBUG] 11:39:22: Humm
[DEBUG] 11:39:22: Et voilà 

.

.

Allez, dans combien de temps, notre mprinfo national va en faire un tuto avec des jolies couleurs ?  :)

 

  • Upvote 1
 Partager
Aller sur la liste des sujets
×
×
  • Créer...