Récupérer un flux instagram

Récemment, dans le cadre familial nous avons eu un problème de « partage » de vidéos entre instagram et whatsapp.

C’est un peu crétin car il s’agit de deux services de facebook, mais quand on partage une vidéo instagram dans whatsapp, seuls les personnes ayant instagram de validé sur leurs comptes peuvent lire la vidéo… Donc certains utilisateurs pouvaient lire la vidéo, les autres non…

J’ai donc du identifier une méthode pour récupérer des flux instagram (vidéos) et ainsi pouvoir les partager aux utilisateurs n’ayant pas de compte.

Donc oui, il existe une méthode rapide, fiable et linuxienne pour récupérer les vidéos : cela s’appelle instalooter, il faut l’utiliser avec Python :

Le code source sur github:

https://github.com/althonos/InstaLooter

La documentation associée:

https://instalooter.readthedocs.io/

Installation et usage pour un serveur linux

pip3 install --user instalooter --pre 
 ~/.local/bin/instalooter -v -u "monuser" -p "monmodepasse" post

Et voilà, encore une victoire de canard!

Et moi, je retourne au confinement…

Installer OpenWRT sur une borne unifi

Les bornes unifi sont des super produits pour les pros. Mais pour ceux qui en veulent toujours plus et se retrouvent limité par le système (sic…) il est possible d’aller encore plus loin. En effet, ces bornes sont toutes basés sur une version du système d’exploitation OpenWRT. Donc forcément compatible avec le système.

Bon, en vrai, la LED je la désactive

On a la confirmation en se connectant en ssh à la borne.


cat /etc/openwrt_release
DISTRIB_ID='LEDE'
DISTRIB_RELEASE='17.01.6'
DISTRIB_REVISION='r3979-2252731af4'
DISTRIB_CODENAME='reboot'
DISTRIB_TARGET='ar71xx/ubnt'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='LEDE Reboot 17.01.6 r3979-2252731af4'
DISTRIB_TAINTS='no-all mklibs busybox'
UnifiAP-AC-LR-BZ.v4.0.80# cat /etc/openwrt_version
r3979-2252731af4

Jusqu’à il y a peu, il était possible d’installer des paquets supplémentaires via opkg… Mais voilà, depuis, ubiquiti l’a interdit 🙁

Mais on peut installer OpenWRT, en perdant par contre la partie « gestion » via le logiciel unifi controller. A vous de voir ce qui vous intéresse.

Dans le cas ou vous souhaitez installer OpenWRT, c’est possible via le tutorial suivant :

https://openwrt.org/toh/ubiquiti/unifiac

ATTENTION pour le package mtd, j’ai du utilisé celui-ci https://downloads.openwrt.org/releases/17.01.6/packages/mips_24kc/base/mtd_23_mips_24kc.ipk

Pour l’installation, j’ai du le décompresser via 7-Zip sur mon poste de travail et j’ai du ensuite recopier l’exécutable dans le dossier /sbin de la borne.

Ensuite : redémarrage, et tout fonctionne du premier coup.

L’inconvénient, c’est que si on a plusieurs routeurs, ou plusieurs bornes, on risque de se retrouver en réseau local avec plusieurs DHCP (bof) et plusieurs DNS (rebof)

Heureusement, on peut facilement configurer les routeurs OpenWRT en mode « Dump AP » (Ce qu’on peut traduire par « point d’accès déversoir »…)

https://openwrt.org/docs/guide-user/network/wifi/dumbap

Zou, je retourne à ma configuration 🙂

Best method ever from Saturday Night

Connaître le niveau de batterie d’un appareil android sur jeedom

L’article suivant décrit le process permettant la mise en place d’un script ssh sous Jeedom;

Tutorial niveau et status batterie sous jeedom

Les adaptations nécessaires et les limitations :

  1. Si le téléphone ou la tablette est hors ligne, cela affiche un avertissement.
  2. Il faut fixer l’adresse IP de la tablette ou du smartphone
  3. Sur les versions récentes d’android, on ne peut pas afficher directement le status en charge / décharge ; Il faut utiliser un contournement suivant pour avoir l’info « Charging » / « Discharging » puis l’afficher via un widget. (voir le code ci-joint et la capture décran)
  4. Toujours sur les versions récentes d’android, l’application SSH doit être lancé ET visible en arrière plan, sinon ça ne marche pas. Si on oublie, pas d’info.
ssh -p 2222 <adresse IP> cat /sys/class/power_supply/battery/uevent | grep STATUS  | cut -d'=' -f2

Calibration de la CR-10

Depuis la remise en route de ma CR-10 après une longue période de stockage je rencontre toujours des problèmes.

Voici quelques liens pour expliquer les calibrations de base :

  1. Réglage du PID de la tête chauffante pour avoir une montée en température constante et une température d’impression constante : https://3dprinting.forumactif.org/t226-reglage-du-pid-aux-petis-oignons 
  2. Calibration de l’extrudeur puis calibration des moteurs des axes : https://mattshub.com/blog/2017/04/19/extruder-calibration (à coupler avec mon article sur la calibration des axes X, Y, Z (ici)

