Bonjour à toutes et tous.
Aujourd'hui un petit retour d'expérience suite à l'achat d'un NS Panel Sonoff et de 2 jours de galère pour réussir à en faire quelque chose. Petite précision : il ne s'agit pas du NSPanel pro, mais de la version avec 2 boutons physiques (et 2 relais pour ma version)
Il y a plein de source de données à propos de ce qu'on peut en faire, je ne vais pas tout couvrir ici évidemment. Pour ma part, j'ai voulu essayer :
- Tasmota + nspanel-lovelace-ui (joBr99) + AppDaemon
- ESPHome + nspanel-lovelace-ui (Sairon) + AppDaemon
- ESPHome Nextion (natif)
- NSPanelManager
- NSPanelEasy
Par hasard complet, j'ai commencé par NSPanelManager. Il faut savoir que le flash est long... très long (je parle du flash de l'écran, l'ESP intégré se flash assez rapidement). A propos de flash, je ne rentrerai pas dans les détails, sauf si quelqu'un en exprime le besoin dans les éventuels commentaires 
.
Je n'ai pas été emballé, mais cela ne tiens qu'à mon affinité propre. Trop restreint à une utilisation simple. Je veux pouvoir afficher la météo, piloter ma clim ou mon chauffage, mes lumières etc ... Par contre, l'esthétique est vraiment soignée.
Nécessite un serveur MQTT et l'installation de l'add-on NSPanel manager (ou dans un serveur docker séparé, c'est à vous de choisir). Les paramètres se font depuis l'interface de l'add-on, mais je l'ai dit, c'est assez succinct.
Puis je suis passé à NSPanelEasy.
Et franchement, il y a matière à... Sauf que moi, je suis difficile, et pas comme tout le monde, et puis je fais ce que je veux (ou presque, on verra plus loin). Tout ça pour dire que je ne me sentais pas à l'aise avec cet écran.
J'ai ensuite voulu passer à Nextion, mais je n'ai jamais réussi. D'ailleurs, à partir de ce moment, je n'ai été que de déconvenues en déconvenues. Ecran injoignable, flash foireux, erreurs en tout genre ... L'ESP ne voyait carrément plus l'écran ou n'arrivait pas à le flasher.
Et là, la sueur froide commence à arriver et on se dit "j'ai briqué l'appareil" !
Après moults essais, tests (démontage total de l'écran, avec sniffage des trames sur les lignes séries en mode fils volants sous tension, et tutti quanti...) j'ai enfin réussi à sortir de l'impasse.
Je ne vais pas être catégorique : ce qui suit a fonctionné pour moi, je n'ai aucune idée de si cela fonctionnera pour vous (si vous êtes dans ce cas de figure).
Quoiqu'il en soit, le flash de NSPanel Easy a mis l'écran dans un état particulier, aucun autre flash n'a fonctionné par la suite. Par chance, une option permet de spécifier un binaire de flash alternatif ce qui m'a permit de m'en sortir. D'ou la technique qui suit, et qui pourrait être d'un grand secours à d'autres.
Je tiens à remercier les différents contributeurs de ces firmwares alternatifs. Ce n'est pas parce que j'ai rencontré des problèmes que tout est à jeter : j'ai sans aucun doute commis des erreurs quelque part.
Et je remercie également Claude.ai qui a été plus qu'utile dans cette aventure (enfin, c'est plutôt un clin d'oeil parce que comme ce n'est pas un être vivant, le remercier n'a pas vraiment de sens ...). Le résumé qui suit et de sa composition, extrait de notre loooooongue conversation sur ce problème. J'ai fais évidemment une relecture et quelques ajouts/corrections.
Sonoff NSPanel : interface Lovelace via ESPHome (composant sairon) + AppDaemon
Mode opératoire pour flasher un Sonoff NSPanel (EU) en ESPHome avec le composant tiers nspanel_lovelace de sairon, piloté par le backend AppDaemon officiel du projet nspanel-lovelace-ui de joBr99.
Pourquoi cette combinaison
- ESPHome + sairon : reste dans l'écosystème ESPHome (pas besoin de Tasmota), tout en réutilisant le riche catalogue de cartes du projet original de joBr99.
- AppDaemon : gère le rendu des pages/cartes en YAML simple, sans avoir à dessiner l'interface soi-même dans Nextion Editor.
- Je trouve personnellement que l'esprit de HA est vraiment marqué dans ce firmware.
Prérequis matériel
- Sonoff NSPanel (pour ma part, un modèle EU avec 2 relais)
- Adaptateur USB-série 3.3V pour le flash de l'ESP
- Un broker MQTT accessible sur le réseau (add-on HA ou serveur tiers)
- Une instance AppDaemon déjà installée et fonctionnelle (serveur dédié ou add-on Home Assistant), avec le plugin
HASSdéjà configuré et une connexion HA validée
Point critique si l'écran a déjà tourné un autre firmware custom
Si l'écran a déjà affiché une interface personnalisée par le passé (NSPanel Easy, NSPanel Manager, etc.), il peut refuser tout nouvel upload de .tft venant d'un logiciel externe — l'écran reste bloqué à diffuser en boucle son propre protocole d'annonce (localeventboot/équivalent), et aucune poignée de main externe n'arrive à s'imposer par-dessus.
Solution qui a fonctionné de façon fiable et reproductible (2 fois) :
-
Flasher temporairement le panel en NSPanel Easy (voir leur doc), laisser la synchronisation Blueprint atteindre 100%. Etrangement, NSPanelEasy arrive à flasher à chaque fois que j'ai eu des problèmes avec d'autres.
-
Flasher un firmware écran depuis l'interface de l'ESP (c'est très long...). Sélectionner le bon modèle de firmware à cette étape (pas comme dans l'image ci-dessous, pour ma part, c'est NSPanel EU)
-
Une fois l'écran opérationnel, dans les substitutions du YAML NSPanel Easy, ajouter :(attention au nom du firmware : ici, c'est pour flasher esphome-nspanel-lovelace-ui)
nextion_update_url: "http://<url_du_tft_cible>/lui-release.tft" -
Reflasher l'ESP, redémarrer (et éventuellement afficher les logs)
-
Sur la page de l'appareil dans Home Assistant, cliquer à nouveau sur le bouton natif "Upload TFT display". Pas de firmware à sélectionner à ce moment, c'est celui qui est indiqué dans le yaml de l'ESP qui serai transférer. Cela peut mettre trèèèèèès longtemps à passer, avec des messages d'erreur, des reboot, des trucs bizarres j'en passe et des meilleurs. C'est à ce moment que j'ai été content d'un bug sur mon PC : le copier-coller ne fonctionnait plus avec Claude.ai, et ce n'est que le temps qu'il me fallait pour recopier les message d'erreur que je voyais qui m'a permit d'attendre suffisamment longtemps pour voir enfin le flash réussir. Donc Il ne faut pas hésiter à attendre au moins une demi-heure !
-
Une fois le transfert terminé et confirmé (l'écran affiche le nouveau contenu, ex: "Waiting for content"). Forcément, il n'est plus synchro avec le firmware de l'ESP. Donc reflasher l'ESP32 avec le firmware final (ci-dessous).
Ce détour exploite le fait que le canal d'upload propre à NSPanel Easy est déjà "en confiance" avec l'écran — un outil externe (Tasmota, sairon, autre) ne l'est pas. Le protocole de communication de nspanel easy semble très bavard et coupe la chique aux autres tentatives de flash des autres firmware...
Étape 1 — Fichier YAML ESPHome final
Fichier (à adapter selon votre application, évidemment): nspanel-1.yaml
substitutions:
device_name: "nspanel-1"
friendly_name: "NSPanel 1"
panel_recv_topic: "nspanel/nspanel_1/panelRecvTopic"
panel_send_topic: "nspanel/nspanel_1/CustomSend"
esphome:
name: ${device_name}
friendly_name: ${friendly_name}
esp32:
board: esp32dev
framework:
type: esp-idf
logger:
level: DEBUG
api:
encryption:
key: !secret encryption_key
ota:
- platform: esphome
password: !secret ota_pwd
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "ap_${device_name}"
captive_portal:
# Composant NSPanel Lovelace UI (sairon)
external_components:
- source:
type: git
url: https://github.com/sairon/esphome-nspanel-lovelace-ui
ref: release/v0.3.x
components: [nspanel_lovelace]
mqtt:
id: mqtt_client
broker: <IP_de_ton_broker>
username: !secret mqtt_user
password: !secret mqtt_password
nspanel_lovelace:
id: nspanel
mqtt_recv_topic: ${panel_recv_topic}
mqtt_send_topic: ${panel_send_topic}
# Relais
switch:
- platform: gpio
pin: GPIO22
name: "Relais 1"
id: relay_1
restore_mode: ALWAYS_OFF
- platform: gpio
pin: GPIO19
name: "Relais 2"
id: relay_2
restore_mode: ALWAYS_OFF
# GPIO4 = alimentation de l'écran. ALWAYS_ON éteint l'écran (signal actif-bas) !
- platform: gpio
pin: GPIO4
id: display_enable
restore_mode: ALWAYS_OFF
internal: true
# Boutons physiques — automatisation LOCALE, pas via MQTT/HA,
# pour continuer à fonctionner même si le réseau/HA est en panne
binary_sensor:
- platform: gpio
pin:
number: GPIO14
mode: INPUT_PULLUP
inverted: true
name: "Bouton gauche"
id: button_gauche
on_click:
- switch.toggle: relay_1
- platform: gpio
pin:
number: GPIO27
mode: INPUT_PULLUP
inverted: true
name: "Bouton droit"
id: button_droit
on_click:
- switch.toggle: relay_2
# Sonde de température (calibration pont NTC du NSPanel)
sensor:
- platform: wifi_signal
name: WiFi Signal
update_interval: 60s
internal: true
- platform: ntc
id: temperature
sensor: resistance_sensor
calibration:
b_constant: 3950
reference_temperature: 25°C
reference_resistance: 10kOhm
name: Temperature
- platform: resistance
id: resistance_sensor
sensor: ntc_source
configuration: DOWNSTREAM
resistor: 11.2kOhm
internal: true
- platform: adc
id: ntc_source
pin: 38
update_interval: 10s
attenuation: 12db
internal: true
# Buzzer
output:
- platform: ledc
id: buzzer_out
pin:
number: 21
rtttl:
id: buzzer
output: buzzer_out
# Liaison série vers l'écran Nextion
uart:
- id: tf_uart
tx_pin: 16
rx_pin: 17
baud_rate: 115200
GPIO4 (activation écran) : ce pin doit être à LOW pour que l'écran s'allume (signal actif-bas). restore_mode: ALWAYS_ON éteint l'écran au démarrage — il faut ALWAYS_OFF.
Le pilotage des relais intégrés peut se gérer sous HA (avec des automations) ou directement dans l'ESP. En ce qui me concerne, une panne de HA ne doit pas empêcher une action aussi bête que allumer la lumière. La domotique, c'est un plus, ce n'est pas la fonction de base (les volets roulants fonctionnent toujours avec leur télécommande, la clim également, idem pour le portail, les porte de garage etc ...). Donc allumer la lumière ne doit pas sortir de l'ESP (hormis pour informer HA).
Étape 2 — Configuration AppDaemon
2.1 Plugin MQTT
Fichier : /opt/appdaemon/conf/appdaemon.yaml (chemin variable selon installation — sur une install manuelle en LXC, souvent /opt/appdaemon/conf/, pas /etc/appdaemon/)
appdaemon:
latitude: <ta_latitude>
longitude: <ta_longitude>
elevation: <ton_altitude>
time_zone: Europe/Paris
plugins:
HASS:
type: hass
ha_url: http://<IP_de_HA>:8123
token: !secret ha_token
MQTT:
type: mqtt
namespace: mqtt
client_host: <IP_du_broker>
client_port: 1883
client_user: !secret mqtt_user
client_password: !secret mqtt_password
logs:
main_log:
filename: /opt/appdaemon/logs/appdaemon.log
error_log:
filename: /opt/appdaemon/logs/error.log
Piège rencontré : sans le plugin MQTT, AppDaemon ne s'abonne à rien — le panel publie ses données dans le vide, l'écran reste bloqué en boucle de chargement, sans message d'erreur explicite.
2.2 Secrets
Fichier : /opt/appdaemon/conf/secrets.yaml
ha_token: "<ton_token_HA_longue_durée>"
mqtt_user: "<user_mqtt>"
mqtt_password: "<password_mqtt>"
2.3 Installation du code de l'application
Pour info, mon serveur AppDaemon est externe à HA (LXC sur Proxmox ...).
cd /opt/appdaemon/conf/apps/
git clone https://github.com/joBr99/nspanel-lovelace-ui.git nspanel-lovelace-ui-temp
cp -r nspanel-lovelace-ui-temp/apps/nspanel-lovelace-ui/* .
rm -rf nspanel-lovelace-ui-temp
2.4 Package Python requis pour la localisation (dates en français)
/opt/appdaemon/venv/bin/python3 -m pip install babel
Utiliser python3 -m pip (et non pip seul) garantit d'installer le package dans le venv d'AppDaemon, pas dans un environnement Python système différent.
2.5 Fichier de config du panel
Fichier : /opt/appdaemon/conf/apps/nspanel-1.yaml (les fichiers .yaml du dossier apps/ sont chargés automatiquement — pas besoin de les référencer depuis apps.yaml)
nspanel-1:
module: nspanel-lovelace-ui
class: NsPanelLovelaceUIManager
config:
panelRecvTopic: "nspanel/nspanel_1/panelRecvTopic"
panelSendTopic: "nspanel/nspanel_1/CustomSend"
model: eu
locale: "fr_FR"
sleepTimeout: 20
screensaver:
entity: weather.maison # remplacer par ta vraie entité météo
sleepBrightness:
- time: "7:00:00"
value: 30
- time: "23:00:00"
value: 5
cards:
- type: cardGrid
title: "Bureau"
entities:
- entity: switch.inter_bureau
- entity: light.led_bureau
- entity: cover.volet_bureau
- entity: climate.bureau_clim_bureau
- entity: navigate.bureau_thermo
name: "Chauffage"
icon: mdi:radiator
hiddenCards:
- type: cardThermo
title: "Chauffage bureau"
entity: climate.thermostat_bureau
key: bureau_thermo
Généralement, chaque modification est prise en compte quasi instantanément. Mais il arrive que cela plante. Dans ce cas, relancer AppDaemon :
systemctl restart appdaemon
Pour le reste (paramétrage de l'écran), la doc de nspanel-lovelace-ui est très bien faite. Si vous souhaitez quelques tips, n'hésitez pas à en faire la demande 
Limitations connues (non résolues à ce jour)
- Je ne vais pas parler de lovelace-ui, il y aurait trop à dire
! Mais cela reste la solution que j'ai choisi pour mon (et peut-être "mes") écrans. - Le composant
mqtt:d'ESPHome publie automatiquement toutes les entités sur des topics génériques, en plus de l'API native — doublon inoffensif mais non désactivable simplement (dit autrement, en langage humain, il y les mêmes entité sous MQTT et sous ESPHome, impossible d'y échapper).
Voilà. Un article dense, sans doute peu compréhensible (c'est facile pour moi, j'ai vécu tout ce qui est noté, donc je comprends ce que ça veut dire). Si par hasard vous avez besoin de précisions, ce sera avec plaisir.
Bonne journée à toutes et tous !
)
