LUA Scripting sur V2.1.x

Pareil !

Si je dé-commente cette ligne l'écran1 exécutant le script de la télémétrie est planté !
--lcd.drawNumber(130, 38, getValue("Cels"), PREC2+LEFT+SMLSIZE)

Si je mets
lcd.drawNumber(130, 38, getValue("CELLS"), PREC2+LEFT+SMLSIZE)

Je ne plante pas et j'ai 0 comme valeur (de même que si je fais getValue("toto"))

Alors que par ailleurs si j'affiche la valeur "Cels" dans l'écran2 de la télémétrie, c'est OK.

Ok, donc, ça ne vient pas d'un défaut de chez moi et ça m'arrange, ça me fait tout pareil, sur un écran chiffre, c'est bon, sur un écran Lua, ça ne va pas.

A part ça, ton message clair et concis avec exemple qui concernait le mélange VG + Script modèle me parle bien Français et devrait m'aider à progresser tout en douceur.

dev.fred a écrit:
Je pense qu'un exemple utilisant ton script de télémétrie avec simplement l'utilisation de la variable globale glipo pour afficher la valeur de Li-Po provenant d'un script model .../... Donc la combinaison des 2 scripts est générique sur les sources..../...


1000 merci.

Parfait et je fais d'1 pierre 3 coups : toi, moi (j'apprends mieux qd c'est bien écrit et le forum est moins bordélique que mes notes)  et peut être un tuto sur le forum
Sinon, attention de ne pas confondre les VGn avec une variable globale LUA (VG m'évoque les VGn) parce-que on peut également les utiliser pour passer des valeurs mais le problème, c'est qu'elles sont liées aux phases de vol)


Sinon
local CelsId = getFieldInfo("Cels").id
lcd.drawText(88,38, "Cels :",SMLSIZE,0)
lcd.drawNumber(130, 38, getValue(CelsId), PREC2+LEFT+SMLSIZE)

Plante pareil.

Si Marco est dans le coin, il pourra peut être confirmer ?

dev.fred a écrit:
local CelsId = getFieldInfo("Cels").id
lcd.drawText(88,38, "Cels :",SMLSIZE,0)
lcd.drawNumber(130, 38, getValue(CelsId), PREC2+LEFT+SMLSIZE)

Si Marco est dans le coin, il pourra peut être confirmer ?

J'allais essayer
CELL-SUM-MIN plante aussi
Cmin ne m'offre que 0 alors que Cmin sur écran chiffre (non Lua) fonctionne.

Décomposez vos lignes ça vous permettra de mieux trouver le problème.

local CelsId = getFieldInfo("Cels").id
local CelsValue = getValue(CelsId)
lcd.drawNumber(130, 38, CelsValue, PREC2+LEFT+SMLSIZE)

Ca vous permettra de voir quelle ligne plante.

Ensuite, vous pouvez ajouter des print qui vont s'afficher dans la console (F6).

Merci Marco,

Depuis la console de debug, il n'y a pas d'équivoque, j'ai un beau message d'erreur sur drawnumber :
Script    test1 error: /SCRIPTS/TELEMETRY/test1.lua:13: bad argument #3 to 'drawNumber' (number expected, got table)

et le problème disparait dés que je commente:
lcd.drawNumber(130, 38, getValue(CelsId), PREC2+LEFT+SMLSIZE)
ou:
lcd.drawNumber(130, 38, getValue("Cels"), PREC2+LEFT+SMLSIZE)

Grâce au print, je vois ce qui se passe:

print(getvalue("SWR"))
30
30
30
30

print(getvalue("Cels"))
table: 02FD5B60
table: 02FD5C78
table: 02FD5C78
table: 02FD5D90
table: 02FD5E08

Comme le message d'erreur l'indique, getvalue récupère une table au lieu d'une valeur!
Je vais créer une "issue" sur github.

N'ouvre pas une issue sur Github, ça me parait normal, si tu as cinq cellules, tu obtiendras une table de 5 éléments, si tu n'en as que 4, tu devrais en obtenir 4.

Il te faut faire une boucle pour traiter élément par élément.

[EDIT]
Pareil avec getValue("GPS"), tu obtiendras une table avec deux éléments : latitude et longitude
Et aussi pour la date et l'heure, tu obtiendras une table.
[/EDIT]

Sacre100, à ton avis il n'est donc pas possible de simuler Cels correctement ?
Un nouveau Companion avec les champs Cel1, Cel2 Cel3 etc.. ne peut-il être envisagé sur les futures versions ?

Heisenberg a écrit:Sacre100, à ton avis il n'est donc pas possible de simuler Cels correctement ?
Un nouveau Companion avec les champs Cel1, Cel2 Cel3 etc.. ne peut-il être envisagé  sur les futures versions ?

Je pense que c'est déjà le cas, il fautjuste comprendre comment c'est fait.

Fred a déjà donné un moyen de rentrer des valeurs correctes pour CELLS, maintenant, il comprendre ce que contient la table retournée par le getValue. Il suffit de mettre quelques print :

local celsValue = getValue("Cels")
print celsValue[1]
print celsValue[2]

Trop tard, je prends juste le risque de dire une bêtise (j'ai l'habitude, je fonctionne par erreurs corrigées) : https://github.com/opentx/opentx/issues/2915

Je n'ai pas essayé de simuler une lipo 3S ou plus; je peux juste tester une 1S ou 2S avec le code que j'ai, donc j'envoie un seul int32 qui peut coder 2 cellules (les bits 5 à 8 codent le nombre de cellules et ici c'est 1 ou 2).
Les écrans de télémétrie interprètent correctement la valeur fournit dans CELLS, la valeur de Cels correspond bien à la somme des 2 cellules, il n'y a que le getValue qui semble déconner.