J’ai réussi à imprimer avec Cura un cube XYZ avec les bonnes dimensions et mon extrudeur imprime la bonne quantité de plastique.

Maintenant le problème suivant est au niveau du réglage de la rétractation. Avant j’avais une valeur de 6,2mm dans S3D avec une vitesse de rétraction de 80 et au final le plastique remontait trop haut et bouchait la buse.

J’ai changé la buse, nettoyé le corps chauffant et baissé la rétractation.

J’ai appliqué la méthode décrite ici : https://www.matterhackers.com/articles/retraction-just-say-no-to-oozing  avec le modèle disponible ici : https://www.thingiverse.com/thing:1441887 

J’ai obtenu des cubes très propres avec Cura et avec S3D avec des valeurs de rétractation entre 5 et 6mm et une vitesse de rétractation aux alentours de 45 mm/s.

Avec Cura j’ai mis la rétractation à 5,2mm et j’ai tenté l’impression de la tour Eiffel et c’est une catastrophe. Il y a des filaments de plastique partout et les morceaux sont difformes a cause des bulles plastique qu’il y a partout.

Je ne vais pas refaire des Tour Eiffel jusqu’à ce que ce soit bon mais j’ai trouvé un modèle qui reproduit correctement le problème sans être trop gros (https://www.thingiverse.com/thing:2510164).

J’ai demandé des conseils sur le groupe Facebook pour essayer de résoudre mes problèmes. Globalement la réponse a été d’augmenter un peu la rétractation et surtout de baisser la température de la buse. J’ai donc fait différents essais et avec une rétractation à 5,5mm et une température de 200°C j’obtiens un rendu plutôt propre avec encore quelques petits fils.

Le filament Arianeplast à vraisemblablement une tendance à couler car les autres personnes qui l’utilisent ont des distances de rétractation de 6,5 à 7 mm. Je vais poursuivre mes essais pour tenter de ne plus avoir du tout de fils mais en tout cas le rendu est vraiment meilleur avec mes paramètres actuels.

A chaque nouveau filament utilisé je préconise les étapes suivantes :

  1. Imprimer une tour de température pour choisir la plus adaptée (ici par exemple)
  2. Régler correctement le flow avec le modèle suivant : https://www.thingiverse.com/thing:3397997
    • Valeur de flow = (Distance attendue / Distance mesurée) x valeur de flow utilisée pour l’impression
  3. Régler la rétractation avec le modèle suivant https://www.thingiverse.com/thing:1441887 
  4. Enregistrer ces paramètres en créant une nouvelle version de PLA dans Cura avec la marque et la couleur ou le type du filament

Monitorer XTeVe via monit

XteVe est un « proxy » vers des serveurs IPTV via des listes M3U. Je l’utilise avec mon FAI (Free) pour interfacer les chaînes multipostes avec plex. On peut également l’utiliser pour regrouper des multiples playlist d’IPTV gratuites (par exemple : https://github.com/iptv-org/iptv)

Consulter le site officiel pour plus d’informations : https://xteve.de/

Oui mais voilà, parfois lors de l’enregistrement, XteVe plante (grrr…). Donc, j’ai souhaité rapidement ajouter un monitoring automatique à xteve pour permettre de le relancer sans intervention manuelle.

La première étape consiste à « transformer » xteve en démon. Ensuite, il faut utiliser un logiciel de monitoring type monit pour le surveiller. C’est simple donc 🙂

Création d’un démon de service

Créer le fichier de service :

cd /etc/systemd/system/
sudo vi xteve.service

Copier le contenu suivant

[Unit]
Description=xTeVe Service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/dossier_installation/xteve -config dossier_configuration
ExecReload=/usr/bin/killall xteve
ExecStop=/usr/bin/killall xteve
KillMode=process
Restart=always
RestartSec=15

User=running_user
Group=running_group
[Install]
WantedBy=multi-user.target

Attention à bien remplir les éléments manquants : dossier_installation,dossier_configuration, running_user et running_group.

On sauvegarde le fichier, puis on active le nouveau service :

sudo systemctl enable xteve
sudo systemctl start xteve

Création du fichier de monitoring pour monit

On crée un nouveau fichier pour ce monitoring ;

sudo vi /etc/monit/conf.d/xteve
check process xteve matching "xteve"
    start program = "systemctl start xteve"
    stop program = "systemctl stop xteve"
    if failed host 127.0.0.1 port 33400 with timeout 30 seconds for 3 cycles then restart

Attention à adapter le numéro de port du monitoring.

Ensuite, il ne reste plus qu’à relancer monit :

sudo /etc/init.d/monit restart

Et voilà, xteve fonctionne désormais tout seul.

… Et les mises à jour ?

Ah… oui… le défaut, c’est que xteve se met à jour uniquement au démarrage de l’application.

Donc, il faut également penser à le relancer de temps à autre pour qu’il puisse faire ces mises à jour. Pour cela, le plus simple reste à rajouter une ligne dans le crontab pour le redémarrer par exemple une fois par semaine le mardi vers 4h du matin (peu de chances d’enregistrer quelque chose…)

Ce qui donne dans crontab :

0 4 * * 1 systemctl restart xteve