Vous devez installer le plugin platformio sous VScodium (ou VScode si vous tenez aux spyware microsoft), en suivant le guide de Tasmota.

Activé MQTT TLS dans les headers Tasmota

Editer le fichier `user_config_override.h` pour y ajouter les lignes :

// FORCE ADDING TLS SUPPORT
#ifndef USE_MQTT_TLS 
#define USE_MQTT_TLS                             // Use TLS for MQTT connection (+34.5k code, +7.0k mem and +4.8k additional during connection handshake)
#define MQTT_TLS_ENABLED       true              // [SetOption103] Enable TLS mode (requires TLS version)
#endif

Vous pouvez y ajouter sans problème vos autres module dans ce fichier si vous avez besoin d’un support d’écran spécial, d’une sonde spécifique etc.

Pré-remplir les données wifi et MQTT

Si vous comptez avoir pas mal d’esp32 ou esp8266 dans votre domotique, je vous conseille aussi de setter les paramètres MQTT et wifi de votre réseau avec ces paramètres :

// -- Setup your own Wifi settings  ---------------
#undef  STA_SSID1
#define STA_SSID1         "votre wifi"             // [Ssid1] Wifi SSID

#undef  STA_PASS1
#define STA_PASS1         "mot de passe"     // [Password1] Wifi password

// -- Setup your own MQTT settings  ---------------
#undef  MQTT_HOST
#define MQTT_HOST         "votre jeedom ou homeassistant" // [MqttHost]

#undef  MQTT_PORT
#define MQTT_PORT         8883                   // [MqttPort] MQTT port (10123 on CloudMQTT)

#undef  MQTT_USER
#define MQTT_USER         "tasmota"         // [MqttUser] Optional user

#undef  MQTT_PASS
#define MQTT_PASS         "mot de passe mqtt dédié pour vos tasmota"         // [MqttPassword] Optional password

#define MQTT_FULLTOPIC    "ip/room/%topic%/%prefix%/"  // mon exemple d'arborescence

Actuellement, il y a quand même la commande suivante à taper dans la console pour un certificat auto-signé qui est à faire comme expliqué dans l’article sur Tasmota MQTT : « SetOption132 1 »

L’article MQTTS sous Tasmota esp8266 possible ? est apparu en premier sur Mon linux.

Explication du prefix dans Tasmota

%prefix%
Tasmota uses 3 prefixes for forming a FullTopic:

• cmnd – prefix to issue commands; ask for status
• stat – reports back status or configuration message
• tele – reports telemetry info at specified intervals

The order of %prefix% and %topic% doesn’t matter, unless you have enabled Auto-discovery for Home Assistant (SetOption19). Enabling this option re-formats the FullTopic to required order.

Using the tokens the following example topics can be made:

• FullTopic %prefix%/%topic%/ default
• FullTopic tasmota/%topic%/%prefix%/
• FullTopic tasmota/bedroom/%topic%/%prefix%/
• FullTopic penthouse/bedroom1/bathroom2/%topic%/%prefix%/
• FullTopic %prefix%/home/cellar/%topic%/

Dans jeedom détection automatique des commandes info avec leur nom via cela dans jmqtt : exemple le nom POWER est pris pour stat/ip/espcam-laser/POWER

Une explication complète de la gestion d’arborescence MQTT pour Tasmota est expliquée sur le site officiel.

Configurer Tasmota pour joindre Mosquitto en MQTTS

Pour configurer MQTTS sur un ESP32 déjà configuré sur votre wifi, vous devez indiquer plusieurs champs dans le menu Configuration > Configure MQTT

• le DNS ou IP de votre serveur MQTT (Jeedom)
• le port MQTTS 8883 (et pas MQTT 1883)
• Cocher la case « MQTT TLS »
• laisser le client
• Indiqué l’utilisateur / mot de passe que vous avez configuré dans Mosquitto
• Indiquez le Topic, un nom reconnaissable
• Pour le Full Topic, veuillez à bien utiliser %topic% et %prefix%, je vous donne un exemple suivant mon arborescence protocole/piece/nom/#