Nous verrons bien.

Bon ben voilà un bout de code qui illustre la chose.

Code:

local function run(event)
  lcd.clear()

  local CelsInfo = getFieldInfo("Cels")
  if not CelsInfo then
    lcd.drawText(50,20, "CelsInfo = nil",SMLSIZE,0)
    return
  end

  local CelsValue = getValue("Cels")
  if type(CelsValue) ~= "table" then
    lcd.drawText(50,20, "CelsValue not a table",SMLSIZE,0)
    return
  end

  lcd.drawText(50,10, "#CelsValue :",SMLSIZE,0)
  lcd.drawNumber(130, 10, #CelsValue, PREC2+LEFT+SMLSIZE)
  lcd.drawText(50,20, "CelsValue[1] :",SMLSIZE,0)
  lcd.drawNumber(130, 20, CelsValue[1], PREC2+LEFT+SMLSIZE)
  lcd.drawText(50,30, "CelsValue[2] :",SMLSIZE,0)
  lcd.drawNumber(130, 30, CelsValue[2], PREC2+LEFT+SMLSIZE)
end

return {run=run}


Une chose que j'ai constaté, c'est qu'on ne peu pas utiliser la mécanique de getFieldInfo en dehors de la fonction run car le champs peu ne pas encore exister lors de l'initialisation du script si le capteur n'a pas encore été découvert.

[EDIT] NON, c'est faux l'id pour Cels, c'est 205
Ensuite, on voit que "Cels" est un capteur un peu spécial car quand tu fais un getFieldInfo("Cels").id, ben cela retourne nil au lieu de retourner un valeur.
[/EDIT]

Voilà, voilà ...

Sacre100 a écrit:
Une chose que j'ai constaté, c'est qu'on ne peu pas utiliser la mécanique de getFieldInfo en dehors de la fonction run car le champs peu ne pas encore exister lors de l'initialisation du script si le capteur n'a pas encore été découvert.

Ca n'a pas de sens, ce cas ne se présenterait qu'une fois... si la première fois que tu utilises ce modèle tu décides d'essayer de lancer le script avant d'avoir configuré la télémétrie sur la radio.

Kilrah a écrit:

Sacre100 a écrit:
Une chose que j'ai constaté, c'est qu'on ne peu pas utiliser la mécanique de getFieldInfo en dehors de la fonction run car le champs peu ne pas encore exister lors de l'initialisation du script si le capteur n'a pas encore été découvert.

Ca n'a pas de sens, ce cas ne se présenterait qu'une fois... si la première fois que tu utilises ce modèle tu décides d'essayer de lancer le script avant d'avoir configuré la télémétrie sur la radio.

Non, ça a du sens si l'on veut mettre un message indiquant à l'utilisateur qu'il doit configurer sa télémétrie pour que le script donne le résultat espéré. Et même avec un tel message, si tu mets ça à l'extérieur et que l'utilisateur configure sa télémétrie alors que le script est déjà chargé en mémoire, ça ne va pas mieux marcher et il ne va pas comprendre pourquoi.

Autant faire un truc propre si l'on souhaite partager ses scripts, ça évite bien des problèmes.

Sacre100 a écrit:...
[EDIT] NON, c'est faux l'id pour Cels, c'est 205
Ensuite, on voit que "Cels" est un capteur un peu spécial car quand tu fais un getFieldInfo("Cels").id, ben cela retourne nil au lieu de retourner un valeur.
[/EDIT]

Encore faux, les Id peuvent changer en fonction de l'ordre de découverte, donc non seulement, les capteurs peuvent ne pas avoir encore été découverts mais en plus leurs noms et leurs Id peuvent varier. Il faut en tenir compte dans l'écriture des scripts LUA.

A noter quand même que Cels est un capteur un peu spécial qui me semble-t-il ne peut pas être créé manuellement. Il faut passer obligatoirement par la détection du capteur sinon ça ne marche pas bien.



Je ne sais pas s'il y a d'autre capteurs dans ce style, a voir.

Sacre100 a écrit:Non, ça a du sens si l'on veut mettre un message indiquant à l'utilisateur qu'il doit configurer sa télémétrie pour que le script donne le résultat espéré.

C'est un prérequis d'office pour tous les scripts lua en 2.1, donc ça va "de soi". C'est bien de le mentionner dans la doc, mais ça sert pas à grand chose de faire quelque chose dans le script lui-même. Les outils pour le faire bien dans le script n'existent pas encore à ce stade.

Heisenberg a écrit:Sacre100, à ton avis il n'est donc pas possible de simuler Cels correctement ?
Un nouveau Companion avec les champs Cel1, Cel2 Cel3 etc.. ne peut-il être envisagé  sur les futures versions ?

Pas besoin d'un nouveau OpenTx / Companion, ça existe déjà.

En fait, dans la télémétrie, on peut créer des champs calculés comme ça (cas de la première cellule) :



En indiquant :
- que c'est un capteur de type "Calculé"
- que la formule est "Elément"
- que le capteur d'élément est "Cels"
- que l'index de l'élément est 1 (ou 2, ou 3, ou 4, ou 5, ou 6)

Donc en fait dans un script LUA, on peut soit accéder à "Cels" et exploiter la table retournée par getValue, soit faire des getValue sur ces champs calculés mais je vous laisse vérifier, il est déjà tard.

Sacre100 a écrit:En fait, dans la télémétrie, on peut créer des champs calculés comme ça (cas de la première cellule) :



En indiquant :
- que c'est un capteur de type "Calculé"
- que la formule est "Elément"
- que le capteur d'élément est "Cels"
- que l'index de l'élément est 1 (ou 2, ou 3, ou 4, ou 5, ou 6)

Donc en fait dans un script LUA, on peut soit accéder à "Cels" et exploiter la table retournée par getValue, soit faire des getValue sur ces champs calculés mais je vous laisse vérifier, il est déjà tard.

Ça revient à utiliser le même système que pour Celmin ou Celmax, et les appels de ces valeurs plantent Companion. Ca marche sur la radio mais pas en simu. Il serait quand-même un peu plus simple d'avoir les champs de chaque cels dispo à remplir sous Companion. Les possesseurs de cette radio ne sont pas tous à l'aise avec la prog et n'ont pas tous un Dev.Fred sous la main pour coder un utilitaire ni même un forum comme celui-ci avec toi et les autres pour aider à s'en sortir.

Je vois pas mal de Turnigy aussi qui tournent sous OpenTX, elles sont rarement utilisées à + de 10 ou 20% de leurs possibilités faute de simplicité. Tout ça pour dire que si c'est possible avec complications, une simplification permettrait à pas mal d'utilisateurs de bénéficier de plus de potentiel d'OpenTX plus ou moins réservé à ce jour à une population curieuse, qui a du temps et qui comprends vite un minimum de logique.

Sacre100 a écrit:
N'ouvre pas une issue sur Github, ça me parait normal, si tu as cinq cellules, tu obtiendras une table de 5 éléments, si tu n'en as que 4, tu devrais en obtenir 4.
Il te faut faire une boucle pour traiter élément par élément.
[EDIT]
Pareil avec getValue("GPS"), tu obtiendras une table avec deux éléments : latitude et longitude
Et aussi pour la date et l'heure, tu obtiendras une table.
[/EDIT]

Tu as raison, c'est pas un bug mais une feature, c'est fait exprès mais peu de monde est au courant que dans ces 3 cas, getvalue retourne une table : https://github.com/opentx/opentx/pull/2826
J'ai essayé de rentrer une des valeurs de la table dans CELLS, il ne comprenait pas, ce n'est plus du codage s.port apparemment.

Donc pour simuler la valeur de Cels dans LUA , il faut un programme pour coder au format s.port, non publié, la valeur à entrer dans la case CELLS du simulateur de télémétrie :

Code:

_int16 cell1 = 5;
_int16 cell2 = 0;
_int16 cellNum=1;

  _int16 cell1Data = cell1 * 1000 / 2;
  _int16 cell2Data = cell2 * 1000 / 2;
  _int32 cellData = 0;
  _int32 firstCellNo = 0;

  cellData = cell2Data & 0x0FFF;
  cellData <<= 12;
  cellData |= cell1Data & 0x0FFF;
  cellData <<= 4;
  cellData |= cellNum & 0x0F;
  cellData <<= 4;
  cellData |= firstCellNo & 0x0F;
return cellData;


Et un autre programme pour décoder la valeur dans LUA:

Code:

local cellValue = "unknown"
local cellResult = nil
local cellID = nil

local function rnd(v,d)
    if d then
     return math.floor((v*10^d)+0.5)/(10^d)
    else
     return math.floor(v+0.5)
    end
end

local function getTelemetryId(name)
    field = getFieldInfo(name)
    if field then
      return field.id
    else
      return -1
    end
end

local function init()
  cellId = getTelemetryId("Cels")
end

local function background()
  cellResult = getValue(cellId)
  if (type(cellResult) == "table") then
    cellValue = ""
    for i, v in ipairs(cellResult) do
      cellValue = cellValue .. i .. ": " .. v .. " "
    end
  else
    cellValue = "telemetry not available"
  end
end

local function run(e)
  lcd.clear()

  lcd.drawText(1,1,"OpenTx 2.1.1 testing",0)

  lcd.drawText(1,11,"Cels:", 0)
  lcd.drawText(lcd.getLastPos()+2,11,cellValue,0)
  lcd.drawText(1, 56, "Mem:", 0)
  lcd.drawText(lcd.getLastPos() + 4, 56, rnd(collectgarbage("count"), 4), 0)
end

return{init=init,run=run,background=background}

C'est à peu prêt inutilisable donc.

Salut Heisenberg,
Je ne sais pas si tu lis l'anglais mais j'ai eu une réponse à mon "issue" sur github : https://github.com/opentx/opentx/issues/2915

Pour le moment la simulation de CELLS, GPS-T et GPS-LL dans un script LUA, c'est bon pour les geeks !

Es-tu arrivé à avoir quelque chose de correct avec GPS-LL, ça m'intéresse pour adapter mes scripts.

J'essaye d'utiliser ce code sans succès pour le moment:

Code:

void FrSkySportSensorGps::setData(float lat, float lon, float alt, float speed, float cog, uint8_t year, uint8_t month, uint8_t day, uint8_t hour, uint8_t minute, uint8_t second)
{
  FrSkySportSensorGps::lat = setLatLon(lat, true);
  FrSkySportSensorGps::lon = setLatLon(lon, false);
  FrSkySportSensorGps::cog = cog * 100;
  FrSkySportSensorGps::speed = speed * 1944; // Convert m/s to knots
  FrSkySportSensorGps::alt = alt * 100;
  FrSkySportSensorGps::date = setDateTime(year, month, day, true);
  FrSkySportSensorGps::time = setDateTime(hour, minute, second, false);
}

uint32_t FrSkySportSensorGps::setLatLon(float latLon, bool isLat)
{
  uint32_t data = (uint32_t)((latLon < 0 ? -latLon : latLon) * 60 * 10000) & 0x3FFFFFFF;
  if(isLat == false) data |= 0x80000000;
  if(latLon < 0) data |= 0x40000000;

  return data;
}

J'en suis là, ç'est Ok pour GPS-T mais je n'arrive à rien avec GPS-LL:

Code:

 bool isDate=true;
  _int32 data = 1; //YearorHour;
  data <<= 8;
  data |= 2; //monthOrMinute;
  data <<= 8;
  data |= 10; //dayOrSecond;
  data <<= 8;
  if(isDate == true) data |= 0xFF;
 // return data;
  bool isLat=true;
  float latLon=45;
  data = (_int32)((latLon < 0 ? -latLon : latLon) * 60 * 10000) & 0x3FFFFFFF;
  if(isLat == false) data |= 0x80000000;
  if(latLon < 0) data |= 0x40000000;

  return data;

ça progresse du coté de github, mon cas alimente un appel ouvert par et il reprend mes arguments.

projectkk2glider a écrit:commented 4 minutes ago

Why we don't have the simple possibility to enter until 6 cells values separated by a semicolumn in CELLS and a converter will crunch this string to create the right s.port format internally. And at the other side, getValue able to have a second optionnal parameter, an indice to get the simple value : eg getValue("Cels",4) to get the value of Cels number 4.
GPS-LL, 2 values, longitude;latitude, GPS-T, 6 values, H;M;S;Y;M;D. Something like that.

Nice idea, I've added it to the #2447

Donc il n'y aura peut-être plus besoin de coder-décoder pour utiliser un truc qui devrait être simple

Chouette, c'est une bonne idée que tu as eue.

Pour le getValue, j'imagine que ce serait mieux d'avoir un getCellValue("Cels", 4), au moins c'est ambiguité.

En attendant, ce n'est pas complqué de l'écrire en LUA :

Code:

local function getCellValue(name, position)
  local values = getValue(name)
  if type(values) == "table" and position >= 1 and position <= #values then
    return values[position]
  else
    return nil -- ou tout autre valeur indiquant qu'on n'a rien trouvé
  end
end


dev.fred a écrit:... mais je n'arrive à rien avec GPS-LL ...

Le problème, c'est que GPS envoie la latitude et la longitude séparément.

Alors j'ai essayé d'envoyé deux valeurs, séparée par un espace, par une virgule, par un point-virgule ou même à tour de rôle mais ça ne marche pas :
Latitude 45° -> 0x019BFFC0
Longitude 45° -> 0x819BFCC0

[EDIT]

En fait ça marche à moitié, la latitude est bien renseignée mais la longitude pas du tout.





[/EDIT]

dev.fred a écrit:ça progresse du coté de github, mon cas alimente un appel ouvert par et il reprend mes arguments.

projectkk2glider a écrit:commented 4 minutes ago

Why we don't have the simple possibility to enter until 6 cells values separated by a semicolumn in CELLS and a converter will crunch this string to create the right s.port format internally. And at the other side, getValue able to have a second optionnal parameter, an indice to get the simple value : eg getValue("Cels",4) to get the value of Cels number 4.
GPS-LL, 2 values, longitude;latitude, GPS-T, 6 values, H;M;S;Y;M;D. Something like that.

Nice idea, I've added it to the #2447

Donc il n'y aura peut-être plus besoin de coder-décoder pour utiliser un truc qui devrait être simple

Ahhh là, ce sera opé pour tous !!
Tu causais de synergie, ça paye.