Post de nouveaux clips Twitch sur Discord

On utilise l’outil Make : https://www.make.com/

Le nombre de transactions étant limité avec les comptes gratuits, on fera tourner le script une fois par jour pour récupérer les clips créés durant les 24 dernières heures.

Vue globale du scénario :

Paramétrage de la box twitch qui permet de récupérer les clips sur le jour précédent :

Paramétrage du filtre pour ne récupérer que les clips avec un titre :

Paramétrage de l’Iterator qui permet de boucler dans la liste des Clips retrouvés :

Paramétrage de l’outil Sleep. Il permet d’éviter le flood dans discord, sans cette temporisation discord bloque la publication trop rapide des messages :

Paramétrage de la box Discord pour la publication :

Paramétrage de la planification. On fait tourner le script une fois par jour (ici à 1h00 du matin) :

Ne pas oublier de mettre le script sur « ON » une fois que les tests sont terminés (le bouton « Run once » permet de lancer le script manuellement).

LoraGate Lixee / configuration et premiers tests

La LoraGate est un modem Lora qui permet de recevoir et émettre des données sur un réseau LoraWan. Elle est disponible dans la boutique Lixee.

Prérequis : disposer d’un compte sur le réseau The Thinks Network (TTN), d’une gateway Lora (exemple en indoor facilement configurable sur TTN : Gateway TTIG) ou être à porté d’une antenne publique du réseau TTN et avoir créé son application dans TTN.

Création du device loragate dans TTN

Dans la console TTN au niveau application, ajouter un end device :

Choisir l’onglet « manually » :

Choisir les paramètres suivants :

Dans les paramètres avancés, laisser l’activation OTAA et choisir la classe C (on peut choisir d’autres options mais la suite de cette doc se base sur cette configuration) :

Générer le DevEUI et l’AppKEY, et remplir l’AppEUI avec des zéros.

Choisir un identifiant pour le device et valider la création :

Configuration de la loragate

J’utilise ici Tera Term sous Windows pour envoyer les commandes AT.

Brancher la loragate sur un port usb et relever le port série dans le gestionnaire de périphériques de windows.

Dans Tera Term, créer une nouvelle connexion série :

Dans le menu Setup -> serial port, configurer la vitesse sur 115200 :

Ouvrir la fenêtre des commandes broadcast depuis le menu Control -> Broadcast command et décocher « Realtime mode » et cocher « send to this process only » :

Tester la connexion en envoyant la commande AT+CGMI?. La réponse devrait être la suivante :

Pour configurer la clef, envoyer les commandes suivantes :

AT+CDEVEUI=XXXXXXXXXXXXXXXX en remplaçant les X par les 16 caractères du DevEUI généré sur TTN

AT+CAPPEUI=0000000000000000

AT+CAPPKEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX en remplaçant les X par les 32 caractères de l’AppKey généré sur TTN

AT+CJOINMODE=0 (correspond au mode OTAA)

AT+CCLASS=2 (correspond à la classe C)

Puis joindre le réseau avec la commande suivante :

AT+CJOIN=1,1,10,8

Si tout s’est bien passé, la connexion devrait être acceptée. A vérifier dans l’onglet « Live Data » du device dans TTN :

Pour tester l’envoi d’un message, envoyer la commande suivante :

AT+DTRX=1,2,10,01253456789

Dans TTN, les bytes envoyés (01 23 45 67 89) devraient être visibles dans le MAC payload :

Configuration du payload formatter dans TTN

Afin de rendre les données disponibles dans un système domotique (par exemple home assistant), il peut être utile (et même nécessaire dans le cas de HA) de formatter le message en json. Le formatage s’effectue dans l’onglet « Payload formatters » dans TTN.

Choisir le formatter suivant :

Puis saisir le code javascript dans la zone « formatter code ». Dans cette exemple, les bytes sont décodés en texte puis le résultat est envoyé dans le champ « value ».

function decodeUplink(input) {
    var encodedString = String.fromCharCode.apply(null, input.bytes),
    decodedString = decodeURIComponent(escape(encodedString));
  return {
    data: {
      value: decodedString
    },
    warnings: [],
    errors: []
  };
}

Par exemple si on envoie le message suivant :

AT+DTRX=1,2,8,54455354

le résultat dans TTN est maintenant un payload json :

lisible par exemple avec l’intégration TTN de HA :

Intégration TTN dans Home Assistant :

Attention, l’intégration TTN native ne support que TTN V2, TTN est maintenant en V3. Il faut installer l’intégration suivante, par exemple avec HACS :

https://github.com/angelnu/home_assistant_thethingsnetwork

(doc à compléter…)

Home Assistant MQTT sensor configuration for klipper/moonraker

Backup de la config klipper