Une fois sauvegardé, vos allez voir dans la Console que votre ESP32 ne peut joindre votre serveur Mosquitto. C’est normal : de base Tasmota ne fait confiance qu’aux certificats d’autorité de certification (CA) et pas aux certificats auto-signé. Plus d’informations dans la documentation.

Il est prévu dans Tasmota de faire confiance la première fois uniquement à un certificat auto-signé. Si celui-ci change par la suite, Tasmota refusera de s’y connecter! Très pratique dans notre cas, car toujours faire confiance à un certificat non signé quelconque, ce serait une passoire pour du main in the middle.

Pour activer cela, il faut activer l’option suivante via la console :

SetOption132 1

Erreur possible

Si une erreur dans les logs de ce type, c’est une erreur TCP de connexion, vérifier que ce n’est pas un problème de firewall : MQT: TLS connection error: -1002]

L’article Tasmota et MQTT – MQTTS est apparu en premier sur Mon linux.

• L’identification du serveur et la sécurisation du flux
• L’identification du client
• L’authentification du client

Vous devez faire le bon compromis entre sécurité et flexibilité. Il ne faut pas forcément pousser le bouton à fond pour tous les cas de figures.

Génération des clés et certificats

Pour MQTTS, 2 options s’offre à vous comme pour un serveur HTTPS :

• générer vos certificats auto-signé
• via une autorité de certification

Dans mon cas ce n’est que du local, ce sera donc de l’auto-signé.

Je génère toujours les clés et certificats sur ma machine perso et ensuite je copie les certificats/clés sur le serveur et les clients, afin de les archiver. C’est donc à faire dans un dossier à garder sous Linux ou en WSL sous Windows.

Veillez bien à remplacer les DNS suivants par votre domaine externe pointant sur votre serveur ainsi que votre DNS interne ou IP interne pour joindre votre serveur MQTT (dans mon cas installé sur mon serveur Jeedom) : DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home

mkdir ca broker clients

#CA
openssl genrsa -out ca/ca.key 2048
openssl req -new -x509 -days 9999 -subj "/C=BE/CN=MQTT-CA/O=home" -key ca/ca.key -out ca/ca.crt

#broker
openssl genrsa -out broker/mosquitto.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-mosquitto" -key broker/mosquitto.key -out broker/mosquitto.csr
openssl x509 -req -extfile <(printf "subjectAltName = DNS:jeedom.YOURDOMAIN.TLD,DNS:jeedom.home,DNS:localhost,IP:127.0.0.1,IP:::1") -in broker/mosquitto.csr
 -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out broker/mosquitto.crt -days 9999 -sha256
 
#client (facultatif) si on souhaite une authentification par certificat du client au lieu de password
openssl genrsa -out clients/local-tasmotas.key 2048
openssl req -new -subj "/C=BE/O=home/CN=MQTT-client-tasmotas" -key clients/local-tasmotas.key -out clients/local-tasmotas.csr
openssl x509 -req -in clients/local-tasmotas.csr -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out clients/local-tasmotas.crt -days 9999 -sha256

MQTTS côté broker Mosquitto

Les certificats et clés privées doivent être archivés, ils ne le sont pas dans le backup Jeedom.

La configuration de base du fichier Debian est : /etc/mosquitto/mosquitto.conf

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

C’est conseillé d’utiliser un fichier dans conf.d : dans mon cas sous Jeedom avec l’installation du plugin jMQTT, le fichier suivant est créé et sera utilisé : /etc/mosquitto/conf.d/jMQTT.conf

Copie des fichiers nécessaires du broker sur le serveur Jeedom :

scp ca/ca.crt broker/mosquitto.crt broker/mosquitto.key jeedom:
ssh jeedom
sudo mv ca.crt mosquitto.crt mosquitto.key /etc/mosquitto/certs/
ls -l /etc/mosquitto/certs

Editer via l’interface web la configuration du fichier jMQTT.conf ou via vim /etc/mosquitto/conf.d/jMQTT.conf

