Aller au contenu

Messages recommandés

  • 2 mois après...
Posté(e)
Le 20/03/2018 à 15:26, CaptainIgloo a dit :

Hi all,

Bon, je crois que j'aurais dû fournir la version à jour des corrections effectuées qui étaient en partie celles annoncées au début :

Améliorations :

 
- Historisation des dernières valeurs et affichages des tendances
- Vérification de disponibilité des API en ligne (Socket 80) pour ne pas bloquer procédure.
- Stockage de la durée journalière d’ensoleillement.
- Utiliser le champ port du VD comme ajusteur du filtre sur horizon.
- Définition des masques.
 
Corrections :
- Message SYNOP, retard d'information d'une heure sur la tranche de 3 heures antérieure.
 
Il faut que je retrouve mes backups du HC2 ...

 

Salut CaptainIglloo,

 

Je constate avec les beaux jour que le VD plante très souvent. Il arrive même qu'il n'est capable que de s’exécuter une seul fois par jour.

Cette erreur apparait très souvent: "line 172: bad argument #1 to 'gsub' (string expected, got nil)"

 

Saurais tu d'où provient cette erreur?

Par la plus grande des chances, as tu retrouvé la MAJ de ton VD?

 

Posté(e)

@Franco268 voici celui qui tourne chez moi.

Si tu as des soucis, vérifie le choix de ta station.

Attention, je l'ai un peu modifié pour répondre à mes besoins:

- la variable globale "octa" prend la valeur de nébulosité

- j'utilise ce VD pour mettre à jour ma variable "jour/nuit"

 

 

Indicateur_solaire.vfib

Posté(e)

J'ai trouvé ce qui bugue. C'est la fonction ci dessous:

 

local synop = ogimet:GET("/cgi-bin/getsynop?block=".. WMOID.."&begin=" .. UTC)

 

synop est dans certains cas vide. Mais pourquoi?

J'ai tapé ma requête dans mon Firefox, elle est a retourné une valeur à chaque fois. Mais pas via le VD.

 

La seule différence entre le VD et ma requete, c'est que j'ai remplacé les variables par des champs fixes.

Est ce le contenu des variables qui ont bugué ou la fonction via la box?

Aucune idée, je n'ai pas pu vérifier, et maintenant ça re fonctonne sans rien n'avoir touché, même pas un petit redémarrage.

 

Quelqu'un a déjà eu ce genre de problème?

 

@Dragoniacs J'ai comparé nos codes, la fonction est exactement la même

Posté(e)

C'est pour ça que je te disais de vérifier le SYNOP. J'ai eu le cas il y a quelques semaines, le SYNOP était en panne / plantait régulièrement. Donc de manière temporaire, j'en ai changé.

Posté(e)

Non. Je me demande si c'est pas station qui avait un soucis. C'est revenu comme ça.

Envoyé de mon SM-A520F en utilisant Tapatalk

  • 4 semaines après...
Posté(e)

Salut à tous !

 

Dites moi juste,

Les valeurs de la variable azimut n'était-elle pas arrondie au degré près ?

 

J'avais fait des scènes pour piloter mes volets mais elles ne fonctionnent plus cette saison. (du genre: fermer si VDSoleilAzimut = 110)

Le vd fonctionne bien pourtant.. 

 

Le problème ne viendrai pas du fait que mon VDSoleilAzimut passerai de 109,98 à 110,13 entre deux rafraîchissement ?

 

J'avais pas fait gaffe à ca quand je l'ai fait à l'époque.. 

 

Merci d'avance et bonne journée à vous !

Posté(e)

Moi je joue avec du > ou Comme tu mets à jour que toutes les 10min, tu risque de ne jamais tomber tout pile sur la valeur recherchée...

Envoyé de mon SM-A520F en utilisant Tapatalk

Posté(e)

J'y ai pensé mais imaginons :

(dit moi ou je me trompe) 

 

Si vdazilmut > 110 alors fermer ? 

Si vdazilmut > 220 alors ouvrir ? 

 

(mais si > 220 par déduction > 110)

 

Et donc tu envois un ordre à tes volets à chaque rafraîchissements ? 

Posté(e)

En fait, je passe par GEA, donc c'est assez simple.

Dans tous les cas, il te faut gérer une double condition :

- fermer si ">110" et "<120"

- ouvrir si ">120"

 

Dans GEA, voici mes lignes :

