Envoyer un webhook avec variable depuis Uptime Kuma

[Ocbsd]

Bonjour La communauté,

Afin de surveiller mon réseau indépendamment de Jeedom, j’ai installé Uptime Kuma dans un container Docker indépendant de Jeedom.

Jeedom est installé sur une VM Proxmox, ainsi que MQTT, Z2M et Zwave dans des Lxc de la même machine.

Mon objectif initial était de jeter un oeil sur Uptime Kuma, pour surveiller mon réseau. Hors il est possible d’envoyer de Uptime Kuma des Notifications et notamment en Webhook.

J’arrive sans problème à envoyer un webhook sur un virtuel ou un scénario, j’arrive à envoyer des tags avec des valeurs fixes, mais je n’arrive pas à envoyer des tags avec variables. Mon but étant, avec un scénario si une machine change de statut je mets à jour le statut de la machine dans un virtuel. Pour cela il faut deux Tags : IP ou nom de la machine et statut. mais impossible d’intégrer ces variables dans le webhook.

Pour précision, Uptime Kuma, envoie une notification à chaque changement de statut, mais on ne peut pas choisir d’envoyer la notification si c’est UP ou si c’est DOWN.

On peut envoyer des données variables, mais je n’y arrive pas, le format des variables est sous format “liquid”, et n’est pas reconnu par Jeedom

Ce qui est très intéressant avec Uptime Kuma est qu’il peut tester les équipements en ICMP, Http, TCP et même Mqtt (je vais testé prochainement pour voir la disponibilité de mon contrôleur Zwave) . Uptime Kuma a également une API, mais mon niveau de connaissance ne me permet pas d’exploiter cette piste.

Ma question est donc avez-vous réussi à envoyer des notifications avec des tags avec des valeurs variables dans Jeedom à partir d’uptime Kuma ?

[Mips]

Bonjour,

mais votre question ne concerne pas jeedom, mais uptimekuma… => post déplacé

[Ocbsd]

Bonjour Mips,

Oui et Non, pour être plus précis, mes interrogations sont de savoir :

• si une personne à réussie à exploiter des données de Uptime Kuma dans Jeedom
• si une personne a réussi sous Jeedom à exploiter des variables envoyées à Jeedom sous format “Liquid”.

[Mips]

je pense que vous êtes déjà trop loin avant de réfléchir à cette question, une autre question se pose avant: pourquoi faire? pourquoi vouloir envoyer ça à jeedom?
et quid si jeedom est déjà down?

perso j’ai gardé uptimekuma séparé, il peut envoyer des notifs mail, telegram, sms etc aussi

[Ocbsd]

J’avais une idée en tête.

Mon contrôleur Zwave est une clé Aeotec 700 montée sur un SLZB MR1U.

De temps en temps (rarement je l’accorde) je dois rebooter le SLZB, car le contrôleur se déconnecte.

Mon but étant je fais un ping sur le Lxc zwave, je controle si le topic Zwave est Ok (via la surveillance Mqtt). et si il y a un probléme, je reboot le SLZB

Le but n’est pas d’intégrer totalement Uptime Kuma dans Jeedom, mais de faire des actions automatiques sur quelques équipements

[Mips]

pas besoin de uptimekuma pour ca, tout peut etre fait depuis jeedom; et pour le coup, si jeedom est down, on s’en fiche que zwave soit down ou up

[Ocbsd]

Ok, je comprends, mais c’était par sécurité, en effet j’utilise l’intégration Uptime Kuma d’Home assistant, qui remonte tous les équipements ainsi que leurs statuts en temps réel. Donc si jeedom Down → notif d’home assistant. L’intérêt est qu’avec un scénario et des tags, on peut tout faire…

Un plus cela fait une base commune, HA et Jeedom…

[Mips]

à chaque message ca part dans une autre direction…

au début c’était intégré uptime kuma avec jeedom, ensuite le but c’était de monitorer si zwave était up pour rédamarrer le smilight et maintenant vous parler de l’intégration avec home assistant…

si uptimekuma est intégré avec HA, gérez le là-bas… encore une fois ca n’a aucun intérêt de vouloir gérer un flux uptimekuma => jeedom dans ce cas car

• si uptimekuma est up, HA aussi (sinon il serait down)
• l’intégration est probablement déjà en place
• rien ne garanti que jeedom soit up à ce moment là par contre

et encore une fois, aucun besoin de cette usine à gaz pour le besoin:

@Ocbsd

Mon but étant je fait un ping sur le Lxc zwave, je controle si le topic Zwave est Ok (via la surveillance Mqtt). et si il y a un probléme, je reboot le SLZB

(pas besoin du ping non plus d’ailleurs)
il suffit d’avoir:

• une commande info qui donne la valeur du topic
• une commande action pour reboot le slzb
• un scénario qui déclenche sur la commande info, vérifie la valeur éventuellement et utilise la commande action

[Ocbsd]

@Mips

à chaque message ca part dans une autre direction…

au début c’était intégré uptime kuma avec jeedom, ensuite le but c’était de monitorer si zwave était up pour rédamarrer le smilight et maintenant vous parler de l’intégration avec home assistant…​

Ok, je pense arrêter la discussion ici, en effet je pense que sur une question générale au début, j’ai ensuite donné des exemples et motivé l’intérêt de ma question initiale, c’était simplement une question générale, et surtout je répondais à votre question :

@Mips

je pense que vous êtes déjà trop loin avant de réfléchir à cette question, une autre question se pose avant: pourquoi faire? pourquoi vouloir envoyer ça à jeedom?
et quid si jeedom est déjà down?

@Mips

si uptimekuma est intégré avec HA, gérez le là-bas… encore une fois ca n’a aucun intérêt de vouloir gérer un flux uptimekuma

Non, HA est sur une VM Proxmox, Uptime Kuma est sur une machine à part, L’intégration HA demande simplement l’IP de Kuma et une clé API. Je parle d’intégration pas d’application.

[TonioBDS]

Hello, je tombe sur ce post alors que je suis en train de configurer mon nouveau miniPC, avec proxmox et un VM qui fait tourner une 20aine de dockers.
Je recherche un moyen d’afficher dans jeedom un status de toutes mes sondes kuma.
Pour l’instant le seul moyen que j’imagine est de créer autant de webhook que j’ai de sonde dans kuma associé à un virtuel/info… donc assez lourd à mettre en place et ne se met pas à jour automatiquement.
Si qqn connait une méthode plus élégante…

[Mips]

Pour intégrer kuma ou pour remonter le statut (et plus si affinités) de vm/lxc proxmox sur jeedom?
Pour le 2eme cas il y a plugin-proxmox

[TonioBDS]

Merci pour l’info, pour le coup ce plugin est capable de bcp plus.
Pour l’instant un script dans un bloc code me permet de récupérer sur un virtuel le status de toutes mes sondes kuma, reste à mettre en forme…

[Ocbsd]

Bonjour @TonioBDS,

Votre solution semble trés interressante, pouvez-vous expliquer ce que fait votre script exactement.

Pour le moment je suis obligé de traiter les infos sous Home Assistant, mais je souhaite plutôt le faire sous jeedom

[ZygOm4t1k]

Salut

L’api semble quand même la meilleure des solutions pour automatiser tout ca

Depuis Jeedom, on peut se connecter à Uptime Kuma via l’api et faire les deux opérations :

1. Récupérer les monitors Kuma. On peut imaginer créer automatiquement un équipement Jeedom par monitor
2. Créer la notification Webhook dans Kuma en pouvant la modifier, la tester ou la supprimer

[TonioBDS]

J’ai commencé par créer une page de status dans Kuma avec toutes mes sondes dessus. Ca permet ensuite avec un peu de code d’accéder à toutes les infos sans identifiants (à voir si tu acceptes ça !).

Ensuite tu crées un équipement virtuel vide et tu récupères son id. Cet équipement regroupera toutes les info Up/Down de tes sondes.

Puis un scenario qui tourne régulièrement (pas plus fréquemment que tes sondes, car sinon ça sert à rien), avec un bloc code (merci Gemini) qui va scruter la page https://IPkuma/api/status-page/heartbeat/livestatus pour les noms des sondes et leur id et https://IPkuma/api/status-page/heartbeat/livestatus pour leur santé.

Le code parcours ça et crée les commande infos si elle n’existent pas :

// --- CONFIGURATION ---
$kuma_config_url = "https://IPkuma/api/status-page/livestatus";
$kuma_hb_url     = "https://IPkuma/api/status-page/heartbeat/livestatus";
$eqLogic_id      = 1246; // ID du Virtuel "Uptime Kuma"

// 1. Charger l'équipement virtuel
$eqLogic = eqLogic::byId($eqLogic_id);
if (!is_object($eqLogic)) {
    $scenario->setLog("Erreur : Impossible de trouver l'équipement virtuel ID " . $eqLogic_id);
    return;
}

// 2. Interrogation des endpoints Uptime Kuma
try {
    // Récupération de la liste des sondes (Noms & IDs)
    $config_json = file_get_contents($kuma_config_url);
    if ($config_json === false) throw new Exception("Impossible de contacter la configuration Kuma.");
    $config_data = json_decode($config_json, true);

    // Récupération des états (Heartbeats)
    $hb_json = file_get_contents($kuma_hb_url);
    if ($hb_json === false) throw new Exception("Impossible de contacter les heartbeats Kuma.");
    $hb_data = json_decode($hb_json, true);
    $heartbeats = isset($hb_data['heartbeatList']) ? $hb_data['heartbeatList'] : array();

} catch (Exception $e) {
    $scenario->setLog("Erreur Uptime Kuma : " . $e->getMessage());
    return;
}