• on laisse les connexions en clair du port 1883 provenant de localhost uniquement (127.0.0.1), plus d’accès en clair depuis l’extérieur (sert pour jeedom se connecter au broker Mosquitto)
• on active le port TLS 8883 sur toutes les interfaces

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key

# Only allow clients with a valid certificat (false to only trus the broker and not the clients)
require_certificate true

Rédémarrez le service et vérifier que le port 8883 est ouvert pour tous et 1883 n’est plus accessible que par 127.0.0.1 :

sudo systemctl restart mosquitto.service
sudo ss -tlpn | egrep '(1883|8883)'
LISTEN    0         100                0.0.0.0:8883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=6))
LISTEN    0         100              127.0.0.1:1883             0.0.0.0:*        users:(("mosquitto",pid=14185,fd=5))

A ce moment là, le trafic entre nos clients et notre serveur est sécurisé. Mais n’importe quel client peut se connecter à notre serveur sans mot de passe!

Basé sur la documentation jMQTT officielle, d’autres informations et erreurs courantes sont disponibles sur ce blog.

Authentification

Mes clients étant des ESP32 qui disposent de Wifi ou mon pc avec MQTT explorer pour le debug, tout en local, une authentification par mot de passe est suffisante. Je distingue les clients IoT avec un seul mot de passe et mes 2 pc avec chacun un mot de passe différent.

Pour un serveur MQTTS publique, l’authentification des clients par certificat est recommandé

1. Créer les fichiers de mot de passe : mosquitto_passwd -c <password file> <username>
   sudo mosquitto_passwd -c /etc/mosquitto/distant.passwd tasmota
2. Configurer le broker avec la ligne : password_file <path to the configuration file>
3. Ajout d’un second utilisateur sudo mosquitto_passwd /etc/mosquitto/distant.passwd hp
4. Redémarrer : sudo systemctl restart mosquitto.service

Le fichier /etc/mosquitto/conf.d/jMQTT.conf

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous true

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

Si vous préférez utiliser un mot de passe pour Jeedom en local, selon si le plugin vous l’impose, vous pouvez le faire :

per_listener_settings true

# jMQTT Mosquitto configuration file
listener 1883 127.0.0.1
allow_anonymous false
persistence false
password_file /etc/mosquitto/local.passwd

# jMQTTS
listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/mosquitto.crt
keyfile /etc/mosquitto/certs/mosquitto.key
allow_anonymous false
persistence false
require_certificate false
password_file /etc/mosquitto/distant.passwd

source

L’article MQTTS sécuriser Mosquitto MQTT est apparu en premier sur Mon linux.

Voici quelques bases d’explications, que vous pouvez compléter avec la documentation officielle du protocole.

architecture de communication de MQTT

Nous avons un broker, celui qui passe les messages.
Des clients Publisher vont envoyer des messages avec un nom appelé Topic
Des clients Subscriber vont recevoir des messages s’ils sont abonnés à ce Topic

architecture du protocole MQTT

C’est organisé en Topic / sujets

On peut faire un topic racine : toto
Et des sous topic :

• toto/test1/o1
• toto/test1/o2
• toto/test2/o1
• toto/test2/o2
• toto/test3