-- Volet du salon coté rue
GEA.add({{"Global+","VDSoleilHauteur",10},{"Global+","VDSoleilAzimut",75},{"Global-","VDSoleilAzimut",125},{"(Value+)",id["VOLET_RUE"],35}},30,"Trop de soleil en façade, je ferme les volets du séjour",{"Close",id["VOLET_RUE"],70})
GEA.add({{"Global+","VDSoleilHauteur",10},{"Global+","VDSoleilAzimut",125},{"(Value-)",id["VOLET_RUE"],90}},30,"Le soleil a tourné, j'ouvre les volets coté séjour",{"Open",id["VOLET_RUE"]})

Je vérifie l'azimut avec une double condition mini/maxi, et je regarde aussi l'état du volet pour ne pas déclencher un mouvement s'il est déjà baissé ou levé.

 

 

 

 

  • Like 2
Posté(e)

OK d'accord. 

 

Bonne idée avec GEA.

 

Je vais me lancer quand j'aurai un moment. 

(je dois retranscrire mes scènes dans GEA du coup) 

 

Merci pour ton petit coup de pouce m'sieur ! 

Posté(e)

Oups ! :o

 

Toutes mes excuses m'dame. 

 

Note à moi-même :

ne jamais se fier à son intuition dans ce genre de situations.. 

 

Encore merci à toi ! 

  • Like 1
Posté(e)

Si ça peut t’aider..., moi je n’utilise pas gea.

J’utilise également des conditions supérieures et inférieures auxquelles j’ajoute une « mémoire » image de l’etat du volet.

- fermer si ">110" et "<120" et volet ouvert

- ouvrir si ">120" et volet fermé 

 

Posté(e)
Il y a 18 heures, pepite a dit :

Msieur @Dragoniacs lol

Tu vas nous la vexer ;-)

Et @pepite qui en rajoute une couche..

Merci lol ! :60: 

 

Il y a 10 heures, Franco268 a dit :

Si ça peut t’aider..., moi je n’utilise pas gea.

J’utilise également des conditions supérieures et inférieures auxquelles j’ajoute une « mémoire » image de l’etat du volet.

- fermer si ">110" et "<120" et volet ouvert

- ouvrir si ">120" et volet fermé 

 

D'accord, merci pour l'info @Franco268

 

En fait l'idée est d'utiliser la position du volet quoi qu'il arrive pour ne pas déclancher d'actions inutilement, c'est bien compris. 

 

Mais quelque chose me tracasse quand même hors GEA (je réfléchi à voix haute) :

 

Dans ">110" et "<120" si je développe ça ne voudrai pas dire "de 110 à 360" et "de 0 à 120"? 

 

Tu utilises le mode blocs ou un script lua ? 

 

J'essaye dès que j'ai un moment avec tout ça j'arriverai bien à faire quelque chose qui fonctionne.. 

 

:)

 

Posté(e)
Il y a 5 heures, j-psy a dit :

qui en rajoute une couche..

De rien hihihi

 

Il y a 5 heures, j-psy a dit :

">110" et "<120"

Pour moi cela signifie plutot de 111 à 119.

  • Like 1
Posté(e)

Tout pareil que Pepite et Dragoniacs de 111 à 119.

Le « et » veut dire que ton azimut doit répondre au 2 conditions. Qu’il doit être plus grand que le premier mais aussi plus petit que le second.

Moi je fais quasiment tout en lua

Posté(e)

Ben je confirme ça a l'aire de fonctionner, j'ai fait un essai sur un volet seul en mode bloc et on dirait que ça marche.  

 

Je vérifie demain sur une journée complète.

(Désolé d'avoir douté..)

 

En tout cas merci pour vos éclaircies, sans vous j'aurais eu chaud cet été ! 

B)

  • Like 1
  • 4 mois après...
Posté(e)

Bonsoir bonsoir, 

 

Bon, ben je crois que l'API Google pour l'élévation n'est plus free ;-)

 

-- Elevation Google API (Free)
GoogleElevation = Net.FHttp("maps.googleapis.com")
local response = GoogleElevation:GET("/maps/api/elevation/json?locations=".. Latitude .. "," .. Longitude .. "&sensor=false")
fibaro:debug(response)
--local jsonTable = json.decode(response["results"][1])
--local Altitude = jsonTable.elevation
jsonTable = json.decode(response)
Altitude = jsonTable.results[1].elevation

J'ai cette erreur là ;-) 

 

[ERROR] 18:47:38: line 74: attempt to index field '?' (a nil value)
[DEBUG] 18:48:38: { "error_message" : "Keyless access to Google Maps Platform is deprecated. Please use an API key with all your API calls to avoid service interruption. For further details please refer to http://g.co/dev/maps-no-account", "results" : [], "status" : "OVER_QUERY_LIMIT" }

 

Suis je le seul ;-)  ? 

×
×
  • Créer...