Core en 4.1.23 et répétition de valeurs binaires

Salon des Développeurs Core V4 (dev)
1

Bonjour à tous,

je ne comprends pas la dernière mise à jour de la fonction eqLogic::checkAndUpdateCmd

		} else if ($cmd->getConfiguration('repeatEventManagement', 'auto') == 'always' || ($cmd->getSubType() == 'binary' && $cmd->getConfiguration('repeatEventManagement', 'auto') == 'auto')) {
			$cmd->event($_value, $_updateTime);
			return true;
		}

Avant on avait :
} else if ($cmd->getConfiguration('repeatEventManagement', 'auto') == 'always') {

Pourquoi traiter différemment des données de types différentes de façon différentes ?
Cela impacte les utilisateurs non ? ils doivent aller dans chaque commandes infos binaires pour modifier la répétition (un énorme travail).

Ou alors j’ai loupé un truc à mettre dans nos plugins ?

Je serai d’avis d’un rollback rapide… (sauf si on m’aide à comprendre svp)

1 « J'aime »
2

Salut,

Je n’ai pas encore regardé en détails le changement et je ne sais pas pourquoi cela impact certain mais le type binaire a, en principe, toujours été répété en mode auto, cf ce vieil article Répétition de la valeur des commandes – Jeedom – Le Blog

3

Oui, je me rappelle qu’a l’époque justement il y avait eu une mise à jour pour supprimer les répétitions sur toutes les valeurs. Cela permettait de ne pas surcharger Jeedom et de ne provoquer les évènements qu’au changement de valeur.

Là on revient en arrière…

4

oui il y a une incidence CPU aussi

5

Oui, j’étais occupé à regarder l’historique pour comprendre si vraiment c’était « un retour en arrière » ou autre chose qui avait été fait.
Avant de re-changer quoi que ce soit je pense qu’il faut comprendre le problème qu’il y avait à l’origine, comprendre celui qui a induit ce fix et comprendre le problème actuel pour pouvoir se faire une opinion et une recommandation, my 2 cents.

6

oui d’ou ca aurait été intéressant que ca soit préparé… là on se retrouve sur le fait accompli…

1 « J'aime »
7

En fait, il y a plusieurs types d’incidences : l’incidence CPU, mais aussi la contrainte que si un utilisateur a mis cela dans un scénario en déclencheur, et bien il sera aussi embêté.

Et puis je me répète, mais pk traiter de deux façons différentes deux types de données…

@Mips je suis d’accord avec toi pour le « comprendre pk cela a été en place ». Mais cela me dépasse. on Tag qui ?

EDIT : @nebz même pire que nous. Les utilisateurs sont réellement embêtés …

1 « J'aime »
8

Je pense qu’on est tous les 3 d’accord, faut mieux en discuter avant qu’après, ce n’est pas la première fois qu’on a ce débat.

Ca je ne sais pas mais à présent je suis assez certain que si cela était changé pour avoir le même comportement, on aurait autant de personne impactées parce que tel historique n’est pas à jour ou tel scénario ne se déclenche plus alors qu’avant ca marchait en mode « auto » et plus maintenant :frowning:

2 « J'aime »
9

@Alexandre @Loic ? Une info là dessus svp ? un avis ?

10

C’est pareil pour jeemate qui peux énormément communiqué, des fois plusieurs fois par seconde. Et je vous avoue que sa l’impacte énormément.

Cordialement
Thibaut

1 « J'aime »
11

Trop de plugins impactés : rfxcom, zwave de mon côté.
Faire la moulinette proposée sur le forum… Je ne trouve pas que se soit une bonne solution…

12

@Jeedom-Team ?

13

Bonjour à tous,

Il semble que le dernier changelog du core était un peu trop alarmiste à en croire l’encre que cela fait couler.

Pour commencer, oui le changelog sur ce point est bien plus alarmiste que la réalité et est surtout là pour permettre aux quelques utilisateurs qui seraient concernés de savoir où chercher.

Bien entendu que si l’équipe passe une modification en indiquant qu’elle corrige un dysfonctionnement il s’agit bien d’une correction de bug et rien d’autre.

@Mips a entièrement raison, les commandes binaires ont toujours été traitées en Toujours répéter en mode auto contrairement aux autres sous-types d’infos dans Jeedom. Cela s’explique par le fait que les informations binaires nécessitent souvent d’être répétées par défaut (détecteur de mouvement, bouton de télécommande, etc).

La fonction event fait ce distinguo depuis la 2.4.6 tel qu’indiqué dans le lien vers l’article du blog sur le second message de ce sujet.

Il s’avère que la plus récente fonction checkAndUpdateCmd ne prenait pas en compte le cas particulier des infos binaires et avait donc un fonctionnement différent de la fonction event au final alors que ces 2 fonctions ont le même but dans 2 classes différentes.

Il s’agit donc bien d’une correction de bug, mise en place dans l’urgence afin de justement garantir le fonctionnement cohérent des plugins tiers et officiels sans avoir à intervenir sur ceux-ci.
Seuls certains plugins vont nécessiter de positionner les commandes info/binaire sur ne jamais répéter : ceux utilisant un démon qui interroge une api qui ne date pas les évènements (IPX800, Philips Hue, etc). C’est inutile pour les autres plugins comme zigbee, openzwave, rfxcom ou enocean par exemple.

Pour finir, la gestion de la répétition des commandes devrait être largement simplifiée en 4.2.

14

Je suis d’accord avec toi pour la répétition d’info interrupteur, mais je n’en vois aucun intérêt pour la répétition d’une ouverture de porte… Cela peut engendrer des faux positifs.

Une proposition, nous mettre un paramètre en plus à la fonction repeatEventManagement pour nous permettre de gérer le type de répétition ?


	public function checkAndUpdateCmd($_logicalId, $_value, $_updateTime = null, $_noRepeat=false) {
		if ($this->getIsEnable() == 0) {
			return false;
		}
		$cmd = is_object($_logicalId) ? $_logicalId : $this->getCmd('info', $_logicalId);
		if (!is_object($cmd)) {
			return false;
		}
		$oldValue = $cmd->execCmd();
		if ($oldValue !== $cmd->formatValue($_value) || $oldValue === '') {
			$cmd->event($_value, $_updateTime);
			return true;
		}
		if ($_updateTime !== null && $_updateTime !== false) {
			if (strtotime($cmd->getCollectDate()) < strtotime($_updateTime)) {
				$cmd->event($_value, $_updateTime);
				return true;
			}
			return false;
		} else if ($_noRepeat===false && ($cmd->getConfiguration('repeatEventManagement', 'auto') == 'always' || ($cmd->getSubType() == 'binary' && $cmd->getConfiguration('repeatEventManagement', 'auto') == 'auto'))) {
			$cmd->event($_value, $_updateTime);
			return true;
		}
		if ($_updateTime !== false) {
			$cmd->setCache('collectDate', date('Y-m-d H:i:s'));
			$this->setStatus(array('lastCommunication' => date('Y-m-d H:i:s'), 'timeout' => 0));
		}
		return false;
	}

(j’ai tapé ça à la va vite, à voir si pas d’erreurs)

Cela modifie seulement deux lignes à la fonction actuelle, ne change pas le fonctionnement de la fonction, et nous permet de gérer les différents types d’infos binaires (ou autres)

15

Comme indiqué en conclusion de mon message, la gestion de la répétition des commandes sera simplifié en 4.2 donc pas de nouvelles option en prévision

16

@Salvialf, j’ai lu tes messages sur le post « Relance systématique »
Tu penses que pas grand monde sera impacté, mais je pense le contraire :slight_smile:
j’ai déjà remarqué que c’est idem avec les plugins rfxcom et openzwave (je ne suis pas allé plus loin).

Les utilisateurs qui utilisent par exemple comme déclencheur de scénario un capteur d’ouverture de porte, et bien ils vont êtres embêtés.

J’ai du mal à concevoir un tel changement sans prendre en compte les utilisations existantes.

Surtout qu’a l’époque (il y a quelques années) on nous a fait pareil dans le sens inverse : Toutes les commandes se répétaient, et après une mise à jour, les répétitions étaient ignorées.

Cela ne concerne pas les plugins, mais cela concerne comment un équipement remonte l’information à un plugin : S’il répète l’info ou pas et comment le plugin l’interprète.
De mon côté j’ai surchargé la fonction, car trop d’utilisateurs sont venus vers moi pour me dire qu’il avaient ce soucis maintenant, et pensaient que cela venait du plugin …

Il y aura un impact (et il y en a déjà 1) … Après c’est un choix, soit on réagit vite, soit on laisse faire :wink:

17

Ce que j’avance est facilement vérifiable par un développeur… le plugin zwave, par exemple, n’utilise pas checkandupdatecmd mais event donc pas de changement.

18

alors autant pour moi tout va bien ^^

19

Du coup on préconise l’utilisation de event ou de checkAndUpdateCmd ?

20

C’est sensiblement la même idée sauf que le premier s’utilise depuis l’équipement directement alors qu’event depuis un objet $cmd.

Comme expliqué plus haut, event a toujours répété les infos binaires ce qui n’était pas toujours le cas pour checkAndUpdateCmd avant correction.

A mon sens je dirai que l’important est de bien préconfigurer les commandes infos binaire à ne jamais répéter si ce n’est pas nécessaire.

1 « J'aime »