Problème sur Min/Max

Salon des Bêta-Testeurs Core V4 (BugsReports)
1

Bonjour,

Je viens de voir que les minValue et maxValue sont initialisés arbitrairement à ‹ 0 › ou ‹ 100 › lors de leurs transpo dans les widget (’#minValue#’ et ‹ #maxValue# ›) si on les laissent ‹ non renseignés ›.

D’autant plus curieux que en BdD ils sont bien dans ce cas égal à «  » et que le filtrage des valeurs lues par les min/max acceptent n’importe quelles valeurs du moment qu’ils ne sont pas renseignés.

Cette initialisation est pénalisante dans les codes de widget et oblige à ajouter des conditions inutiles ( if ==0, if ==100 …) si l’on utilise, comme c’est mon cas le fait que les min/max sont ou ne sont pas renseignés.

De plus la plage 0-100 n’est pas universelle, le rssi de BLEA utilise -200-0, les volets souvent la plage 0-199 (0-99 fermé, 100-199 ouvert), etc.

2

Bonjour,
Oui tout a fait c’est normal il faut si ça va pas le corriger toi

3

C’est malheureusement impossible à corriger puisque l’on a pas accès à la valeur paramétrée en min/max mais seulement à la valeur RECALCULEE !!!

Par ailleurs je vois que les widget core s’attendent eux aussi à ce que ces valeurs puissent être vide :

    min: ('#minValue#' == '') ? 0 : parseInt('#minValue#'),
    max: ('#maxValue#' == '') ? 100 : parseInt('#maxValue#'),
    value: ('#state#' == '') ? 0 : parseInt(_options.display_value),

Donc je ne vois pas l’intérêt de ce calcul forcé des valeurs Min/Max.

4

Ben dans la configuration avancé de la commande tu peux changer le min/max.

Oui les widgets ont une double sécurité pour éviter de planter tous le js.

5

Changer la valeur Min/MAX n’avancera à rien. Je vais essayer de donner un exemple :

Supposons que je veuille calculer la valeur d’une commande comme égale à #minValue# SI celui ci est paramétré, sinon comme égal à #minHistoryValue#. Problème simple :wink: et très courant je pense.

Seulement là, comme #minValue# est TOUJOURS recalculé à ‹ 0 › si pas paramétré (vide donc), c’est un min = ‹ 0 › qui sera exploité.

Bien sur je peux faire :
value = (’#minValue#’ != 0 ? ‹ #minValue# › : ‹ #minHistoryValue# ›)

Seulement dans ce cas je ne pourrais plus jamais exploiter VOLONTAIREMENT la valeur ‹ 0 › !!! sauf à bidouiller en mettant en min ‹ 0.001 › par exemple … pas très élégant :frowning:

Bien sur le problème est le même pour le Max.

Cette problématique est relativement courante si on travaille sur des widget de visualisation.

6

Euh tu veux faire quoi je comprends pas trop la…

7

sorry, je vais essayer d’être plus clair,

je voudrais que la ligne suivante soit exploitable :

min: (’#minValue#’ == ‹  ›) ? parseInt(‘#minHistoryValue#’) : parseInt(’#minValue#’),

Actuellement cela renverra TOUJOURS ‹ 0 › puisque le minValue est forcé à 0 si vide

Si pour pallier au problème si je fait :

min: (’#minValue#’ == 0) ? ‘#minHistoryValue#’ : parseInt(’#minValue#’),

Là, je ne peut plus utiliser la valeur ‹ 0 › pour le min … donc obligé d’utiliser une argutie du genre min = 0.0001

Le besoin existe par exemple pour calculer les bornes d’affichage min/max d’une jauge.

8

Ben les borne d’affichage sont toujours au pire le minhistorize et le maxhistorize donc je comprends pas trop. Surtout que si le mec active pas l’envoi des historize ça marche plus ton truc…

9

Une image va aider :slight_smile: :

Capture

Deux jauges de tension, à gauche avec un mini de ‹ 0 › (valeur par défaut actuellement), à droite avec un mini à ‹ minHistoryValue ›

Maintenant si je force le mini à 230 cela donne :

Capture1

Donc le but est : si je met ‹ 0 › ou rien) ou ‹ 230 › dans le mini j’ai l’image de gauche ou du bas,

Par contre si je ne RENSEIGNE PAS le mini j’ai l’image de droite avec une échelle complète basé sur l’histo et c’est cela qui n’es pas possible de faire actuellement ! :frowning:

10

Ok je comprends mais honnêtement je suis pas motivé pour faire le changement, a chaque fois que j’ai fait ça je n’ai pas maîtrisé les effets de bord et j’en ai pris plein la tête…

11

Alors pour essayer de te motiver :slight_smile: je le dirais d’une autre manière :wink:

Ces min/max sont au premier chef utilisé dans :

  1. Le filtrage des valeurs en provenance des capteurs, actuellement si non renseigné, pas de filtrage, et c’est donc OK.
  2. Dans les widget, les widget core ont déjà prévus le coup via des lignes du type :
    min: (’#minValue#’ == ‹  ›) ? 0 : parseInt(’#minValue#’),
    max: (’#maxValue#’ == ‹  ›) ? 100 : parseInt(’#maxValue#’),

Les bornes recalculées a ‹ 0 › et ‹ 100 › et sont TOTALEMENTarbitraire (BLEA -200, volet 0-199, beaucoup d’équipement sont à 0-255, etc) et donc dangereuse.

C’est pour ces raisons que je pense que le bout de code gérant ces recalculs doit être une séquelle historique pas encore nettoyé pour l’instant. Mais l’intérêt de la V4 n’est il pas de remettre les choses à plat et de nettoyer au maximum ?

Et pour ce qui est d’en prendre plein la tronche, attend la sortie de la V4 :):grin::smile::joy: !!!

12

On va déjà en prendre plein la tête en v4 je peux pas empiler encore ça qui peut casser le js de widget tierce encore une fois. Désolé mais déjà là ça va être très dur de tout encaisser je peux pas faire plus.

Quand je vois rien que ici en comité réduis ce que c’est j’ai vraiment peur quand ça sera ouvert a tous.

13

Les widget tierce … de toute manière il va falloir qu’ils soient retravaillés, c’est un acquis en V4, alors un peu plus, un peu moins … :slight_smile:

Et de ce que j’ai vu tous le monde a gérés les valeurs par defaut des ‹ #xxxxxx# › en s’appuyant sur les exemples du core.

Honnêtement, je ne pense pas que la suppression de cette verrue dans le code générera plus de problèmes, au contraire.

Je vois mon exemple, il m’a fallu quelques heures pour trouver l’origine de l’anomalie d’affichage de mes jauges, et ensuite me convaincre moi même que c’était un recalcul forcé de CES valeurs.

Quoiqu’il en soit, pourrais tu me dire ou se trouve ce recalcul dans le code, cela me permettrait de le gérer à minima sur mes install … Merci d’avance

14

J’ai viré le 0/100 par defaut je te dis pas que ca reste comme ca si je vois des effets de bord mais j’aurais essayé au moins

15

Merci Loîc,

Ca devrait passer j’ai fait la modif chez moi depuis 15 jours (plus de 200 widgets) et je n’ai vu aucun problème remonté, pour l’instant :wink:

16

Depuis la modif j’ai un soucis sur un core horizontal

Capture

Si je met des min/max sur l’info et sur l’action (le slider en dessous) :

Capture2

Bon dans l’absolu, je devrait avoir des min/max sur une telle commande, on est d’accord …

17

Bon j’ai du faire un retour arrière sur cette modification elle est trop impactante en plus dans certain cas de devoir ajouter un peu de code et donc de ralentir jeedom (surtout en mobile ou le min/max sont en attribut de balise html)