Je me répond, j’avais relancé l’hote esxi est cela avait désactiver le SSH 
, je l’ai remis et tout refonctionne sans soucis.
suggestion :
Un message dans le centre d’alerte de Jeedom recommandant d’activé le SSH de eSXI en cas d’échec de connexion serait peut être une bonne idée 
C’est vrai qu’on ne relance pas souvent l’hôte et que l’on oublie vite qu’il faut réactiver le SSH !!!
@TaG
Petit soucis dont je viens de m’apercevoir, si l’on change le widget affecté à une commande (usage proc ou utilisation ram), cela revient automatiquement à la valeur par défaut au bout de quelques minutes …
Hello,
J’ai rajouté un message en cas de problème de connexion, il arrivera directement dans le centre de message avec l’action conseillée.
J’ai modifié pour que la modification d’un widget soit conservée et non pas écrasée par ce que j’ai mis lors de la création de la commande.
C’est poussé en stable, dis moi si tout est ok @m.georgein s’il te plait.
Merci
Tout est OK en beta,
Et encore merci, un vrai plaisir d’utiliser ce plugin qui ne pose AUCUN problème de fonctionnement et avec un dev réactif en prime !
Merci pour ta validation et ton message d’encouragement :).
Dispo en beta et en stable si tu préfères être en stable 
Salut,
Je viens d’installer le plugin et tout fonctionne parfaitement, mais je souhaitais en cas de batterie faible de mon onduleur tout éteindre proprement. Je peux éteindre mes différentes VM mais je voulais connaitre la technique pour éteindre également L’hôte. Quelqu’un pourrait me donner la technique ?
Merci.
Hello,
C’est quelque chose que je n’ai pas prévu, car je suis partis du principe que jeedom tourne sur l’ESXi.
Mais il est vrai qu’avec l’arrêt automatique des VMs que l’on peut configurer, je peux prévoir d’avoir l’arrêt de l’ESXi.
Reste à faire :
C’est vrai que Jeedom sera éteint j’y avais pas pensé… je ne sais pas si c’est possible.
En tout cas merci à toi de te pencher la dessus à l’occasion.
Bonjour.
Merci pour ce plugin.
Petit retour sur la fonction température des disques :
Sur 9 disques, je n’ai la remontée que de 5 disques. C’est-à-dire que seules 5 commandes sont créées.
4 disques étant du même modèle, le LogicalId des commandes est donc identique.
Liste des disques :
WDC_WD100EZAZ2D11TDBA0 => OK
Hitachi_HDS5C4040ALE630 => OK
ST4000DM0002D1F2168 => OK
WDC_WD100EZAZ2D11TDBA0 => pas de commande créée
ST8000VN00222D2EL112 => OK
ST8000VN00222D2EL112 => pas de commande créée
ST8000VN00222D2EL112 => pas de commande créée
Samsung_SSD_840_PRO_Series => OK
ST4000DM0002D1F2168 => pas de commande créée
Autre chose :
Le relevé de température se base sur smartd (« esxcli storage core device smart get -d… »).
Les valeurs retournées n’étant pas formatées pareils pour tous les constructeurs, ne serait-il pas plutôt possible d’utiliser smartctl pour récupérer ces valeurs ?
Voilà la raison :
Commande smartd :
esxcli storage core device smart get -d t10.ATA_____WDC_WD100EZAZ2D11TDBA0___________________2YK4R05D____________
Parameter Value Threshold Worst
---------------------------- ----- --------- -----
Health Status OK N/A N/A
Media Wearout Indicator N/A N/A N/A
Write Error Count N/A N/A N/A
Read Error Count 0 16 N/A
Power-on Hours 193 0 N/A
Power Cycle Count 52 0 N/A
Reallocated Sector Count 0 5 N/A
Raw Read Error Rate 0 16 N/A
**Drive Temperature 14 0 14**
Driver Rated Max Temperature N/A N/A N/A
Write Sectors TOT Count N/A N/A N/A
Read Sectors TOT Count N/A N/A N/A
Initial Bad Block Count N/A N/A N/A```
Et là, commande smartctl :
smartctl -d sat --all /dev/disks/t10.ATA_____WDC_WD100EZAZ2D11TDBA0___________________2YK4R05D____________
...
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0
2 Throughput_Performance 0x0004 131 131 054 Old_age Offline - 104
3 Spin_Up_Time 0x0007 136 136 024 Pre-fail Always - 483 (Average 485)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 53
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000a 100 100 067 Old_age Always - 0
8 Seek_Time_Performance 0x0004 128 128 020 Old_age Offline - 18
9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 4801
10 Spin_Retry_Count 0x0012 100 100 060 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 52
22 Unknown_Attribute 0x0023 100 100 025 Pre-fail Always - 100
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 416
193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 416
**194 Temperature_Celsius 0x0002 014 014 000 Old_age Always - 24 (Min/Max 12/57)**
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
...
24° dans RAW_VALUE
Hello,
Juste pour te dire que j’ai vu le message. Mais je suis en plein dans les démarches post déménagement.
Beaucoup de papiers à gérer.
Salut,
lorsque tu trouveras 5 minutes, j’ai fait de mon coté une petite modif dans ton plugin.
Dans le cron 5, j’ai ajouté un petit test dans le « foreach » des équipements pour ne pas mettre à jour les informations des VM dont l’équipement est désactivé dans Jeedom.
juste un petit :
$eqLogic->isEnable == 1
dans le if existant.
J’ai pas mal de VM sur mon ESXi que je ne souhaite pas observer (souvent arrêtée) donc pour moi inutile de « spammer » l’ESXi avec des demandes inutiles.
Bref si tu penses que ma modif est intéressante merci de l’intégrer dans tes prochaines versions.
ken@vo
Phil
Hello,
J’ai poussé en stable les dernières modifications de la beta, voir changelog, mais dans le gros changement c’est l’ajout du menu de gauche en cliquant l’icone à gauche du champ Mes équipements VMWARE.
Concernant ta demande @Phil56, je regarde pour pousser ça en beta.
Désolé pour le délai, mais la suite du déménagement plus le covid ne m’ont pas aidé ;).
Mais ce plugin n’est pas abandonné ;).
C’est poussé en beta.
Si tu attends le log du cron 5, tu verras ceci :
[2020-04-20 19:22:31][INFO] : ========================================================
[2020-04-20 19:22:31][INFO] : ================ Début du log - Cron 5 =================
[2020-04-20 19:22:31][INFO] : ========================================================
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH on est sur l’équipement : Android_For_TTS
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH on est sur l’équipement : Jeedom_Beta_Debian_9
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH on est sur l’équipement : Jeedom_Debian9_PHP7_ONLY_Plugins
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH on est sur l’équipement : Ubiquiti_Unifi
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH on est sur l’équipement : Unifi
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH on est sur l’équipement : Debian10_Jeedom
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH on est sur l’équipement : ESXI_PRD
[2020-04-20 19:22:31][DEBUG] : Func cron 5 on a trouvé un ESXi : ESXI_PRD
[2020-04-20 19:22:31][DEBUG] : Login utilisé : backupaccount - Ip de l’ESXi : 192.168.1.225 - Port SSH de l’ESXi :
[2020-04-20 19:22:31][INFO] : ESXi joignable
[2020-04-20 19:22:31][INFO] : Connexion OK à l’ESXi
[2020-04-20 19:22:31][DEBUG] : Apres la connexion
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH Recherche VM - Equipement : Android_For_TTS
[2020-04-20 19:22:31][DEBUG] : Func cron 5 FOREACH Recherche VM - Equipement : Jeedom_Beta_Debian_9
[2020-04-20 19:22:31][DEBUG] : On appelle la commande qui cherche l’ID de la vm à mettre à jour car Active
La VM android_for_tts est désactivé dans jeedom.
Tu la vois passer, mais directement, la VM Jeedom_Beta_debian9 passe derrière et là tu vois le message :
On appelle la commande qui cherche l’ID de la vm à mettre à jour car Active
(donc l’équipement jeedom est actif)
Dis moi si ça te convient
La doc n’est pas encore mise à jour
Bonjour,
j’ai installé la dernière beta et tu ne viens bien tester que les VM actives.
Merci
Ken@vo
Phil
Hello,
Super Merci pour ta confirmation ;)!!
Bonne journée
Bonjour.
Pour ceux qui comme moi se sont arraché les cheveux à faire fonctionner les snapshots.
Voiçi une copie d’écran fonctionnelle.
Certes tout est marqué dans la doc, mais c’est vraiment pas clair ( en tous cas pour moi)
Dans la doc c’est difficile de comprendre qui faut vraiment tapper littéralement dans les champs « Nom= Description= »
je pense que cela mériterai des champs dédié pour n’avoir à taper que les valeurs et non les variables avec.
Alors je me doute que ca facilite la création dans les scénarios, mais manuellement c’est très compliqué je trouve.
Ou idéalement pouvoir faire les deux.
Hello,
J’ai bien compris votre problématique. Pour les champs dédié, ça ne colle pas dans le cadre d’un scénario, si tu regardes tous les plugins qui ont plusieurs options, c’est ainsi que ça fonctionne.
Et si on partait dans l’idée, d’une commande pour les scénarios, deux champs pour la tuile avec un bouton pour lancer, ça devient l’anarchie et idem, ça ne sera pas clair pour les utilisateurs…
N’étant pas un utilisateur qui se sert des tuiles, je n’ai pas pointé du doigt ce problème.
J’essaye de trouver une solution pour la tuile sans devoir en faire une spécifique.
Hello,
Est-ce que ce rendu peut convenir et serait plus parlant ?
Si oui, je pousserai le code à jour pour le texte inclut dans le champ à remplir (nom/description) et indiquerait dans la doc la ligne de code à saisir en personnalisation avancée pour que chacun soit autonome.
Merci pour vos retours.
Bonjour,
Merci pour votre plugin qui est vraiment utile et simple d’utilisation.
Je rencontre un soucis, en effet je dispose de 2 serveurs ESXi (6.5), sur chaque serveurs, il existe des VMs ayant le même nom sur un serveur et sur l’autre.
Voilà donc ce qu’il se passe: Je lance une synchro sur le premier serveur, toute les VMs remontent correctement sur Jeedom.
Ensuite, lorsque je lance une synchro sur le second serveur, les VMs ayant le même nom disparaissent (sur Jeedom) du premier pour apparaître sur le second.
C’est mineur et contournable en modifiant le nom des VMs sur ESXi de manière à éviter les doublons de nom, mais cela ne m’arrange pas trop …
Pensez-vous pouvoir facilement corriger cela de votre côté ?
Merci,
André
bonjour.
Je voudrai faire des scénarios avec l’état des VM
Mais attendre 1h pour remonter si une VM est allumé ou éteinte c’est pas viable
Comment le passer à la minute ? il faut désactiver le cron hourly ?
