depuis l’alpha 4.5, il y a eu un changement sur les #trigger# des scénarios.
#trigger# : Peut être :
api si le lancement a été déclenché par l’API,
TYPEcmd si le lancement a été déclenché par une commande, avec TYPE remplacé par l’id du plugin (ex virtualCmd),
schedule s’il a été lancé par une programmation,
user s’il a été lancé manuellement,
start pour un lancement au démarrage de Jeedom.
Or, le plugin Alarme utilise lui-aussi le tag #trigger#
Les tags possible sont :
#mode# : nom du mode en cours
#trigger# : nom de la commande qui a déclenché l’alerte
#zone# : nom de la zone de la commande qui a déclenché l’alerte
De fait, lorsque l’alarme est déclenchée, #trigger# prend désormais la valeur de « other » au-lieu d’être le nom de la commande qui a déclenché l’alerte.
Du coup, mes scénarios de déclenchement ne fonctionnent plus…
La mise a jour est disponible en beta. Attention le tag #trigger# devient #alarm_trigger#, c’est a vous de faire le changement (celui ci ne pouvant être fait automatiquement sans risqué de faire des changement non voulu désolé).
ok, normal de pas modifier le tag dans les scénarios du coup, par contre dans les champs même des actions du plugin alarme s’il y avait #trigger# ca sera d’office le trigger de l’alarme, donc je pense que tu peux le modifier en #alarm_trigger# par remplacement, ca cassera moins chez les gens…
une sorte de truc comme ça dans appelé dans install.php et la fonction alarm_update (fait avec chatGPT, donc peut-etre pas exactement ce qu’il faut faire, mais c’est pour l’idée de prendre le champ configuration comme un seul champ et pas chaque valeur json…) :
public static function updateConfigurationTrigger() {
// Sélectionner toutes les lignes où eqType_name est 'alarm' et où configuration contient #trigger#
$sql = 'SELECT id, configuration FROM eqLogic WHERE eqType_name = :eqType_name AND configuration LIKE :pattern';
$values = array(
'eqType_name' => 'alarm',
'pattern' => '%#trigger#%'
);
// Récupération des enregistrements concernés
$rows = DB::Prepare($sql, $values, DB::FETCH_TYPE_ALL, PDO::FETCH_ASSOC);
foreach ($rows as $row) {
// Remplacement de toutes les occurrences de #trigger# par #alarm_trigger# dans le JSON
$updatedConfiguration = str_replace('#trigger#', '#alarm_trigger#', $row['configuration']);
// Mise à jour dans la base de données
$updateSql = 'UPDATE eqLogic SET configuration = :configuration WHERE id = :id';
$updateValues = array(
'configuration' => $updatedConfiguration,
'id' => $row['id']
);
// Exécution de la requête d'update
DB::Prepare($updateSql, $updateValues, DB::FETCH_TYPE_NONE);
}
}
Bonjour,
C’est ajouté mais je maintiens que c’est une belle connerie, après c’est vous les utilisateurs pas moi mais a chaque fois que j’ai fait ce genre de truc sur jeedom j’ai eu une tonne de merde derriere, mieux vaut laisser l’utilisateur faire cette migration c’est beaucoup plus sur.
Car la version 4.5 du core comme l’indique le changelog revoit une grosse partie des scénario pour permettre l’instanciation des tags et donc toute ca partie et maintenant il n’est plus possible d’écraser les tags propre au scénario