On peut souscrire à plusieurs Topic via toto/* ou toto/#
Il n’est pas possible de mettre # pour la racine

On peut s’inscrire à plusieurs sous Topic via le + : toto/+/o1

MQTT Broker

Le plus utilisé : Mosquitto. Il est open-source et simple de configuration.

Organisation des Topic Jeedom

Il faut vous organiser à l’avance pour l’arborescence des topic qui seront utilisé chez vous. Voici ce que j’ai organisé chez moi pour les niveaux :

1. mettre le protocole passerelle
2. mettre la pièce ou une référence à la pièce
3. mettre le device
4. mettre les topics du device

Cela permet par exemple de matcher tous les objets du bureau quelque soit son protocole!

• MQTT direct : ip/piece/device/xxx
  • si plusieurs composant pour un seul objet, mettre cet objet devant le device : ip/display-rdc/matrixled-temp/xxx et ip/display-rdc/matrixled-spotify/xxx par exemple
• modbus2mqtt : modbus/rdc/device/xxx
• zigbee2mqtt : zigbee/bureau/device/xxx
• zwaveJS : zwave/bureau/device/xxx

clients

• Windows : MQTT Explorer permet le MQTT en clair, en MQTTS avec certificat serveur uniquement ou avec la pair de certificat/clé client
• Android j’en cherche encore un bon pour le debug

L’article MQTT broker est apparu en premier sur Mon linux.

• Vert pour disponible avec une intensité faible
• Orange clair pour occupé
• Rouge pour ne pas déranger ou lors d’un appel

En plus de cela, le bandeau LED s’éteint lorsque le statut est absent ou hors connexion.

Comme je l’avais dit dans l’article précédent, il faut veiller à avoir un statut de présence dans le bureau, afin de gérer le bandeau LED uniquement lorsque l’on est en télétravail.

Création d’un widget de présence bureau et scénario Teams

Vous créez un simple virtuel. Dans mon cas c’est un tag NFC qui est utilisé, mais un simple bouton suffit également.

Le scénario est utilisé sur évènement de nos 2 infos du virtuel Teams :

1. La condition primaire permet d’exécuter le script que lorsque l’on est présent :

#[bureau][tag bureau][présence bureau]# == 1

2. Un point important ici est l’utilisation de trigger() pour exécuter des actions différentes en fonction d’un mixte entre statut et activité par rapport à ce que teams nous envoie. Dans ce cas-ci je fais appel au scénario de gestion du bandeau LED en lui donnant la couleur rouge et l’intensité 100 (de 0 à 254). Le bandeau faisant 50cm pas besoin

( (trigger(#[bureau][teams mode][status]#) OU trigger(#[bureau][tag bureau][présence bureau]#) ) ET (#[bureau][teams mode][status]# == "Au téléphone" OU #[bureau][teams mode][status]# == "Ne pas déranger" OU #[bureau][teams mode][status]# == "En présentation" OU #[bureau][teams mode][status]# == "En réunion") ) OU (trigger(#[bureau][teams mode][activity]#) AND #[bureau][teams mode][activity]# == "En appel")

3. Dans l’autre cas, on évalue pour l’état occupé ou focusing de mettre en orange

(trigger(#[bureau][teams mode][status]#) OU trigger(#[bureau][tag bureau][présence bureau]#) ) ET (#[bureau][teams mode][status]# == "Occupé" OU #[bureau][teams mode][status]# == "Focusing")

4. Dans le dernier cas, on évalue pour l’état disponible pour mettre en vert :

( (trigger(#[bureau][teams mode][status]#) OU  trigger(#[bureau][tag bureau][présence bureau]#)) ET #[bureau][teams mode][status]# == "Disponible" ) OU (trigger(#[bureau][teams mode][activity]#) AND #[bureau][teams mode][activity]# == "Plus en appel")

5. Lorsque l’on est plus présent et que le bandeau est allumé, on l’étein

trigger(#[bureau][tag bureau][présence bureau]#) ET #[bureau][ruban led occupation][Etat]# == 1

Scenario de gestion de couleur

J’ai préféré séparer l’appel direct au bandeau led afin de pouvoir l’utiliser pour autre chose, genre une alerte etc

L’article Signaler son statut Teams via des LED RGB est apparu en premier sur Mon linux.

Le but est de récupérer le statut Teams via sa machine windows afin de le mettre à jour sur sa domotique Jeedom. Cela permet de faire des scénarios pour les lumières, le chauffage, etc.

Le script d’origine est fait pour homeAssitant par EBOOZ. Je l’ai modifié afin de le rendre compatible avec Jeedom, gérer les caractères « spéciaux » en UTF8 sous powershell, par spéciaux on entend simplement les caractères accentués de la langue française… Pas mal de modifications de variables pour rendre ce script multilingue également. J’ai revu la partie installation pour la rendre plus générique, celle d’origine étant plus hasardeuse en fonction du répertoire courant.

La configuration du virtuel

Création d’un virtuel pour gérer l’état du statut et de l’activité :

Une fois créé, enregistrez pour obtenir les 2 ID utilisés par le script.

Récupération de l’url API via l’onglet équipement :

Vous avez récupéré l’url ainsi que l’apikey (grisé sur l’image).

Le script TeamsStatus

Le TeamsStatus est composé d’un script powershell, d’un fichier de configuration et du binaire nssm.exe qui permet de créer facilement un service sous Windows pour un script.

Il peut également service à faire un update manuel, utilise en cas de test :

C:\Scripts\Get-TeamsStatus.ps1 Occupé

Installation du script

Récupérez le projet git via un fichier zip ou un git clone :

git clone https://github.com/belgotux/TeamsStatus.git

Copiez le fichier Settings de votre langue :

cp Settings-fr.ps1 Settings.local.ps1

• Remplacez <Insert token> avec le token Jeedom que vous avez généré
• Remplacez <UserName> avec le nom d’utilisateur local de la machine qui est logué dans Teams et que vous voulez monitorer
• Remplacez <Jeedom URL> avec l’URL de votre serveur Jeedom
• Remplacez <ID> de statut par l’ID du virtuel que vous avez créé
• Remplacez <ID> d’activité par l’ID du virtuel que vous avez créé

Installez le script avec l’invite de commande admin PowerShell :

New-Item -Path "c:\Scripts\" -ItemType Directory
Copy-Item -Path .\nssm.exe -Destination "c:\Scripts\"
Copy-Item -Path .\Settings.local.ps1 -Destination "c:\Scripts\"
Copy-Item -Path .\Get-TeamsStatus.ps1 -Destination "c:\Scripts\"
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Unblock-File c:\Scripts\Settings.local.ps1
Unblock-File c:\Scripts\Get-TeamsStatus.ps1
Start-Process -FilePath "c:\Scripts\nssm.exe" -ArgumentList 'install "Microsoft Teams Status Monitor" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-command "& { . C:\Scripts\Get-TeamsStatus.ps1 }"" ' -NoNewWindow -Wait
Start-Service -Name "Microsoft Teams Status Monitor"

Après avoir exécuter ces commandes, démarrez l’application teams pour voir si le statut remonte bien dans votre domotique Jeedom.

Widget Jeedom

Vous devriez obtenir ce widget dans votre Domotique Jeedom, avec votre status selon votre état, en ligne, occupé, hors connexion :

Maintenant à vous de voir ce que vous voulez en faire dans vos scénarios! Piloter un éclairage, le chauffage, un bandeau led, etc!

Attention que ce statut est remonter dans Jeedom où que vous soyez! Pensez à l’associer dans vos scénarios avec un statut de présence à la maison. Pour éviter d’allumer votre chauffage quand vous êtes en présentiel au bureau

L’article Obtenir son statut Teams dans sa domotique Jeedom est apparu en premier sur Mon linux.

Avoir l’ampli branché en permanence consomme pas mal d’énergie pour rien, en plus de générer un bruit de vide désagréable. Il faut donc penser à l’éteindre de manière automatique quand vous n’écoutez pas de musique.

Le matériel nécessaire pour votre squeezelite

Imaginons que vous ayez ce matériel pour chacune de vos 2 pièces, le living et la cuisine :

• Un raspberry pi 3 sur son alim 5v
• Un DAC auto-alimenté en USB
• Un ampli avec sa propre alimentation et vos baffles
• Une plaque de 1 relai 230v 10A pour commander un ampli en 230v, isolé par optocoupleur. Des cartes toutes faites existent, bien faites et pas cher.. Dans mon cas j’avais une plaque de 4 relais  Geekcreit, achetée 2,45€… Ca va pas nous ruiner…

Pour ne pas allumer ou éteindre votre ampli manuellement quand vous utilisez votre piCorePlayer, vous pouvez passer par les GPIO de votre raspberry pi!

Configurer piCorePlayer

piCorePlayer vous permet d’utiliser directement une des GPIO via son interface web, même pas besoin de passer par la ligne de commande, pour cela il faut :

1. Se mettre en mode Advance
2. Sélectionner le port GPIO que vous comptez utiliser, ici le GPIO18
3. Sélectionner que le GPIO est actif à l’état bas « Active Low ». C’est important! Car ces types de relais sont normalement ouverts à l’état haut et ne se ferment qu’à l’état bas pour faire le contact
4. On valide et on redémarre le raspberry pi

Branchement du relais sur le raspberry pi 3

Il faut maintenant brancher le 3.3v du raspberry pi sur le Vcc de la carte relais, le GND au GND, et le GPIO18 sur le INT1.

Ensuite on test via l’interface web d’allumer et éteindre le client squeezelite, on entend le relais sans problème ainsi que le son

Conclusion sur la consommation

De mon côté, l’alimentation 12v utilisée pour l’ampli consomme 1w en veille, au lieu des 8w consommés à vide sans l’utilisation de ce GPIO…

Le raspberry pi 3 au repos consomme en permanence 5v 0.23A + le DAC USB consomme 0.02A = 1.25w + les 1w du transfo en veille. Donc 2.25w en permanence, 20kWh sur l’année, 5.71€/an d’électricité…

En fonctionnement, il y a le raspberry pi, un DAC et 2 relais d’allumé (2×0,05A) 5v 0.40A  = 2w. L’ampli et son transfo 12v à vide 10w. A cela, il faut ajouter la puissance des baffles, l’ampli pouvant gérer 2x50w.

C’est une solution économique en électricité pour du matériel connecté H24!

L’article Allumer et éteindre l’ampli de sa squeezelite automatiquement via GPIO – multiroom LMS est apparu en premier sur Mon linux.

Mais pour du multiroom, je vous conseille de mettre le serveur LMS sur un serveur à part. Cela peut être un serveur existant si vous en avez déjà un qui vous sert pour votre nextcloud, vos téléchargements, etc. Il faut utiliser piCorePlayer sur un raspberry pi uniquement comme player UPnp/dlna et squeezebox.

Pré-requis : avoir installer le serveur LMS

Configurer piCorePlayer

Pendre l’image pour raspberry pi ici, afin de transformer votre raspberry pi en player UPnP/DLNA, mais surtout comme player squeezebox! Plus d’info sur piCorePlayer via sourceforge.

Pas besoin de brancher d’écran! Juste mettre la carte microSD, brancher le câble réseau et brancher le microUSB et c’est tout!

Ensuite, récupérez l’IP obtenue en DHCP sur votre routeur et connectez vous en HTTP pour vérifier qu’il y a une interface web qui répond piCorePlayer.

Vous allez sur votre interface Logitech Media Server pour voir apparaitre une nouvelle platine, nommée « piCorePlayer ».
Renommez la avec le nom de votre pièce par exemple et puis validez. Vous aurez quelque chose comme ceci :

Tester que cela fonctionne avec un casque via le jack 3.5mm intégré au raspberry pi.

Utilisation d’un DAC USB

Le son sortant du raspberry pi est très mauvais, vous en conviendrez… Il faut donc passer par un DAC USB afin d’avoir une meilleure qualité sonore.

Selon votre budget, aliexpress ou son-video sera votre fournisseur Il faut être en adéquation avec tout le matériel! Mettre un DAC à 100€ pour un ampli chinois à 5€ et des baffles à 500€ ne sera pas cohérent… Dans ce projet, je ne vise pas le low cost, ni le top du top, le but est d’avoir un son d’ambiance suffisant et agréable pour mes oreilles.

J’en ai testé plusieurs sur aliexpress par curiosité, il y en a de 1€ à 50€. Dans le cadre de mon projet, un bon rapport qualité/prix est un DAC à base du composant PCM2704 USB DAC. Il permet :

• 16 bits
• 32 bit
• 44.1, 48kHz

Un DAC USB intéressant utilisant cette puce à 7€ sur aliexpress :

Ceux qui veulent une fréquence d’échantillonnage de qualité de 192khz devront chercher ailleurs… Dans mon cas 48kHz est suffisant pour un son d’ambiance pour la salle à manger quand des amis sont là ou la cuisine. Pour le salon, c’est un ampli Onkyo compatible 192 kHz/24-bit qui liera les FLAC sur des enceintes adaptées via UPnP/DLNA pour la bonne musique

Pour faire fonctionner le DAC USB au lieu du jack interne 3.5mm, vérifier qu’il est bien pris en compte par ALSA
Se connecter en SSH avec ceci :

• utilisateur : tc
• password : piCore

Passer en root

sudo su

Lister des devices dans ALSA pour voir le DAC USB

root@piCorePlayer:/home/tc# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 7/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: DAC [USB Audio DAC], device 0: USB Audio [USB Audio]
 Subdevices: 1/1
 Subdevice #0: subdevice #0

Ensuite régler le niveau sonore du DAC via la commande suivante

alsamixer

Faire « F6 » et sélectionner « USB Audio DAC » ou la carte que vous avez utilisé

Vous pouvez limiter le volume maximum pour protéger le baffle si besoin. Cela permet de protéger vos enceintes d’une mauvaise manipulation Vous pourrez augmenter ou réduite le son de votre enceinte via LMS.

Ensuite, dans l’interface web de piCorePlayer, on va se mettre en mode Normal au lieu de Basic, afin de pouvoir sélectionner « USB audio » comme sortie.

Dans l’output setting « sysdefault:CARD=DAC ». Remplacez DAC par le nom de votre carte, voir ce qu’il y a après le « card 1: » dans la commande aplay.

L’interface propose de relancer le service Squeezelite, ensuite la sortie du DAC devrait fonctionner quand vous lancez un stream à partir de LMS!

Tester avec un casque jack 3.5mm.

Utiliser  un ampli derrière le DAC USB

Ce DAC USB a suffisamment de puissance pour alimenter un ampli via son entrée ligne. Vous pouvez utilisez n’importe quel ampli. Dans mon cas, je n’ai pas besoin d’ampli fidèle de class AB, qui est encombrant et a un mauvais rendement. Il me faut quelque chose en cohérence avec mon DAC USB commandé sur aliexpress : un ampli class D qui offre un bon rendement.

La qualité sonore du class D est moindre que celle d’un class AB, mais pour du streaming de fichiers compressés, c’est suffisant. Attention toutefois, il y a ampli class D à 2€ et ampli class D qui présente un bon son à quelques dizaines d’euros… Le prix est question des composants utilisés autour de la puce de gestion. En cherchant un peu, Tripath fait des puces d’ampli qu’ils nomment class T. C’est une puce pour faire un ampli digital mais à haute fidélité : TK2050.

Quelques caractéristiques de la fidélité de la puce :

• 0.005% THD+N @ 70W 4Ω
• 0.007% THD+N @ 30W 8Ω

Pas mal me direz vous! La puce a un coût faible par rapport au reste des composants, il y a donc des amplis à tous les prix avec ce composant. Cela dépendra aussi si l’alimentation est incluse ou non. Comptez bien le nombre de self et de condensateur, c’est déjà une bonne piste pour voir la qualité de la carte ampli.

Dans mon cas, je me suis penché sur celui-ci chez aliexpress. Pour 15€, j’en suis agréablement surpris. Il présente :

• une entrée pour relier le DAC avec un câble jack 3.5mm où les 3 fils sont coupés à l’autre extrémité pour le relier au bornier.
• Une entrée pour l’alimentation (12-20Vdc), vous pouvez donc récupérer une alimentation de portable 90w ou de pc fixe sans problème.
• 2 sorties de 50w pour relier vos baffles passifs

Il ne manque plus que brancher vos baffles et vous avez votre enceinte multiroom complète!

L’article Transformer votre raspberry pi en player squeezebox avec piCorePlayer – multiroom LMS est apparu en premier sur Mon linux.

Configuration du serveur LMS

En premier, activer les plugins suivants via l’interface web :

• UPnP/DLNA bridge (lien du projet)

• Chromecast Bridge (lien du projet)

Redémarrer le service :

service logitechmediaserver restart

Aller dans les paramètres du plugin UPnP :

1. faire start the bridge
2. choisir le binaire dans la liste
3. appliquer

Attendre 30sec que le fichier de configuration soit créé, ensuite actualiser la page

On voit apparaitre les périphériques UPnP dans la liste des paramètres du plugin, déjà bon signe

1. Décocher la case « Running » pour arrêter le plugin et appliquer. Il est très recommandé de configurer le plugin quand il est arrêté
2. Sélectionner un périphérique UPnP (ici TX-NR646)

Dans « Apply pre-defined player profile » :

1. Choisir un profil qui correspond au mieux au périphérique (tout n’est pas dispo)
2. Cocher apply
3. Ensuite appliquer (en bas à droite)

Maintenant, changer le nom du player pour mettre « salon » par exemple. On peut changer le niveau max du volume. Pour mon ampli la gestion du son bug, dès que je change le son via l’appli il oscille entre le volume 25 et 35 par exemple…

Dans mon cas, je désactive donc la gestion du son, que je ferai sur l’ampli directement :

1. LMS volume changes « ignore all changes »
2. feedback to LMS « yes »

On applique et le périphérique devrait apparaitre dans la liste du serveur Logitech Media Server, essayez de streamer votre musique dessus

Pour info, le processus « squeeze2upnp » ouvre un port pour son serveur HTTP : 49152
Pour rappel, le client UPnP fonctionne avec un appel HTTP GET pour avoir le fichier audio sur la page web de ce plugin sur le port 49152 et non sur le port 9000 du LogitechMediaServer. Si vous avez un firewall ça peut être utile. Vous trouverez de l’information sur Wikipedia.

L’article Multiroom LMS – Utiliser un client UPnP/DLNA comme player est apparu en premier sur Mon linux.

• Version x64 : Lien officiel (lien copie) MD5SUM 907A173169145073B9440CFCECDCB283
• Version i386 : Lien officiel (lien copie) MD5SUM 2A501F304C0D4FF9EEC115C700613D7D
• Version ARM : Lien officiel (lien copie) MD5SUM 9C05375A75D19B1E2811DC244CDAB15E

Dans le cas de mon serveur en Atom x5-z8350, je prendrai donc la version AMD64…

wget http://downloads.slimdevices.com/LogitechMediaServer_v7.9.0/logitechmediaserver_7.9.0_amd64.deb
dpkg -i logitechmediaserver_7.9.0_amd64.deb

Une fois installé, il suffit d’aller sur le port 9000 de votre serveur

Si besoin faire un « netstat -tlpn » pour voir si le service est bien lancé et relancer le service

service logitechmediaserver restart

http://IP:9000

Il ne reste qu’à suivre le wizard pour configurer un répertoire de musique, de liste de lecture, etc

Pour le dossier de musique, il faut les droits suivants :

chown -R squeezeboxserver:nogroup /disk/MUSIC/
chmod 644 /disk/MUSIC/*

Maintenant que vous être dans l’interface web :

1. Cliquez sur Paramètres en bas de page
2. Allez dans réglages de base > Analyser le dossier multimédia et attendez quelques secondes ou minutes selon la taille de votre dossier musique
   
3. Dans l’onglet Informations il y a le détail des scans de la bibliothèque
4. Dans l’interface principal, on actualise et les fichiers sont présents allez dans « Dossier de musique » par exemple

La partie serveur est maintenant finie, rien de compliqué

Passez à l’utilisation d’un player UPnP/DLNA si vous en avez un comme une smart TV ou un ampli. Sinon passez à la configuration du player raspberry pi.

L’article Multiroom LMS – Installation du serveur logitech media server est apparu en premier sur Mon linux.