// 3. Extraction des sondes
$monitors = array();
if (isset($config_data['publicGroupList'])) {
    foreach ($config_data['publicGroupList'] as $group) {
        if (isset($group['monitorList'])) {
            foreach ($group['monitorList'] as $monitor) {
                $monitors[strval($monitor['id'])] = $monitor['name'];
            }
        }
    }
}

// 4. Parcourir les sondes et mettre à jour / créer dans Jeedom
foreach ($monitors as $m_id => $m_name) {
    
    // Déterminer le statut courant (1 = UP, 0 = DOWN)
    $status = 0;
    if (isset($heartbeats[$m_id]) && count($heartbeats[$m_id]) > 0) {
        $last_hb = end($heartbeats[$m_id]);
        if (isset($last_hb['status']) && $last_hb['status'] == 1) {
            $status = 1;
        }
    }

    // Chercher si la commande existe déjà dans le Virtuel
    $cmd = $eqLogic->getCmd('info', $m_name);

    // Si elle n'existe pas, ON LA CRÉE AUTOMATIQUEMENT
    if (!is_object($cmd)) {
        $scenario->setLog("Création automatique de la commande : " . $m_name);
        $cmd = new cmd();
        $cmd->setName($m_name);
        $cmd->setLogicalId($m_name);
        $cmd->setEqLogic_id($eqLogic_id);
        $cmd->setType('info');
        $cmd->setSubType('binary'); // Info Binaire (0/1)
        $cmd->setDisplay('generic_type', 'GENERIC_INFO');
        $cmd->save();
    }

    // Mettre à jour la valeur de la commande
    $cmd->event($status);
    $scenario->setLog("Sonde : " . $m_name . " -> Statut : " . $status);
}

Je suis pas encore ultra satisfait de la mise en forme, pour l’instant en tableau avec un widget rond vert ou rouge :

[ZygOm4t1k]

Salut

Je ne connaissais pas mais j’ai essayé et l’essayer c 'est l’adopter

J’ai fait un petit plugin

avec un équipement source

et après sync il crée les sondes avec les commandes

Et les widgets . A gauche la source et a droite les sondes

Me reste a voir la création d’un webhook depuis jeedom pour une sonde en passant l’id de la commande état et récupérer le status pour le transmettre a jeedom

[Ocbsd]

Bonjour @ZygOm4t1k

Vous avez fait un truc de dingue. Par contre j’ai une question, l’info est demandée par jeedom à uptime-kuma toutes les x minutes, ou uptime-kuma envoie les infos lorsqu’il y a un changement.

Actuellement je travail sur un stack qui envoie à jeedom (au demarrage et toutes les heures) l’inventaire de toutes les sondes avec leur état, puis envoie toute les minutes les changements des sondes concernées. Aprés il faut l’exploiter…

[ZygOm4t1k]

Salut

Le plugin utilise deux mécanismes complémentaires :

• Un démon interroge périodiquement Uptime Kuma. La fréquence est configurable. Il met à jour dans Jeedom le statut, le ping, le message et la date de dernière vérification de chaque sonde/moniteur.

• Un webhook est créé comme notification dans Uptime Kuma et associé à chaque sonde. Lors d’un changement d’état, Uptime Kuma envoie immédiatement l’événement à Jeedom, sans attendre le prochain passage du démon. C’est une remontée quasiment en temps réel.

Le démon assure la synchronisation régulière des informations et le rattrapage d’un éventuel événement manqué.

[Ocbsd]

Ok, je viens de finaliser le container, le principe est donc le suivant : lors du demarrage et toutes les heures le container envoie à Jeedom dans une commande d’un virtuel jeedom, l’ensemble des sondes avec l’etat (up ou down). Puis toutes les minutes si l’etat des sondes change, le container envoie dans la même commande, les sondes qui ont changées, si pas de changement, pas d’envoi.

Un scénario exploite les infos de la commande, fait une correspondance entre sonde et commande du virtuel contenant les sondes selectionnées.

Mon but n’est pas de faire l’inventaire des sondes d’Uptime Kuma, mais d’en retenir quelques unes. Pour infos j’ai environ 60 sondes, il y en a environ 15 que je dois surveiller. Si cela intéresse des personnes, je fais encore quelques tests et je fais un tuto.

[TonioBDS]

Hello !
Il est téléchargeable pour test ce plugin ? j’ai tenté “kuma” sur le market mais sans succès !
Merci !