Ces étapes permettent d’automatiser un backup de la configuration de klipper vers un nas (ou tout autre serveur accessible par ssh) à l’extinction du raspbery pi sur lequel tourne klipper. Ici on utilise la commande rsync pour synchroniser le dossier klipper_config sur le nas.

1 – création du script de backup

Se loguer au raspberry pi puis créer un répertoire script dans le répertoire home du user pi :

cd
mkdir scripts

Dans ce répertoire, créer un script backup.sh :

cd /home/pi/scripts
nano backup.sh

Contenu du script :

#!/bin/bash
rsync -a --rsync-path=/usr/bin/rsync /home/pi/klipper_config <user_du_nas>@<ip_du_nas>:/path/du/repertoire/sur/le/nas

Remarque : ici le paramètre –rsync-path est nécessaire pour un NAS synology, il contient le path vers la commande rsync sur le nas. Il peut sans doute être omis dans d’autres cas (à tester).

Valider par ctr + x puis yes et entrée, et mettre les droits en exécution :

chmod +x backup.sh

2 – création de la clef rsa

Il est nécessaire de créer une clef rsa et de l’envoyer au nas pour pouvoir s’y connecter. Lors de la création de la clef valider les étapes par entrée :

cd
ssh-keygen -t rsa
ssh-copy-id <user_du_nas>@<ip_du_nas>

3 – mise en place du service

Sur le raspberry pi, créer le fichier de définition du service dans /etc/systemd/system :

cd /etc/systemd/system
sudo nano klipper.backup.service

Contenu du fichier :

[Unit]
Description=Backup de la config klipper
Requires=network.target
After=network.target
Before=shutdown.target halt.target poweroff.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=true
ExecStop=/bin/bash /home/pi/scripts/backup.sh
User=pi

[Install]
WantedBy=multi-user.target

Enregistrer le fichier et sortir de nano par ctrl + x, valider par yes puis entrée.

Activer et lancer le service :

sudo systemctl enable klipper.backup
sudo systemctl start klipper.backup

Switch HASS pour piloter le service hyperion

1- Installation de l’addon SSH depuis le menu Superviseur

2- Génération de la clef ssh

Ouvrir le menu Terminal

Entrez la commande suivante pour générer la clef ssh. Laissez le path par défaut. Ne pas renseigner de passphrase sinon la connexion ssh va demander le mot de passe (appuyez sur entrée pour la laisser vide).

ssh-keygen -t rsa

Copiez la clef sur le serveur hyperion (ssh doit avoir été activé sur le serveur). Remplacez « pi » si nécessaire par l’utilisateur à utiliser pour la connexion au serveur.

ssh-copy-id pi@<ipduserveur>

Vous pouvez tester que la connexion fonctionne avec la commande suivante :

ssh pi@<ipduserveur>

Si vous avez testé la connexion, déconnectez vous du serveur hyperion par « exit ».

Créez le répertoire .ssh dans le répertoire config de hass :

mkdir /config/.ssh

Copiez les clefs dans le répertoire :

cp /root/.ssh/* /config/.ssh

3- Création des scripts shell sur le serveur hyperion

Sur le serveur hyperion créez les 3 fichiers suivants par exemple dans votre répertoire home dans le sous-répertoire « scripts ».

hyperion_start.sh :

#!/bin/bash
if pidof hyperiond; then
    echo "hyperion already launched"
else
    sudo systemctl start hyperion.service
    echo "hyperion launched"
fi

hyperion_stop.sh :

#!/bin/bash
if pidof hyperiond; then
    sudo systemctl stop hyperion.service
    echo "hyperion stopped"
else
    echo "hyperion is not started"
fi

hyperion_state.sh :

#!/bin/bash
if pidof hyperiond > /dev/null; then
    echo "on"
else
    echo  "off"
fi

Modifier le droit des scripts pour les rendre exécutable :

chmod +x hyperion*.sh

4- Configuration du switch

Ajouter la configuration suivante dans le fichier configuration.yaml de hass. Remplacez « <ipduserveur> » par l’ip du serveur hyperion et éventuellement « pi » par l’utilisateur pour la connexion. Remplacez éventuellement « scripts » par le path où vous avez installé les scripts.

switch:
    - platform: command_line
      switches:
        hyperion_switch:
            command_on: "ssh -i /config/.ssh/id_rsa \
                             -o StrictHostKeyChecking=no \
                             pi@<ipduserveur> scipts/hyperion_start.sh"
            command_off: "ssh -i /config/.ssh/id_rsa
                              -o StrictHostKeyChecking=no \
                              pi@<ipduserveur> scripts/hyperion_stop.sh"
            command_state: "ssh -i /config/.ssh/id_rsa \
                                -o StrictHostKeyChecking=no \
                                pi@<ipduserveur> scripts/hyperion_state.sh"
            value_template: '{{ value == "on" }}'